freenode/#clasp - IRC Chatlog
Search
17:32:15
drmeister
From the *magit: clasp (magit-status) hit 'd' 'r' to specify a range as in working-fastgf..derivable
17:34:22
drmeister
I can never just get fastgf working for Common Lisp classes - oh no! I have to get it working for wrapped C++ classes and derivable C++ classes at the same time.
17:35:04
drmeister
And I make what seem like perfectly reasonable changes but that breaks CLOS startup in weird unobvious ways.
18:49:30
Shinmera
drmeister: btw: https://www.kickstarter.com/projects/1681258897/its-magit-the-magical-git-client?ref=4fjway
20:39:25
Serenitty[m]
Hm, the error that I'm getting here is all in the LLVM IR, so I have no idea how to fix it.
20:40:41
Serenitty[m]
ACTION sent a long message: Serenitty[m]_2017-09-09_20:40:40.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/XHNqREycmwSBVTPOZraFJeoc>
20:41:38
drmeister
It's going to take a bit of time to reproduce that one and figure out what is going on.
20:42:09
Serenitty[m]
In the meantime, should I just build the master branch? Would I be missing out on much?
20:42:12
frgo
This is again the target triple problem. I tried to get gentoo running here but no luck. I had a similar thing on macos in another project.
20:43:37
drmeister
I think the problem is unrelated. We've had warnings about the target triple for a long time.
20:44:37
drmeister
I don't have anything running right now - everything is broken for me - so I can't do much at the moment.
20:45:25
drmeister
Serenitty[m]: I'm working on generic function dispatch and yes - my build is broken at the moment.
20:46:40
frgo
drmeister: I was wondering how exactly we get the target triple from LLVM - where do I have to look? wscript?
20:47:27
drmeister
It's hard coded in one place https://github.com/drmeister/clasp/blob/working-fastgf/src/lisp/kernel/cmp/jit-setup.lsp#L58
20:49:33
drmeister
Serenitty[m]: You caught us at a bad time. Within days of switching to llvm5.0 when I was working on generic function dispatch and broke everything on my system.
20:49:34
frgo
Ok. Thanks. I think I do wrote a little C++ utility that just prints the triple. As a reference and for checking if we have all the same / the right ones.
20:51:02
Serenitty[m]
When you say generic dispatch, does that involve generating compiled code for dispatch? I remember being told that in other implementation dispatch was very slow because it was all interpreted. Is that true?
20:52:09
drmeister
Yes, it involves generating compiled code for dispatch. I don't know about other implementations.
20:53:05
drmeister
It will be once I get it working. My challenge is that I have to get it working for C++ classes and derivable C++ classes at the same time. Lots of moving parts.
20:53:37
Serenitty[m]
Ah, so generic functions need to be able to specialize on C++ types? That's amazing.
20:56:04
Serenitty[m]
One more thing. The instructions say to clone the master branch of the externals repository, no matter which branch of Clasp you are using. Is this correct?
21:01:55
Serenitty[m]
Or well, not the first time. I did it this time for the testing branch, but testing is even with master, anyway.
21:02:58
drmeister
I'm just much more focused on developing clasp than serving it up to users at the moment. Hang on...
21:34:45
drmeister
(clos:class-precedence-list (class-of (make-instance 'ast-tooling:match-callback))) ->
21:35:18
drmeister
(#<The STANDARD-CLASS AST-TOOLING:MATCH-CALLBACK> #<The CORE:DERIVABLE-CXX-CLASS CORE:DERIVABLE-CXX-OBJECT> #<The BUILT-IN-CLASS CORE:INSTANCE> #<The BUILT-IN-CLASS CORE:GENERAL> #<The STANDARD-CLASS AST-TOOLING:MATCH-CALLBACK-ABSTRACT> #<The BUILT-IN-CLASS T>)
21:36:27
drmeister
I didn't recommend it because I know one system where the 'testing' branch broke.
23:14:45
drmeister
I'm building on Linux now - I also am seeing issues with missing standard header files.
23:23:15
Serenitty[m]
Well, the externals built perfectly without any modifications this time, which is an improvement. But I get the following error when I try to build Clasp itself: AssertionError: Could not find /home/gareth/Code/clasp/src/llvmo/builtins.cc
23:27:58
Bike
so preview is old enough for llvm 4, but not new enough to have the file we forgot to put in... unfortunate
23:30:53
drmeister
Serenitty[m]: could you check back in a few days? We are not ready to build anything it appears.
0:27:43
drmeister
Hit a fatal error in llvm/clang: Cannot select: 0x78ed018: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<%"struct.core::ThreadLocalState"** @my_thread> 0 [TF=10] 0x78ed2f0: i64 = TargetGlobalTLSAddress<%"struct.core::ThreadLocalState"** @my_thread> 0 [TF=10]
1:58:11
drmeister
I have a fix - but it's a bit of a step back - I took out inlining of calls to get the thread-local storage in the JITted code.
2:13:14
drmeister
There are discussions that suggest accessing thread local variables in the host from jitted code is problematic
2:24:25
Bike
wonder why it works on OS X then. oh well, i guess we'll continue hoping special variables are rare
2:36:47
drmeister
Just one - it implemented symbol-value. It's not too bad - it has to look up symbol-value in a thread local data structure.
2:39:26
drmeister
Getting there - the analyzer runs within Clasp - so I have to build a version of Clasp that doesn't need the static analyzer product.