freenode/#lisp - IRC Chatlog
Search
0:07:53
pjb
Shinmera: I wouldn't be so categoric: pointers can have different sizes. eg. in MS-DOS. But also because you may have pointers to different type of data requiring more or less bits.
3:38:45
jasom
pjb: Bike, faff appears to be gone now, but what about this, which doesn't appear to have been suggested: (apply map 'list (lambda (x y) (+ x y)) (k1))
3:48:31
emaczen
https://pastebin.com/PKJz7FLH -- I am having trouble converting this C code to lisp CFFI code
3:49:26
emaczen
I've written a short fully working program that uses CFFI and an external C library without any problems before, but the code was of a different style and didn't pass pointers to be modified like this code does
3:57:06
|3b|
https://github.com/3b/3b-libusb1/blob/master/bindings.lisp is how i would have done it ~2.5 years ago :)
3:58:07
axg
in the C++ code, you are passing the address of your ctx pointer to init. in the lisp version, it looks like you are passing null
3:58:53
|3b|
(though possibly for older version of libusb, not sure how much/if it has changed since then)
4:06:29
|3b|
you might need to read the pointer from that pointer after calling init to get something you can pass to other functions
4:07:31
pjb
jasom: I proposed: (apply (function map) 'list (function +) (f1)) <-- F1, an operator returning a list of lists. The point of k1 is that it is not possible for a macro to return multiple forms. A macro can only return one form. This form could compute a list of list, so (apply (function map) 'list (function +) (k1)) would be possible. But there would be no point in using a macro, since a function would work as well.
4:10:13
emaczen
All I changed was adding (cffi:mem-ref context :pointer) right after (libusb-init context)
4:13:37
emaczen
Okay now, it isn't giving me an unhandled memory error BUT when I (cffi:mem-ref devices :pointer 5) it is the null pointer
4:15:34
|3b|
ACTION can't explain it in IRc better than https://github.com/3b/3b-libusb1/blob/master/wrappers.lisp#L15 :p
4:17:47
jasom
emaczen: yes; the lisp code you would would roughly correspond to the c code: context = malloc(sizeof(void **)); libusb_init(context); libusb_get_device_list(*context);
4:18:30
|3b|
thanks, that's what i was failing to find words for :) been too long since i used C directly
4:18:33
jasom
because you need to explicitly allocate in lisp anything you are going to pass to C (rather than implicitly allocate on the stack like your C code)
4:19:48
emaczen
Now my problem is that libusb-get-device-list returns 6 (so I have 6 usb devices) which means I should be able to (cffi:mem-ref devices :pointer 5)
4:25:05
|3b|
and you probably want mem-aref there, where the offset is in pointers rather than bytes
4:29:13
emaczen
What should I be expecting in the print statements? I have no idea what are reasonable values for the number of configurations, device class, vendor id, or product id
4:36:14
beach
So again, we are on freenode (dedicated to free software) in the #lisp channel (dedicated to Common Lisp), but we are talking about using other languages on commercial operating systems. Go figure.
4:39:08
|3b|
beach: at least the foreign library in question doesn't require the commercial operating systems :)
4:49:12
|3b|
ACTION generally considers falling cffi:foreign-alloc directly to be "something wrong" without good reason, but shouldn't affect output of that
4:51:55
|3b|
assuming those are correct, looks reasonable, but i'd probably try to verify the offsets if possible (print results of offsetof from the c code for example)
4:52:15
|3b|
works if you know your ABI well enough to get the alignment etc right when counting bytes :)
4:52:49
|3b|
ACTION would just put all the fields in and let cffi figure it out for normal libraries
4:55:58
emaczen
and then I'm calling (print-dev (cffi:mem-aref devices :pointer 2)) or another index
5:04:43
|3b|
ACTION thinks padding might not matter for that struct, since it has uint8 in multiples of 2 between the uint16, but multiplying offsets by 8 probably isn't good :)
5:05:09
|3b|
(at least in my version of it, which presumably matched the C version well enough for my code to run at some point)
5:09:19
emaczen
|3b|: Right now, I'm just trying to get started with programming with USB devices from CL
5:12:03
|3b|
might see if my lib still works... not very complete but at least might bet you a little bit further to start out
5:16:25
emaczen
|3b|: Thanks for the help, the hardest part is getting started... I should be able to figure out a lot from here with the pointers given
5:22:13
sigjuice
would it be possible to do something like this to make a custom sbcl binary? (defsystem "mysbcl/exe" :build-operation program-op :build-pathname "mysbcl" :entry-point "launch-sbcl-repl????" :depends-on (...))
5:36:34
pillton
sigjuice: https://github.com/markcox80/lisp-executable/blob/master/lisp-executable-example.asd#L39
5:42:14
sigjuice
|3b| yes, sort of. and is it something I can use as an entrypoint in the asdf:defsystem I mentioned above.
5:47:12
pillton
sigjuice: Lisp-executable won't be of any use if you want that. I didn't read what you said properly.
5:58:12
pillton
sigjuice: No worries. Sorry for not reading your original question correctly. Thanks to |3b|.
9:36:50
schweers
ACTION wonders if filenames like foo.tar.gz might have been a bad idea after all (considering how SBCL handles the type of a namesting/pathname)
9:56:47
pjb
schweers: for unix, it's not a bad idea. But for common lisp logical pathnames, it's redhibitory, since #\. is not a conforming character for pathname names. cf. 19.3.1
9:58:00
schweers
Well, how were an implementation to know whether the dot separates the (stack of) type(s), or whether its just a funny name?
9:59:13
schweers
I know it is, but what I mean is: what might be the best behaviour? guessing is not an option, and the filenames themselves don’t provide enough information
10:02:13
schweers
pjb: I just now realized you were talking about logical pathnames. Are the rules for them relevant if I don’t use them (directly)?
10:04:41
Shinmera
schweers: The real problem is that the file name matters at all, rather than the type of file being encoded in the data/inode in a standard way.
10:05:13
schweers
That is what I would have preferred (I guess), but filesystems are the way they now are, I guess :(
10:06:08
pjb
schweers: of course, logical pathnames are not relevant when you don't use them directly. When you talk about a physical pathname such as "foo.tar.gz", nothing matters, since it's entirely implementation dependent how it's interpreted.
10:06:27
pjb
schweers: yes, two implementations can choose to cut the name / type on different dots.
10:07:10
schweers
okay, that’s what I thought. Not entirely satisfactory, but I guess I’ll just have to live with that
10:10:22
schweers
considering logical pathnames: are they used in the wild? i.e. do you guys and gals use them?
10:11:08
schweers
I must admit that I don’t know anything about them, other than that I have read statements online (can’t remember where or by whom) that they are badly designed and one should avoid them
10:11:11
pjb
You could have the rule, that you should not have literal physical pathnames in lisp sources. Only literal logical pathnames are allowed.
10:12:15
pjb
logical pathnames offers an indirection level allowing you to manipulate pathnames in an implementation independent way, thru the logical-pathname-translation mapping.
10:12:52
pjb
So you don't have to care where the files and directory your application uses are located; this will be decided by the user (thru load-logical-pathname-translations).
10:13:44
pjb
see for example: https://gitlab.com/patchwork/patchwork/blob/master/loghosts.lisp and https://gitlab.com/patchwork/patchwork/blob/master/builder.lisp
10:20:50
pjb
schweers: in this case, I define the logical hosts and their translations in loghosts.lisp; but it could be left to the user, using load-logical-pathname-translations.
10:21:33
pjb
schweers: when you install an application, your installation script could generate the logical pathname translation file to be used by load-logical-pathname-translations for the user, depending in the installation paths.
10:22:25
schweers
So one can define a logical path to the applications installation directory and have the user configure where that points to prior to building?
10:22:26
pjb
schweers: In this example, this allows the rest of the build scripts such as builder.lisp to use logical pathname literals independently of the locations of the various sources directories.
10:23:53
pjb
Basically, if you save a physical pathname in a lisp image, you failed (because a different user may run the same executable lisp image, so hardwired pathnames may be wrong).
10:24:24
pjb
Since logical pathnames are translated at run-time, you can save them in your sources, your fasls, or your lisp images.
10:24:45
pjb
The only thing you have to remember is that you can only translate from logical to physical, never the other direction.
10:25:04
schweers
its settled, I must learn how to use these beasts :) thanks a lot for the information!
10:25:34
pjb
So when you get a physical pathname at run-time (such as with DIRECTORY, or using an "open" dialog, or given by the user), you must keep it as physical pathname (you can still manipulate all the pathnames with pathname functions).
10:26:16
pjb
The only difficulty there is that there's a lot of implementation and platform specific behavior allowed… So it's delicate to use conformingly.
10:29:34
Shinmera
too bad logical pathnames don't deal well with case and other special characters, among other things.
10:32:23
pjb
(setf (logical-pathname-translations "MY-APP") '(("SUMMER.*" "/opt/my-app/été.*"))) (translate-logical-pathname #P"MY-APP:SUMMER.TXT") #| --> #P"/opt/my-app/été.TXT" |#
10:32:49
pjb
The point of logical pathnames is that you don't polute your sources with implementation and platform specific path literals.
10:33:23
pjb
All those implementation and platform specific physical pathnames, with those cases and special characters variants, are collected into a single place, the logical pathname translation table.
10:34:14
pjb
That said, some implementations may have physical pathnames restrictions that make them unable to represent all the paths of a given platform. Call that a bug.
10:34:33
schweers
do I understand correctly that logical pathnames are there to encode well-known-places which depend on the implementation, the OS, or in some other way on the environment? i.e. obtaining the users home directory would be a valid use of logical pathnames?
10:36:07
pjb
schweers: indeed, in some implementations, #"HOME:" is mapped to (user-homedir-pathname).
10:37:33
schweers
so when reading user specific configs, a logical pathname might translate to ~/.config/ on unix and to … uh … /Users/$USERNAME/.AppData/ on windows? (I don’t use windows much, so I might be wrong here, but I guess you see my point)
10:38:20
pjb
on windows it's even more complex, since appdata and other user specific files are not necessarily in (user-homedir-pathname)…
10:42:45
jmercouris
there's not really a convention in Windows, especially because they support basically all legacy programs
10:43:49
schweers
If I recall correctly MS does have guidelines for these sort of things, but they don’t document it as loudly as they should, as is often the case
10:44:18
Shinmera
schweers: You don't put things into AppData, you put them in AppData\Local, AppData\Roaming, or AppData\LocalLow
10:44:34
schweers
for instance I think its quite bad that still so many programs put their data directly into the users home on unix
10:44:51
jmercouris
yes, that is really annoying, but there is nothing motivating programs from not doing that
10:45:08
schweers
Shinmera: fair enough, as I said, I don’t really use windows ;) Nevertheless, thanks for correcting me
10:45:12
jmercouris
if people really wanted to see a change, a distro would have to take a hard stance and somehow make that harder on their platform or something
10:46:45
jmercouris
I am also 10+ years, but at some point Linux made me very bitter and pushed me to bsd...
10:46:52
schweers
pjb: yes, but that doesn’t cover the majority of software, which is, sadly, not written in lisp
11:00:00
schweers
pjb: what exactly am I supposed to pass to LOGICAL-PATHNAME-TRANSLATIONS? I tried this, but it gave me an error, because the argument is of the wrong type: (logical-pathname-translations (pathname-host *default-pathname-defaults*))
11:01:39
pjb
(setf (logical-pathname-translations "MY-APP") '(("SUMMER.*" "/opt/my-app/été.*"))) (translate-logical-pathname #P"MY-APP:SUMMER.TXT")
11:02:08
pjb
Not necessarily. Some may be provided by the implementation. logical host names such as "SYSTEM" "SYS" "SOURCES" etc…
11:04:13
pjb
so you can access all the files that can be translated by the implementations default rules to map logical pathnames to physical pathnames.
11:08:28
jmercouris
I'm trying to load my system in SBCL, and I am getting a strange error: https://gist.github.com/6d13c14b6005330a69b0b5622d2fd85b
11:09:17
pjb
jmercouris: :mailto is a new option for asdf systems. Perhaps write #+asdf3 :mailto #+asdf3 "foo@bar.baz"
11:10:03
jmercouris
how does one load a recent version of asdf? is it not built into the implementation?
11:12:09
pjb
I download it from https://common-lisp.net/project/asdf/#downloads and then I use (load "asdf.lisp") in my common.lisp rc file. More precisely: (defun load-asdf3 () (unless (member :asdf3 *features*) (load (merge-pathnames #P"src/public/lisp/tools/asdf.lisp" (user-homedir-pathname))))) (load-asdf3)
11:13:10
jmercouris
seems I am using a very old version of sbcl, let me update it first, then I'll try updating asdf by itself if that doesn't suffice
11:20:26
jmercouris
the binaries here are really out of date for darwin: http://www.sbcl.org/platform-table.html