freenode/#lisp - IRC Chatlog
Search
6:36:48
loke`
The onyl way I can get around this, it seems, is by getting the cert used for signing and add that manually.
6:56:29
resttime
https://github.com/fukamachi/dexador/commit/0b0e0b56f9c695d052a46c85f9e20f6e30946526#diff-94c10f296dac06851e39cc9ad5773f9b
8:12:19
Shinmera
Dexador is nicely fast (drakma is dog slow), but I've had some issues with it just erroring over simple stuff
8:12:32
Shinmera
Don't remember the context of the breakage, but it wasn't even anything about cl+ssl.
14:39:39
drmeister
Is anyone interested in writing a Common Lisp library to parse DWARF? It would be generally useful to get Common Lisp to understand C++ code.
14:40:32
drmeister
I'm interested because we've got a Common Lisp compiler (Clasp) that generates DWARF and I'd like to use a DWARF interpreter for the debugger.
14:41:42
Xach
https://github.com/angavrilov/cl-linux-debug/blob/master/code-info/dwarf.lisp is the first thing on google, but i don't think that's what i was remembering.
14:43:16
drmeister
What did you google? I swear I've used the google dozens of times looking for things like this.
14:44:09
drmeister
If anyone knows anything about Common Lisp libraries to interpret DWARF - I'd love to hear about it.
14:44:55
drmeister
We generate DWARF and are going to do it better in the near future with the wonderful new cst-to-ast source tracking features that beach has added to Cleavir.
14:45:39
drmeister
But like the cursed cook who can prepare sumptuous meals - but never taste them - we generate DWARF but cannot interpret it.
14:46:51
jurov
Seems I've found a quicklisp/asdf bug. When a system has a.lisp and b.lisp and macro in b.lisp calls a function A from a.lisp at loading time...
14:46:53
drmeister
In other news - Clasp now has multithreading with compacting semi-conservative garbage collection.
14:47:02
jurov
...later I updated A, but the compiled macro was not recompiled by quicklisp, I had to remove cached fasl files.
14:49:25
drmeister
Some things are and some things aren't. Integer numerical code is approaching C/Fortran speed - maybe off by a factor of 2. The compiler is slow.
14:49:44
Xach
jurov: you changed a.lisp and saved the file but b.lisp was not updated when you used (asdf:load-system "your-system")?
14:49:59
Shinmera
drmeister: Last time we had MPS running it was a significant factor slower than Boehm
14:50:53
drmeister
Shinmera: Ah - yes - I haven't profiled it much yet but it's about as fast as Boehm. The bottlenecks we experience are not due to the GC.
14:51:29
drmeister
The problems we had before were probably due to a multi-megabyte character property array that was being allocated during startup.
14:52:01
drmeister
Stassats found that and we removed it. It was also being created in ECL - but not to the same extent.
14:53:53
drmeister
I don't look to our previous experiences with MPS as illuminating anything about performance - there were too many problems with my implementation.
14:55:19
jurov
Xach ah yes, the a.lisp and b.lisp are just listed as components without any :depends-on info
14:55:45
drmeister
The thing about MPS is that allocations are just pointer bumps. Once we get allocations inlined into the Common Lisp code that uses them - they will be as fast as they can be.
15:00:18
Xach
jurov: can you share the system file? and the other files? or maybe provide simplified versions? i'm still quite curious
15:00:24
jurov
OK. It's actually this one: https://github.com/adolenc/cl-neovim/blob/master/cl-neovim.asd . the macro is in api.lisp and the function called by macro is in vim-utils.lisp
15:01:36
Xach
jurov: and you observe that changing vim-utils.lisp and saving it, then using (asdf:load-system "cl-neovim") does not result in recompiling api.lisp?
15:02:31
jurov
Yes. I commented out #'clean-up-name in vim-utils completely and system loaded despite that
15:04:29
scymtym
Xach: in my mental model, :serial only affects immediately contained :components, not transitively contained ones
15:06:45
smokeink
Is it possible in CL to replace 't with 'true ? (define-symbol-macro true 't) can make 'true be read as 't , but how to make the repl display true instead of t (when something evals to t) ?
15:15:42
smokeink
tried this but it doesn't work: (defmethod print-object ((obj t) out) (format out "~A" 'true))
15:18:07
smokeink
yes, I thought so , but how to make it work for any class, including the class of 't itself ? Actually I need it to work just for 't
15:21:09
beach
smokeink: You might want to try ((obj (eql t)) out) but I am pretty sure that this would be undefined behavior.
15:31:19
beach
smokeink: Mostly, you are not allowed to modify the behavior of a Common Lisp system with respect to the standard objects of that system. The rule is not as general as I am stating it here, but that's the essence of it.
15:48:59
pjb
smokeink: (defgeneric my-print-object (o s) (:method (o s) (print-object o s)) (:method ((o (eql t)) s) (princ "true" s) o))
15:50:51
jackdaniel
another angle to do that would be defining around method on print-object and "stealing" the flow if t is passed (also unportable)
16:16:11
jackdaniel
but in principle each undefined behavior trigger is an invitation for nasal daemons
16:17:49
jackdaniel
yes, but from the cognitive perspective of language, by asking: how portable is this and this means – how likely will it fail
16:18:04
jackdaniel
otherwise "bordeaux threads is a portability layer" wouldn't make much sense, would it?
16:19:20
Shinmera
Well, it does make sense, because it extends the specification of the CLHS by its own interface, thus extending what it means to be portable.
16:19:43
_death
smokeink: it is precisely for doing this kind of thing, customized pretty-printing of lisp forms
16:19:59
Shinmera
If an implementation is not supported by it, then that implementation is not conforming, making it irrelevant for the question of whether code is portable on it or not
16:23:06
jackdaniel
code which uses threads (even through bt) isn't portable if we take definition you have linked a few lines above
16:24:50
pjb
BT can only aim at covering the implementations that implement a threading extension, but not all implementation do. So writing code using threads cannot be portable by definition.
16:25:25
pjb
Your application is only portable to the intersection of all the supported set of all its dependencies.
16:25:27
_death
the clhs definition is a stipulative one.. not very good for trying to understand the common use of the term
16:25:48
pjb
Often this restricts the practical portability to very few implementations, platforms and systems.
16:26:25
pjb
Shinmera: it would be nice, but very few implementation take the pain of implementing a portability layer API. cffi, bt, closer-mop, etc.
16:27:08
pjb
Sometimes they may move slowly toward better support (eg. asdf), but there's no will to boldly implement those interfaces directly.
16:27:09
jackdaniel
Shinmera: in that case what smokeink wants may be considered his informal spec. then it works where it works. word portability loses its meaning, or indeed we agree, that this definition can't be taken verbatim in conversation proceeded in natural language
16:28:45
Shinmera
As we have already determined, there are better ways in which his actual question could have been formulated, though.
16:28:46
jackdaniel
so if you know, then saying that "it's not a gradient" was referring not to the *meaning* he used, but something what it has common term with
16:30:41
Shinmera
Just because I can leniently interpret sentences does not mean I agree with the way they were expressed.
18:13:36
pjb
For your custom-defined CLOS objects, you need to implement PRINT-OBJECT and depending on the syntax used when printing it readably, reader macros.
18:15:39
pjb
jmercouris: ie. your first reflex should have been /msg specbot clhs read-from-string RET /msg specbot clhs *print-readably* RET /msg specbot clhs prin1-to-string RET