<pve>
But I'm wondering if this approach has any dangerous pitfalls
<moon-child>
you mean using eclector in place of the implementation's reader? Why, out of curiosity?
<pve>
basically it sets up a readtable where all standard-characters (by default) redirect to an eclector client
<pve>
moon-child: Why, out of curiosity! :)
<moon-child>
:)
<pve>
moon-child: jokes aside, I was wondering if lukego's adventures with greek letters could be handled with eclector
heisig has quit [Quit: Leaving]
<lukego>
I don't quite have a mental model for projects like Eclector that do a new portable implementation of what's normally a primitive, like the reader. Is it something for random projects to use as a dependency? Or something for SICL? Or something to be adopted by SBCL etc in the future? Or if more than one then what are the weights?
<pve>
moon-child: also I'm working on a smalltalk-like language, and I think eclector could help me
<lukego>
I immediately worry that plugging a new reader into an existing compiler like SBCL will end up having complications, e.g. source location tracking behaving differently, but I don't know if that's founded.
<beach>
lukego: It was spun off from the SICL reader. But it exists partly because for Second Climacs we need to also return skipped material like comments, and Eclector allows that.
<moon-child>
lukego: yes, it is intended to be used by cl implementations
<moon-child>
oh, yes, also editors. I should not speak out of turn :P
amb007 has quit [Read error: Connection reset by peer]
<beach>
lukego: Furthermore, it allows you to avoid calling INTERN and you can control how tokens are made.
<lukego>
So it's not especially aimed at application/library programmers then?
amb007 has joined #commonlisp
<beach>
The Second Climacs application is an example of that, no?
<beach>
lukego: But it could also be used as the native reader of a new (or existing) Common Lisp implementation, for people who want to decrease the maintenance burden.
<lukego>
well, not in the sense I meant, since the application is using it to parse Lisp code, rather than using it to compile the application's own code
<lukego>
So quite different from my use case of just wanting to tweak the behavior of the reader for compiling my own application code.
<beach>
I see. Right, it is not a general parser for any application input.
<beach>
lukego: It is also different from what you want since you stated that you are interested specifically in how the SBCL reader works.
<lukego>
okay, so for my application it seems like Eclector would come into the picture if SBCL would adopt it as the native reader one day, or if I would swtch from SBCL to SICL
<beach>
For SICL, you won't have a choice. It's Eclector or nothing.
<lukego>
until someone invents an Even Better portable reader to plug into SICL ;-)
<beach>
I think Clasp uses Eclector, at least in later stages of the system, since Eclector can track source information too.
<beach>
That was another reason for creating it. It can wrap S-expressions in standard objects that store information about source location.
<beach>
All that in an implementation-independent way.
<lukego>
but yeah I'm keen to find excuses to dig into the SBCL code. Many years ago I kind-of understood how source location tracking worked in CMUCL and I know that it's misfiring in obvious ways on my own computer (lots of off-by-ones on top level forms when I `M-.' into SBCL internals.) Maybe once I understand that code better I'll be able to relate it to Eclector & see its potential as a reader for SBCL.
<lukego>
I haven't internalized what "implementation-independent" really means in this context though. I mean, if you use Eclector as the reader for your compiler, then that is kind of adopting it into your implementation, right? I get lost on this stuff, like with "bare metal" OS that target QEMU etc.
<moon-child>
an implementation might have its own utility functions which the reader uses. Then it would be difficult to separate the reader from the rest of the implementation and use it as a library. In either case, the reader is not provided _as_ a library
<lukego>
Seems like a jolly good project in any case :) I can absolutely see the value of modular implementations of major parts of a Lisp system, both for development of new Lisps and maintenance of old ones
<lukego>
Just less obvious how to use it. shades of "it's simple, I'm just running a GNU userspace on a FreeBSD kernel in a Linux container hosted in a Xen VM"
<lukego>
but I know that other people's brains are better at this stuff, as evidenced by people figuring out how to bootstrap systems in good ways and so on :)
<pve>
anyway, I'm pretty happy with how easily eclector lets me make a "file-local package nicknames" reader, by basically defining one method
<pve>
I think allegro's hierarchical packages could be done in the same way
<beach>
Sounds plausible.
cosimone has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
trevlif has joined #commonlisp
<trevlif>
Hi
<trevlif>
Is this channel active?
<trevlif>
I read online I can ask CL questions here
<beach>
Yes.
<beach>
trevlif: Welcome to #commonlisp.
<trevlif>
Thank you beach.
<trevlif>
Nice to meet you
<beach>
trevlif: If you have a lot of questions, and they turn out to be fairly trivial, you may at some point be redirected to #clschool, but some such question are tolerated here.
<trevlif>
I have one question, which I'm struggling with and the guides were confusing
<beach>
Go right ahead.
<trevlif>
Thanks
<trevlif>
I am trying to understand how read-time works with macro definitions and macro calls. I understand the expansion of a macro and the evaluation of parameters in the macro call via ` and ,. What I don't understand is how read-time works during the initial step of defining a macro with DEFMACRO
<trevlif>
The online specifications for DEFMACRO are very complicated to me unfortunately. For example, why isn't a ",a" in a macro definition, evaluated during the definition of the macro?
<trevlif>
and why is it evaluated during the expansion of a macro call?
<beach>
Read-time is not involved in macro definitions. The backquote syntax is turned into a macro call by the reader, like (xxx:quasiquote ... (xxx:unquote ...))
<beach>
The ` and , syntax are unrelated to macros.
<beach>
They just happen to be convenient for writing macros.
<trevlif>
Thanks, that is what I suspected. Sorry to bother, but could you expand on "Read-time is not involved in macro definitions.
<beach>
You can think of `(a ,b) as turning into (list 'a b) once the quasiquote macro has been expanded.
<trevlif>
Why is that? Isn't the macro definition being read in?
<beach>
Sure, that much it is involved.
<beach>
If you have say (defmacro m (x) (list 'list x)), the reader will of course turn that into a list.
<beach>
(DEFMACRO M (X) (LIST (QUOTE X)))
<beach>
And if you have (defmacro m (x) `(list ,x)), the reader will turn it into something like (DEFMACRO M (X) (QUASIQUOTE (LIST (UNQUOTE X))))
<beach>
But the responsibility of the reader ends there.
<trevlif>
Why is that?
<beach>
Why does the responsibility of the reader end there? Because the form has now been turned into an S-expression, and the rest is handled by EVAL.
<trevlif>
Like I get why from a practical perspective, but just curious why X is not being evaluated during the macro definition, but rather the macro expansion
<trevlif>
That makes sense
gaqwas has joined #commonlisp
<trevlif>
Is thee another eval during macro expansion?
<trevlif>
(and then another when the actual expanded form is evaluated)?
<beach>
Is your question "How does the system manage to avoid evaluating X..?" or "What is the reason for X not being evaluated?"
kakuhen_ has quit [Ping timeout: 240 seconds]
<beach>
OK, so when EVAL sees a compound form like (operator argument-form ...), it checks what the operator is.
<trevlif>
Sorry as I am a bit confused. I want to know why ,X is being evaluated during macroexpansion and not during the macro definition.
<beach>
If it is a function, the function is called on the evaluated arguments.
<beach>
If it is a macro, the macro function is called on the unealuated arguments, and the result of the macro function is then evaluated again.
<trevlif>
And it is that macro function that evaluates any items that are like ,X?
<trevlif>
That is "macroexpand" right? (or something similar)
kakuhen has joined #commonlisp
<beach>
I think I described how ` and , work. They turn into a macro call. That has nothing to do with macros at all. You can do (second `(hello ,*print-base*) at the REPL.
<beach>
No need for a macro.
<beach>
`(a , b) is just a more convenient way of expressing (list 'a b).
<beach>
Nothing to do with macros at all.
vats has joined #commonlisp
<beach>
It gets a bit more complicated when you have ,@ as well, but the idea is the same.
<trevlif>
Is a macro definition just a list then (with the parameters and other details)?
<beach>
A macro turns into a "macro function". That macro function takes the entire form, like if the macro call is (m (a b c)), then that list is given to the macro function. The macro function may or may not use that input to create a new form that is then returned by the macro function.
<beach>
That's all there is to it.
<beach>
EVAL then evaluates that new form in place of the original one.
<trevlif>
Thanks, thats pretty helpful
<beach>
Consider (defmacro m (x) (list 'list 234)).
<trevlif>
I need to connect the dots a bit more, so will have a think. But I can start to see the patterns forming and its starting to make sense (though not fully yet)
<beach>
When you write something like (m hello) then the macro function returns (list 234) as is normal.
<beach>
Then EVAL evaluates that form in place of (m hello).
<beach>
I should not have used LIST twice. Let me consider a better example...
froggey has quit [Ping timeout: 240 seconds]
<beach>
(defmacro m (x) (list 'cons 234 111))
gaqwas has quit [Ping timeout: 252 seconds]
<beach>
EVAL sees (m hello). The macro function ignores X and returns the list (cons 234 111).
<beach>
That form is then evaluted in place of (m hello).
<beach>
That's all there is.
froggey has joined #commonlisp
<trevlif>
And during the macro definition of m, nothing is evaluated yes? It is just storing (list 'cons 234 111) as part of the macro function, to be returned for expansion during a macro call?
<trevlif>
So it doesn't actually generate (cons 234 111) UNTIL eval is called as per your most recent sentence "EVAL sees .... "
<beach>
Right, (defmacro m (x) (list 'cons 234 111)) turns into something like (setf (macro-function 'm) (lambda (form environment) (list 'cons 234 111)))
<beach>
So everything is wrapped in LAMBDA and therefore not evaluated.
<trevlif>
Thank you!
<trevlif>
I think that nearly makes perfect sense
<beach>
Great!
<trevlif>
I will read through a few more times, but at least at this moment, it seems to be sticking
<trevlif>
Thank you for your help, much appreciate
<beach>
Pleasure.
amk has quit [Remote host closed the connection]
luna-is-here_ has quit [Ping timeout: 245 seconds]
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 276 seconds]
X-Scale has quit [Read error: Connection reset by peer]
notzmv has quit [Ping timeout: 252 seconds]
<moon-child>
When I first learnt lisp, coming from unix, it took me a while to grok the compilation model. There is a single lisp image, which contains both the compiler and your code
<moon-child>
Well, it almost seems like unix works that way too. AFter all, the compiler is a first-class file that operates on first-class files (source code) and produces first-class files (objects)
<moon-child>
But unix is _stratified_. The values you operate on _in_ your c code are not files, and files are not first-class elements of c
<moon-child>
lisp is not stratified
<beach>
That's an interesting analysis.
<shka>
compilation includes the runtime
<shka>
runtime includes the compilation
<shka>
running lisp process is in effect a self modifying program
attila_lendvai_ has quit [Read error: Connection reset by peer]
attila_lendvai_ has joined #commonlisp
<shka>
it is beautiful, it is like lisp itself was living being
<pjb>
trevlif: try: (macroexpand-1 '(defmacro m (x) (list 'cons x 456)))
kakuhen has quit [Quit: Leaving...]
<beach>
pjb: In SBCL, that doesn't work very well, unfortunately.
<pjb>
trevlif: in the result you should find a lambda corresponding to the macro function.
<pjb>
Well, I don't really advise sbcl to newbies…
<beach>
I understand.
<beach>
But we don't know what Common Lisp system trevlif is using.
<beach>
That is one objective with SICL, i.e., have macro expanders expand to something more obvious.
<pjb>
:-)
<pjb>
at least with macroexpand-1.
<moon-child>
pjb: what _do_ you recommend? Ccl, abcl, and clisp all produce output that seems to be similarly intimidating
<moon-child>
(at least for that particular expansion)
<trevlif>
Thank you! That helps
<trevlif>
Unfortunately I am using SBCL, is there another implementation I should use for bit more meaningful macroexpansions?
<trevlif>
It would be really helpful to get something more meaningful - its hard to follow macroexpansion at times
<flip214>
trevlif: My suggestion is to get used to that bit of noise. SBCL is much better in any other way.
<flip214>
Please note that only CL:DEFMACRO gives that noise - your own macros will be much easier to read!
<pjb>
moon-child: indeed. Often clisp and ccl give better results, but not always. Notably, ccl has a nfunction "fsubr"/special-operator, and clisp has an extension on the cl:function special operator…
<flip214>
especially if you use the convention to have a macro just defer to a function doing the work, which can be easily tested
vats has quit [Ping timeout: 252 seconds]
<beach>
flip214: How can self-written macros that are defined using DEFMACRO be less noisy than any other macro defined using DEFMACRO?
heisig has joined #commonlisp
<flip214>
beach: (DEFMACRO foo (&body body) `(progn ,@ body)), then macroexpand (via slime or manually) the form (foo 1)
<flip214>
Even in SBCL I get (PROGN 1) as output.
<flip214>
The noise is due to the CL:DEFMACRO expansion, not due to macro expansion ;)
<beach>
flip214: But the situation here was (macroexpand-1 '(defmacro ...))
<flip214>
beach: but why is expanding CL:DEFMACRO so critical?
<pjb>
flip214: it should be pedagogical!
<beach>
Because we (me and pjb) wanted to explain how DEFMACRO turned into a (lambda (form environment)...)
<flip214>
ah, okay. Sorry about my noise, then.
<trevlif>
Thanks, it was very helpful. I was okay with the other parts, but understanding how DEFMACRO worked better helped connect the missing pieces
<trevlif>
I will try CLISP also now, I want to also get into the habit of using multiple implementations
amk has joined #commonlisp
scymtym has joined #commonlisp
heisig has quit [Remote host closed the connection]
heisig has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
heisig has quit [Remote host closed the connection]
heisig has joined #commonlisp
treflip has joined #commonlisp
notzmv has joined #commonlisp
attila_lendvai_ has quit [Ping timeout: 252 seconds]
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
heisig has quit [Ping timeout: 265 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
cosimone has quit [Ping timeout: 252 seconds]
attila_lendvai_ has joined #commonlisp
attila_lendvai_ has quit [Ping timeout: 252 seconds]
<lotuseater>
(defmacro defmacro ...)
random-nick has joined #commonlisp
<shka>
yo
<shka>
is uiop/launch-program and wait-process are both thread safe?
tyson2 has joined #commonlisp
<lotuseater>
trevlif: how long are you now into the journey?
<shka>
by that i mean: can i start process on a one thread, and wait for it to finish on other
VincentVega has joined #commonlisp
karlosz has joined #commonlisp
karlosz has quit [Remote host closed the connection]
karlosz has joined #commonlisp
vats has joined #commonlisp
attila_lendvai has quit [Ping timeout: 252 seconds]
yitzi has joined #commonlisp
scymtym has quit [Ping timeout: 252 seconds]
vats has quit [Remote host closed the connection]
vats has joined #commonlisp
vats has quit [Remote host closed the connection]
vats has joined #commonlisp
robin has joined #commonlisp
cosimone has joined #commonlisp
<jcowan>
shka: The Posix man page says: "The wait() function shall suspend execution of the calling thread until status information for one of the terminated child processes of the calling process is available, or until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. If more than one thread is suspended in wait() or waitpid() awaiting termination of the same process, exactly
<jcowan>
one thread shall return the process status at the time of the target process termination."
scymtym has joined #commonlisp
<jcowan>
So at the Posix level it's safe.
<shka>
jcowan: thanks, but i am seeing thread hanged on wait but exit-code was 0
<lotuseater>
beach: hihi yes ^^ and by the way, i at the weekend i loaded the SICL LOOP module into my SBCL session, works good and now the macroexpands are more readable :)
<beach>
Ah, yes. Xach has been known to do that in order to check that programs are conforming.
<beach>
In fact, just a few hours ago, I found two violations of the LOOP syntax in a module written by heisig.
<beach>
I sometimes get it wrong myself, so it is good to have a strict implementation of LOOP.
<beach>
lotuseater: Later on in the bootstrapping process, the actual definition is loaded.
<lotuseater>
even the other filename defmacro-defmacro.lisp is amusing :)
<beach>
Indeed.
<lotuseater>
okay how to work with environments I'm not aware of
<beach>
You usually can't.
<lotuseater>
but I wrote some lines with heisig last week, it sounded like he is happy for help with sb-simd or other repos
<lotuseater>
okay why not?
<beach>
A typical Common Lisp implementation does not have an explicit representation for the global environment. It is spread out over the system. Functions with symbols as names might be kept in a slot in a symbol object. Method combinations might be stored in a hash table, etc.
<beach>
Type definitions might be in a different hash table, that is a value of a special variable.
<lotuseater>
phew
<beach>
I thought that was pretty messy, so I invented first-class global environments.
<lotuseater>
If you don't feel I could really understand it. :/
<beach>
The paper is not complicated. It's the idea that someone had to have.
<lotuseater>
but I wanted to read the ~50 pages about petalisp
kevingal has joined #commonlisp
<beach>
That's a good idea!
trevlif has left #commonlisp [ERC (IRC client for Emacs 26.3)]
Bike has joined #commonlisp
didi has joined #commonlisp
<didi>
I always struggle to decide between &rest or &optional when defining a lambda list that expects a set of objects. For example, (defun fn (&optional list) ...) against (defun fn (&rest list) ...). Calling (fn a b c) is more convenient than (fn '(a b c)), but (apply #'fn list) against (fn list) is not. There is also a limit to the number of arguments a function can have, so (apply #'fn list) is less robust than (fn list).
<lotuseater>
use &optional if you know the number of args and &rest if not exactly
<lotuseater>
but beware Norvig's golden rule, never mix &optional and &key without isolating :)
<lotuseater>
so not (defun foo (&optional a b &key c) ...) but you could use (defun foo ((&optional a b) &key c) ...)
<lotuseater>
and APPLY and FUNCALL are useful in function bodies when, well, applying a function you get as an argument
frgo has quit [Remote host closed the connection]
Fare has joined #commonlisp
<lotuseater>
&optional gives you the additional power for having initforms to the arguments like with &key
<Xach>
lotuseater: you cannot use (defun foo ((&optional a b) &key c) ...). Perhaps you are thinking of defmacro.
<lotuseater>
oh hm, okay, thanks
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #commonlisp
<didi>
lotuseater: I'm unsure how these pertain to the problem at hand, but thanks.
<lotuseater>
okay good to know, all must be symbols in DEFUN
Inline has quit [Quit: Leaving]
<didi>
I guess I should use &optional if I want to be portable. SBCL's CALL-ARGUMENTS-LIMIT is 4611686018427387903, but it could be 50.
Alfr has quit [Ping timeout: 250 seconds]
Fare has quit [Remote host closed the connection]
Fare has joined #commonlisp
frgo has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
frgo_ has joined #commonlisp
frgo has quit [Ping timeout: 252 seconds]
waleee has joined #commonlisp
<phoe>
didi: ABCL's is 50.
karlosz has quit [Quit: karlosz]
tyson2 has joined #commonlisp
Alfr has joined #commonlisp
Inline has joined #commonlisp
Qwnavery has quit [Quit: WeeChat 3.2]
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
Cymew has quit [Ping timeout: 252 seconds]
frgo has joined #commonlisp
frgo_ has quit [Ping timeout: 252 seconds]
tfb has joined #commonlisp
<jcowan>
beach: Reinvented
<pjb>
didi: use &rest and parse it to accept both elements and a final list!
<pjb>
Note: (defun foo-process (list) #| no optional or rest here! |#)
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<beach>
jcowan: First-class global environments you mean? I saw no evidence in the literature of a solution to the performance problem of having every lookup be through a hash table.
<beach>
jcowan: But you probably didn't read the paper since it is too long for your liking, so perhaps you missed that part.
<beach>
Slow first-class global environments are common in the literature, though.
<didi>
pjb: It's a compromise. If I understand correctly one would eval (foo a '()) to call against one argument.
<didi>
Or (foo '(a)).
<didi>
phoe: Curiously low.
vats has quit [Ping timeout: 260 seconds]
attila_lendvai has joined #commonlisp
<jcowan>
beach: I did indeed read your paper. I have started the Queinnec paper now.
<jcowan>
I am not trying to deprive you of your rightful credit
<beach>
Good.
kuler has joined #commonlisp
<pjb>
didi: or detect if the last argument is a list.
<didi>
pjb: Ah, but you see, an element can also be a list.
<pjb>
didi: but indeed, you should not confuse (foo '(a)) == (foo 'a nil) with (foo '((a))) == (foo '(a) nil)
<pjb>
So sometimes you may want to add a nil as last argument…
<didi>
pjb: Right, but if I need to start adding sentinels, I prefer to use &optional list.
<pjb>
But you can always wrap them in a list: (foo (list e1 e2 e3)) to be sure. (works whether e3 is an atom or not).
<pjb>
In anycase you still need to handle the case, when you have more than one element.
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
Fare has quit [Ping timeout: 252 seconds]
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
frgo has quit [Remote host closed the connection]
attila_lendvai_ has joined #commonlisp
Fare has joined #commonlisp
<didi>
Can/Should I use an `ASSERT' form inside a DEFMACRO to make sure the user passed a symbol?
<White_Flame>
only if you want to override the default error
<didi>
White_Flame: Thank you.
yitzi has quit [Quit: Leaving]
<pjb>
didi: it's a complex question.
<pjb>
didi: you have 2 forms for assert. with and without places. without places, assert will just signal an error and you will have to abort. With places, assert will let you use restarts to set those places and try the assert again.
<pjb>
didi: this is what you can do with check-type too.
<pjb>
didi: but in all cases, this doesn't give a very good or informative error message or restart for your macro.
<pjb>
didi: it may be preferable to test for the error condition, and signal a more specific error condition, with a clearer message, in the context of your macro.
<pjb>
(defmacro foo (name) (unless (symbolp name) (error 'bad-foo-argument :parameter 'name :value name :type (type-of name) :expected-type 'symbol :format-control "You passed ~S which is of type ~S to the macro ~S, but it expected a ~S" :format-arguments (list name (type-of name) 'foo 'symbol))) `(list ',name)) (foo 42) --> error: You passed 42 which is of type (integer 42 42) to the macro FOO, but it expected a SYMBOL ; Way better !
<didi>
oic
<pjb>
didi: that said, conditions signaled by macros are usually caught only by the compiler or the callers of the compiler (compile, compile-file, eval, possibly coerce), so the usefulness of defining specific conditions for them is debatable.
<White_Flame>
didi: what error message do you currently get when you macroexpand without your own error check?
<White_Flame>
sbcl is pretty good with errors about "123 is not a symbol and cannot be used as a local variable" etc already
<pjb>
Using one of the simple-…-error condition could be enough (but the standard only defines simple-type-error).
<didi>
White_Flame: " (U) is not a symbol and cannot be used as a local variable."
<White_Flame>
and that's not enough of an error description for this use case?
<didi>
White_Flame: I think it is.
<White_Flame>
for things like (with-open-file (4 "foo.txt") ...), it expands to LET, which gets you that local variable error as well, which makes sense for that parameter of the macro
silasfox has quit [Ping timeout: 240 seconds]
<didi>
Incidentally, I'm expanding to LET too.
<White_Flame>
right
<White_Flame>
that's one big advantage of macros (or well I guess any composition) is that you automatically get the features of the expansion already
luna-is-here has joined #commonlisp
silasfox has joined #commonlisp
silasfox has quit [Ping timeout: 260 seconds]
yitzi has joined #commonlisp
silasfox has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
silasfox has quit [Ping timeout: 252 seconds]
cage has joined #commonlisp
<didi>
Isn't it curious DOLIST doesn't do destructuring?
<pjb>
(dolist (entry list) (destructuring-bind (x y z) entry …))
<didi>
Sure sure.
<pjb>
didi: one problem is that destructuring-bind will signal errors if the entry cannot be parsed.
<pjb>
and dolist was certainly invented before destructuring-bind.
<pjb>
Perhaps it's even used in it!
amb007 has quit [Ping timeout: 252 seconds]
<didi>
It's DOLIST all the way down.
amb007 has joined #commonlisp
lisp123 has joined #commonlisp
<pjb>
didi: the thing is that it's too easy: (defmacro dbdolist (bindings list-expression &optional result-expression) (let ((ventry (gensym))) `(dolist (,ventry ,list-expression ,result-expression) ,(if (atom bindings) `(let ((,bindings ,ventry)) ,@body) `(destructuring-bind ,bindings ,ventry ,@body)))))
<pjb>
didi: and there, you have it!
<didi>
pjb: Thanks.
seok has quit [Ping timeout: 256 seconds]
lottaquestions has joined #commonlisp
Alfr has quit [Quit: Leaving]
lisp123_ has joined #commonlisp
tyson2 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
<lisp123_>
Quick Qn - how to re-run ASDF tests (asdf:test-system)? I changed my test files, but it seems like ASDF is referring to the old versions
<Shinmera>
depends on your setup.
<lisp123_>
Shinmera: Actually I am using parachute! :) Great tool
<lisp123_>
I deleted a test, but it is still running when I try asdf:test-system again
<Shinmera>
By 'deleting a test' you mean you removed the define-test form from the source file?
<lisp123_>
Yes
<Shinmera>
Lisp doesn't know you 'deleted' things since it doesn't track definitions within files.
<Shinmera>
You have to call parachute:remove-test
<pjb>
or reboot your lisp.
<Shinmera>
Same for any other source file, if you just delete the defun and reload, lisp is none the wiser. You have to manually fmakunbound.
<Shinmera>
Or whatever other equivalent for whatever definition you had.
<pjb>
Notably, for methods… Hence the use of remove-method.
<pjb>
or sometimes (unintern 'foo), but it may not be enough to undo (there may remain references to the newly uninterned symbol #:foo).
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
<lisp123_>
Thanks
<lisp123_>
Shinmera: I am getting an error "no test found", is that because I recompiled without the test?
<lisp123_>
Or its a user error on my end?
<Shinmera>
tests in parachute are local to a package, make sure you either pass the test package or are in the test package.
<lisp123_>
Thanks! That did it. Thanks again
<Shinmera>
No problem
<lisp123_>
pjb: thanks for the info
amb007 has quit [Read error: Connection reset by peer]
<scymtym>
this is just talking the wire protocol over a UNIX socket, allocating shared memory, transmitting the shm file descriptor and, the part you are probably wondering about, rendering into the shared memory using McCLIM's software renderer
<shka>
oh, ok
<shka>
actually less complex then i thought
<shka>
still cool
<scymtym>
thanks
<scymtym>
you would need mostly the same machinery for client-side OpenGL rendering
karlosz has quit [Quit: karlosz]
jasom has joined #commonlisp
cage has joined #commonlisp
karlosz has joined #commonlisp
vats has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
karlosz has quit [Quit: karlosz]
rain3 has joined #commonlisp
karlosz has joined #commonlisp
<lisp123_>
Is there a way to step back in slime?
<shka>
in a debugger?
<lisp123_>
after doing a step-next, or is this impossible
<lisp123_>
shka: yes
kevingal has quit [Read error: Connection reset by peer]
<shka>
i don't think so
<lisp123_>
Thanks. Thought so too (given its based on restarts)
Alfr has joined #commonlisp
treflip has quit [Remote host closed the connection]
gaqwas has joined #commonlisp
vats has quit [Ping timeout: 252 seconds]
tfeb has joined #commonlisp
<pjb>
lisp123_: theorically, it's not impossible, but no known lisp debugger has implemented it.
<pjb>
lisp123_: you may have a look at cl-stepper.
<pjb>
lisp123_: note that if you want to be able to mutate the state and continue the execution from a point in the past, you'll need to implement continuations in CL. But it is possible that delimited continuations are enough, if you just drop the alternate futures.
<pjb>
lisp123_: otherwise cf. time travelling debuggers.
<pjb>
lisp123_: (they make snapshots on syscalls, and to go back, they actually restore the previous snapshot and execute forward until the previous instruction/expression).
<tfeb>
I hate to say this but in desperation I have stepped back in a debugger by saving & restoring worlds.
karlosz has quit [Quit: karlosz]
yitzi has quit [Ping timeout: 252 seconds]
pve has quit [Quit: leaving]
<tfeb>
(a long time ago on a system which took many hours to get to the state before the state that killed it)
<pjb>
tfeb: indeed, it's a possibility in CL to save the lisp image often…
<pjb>
But in general, this doesn't save the threads. clisp makes big efforts to restore stuff.
akoana has joined #commonlisp
<bhyde[m]>
interlisp had deep support for undo; so you could run forward and backward. see https://larrymasinter.net/interlisp-ieee.pdf, for example the mention of undo at the bottom of the first column
<tfeb>
pjb: yes, I was just about to ask if there were any systems other than dmachines which could do the 'restart the world from where it left off' thing
<jcowan>
Someone should port the Interlisp File Manager (or part of it) to CL
<tfeb>
I have turned off a d machine, carried it downstars, turned it on ... and continued a telnet session
<jcowan>
Well, provided you can do it within the telneted-to system's TCP timeout
<tfeb>
right, which must have been kong enough (also probably old-fashioned ethernet probably helped, so no switches getting in the way)
dra has joined #commonlisp
<lisp123_>
pjb: Thanks
didi has left #commonlisp [O bella ciao bella ciao bella ciao, ciao, ciao.]
<lisp123_>
pjb: Do you have a channel for cl-stepper?
<pjb>
none.
<lisp123_>
Do you want to go to #cl-stepper? Had a quick qn
<lisp123_>
(if you have time of course)
tfeb has quit [Quit: died]
tfeb has joined #commonlisp
rain3 has quit [Quit: Leaving]
cage has quit [Remote host closed the connection]
scymtym has quit [Ping timeout: 252 seconds]
<jcowan>
bhyde[m]: Interlisp and Medley are on-topic at #lisp; it would be nice to have someone else there (who knows more than I do)
saltrocklamp[m] has quit [Changing host]
saltrocklamp[m] has joined #commonlisp
tfeb has quit [Remote host closed the connection]
contrapunctus has left #commonlisp [#commonlisp]
contrapunctus has joined #commonlisp
scymtym has joined #commonlisp
scymtym has quit [Remote host closed the connection]
scymtym has joined #commonlisp
Skyfire has quit [Quit: brb]
Lord_of_Life_ has joined #commonlisp
Skyfire has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life_ is now known as Lord_of_Life
Inline has quit [Quit: Leaving]
ec_ has joined #commonlisp
Inline has joined #commonlisp
gaqwas has quit [Read error: No route to host]
gaqwas has joined #commonlisp
elderK has joined #commonlisp
lisp123_ has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 260 seconds]
karlosz has joined #commonlisp
shka has quit [Ping timeout: 265 seconds]
lisp123 has joined #commonlisp
hexology has quit [Quit: hex on you ...]
contrapunctus has left #commonlisp [#commonlisp]
gaqwas has quit [Ping timeout: 252 seconds]
zagura has quit [Ping timeout: 240 seconds]
contrapunctus has joined #commonlisp
hendursaga has quit [Ping timeout: 276 seconds]
hendursaga has joined #commonlisp
attila_lendvai has quit [Ping timeout: 252 seconds]
zagura__ has joined #commonlisp
cosimone` has quit [Ping timeout: 252 seconds]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
dre has joined #commonlisp
dra has quit [Remote host closed the connection]
VincentV` has quit [Remote host closed the connection]