<moon-child>
recordgroovy: I am not so sure of the special-casing of eof. Usually it makes more sense to treat the eof as just another kind of token
<recordgroovy>
Yeah that probably makes more sense. I'll put that in my todo.
hineios has joined #commonlisp
zacts has joined #commonlisp
zacts has quit [Quit: Client closed]
waleee has quit [Ping timeout: 255 seconds]
cjb has quit [Quit: rcirc on GNU Emacs 28.0.50]
mister_m` has quit [Ping timeout: 265 seconds]
tyson2 has quit [Remote host closed the connection]
prxq_ has joined #commonlisp
prxq has quit [Ping timeout: 268 seconds]
makomo has quit [Ping timeout: 252 seconds]
srhm has quit [Quit: Konversation terminated!]
<beach>
Good morning everyone!
cjb has joined #commonlisp
mister_m has joined #commonlisp
recordgroovy has quit [Quit: leaving]
derelict_ has joined #commonlisp
<Mrtn[m]>
It's raining. At least according to my watch.
<hayley>
Looks like it just stopped here. Have fun.
hafat has quit [Ping timeout: 276 seconds]
Oladon has joined #commonlisp
Bike has quit [Quit: Lost terminal]
mister_m has quit [Remote host closed the connection]
Inline has quit [Quit: Leaving]
Melantha has quit [Ping timeout: 256 seconds]
mariari has quit [Ping timeout: 256 seconds]
mariari has joined #commonlisp
mariari has quit [Ping timeout: 268 seconds]
mariari has joined #commonlisp
selwyn has joined #commonlisp
gaqwas has joined #commonlisp
peterhil has joined #commonlisp
mariari has quit [Ping timeout: 245 seconds]
selwyn has quit [Read error: Connection reset by peer]
mariari has joined #commonlisp
Oladon has quit [Quit: Leaving.]
lotuseater has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life has joined #commonlisp
lottaquestions has joined #commonlisp
lottaquestions_ has quit [Ping timeout: 252 seconds]
lottaquestions has quit [Client Quit]
lottaquestions has joined #commonlisp
cjb has quit [Quit: rcirc on GNU Emacs 28.0.50]
<phantomics>
recordgroovy: Looks interesting at a glance, very neat code. I'll give it a try when I have time
gaqwas has quit [Ping timeout: 252 seconds]
<susam>
Good morning, everyone!
<beach>
Hello susam.
shka has joined #commonlisp
<susam>
Hello beach!
kakuhen has joined #commonlisp
Th30n has joined #commonlisp
<pjb>
<pjb>
lotuseater: I've seen big systems defining some dispatching reader macros on $ ; but nowadays, with unicode, you can more often just define a reader macro on a unicode character.
<pjb>
Depending on what you need.
<lotuseater>
thx pjb
<lotuseater>
Hi there beach :)
<lotuseater>
Narrow-minded employment in Germany is really annoying.
tfeb has joined #commonlisp
attila_lendvai has joined #commonlisp
tfeb has quit [Quit: died]
<kakuhen>
Is it possible for eval-when to implicitly modify arguments of functions like find-class?
layerex has joined #commonlisp
<kakuhen>
I have a macro that transforms a given symbol and creates a class named with this transformed symbol, together with methods specialized on the class.
<kakuhen>
Say this transformed symbol is X. Both CCL and SBCL throw style warnings that my defmethod's are using the undefined type X, but the class was defined right before I define these methods.
<pjb>
kakuhen: not eval-when directly, but eval-when implies that the body will be evaluated in different environments, so it's possible that operators that may depend on the environment such as find-class give different results.
<kakuhen>
So I decided to wrap (defclass X () ...) in an eval-when form. Above in the macro, I check the output (find-class X nil). When I use eval-when, errorp somehow becomes T rather than nil
<pjb>
It should be the job of the programmer to ensure that the differences are not semantically different.
<kakuhen>
This issues goes away, however, when I use (find-class X nil nil)
<pjb>
try: (find-class 'x t nil)
<kakuhen>
pjb: Yeah, I suspect eval-when implying a different environment somehow makes the arguments supplied to FIND-CLASS "flip," but it wouldn't explain why this issues goes away when I supply the environment.
<pjb>
find-class is a function.
<kakuhen>
anyway, I am trying this because SBCL and CCL are giving me style warnings (ECL doesn't give style warnings), and I assume it could be a bug in both SBCL and CCL's compiler, but I don't want to jump to such conclusions yet.
<kakuhen>
and I get strange behavior with FIND-CLASS when I include an (eval-when (:compile-toplevel :load-toplevel) ...) in the macro
<pjb>
You must be doing somethign strange, because a simple toplevel sequence of defclass defmethod should work nicely.
<kakuhen>
Anyway, I am trying to produce a minimal working example of the style warnings SBCL and CCL produce
pve has joined #commonlisp
<kakuhen>
SBCL produces twice as many style warnings as CCL, so it's catching(?) something that CCL isn't. Meanwhile ECL just gives zero style warnings.
<pjb>
kakuhen: so, your macro should expand to (progn (defclass x () ()) (defmethod moo ((x x)) …))
<kakuhen>
I'm not sure why a type for a class wouldn't propagate after you define it
<beach>
kakuhen: The dictionary entry for DEFCLASS contains a phrase that makes its compile-time behavior very hard to understand.
<beach>
That might be the reason for the differences in behavior of different implementations.
<beach>
It is essentially impossible for an implementation to comply with what the standard says.
<kakuhen>
I see. And, before it gets asked, yes, I set the debug level to 3 before compiling on each implementation.
<pjb>
"If a defclass form appears as a top level form, the compiler must make the class name be recognized as a valid type name in subsequent declarations (as for deftype) and be recognized as a valid class name for defmethod parameter specializers and for use as the :metaclass option of a subsequent defclass. The compiler must make the class definition available to be returned by find-class when its environment argument is a value received
<pjb>
as the environment parameter of a macro. "
<beach>
It's the last phrase that is problematic.
<pjb>
Indeed.
<pjb>
Hence the difference observed by kakuhen.
<beach>
Possibly, yes.
<pjb>
kakuhen: But I've seen nothing that implies a need for eval-when in your macro expansion. Just use progn around your defclass and defmethod forms.
<kakuhen>
The style warnings disappear on both SBCL and CCL once I use (find-class X nil nil) and put the defclass in this eval-when block(?)
<kakuhen>
but I found an interesting behavior where ERRORP automatically gets set to T (on both sbcl and ccl!) if I just have (find-class X nil) written, and the defclass is in this eval-when block
treflip has joined #commonlisp
<kakuhen>
this behavior mysteriously goes away if I do one of two things: remove the eval-when block, or explicitly provide the environment
<kakuhen>
I'm trying to produce a minimal working example but so far I haven't been able to reproduce the style warnings, yet.
<beach>
I would be interested in complete examples of what happens in different implementations and what you expected to happen. But take your time.
<beach>
kakuhen: It is not enough to say that the definition is in an "eval-when block". The "situations" given in that form are important too.
<beach>
That's why we need complete examples.
layerex has quit [Quit: Leaving]
<kakuhen>
OK I found out why I was unable to produce a minimal working example of this issue
<kakuhen>
I was looking in the wrong macro >_<
<lotuseater>
nice what was it?
pranavats has left #commonlisp [Disconnected: Received SIGTERM]
<kakuhen>
Ok this will sound really dumb, but I have a macro %FOO and a macro FOO that calls %FOO with a restart-case
<kakuhen>
Calling (%FOO bar) does not give the undefined type warning. Calling (FOO bar) does.
<lotuseater>
hmm, see the advise of beach from 10:05
<kakuhen>
i understand the importance, but i also want to minimize irrelevant information -- you'll know i've given up in attempting to produce a minimal example when i just send the entire lisp file along with the repl output for each implementation.
<kakuhen>
Okay I got the example -- really excited now
<lotuseater>
hehe
<beach>
You also need to show when the behavior you observe happens, like if it is at compile time, load time, or run time.
<lotuseater>
beach: this is given by the kind of error the debugger throws, right?
<lotuseater>
kakuhen: do you need a macro for foo?
<beach>
lotuseater: Wow, hold on! First errors are not "thrown", they are "signaled". Second, it is not typically the debugger that signals the error, but the application code, which will call the debugger if the error is not handled. Third, no, the same error can be signaled in all three situations.
<kakuhen>
Expected behavior: I expect the new class' corresponding type to be defined before we define the method specializing on the new class.
<kakuhen>
ECL does not give any style warnings, but I will nonetheless give output for it soon.
pranavats has left #commonlisp [Disconnected: Received SIGTERM]
<kakuhen>
These style warnings disappear when the defclass is compiled and loaded at the top level, that is, we place it inside (eval-when (:compile-toplevel :load-toplevel :execute) ...)
<kakuhen>
But this opens up a can of worms where FIND-CLASS suddenly sets ERRORP to T despite supplying NIL to it. This goes away if you explicitly provide NIL for both ERRORP and ENVIRONMENT
pranavats has joined #commonlisp
<beach>
kakuhen: I see no trace of the argument to FIND-CLASS having been altered. I see essentially the same behavior, i.e. that the class is not recognized. And I think it will take me some time to figure out why. Others here are usually much faster.
<beach>
kakuhen: Did you try macro expanding some stuff?
prxq_ is now known as prxq
<kakuhen>
Yes. And it seemed fine to me. It was invoking FIND-CLASS exactly as I intended, yet ERRORP would be set to T
<kakuhen>
I am currently working on an example that reproduces this behavior
<beach>
kakuhen: And, again, your examples don't show how you compiled and/or loaded the file containing the macro definitions.
<kakuhen>
ah... I'm running C-c C-c in SLY, and I denoted in the file where I have compiled both
<kakuhen>
that corresponds to compile and loading a region
<kakuhen>
is there a lisp function I can invoke at the REPL to explicitly do this?
<beach>
(load (compile-file ...)) if file-compilation semantics is what you want.
<kakuhen>
That seems like what I want, I'll do that for my next outputs.
<beach>
But I don't know what SLY uses.
<beach>
It might do something entirely different.
<beach>
You say "It was invoking FIND-CLASS", but what makes you so sure about that?
<beach>
And what makes you think that FIND-CLASS should be invoked as you intended, rather than as the system decided to invoke it?
<kakuhen>
beach: here is a working example where FIND-CLASS mysterious gets ERRORP set to T http://0x0.st/-WyX.lisp
<kakuhen>
I will post the output from CCL soon, and this time I am compiling and loading at the REPL.
<beach>
There is also the question of what the current package is at compile time.
<beach>
It happens when the DEFMETHOD form is evaluated.
<kakuhen>
Wouldn't that imply the DEFMETHOD form is evaluated before my own FIND-CLASS call?
<kakuhen>
It's not obvious to me why that would happen
<beach>
Not necessarily. The DEFMETHOD macro probably turns names into classes.
<beach>
Whereas your FIND-CLASS call is not evaluated until load time.
<kakuhen>
Okay, I guess that settles the issue with the FIND-CLASS call. This convinced me that my earlier interpretation is incorrect.
<kakuhen>
Thank you for being patient with me by the way
<kakuhen>
Now my remaining question is the cause of the style warnings.
<beach>
Anyway, the FIND-CLASS call is not yours. it is done by the call to ENSURE-METHOD.
<beach>
I could be wrong about the details, but I am pretty sure of the last thing.
<beach>
Even if your call to FIND-CLASS is evaluated before the defmethod form, you would not see any output from your find-class call.
<kakuhen>
I would like to correct myself on what I said at 01:23 PDT. The FIND-CLASS call that ultimately signals an error does not occur when I specify (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) in my eval-when block. It occurs when I am missing the :EXECUTE symbol
<kakuhen>
So this error is more due to myself misusing / not understanding what happens when I use EVAL-WHEN with specific arguments
peterhil has joined #commonlisp
<beach>
Also, every new attempt must be done in a fresh image, or else, you may have altered the global state of your environment in previous attempts.
<kakuhen>
Yes. When I made the separate examples, I made sure to restart my lisp image and delete the FASLs generated by the compiler
<kakuhen>
I did leave the alexandria FASLs untouched, however.
<beach>
That should still work.
Melantha has joined #commonlisp
makomo has joined #commonlisp
<kakuhen>
lotuseater: The reason I have a macro that calls %foo is so that I can pass symbols as arguments. I originally had FOO as a function in my actual code, but ALEXANDRIA:SYMBOLICATE would then complain that I supplied neither a symbol nor a string.
<beach>
Anyway, that backtrace that confused you reminded me of a rule I made for SICL system code (but that I have not had the energy to implement entirely yet), namely that if a standard operator A calls another standard operator B, then A should make sure that B succeeds or else capture any errors by B so that the ultimate error is signaled in terms of A.
scymtym has joined #commonlisp
<beach>
If that rule had been followed here, you would not have seen a call to FIND-CLASS in the backtrace.
<beach>
kakuhen: It would be much preferable if you could eliminate a lot of extraneous stuff to provide a minimal example. Those macro combinations, and the call to Alexandria make it harder to follow.
<kakuhen>
What I provided in http://0x0.st/-Wy-.lisp is enough to reproduce the warning, but I will attempt removing the call to Alexandria right now. Unfortunately, I am unable to reproduce the style warnings unless I have those macro combinations. The style warnings happen when FOO is called, but not when %FOO itself is called.
<beach>
But is the restart-case really necessary?
<beach>
[for instance]
<kakuhen>
Yes. In my original code, there is a scenario where a condition I made gets signalled, and the user has two choices to restart.
<beach>
I meant for the messages and errors you see.
<beach>
Not for your application.
<beach>
That's what I mean by simplifying the test case.
<beach>
So, this example again shows that support for debugging is not great, at least in the free Common Lisp implementations.
<kakuhen>
beach: Unfortunately, the style warnings do not appear without the RESTART-CASE macro.
CrashTestDummy3 has joined #commonlisp
<kakuhen>
So perhaps there is something about that macro that causes this. Interestingly enough, ECL does not complain at all. It's just CCL that complains, and SBCL complains even louder by giving twice as many style warnings as CCL.
igemnace has quit [Ping timeout: 245 seconds]
<pjb>
beach: note: this rule about where to signal or re-signal errors from, should be different when you are debugging the implementation. often I have code that will use either handler-case or handler-bind (notably in tests) depending on what you want to debug (eg. the tested code, or the tests).
<beach>
Yes, I am talking only about the application programmer here.
CrashTestDummy2 has quit [Ping timeout: 276 seconds]
<pjb>
I understand. But when you implement the rule, you need to make it optional because the code and conditions are also used by implementers.
<beach>
I see what you are saying.
<beach>
Also, I would like to see the backtrace not mention the particular operator that was invoked, because the operator that failed could be the result of a macro expansion, and that would be (is?) confusing to the application programmer.
<kakuhen>
pjb: hmm... on my side I am getting warnings, though, even when I run the REPL in a terminal rather than SLY
<beach>
Instead, the tentative plan is to show the source form (as highlighted text in the source code) that caused the problem.
igemnace has joined #commonlisp
<pjb>
kakuhen: I use (proclaim '(optimize (safety 3) (debug 3) (space 0) (speed 0) (compilation-speed 3)))
<kakuhen>
The style warning goes away when I use those options
<kakuhen>
I'm starting to think backquoting restart-case is just giving me more trouble than what it's worth
igemnace has quit [Read error: Connection reset by peer]
<pjb>
kakuhen: https://termbin.com/xr0o2 ; probably the warning occurs when the implementations tries to perform compilation-time optimization that would require the class to be defined, which it cannot do without evaluating the defclass that is in the progn. It cannot do that because it's in a single progn form; but should be able to do, because it's a toplevel progn form, so it could be spliced out.
<pjb>
kakuhen: in conclusion, I think the warning is a bug in those compilers.
<hayley>
Is there much I can do to make it more likely that I can handle a STORAGE-CONDITION (for running out of memory) rather than crashing the Lisp implementation?
<pjb>
hayley: depends on the implementations, and on your application…
<kakuhen>
pjb: one of my friends speculated this, since sbcl and ccl apparently share some common history with their compilers, and both have very similar behavior when running this macro, yet ECL didn't
<hayley>
For example, (handler-case (loop collect 2) (storage-condition () 'no)) crashes into LDB rather than signalling on SBCL.
<pjb>
hayley: one trick could be to allocate some vector, and when you get this storage-condition, to release the last reference to that vector to free some space.
<hayley>
pjb: Yes, hence the probabilistic phrasing of my question.
<pjb>
hayley: that should require a minimum of space to perform, but the question is whether it will be enough to continue.
<pjb>
hayley: somebody did an evaluation of the handling of storage-condition in various implementation when usenet cll was still a thing, but nothing moved since.
<hayley>
If I cons up larger objects then I seem to have a better chance on SBCL.
<pjb>
hayley: somebody would have to provide patches to the implementations. So far it has been easier to just buy more RAM.
<hayley>
pjb: My current "threat model" is that we are overwhelmed with messages on a server, and so we run out of memory allocating objects for them all. To handle it, we would probably kill threads which try to run out of memory.
<pjb>
One problem is that the storage-condition handler may require some memory to work. If the heap is already overextended, it may be difficult. So the implementation should reserve some space for the handlers in this situation.
<hayley>
Given that such message objects would be large, maybe with large strings or byte vectors, it seems I would have a good chance on SBCL.
kevingal has joined #commonlisp
<hayley>
It appears SBCL reuses one SB-KERNEL::HEAP-EXHAUSTED-ERROR object.
amb007 has quit [Ping timeout: 276 seconds]
<flip214>
hayley: well, you could mmap() your message files and have your OS swap them in/out as needed?
<flip214>
might not be as easy to handle as strings or ub8 vectors... don't know what you need, though.
amb007 has joined #commonlisp
<hayley>
I meant messages coming over a network, which would probably tend to be small.
<hayley>
I already have a message size limit, but one could just send more messages at that size limit on multiple connections (and thus threads; I guess every other multiplexing model looks a bit nicer with this problem) and blow the heap that way.
<flip214>
well, just use the TCP buffers then - only operate on a limited number of messages
<flip214>
the others are kept in local and remote TCP buffers
<flip214>
so if you know how much heap you need per message, and the size of your heap, you can restrict the number of parallel threads and be done
<flip214>
Hunchentoot-QUUX for HTTP gives you a thread pool, for example
<hayley>
Right. I don't think I know how much heap I need per message, and it would hurt my head too much to use only TCP buffers.
<moon-child>
I would change the variable there and say, rather, you know how much heap you need per message, and the number of cores your machine has; so you know the size your heap needs to be
<moon-child>
hayley: you may not know exactly, but it should not be overly difficult to come up with a conservative estimate, no?
igemnace has joined #commonlisp
<hayley>
I don't know what my server will be used for, and so I could only say something between 10² and 10⁷ bytes per message?
amb007 has quit [Ping timeout: 258 seconds]
amb007 has joined #commonlisp
<hayley>
So, taking the maximum limits the throughput substantially if that is not the case, but a more conservative estimate would be too conservative. Hence why I would like a more...I suppose "feedback"-driven approach?
<moon-child>
I don't think this kind of probabilistic approaches to security is the right one. Is it better that you have (say) an 80% chance of signalling a condition than a 5% chance? Marginally. But if the implementation is unwilling to _reliably_ signal such a condition, I think it is better to accept that as a constraint and look for an alternative solution (or, patch the implementation, as pjb
<moon-child>
suggests)
<hayley>
I would consider it to be a performance hack, as there is no security (or progress, for that matter) lost if the server crashes outright, but I would prefer to only kill one connection rather than all of them.
<moon-child>
for instance, separate your server into multiple processes and use the operating system to coordinate them
<flip214>
hayley: run (TIME (process-one-message)) - the output will tell you how much heap was allocated. round up, and estimate.
<flip214>
also, you can have a background thread monitoring heap usage - but then you'll need to find out which thread to kill...
<flip214>
depending on your usecase (needs IO, or not) it might be easier to just limit number of thread == number of cores. then every thread can process a message without any wait time => minimum latency, minimum heap usage.
<flip214>
works for me with PDF generation - there's no IO involved, just CPU, so there's no reason to have more threads than can run at the same time.
<moon-child>
I think a server must of necessity do a lot of i/o. But I think the usual approach there is to just have one i/o thread which receives connections and pushes them onto a work queue; and to do writing asynchronously
<hayley>
I can't seem to understand anything that isn't "straight line" networking code with threads, such as using some callback async library or polling or whatnot. Then writing it is daunting.
amb007 has quit [Ping timeout: 245 seconds]
amb007 has joined #commonlisp
<flip214>
hayley: SB-EXT:CALL-WITH-TIMING can give you a :BYTES-CONSED result, so your threads can (over time) estimate their memory use themselves ;)
<flip214>
moon-child: I meant disk-IO that would block worker threads. as soon as an HTTP request has arrived, all the work until pushing the result might be possible without any IO.
<moon-child>
ah, yes. Usual approach for this is coroutines, but I don't think we have any cl implementations that support them
<flip214>
moon-child: HT-QUUX uses an acceptor thread and a pool of worker threads.
<moon-child>
(of course, come closos, plain threads will be cheap enough it won't matter. But who knows then that will be)
<hayley>
Another difference is that I have connections which are expected to be persistent, whereas I can't remember if Hunchentoot supports keep-alive.
derelict_ has quit [Ping timeout: 252 seconds]
<flip214>
hayley: you can tell HT to ignore a TCP socket - and pass that on to an extra thread.
<hayley>
moon-child: FWIW my secret plan is to prototype "green threads" in a fork of SICL, which would then be somewhat reusable for a thread implementation in CLOSOS.
<flip214>
hayley: green threads - with all the features of OS threads? like scheduling priorities, blocking behaviour for OS calls, timeouts, ...??
<flip214>
I've worked on such a library in C - but it never got up to par on features with kernel threads.
<hayley>
Well, Erlang has priorities, and in the case of CLOSOS, blocking OS calls could be handled with the usual devices (mostly semaphores I suppose).
<hayley>
On a Unix system, I think the Erlang and Haskell people both either attempt to use asynchronous operations or a thread pool for synchronous operations, which still use something like mailboxes to unblock the appropriate thread and provide the result.
<flip214>
IMO that's too much complexity for too few advantages. Just use pthreads.
tfeb has joined #commonlisp
<hayley>
Apparently the fastest servers these days use other async stuff, which is backed by some polling technique (epoll, etc, maybe io_uring if you're fancy). Without some intermediate stuff they don't work too well with threads apparently.
<flip214>
yeah. But if your actual workload (PDFs, for me) take 30-60msec to generate, and I only have a handful of cores (and a handful of threads), the server implementation doesn't actually matter.
<hayley>
Right, that probably isn't my workload though.
<flip214>
of course, the "hello world ~a" examples need to keep the server as small as possible for their benchmarks...
<flip214>
io_uring might make sense for tpd2 or similar
random-nick has joined #commonlisp
yitzi has joined #commonlisp
<kakuhen>
pjb: thanks for helping me btw. you too, beach. I'm going to sleep now.
kakuhen has quit [Quit: Leaving...]
attila_lendvai has quit [Read error: Connection reset by peer]
superfly` has joined #commonlisp
<superfly`>
Hi
attila_lendvai has joined #commonlisp
<superfly`>
How are you guys going? Just discovered IRC
<hayley>
Welcome to IRC!
<superfly`>
thanks hayley!
tfeb has quit [Quit: died]
<superfly`>
I have been doing common lisp lately, its fun
silasfox has joined #commonlisp
tyson2 has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
ahc has joined #commonlisp
akanouras has quit [Quit: You have been idle for 30+ days]
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
CrashTestDummy2 has joined #commonlisp
cage has joined #commonlisp
CrashTestDummy3 has quit [Ping timeout: 240 seconds]
scymtym has quit [Ping timeout: 256 seconds]
silasfox has quit [Ping timeout: 240 seconds]
silasfox has joined #commonlisp
selwyn has joined #commonlisp
selwyn has quit [Remote host closed the connection]
selwyn has joined #commonlisp
superfly` has left #commonlisp [ERC (IRC client for Emacs 26.3)]
amb007 has quit [Ping timeout: 245 seconds]
amb007 has joined #commonlisp
rain3 has joined #commonlisp
amb007 has quit [Ping timeout: 276 seconds]
amb007 has joined #commonlisp
Qwnavery has joined #commonlisp
<shka>
my buddy superfly is here
<beach>
was.
Qwnavery has quit [Ping timeout: 268 seconds]
Krystof has quit [Ping timeout: 250 seconds]
<yitzi>
beach: Thanks for the paper reference regarding CL and SICL debugging. Very informative.
<beach>
Sure. Glad you liked it.
<yitzi>
I noticed that there wasn't a section on CMUCL. From what the user manual and repo says they support stepping and breakpoints, although the stepper was broken until recently.
<beach>
Hmm, I thought I had one. That's an omission.
<yitzi>
Not sure how well maintained it is though. I can't currently test it in my environment since CMUCL can't load ironclad on my system.
<beach>
Yes, I see.
<jackdaniel>
flip214: kernel threads become troublesome when there are a lot of them (the context switch of a kernel thread is more expensive)
<jackdaniel>
also green threads (when pooled in a single native thread) have assured a certain amount of atomicity
<yitzi>
beach: No offense taken if you aren't.
<jackdaniel>
a side-benefit is that if you bother to implement green threads you will probably have delimited continuations for free
<jackdaniel>
(and with that come numerous interesting programming techniques - i.e generators)
<flip214>
jackdaniel: the continuations are a _requirement_, I guess
<flip214>
with all their own .... challenges ;)
<jackdaniel>
delimited continuations*
<jackdaniel>
full blown continuations require much more work
<flip214>
and with _lots_ of kernel threads you run in all the (already-solved, on the kernel-side) scheduling things - O(1), priorities, fairness, ...
<beach>
yitzi: Not sure what I am looking at, or what to expect.
<beach>
Oh, I got some kind of launcher now.
<jackdaniel>
flip214: yes, and these features have a cost, ditto what I've said earlier
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
<yitzi>
beach: It is slow b.c. it is a free server. Try the "debug.ipynb" in the left pane.
<hayley>
jackdaniel: I thought of green threads in the terms of undelimited one shot continuations.
Bike has joined #commonlisp
<beach>
yitzi: Yes, I can use it. Nifty!
<yitzi>
beach: In addition to debugging, stepping, source and variable inspection there is also symbol completion and help/inspect. Along with a widgets and pile of other stuff.
<beach>
Wow, very ambitious.
<yitzi>
The debugging is still a work in progress. The other stuff is pretty well tested and used by drmeister's group. There is also a maxima-jupyter kernel available based on the same code.
Krystof has joined #commonlisp
<beach>
You have been hard at work.
<jackdaniel>
hayley: what is an "undelimited one shot" continuation?
<jackdaniel>
delimited continuation is the continuation that can't go backwards
<yitzi>
beach: Yep. I've already started tweaking some of the debug messaging based on some your ideas. Thanks again!
<jackdaniel>
i.e you can't rewind it to three instructions before
<hayley>
jackdaniel: Just a snapshot of all machine registers.
<jackdaniel>
I don't understand
<hayley>
I read a delimited continuation was a continuation which was "delimited" to some frame with shift/reset.
<jackdaniel>
in non-scheme terms, a delimited continuation is a computing context that may be resumed, and after resuming it may yield control again (and be resumed again)
<Bike>
"one shot" means you can only use it once, like because the stack isn't copied so it will no longer be in place if you try to continue there later. so register saving works.
<jackdaniel>
I see ,thanks
<hayley>
I /guess/ we are delimited by THREAD-YIELD (and preemptive scheduling) but it doesn't fit how they are presented in Scheme land in my opinion.
<Bike>
i don't think threads are really "delimited continuations". the way the continuations given by shift work, they add to the current call stack, so they return like normal functions (to muddle several levels of description)
<jackdaniel>
so if the stack is not copied and you allow yielding, then how does it work? all threads share the same stack?
<Bike>
i t hink they have different stacks?
silasfox has quit [Ping timeout: 252 seconds]
<jackdaniel>
OK, makes sense
<hayley>
Each thread has a separate stack, and yielding saves state, returns to some scheduler, then loads the new state.
<jackdaniel>
I didn't say that delimited continuations are threads, I'm saying that cooperative threads may be implemented with delimited continuations
silasfox has joined #commonlisp
<hayley>
But my observation was the only green thread implementation with continuations uses undelimited continuations once, as I couldn't spot the delimiting.
<Bike>
is the high limit, like, the scheduler?
<hayley>
Somehow delimited continuations are harder for me to understand than undelimited even though the former is supposedly much better to use.
recordgroovy has joined #commonlisp
<Bike>
no, i think delimited continuations are definitely harder to understand
<hayley>
The former does some stack knotting, whereas the latter is a funny first class GOTO.
<Bike>
they have some interesting advantages over undelimited, but simplicity is not one of them
<jackdaniel>
I will read on that later, but some loose searching seems to indicate, that one-shot continuations are a certain class of delimited continuations
<jackdaniel>
s/class/subclass/
<Bike>
you can definitely have one shot undelimited continuations
<Bike>
cl:block sort of does that, though with only dynamic extent
pranavats has left #commonlisp [Disconnected: Received SIGTERM]
<Bike>
and most hagiographies of delimited continuations emphasize their composability which kind of goes with reusability
<jackdaniel>
continuations that can be called multiple times are full continuations, one-shot may be resumed only once and delimited capture the entire /remaining/ continuation; that's what I've grasped from this quick search
<Bike>
i think that depends on what you mean by "remaining"
<jackdaniel>
but as stated, I will read on that later
<jackdaniel>
thanks for pointers
<hayley>
I think get/setcontext in POSIX-2001 manipulate one shot undelimited continuations, as they are just all the registers as described previously.
<Bike>
i would say they area, yeah.
<Bike>
they are*
<hayley>
Bike: "hagiographies" I like your words, magic man.
<hayley>
Before I was going to say setjmp/longjmp but those are mere escape continuations as I understand how you are supposed to use them.
amb007 has quit [Ping timeout: 240 seconds]
* hayley
has only used setjmp to get GC roots to this day.
amb007 has joined #commonlisp
pranavats has joined #commonlisp
<Bike>
yeah longjmp has the "UB if the function that used setjmp has returned" bit, so they're only an escape
amb007 has quit [Ping timeout: 276 seconds]
amb007 has joined #commonlisp
ldb has joined #commonlisp
<ldb>
hello
silasfox has quit [Ping timeout: 276 seconds]
silasfox has joined #commonlisp
pranavats has left #commonlisp [Disconnected: Received SIGTERM]
pranavats has joined #commonlisp
<pjb>
Bike: like block/return-from indeed.
<rain3>
a 2 hours long video from Atlanta Functional Programming - Common Lisp Study Group youtube channel can be condensed in 1-5 pages of good old text tutorial which in turn can be studied in 10-30 minutes instead of 2-6 hours of listening and watching and pausing and scrolling
<jackdaniel>
writing tutorials is a solitary activity while study group is a social activity
waleee has joined #commonlisp
<jackdaniel>
so while the former purpose is teaching, the latter purpose is socializing (in my understanding)
silasfox has quit [Ping timeout: 252 seconds]
<rain3>
socializing around good content which can be summarized as a high quality tutorial , either before or after the meeting
<jackdaniel>
since you've watched it you may write a high quality tutorial then ;)
<rain3>
that's the problem, I haven't watched it because it's too arduous and inefficient
<rain3>
I'd rather read the sourcecode
<rain3>
and the papers
<jackdaniel>
ah, that's a shame; perhaps you could write a high-quality tutorial or a paper on another topic related to lisp; I'd gladly read it
<ldb>
there is nothing mandatory for reading
<ldb>
could there be alternative source
<lotuseater>
I skipped through it, is ":filter :something" a method-combination? wasn't aware they can be done that way, but I think because I didn't define ones myself yet
<ldb>
lotuseater: that's probably optional argument lists, I don't think you need method-combination for that
<lotuseater>
hmm :)
<Bike>
what's the context?
<rain3>
jackdaniel: on the other hand your CLIM videos are from beginning to end golden and enjoyable, good and efficient for teaching others
<lotuseater>
they have something like (defmethod stack-push :filter :number ((stack (eql 'normal))) ...)
<jackdaniel>
thanks
<jackdaniel>
they are not followed with tutorials neither though
<rain3>
yes but they are done differently
<rain3>
they are video tutorials in themselves
<ldb>
lotuseater: ok that's indeed method combination type
taiju has quit [Remote host closed the connection]
taiju has joined #commonlisp
<jackdaniel>
that's nice to hear; either way preparing a tutorial after giving a talk is an extra work - if someone does that it is fine; but expecting it from that person is a bit much
<rain3>
I am not asking for it.. I am only pointing out that the same thing can be done more efficiently . If you have the tutorial prepared before, then you don't need to waste time thinking and fighting with bugs 'sorry, it didn't work, we'll try again in the next video'
<rain3>
in a video about the Cells library it happened
<Bike>
those are qualifiers for a custom method combination
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
ahc has quit [Ping timeout: 246 seconds]
eta has quit [Quit: changing]
eta has joined #commonlisp
waleee has quit [Ping timeout: 276 seconds]
ldb has quit [Remote host closed the connection]
ldb has joined #commonlisp
mister_m has joined #commonlisp
<pjb>
rain3: totally agree, videos are two slow in general. However it is not necessarily a bad thing: 1- you can listen to them in parallel to some other task. 2- sometimes you're not working at 100% of your capacities yourself, so it's not so bad they're a little slow. 3- it can give you an excuse for such a slow day.
<pjb>
(and you can always play them at 2x, even if one may sometimes regret there's not an option to play them at 10x).
<pjb>
Perhaps somebody at google will implement an AI to summarize a video, and transform it into a multimedia stream that could be absorbed by brains in high speed. Or perhaps we'll have to wait for neuralink to provide the brain downloading feature…
<rain3>
the video above actually was quite good in comparison with others. I've downloaded them so that I can play at 10x with vlc player , then I deleted all of those which only had examples from the readme of the lib
treflip has quit [Remote host closed the connection]
tfeb has joined #commonlisp
Josh_2 has joined #commonlisp
Th30n has quit [Quit: WeeChat 3.2]
ldb has quit [Ping timeout: 258 seconds]
tfeb has quit [Quit: died]
zacts has joined #commonlisp
zos has joined #commonlisp
ldb has joined #commonlisp
hafat has joined #commonlisp
ldb has quit [Ping timeout: 245 seconds]
ldb has joined #commonlisp
hendursaga has joined #commonlisp
ldb has quit [Ping timeout: 265 seconds]
hafat has quit [Quit: Leaving]
Lycurgus has joined #commonlisp
Inline has joined #commonlisp
<zos>
Hello all, I am interested in learning common lisp. I have started working my way through Practical Common Lisp. Right now I am using SBCL with Doom Emacs. In some tutorials I have come across mentions of roswell and am wondering if it is worth setting up from the start.
ldb has joined #commonlisp
<rain3>
it's good to set it up so that you can easily switch between different versions of SBCL when needed
<beach>
zos: Welcome to #commonlisp
<zos>
thanks you!
<beach>
zos: I have been using SBCL for decades and never saw the use for Roswell.
<rain3>
and I am not a roswell guy, I have been avoiding it
<beach>
zos: If I were you, I would wait until it is needed.
<Lycurgus>
anybody can speak from current state?
<rain3>
beach's advice is the best
<Lycurgus>
i believe in n chances, especially if somebody else does the m+1 of them, in my case m is like 2 -4
srhm has joined #commonlisp
zacts has quit [Quit: zacts]
<Lycurgus>
in FOSS ofc, not in the corporate
derelict_ has joined #commonlisp
<beach>
Lycurgus: What is the context?
<Lycurgus>
assesment of roswell
ldb has quit [Ping timeout: 272 seconds]
<Lycurgus>
*assessment
<zos>
That sounds like good advice - it is going to take some time before I am likely to need to worry about deployment. Thank you for your help
<beach>
zos: #commonlisp is not really for newbie questions, in case you want to ask such questions at some point. They are tolerated though, and if they become too trivial or too numerous, you might be asked to go to #clschool.
<beach>
Then, you might not need any of that at all of course. Just saying.
<zos>
Ok, I will keep that in mind. Thank you again
<beach>
Pleasure. Good luck!
ldb has joined #commonlisp
ldb has quit [Ping timeout: 252 seconds]
ldb has joined #commonlisp
selwyn has quit [Read error: Connection reset by peer]
<phantomics>
And then I check the value of foo, it's still 123
jealousmonk has joined #commonlisp
<phantomics>
Why doesn't the set-foo function defined in the (let) affect the top-level binding of foo? The function is defined before the value inside the (let) form is locally bound to foo
lad has quit [Ping timeout: 268 seconds]
<beach>
You can't close over special variables.
<phantomics>
Ok, so this method would work if foo was a lexical variable defined in a (let) form containing the code rather than a special variable?
<jcowan>
And CL, alas, lacks lexically scoped global variables.
Vultyre_ has joined #commonlisp
<jackdaniel>
daily quiz: what's a practical value of (apply foo (car bar) (cdr bar)) compared to (apply foo bar) ;?
<beach>
phantomics: It depends on your definition of "work", but yes, you can close over lexical variables.
<phantomics>
Makes sense, thanks
<jackdaniel>
jcowan: how about (let ((foo 42)) (declare (special foo)))
<beach>
jackdaniel: Do you have an answer to the quiz, or are you out of ideas?
<jackdaniel>
beach: I do
<jackdaniel>
I wouldn't say "quiz" otherwise
<beach>
And BAR is just a variable, yes?
<jackdaniel>
sure
sgithens has joined #commonlisp
<jcowan>
Sure, but my claim was that there are no global lexical variables, as you cannot wrap a let around your program (becaause too many things in it insist on being top-level)
<jackdaniel>
there are file-local-variables (in the standard it is i.e *readtable*, but there is also asdf extension that gives you that)
<beach>
jackdaniel: I can imagine if foo is something like #'apply, and (car bar) is something like #'reduce, but I am not sure.
<jackdaniel>
of course one could argue that the practical application I have in mind can't be considered a good style of programming
<jackdaniel>
but the first assures, that at least one argument is passed to the function
<jackdaniel>
consider a generic function (defgeneric foo (a &rest args))
<beach>
Fair enough.
<jackdaniel>
when bar is NIL, then the arity does not match
<jackdaniel>
however you could specialize the first argument on null as a fallback, and then bar could be nil
<beach>
*sigh* sure.
<jcowan>
*double sigh* for NIL punning in Lisp
lad has joined #commonlisp
<hendursaga>
Is Consfigurator and Adams the only configuration management software using CL?
<j-sh>
What is the current best way to use the GNUstep GUI toolkit (and maybe its RAD tool Gorm) with common lisp?
<pjb>
phantomics: yes, it would work with lexical variables, but the question is why did you make a temporary binding of foo in your let?
<pjb>
phantomics: it's not wrong, that's the point of dynamic variables: they let you shadow temporarily the previous binding, during the execution of a let body. But the point is that if you want to have the previous binding mutated, you should not temporarily shadow it!!!
<pjb>
phantomics: without (*foo* *foo*), it works as you wanted, doesn't it?
<pjb>
phantomics: note that defvar declares the variable name as special; this is a global declaration that cannot be removed or shadowed. So it is important to use the earmuff convention foo -> *foo* to avoid damaging the normal variable names.
dickbar__ has joined #commonlisp
<pjb>
Always use *foo* for special variables to avoid hours or days of debugging!
<beach>
j-sh: In the logs for a year back, this is the first time GNUstep is mentioned.
<pjb>
j-sh: the question is difficult.
<pjb>
j-sh: the first problem is that there are different Objective-C runtimes: Apple's runtime, GNU runtime, cocotron runtime (used on MS-Windows I believe).
<pjb>
j-sh: the next problem is the FFI from lisp to Objective-C; there are some nice things: the objc runtime is a pure C API. There are some more difficult things: depending on the runtime and the libraries or frameworks, it's not always easy to introspect the API; we still have to process the headers, and this is not easy (failproof) to do it automatically.
<pjb>
j-sh: ccl provides a FFI that works with Apple's runtime. I don't know how well it could work with GNU Objective-C runtime. There's an Objectiev-C FFI that could work with GNU Objective-C (and possibly cocotron, IIRC), but AFAIK it has bitrotten.
Lycurgus has quit [Quit: Exeunt]
<pjb>
even ccl uses a ffigen that is a patch of Apple gcc version 4 that is entirely outdated and therefore is completely bit-rotten; I don't know how to generate the cdb files ccl FFI requires to deal nicely with frameworks on current systems.
<pjb>
j-sh: so to use CL with GNU objective-c runtime, even less batteries are included.
<pjb>
In short, it's a mess, and we'd need to re-implement from scratch an CL -> Objective-C FFI that would work nicely for all runtimes, and all frameworks. But it's not a small project.
<phantomics>
pjb: I know I'm using weird conventions in this code, that's because it's for the output of my APL compiler, and APL has some odd conventions for implicitly shadowing variables but also has ways of modifying variables at the top level of their scope
<pjb>
j-sh: well, http://git.informatimago.com/viewgit/index.php?a=tree&p=public/games/hangman-cocoa-objc&h=6a4c99a8d52e6cdaf08b28dffa67797dab8f9a89&hb=99a80c170985b9b3a753025c00870c63a94cf678 ; I don't know if I left the gnustep version on github.
<pjb>
(nope. the gnustep/ subdir only contains objective-c code… ; as I said, the problem is difficult and has not been worked on ever)
<pjb>
j-sh: basically, CL is a not used by a lot of programmers. GNUstep is not used by a lot of programmers. CL with GNUstep is used by a handful of programmers and we don't have the resources to make any progress on the combination.
<pjb>
j-sh: as beach said, it has been a long time since we talked about GNUstep in #commonlisp
<lotuseater>
but now i learned about GNUstep
mister_m has quit [Ping timeout: 240 seconds]
amb007 has quit [Read error: Connection reset by peer]
rain3 has quit [Remote host closed the connection]
rain3_ has joined #commonlisp
amb007 has joined #commonlisp
rain3_ is now known as rain3
<pjb>
lotuseater: j-sh: so a first step would be to define a complete FFI to the gnu objective-c runtime, to the apple objectiev-c runtime, and possibly others (cocotron, etc).
ec has joined #commonlisp
<pjb>
lotuseater: j-sh: next, define a higher level CL to objective-C interface using introspection and working with all runtimes.
<pjb>
lotuseater: j-sh: finally, use my reader macros to be able to use the nice Objective-CL syntax ;-)
<pjb>
two problems: 1- dealing with C macros in the objc runtime headers. 2- dealing with the various structure layout (packed/not packed, 32-bit/64-bit, and other #ifdef).
<pjb>
this cannot be dealt with with introspection.
<pjb>
(perhaps introspecting the debugging symbols in the shared libraries of the run-time, but this adds a new complexity (gdb symbols, dwarf symbols? what to do if stripped without debugging symbols? etc).
<pjb>
And you can also add to the difficulty by wanting to support iOS…
nij- has joined #commonlisp
<j-sh>
pjb Thank you for your extensive answer, I didn't know that it would be that difficult to use CL with GNUstep.
<j-sh>
But I will probably try to solve the issues once I have some time off in the future.
<j-sh>
I personally think that it is a shame that GNUstep didn't get the recognition that something like GTK (it is even older than GTK AFAIK) got, but I guess there aren't many people that want to touch an Objective-c codebase especially since it has the "Apple stigma" to it and even Apple themselves try as hard as possible to deprecate Objective-C
<j-sh>
and replace it with Swift.
<pjb>
j-sh: well, it's not that it's difficult. It's labor intensive to do something complete.
<pjb>
j-sh: if you just want to send a few message, you really need to FFI a few functions in the runtime. You can easily do that.
jeosol has joined #commonlisp
<pjb>
j-sh: if there were bindings for other languages to GNUstep, that could indeed make it more popular.
<j-sh>
pjb There are apparently bindings for Java, ruby and Smalltalk, but I'm not sure how much they are maintained.
zos has quit [Quit: Leaving]
gaqwas has joined #commonlisp
<pjb>
For example, one problem is that the code used to encode the types are defined with #define in the runtime.h header. So CL needs either to parse those headers, or to hardwire the encoding for each compiler/runtime.
<pjb>
j-sh: For example, you can cffi:defcfun objc_msgSend and sel_getUid, and then already you can send messages to objects.
<pjb>
but in CL you'd want to be able to introspect the classes and objects. So you'd want the full monty.
<pjb>
you'd want to do the same in CL for Objective-C classes. (even more, since in Objective-C the methods are attached to the classes, so you'd also want to list the methods).
<pjb>
and categories, properties, protocols, etc…
Fare has joined #commonlisp
<lotuseater>
a C# software developer he could also extend his language or that it couldn't be different in CL ^^ hard to make him clear why not
<lotuseater>
*meant
hafat has quit [Quit: Leaving]
tfeb has joined #commonlisp
akoana has joined #commonlisp
<lotuseater>
he also called CL a niche lang, but I shouldn't care
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
waleee has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
nij- has quit [Quit: Using Circe, the loveliest of all IRC clients]
zos has joined #commonlisp
jmhimara has joined #commonlisp
lisp123__ has joined #commonlisp
Guest39 has quit [Quit: Client closed]
jmhimara has quit [Quit: Client closed]
meraz_1 has joined #commonlisp
selwyn has joined #commonlisp
<jcowan>
Anyone who asks you "But why would you want to do *that*?" when talking about cross-language comparison should be resolutely ignored: nobody "wants" a feature they've never heard of, because they've learned to work around it or not to want it or are simply clueless. (However, the question does make sense within a single language, because there may well be a different way to achieve the same effect within the language.)
<lotuseater>
yes
<lotuseater>
I also tell that's an experience no one can just tell you, you must make it yourself to really get the difference.
peterhil has quit [Ping timeout: 268 seconds]
<lotuseater>
and then came "but anyone can hack on the compiler so you also have to"
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
<lotuseater>
haha and just because something is used by more people or there are many (aweful) book about it means it's better (just better marketed)
peterhil has joined #commonlisp
<jcowan>
This is a highly speculative question: can anyone see a use case for a separate class hierarchy allowing you to create generic functions that aren't related to ordinary generic functions?
<lotuseater>
ondeed it is
<jcowan>
Namely?
<tfeb>
lotuseater: 'popular does not mean good: it merely means good at being popular', as someone once said.
<lotuseater>
hm?
<lotuseater>
haha yes tfeb
<lotuseater>
it reminds me of a sentence of Knuth
rain3 has quit [Ping timeout: 240 seconds]
<aeth>
jcowan: already exists, sort of
<jcowan>
???
<aeth>
not via a separate class hierarchy, though, via types.
<aeth>
types allow you to dispatch on numbers/sequences/arrays that don't necessarily have distinct classes
<aeth>
since you could e.g. (simple-array octet (* *)) as a type for 2D (unsigned-byte 8) arrays (assuming octet is defined as such)
<aeth>
jcowan: I wouldn't be surprised if there are other distinct generic function systems, too, perhaps more close to what you're looking for
<jcowan>
Clojure allows uou to create independent class hierarchies, but I can find no explanation of why you'd want to.
<aeth>
maybe for ORM?
<aeth>
so relations-as-pseudoclasses?
<aeth>
or for a DSL where you don't want to represent the DSL's classes as native classes
<jcowan>
Okay, that last makes sense to me
<aeth>
and perhaps you can't do that, if it's a well-specified language in a way that's incompatible with the host language
<aeth>
but that way at least you can use built-in generics even though you can't use the built-in class hierarchy
<jcowan>
How's that possible?
tfeb has quit [Quit: died]
<pjb>
jcowan: independent class hierarchies are usually an illusion, there's normally a TOP class (eg. T in CLOS).
dsk has quit [Ping timeout: 252 seconds]
derelict_ has quit [Quit: WeeChat 3.2]
<pjb>
jcowan: that said, in CLOS, playing with metaclasses, you can probably implement separate subhierarchies according to your wishes.
<jcowan>
But not in C++
<pjb>
Well, C++ is not OO.
<pjb>
but yes.
srhm has quit [Quit: Konversation terminated!]
srhm has joined #commonlisp
asarch has joined #commonlisp
sander has quit [Ping timeout: 265 seconds]
sander has joined #commonlisp
d4ryus has quit [Ping timeout: 256 seconds]
hhdave has quit [Ping timeout: 250 seconds]
silasfox has quit [Ping timeout: 250 seconds]
pranavats has quit [Ping timeout: 252 seconds]
dsk has joined #commonlisp
silasfox has joined #commonlisp
asarch has quit [Quit: Leaving]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
pve has quit [Ping timeout: 240 seconds]
lad has quit [Ping timeout: 245 seconds]
kakuhen has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
<lotuseater>
pjb: :D
<lotuseater>
tell that Bjarne Stroustrup
derelict has joined #commonlisp
meraz_1 has quit [Quit: meraz_1]
gaqwas has quit [Ping timeout: 240 seconds]
shka has quit [Ping timeout: 245 seconds]
<phantomics>
Hey, another question. When a local binding is created for a dynamic variable, functions defined even outside the scope of that local binding will use the local binding, correct?
<phantomics>
The (set-foo) inside the (let) form doesn't actually change the top-level value of foo, even though the function is defined outside
<_death>
right
<phantomics>
Ok. I have a workaround but it'll be a pain to set up
<pjb>
lotuseater: the only advice I have for Bjarne, unfortunately, is to ask to be interned in a lunatic asylum.
<pjb>
phantomics: wrong
<lotuseater>
lol
<pjb>
phantomics: you don't have _local_ bindings for _dynamic_ variables. It's like asking what taste is the color blue? it's meaningless.
<pjb>
phantomics: what you have is _TEMPORARY_ bindings for _dynamic_ variables.
<pjb>
dynamic = time ; lexical = space.
<phantomics>
I know that the dynamic vars have a value stack and a value gets pushed onto the stack within that (let) scope
<pjb>
phantomics: how do you know that? are you an implementer?
lad has joined #commonlisp
<phantomics>
That's what I read before
<pjb>
phantomics: the set-foo mutates the binding of the dynamic variable foo that is active WHEN the function set-foo is called.
<phantomics>
Makes sense
<pjb>
phantomics: in set-foo, there is absolutely no consideration for WHERE the variable foo is bound. Only WHEN it is bound.
<pjb>
since foo is a dynamic variable.
<pjb>
The only "work around" is to use lexical variables.
<pjb>
Note: you can define global lexical variables using symbol macros. Search for a defglobal or deflex in libraries.
<phantomics>
The workaround, as far as the April compiler is concerned, is to prefix the internal representations of all lexical variables with something
<phantomics>
So if someone enters foo←5 at the top level, a dynamic foo variable is created
<phantomics>
And then if they write a function like {foo←5 ⋄ foo+⍵}, a lexical variable called something like "𝕏foo" that shadows the value of the external "foo" is instantiated in a (let) form
<pjb>
So you're implementing lexical variables with dynamic variable when you have a language that already has lexical variable? Why? Are you masochist?
<phantomics>
APL
<phantomics>
APL's top-level variables are effectively dynamic
<lotuseater>
pjb: not him but Ken Iverson xD
<phantomics>
It creates implicit shadowed lexical variables when you assign a value to something inside a function
<pjb>
Ok, so you have toplevel variables that are dynamic and local variables that are lexical, and the local lexical variable can shadow the the toplevel dynamic variable?
<phantomics>
Correct
<pjb>
In that case, indeed, you need some kind of renaming or use a different namespace (package).
<phantomics>
That's what I'm planning to do, with that "𝕏" prefix
<pjb>
The local lexical variables can be renamed at will, since they're lexical.
<pjb>
Well, you can just use (gensym) to generate new names…
<phantomics>
The tricky part is that APL has a type of function that can reassign the global variable outside of a function's scope
<phantomics>
But given a lexical variable's name, I need to be able to find if it is shadowing a dynamic variable
<phantomics>
The prefix system allows that
<pjb>
No, you can rename all the lexical variables.
<pjb>
(mapcar (lambda (lexical-apl-variable) (cons lexical-apl-variable (gensym))) lexical-apl-variables) to build an a-list mapping the lexical-apl-variables to lexical-lisp-variables.
<phantomics>
If I rename them to gensyms how do I find their corresponding external dynamic var symbol? Enter it all in a hash table? The prefix system is simpler, and double-struck letters are illegal in April var name so there's no chance of collision
<pjb>
You find that before, by looking up the apl-variable in a global-dynamic-apl-variables list.
<phantomics>
That seems cumbersome when I could just remove the lexical var prefix and look for the existence of a dynamic var by that name
<phantomics>
Also the gensyms would make April's compiled code harder to read
<pjb>
Yes.
<pjb>
But for compiled code, it doesn't matter much…
<pjb>
For translated code, it would be more important.
<phantomics>
April is designed to produce relatively readable compiled code for the purpose of debugging
<pjb>
In that case, your idea is good.
j-sh has quit [Quit: Connection closed]
<phantomics>
And by compiled I may mean closer to what you mean by translated
<phantomics>
APL converted into Lisp designed for readability, I've built a lot of stuff including some reader macros just to make the output more readable
<pjb>
note: lexical variables are not accessible from "outside" the function, while global variables are accessible from anywhere.
<pjb>
therefore I would use a package such as "APL-VARIABLES" to intern the names of the global dynamic variables, and another package "APL-INTERNALS" to intern the name of the lexical variables.
<phantomics>
The concept of "global lexical variables" is interesting though, I may check into those tools you mentioned in case they're useful
<pjb>
You'd have APL-VARIABLES:FOO and APL-INTERNALS:FOO.
<pjb>
Well, you'd have APL-VARIABLES:FOO and APL-INTERNALS::FOO. You wouldn't have to export symbols from APL-INTERNALS.
<phantomics>
April already supports multiple workspaces, each of which is implemented as a package, so that means I would have to have two of those packages for each workspace
<pjb>
Possibly.
<pjb>
This is a consideration if you want to interact with lisp.
<pjb>
having APL code generate packages with exported symbols only for the "public" stuff and other packages for the internals would be clean.
<phantomics>
April is intended to be highly interactive with Lisp; each workspace is a package, all variables you create can be accessed from the Lisp instance.
<phantomics>
If all the lexical vars are interned in a "sub-package" that could be fairly clean, no one would need to do much with the lexical package
<jcowan>
pjb: You can only be internet in LUNATIC-ASYLUM if it's a known package
<jcowan>
s/internet/interned
<pjb>
lispers yes, but C++ designers can be interned in real-life asylums.
attila_lendvai has quit [Ping timeout: 256 seconds]
char has joined #commonlisp
kevingal has quit [Remote host closed the connection]
<char>
Hello everyone
<lotuseater>
hi char :)
zacts has joined #commonlisp
<char>
Is there any good forward+reverse proxy for common lisp? I couldn't find how to forward http tcp sockets with hunchentoot
Krystof has quit [Ping timeout: 268 seconds]
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
contrapunctus has quit [Ping timeout: 240 seconds]
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
zacts has quit [Ping timeout: 246 seconds]
recordgroovy has quit [Quit: leaving]
recordgroovy has joined #commonlisp
recordgroovy has quit [Client Quit]
recordgroovy has joined #commonlisp
recordgroovy has quit [Client Quit]
recordgroovy has joined #commonlisp
taiju has quit [Ping timeout: 276 seconds]
taiju has joined #commonlisp
pegaso has joined #commonlisp
dsk has quit [Ping timeout: 240 seconds]
tyson2 has joined #commonlisp
zacts has joined #commonlisp
zacts has quit [Client Quit]
selwyn has quit [Read error: Connection reset by peer]
lotuseater has left #commonlisp [ERC (IRC client for Emacs 27.2)]