freenode/#lisp - IRC Chatlog
Search
8:39:58
shrdlu68
flip214: How did you solve the multithreading thing where different threads were writing to a stream?
8:41:19
flip214
I was stumbling about having :if-already-exists :append and did look at old data in that file.
8:57:53
jeosol
flip214: had similar problems with my parallel code, and used with (bt:with-lock-held ...)
9:17:54
MrMc
I am trying to use parenscript with the Chartist javascript library how do I get parenscript to emmit new Chartist.Line('.ct-chart', data);
9:20:17
MrMc
The challenge is that this is wrapped as a function returning new Chartist.Line('.ct-chart', data)
11:01:22
phoe
antoszka: I have no idea how postmodern works on the inside. Even if I use multiple threads in my code, they may block on a single connection for example.
11:02:10
antoszka
Well I'm sure you could easily find that out if you try (by even watching connections).
11:20:28
flip214
also, see https://www.quicklisp.org/beta/UNOFFICIAL/docs/postmodern/doc/postmodern.html#*max-pool-size*
11:41:52
flip214
I guess you should be using (with-connection (... :pooled-p T) body) and not ever set *DATABASE* at all.
11:43:35
flip214
phoe: and also be aware of potential problems if you (need to) give the database connection up, eg. because of multiple independent requests via hunchentoot
11:44:15
flip214
a SELECT FOR UPDATE will not work, because a) the old transaction might/will be aborted, and b) you might get assigned some other connection
13:44:21
schweers
is LAUNCH-PROGRAM a fairly recent addition to UIOP? I don’t have it on my machine.
13:44:42
schweers
As I’m running debian (read: ancient software) I suspect that I might need a newer version
13:47:52
schweers
so I don’t necessarily have to install a new version for the whole system, but can drop it somewhere where the installed asdf can find it?
13:48:27
svillemot
schweers: /usr/local/share/common-lisp/source should be the right system-wide path
13:49:53
shrdlu68
schweers: This may help: https://common-lisp.net/project/asdf/asdf/Replacing-your-implementation_0027s-ASDF.html#Replacing-your-implementation_0027s-ASDF
13:52:14
svillemot
my understanding is that schweers uses the ASDF from the Debian package, not from its implem, which is 3.1.7 in Debian "Stretch" 9
13:52:56
schweers
I’m not entirely sure whether asdf comes from the implementation (sbcl) or from debian. Is there a way to check which version is currently loaded?
13:53:22
schweers
It seems that the cl-asdf package from debian testing is new enough, maybe I’ll use that or build a newer sbcl from source
13:56:21
schweers
huh. I’ve installed the new version and I still get the old one in a new lisp image
14:34:24
schweers
It seems to me that the process dies in my program (where I do not care about the return value, other than the stream it contains)
14:39:02
schweers
I want to compress my output with bzip2. So instead of just opening the file (as I did until now), I create a bzip2 process. I give it as output the filename I previously opened directly and return the input stream, promptly forgetting the process-info value itself
14:39:36
schweers
flip214: my experiments on the REPL showed me that CLOSE on the input stream is sufficient, how is that wrong?
14:41:00
schweers
I get your point, but still: why do the processes seem to simply die? is it because the return value of launch-program is garbage collected?
14:42:26
flip214
schweers: do you call a shell with redirection, or pass the output filename to bzip2 as :output?
14:42:39
phoe
schweers: check all the output streams of bzip2, including stderr, for any data that might appear there.
14:45:32
schweers
seemed very dead to me. and simply using the bzip2 binary seemed to be the easier way
14:46:49
schweers
the thing is that I’m just working this into a somewhat complex program. so pasting the relevant bits isn’t really a straightforward process :/
14:52:27
schweers
is it possible that I’m not allowed to call LAUNCH-PROGRAM from a thread other than the main thread?
15:17:29
schweers
turns out that I am giving some wrong parameters in. I gave a broken pathname, gave :rename-and-delete (which is illegal), and :error-output t is also apparently illegal
15:19:50
flip214
ACTION waits for phoe to give a downward arrow, so that I can write something useful there
15:29:11
schweers
is there actually a good reason why sbcl does not properly work with pathname types like "tar.bz2"?
15:29:58
phoe
schweers: yes, there was one - when you have "foo.bar.baz" it has no idea whether the file "extension" is "bar.baz" or "baz"
15:31:32
rpg
schweers: this isn't really SBCL's fault -- the ANSI spec really isn't clear about how file types should be parsed, because it was written in a time of greater filesystem diversity than today.
15:31:42
phoe
(uiop:native-namestring (make-pathname :name "foo" :type "bar.baz")) ;=> "foo.bar.baz"
15:32:05
rpg
I am honestly a little surprised, though, that when you push a type in with MAKE-PATHNAME it doesn't do the right thing.
15:32:11
Xach
schweers: I suspect it is inherited from CMUCL, and the answer may be lost in the mists of time. or not!
15:32:59
phoe
rpg: the type is correctly set to be "tar.bz2" but NAMESTRING refuses to work with it.
15:34:11
flip214
The pathname #<PATHNAME ...> does not have a namestring because the :TYPE component contains a #\.
15:34:22
schweers
rpg: regarding your point that the standard doesn’t specify how to do this: I know that, but it seems like a language lawer move. It seems to me to be an insane way of handling this, but I might be wrong. Hence my question about the rationale for this way of doing things.
15:34:58
Xach
schweers: I think it is reasonable to say that the type is everything after the final "." and the name is everything before.
15:35:34
rpg
Xach: but surely if you actually push a value into type as in this case, NAMESTRING ought to report it back.
15:35:40
schweers
Does the standard require namestring parsing and printing to be a bijective relation?
15:36:20
Xach
rpg: if you parse-namestring you get a different object, and that's not what namestrings are for.
15:36:22
rpg
Xach: In that case, I think SBCL should raise an error in response to setting type in that way.
15:45:49
flip214
how about (CONCATENATE 'string filename ".tar.bz2") and avoid pathnames altogether?
15:46:37
Xach
If it were me, I would make a function that makes a new suffix like .bz2 by combining the existing name and type into the name and making the new suffix the type. There are many other options.
15:51:28
Shinmera
pathname-utils has functions to get the "real" type and name of a file, but nothing to push/pop types. Should probably add that.
15:51:30
Xach
ccl had an approach where the namestring had an escape character distinguishing where the name ended and the type began. i don't remember exactly how it was shown, but it meant you would see something like "foo\.tar.gz" or "foo>.tar.gz"
16:29:09
beach
jcowan: Maybe you missed it, but I told you that SICL and Clasp are very very different implementation.
16:39:39
beach
Yes. That part (Cleavir, the compiler framework) is working, and Clasp uses it for its main compiler.
16:40:56
beach
The first intermediate representation is AST. Then the AST is translated to HIR (High-level Intermediate Representation).
16:42:06
beach
HIR is pretty much a standard flow graph as in other compilers, except that only Common Lisp objects are manipulated by the instructions, so address calculations are not exposed at that level.
16:49:47
jcowan
But there is nothing wrong with the idea of writing a back end that outputs Scheme and invokes Scheme procedures that implement the primops.
16:50:29
jasom
jcowan: scheme isn't necessarily an optimal kernel language for CL, but it's certainly ported to everything.
16:50:43
beach
jcowan: Well, the entire compiler is written in Common Lisp, but if you don't mind having a Scheme compiler written in Common Lisp, then that's fine.
16:51:12
jcowan
It would be a Common Lisp compiler that generates Scheme (as opposed to C or C++ or LLVM), not a Scheme compiler.
16:51:57
beach
jcowan: Well, SICL has a similar backend already. It takes HIR and translates it into a very simple subset of Common Lisp.
16:51:58
jcowan
dlowe: Yes, but generating Scheme means you can use more capable Scheme systems than Guile
16:52:14
beach
jcowan: That way, I can execute SICL code inside a Common Lisp host, in this case SBCL.
16:53:52
jcowan
This is distinct from aeth's desire to have a Scheme compiler that generates Common Lisp.
16:56:49
phoe
...I just realized that if someone tried to make a Common Lisp successor and if they called it Uncommon Lisp, it would be pronounced like "uncle".
16:56:52
jcowan
Unfortunately aeth and I were discussing the two ideas at the same time, and I occasionally lost track
16:59:10
jcowan
Scheme has also been thought of an as an UNCOL (Universal Computer Oriented Language), or mechanism for translating between any two other computer languages
17:04:31
semz
rpg: Thanks for recommending CCL the other day. After a few hours of beating it with a stick it worked without any visible trouble.
17:14:32
semz
phoe: There were four problems. The first was the usual missing glibc-specific includes, <mcheck.h> and <fpucontrol.h>. Interestingly enough, fpucontrol.h didn't seem to be actually used anywhere.
17:15:05
semz
The second was a missing definition of struct _libc_xmm, or more accurately the fact that this struct has no name in musl. A somewhat ugly way to fix that was to define struct _libc_xmm in the same way in the source file
17:15:24
semz
The third was a glibc-specific function to get a version string which I just replaced with a placeholder
17:16:15
semz
Finally, the kernel would compile but segfault during relocation (do_relocs wrote to j_SPjmpsym which is readonly). This was fixed by disabling PIC though this might bite me later
17:16:43
jmercouris
I just assumed they made fasls and had a specialized "kernel" that could load their own fasls
17:17:11
phoe
we can compute everything computable by writing programs on punch cards or whatever, there's no point in making any other input device
17:17:37
jasom
jmercouris: they all have a runtime that implements things like GC, I/O and such, but when you compile a function it generates machine code that only assumes the existence of that runtime.
17:18:23
jmercouris
jasom: wow, it actually made asm on my screen with disassemble, very interesting
17:18:54
jasom
jmercouris: if you run a profiling run first than disassembly will also have instruction level profiling information
17:19:49
Bike
most compiled c programs do not run on bare metal either. there's no need for them to.
17:20:38
jasom
jmercouris: and when you save an image, it dumps all of ram to disk, including the compiled functions
17:21:01
Bike
do you know what a compiled c program looks like? you get an elf or a mach-o or whatever, which has code, and a bunch of other stuff
17:22:08
jmercouris
though I assume on embedded devices, for microlisp? ulisp? there is a way to make JUST the instructions that run the program, right?
17:23:13
jasom
sbcl does not currently have a working tree shaker (though there was a prototype one about 10 years ago)
17:23:54
jasom
This is odd because embedded devices now adays are much beefier than a mid-80s lisp machine.
17:24:46
dlowe
you have root objects that are always accessible. Those objects refer to other objects that must be kept live.
17:25:20
jasom
jmercouris: well actually it's a graph, but it's a directed graph with known roots. If you remove e.g. the common-lisp package from the roots, then any functions in common-lisp not referenced from your program will "fall out" of the tree. Hence a tree shaker
17:25:38
jasom
jmercouris: you have it backwards. All objects in CL are reachable from a set of root objects.
17:26:04
jasom
jmercouris: this is how garbage collectors work. any objects not reachable from the set of root objects are no longer in use, and thus freed.
17:26:52
jmercouris
okay, so there is no root object, but a set of root objects that all CL implementations implement?
17:27:23
dlowe
anyway, a tree shaker lets you specify, explicitly, which root objects you *actually* care about, and then prunes objects that don't have a reference to them.
17:28:31
jmercouris
let's not get into that, especially not when we begin talking about distributed systems
17:29:20
Bike
so as an example, in lispworks, you usually distribute images that don't include the compiler
17:29:30
jmercouris
okay, so let's say a given implementation, how do they decide what the root objects will be?
17:29:45
Bike
so the lispworks whatevermacallit shakes out the compiler functions and stuff that's dead if those aren't in.
17:30:34
jasom
jmercouris: everything reachable from the global environment. e.g. everything in all of the packages defined by the implementation (including, but not limited to the COMMON-LISP package)
17:31:02
specbot
The Global Environment: http://www.lispworks.com/reference/HyperSpec/Body/03_aaa.htm
17:31:35
jasom
For tree shaking, you just remove all of the non-user-defined packages from the root set, and then anything not used by user-defined packages is no longer reachable, and can be safely deleted.
17:31:52
dlowe
The after-tree-shaking image is not guaranteed to be a conforming implementation of CL. :)
17:31:55
jasom
It's actually somewhat trickier than that (the devil is always in the details), but that's the idea.
17:33:08
jmercouris
I have these nebulous images in my mind of the different components working together
17:33:13
jasom
if they try to convert strings to symbols at runtime (e.g. they are implementing an interpreter) it won't work right, but if you have an interpreter then you need the whole runtime anywas and shouldn't be using a tree-shaker.
17:34:04
jmercouris
does it free them from memory? is there some special process? is it tied to the implementation? is there a CL command?
17:34:43
jasom
jmercouris: It is not built into the standard, but almost all implementations provide it.
17:35:09
jasom
jmercouris: plus, most implementations usually run the GC implicitly before saving an image (Because it would be stupid to not to)
17:37:41
jasom
ECL with the boehm collector disabled would work; you can use free() to free the objects.
17:37:53
Bike
a system with manual memory management but without fixed addresses sounds pretty weird.