freenode/#clasp - IRC Chatlog
Search
13:21:22
Bike
drmeister: with cst inliningn i get "Mismatch in store function vs target function - you are attempting to store a value in a target where the store instruction is in a different LLVM function from the target value"
14:38:41
Bike
it checks whether the instance being allocated is a class in two different ways, and fuck that, for a start
21:42:43
kpoeck
Question: some of the things I note as bugs are in code borrowed from ecl, but obviously fixed in ecl after the code was cloned
21:44:27
Bike
We have enough different code now that you can't usually paste things from one to the other without at least a little modification.
21:46:58
Bike
that's probably the way to go. i see the problem with cons specifically, that's pretty bad. if missing an else branch.
21:47:48
kpoeck
I think the else branch for (and (consp args) (consp (cdr args))) should be (values 'list '* t)
21:47:51
Bike
but if you compare ecl's and clasp's closest-sequence-type they've been rewritten in different ways.
21:55:06
kpoeck
I have not analyzed about 50% of pfdietz ansi-test suite for clasp, lets see what the other 50% will bring
21:56:24
drmeister
This? " with cst inliningn i get "Mismatch in store function vs target function - you are attempting to store a value in a target where the store instruction is in a different LLVM function from the target value"
21:58:00
drmeister
Somehow a store instruction is being generated in one function that is storing into an alloca in another function.
21:58:13
drmeister
Either the store instruction is out of place or the destination alloca is out of place.
22:02:38
drmeister
I'm not sure - I compiled clasp+cando and when it hit clasp/extensions/cando/src/lisp/leap/fortran.lisp (defconstant %format "format") the compiler stopped with an error. I was in a hurry so I changed it to defvar and restarted the build - then it crashed for another reason.
22:03:50
Bike
but when i did it just for clasp there were a bunch of places that did redefinitions, and then on top of that there's the way build works running through everything several times.
22:04:03
Bike
there was even one in CLOS where it defines a constant and then deliberately writes into the constant...
22:04:08
drmeister
Ok - I'm trying a rebuild with the DEFVAR and if that works I'll set it back to DEFCONSTANT and try again and see if I can reproduce it.
22:36:02
Bicyclidine
one thing is that if you compile file a defconstant and then load the fasl, that's a redefinition
0:22:05
drmeister
And here... https://github.com/drmeister/cando/blob/dev/src/lisp/leap/topology.lisp#L1309
0:24:01
Bike
here's the issue. defconstant twice is only defined if the values are eql. if the values are eql there's no problem.
0:24:28
Bike
but the string at compile time will be different from the string reconstructed by a fasl, so they won't be eql.
0:24:48
Bike
previously clasp would let you redefine constants to anything if you hit another defconstant.
0:25:48
drmeister
Which does (ql:quickload "build-cando") and the build-cando.asd looks like this...
0:27:34
drmeister
What do you recommend? Is it a bug in the defconstant implementation or something else?
0:27:50
Bike
it's not a bug. i just made defconstant strict, and cando was relying on undefined behavior.
0:28:32
drmeister
Got it - that's ok - if I'm abusing DEFCONSTANT then I have no problem changing the code so that I'm not.
0:29:18
Bike
okay, so here's an example of what i did when this came up in clasp itself https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/lsp/mislib.lsp#L180
0:29:40
Bike
means it'll ignore constant redefinitions as long as the new value is equalp to the old one
0:33:56
attila_lendvai
constantness as an intention has useful information for the reader of the code (that includes you 2 weeks down the road), so it's worth keeping
0:35:44
drmeister
Bike: No problem - I didn't internalize the spec on DEFCONSTANT and wrote bad code.