freenode/#lisp - IRC Chatlog

16:47:18 atw I've got a question about http://metamodular.com/lispos.pdf, re the single memory abstraction. Does this mean that every time a program creates a cons cell or object, that thing is written in the slow, permanent secondary memory?

16:55:07 phoe not immediately I assume

16:55:36 atw hello phoe! I bought your book recently :)

16:55:53 phoe it gets written into RAM for sure, and I don't know what is the exact process of synchronizing data between RAM and non-volatile memory or what beach plans for this

16:55:58 phoe atw: thanks, hope it serves you well

17:02:20 atw I'm making a toy lisp system and I wanted something like (persist o) which causes o to be written to disk and evaluates to o. I was curious if CLOSOS took an explicit approach like this or if there's something more implicit that makes sense to do

18:07:19 Bike atw: don't quote me on this, but my impression was permanent storage is only done when a snapshot is taken, which may happen automatically but not at every moment

18:10:28 pjb atw: in addition to snapshots, there may be logs written (of changed pages). but this would be performed in an efficient background task that wouldn't impact much the system performance.

18:10:58 pjb atw: it worked like this on EROS and I found it was a nice feature. Unfortunately for some reasons, this feature wasn't kept for CoyotOS.

18:12:08 pjb atw: for a lispOS system you may also choose to have hardware to ensure persistence of the core memory. Either with a different core memory technology, or by using eg. batteries to keep the DRAM alive.

18:13:08 pjb atw: notice how systems such as macOS try very hard to give the user the impression of persistent core memory: when you crash and reboot, it can reopen all the open application and restore the state they were in (if the application implements the feature).e

18:13:33 pjb atw: this means that this is a good feature for the users, so there's no reason why it could't be implemented in hardware (with battery backed DRAM).

18:13:51 pjb atw: but of course, for that you need a system that wouldn't crash and destroy the DRAM contents…

18:15:04 pjb beach: ok. Then I didn't understand the aspect you didn't understand yet.

18:38:16 mister_m Is ``format'' the preferred way to join a list of items with a given separator?

18:38:48 mister_m without a package like ``cl-str''

18:39:09 phoe mister_m: I guess so

18:39:32 phoe (format nil "~{~A~^ ~}" things) is how I do it

18:39:43 phoe with space being the separator, that is

18:40:35 mister_m is using a library such as cl-str more typical for stuff like this?

18:41:05 phoe I guess it depends on the programmer in question

18:41:18 phoe I never used cl-str in my life, but mostly because I never needed it

18:41:26 phoe if you do more string processing then I guess it can be useful

18:42:43 mister_m fair enough

18:42:46 mister_m thanks

18:43:22 Josh_2 mister_m: I find cl-str very useful

18:44:25 Josh_2 I use str:split all the time

18:45:32 notzmv ** NICK Guest4205

18:48:15 mister_m It is nice not having to re-implement various things like that certainly. split-sequence seems pretty common as well for that usage too or cl-ppcre's split

19:01:52 Jachy I similarly like uiop:split-string because it's just there, but then some fraction of the time I also want to join and at that point might as well pull in cl-str...

19:13:50 remexre any reason why the reader wouldn't be able to find a package (sb-introspect) but find-symbol can find symbols from it at compiletime or runtime?

19:15:10 Xach remexre: case issues maybe. i can't think of anything else offhand but it would help to see the error or code or both.

