freenode/#lisp - IRC Chatlog
Search
23:17:17
_death
vsync: for protocols, there's clim spec, amop, mikel evins's posts, dylan manuals, various papers (by amop authors, strandh, gabriel, etc.), many c.l.l posts
23:22:05
pookleblinky
Hm, tried running benchmarks between sbcl,ccl, and clisp, but each has an interestingly different focus on internal (time) function
23:33:03
Lord_Nightmare
what about cmucl? did that diverge enougb from sbcl by now to have a significantly different benchmark?
0:06:03
akkad
pookleblinky: (let ((btime (get-internal-real-time)) (etime (get-internal-real-time))) (format t "Delta is ~a~%" (/ (float (- etime btime)) (float internal-time-units-per-second))))
0:08:25
akkad
pookleblinky: http://zeniv.linux.org.uk/~ober/report.html has numbers from cl-bench. pretty recent
1:27:38
vsync
_death: cool, thanks... so frustrating because I have a vague mental image of a specific PDF or two and some Web pages, that laid it out in a specific way, just can't find any of them
2:04:01
vsync
what's a good name for a function to find a thing that exists, or make it if it doesn't, or return the thing?
2:05:47
vsync
it's not a function but an operation... i'm defining several operations that will have different implementations and substeps each, and will take paths depending on state at runtime and the arguments
2:05:58
pjb
If you make and keep it for next time, and you use some parameters to make it, then it's an "intern" operation.
2:06:23
vsync
so one of them involves making it or not, depending, but it's one high-level step from user's point of view (though not transparent to them)
2:08:31
vsync
if i can find a nice syntax to make (with-patient (pt-designator) ...) work you know I will
2:09:00
vsync
acquire is also nice because it can be acquiring a handle on the patient for the session, or acquiring new info about the patient
2:10:59
vsync
ok, now how about making an empty thing that will be later filled in and possibly actually used
2:13:23
vsync
trying to remember what the thing that makes the completely empty instance given to initialize-instance is called
3:00:00
vsync
beach: may not have seen this before but yes "protocol classes" and the explanation is exactly what I was thinking of
3:02:45
vsync
and now that I have that phrase, it seems CLIM was probably my prototypical example, which feels very familiar
3:03:34
beach
I did finally "get" object-oriented programming in CLOS when I read the CLIM II specification. I had red Keene's book before, but that was not enough.
3:24:06
tgips
beach: hi,i found a nice pdf version about Standard on plant lisp by Currell Berry.and i want to konw, whether it's much difference between r2004 version and r1994 version。
3:25:04
beach
tgips: This channel is dedicated on Common Lisp, and for Common Lisp there is only one standard, from 1994.
3:26:54
sausages
for my project in SBCL I have many, many different defstructs that have some members that are of type FUNCTION. For purposes of letting DESCRIBE easily remind my forgetful self what-lambda-functions-should-take-what-parameters for anything using these structs (and maybe hopefully giving more hints to the compiler's optimizer as a possible bonus), I want to more strictly define the types of these as not
3:27:00
sausages
just vague FUNCTION but (function (param-type-1 param-type-2 ... param-type-n) return-type). Seems to work OK defining such structs from the REPL and from SLIME, but during an actual block-compile SBCL gives me "Function types are not a legal argument to TYPEP". Is there perhaps a "proper" way to go about this?
3:29:46
tgips
beach: https://infostore.saiglobal.com/en-au/Standards/ANSI-INCITS-226-1994-R2004--706351/ then does this ?
3:29:47
Bike
I think slot :type should be okay with something that's not allowed for typep, but i'm not sure.
3:31:33
beach
tgips: It must be only cosmetic changes. The standard has not been revised or altered.
3:36:58
beach
tgips: Mainly, we consider the Common Lisp HyperSpec to be *the* standard, modulo some typos that "everybody knows about".
3:36:59
sausages
this works OK at the REPL, or doing C-c C-k from SLIME, but via an actual compile is when that TYPEP error happens
3:39:16
beach
sausages: You can't use TYPEP with a function type specifier if that's what you are trying to do.
3:39:23
Bike
If I have (defstruct foo (bar #'identity :type (function (t)))) then there are no problems compiling, (make-foo) works, (make-foo :bar #'+) works (because the type check is impossible), and (make-foo :bar 7) signals the proper error of "7 is not a (function (t))"
3:39:43
Bike
and yeah you can't type check functions with that much detail, though it may help the optimizer
3:40:43
beach
sausages: Maybe I am wrong, but it looks like a situation where it would be more advantageous to use standard classes and generic functions, instead of what you are doing. No?
3:41:23
sausages
converting everything to use CLOS instead of structs would take a very, very long time. I've been working on this for almost 5 years
3:42:44
sausages
it isn't too important, I just like how DESCRIBE helps me remember things I tend to forget often, and that would have been helpful to define more strictly what parameters a struct's lambda functions are expected to have
3:44:33
beach
Seriously, using generic functions and standard classes can make the code much more understandable.
3:44:44
sausages
the fact that it's not reproducing this error on this example file I made makes me wonder if it's something else causing the TYPEP error in my actual project
3:56:40
beach
sausages: You are already using CLOS. You can't use Common Lisp without using CLOS. The difference is between using structure classes or standard classes, and between using ordinary functions and generic functions.
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