freenode/#lisp - IRC Chatlog
Search
13:31:23
huonib
does anyone know of a compiled, dynamic language that doesn't use a garbage collector? I think an academic one might exist, but I am not sure
13:31:41
huonib
I am unsure if being dynamic requires a garbage collector... and I cannot find anything making that claim online
13:35:43
jackdaniel
put in your init (ext::disable-gc) and there you go, common lisp doesn't use the garbage collector ;-)
13:36:29
Krystof
I seem to recall stories about Lisp Machines needing to be power-cycled because they really really believed in tenure
13:37:04
Xach
I recently learned that Allegro has an operation "panify" to ensure that certain objects never grow old
13:40:39
jcowan
huonib: GC is what you do to the heap, and Forth has no heap, only two stacks. (Which at that is better than Fortran II, which has neither heap nor stack.)
13:44:00
phantomics
Here's a question, not sure if this is completely off the wall ridiculous or not: how practical would it be to create a dialect or DSL within CL that runs code without GC? Meaning inside the code written in this DSL, you would have to manually manage memory and there would be functions for that
13:44:40
Bike
it would be difficult for objects in a managed space to refer to objects in an unmanaged space and vice versa. though it's possible. i mean, most implementations can handle foreign pointers.
13:45:19
Bike
but if an object in unmanaged space has a pointer to an object in managed space, and the collector tries to move things, problems will happen
13:45:59
phantomics
Yeah, if CFFI is possible I'd think something like this should be, I don't know if CLs have any functions that let you turn off GC for objects created within a particular block of code
13:49:09
Nilby
phantomics: When heavily using a C FFI objects you have to somewhat restrict yourself to such a dialect. Thank goodness for with- macros. There are also some foreign calls which necessitate turning off GC in some implementations.
13:52:34
Shinmera
And that's not even a joke. Allocate things once in a block, then manually recycle the objects. Presto, no GC.
13:53:11
Shinmera
You don't need a DSL or whatever for that, just a lot of restraint and a lot of annoying manual recycling, just when you manually malloc/free.
13:54:12
Bike
it might be nice if the compiler could help by flagging function calls that allocate, though.
13:54:53
Shinmera
But not even a DSL can help with that (you can't know what's going to allocate without help from the compiler)
13:57:40
Shinmera
One trick I've been making use of in Kandria recently is, since I know some things are going to run single-threaded, but I cannot stack-allocate certain complex objects, I can instead use load-time-value to create a local instance that'll be re-used. Certainly less handy and more dangerous than stack allocation, but it does the trick.
13:58:17
Bike
there have been a couple times when i've been like "i know, i'll do the l-t-v trick" and then remembered other threads exist. very sad
13:58:56
mfiano
Shinmera: Interesting. Can you link to one part of your code that does that? I'd like to see it in context.
13:59:49
phoe
what is the issue with l-t-v in a multithreaded context? race conditions, or also something else?
14:00:16
Shinmera
if two threads access the same function at the same time they'll use the same instance and thrash it
14:00:22
semz
Nilby, I recall something like that as well, but iirc it had a supremely ungoogleable name like CL- or something...
14:00:47
Shinmera
mfiano: https://gitea.tymoon.eu/shinmera/kandria/src/branch/master/toolkit.lisp#L335 and tvec/tv+ things.
14:01:32
Shinmera
mfiano: For hit I know the object is not going to escape or be cached, so I can avoid allocating more than one instance.
14:02:16
Shinmera
I could potentially stack-allocate the vecs, but as 3d-vectors is set up it can't do that most of the time.
14:03:34
mfiano
AH I have recently start stack-allocating some vectors in my collision detection codes, and some lexical variables cannot be stack allocated because they call c2mop:s-i-a or something. Was trying to figure out what I could do about it
14:05:41
mfiano
But I did make it more manageable. I had a OBB struct with like 20 slots, mostly all for mutating temp variables. It was a mess lol. Now there's only 5, with 2 of them being an unfortunate temp variable
14:10:27
semz
Turns out I was thinking of CL_1 as defined by CLICC, but that does seem to have a GC, so probably a different project.
14:15:33
beach
I define "dynamic language" as one with semantics defined by a suite of interactions.
14:29:10
phoe
convert your string into a byte array, append the string's length to it, convert the result into an integer
14:32:22
phoe
my UX instincts are telling me that modes should provide some sort of taskbar-like icon that can then be displayed, but that's orthogonal to your issue
14:33:07
phoe
that's not really a #lisp question I think :D you can try to use the first letter of the mode, or something
14:33:22
jmercouris
well it is a #lisp question in the sense that I want to go from string -> unique glyph
14:38:14
phoe
and, honestly, I think that providing icons and falling back to first letters of each mode name is going to be much better than generating tiny semirandom icons that users will need to memorize anyway before being able to use them well enough
14:45:46
jackdaniel
some random mcclim hackery show off: http://turtleware.eu/static/paste/3337104a-showoff.webm
14:46:09
jackdaniel
what you see there is a normal clim application run in the browser (the hunchentoot acceptor is also a frame manager)
14:58:55
Josh_2
I have dumped my lisp image and I'm now connecting to it using sly-connect. How do I get all the output to go through my connected repl instead of into the terminal that I started the image in?
15:06:17
jmercouris
Josh_2: i don’t believe you can, when you start sly the *inferior lisp* buffer is always pushing some messages
15:06:35
jmercouris
I think the problem is in the case of CFFI that is writing to stdout for example
15:10:01
jackdaniel
even when you start your lisp from emacs other processes that write to stdout will still write to stdout
15:38:03
phoe
Bike: regarding the l-t-v trick, l-t-v CLHS page states that the object is treated as a literal; doesn't mutating it invoke UB then?
15:42:22
Shinmera
It sure does, but there's no incentive for it to not just work the way you expect it to.
15:43:19
mfiano
I think we all know we can't assume programmers to make sound decisions all the time. I can't guarantee an implementation won't be doing something funky, or my current implementation some time in the future.
15:44:41
phoe
I guess an implementation could go ahead and define that behavior as possible and useful, then
15:46:50
Nilby
But there's an incentive as an implementation developer to have popular software run on your implementation.
15:46:52
mfiano
Might want to wrap that pattern up in a macro just to have a search point and a single place for a big comment.
15:46:56
_death
if I understand it correctly, the compiler treats it as a literal object, but it's still modifiable by the user, as long as read-only is nil, as the preceding paragraph says
15:48:26
phoe
yes, I can see that it is being confusing; generally, "modifiable data" and "literal object" should be disjoint sets
15:51:20
_death
literal here means it's "referenced directly in a program rather than being computed by the program".. I think it means the form is only evaluated once
15:55:01
Shinmera
My favourite lisp aesthetic is being fast in the face of adversity. This includes having unmodifiable things at times.
15:59:15
Nilby
If it doesn't exist because it's optimized away, or it's existence is temporary, sure, but if you break in the debugger at the just right place, it's modifiable. I can accept things intentionally protected by memory barriers and such. It's also happens to be the aesthetic of assembly code.
16:05:51
pjb
Nilby: it is not necessary. Non-controlled systems want to put the code in read-only memory to avoid exploits. Controlled systems want to prevent write access (and sometimes even read-access) to the code to ensure control and security. And in lisp we can always modify the source sexp and recompile.
16:06:30
epony
https://en.wikipedia.org/wiki/Return-oriented_programming challenges that Apr06 1559<pjb> Shinmera: in general, compiled code is immutable.
16:07:16
pjb
epony: of course, there are nice hacks possible when you can modify the code. Also, instruction caches want to avoid it.
16:08:31
pjb
jmercouris: note: you could perhaps use :default-initargs to avoid having to redefine the slot in the subclass?
16:18:42
Nilby
pjb: Yes, I agree it's not necessary, but still useful. I think it's basically game over for security if something can control Lisp code, but in some way beach's idea of top level first class environments is like having virtual lisp machines. I would like to think it could include hardware level protection, so that memory address and compiled code could still be safely modifiable.