freenode/#clasp - IRC Chatlog
Search
4:19:00
drmeister
I'm not sure what is going on there - I'm improving the backtraces to make it easier to debug
4:31:36
drmeister
Actually, the types should match - there is something going wrong with the equal test
4:32:53
drmeister
It compares the value type to the (llvm-sys:get-contained-type (llvm-sys:get-type destination))
4:34:31
drmeister
So something is wrong with the types in this test: https://github.com/drmeister/clasp/blob/dev/src/llvmo/llvmoExpose.cc#L2908
4:39:16
drmeister
Hmm, maybe it's multithreading and the types are not being declared in the same threads. Where are these defined? (cc-mir:lexical-location-type datum)
4:39:56
drmeister
Maybe you are defining them in one thread - rather than looking them up in the context when you use them.
5:02:08
drmeister
::notify Bike Where do you define the types that you use for the alloca and for the datum?
11:23:15
drmeister
fastgf appears to be working with threads now. I switched all of the code over to use CAS
11:26:42
drmeister
933 discriminator functions are compiled in the course of starting up and compiling one form.
11:41:19
drmeister
Thank you very much for pointing out CAS as an alternative. That's the first time I've seriously used it.
12:32:34
drmeister
Bike: Re the irc-store error - is there a table of types stored somewhere that are used to create the alloca or the datum?
12:33:49
drmeister
Because the two types being compared have the same text representation, which in the past has meant they are defined in different threads.
12:41:35
Colleen
Bike: drmeister said 7 hours, 39 minutes ago: Where do you define the types that you use for the alloca and for the datum?
12:42:07
Bike
by the way, clasp dev built fine, didn't see this error, guess i'll try compiling layout-procedure?
12:42:52
drmeister
You aren't running in slime with :spawn - you won't see it unless you are compiling in a different thread from the one that defined the types.
12:44:53
Bike
https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/cmp/cmpintrinsics.lsp#L270-L291
12:47:07
drmeister
Check for any types that are put into tables or globals or whatnot. The type needs to be obtained from the LLVMContext at the time that its used, in the thread that its used in.
12:48:50
drmeister
On my end I'm exposing the call to get the LLVMContext from the type and then compare wrapped LLVMContexts with equal - with that I'll be able to improve the error message.
12:50:41
Bike
on my fix i got a compiler error and the lowest frame in the backtrace is swank::eval-region, buh
12:57:10
drmeister
Do you have any other suggestion rather than the symbol macro thing? I was going for a concise label for types and the ability to behave like a function to get the type from the current *llvm-context*
12:59:12
Bike
it seems like a fine way to deal with the way llvm types work. i guess it's that types being thread-dependent is a little weird for me
13:19:33
drmeister
stassats: I have some slime changes specific to clasp - I'll rebase slime into my repo and then push the change - or should I talk to someone before I do that?
13:23:12
drmeister
Bike: I pushed my changes - you can try the (declare (debug 3)) thing in Cleavir and probe why it's not generating debug info.
13:27:47
beach
For further testing of the CST-to-AST system, I have created a version of the EVAL that I use in SICL that starts by converting the form to a CST. I still have some customization to do, but I can now evaluate forms like (+ 3 4).
13:38:51
drmeister
Bike: I added an error message to irc-store so that it warns if types are obtained from different LLVMContexts/threads.
13:57:23
drmeister
I can now - llvm Type has a getContext and I already exposed LLVMContext's to Clasp. So I wrote a 'equal' method for LLVMContext's that compares their internal pointer.
15:12:00
drmeister
Slime with multithreading is still broken - it seemed to work for a few hours and now it's screwing up again - in a very reproducable way.
15:27:05
drmeister
The challenge is that I can't be sure that the problem is fixed. Things seemed to work fine last night - I couldn't break slime.
15:31:21
drmeister
That doesn't mean that's not the problem - it may be print-object or something like that.
15:40:09
drmeister
shiho: Could you work on getting the fortran formatted output working for the terms that we do have worked out?
15:54:50
drmeister
I wrap the method name and selectors in {} to indicate that it is not a simple function name.
15:55:12
drmeister
shiho: I'm going to start building a new version of Clasp that maybe tomorrow we can use to debug your problems better.
15:58:39
drmeister
We need to set up a torture test of multi-threaded compilation - to compile lots of stuff in multiple threads.