freenode/#clasp - IRC Chatlog
Search
2:56:52
drmeister
Do we need to change how defconstant compiles in Clasp so that we can handle things like...
3:52:54
ringer1_
drmeister, don't want to take up any of your time (tonight) but I do want to use clasp and help in some way
3:53:43
ringer1_
Was starting to fear the project was stalled -- had trouble finding your irc even (my client didn't have the channel)
3:57:59
ringer1_
drmeister, yes it is HUGE, I watched your old talk at Google and you amazed me (I am not that easily impressed either)
4:01:13
ringer1
sorry, got kicked by server issue -- having multiple irc client difficulties getting to you folks
4:01:58
ringer1
beach, I thought that would be enough -- limited Lisp experience and he first got it working and then brought it up to decent performance
4:02:44
ringer1
There isn't detail of that effort in the talk, but I'll bet there are a lot of specifics I don't know about
4:03:30
ringer1
but I can imagine trying to hack through these several code bases, just getting the builds to work can be tedious as soon as you leave the main line
4:03:56
drmeister
beach: I plan to propose at Nvidia that we use cleavir to compile a small subset of Common Lisp to PTX for Nvidia GPU's.
4:04:02
ringer1
I run into this because although I'm willing to do Linux, I typically want to see Windows work also
4:05:56
ringer1
I knew a tiny amount about LLVM since I've been looking into Julia and Haskell to LLVM
4:22:06
drmeister
beach: I'm not sure if I asked this before - we don't have a way of serializing HIR do we?
4:24:25
drmeister
::notify kpoeck Did you see this problem building mcclim? [package iterate]...............Condition of type: SIMPLE-ERRORNo applicable method for UPDATE-INSTANCE-FOR-REDEFINED-CLASS with arguments of types CLAUSE-INFO NULL NULL NULL. ? If so - how did you get past it?
4:38:16
beach
We would need to add methods on that generic function (SAVE-INFO is it?) for every HIR class. But that can be done.
5:42:17
ringer1
good night, any particular thing best to read or do to get up to speed? Found the cleavir.pdf
5:43:13
beach
Depends on what you want to accomplish. As a user of Clasp, you don't need any of that.
5:43:47
beach
If you want to attack the compiler, you need to be an experienced Common Lisp programmer with lots of CLOS experience, and you need to know about compiler design.
11:24:22
drmeister
beach: I'm thinking of serializing HIR so that we can get optcl (sp?) running and render HIR from clasp.
11:25:01
drmeister
Bike has got a nasty inlining bug and I'm thinking about tools that could help debug the problem.
11:46:21
drmeister
Because I'm having trouble getting McClim to build on Clasp and it takes a long time to get it to build.
11:47:14
drmeister
So - what if we serialize out HIR graphs as we generate them and then flip through them with opticl running on McClim in sbcl.
11:48:05
drmeister
Like we currently use Chrome to visualize HIR graphs serialized out as PDF or PNG files.
11:48:07
beach
But if you are going to run it from SBCL, why not run the visualizer. SBCL loads McCLIM quite easily.
11:50:38
drmeister
When kpoeck told me about it I assumed it was your HIR viewer. In retrospect it seems a bit odd that kpoeck would point me to the HIR visualizer.
11:51:54
beach
Well, if you run cleavir-ir-visualizer from SBCL, you don't need to care about opticl.
11:56:12
drmeister
Here's what I'm imagining - if we were to set up a breakpoint in the inlining code and step through it from break-point to break-point while generating HIR output in sequential files - could the cleavir-ir-visualizer rapidly render the HIR so we can see each change to the HIR as it happens?
11:57:37
beach
Hard to say. I imagine it depends on the size of the HIR. When I have used it, it was instantaneous.
11:58:20
drmeister
Bike has spent months debugging inlining and I have a lot of ideas for things to do with HIR.
11:59:27
beach
I would set up a SICL first-class global environment inside SBCL that contains Clasp macros and other essential definitions.
12:02:07
drmeister
We need a better tool to debug this stuff. The "sea of nodes" is bewildering to navigate.
12:03:32
beach
A basic block would have tons of data input to it and output from it that would not be obvious to understand.
12:04:41
drmeister
We don't have a basic block compiler - we need more powerful debugging tools for our compiler.
12:05:01
beach
Looking at your Graphviz renderings, I can already say that the visualizer does a much better job.
12:05:26
drmeister
But using graphviz from one graph to another, things jump around a lot and we can't collapse and expand subgraphs.
12:06:48
drmeister
I'd like to add annotations to the HIR and have the visualizer use those annotations to decide what to render.
12:07:56
drmeister
Sounds dreamy - I'll encourage Bike to get sicl and the visualizer up and running.
12:08:37
beach
I carefully compute the longest simple path in each function so that the main control flow is downwards.
12:10:46
beach
Now, the visualizer is CLIM and Common Lisp code, so it would be fairly easy to add a CLIM command, say, "inline step".
12:11:16
beach
... since CLIM automatically recomputes the output records after each command invocation.
12:12:53
beach
And it could be driven by "presentations". Click on a node to transform it in some way.
12:13:30
beach
These commands don't all exist of course, but this is CLIM and Common Lisp, so they make it easy to do things like that.
12:17:38
drmeister
Sounds good. What do you think about a "comment" instruction - it would do nothing but let you embed some info in the HIR and it would get carried along with the transformations.
12:23:31
scymtym
beach: i hope i'm reducing the confusion instead of adding to it but i also thought that opticl was a non-optional dependency of mcclim nowadays. are you sure it is not?
12:26:25
scymtym
i guess the important question is whether loading mcclim automatically loads opticl and if so, if there is a way to avoid that
12:27:11
jackdaniel
it is on asdf dependency chain (so yes, it is loaded by default), but changing that would be easy
12:28:21
stassats
you were not happy with it using ffi, but if you don't actually run the code that uses ffi, that won't be a problem
12:29:25
jackdaniel
I think that clisp was locked out due to indirect dependency on static vectors by opticl
12:31:03
jackdaniel
yes, I believe it is based on ffi and on unsupported implementations it simply errors in asd file
12:33:42
jackdaniel
excerpt from its readme: "Can optionally write to foreign memory using static-vectors. This is useful when needing to
12:33:45
jackdaniel
efficiently pass a pointer to the image data with a foreign library, such as OpenGL."
12:34:41
jackdaniel
and pngload is opticl's fast backend for png loading (there was slower implementation used beforehand and that's what clisp resolves to)
12:37:54
beach
I think if opticl is the only problem for loading McCLIM into Clasp, and McCLIM doesn't really need it, at least not in order to run the visualizer, then the most efficient solution is to comment out the dependency on opticl.
12:40:22
scymtym
the high performance claim of pngload doesn't seem super-convincing given they do (with-slots (data palette transparency) *png-object* …) and then access the slots in inner loops
12:41:25
Shinmera
scymtym: It's faster than the previous library for sure and currently bounded by chipz deflation.
13:55:53
drmeister
And what was it before we made this change? I want to compare apples to apples here.
13:58:00
beach
drmeister: It appears that, although opticl is a dependency for McCLIM, it is only needed for loading certain types of image files. So if opticl is the main difficulty in running McCLIM from Clasp, then the simplest solution might be to eliminate that dependency.
13:58:50
drmeister
I have a few other problems building McClim that kpoeck got around somehow. I'll wait until he has some time to show me how he did it.
14:04:24
rustyv
just wanted to quickly mention that I tried doing a CLASP build on a fresh Debian machine over the weekend
14:14:09
drmeister
Ok, thanks - it looks like I have some work to do there - I won't be able to look at it for at least a week.
14:23:57
rustyv
and you think it's not due to some differences in how the build process is handled in Debian vs. MacOS?
14:25:25
rustyv
is it possible that I was just following the wrong build instructions? Are the instructions on the github wiki the most up to date?
14:26:26
drmeister
That's debugging right? It worked on macOS a few weeks ago when I tested it and it doesn't work on Linux. Why? No idea.
14:28:27
drmeister
Look up thread local storage in Clang and read up on OS dependence. You will see that it's kind of a nasty area.
14:29:48
drmeister
We are compiling bitcode and then loading it dynamically into a running environment - who does that? Almost nobody - it's bleeding edge stuff.
14:31:43
rustyv
oh, for sure. It's neat stuff, to say the least :) I had no expectations that things would work flawlessly.
14:32:12
Bike
drmeister: multiple-value-foreign-call returns multiple values but takes single values as inputs, right?
14:36:44
drmeister
Bike: I think so - I think it is only there to handle cases where the call returns multiple values.