freenode/#clasp - IRC Chatlog
Search
0:38:44
drmeister
On macOS they are actually "bundle" files - they are like dylib but are linked with an extra flag.
0:45:17
balrog
that said I haven't seen a ton done in this regard with DWARF, but now I'm sidetracking myself.
0:47:36
drmeister
You are familiar with the difference between a bundle file and a dylib file on macOS?
0:48:14
Bike
hey produce a file that is both a library and anexecutable, to the great confusion of reverse engineers and their totally legitimate IDA Pro licenses. <-- oh no
0:49:12
drmeister
My understanding is that a bundle file is something that you can dyload into an executable and a dylib is a library to link with object files.
0:51:40
balrog
this is stuff that became unimportant around 10.4 and completely irrelevant since what, 10.5 or so?
0:52:24
drmeister
I haven't made the leap to clean out my hacked boehm and build from brew installed boehm
1:02:03
karlosz
because the code generated under cleavir uses so much stack space that self compiling means that once halfd of the system is replaced it blows up from stack usage
1:02:50
Bike
that's way deep. what does a backtrace like? perhaps it's recursively calling something that does special bindings or the like?
1:03:44
karlosz
i'm not sure. i encapsulated pone of the compile functions and even clisps compiler stack overflowed when compiling cleavir
1:04:26
karlosz
encapsualte as in (defun compile (name def) (if *use-cleavir* .... (clisp-compile ...))
1:06:04
karlosz
and all temporary variables have to be allocated on the stack since its a stack machine, hence why im suspecting the stack usage of cleavir+ clisp to be a problem
1:08:37
karlosz
the special variable binding thing was a problem too, but i fixed that by adding a reader macro telling cleavir not to self compile those things
1:08:48
drmeister
karlosz: Is it a normal C stack - or so kind of shadow stack that clisp maintains?
1:10:42
drmeister
balrog: Yeah and I've been suffering from a bout of "programmers block" - I don't know what the problem is with me and this atom-tree code - I just feel like I'm climbing a sheer cliff face with it.
1:11:25
drmeister
So I've been nibbling around the problem, trying to make my job easier by writing graphviz code to visualize it and take it one function at a time.
1:18:37
drmeister
They even have a "Get your parents to buy it for you by screaming real loud" page: https://conferences.oreilly.com/jupyter/jup-ny/public/content/convince-manager
1:26:21
drmeister
What's wrong with this construct? It's a handler-bind inside of a handler-case - I'm still wrapping my head around conditions and restarts - does it make sense to have a handler-bind inside of a handler-case like this?
1:27:06
drmeister
Clearly I want to generate the backtrace in the handler-bind serious-condition handler - so that it is generated before the stack is unwound.
1:27:35
drmeister
Should I write it into a closed over variable so that the handler-case simple-condition and serious-condition can print it?
1:30:18
drmeister
I added calls to (trivial-backtrace:print-backtrace-to-stream *error-output*) to the handler-case clauses.
1:31:15
Bike
i'd say you can drop the handler-case and just have a handler-bind that muffles warnings, prints conditions, and for errors prints backtrace
3:55:30
drmeister
balrog: We have a version of clasp that does full source tracking and generates lots of debug information.
3:56:16
drmeister
It builds - but it's not quite ready for prime-time because Bike is still working on getting a new type of inlining working.
3:56:46
drmeister
We have disabled the new type of inlining - and because of this it runs about 2x slower than the 'dev' branch.
5:28:41
karlosz
(clisp-cleavir interface meaning not the stuff in the SICL repository, but all the stuff i defined)
5:33:16
karlosz
drmeister: not quite. i've only tried self compiling the machinery i added. lemme try getting quicklisp to use cleavir to load the other parts of sicl
11:13:56
attila_lendvai
drmeister: if you want control over the waf output then you need to stop using print in wscript. mimic the log.info() or .debug() calls that you find there.
12:06:18
kpoeck
Regarding ansi-tests, I forked the hopefully newest repository from jackdaniel on gitlab and pushed the modifications to run clasp in a branch
12:07:34
kpoeck
Instructions on how to run in https://gitlab.common-lisp.net/kpoeck/ansi-test/wikis/How-to-run-the-tests-for-clasp
12:09:34
kpoeck
Since clasp is relatively slow, I added features to just load parts of the tests, e.g. just sequences, but pushing :ansi-load-sequences to *features*
12:10:35
kpoeck
I did not touch any test from upstream, but deactivated the tests that make clasp exit and defined expected failures
12:13:30
kpoeck
Will try to add a functionality to execute the tests with fork, as clasp does in compiling (but need to figure out, how to communicate the subresults)
12:14:48
kpoeck
On my machine (some fixes not yet merged or not even comitted) I get 750 out of 21724 total tests failed:
12:17:02
kpoeck
obviously will try to clean up and make a pr to jackdaniel repository (after testing my changes with other lisps)