freenode/#clasp - IRC Chatlog
Search
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.
14:41:08
rustyv
drmeister: I'd gladly offer help if I had enough knowledge to give. I'm not knowledgeable in C++ or much of CL for that matter.
14:45:49
drmeister
kpoeck_: I did see that - and I am using the following branches of clx and mcclim...
14:47:22
drmeister
I'll restart the build and paste the log - but you don't need to debug my problems unless you have already done so.
21:33:03
Colleen
kpoeck: drmeister said at 2018.10.13 19:45:00: Don't build MPS for now - I can see a problem - but I don't know why it's happening.
21:33:03
Colleen
kpoeck: drmeister said 17 hours, 8 minutes ago: 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?
21:33:42
kpoeck
(defmethod clos:update-instance-for-redefined-class ((instance structure-object) added-slots discarded-slots property-list &rest initargs))