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?
14:23:57
beach
jmercouris: There is no problem what so ever in serializing a hash table to disk. The circularity "problem" can be solved with another hash table. But there is no standard way of doing it.
14:24:02
beach
jmercouris: Also, seok seems to think that the object itself can be saved to disk, but there is always going to be some conversion to an external representation.
14:25:09
jmercouris
beach: oh I see, what if you took the contents into ram and literally piped them onto a disk
14:25:55
beach
jmercouris: Yes, and then the GC moves the objects so that their addresses no longer correspond to what you wrote on disk.
14:27:15
beach
jmercouris: You would need an operating system in which RAM is just a cache for secondary memory for it to work. Like CLOSOS for instance.
14:28:51
jmercouris
beach: what if we just dumped the lisp image, couldn't that be effectively persisting the hash table?
14:31:53
p_l
there was an extension to SBCL that allowed dumping partial images, so long as the image that loaded the resulting file was the same image that generated it
14:32:30
p_l
it essentially allowed you to do a dump of memory region and then reload it, but it did none of the stuff that FASLs do for relocation et al, so you had to use the same base image
14:41:42
flip214
I've got a (make-hash-table :test #'equalp); is there a way to get structures or class instances recognized as (equal) keys?
14:42:05
flip214
I guess that for structures :TYPE vector or :TYPE list might achieve that, but that has a few disadvantages...
14:45:06
pjb
flip214: all objects can be compares with eql equal or equalp, so there's no way to say this object can only be compared with equal.
14:47:05
Posterdati
please I'd like to submit some fixes for cffi and iolib for OpenBSD, is there anyone who can help me? Thanks
14:47:06
flip214
pjb: but "equality" (however defined) isn't recognized by default, unless they're EQ
14:49:55
flip214
perhaps the easiest way is to not use structures or classes but lists starting with some symbol
14:51:56
pjb
flip214: the point is that it may be meaningful to use either test function on whatever type of keys you have.