freenode/#clasp - IRC Chatlog
Search
14:37:04
Bike
no. it doesn't seem to be caused by having inline asts. next i suppose i can disable inlining entirely
14:37:19
Shinmera
drmeister: any idea when you'll have time to look at usocket? Not saying you should get to it now, just wondering.
14:39:20
drmeister
Shinmera: I'll take a quick look at it now and see if there is anything simple that I can fix.
14:39:51
drmeister
You said pull the latest usocket from clasp-developers and then run (asdf:test-system :usocket) . to test it - yes?
14:43:15
drmeister
Shinmera: It's got to be problems in mimicking the few sb-bsd-sockets functions from ecl that clasp mimics.
14:44:53
drmeister
beach: We see eclector default source positions (cons number number) showing up. This should never happen because we provide our own source-position method.
14:46:01
drmeister
Indeed. Bike has been working with cst for months - and got it working and then when I tried to build it - I saw this.
14:48:06
beach
And because DEFMETHOD defines the generic function if it does not exist, the problem can go undetected.
14:53:06
beach
You then have to make sure you define your method on the generic function in the right package.
14:55:07
drmeister
https://github.com/robert-strandh/Eclector/blob/master/code/parse-result/package.lisp#L11
14:56:21
drmeister
Bike: scymtym suggested that we subclass eclector.concrete-syntax-tree:cst-client and specialize on that. We don't do that right now.
14:57:06
drmeister
It's probably not the problem unless eclector redefines the source-position method specialized on eclector.concrete-syntax-tree:cst-client
14:58:04
drmeister
https://github.com/robert-strandh/Eclector/blob/master/code/parse-result/generic-functions.lisp#L5
14:59:27
beach
And are you sure that the client you specialize on is also the client that it gets passed?
15:42:43
beach
I don't have a problem here, but then, I specialize on the stream rather than on the client.
15:43:08
beach
So it could be that the function is not passed the client that they bind *client* to.
15:51:40
drmeister
Now I'm starting iclasp from the shell loading bclasp, then setting the :cst *feature*, then loading cleavir then tracing the function...
15:59:36
shiho
drmeister: Did you change somethings about pdb file? (:= *protein* (load-pdb "181L_mod_H_added.pdb")) used to work but now it doesn't.
16:03:02
drmeister
pfdietz: I saw that on hacker news this morning. There is some interesting stuff wrt ORC and registering jitted functions for debugging that I need to follow up on.
16:04:37
drmeister
Shinmera: usocket is going to take a while - I don't see trivial problems that I can fix right away. I'm not sure what is wrong.
16:13:17
drmeister
Yes - I started by looking at that - I see in sbcl.lisp that there is a call to (socket-close socket :abort t) - that's the only call with three arguments.
16:14:02
drmeister
Then I saw that ecl and clasp depend on sbcl.lisp - they probably build on the sbcl code. I don't have slime up at the moment to trace the calls back to the C++ code to see where this problem could be coming up.
16:14:29
drmeister
It may be that the inner C++ function takes one argument now when it should accept :abort t ?
16:16:47
drmeister
It looks like when a (cons number number) gets into Clasp that everything goes to sh*t.
16:23:52
Bike
the C++ name is make. make returns the result of create, which returns the result of a GC_ALLOCATE
16:27:58
drmeister
My initial debugging told me that there were origins that had the form (cons number number) and clasp was doing some implicit casting that let them into the system in a very bad way.
16:28:32
drmeister
The pointers to cons cells were being cast to SourcePosInfo_sp pointers and that is very, very bad.
16:29:19
drmeister
I just added type checking - but this isn't supposed to happen. Source locations are supposed to be SourcePosInfo_sp pointers.
16:30:54
drmeister
We had a combination of (cons number number) being passed in to source-pos-info-file-handle and source-pos-info-handle not doing any type checking and then implicitly casting it to a SourcePosInfo_sp pointer. I fixed the latter here and hopefully now it won't segfault and lock up.
16:44:00
Bike
drmeister: ok, so the origin of the instruction is (0 . 17) i.e. wrong, and then source-pos-info is the car of that, zero, which is what i saw before.
16:54:48
drmeister
I pushed my type check for source-pos-info-file-handle and the better workbench-load.lisp file.
17:16:29
drmeister
The source-position generic function now takes the lambda list (client stream) and the method that we define in translate.lisp thinks it takes (stream client)
19:24:41
Bike
it gets to loop-read-and-compile-forms, then within a few anonymous funcalls it hits another bad access
20:09:31
Bike
the frame source info isn't any more specific, so i'm not even sure what function it is in
23:14:52
drmeister
I wasn't convinced that it was the first argument rather than one of the other functions in the function list.
23:16:42
drmeister
Yes - the result of coercing the function-designator or one of the functions in functions.
23:36:04
drmeister
And I'll check fmv - a standard-generic-function can be a function designator - right? Of course it can.
0:37:25
drmeister
Generic functions are instances of FuncallableInstance_O - that inherits from Function_O