freenode/lisp - IRC Chatlog
Search
18:49:28
benjamindc
Does anyone know of a good tutorial the describes up-to-date best practices for Lisp project organization and build processes?
19:10:54
loli
is there any literature on how to write an image based system, akin to Common lisp or those forth/smalltalk systems?
19:15:28
phoe
the basic idea of the Roots of Lisp interpreter is the same idea that stands behind all image-based systems
19:15:38
dlowe
a lot of "scripting languages" are also image based systems, so I'm not sure why people acts it's so crazy when lisp does it
19:16:51
loli
can those systems save the current image, then resume on a ceratin function afterwords? I'm curious on how the format of that is, thanks for the suggestion
19:16:55
no-defun-allowed
They're just tedious to use interactively; I can't break into a REPL in a Python program too easily.
19:17:28
loli
well I'm curious if that kind of detail is noted anywhere, as when I searched for papers on the subject it came up baren
19:17:33
phoe
most Lisp implementations dump their in-memory data structures somewhere and then restore those when the image is reloaded
19:17:41
no-defun-allowed
And one does not have update-instance-for-redefined class, so one is limited in what they can change while live.
19:18:05
phoe
the simplest idea ever is to record all commands that were issued to the image from its start to its freezing and then replay them when the image is thawed
19:19:20
phoe
I mean, if in theory you do (defun foo () 42) (defun bar () (foo)) (dump-image "foo.image") then all that is required for the dumped image to become equivalent is to reexecute (defun foo () 42) (defun bar () (foo))
19:19:43
phoe
obviously this won't work in case of filesystem interaction or other side effects, but it's a simple idea that will work for toy interpreters
19:20:07
no-defun-allowed
Some Smalltalk implementations do that, and export a changelog pretty much like that one.
19:26:25
loli
I've made a fair few interpreters in my day, I guess the saving the memory to disk in a format that is very quick to reload is what alludes me
19:27:07
no-defun-allowed
I can't remember if they also dump an image now, but in some cases, they don't touch the filesystem at any other time.
19:29:22
phoe
https://github.com/phoe-trash/ccl/blob/0aa5b5d209f288ee04157c60624dea5f79787c16/xdump/faslenv.lisp
19:30:06
phoe
DEFINE-FASL-OPERATIONS contains a declarative list of all FASL commands permitted in a CCL FASL file
19:33:17
loli
thanks for the links, I'll spend some time studying them, and hopefully have a better idea how to make a nice image environment
19:35:05
no-defun-allowed
Wouldn't code have to be position-independent, or installable at an arbitrary location given to you?
19:37:58
phoe
but e.g. if all of your code is interpreted then your code is actually data, and dumping data is easier
19:39:22
phoe
then your compiled code needs to take this into account - code must be reloadable like this
19:47:53
benjamin`
oh i did come across that, but it hasn't been touched in 4 years, save for an edit to the README
19:57:30
phoe
e.g. https://github.com/rtoy/cmucl/commit/932884a4b406572614a9830bf864738a0c3a5700.patch has his mail
20:32:21
dbotton
Is there any document that describes the interaction between threads and condition handlers? dynamic variables?
20:34:23
no-defun-allowed
Those are usually implemented with dynamic variables, and dynamic variables are also thread-local. What phoe said.
20:34:46
Bike
i don't see condition handlers or other parts of the dynamic environment mentioned in bordeaux-threads's docs, at a glance
20:35:51
no-defun-allowed
You probably should use mailboxes for message passing (eg safe-queue provides those).
20:44:04
aeth
multithreading is still an underexplored frontier in most languages and CL is no exception (or is that "condition"?) here
20:44:56
phoe
well, in CL every thread has its own handlers since every thread has its own dynamic environment
20:45:11
phoe
passing condition objects around threads is possible since they're Lisp data like any other
20:45:29
phoe
it's just that stack information is not passable so easily because it's strictly thread-local unlike condition objects
20:50:41
dbotton
I wouldn't say most languages. The idea Bike is to say to have a thread block until receives a signal etc
20:51:17
aeth
dbotton: re "most"... by quantity, I wouldn't be surprised if most languages don't even have "real" (non-green) threads yet.
20:55:27
sm2n
dbotton, I don't really see what would stop you from writing your own scheduler that could do that though
20:58:42
dbotton
sm2n, I am actually thinking about copying some of the Ada concurrency abstractions as an exercise
20:58:57
_death
so, I've decided to archive the old Road to Lisp Survey submissions that were hosted on ALU wiki on github.. https://github.com/death/road-to-lisp hopefully none of those listed minds...
21:03:29
dbotton
aeth maybe I am missing it, but the use of non-green threads is going to be more of the implementation or os then the language
21:12:31
Bike
how's that? i googled up https://oberoncore.ru/_media/wiki/lang/reali_p.active_oberon_language_report.en.pdf but it's a different sense of the word
21:14:18
no-defun-allowed
There are "condition variables" which are synchronisation primitives, but not related to the condition system.
21:14:54
Bike
i mean, the wikipedia article does make it sound like lisp type conditions, but there's no detailed information
21:16:53
aeth
dbotton: most languages are single-implementation or single-dominant-implementation languages, so it's doubtful that they have something like bordeaux-threads if the dominant implementation doesn't have the need for it yet.
21:20:17
dbotton
at least tasks, protected types etc like Ada or perhaps something like the model of active oberon (I wish I could say have experience with it but do not but I like the idea)
22:17:13
sm2n
dbotton_, CL does have some high level concurrency abstractions, for example lparallel
23:56:22
aeth
it's too big to fit in github, but you can click on, say, 1am, and then manually rename the URL
23:56:33
aeth
e.g. replace "1am" with the project you want in https://github.com/quicklisp/quicklisp-projects/tree/master/projects/1am
1:40:54
dbotton_
is the convention to only on global vars or also in locally declared special vars too?
1:44:20
aeth
and most of the "occasionally seen" stuff are probably just in one project (one even says Macsyma)
1:49:53
aeth
you can violate a few of the archaic rules. No one will complain if you use define-foo instead of deffoo or defoo. It's even in the standard, with define-condition
1:51:07
aeth
you're far more likely to see the actual type instead of foo&/foo$ if you're writing numerical code... especially since you basically gain nothing for having a "foo, operating on floats" since if you don't specify single-float or double-float, you're probably just going to get the generic + anyway
1:52:10
_death
aeth: gbbopen uses foo$ to mean single-float.. there's also foo$&/foo$$/foo$$$ for the others
1:54:38
_death
aeth: https://old.reddit.com/r/Common_Lisp/comments/g0muke/gbbopen_highperformance_blackboardsystem_framework/fnawmns/ has more info on blackboard systems
1:55:36
_death
anyway, it's not that important.. I would say +foo+ is widely used, but not universally used.. e.g., CL does not use it (and neither do I, for some years now)
1:56:34
borei
can somebody gimme heads-up - is it possible to find out size of the basic types - single-float, double-float, integer, etc.
2:03:23
aeth
_death: idk, +foo+ seems like one of the most universally used conventions, excluding CL's built-ins... since if you don't, it's reserved. You're not allowed to (let ((most-positive-fixnum 42)) most-positive-fixnum)
2:03:25
no-defun-allowed
A Common Lisp program isn't concerned with the size of objects in memory, so it'd be very implementation dependent.
2:03:54
aeth
_death: I know that the current standard discourages USE in DEFPACKAGE outside of CL, but anything that doesn't +foo+ its constants is unUSEable
2:06:38
aeth
borei: the size of a fixnum is probably (log (- most-positive-fixnum most-negative-fixnum) 2) bits
2:06:54
_death
aeth: if you want your package to be USEable, you use names that assume less context..
2:08:50
aeth
(if it's larger than a fixnum it might be a bignum at the ends of that specified interval, but not necessarily... SBCL optimizes (unsigned-byte 64) and (signed-byte 64) in some circumstances)
2:08:52
_death
aeth: for example you would use (defconstant ebac-swedish-standards-factor 1.2) rather than (defconstant factor 1.2)
2:14:20
no-defun-allowed
Well, a fixnum on most implementations doesn't allocate anything on the heap. But there is the one word that every object occupies.
2:15:36
aeth
if it actually exists, it will probably be 63 bits with a tag bit... or more generally (log (- most-positive-fixnum most-negative-fixnum) 2) bits with the rest of the 64 (or 32 or whatever) bits as a tag bit, since most don't optimize fixnums to the point of giving them 63 bits.
2:16:14
aeth
But, yes, it can be smaller if the compiler has enough information. If everything's (unsigned-byte 32) and stays (unsigned-byte 32) it might just be able to do more if the instruction set lets it. Also, e.g. bit.
2:17:12
Nilby
Or it, in memory, could be bigger than the amount of bits needed to represent it, for example if it is GC'd and turned into a forwarding pointer.
2:18:54
aeth
Even if there was a SIZEOF it would probably have to pretend to be a fixnum (e.g. 63 bits in SBCL) even if it's actually smaller...
2:22:22
dbotton
I find this interesting Dynamic binding was actually a bug in McCarthy's lisp 1.0 and then became a feature ever since
2:26:52
Nilby
I think calling dynamic binding a bug is a little exaggeration. I think it's just easier to implement. Perhaps lexical binding is more a 2.0 feature.
2:28:23
aeth
technically, M-expressions were the big 2.0 feature. https://en.wikipedia.org/wiki/LISP_2
2:28:31
Nilby
especially when the first version was by hand in assembly, translated from the lisp implementation on paper
2:38:11
Bike
C sizeof exists because C defines that objects can be treated as arrays of bytes (or chars, or whatever it is), and sizeof returns the size of that
2:38:54
Bike
implementations of Lisp and C can use other representations internally. adding up the sizes of C objects won't accurate reflect memory usage in a C program because the allocator has its own overhead, etc