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.
13:59:51
pjb
minion: memo for smokeink: there still a difference writing (function (lambda …)) instead of (lambda …). In the later case, the lambda macro will have to be expanded, and therefore *macroexpand-hook* will be called. In the former case, no such thing occurs. So there may be different side effects.
14:02:27
pjb
minion: memo for smokeink: there may also be a big difference if function is not cl:function. I note in this source that they use cl:defun, perhaps function is shadowed too. Check the package definition!
14:02:34
boeg
Is there a function in sly (or slime) thats like sldb-show-frame-source/sldb-show-source, but where it jumps to the place in my local source code where the bug in *my* code is so I can fix it?
14:04:17
p_l
it's even not the case that hashtables are blocking it, but lack of standard serialization for things like classes - because hashtables can accept anything as key so long as sxhash works on it
14:05:02
boeg
pjb: well, right now I introduced a bug where I use the wrong keyword parameter with make-instance, so when I run sldb-show-frame-source it jumps into the sbcl codebase where the code is run (i'm guessing), not into the place in my source code where i typed ":accessor" wrong. Does that make sense?
14:05:11
p_l
so it's easy to serialize a hashtable that uses a primitive type as keys (as most people think of hashtables), except common lisp hashtables (and actually hashtables in many other languages) support arbitrary keys
14:05:52
pjb
boeg: yep. In the sldb window you get a stack of frames, so you need to look down the first user function and type v to jump on it.
14:07:42
pjb
boeg: I guess you could write an emacs command to lookup for each frame if the source is in or outside some specific directory.
14:09:39
pjb
Serializing hash-table requires serializing the hash-table attributes, and then to initialize the deserialized table with them. It's feasible. At least we don't have the difficulty as with displaced arrays.
14:09:56
Odin-
p_l: Couldn't you define a serialisation for a hash table which barfs if printing readably and the key is bad?
14:12:51
pjb
I guess it's because of those additionnal attributes that there is no default printer/reader for hash-tables. Note that for arrays, the reader won't create arrays of the same types, or with fill pointers, or displaced, etc. The printer writes a projection. For a hash-table you would need at least :test otherwise the new table would be useless.
14:14:12
jmercouris
so, circular structures are only an issue during traversal right? so the problem is that we have to traverse the structure to persist it to disk?
14:19:03
dnaeon
hey all, what would be the idiomatic way to access nested alist values as returned by cl-json when using some nested JSON object? is there a library I'm missing, or should I just write my own function instead? This seems something that should already be provided by a library, but I haven't seen such.
14:19:51
dnaeon
currently I'm using my own util function, which simply REDUCEs the alist with the given key-path, but I was wondering whether there's such thing already?