freenode/#lisp - IRC Chatlog
Search
1:35:26
huonib
can someone help me with this? I am working on a project and I am looking to use a lisp that compiles to a small binary - either ecl, chez, or chicken scheme
1:35:42
huonib
right now I am trying this with ecl but I am getting an error: https://gist.github.com/huonib/9ddddc7998c43681795309233feeeb5c
1:38:21
Bike
wait, sorry, what is make-build? i don't have that function in my asdf and i don't see it in the manual.
1:38:52
huonib
Bike: found it here: https://common-lisp.net/project/ecl/static/manual/System-building.html#Compiling-with-ASDF
1:39:31
Bike
well, my guess is that when the program starts, *package* is something other than helloworld
1:43:01
huonib
when does the package change automatically? I thought slime did that for some reason.
1:48:22
Bike
yeah, no prob. i don't know how to use make-build, but you could probably set it in :prologue-code?
2:08:41
huonib
huh - I didn't have that much faith in ECL, since I heard nobody really uses it, but it generates a binary of 2.1 MB whereas chicken scheme is at 4.6 MB
2:12:11
huonib
Bike: I am a complete idiot, so bear with me, but chicken scheme can compile without the runtime - is that possible with ecl?
2:13:24
huonib
Bike: https://wiki.call-cc.org/generating%20the%20smallest%20possible,%20self-contained%20executable
2:15:09
Bike
the C standard uses the term 'freestanding' to mean implementations that almost entirely lack runtime support
2:17:02
Bike
i think there's an #ecl channel, and also jackdaniel comes around here and is a maintainer
10:00:19
luis
I've just noticed that SLIME's presentations weakly reference their respective object: they don't prevent the object from being GCed and if the object is GCed, the presentation is disabled (it turns into plain text). I'd never noticed this before. Is this how LispM/CLIM presentations work too?
10:01:08
loke[m]1
luis: that's not how they behaved in the past. I'm pretty sure I needed to C-x M-o to lose the references to them.
10:04:58
luis
loke[m]1: I was under that impression too, but *object-to-presentation-id* and *presentation-id-to-object* have been weak hash-tables for well over a decade and I don't think the REPL has ever stored them anywhere but * ** ** / // //. At some point (2006-ish?) SBCL didn't support weak hash-tables.
10:06:41
loke[m]1
luis: Perhaps the reference is held somewhere else. I just tried creating a large array, leaving it in a presentation and did a (gc :full t)
10:08:36
loke[m]1
The 5 evaluations of (gc :full t) should have been enough, but for good measure I did about 10 more evaluations of simple numbers followed by a few more gc's.
10:14:38
loke[m]1
luis: Well, I went to it and typed C-c C-v TAB. But yes, right-clicking also works.
10:20:38
no-defun-allowed
I remember copying the presentation to another buffer, and then doing some more stuff, including clearing output, then the presentation would stop working.
10:22:10
luis
no-defun-allowed: that's expected since clearing output clears presentations (or it tries to, I'm baffled by that particular bit of code too, but that's another story)
10:24:20
no-defun-allowed
CLIM presentations would strongly reference from memory, else they could not be ACCEPTed or used for gesture translation(?) later, and I don't recall reading that the implementation could allow ACCEPT to stop working for whatever reason.
10:24:30
luis
So, the test case is: evaluate the following forms in the slime-repl one by one: (make-array 10), 1, 2, 3, (gc :full t) then right click (or C-c C-v TAB) the array presentation. I get "object no longer recorded" but it works for loke[m]1 for some reason.
10:25:51
no-defun-allowed
Huh, it does in fact say "Object no longer recorded" in the right-click menu, and then it ceases to be clickable.
10:29:06
no-defun-allowed
It means to evaluate 1, then evaluate 2, then evaluate 3, in order to clear out the "history" variables.
10:31:08
rick-monster
in that case I can repro - C-c C-v TAB results in "Attempt to access unrecorded object (id 94)"
11:03:24
rick-monster
I'm dusting off an old music-control framework I wrote for lisp-on-linux and would like to discuss an aspect of the design.
11:03:36
rick-monster
the project is called 'serial hub' because it aggregates events from serial devices (eg midi, OSC, other usb music-controller peripherals). Currently each serial device or network socket has dedicated blocking thread to translate incoming serial data from a stream to lisp object. lisp objects from various sources are aggregated by sending them into a threadsafe channel (lisp library calispel). application layer simply re
11:05:38
rick-monster
thought for a while I should make the framework single-threaded. Rather than threads aggregate threadsafe channel, better to poll a group of file-descriptors in event-loop idle phase. I suspect this makes timing more deterministic when run on single-core linux.
11:10:38
rick-monster
1. will I run into horrible insurmountable problems with this file-descriptor-polling approach (sbcl/ccl for linux x86/ARM) when USB cable of a serial device is unexpectedly pulled?
11:11:22
rick-monster
2. is there a good existing lisp library which will handle the file-descriptor-polling part?
11:11:46
luis
rick-monster: if you're going to serialize event handling anyway polling a group of fds seems better, but nothing beats testing. iolib seems like a good candidate for that.
11:11:56
no-defun-allowed
There's an array of file descriptors and flags you pass, and one of those flags is to poll for errors.
11:16:43
rick-monster
no-defun-allowed: think I remember previously hitting a case where reading a now-unplugged USB-device file descriptor raises a signal which got mis-handled by sbcl causing a meltdown. Maybe this poll-for-errors is the trick I was missing
11:17:39
luis
rick-monster: that seems like a problem that would happen regardless of polling strategy.
11:19:47
rick-monster
luis, no-defun-allowed thanks for your input. think I need to approach the problem with a new mini-project which simply reads/writes a single serial device via iolib, but correctly detects and handles USB hotplugging