freenode/#lisp - IRC Chatlog
Search
5:29:13
antoszka
whoever runs the lispjobs.wordpress.com blog please add https://www.accenture.com/fi-en/careers/jobdetails?id=00479172_en :)
6:48:21
knobo
I'm just beginning to look in to it. some of the images grows to more than 400Mb of resident memory
9:28:06
jackdaniel
was there any take in to create a virtual filesystem for CL (with virtual pathnames), so one could have bundled resources yet treat them as files? #P"virtual:images;foo.bmp"
9:30:11
jackdaniel
such file could be baked by a vector for instance or by a function which produces data
9:32:51
jackdaniel
I believe it would need implementation support and can't be implemented as a library
9:34:55
phoe
the implementation's file access primitives would need to be updated to support such a virtual filesystem
9:35:54
phoe
what can be done, though, is implementing this as a library in portable CL that does *not* use these file-based primitives
9:36:51
phoe
this way, implementors will have an easy way of using this new implementation of the filesystem.
9:37:33
jackdaniel
phoe: that's called gray streams. I'm talking about plugging new kind of files into already existing systems, so they "just work"
9:38:05
phoe
jackdaniel: not only gray streams. you need to provide a lot of functions that also deal with directory structure, file existence, etc..
9:38:42
whoman
that sounds like a lot of work. what about using an existing virtual filesystem like in-memory..?
9:38:43
phoe
and I already said it - you need to modify the Lisp implementation file-accessing primitives, so they know how to handle this "new kind of files".
9:39:17
phoe
whoman: then you need to create this filesystem outside of Lisp, which might not be possible on some platforms.
9:39:31
jackdaniel
modifying them isn't much bigger issue than proposing new interface for everyone to use, but gain is bigger
9:40:33
jackdaniel
what do you mean "how?" - implementations have extensions, writing new one isn't a technical problem, more a question whenever other implementation will adapt such thing
9:41:20
jackdaniel
but it's easier to convince limited number of implementers to add extension than to convince limitless number of users to *always* use your new api
9:41:58
phoe
you export the API from your virtual extension module so the implementors can hook into it.
9:42:19
phoe
the users are not really meant to use it directly, except for maybe telling the Lisp image that they want to use the virtual filesystem and how they want to use it.
9:42:27
phoe
the rest is hidden in the http://www.lispworks.com/documentation/HyperSpec/Body/c_files.htm functions.
9:43:29
whoman
does it need to be complicated? honestly i would bundle resources by turning binary into lisp forms and then reference them in a named tree structure like alist or plis
9:43:40
phoe
but now that I think of it, the "how they want to use it" part can be abstracted away either. pathnames, anyone?
9:44:36
jackdaniel
phoe: I think you bring more confusion here with your hyped ideas. I'm asking about feasibility and whenever there is some work already done in that direction
9:45:37
phoe
I'm just describing a module implementing a virtual filesystem, written in portable Common Lisp, that can be then used by implementors to plug it into their CL systems.
9:45:41
jackdaniel
you start to talk about libraries, portable cl, propose pathnames, interfaces, primitives, hooks - various implementation details
9:47:16
jackdaniel
sadly someone who might have heard of it won't see the question due to high noise/signal ratio ;-) see you later
10:07:52
pjb
phoe: it's a pure CL (no Gray Stream) implementation of the I/O system, storing files and directories in memory (hash-tables, vectors).
10:08:37
pjb
Nowadays, I know Gray Streams, and I would probably use them for this, since it would be much more practical (both for the implementer and for the user of vfs).
10:09:37
pjb
jackdaniel: the virtual pathnames are implemented IIRC. You would just need to hook the I/O stuff onto a Gray Stream, and it would work in a day or too, I guess.
10:10:47
pjb
Then, there are COPY-FILE functions, you would need perhaps a COPY-DIRECTORY function, and you could load resources from the external file system to the VFS easily. Don't forget to save your image ;-)
10:20:35
jackdaniel
in ECL it would have native implementation (performance reasons), I'm mostly interested in API
10:27:18
pjb
Take it from git: https://framagit.org/com-informatimago/com-informatimago/tree/master/future/vfs
10:28:49
pjb
Never heard of anything else like this. Well, there are flexi-streams to read and write binary streams to vectors. That's all.
10:31:03
pjb
If you want to add a VFS to an implementation, it'll be easier since you already have the implementation I/O infrastructure to hook into.
10:40:19
pjb
Yes, you need to define a file system with it's own API (you could also use a POSIX-like API if you wanted).
10:42:03
pjb
I don't remember if FUSE existed when I worked on this VFS, but it would definitely be a good idea to study it.
10:43:12
jackdaniel
we also have a library cl-fuse (I think that's the name), I'll see what API it proposes
10:44:28
pjb
Also, I remember somebody worked on a FUSE file system implemented in CL that gave access to the CL package from the linux command line (it would map CL functions to unix commands in the FUSE VFS).
15:23:39
JuanDaugherty
i assume it's just equivocation of "distributed control problem" with "distributed system framework" as the latter would make sense with the other stuff on that page
16:44:23
azrazalea
So i'm slowly inducting a co-worker into Common Lisp via evangelism. I mentioned the idea that functions (libraries and standard) tend to return useful things that might be useful unlike some other languages where the same function might return nothing or a boolean. However, for the life of me i'm brain farting on examples to link to. Can someone help me out?
16:47:37
Bike
i'm not sure what you mean. functions return things in most languages, that's why they're called "functions" rather than "subroutines"
16:48:19
azrazalea
Bike: Well, i'm getting the idea from one of the beginner books I read years ago. Either practical common lisp or another
16:50:08
azrazalea
Basically in the author's opinion Common lisp programmers tend to return things instead of just writing "void" functions which is common in many other languages. I think part of that is the combination of implicit return and considering most things truthy though
16:51:05
Bike
cl functions can return multiple values and signal errors, so the C pattern of passing in a pointer to get its value mutated while the function itself returns a boolean is right out
16:51:43
pjb
and furthermore, CL functions can return multiple values, so again, it's not usual to mutate the arguments (unless you're doing OO).
16:54:18
pjb
azrazalea: if you want to explode the brains of C programmers, show them: (block foo (mapcar (lambda (x) (if (zerop x) (return-from foo 'zero)) (1+ x)) '(1 2 3 0 5 6))) #| --> zero |#