freenode/#clasp - IRC Chatlog
Search
21:18:01
kpoeck
When calling FILL-POINTER the argument "#.ext::single-float-positive-infinity" is not an array with a fill pointer.
21:44:16
karlosz
a proper fix for all those warnings involves stack shuffling when implementing tose phi functions
21:45:05
karlosz
theres almost no literature on it and it's pretty nasty with respect to merge points and keeping track of stack indices
21:45:38
attila_lendvai
is this so? when cclasp.exe is linked by ld, then it gets linked together with all of the compiled C++ definitions that basically make up iclasp.exe, but some of those definitions are shadowed by the stuff that is compiled from lisp sources by cleavir and written into .o files that ld understands, right? and this happens because/according to the careful input file ordering given to ld?
21:46:11
Bike
attila_lendvai: i think the iclasp and lisp definitions have different names in the C sense.
21:49:52
attila_lendvai
so, then iclasp's '+ is replaced by cclasp's '+ by (setf (fdefinition ..)..) (as issued by the init code of some foo.o at exe startup?), and by cleavir picking the right definition when inlining, right? because as far as I understand all of iclasp gets linked not only to cclasp.exe, but even to cando.exe
21:51:14
attila_lendvai
IOW, all of iclasp is around in the cclasp.exe, but parts of it are shadowed in the CL universe?
21:53:46
Bike
inlining is kind of a separate matter, but yeah, there's a setf fdefinition side effect.
22:10:37
attila_lendvai
so, basically once iclasp (aka stage-1) has loaded aclasp (aka stage-2), and once aclasp compiled itself into artifacts that ld understands, then we could link an aclasp.exe that is potentially completely independent of the codebase of iclasp (i.e. it could even have a different memory layout). and the stage-2 C++ codebase would need to implement less stuff in C++ (because aclasp implements more stuff in lisp)
22:11:10
attila_lendvai
ACTION needs to much better understand how the lisp universe is bound to the c universe in clasp, and thus starts to look for docs
22:14:02
attila_lendvai
I don't necessarily mind when there are no docs, but when the same codebase is also full of random files (i.e. complexity, noise)... that doesn't help
22:15:50
attila_lendvai
can you think of a definition that has a relatively unique name that I could grep for to see how its C++ implementation is replaced by a lisp reimplementation?
22:17:12
attila_lendvai
Bike: a short bird's eye view would definitely help me here, but detailed docs cost programmer time that can be put to rather bringing the codebase closer to a readable documentation
22:19:27
karlosz
a lot of useless computation coud be saved while compiling by doing some math to figure out how to keep accessory information correct and not just recomputing it every time in a loop
22:23:15
karlosz
maybe a declarative macro interface declaring what information gets changed/needs to be recomputed for each individual pass and some manager that can figure out how to recompute things from that info
22:25:22
attila_lendvai
looks like I'll have to take a deep breath and look at the code itself... I'm not overly excited about the details of ld and C++ internals, but I learned programming in m68k asm, so I should have the means if I can muster the motivation...
22:26:24
attila_lendvai
but the clasp codebase could be improved plenty to be more welcoming to newcomers
22:30:41
Bike
attila_lendvai: i mean, it's pretty much that there's an iclasp executable, and when you run cclasp you have it load a bunch of fasls that do redefinitions
22:38:04
attila_lendvai
this is what I'm aiming to address with a more structured bootstrap: clasp-builder.lisp is full of weird tagbody-go code because iclasp is very limited, but it's the same code that is run to build cclasp, i.e. when full CL is available. this is an unnecessary waste of programmer brain cycles.
22:55:46
attila_lendvai
the wscript gives a list of files to compile/load-a/b/cclasp, that then arbitrarily filter out ranges of that list using the filenames at the expected start/end indexes. and I wonder why I don't understand what's going on...