libera/#clasp - IRC Chatlog
Search
16:27:22
yitzi
There is some documentation for it on line 263 in include/clasp/core/lambdaListHandler.h
17:02:53
drmeister
::notify karlosz We have several functions that parse lambda lists. In lambdaListHandler.cc start with parse_lambda_list - that's a C++ function that breaks it up (copied from ECL). You probably want the lisp accessible one - use core__process_lambda_list
17:14:23
drmeister
I'm going to push my bytecode additions soon - then you guys can get to work on writing the interpreter and modifying your compiler to work with them.
17:18:07
drmeister
the BytecodeModule_O initializes a _Literals slot with a ComplexVector_T_sp object and a _Bytecode slot with a ComplexVector_byte8_t_sp object. You can use those to fill in information or stick anything you want (simple-vectors) into those slots.
17:26:54
drmeister
karlosz said he was working on lambda list processing - so it sounds like argument handling isn't in place yet.
17:26:58
Bike
karlosz has been doing a lot of it... looks like it can do progn let flet labels setq if function tagbody go block reutnr-from quote
17:27:17
Colleen
karlosz: drmeister said 24 minutes, 23 seconds ago: We have several functions that parse lambda lists. In lambdaListHandler.cc start with parse_lambda_list - that's a C++ function that breaks it up (copied from ECL). You probably want the lisp accessible one - use core__process_lambda_list
17:28:46
karlosz
drmeister: parse-lambda-list looks like what I need. trying to keep in mind that we'll want to rewrite the compiler in C++ soon so trying to keep things simple
17:29:34
karlosz
Bike: we'll probably have to merge the cvm repo into clasp or something so we can reference clasp specific functions for lambda list parsing etc? I don't really fancy writing a generic lambda list handler there
17:34:14
yitzi
drmiester: The updates for the show command should be in the nightly build, btw. Sidebars, etc. I've also add stuff to cando-user-install to automatically take care of jupyter widget installation and updating.
17:40:21
karlosz
Bike: i think this is how we should proceed. start making the compiler in cvm clasp specific but still in Lisp (using functionality such as parse_lambda_list and the clasp catchers, throwers, special variable representation, progv, etc.) and plug it into the new VM datastructures drmeister wrote. then we write out the real VM and test against the
17:40:21
karlosz
Lisp compiler. Once the Lisp compiler is fleshed out we rewrite it in C++. The compiler is still simple enough to make that straightforward
17:43:12
drmeister
F*CK - I'm getting spurious random crashes and assertion failures. I'm talking about over the last couple of days. They are happening enough to trigger my spidey senses that there is some kind of problem.
17:44:44
Bike
i was thinking we could use alexandria to parse lambda lists and define thunk versus of progv and stuff. with the vm calling vm trick we can make vm dynamic environments into host dynamic environments
17:48:04
karlosz
i suppose alexandria:parse-ordinary-lambda-list is generic enough for the purpose at hand which is to deal with the entry points we need
17:50:49
karlosz
Bike: will you have time to deal with the rest of the special forms and the environment stuff? there's not that many left to do at this point
17:53:30
drmeister
I'm going to push this stuff in the 'vm' branch because I'm worried about stability of clasp at the moment. I need to run this on zeus under udb to see if I can figure out if there is a problem and what that problem is.
17:54:08
drmeister
This bytecode stuff. Are you guys ok with working in the 'vm' branch for the bytecode stuff? I'll keep it updated with main.
17:57:00
drmeister
None of what I've done should have led to random crashes but who the heck knows what's truly going on with complex software
17:57:40
drmeister
I'm building clasp over and over and over again and like 1 out of 4 clasp runs something weird happens.
18:03:07
Bike
drmeister: yeah, i've seen some things. "unidentifiable entry point" a lot. one time i got "../src/llvmo/runtimeJit.cc.227:abandon I have no idea what to do here" and then it just hung
18:03:26
yitzi
Don't forget about the ansi failures with disassemble that happened after drmeister reworked the function classes. Unless Bike has figured out it out.
18:03:30
Bike
drmeister: also, as yitzi noted, currently the tests are failing because (typep #'make-instance 'core:funcallable-instance) => NIL - not sure what's up with that
18:27:53
Bike
and that error is happening because generic functions are no longer considered compiled-functions
18:33:43
drmeister
Ok, I'll take a look at it. "generic functions are no longer considered compiled-functions" sounds really wrong.
18:34:17
Bike
i think the (typep #'make-instance 'core:funcallable-instance) => NIL is the underlying problem there
18:34:26
drmeister
I'm running the static analyzer on my changes after merging the main branch. I'll push soon to the 'vm' branch.
19:16:40
Bike
i just got an error after misc-1, too. i think the one that indicates a memory problem?
19:18:56
Bike
../src/gctools/cons_scan.cc:50 CONS in cons_scan client=0x7f47c30fcec8 original_client=0x7f47c30fcec8 limit=0x7f47c30fced8 (it's not a CONS or any of MPS fwd/pad1/pad2 car=0xcccccccccccccccc cdr=(nil)
20:33:19
drmeister
I found one problem. Initializing the VirtualMachine stack I was writing outside of the stack.
20:58:00
drmeister
I fixed the bad pointer issue and I'm running the static analyzer and then I'll push everything to main - then we can evaluate the other problems we are seeing.
21:45:17
Bike
yitzi: one of the PR tests failed in a strange way. the other two look good, though (meaning they're fine except DISASSEMBLE-8 and DISASSEMBLE-9)
22:38:08
yitzi
Bike: I agree, I don't think that has anything to do with that PR. Could be just a crash.
22:44:20
yitzi
drmeister: When the analyze script is done, both src/analyze/clasp_gc.sif and src/analyze/clasp_gc_cando.sif should be updated.
22:46:44
drmeister
(class-of #'make-instance) -> #<The CLOS:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
22:59:21
drmeister
I'm exposing a function core__header_stamp that will read the header stamp. I expect that to be the stamp of FuncallableInstance_O but the rack stamp will be the stamp for #<The CLOS:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
23:59:49
drmeister
(sb-mop:class-precedence-list (class-of #'make-instance)) doesn't include funcallable-instance
0:51:34
drmeister
::notify karlosz I pushed the changes to the 'vm' branch of clasp to support a bytecode compiler and interpreter.
0:51:47
drmeister
::notify Bike I pushed the changes to the 'vm' branch of clasp to support a bytecode compiler and interpreter.
1:24:24
drmeister
I have the C++ function bytecode_call invoke (defun SYS:BYTECODE-CALL (pc-pointer closure args) ...)
1:24:48
drmeister
I've added methods to access the entry-point from the closure and all the bytecode_function stuff you asked for.
1:25:18
drmeister
Also, the pc-pointer is a Pointer_O object and you can read bytes and in-place-increment the pointer with a positive or negative offset.
1:26:44
drmeister
It won't be super fast because of overhead - but it should let you write one for debugging and testing.
1:49:32
Colleen
Bike: drmeister said 57 minutes, 45 seconds ago: I pushed the changes to the 'vm' branch of clasp to support a bytecode compiler and interpreter.
1:50:26
drmeister
Right. The stamp for FuncallableInstance_O is in the header of every generic function - but the class of a generic function is defined by the stamp in its rack.
1:51:26
drmeister
Just like the stamp of Instance_O is in the header of every instance of a clos class - but it's not in the class-precedence list of any clos class
1:52:10
drmeister
Yeah gc::IsA uses the header stamp to determine what C++ class an object belongs to.
1:52:12
Bike
L339-340 of src/core/predicates.cc is where compiled-function-p checks if something's a funcallable instance
1:55:06
Bike
also (typeq #'make-instance core:funcallable-instance), which uses the header stamp i think
2:00:52
Bike
(clos:funcallable-standard-instance-access #'make-instance 2) => #<METHOD-COMBINATION STANDARD>
2:06:13
drmeister
Digging deeper - I just need to get my cando to build here and I can ask it some questions.
2:31:56
drmeister
STAMPWTAG_core__FuncallableInstance_O = ADJUST_STAMP(997), // stamp 249 unshifted 0x3E5 shifted 0xF94
2:37:15
drmeister
Bike: aside - are we going to call bytecode compiled function xxx (compiled-function-p xxx) -> T
2:50:41
Bike
for now we might want to say no, in case there's stuff expecting compiled functions to have machine code, like disassemble does
2:50:55
Bike
(having disassemble work on the bytecode would be good. i already wrote a disassembler for the bytecode)