freenode/lisp - IRC Chatlog
Search
6:03:04
smokeink
setting file position on a stream of type SB-INT:FORM-TRACKING-STREAM i.e. by doing: (file-position stream 50) give this error: "#<SB-INT:FORM-TRACKING-STREAM for ... {DC08F051}> is not positionable" what's the proper way to set the position for such a stream, or is it impossible?
6:04:49
smokeink
I have some reader macros which set the position back into the stream, depending on the form they encounter when (read)ing
6:07:12
smokeink
they work fine, but sbcl's (load ) fails with that error when reading forms with such dispatching macro characters, because it uses SB-INT:FORM-TRACKING-STREAM instead of a normal stream
6:46:28
smokeink
I'll try repeated calls to (unread-char ) instead of (file-position ); it should work
7:12:17
emaczen
https://plaster.tymoon.eu/view/1646#1648 -- can anyone help with passing C structs via libffi via sb-alien?
7:57:02
pjb
smokeink: file-position only works on file-streams. That's why it's called FILE-position, and not STREAM-position or something…
7:57:55
pjb
smokeink: therefore your macro, to be able to "read" back, can only do it if it has saved the input in case of a non-file-stream.
7:58:07
aeth
I suppose if you need to unread e.g. three times, you could write your own buffer for read/unread. As in, even if the character is no longer in the stream, it can be in *your* buffer.
8:02:00
pjb
aeth: exactly. Have a look at the COM.INFORMATIMAGO.COMMON-LISP.CESARUM.PEEK-STREAM package.
11:18:06
smokeink
https://github.com/tokenrove/series/blob/master/s-code.lisp#L7434 <- isn't this a bug? if fn is not a symbol we can't do (function ,fn); if fn is a (lambda ()) , we can do (function ,fn) but there is no need
11:44:46
beach
smokeink: It looks like this function only takes names of functions as its second argument, not function objects.
11:52:24
smokeink
with that #M dispatch macro, instead of (MAP-FN 'T (COMPOSE #'1+ #'1+) (SCAN `(1 2))) , one can do (#M(compose #'1+ #'1+) (scan `(1 2))) - but compose won't work with the code as it's there, and it looks to me like it's just an unnecessary limitation ; it's not the only such crappy limitation ... "why should init be a function" https://www.reddit.com/r/lisp/comments/7rsfyn/testing_the_series_common_lisp_package/
13:04:41
beach
seok: Tell me how you would save a hash table as bytes in a file, and I'll tell you whether it is a good idea or not.
13:08:34
seok
I don't know, I have just remembered seeing some libraries before which lets you store CLOS objects as files. Imagined hashes would be simpler
13:21:13
p_l
some implementations have ways around it (I think there was low-level access in some to generate a FASL file containing specific lisp objects)
13:21:38
p_l
for CLOS, you have the advantage of Meta Object Protocol allowing easy implementation of serialization
13:29:15
p_l
seok: a pretty easy way would be to store the hash table as plist or alist, and use code like (with-open-file (*hashtable-file* "hashtable.file" :direction :read) (alexandria:plist-hash-table (read *hashtable-file*)))
13:29:40
beach
seok: Either way, these libraries will not store the object itself. There is always some transformation involved like serialization. That is why I told you that saving it as a Lisp object would be hard.
13:43:34
tfb
seok: there are only strings (well, sequences of bytes) on disk (at least in (almost all?) modern filesystems), so *something* is always doing that. It really depends on whether you have to do it or something does it for you.