libera/#commonlisp - IRC Chatlog
Search
18:51:50
bollu
Also, what's the common lisp equivalent of (a, b) = (10, 20) where a and b are *slots* of some structure?
18:52:04
bollu
(that is, I have a function that returns multiple values. I want to store the return values into a struct's slots)
18:52:41
Bike
as for the restart, to "discard" an error you pretty much need to abort the thread entirely
18:54:03
Bike
the debugger is invoked by the thread that hit the error, so i suppose what you'd need to do is have some shared flag saying whether the debugger has been entered. the first thread that hits an error trips that flag and enters the debugger normally, while the rest abort
19:05:16
bollu
it seems to work... most of the time? Sometimes it gets confusing to predict what the keys do
19:06:58
bollu
Question: I tried using `defstruct` inside a `defun`, and this did not seem to actually define a `struct`. Is this not allowed? Would `defclass` work? I just want a lightweight way to structure some data inside a block of code [think, gather success/failure/NA statistics]
19:09:09
contrapunctus
* Boon, Lispy, and Smartparens, in that order. Actually, I'm rarely using Smartparens of late...
19:11:30
pjb
bollu: there would be little point in definining a structure type at run-time, since you would have no code to take advantage of it, no code calling the run-time newly created constructor, no code calling the run-time newly created accessors, and no code to check the run-time newly created type!
19:20:11
pjb
bollu: it is still allowed, but it just doesn't do what you think it does. defclass would be the same. As would be defvar, defparameter, or any def<something> or define-<something> operator!
19:20:12
bollu
pjb I waned to enforce scoping, to make it clear that this struct I was creating represents a concept that's only manipulated in this part of the program
19:20:12
pjb
bollu: defining operators are better kept as top-level forms, to be compiled and evaluated at compilation-time.
19:20:12
pjb
bollu: functions can be defined locally, with flet or labels. You can use a macro to define a local lexical functionnal abstraction.
19:20:14
Bike
there's not. there is no way to hook into the standard structure mechanism to restrain its scope. you could make something _like_ defstruct, but it wouldn't have any implemention support like packing. and there's no way to make a non-global type definition.
19:30:45
dlowe
but yeah, in lisp we use our built-ins like plists for those kinds of temporary structures
19:31:18
dlowe
also consider using returning multiple values for things you would otherwise use structures for
19:37:50
pjb
If the structure type was local, you would most certainly NOT WANT to return any of it!!! dynamic-extend exclusively!
20:27:53
dlowe
well, you could have a local structure type that was passed around local functions I guess
20:33:55
White_Flame
you could also probably gensym everything up instead of giving it standard names
23:29:48
seok-
is there any library which can load ttf fonts as well as convert a glyph/character to png or any other image?
23:32:13
Mrtn[m]
seok-: What about making a procedure that takes a font, a glyph and an image, and plots the glyph on the image?
23:32:24
_death
zpb-ttf can load ttf fonts, and you can use vecto to render text.. there's also cl-freetype2 and cl-cairo2 for example
23:35:34
lisp123
I use defvar *server* to avoid trying to recreate it every time I reload my lisp file
23:35:37
seok-
Could you please elaborate how the object type produced by zpb-ttf can be used as the font to produce text on vecto?
23:39:10
lisp123
But it still evaluates the make server form - how to avoid that? (defvar *acceptor* (make-instance 'hunchentoot:easy-acceptor :port 12345)) (hunchentoot:start *acceptor*)
23:40:04
_death
lisp123: do you mean that it evaluates start twice? (because it's not in the defvar form)
23:41:02
lisp123
on second load (make-instance 'hunchentoot:easy-acceptr ...) returns an error because hunchentoot is already listening on 12345
23:45:39
lisp123
What should I check? I got this: acceptor #<WEBSOCKET-ACCEPTOR (host *, port 12345)> is already listening [Condition of type HUNCHENTOOT::HUNCHENTOOT-SIMPLE-ERROR]
23:46:35
lisp123
(defvar *acceptor* (make-instance 'hunchentoot:easy-acceptor :port 12345)) here is the issue, hunchentoot:start is fine (which I think was your question)
23:47:59
_death
you use hunchentoot:easy-acceptor, but the error you show refers to websocket-acceptor
23:48:46
lisp123
(defvar *server* (make-instance 'hunchensocket:websocket-acceptor :port 12345)) also errors out - that was the first error
23:49:33
_death
maybe you should come up with a small self-contained example that shows your problem.. it should be a file that, when loaded twice, results in the error you get
0:13:14
drmeister
How should I read the argument type in this: (cffi:defcfun ("libusb_init" %usb::init) :int (%usb::ctx (:pointer (:pointer %usb::context))))?
0:14:58
semz
Yeah. It's pointer to pointer to whatever %usb::context is. Although afaik cffi doesn't actually use pointer types for anything.
0:15:33
drmeister
I'm writing some code to control a USB printer that writes RFID labels. I'm using claw-usb in clasp Common Lisp.
0:16:05
semz
Erm, I mean that in (:pointer x), CFFI doesn't really care about the x. Obviously it uses pointer types themselves.
0:17:41
drmeister
If I go (let ((ctx (cffi:null-pointer))) (%usb:init ctx) ...) then it should write an address into the ctx object foreign-data object?
0:18:16
drmeister
That's how it's used in an example and it works - but when I inspect the object in ctx I don't see anything written.
0:19:53
drmeister
The code works - I get a list of [vid:pid] values for my attached usb devices. I don't understand why when I don't see anything written into ctx.
0:23:06
semz
"Sessions are created by libusb_init() and destroyed through libusb_exit(). If your application is guaranteed to only ever include a single libusb user (i.e. you), you do not have to worry about contexts: pass NULL in every function call where a context is required, and the default context will be used."
0:23:16
semz
( https://libusb.sourceforge.io/api-1.0/group__libusb__lib.html#ga4ec088aa7b79c4a9599e39bf36a72833 )