freenode/#lisp - IRC Chatlog
Search
20:51:01
drmeister
jackdaniel: Is there a way to tell ECL to compile files to .c/.eclh/.data and NOT invoke the C compiler?
20:54:25
drmeister
Oh - so disassemble does the first pass of compilation but doesn't invoke the C compiler.
20:55:50
jackdaniel
in practice right now it works only with lambda, like (disassemble nil '(lambda () whatever))
21:01:40
jackdaniel
from other notes, regarding stack corruption in ECL, if anyone is interested in the cause here it comes: https://gitlab.com/embeddable-common-lisp/ecl/issues/513#note_188189573
21:03:04
drmeister
Bike is actually working on that right now - he would be better equipped to answer.
21:05:04
jackdaniel
hum, I thought we were talking on clasp channel, I've got confused for a second :)
21:06:14
drmeister
In bclasp I allocate temporary multiple-values on the stack and save and load to/from that.
21:08:46
jackdaniel
I'm not sure how that would help with mvp1? consing a result is not a problem (except that it conses of course ;)
3:23:22
dialectic
I have, in some of my lightweight archaeology, discovered something called an "array leader" which existed in Lisp Machine Lisp among other places, and which might have made it into Common Lisp but did not. Is this similar to, in C:
3:29:23
Bike
https://4.bp.blogspot.com/-e-EzMef4w_Q/WlENwVD397I/AAAAAAAABqs/lR2j30OaA2k-p8At759le-eR-p3EFjshwCLcBGAs/s1600/chinenual.png
3:29:45
Bike
http://www.bitsavers.org/pdf/mit/cadr/chinual_4thEd_Jul81.pdf page 110 here (122 in the pdf)
3:30:39
Bike
it does seem a bit like a flexible array member, but it can be accessed as a thing in itself, so it might not have been implemented as one
3:32:16
dialectic
Interesting. I wonder why it didn't make it into CL. That's useful if you're handed a contiguous "buffer with a header" from somewhere else.
3:33:27
Bike
e.g., it mentions the zeroth element of the leader is the fill pointer, and if you use an array with a leader but don't treat that spot as a fill pointer you'll have problems
4:09:02
White_Flame
dialectic: in my reading of the Ivory, the array leader is variable-sized. The Lisp implementation chooses to implement certain structures using arrays, and can store any amount of metadata in the leader. The CPU mechanisms are oblivious to what's there
4:10:27
White_Flame
on the Ivory, the object pointer to an array is to the normal array header, and the leader is before that in memory
4:43:32
White_Flame
yeah, it's definitely an implementation artifact for constructing other compound data types, not a feature of standard arrays
4:45:06
White_Flame
but since the GC was very low-level, the memory layout of extended custom objects needed to follow a regular model that the GC could always grok
4:46:15
White_Flame
nowadays, since GC is at the same software level as the rest of the software runtime, it can be much smarter
4:46:36
White_Flame
and object types can have much more customization than relying on low-level array metadata
6:00:20
no-defun-allowed
GCL isn't a conforming Common Lisp implementation, and it doesn't have a native code compiler that makes JVM weenies fear for their lives[citation needed].
6:01:11
no-defun-allowed
GCL, if it is supposed to be a Common Lisp implementation, has to be a Lisp-2. There should be zero difference in semantics when running portable CL programs on conforming implementations.
6:02:08
jackdaniel
dialectic: https://common-lisp.net/project/ecl/static/quarterly/img/vol4/all-hierarchy.png
6:02:36
no-defun-allowed
Kyoto implemented CLtL 1 (which is not ANSI CL), Austin-Kyoto was an improved fork, then GCL was derived from AK.
6:04:31
jackdaniel
probably I should paint some green blocks yellow and vice versa after 3y, but nvm that
6:06:14
jackdaniel
there is also some inaccuracy in the obsolete section, I remember being called for making the link Lisp-to-C towards Star Sapphire