libera/#commonlisp - IRC Chatlog
Search
12:09:47
pve
Hi, is there a big difference between doing (eval `(defmethod foo ...)) and creating the method "manually" followed by (add-method #'foo my-new-method)?
12:21:31
lisp123
if you are speaking in terms of writing these forms in a file, then obviously, the latter is faster
12:22:10
lisp123
but working in a live, running image, given that defmethod is already a top-level form, my suspicion is that they might be the same
12:27:06
lisp123
defmethod is a macro, so some of its work will be done in compile time vs. load time
12:29:04
lisp123
Sorry, I guess you were referring to doing the parts of defmethod manaully in your latter part --> so what I just said may not apply directly, but to the extent there are any macros within those parts, it will be faster
12:30:11
pve
lisp123: yes, I mean (make-instance some-method-class ... ) and the whole make-method-lambda deal
12:31:33
lisp123
I see. Will wait for someone else to respond, but in the meantime (I have to jet), here's the source of defmethod (https://plaster.tymoon.eu/view/2730#2730)
13:35:12
pve
beach: but is defmethod the only way to create a new method using CL only (i.e. no MOP)?
14:06:20
pjb
ns12: com.informatimago.common-lisp.cesarum.utility:define-structure-class implements the defstruct API using CLOS, so I would say it qualify as a library providing standard compliant structures, but with extra features.
14:09:49
pjb
pve: and perhaps other implementation specific details your implementation defmethod does…
15:33:35
Guest74
so I'm revisiting and cleaning up my ioctl stuff and see that i've kept c style names for structs and constants. I'm wondering if I should keep them exactly like this since that's what all the manuals/tutorials on the internet say, or lispify them?
15:35:54
pjb
Guest74: depends. I split by ffi stuff in two layers. a lower layer where I stick to C, and a higher layer, where I lispify.
15:37:12
Guest74
I've thought of that, but since they're just ioctls and not actual ffi to a library I'm wondering if that's even worth it.
15:38:38
Guest74
I'm also wondering if it's a terrible idea to replace all foreign structs with just static-vectors and then have lisp side functions to access the array as the struct slots. I'm not sure if that is more work, or faster for setting/getting.
16:18:42
Guest74
anybody know how to translate this to lisp from c? 1000000000UL/a I have no idea what's going on in the c.
16:36:13
semz
Guest74: If a is a float or double, 1000000000 would be converted to that first. / does the same thing in CL if a is a floating-point number.
16:37:16
semz
If you translate C names to Lisp names, I'd recommend being extra careful that your scheme is consistent and intuitive though; speaking from experience, it's infuriating when you have to look up how each name was translated in the manual when you're familiar with the underlying foreign API.
16:43:27
beach
On the rare occasions that I had to use a Lisp interface to a C library, I found it infuriating to have to consult the manual for the C library at all. I expected a consistent, well documented Lisp interface that did not refer to the underlying C library or its concepts.
16:55:41
Guest74
beach: it's not a foreign library, it's just ioctls. How do you handle interfacing with the linux kernel?
16:57:24
beach
I haven't given any thought to that. But some day I guess I will have to, given that I want a Lisp-y POSIX library at some point.
16:59:40
Guest74
I figure the lispy interface should be built on ioctls, since, as far as i understand, that's how you interact with the kernel. the ioctl level being not so lispy.
17:00:55
Guest74
I figure the person writing the lispy interface wouldn't mind the c-ness of the ioctl interface since all documentation for the kernel is written that way.
17:04:59
Guest74
though at the same time, I'd also like to change things like DRM_IOCTL_MODE_GETRESOURCES to drm-ioctl:mode-getresources , which kinda makes sens to me. But then how for do I go? drm-ioctl:mode-get-resources?
17:10:01
beach
I might create one Lisp function for each type of IOCTL, rather than maintaining the interface. But I think you are saying that that's someone else's job.
17:11:29
Guest74
yes, I figure in the higher level library, the equivalent of libdrm in c, it would just be a function, and no trace of ioctls would be seen.
17:13:16
Guest74
lol, preferably. I suspect that would be more work and I'd rather just start using the parts I need. However, I would like to at least standardize the lisp representation of ioctls.
18:32:16
semz
Is there a recommended way to document/enforce crucial assumptions for a piece of code? I use (eval-when (:compile-toplevel :load-toplevel :execute) (unless (precondition-holds-p) (error "FOO isn't supported because BAR."))), but maybe there's a better way.
18:32:36
jcowan
Sometimes reading *less* is wiser. Learning CL by reading the whole spec is only for crazies like me.
18:32:51
semz
This is under the assumption that there isn't a portable fallback implementation, of course.
18:53:47
Alfr
semz, if it's a system you're testing for and you're using asdf, there's :depends-on. Further, is it fatal at compile/load time or is it permissible for what's missing to be loaded later?
19:12:14
jcowan
People underestimate how BIG Posix actually is when they set out to provide a non-thin library. By actual count: 81 headers, 1191 interfaces, and 51 data types.
20:25:51
Alfr
semz, the list of places can be empty, they're only needed if you want the continue restart to ask for new values.
20:28:15
semz
Amusingly/annoyingly enough, SBCL complains about dead code if the assertion is true at compile time.
20:43:03
jackdaniel
I find it the most annoying that it complains about &optional and &key parameters in the same lambda list
20:43:06
Guest74
jcowan: thankfully I'm not doing any of that. Only graphics related stuff, but anybody can use the ioctl macros to make kernel interface headers easy to convert.
20:45:39
Guest74
I don't know why but i had a lot of optional then key stuff, but now i just find it annoying.
21:31:53
Guest74
I've just noticed that when a package has a . in it slime onlydisplays what's after the period when in the package. Is this supposed to be like this?
22:00:43
theothornhill
I'm working on a compiler where I have an AST, and a hash-table with keys as type names pointing to ast nodes. I want to access both of these regularly from other functions. What is best practice here? I was thinking of creating a macro such as `with-ensured-ast` that either returns a memoized ast and hash-table or initializes one. Or I could suck it up and ensure that all functions that need them get them as parameters.
22:02:27
theothornhill
Now i just remember to (let ((*schema* (build-schema "..."))) ...) everytime I do things
22:02:55
semz
I'd probably go for a dynamic variable, especially if that table is essentially global during the compilation.
22:04:02
theothornhill
Yeah, it is. So you just decide the entry point, bind it and hope for the best?
22:06:38
semz
Yes. If you want a little less hoping during development, it might help to set the variable's default value to something that cannot possibly do anything but blow up instantly.
22:06:44
White_Flame
btw, I'd also make a with-ensured-ast which creates the dynamic bindings for you
22:07:48
semz
e.g. NIL if it's a hashtable, or :invalid if it's a list. Not always possible though, depending on the intended type.
22:09:14
theothornhill
Well the ast is just an instance of an object and the table a table, so nil will break things nicely
22:21:52
Guest74
etimmons: it's like a low slashdot id before they sold out. I'm the 74th guest! this will be mint in a few years.
23:14:04
phantomics
quick question: is there a standard way in CL to make a rational number other than (/ x y)? In SBCL, there's a sb-kernel function called (build-rational) that does this, but I can't find anything that's implementation-independent