freenode/#clasp - IRC Chatlog
Search
8:51:30
robink
jackdaniel: I *think* it (Clojure( tries to minimize duplication (it likes persistent data structures like any LISP), so you might have a redundant head of an indexed sequence, but then the rest is pointing at the remainder of the array.
8:52:15
robink
jackdaniel: I don't *think* it copies the vector wholesale, anyway, if it doesn't have to (there may be some situations in which it doesn't need to but does because linking in to part of it is too much effort somehow)
8:52:19
jackdaniel
robink: usually Common Lisp is simply referred as Lisp or CL (no capitalized LISP which is a dialect from early '60)
8:52:47
jackdaniel
regarding vectors: displaced array is exactly that: not a copy, but a new object which is displaced on existing array
8:52:55
robink
I sort of assumed LISP referred to the family descended from the original dialect as well.
8:54:03
robink
jackdaniel: There may be some extra hackery thrown in there, but the general idea (& promise to those who haven't looked under the hood, like myself) is that even non-literal-list data structures will be kept as persistent as is feasable (more-or-less)
8:56:32
jackdaniel
I'm afraid he could give me much more detailed explanation than what I want to know, so maybe it is for the best he isn't ;-)
16:30:08
Bike
so how can we improve error handling with compile-file-paralllel. also maybe clean it up, there's weird things in the file
16:59:13
kpoeck
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/compile-file-parallel.lsp#L184
17:27:00
kpoeck
I wonder whether we need to catch errors from compile-from-ast and throw them in the main process
17:29:04
Bike
as it happens now, you get an error, and then you get another error about a missing file.
17:32:25
drmeister
We should push any errors discovered in threads running compile-from-ast into the ast-job object that is unique to each thread and then pull them out in the main thread once they are all joined up.
17:34:01
drmeister
Also - there appears to be some lock contention between the compile-from-ast threads and the main thread - I haven't tracked it down yet.
17:34:41
kpoeck
So this definition: https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/compile-file-parallel.lsp#L52
17:37:22
kpoeck
but if here https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/compile-file-parallel.lsp#L58 we put a handler-case to store the errors in the ast-job
17:38:24
kpoeck
than probably the stack is long gone when we in https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/compile-file-parallel.lsp#L186 we could rethrow the errors
17:53:23
drmeister
kpoeck_: Yes - the ast-job needs a slot to store errors . https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/compile-file-parallel.lsp#L52
17:55:04
drmeister
I didn't think there would be any errors in compile-from-ast. Do you know what errors we will see? I've lost the thread of this issue.
18:03:50
drmeister
Hi robink - could you give me a quick rundown on what you are trying to build and on what? Linux/gentoo - right? Clasp dev branch - right?
18:05:25
robink
drmeister: Yes and yes. Here's a link to the current ebuild: https://github.com/Haifen/robinkverlay/blob/master/dev-lisp/clasp/clasp-9999.ebuild
18:08:48
robink
drmeister: It's a set of build rules (nominally written in Bash) for compiling/installing a package on a Gentoo system (Gentoo is by-and-large source-based).
18:10:17
robink
drmeister: Portage (Gentoo's package management system) at its core is a hodgepodge of Bash and Python (with a dash of native-compiled C thrown in), but everything is exposed to people writing the ebuilds via Bash function hooks.
18:14:59
robink
drmeister: Compile process seems to get stuck (runs for 6 hours, entire compile normally takes less than 4 doing it 'by hand') when at the point of 'Loading/compiling source: /var/tmp/portage/dev-lisp/clasp-9999/work/clasp-9999/src/lisp/kernel/cleavir/inline.lisp' in '[195/199] compile_cclasp'.
18:16:08
drmeister
I don't understand why it would be hanging in 'inline.lisp' - we haven't had a hang in there for months.
18:16:49
robink
drmeister: I don't know either, especially since it gets through that file without error when compiling with what should be (but clearly isn't) an identical process.
18:17:47
robink
drmeister: Not at present, unfortunately. I haven't run Debian in years, and I need to bring my MacBook Pro back to life (most likely some solder joints on the CPU BGA have come loose).
18:19:08
robink
drmeister: Again, it builds successfully when I'm not compiling from an ebuild. Granted, that makes this more of a Portage problem (and, perhaps, not something to complain about in #clasp), but I can compile it one way, and not another, and the two are *supposed* to be similar enough to be functionally identical.
18:20:37
drmeister
So it builds from the command line but not Portage. Sorry if I am repeating my questions.
18:22:36
robink
drmeister: ...could be that the build process wants to read/write to/from some bit of the filesystem that Portage regards as verboten.
18:22:42
drmeister
Here's an idea. What if you run 'strace <path-to-iclasp-boehm>/iclasp-boehm -t b' from your command line and within Portage (however you can do that) and then compare the libraries being loaded.
18:23:19
drmeister
If you could identify differences OR demonstrate that there are no differences - then we might learn something that we don't know right now.
18:23:26
robink
drmeister: Sure, I'd have to rework the ebuild and build up iclasp-boehm from within Portage, but that's doable.
18:24:15
robink
drmeister: I'll also increase the verbosity of Portage's sandbox reporting feature (it's possible to have it log what it thinks are sandbox violations, but not actually enforce sandbox policy).
18:25:36
drmeister
strace might also give clues about what clasp is trying to read/write to/from that Portage may be disallowing. I dunno.
18:26:54
robink
drmeister: It well could (it certainly would provide a bit of extra verbosity). I'm mostly harping on the Portage sandbox because 9 times out of 10 when I've had this kind of problem with an ebuild (builds from commandline, not from Portage's build environment) there's been a sandbox hangup.
18:28:21
robink
drmeister: but since the Clasp build process isn't complaining bitterly if and/or when that happens, seeing what's happening with strace might shed some light.
18:33:56
drmeister
A gdb backtrace of the hung process would also be helpful - but it may be deep in the cleavir compiler.
18:34:47
drmeister
The main special thing about inline.lisp is that is when the cleavir compiler first activates. But it doesn't do any special file access as far as I know.
18:34:53
robink
drmeister: OK. Are there any DEBUG_OPTIONS I should leave on, then? Right now I'm turning everything but DEBUG_CCLASP_LISP off.
18:35:33
drmeister
No - I think DEBUG_CCLASP_LISP is now obsolete (as of a few weeks ago) I haven't gotten around to cleaning it out.
18:36:15
drmeister
I completely rewrote the way lisp backtraces are generated in the last months. It doesn't depend on that flag.
18:36:55
robink
drmeister: Gotcha. I assume, then, that the build process generates debugging symbols even with DEBUG_CCLASP_LISP turned off?
18:37:52
robink
(I also assume that if that's the case, "normal operation" implies running a binary with the debugging symbols still linked into the executable/fasl-image)
18:39:54
drmeister
Another recommendation is remove DEBUG_JIT_LOG_SYMBOLS from your DEBUG_OPTIONS in your wscript.config file - when it's defined it creates a file in /tmp/ Maybe that's causing a problem.
18:40:15
drmeister
But if it was it should have shown up right when clasp starts up - so I'm downgrading that concern.
18:40:25
robink
drmeister: It's not presently defined (it's not in the .template), so I'm assuming it's switched off.
18:44:34
robink
OK, the ebuild has been updated, once I have a commandline-compiled Clasp I'll start the process of compiling iclasp-boehm from Portage so I can test it out w/ strace & compare.
18:54:39
robink
Well, it's hard to argue that anything is definitely 'superior', but to me it strikes a nice balance of ease-of-use and source-based control of package installation.
18:56:00
jackdaniel
I'll take my chances with guixsd soon because I like parens in my system definitions :-)
18:57:09
robink
jackdaniel: I actually think a Lisp-y source-based package management system is better than what Gentoo is doing, but I invested enough time (and early-learning-curve pain) familiarizing myself with Gentoo that it's hard to leave.
19:02:03
robink
jackdaniel: but Python is OK, and since it has __iter__/__next__ (and generators) as language primitives, I can pretend it has Lambda Nature.
19:03:46
drmeister
Python is great for certain things - we use waf (Python) and we've been using buildbot (also Python) - they are great.
19:08:33
robink
stassats: I'm actually a fan of Clojure (not so much of the Java runtime, though (I've joked that Clojure is the 10-foot-pole that I'll touch the JRE with)).
19:10:21
robink
stassats: That said, I hold no delusions about it being the World's Greatest Lisp, but it is *a* Lisp that's easy to get up-and-running.
19:10:44
drmeister
ACTION and any conversation about Python https://www.youtube.com/watch?v=lPXXuGJ5H08
19:48:25
drmeister
Can I get back to you in a bit? I've got a bunch of broken stuff on my end - no working clasp at the moment.
20:46:29
Bike
drmeister: in the load time value machine code, does the "reader" template function referred to actually exist somewhere?