freenode/#clasp - IRC Chatlog
Search
5:33:17
drmeister
::notify shiho Pull the latest clasp 'dev' and start building it again. I had introduced a problem in the previous version that only showed up when building quicklisp. The new 'dev' fixes it.
5:48:43
verisimilitude
Here's a quick question; the proper way to exit from a running Clasp is (CORE:QUIT), right?
9:20:29
kpoeck
When i now compile a previosly interpreted function, i get a error about core:: Lambda-List-Handler-Lamda-List not having a method for fixnum
11:12:01
cracauer
some clasp thing successfully built overnight, without using pinned other software. Wo-hoo.
11:59:10
scymtym
ACTION thinks he finally untangled the interdependencies between conditions in Eclector's reader and readtable packages
12:20:39
scymtym
as a result entering a stray #\# no longer crashes the language server (bonus: nice syntax error reports). yay
12:52:51
Colleen
shiho: drmeister said 7 hours, 23 minutes ago: Pull the latest clasp 'dev' and start building it again. I had introduced a problem in the previous version that only showed up when building quicklisp. The new 'dev' fixes it.
12:52:51
Colleen
shiho: drmeister said 7 hours, 19 minutes ago: Pull the latest clasp 'dev' and start building it again. I had introduced a problem in the previous version that only showed up when building quicklisp. The new 'dev' fixes it.
13:14:38
scymtym
do you consider this a full paper/short paper/lightning talk and is the scope strictly eclector or CL source tracking for compilation and editing?
13:20:27
scymtym
reading the abstract made me think about a survey of source tracking techniques for CL. i.e. 1) the classic using CL:READ into stuffing things a hash-table 2) using eclector and storing source locations in slots of intermediate representation objects 3) using eclector and storing source locations outside of intermediate representation objects maybe 4) decoupling the reader from the result representation using protocols
13:21:00
scymtym
something like that seems more "scientific" to me than describing a library, but that may be my bias
13:23:05
beach
There could also be an "application" section after the "our technique" section that suggests several use cases.
13:24:00
scymtym
yes, except that, if eclector's architecture is sound, there should be lots of applications
13:25:04
beach
I should continue working on it. That way you will have a better idea of what I have in mind.
13:25:49
beach
And of course, the abstract is a summary of the paper, so it may change as the contents evolves.
13:26:30
scymtym
my point is, aren't those applications, their different requirements, how well the existing and new reader implementation techniques meet those be more interesting than the library itself?
13:28:10
beach
I think the technique itself is interesting too. The out-of-band wrapping, so that the reader still returns expressions, etc.
13:29:39
scymtym
this thought also touches on the fact that CST, AST, the source location representation library and the transform tracking library are all unpublished (i think) but may be important for understanding certain aspects
13:31:52
scymtym
in fact, describing an abstract syntax for CL at all, implemented as a library or not, seems like a solid contribution
13:35:10
scymtym
but in my previous message, i really meant *A*ST since i'm not aware that a description of the (an?) abstract syntax has been published (despite various code walkers and whatnot implementing something more or less to that effect)
13:36:39
scymtym
for example http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.walker;a=headblob;f=/source/handler.lisp
13:38:41
heisig
scymtym, beach: I think you should also mention that once you have such an amazing reader for Common Lisp, you also have an amazing tool for all languages you build ON Lisp.
13:39:35
Bike
also the place clasp "code walks" does so by putting a method on convert, rather than building an AST and then examining i
13:39:49
Bike
i guess that could change though. could just map-ast and look for the particular nodes. not sure
13:40:40
heisig
I don't know. What happens to Eclector if the readtable would be hacked to read in e.g. FORTRAN?
13:41:16
heisig
But even if it would only work for S-expression based DSLs that would already be a huge win.
13:41:21
Bike
scymtym: convert is the generate-ast form->AST function. with cst we have to do form->CST->AST
13:42:58
scymtym
Bike: i see. so something like: (defmethod convert ((form cons)) (convert-using-operator form (car form)))?
13:43:21
beach
scymtym: This discussion reminds me of the difficulty I have had defining a general-purpose code walker.
13:45:20
scymtym
Bike: sorry, i misunderstood. i thought you meant putting one method for each special operator
13:46:28
scymtym
beach: i did a generic code walker with pkhuong's idea for composability for SBCL. i think it is pretty cool, but too hard to integrate into SBCL
13:48:52
beach
I imagine it has to be configured what it returns, and how to combine the results of recursive calls to form a complete call.
13:49:59
scymtym
https://github.com/scymtym/sbcl/blob/wip-walk-forms-new-marco-stuff/examples/code-walking-example-without-clos.lisp
13:52:26
Colleen
kpoeck: drmeister said 2 hours, 2 minutes ago: Do you have a test case for that lambda list thing?
13:52:42
scymtym
the gist is: a user function is called for each form. it receives a function that recurses into (direct) children when called, a function for replacing the current form with something else and a function for reconstituting results received from recursive calls into forms
14:38:22
kpoeck
Well staring at the source code the error seemed obvious, will paste the error when i am again in front of my computer
15:01:55
drmeister
::notify kpoeck I removed four function classes - one of which was the InterpretedClosure_O class - and now we just use ClosureWithSlots_O. Slots that were unique to InterpretedClosure_O class are now put into the generic slots of ClosureWithSlots_O. You are probably running into a consequence of that change. I don't know yet if what you are seeing is incorrect behavior or just different implementation specific behavior.
15:03:18
drmeister
I don't know yet - every time I get to onto IRC kpoeck has just left - so I haven't been able to get details and I can't figure it out from the IRC log.
15:07:10
drmeister
Huh - I expected (defun foo (a) (list a)) to generate a compiled function - but it's not - it's an interpreted function.
15:08:03
scymtym
Bike: looking at the eclector condition reporters, i'm changing "~D elements" to "~D element~:P" to get the correct numerus (i'm mentioning this in case you are not familiar with the idiom)
15:12:15
drmeister
So maybe it's a problem that it thinks it's an interpreted function when it is a compiled function - or it should be a compiled function but it's an interpreted function. Digging deeper.
15:18:14
drmeister
There is C++ field in ClosureWithSlots that stores an enum of either interpretedClosure, bclaspClosure or cclaspClosure.
15:22:14
drmeister
The plan was to remove those other closure classes and use slots in ClosureWithSlots_O to emulate them - right?
15:25:25
Bike
I kind of expected that there wouldn't be a need to distinguish bclasp closures and cclasp closures though.
15:26:43
drmeister
For what method? Slot lookup is different for bclasp closures and cclasp closures. bclasp closures have a separate activation frame that they have to look into.
15:27:06
Bike
right, but the only thing that has to look up slots is the underlying function, right?
15:27:48
Colleen
kpoeck: drmeister said 25 minutes, 52 seconds ago: I removed four function classes - one of which was the InterpretedClosure_O class - and now we just use ClosureWithSlots_O. Slots that were unique to InterpretedClosure_O class are now put into the generic slots of ClosureWithSlots_O. You are probably running into a consequence of that change. I don't know yet if what you are seeing is incorrect behavior or just different implementation specific behavior.