libera/#clasp - IRC Chatlog
Search
14:32:37
drmeister
Ok - but `brew upgrade` on some of our machines is complaining and failing with llvm15 - that must be a brew screwup then.
14:33:22
drmeister
Now on my machine I have that `ld:library not found for -lexpat` - that looks like a koga/building/linking issue.
14:33:46
drmeister
I just tried setting `export DYLD_LIBRARY_PATH=/usr/local/Cellar/expat/2.5.0/lib/`
14:34:48
drmeister
I cannot run cando-user-install - it keeps failing with `ld: library not found for -lexpat`
15:21:45
Bike
trying to use my bytecode compile file stuff to build some quicklisp systems... looks like i need to figure out what cmpbundle is/does
15:27:30
Bike
does build-fasl just take a bunch of compile-file outputs and combine them into a single file?
15:28:33
Bike
and, much more bikesheddy question, what file extension should i use for bytecode FASLs? i've been using "lbc" for "lisp byte code" since i figure we have enough fasX already
15:53:31
yitzi
Even if we compile to bytecode....snapshots will still be around for SAVE-LISP-AND-DIE.... so it needs to be improved
15:53:40
drmeister
I'll paste the working command line and the one that doesn't find expat once I have them both.
15:56:00
drmeister
Yes, I don't want to remove snapshots or save-lisp-and-die - they are very useful. I just want bytecode for those cases where we don't need ultimate speed and we don't want to depend on the user to get a brittle compile/link to work.
15:56:34
drmeister
/usr/local/Cellar/llvm@14/14.0.6/bin/clang++ -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib -L/usr/local/Cellar/llvm@14/14.0.6/lib -Wl,-search_paths_first -Wl,-headerpad_max_install_names -pthread -fvisibility=default -rdynamic -L/usr/local/Cellar/fmt/9.1.0/lib -L/usr/local/Cellar/gmp/6.2.1_1/lib -oboehmprecise/sclasp-boehmprecise -sectcreate __CLASP __clasp /tmp/ss-MlJIJbXT
15:56:34
drmeister
-Wl,-force_load,/Users/meister/Development/cando/build/boehmprecise/lib//libclasp.a -lclangASTMatchers -lclangDynamicASTMatchers -lclangIndex -lclangTooling -lclangFormat -lclangToolingInclusions -lclangToolingCore -lclangBasic -lclangCodeGen -lclangDriver -lclangFrontend -lclangFrontendTool -lclangCodeGen -lclangRewriteFrontend -lclangARCMigrate -lclangStaticAnalyzerFrontend -lclangFrontend -lclangDriver -lclangParse
15:56:34
drmeister
-lclangSerialization -lclangSema -lclangEdit -lclangStaticAnalyzerCheckers -lclangStaticAnalyzerCore -lclangAnalysis -lclangAST -lclangRewrite -lclangLex -lclangBasic -lLLVM-14 -lexpat -lfmt -lgmpxx -lgmp
15:57:00
drmeister
/usr/local/Cellar/llvm@14/14.0.6/bin/clang++ -L/usr/local/Cellar/llvm@14/14.0.6/lib -Wl,-search_paths_first -Wl,-headerpad_max_install_names -pthread -fvisibility=default -rdynamic -L/usr/local/Cellar/fmt/9.1.0/lib -L/usr/local/Cellar/gmp/6.2.1_1/lib -o/Users/meister/.local/bin/scando -sectcreate __CLASP __clasp /tmp/ss-TUytFb0i -Wl,-force_load,/usr/local/Cellar/cando/2.1.0-26-g7fa8d5d6a-gbb2c2b01/lib/clasp//libclasp.a -lclang-cpp
16:06:59
Bike
really i just think we have proliferated too many of these already and i'm loathe to add another one, but i guess that's what it comes down to
16:08:06
Bike
but is that what cmpbundle does? build-fasl particularly? put a bunch of fasls together? because i have not written that capability for the bytecode fasls but i guess i could
16:28:25
drmeister
I traced build-fasl and I combine that with my recollection it takes a list of .faso files and links them into a .fasp file.
16:30:03
drmeister
More generally - it takes a bunch of object files and combines them into a library file.
16:30:53
drmeister
It supports object files of different types: :faso, :fasoll, :fasobc, and :object
16:32:14
drmeister
You need to add an equivalent for bytecode object files and a format for a bytecode library.
16:32:43
drmeister
I think you should stick with .fas<bytecode-object-identifier> and .fas<bytecode-library-identifier>.
16:33:00
drmeister
ASDF requires that there be an object file extension and a separate library file extension.
16:34:45
yitzi
There are some of the FASL formats that don't work in build. We could probably remove some old ones.
16:37:01
drmeister
The :object we haven't used for a while and maybe we could get rid of that one - it's the traditional way of linking things.
16:37:32
drmeister
But since we've taken control of the object files more directly I would be fine with removing :object
16:39:52
drmeister
I don't see more .fas<xxx> as a needless proliferation. The .fas<xxx> let's us quickly find/identify the .fas<xxx> files.
16:41:34
drmeister
Especially because we are going to be mixing .faso/.fasp and .fas<whatever-bike-chooses-for-bytecode-object-files>/.fas<whatever-bike-chooses-for-bytecode-library-files>
16:42:25
drmeister
As I mentioned above - it's a HARD requirement of ASDF that we have two file types, one for object files and one for libraries.
16:43:05
drmeister
And the build-fasl function is responsible for linking multiple object files into libraries.
16:43:52
drmeister
Clasp also has the ability to link multiple library files into another library file.
16:45:40
drmeister
I think I did that so that we could bundle up a whole bunch of code into a single file and load it with a single command.
16:55:33
Bike
being able to link multiple bytecode fasls together into one big one is a nice feature anyway. i should be able to make it a little smarter in that the sub-fasls will be able to share constants.
16:57:30
Bike
i would generally like to support a couple operations with fasls besides loading, since i think that can improve robustness. for example if we put in some kind of versioning info, when we load we could check that before actually executing any of the fasl code, so if there's a mismatch we don't end up with the fasl half loaded
16:59:12
Bike
or even something finer grained, like making sure all the packages exist before doing anything
16:59:35
Bike
i don't have a problem with the .fas extension. the proliferation is just in the actual formats. we have like, at least eight i think
17:03:01
Bike
the more ideal situation imo is if we had one format that we could put different stuff in depending on the situation. e.g. we have the same file format for bytecode, bitcode, object code, and ll, and just indicate the different kinds of code within the file
17:20:03
Bike
well ideally it would be one actual format rather than a bunch of different formats. for example the format i'm working on has a byte for "bytecode function coming up", so it could have another one for "bitcode coming up"