19:17:29 remexre code is just (format t "~s~%" (sb-introspect:function-lambda-list #'foo)) vs (format t "~s~%" (funcall (find-symbol "FUNCTION-LAMBDA-LIST" "SB-INTROSPECT") #'foo))

19:17:52 Xach oh, sb-introspect isn't loaded yet, then.

19:17:57 remexre the former of which results in READ error during COMPILE-FILE: Package SB-INTROSPECT does not exist.

19:18:00 Xach easy enough

19:18:14 remexre oh, it's not loaded by default? I'd've assumed all the compiler builtin libs were

19:18:19 Xach no.

19:18:29 remexre ok, I should just be able to import-from it, right?

19:18:35 Xach after it's loaded, yes

19:18:52 Xach slime distorts the sense of what's loaded by default

19:18:56 Xach sb-posix isn't even loaded by default

19:20:01 remexre okay, looks like import-from works w/ package-inferred-system; thanks for the help!

19:24:07 atw thanks pjb, Bike :)

20:52:21 notzmv ** NICK Guest82031

21:44:51 npfaro hi lispers

21:45:04 npfaro what is the current status on windows builds of SBCL? it looks like it has been sitting at 2.0.0 for a while

21:45:09 npfaro is it possible to build from src on windows?

21:45:12 npfaro (the latest that is)

21:48:35 lotuseater npfaro: or you check out the version in here https://portacle.github.io/#get-win

21:48:58 lotuseater and to build newer sbcl you also need sbcl ^^

21:49:08 brandflake11 lotuseater: Haha, I was just looking there to see what the version was for npfaro

21:50:08 lotuseater hm i didn't see the sbcl version directly nor want to download :D

21:59:42 brandflake11 npfaro: Have you tried compiling sbcl? It's pretty easy to compile.

22:00:17 brandflake11 At least on Linux...

0:25:52 atw` ** NICK atw

1:26:11 notzmv- ** NICK notzmv

3:01:32 beach Good morning everyone!

3:04:37 beach atw: The CLOSOS specification calls for automatic persistence, so nothing explicit needs to be done. As with other persistent systems, it is handled by checkpointing. There is a chapter discussing the possible techniques.

3:21:39 pjb I'd favor batteries for DRAM…

3:23:11 beach pjb: Jim Goodman made the same observation when I told him about checkpointing.

3:23:14 pjb In laptop, this is already done to implement suspend mode.

3:23:30 pjb So we could just ask to have the feature also on desktops and servers.

3:23:48 beach I kind of agree, but you still need checkpointing, which became clear to me when I forgot to put my laptop on a charger one day.

3:24:09 pjb Usually it lasts more time. from one week to one month.

3:24:25 pjb But indeed, when the battery goes low, the laptop hibernates (saves the RAM to disk).

3:24:29 beach But with a battery, checkpointing can be greatly simplified I think.

3:24:37 pjb Definitely.

3:24:53 pjb And we avoid the risk of losing a few minutes or seconds of transactions.

3:25:19 beach That too. Also, we need to plan for persistent primary memory.

3:25:30 beach It shouldn't be far in the future now.

3:25:46 pjb The thing is that then we require a system that doesn't crash (damaging the memory contents).

3:26:57 pjb It looks like that we may have to integrate a computer platform eventually, specifically optimized for CLOSOS or lispos…

3:27:21 beach You mean adapt the hardware?

3:28:24 pjb I mean that some modification to some motherboard may be required, so we may have to negociate with a vendor, or design our own.

3:29:34 beach What I would like to se is a system like CLOSOS used in things like smartphones, in which case, the smartphone makers will do the adaptation.

3:29:46 beach *to see

3:29:49 pjb Other components are concerned too, such as disk controllers. You want to ensure that data stored in the disk controller buffers is stored to persistent media when a power off event occurs.

3:30:17 pjb beach: indeed, laptops, tablets and phones already have the required hardware.

3:30:41 beach Definitely! Disk caches inside disk modules can be evil.

3:32:57 beach pjb: And thanks for the link to DDR5.

3:41:47 beach I find myself having mixed reactions to all those "toy Lisp" projects we learn about regularly. On the one hand, I think they are great, because they are going to be a way for the creators to learn about Lisp, programming-language design, compiler techniques, etc. On the other hand, I think that they are a gigantic waste of time, because the time could be spent on maintenance of some existing real Common Lisp implementation.

3:53:44 jcowan returning "the same value" for setq must mean returning a value eql to the input.

3:54:27 jcowan as opposed to eq

3:55:31 pjb beach: existing implementation have to move in a specific direction; it may be difficult to experiment with them. Also, most implementations are not modular enough.

3:55:47 Bike "same" is defined in the glossary to mean eql. i don't think the description of setq uses the word though.

3:55:48 pjb since this exclude sicl, yes, more people should participate ;-)

3:56:28 pjb jcowan: it's not possible return values that are EQ, since immutable lisp objects can be copied willy-nilly and not be EQ anymore.

3:57:17 pjb jcowan: but there's still a difficulty. With SETF, we can mutate the place with a value that is different from the argument to SETF.

3:59:17 pjb jcowan: and SETF says: "results---the multiple values[2] returned by the storing form for the last place, …"; this is different than for SETQ. For example, we could write (setf (double x) 2) (assert (= 1 x)) I understand that this setf should return 1.

3:59:49 beach pjb: I guess you are right about existing implementations.

3:59:50 pjb (but it could be anything really, it depends on the storing form).

4:03:31 jcowan Scheme doesn't have this problem, because the setq and setf analogues return a single unspecified value

4:26:53 Bike i thought scheme didn't even have eq. shows what i know

4:44:16 beach Maybe we could persuade some of the creators of those "toy Lisps" to create the Bootstrap Common Lisp (BOCL) that I have been thinking about off and on.

4:46:07 beach I mean BOCL is itself a "toy Lisp" in that performance is not (supposed to be) an issue.