<White_Flame>
skeemer: I'd also recommend being in #clschool
<skeemer>
thanks White_Flame !
Oddity has quit [Ping timeout: 256 seconds]
aeth_ has joined #commonlisp
aeth has quit [Killed (NickServ (GHOST command used by aeth_))]
aeth_ is now known as aeth
OlCe has quit [Ping timeout: 256 seconds]
morganw has quit [Remote host closed the connection]
Oddity has joined #commonlisp
NotThatRPG_ has quit [Read error: Connection reset by peer]
NotThatRPG has joined #commonlisp
Tallund has quit [Ping timeout: 256 seconds]
akoana has joined #commonlisp
vcarvalho has quit [Ping timeout: 256 seconds]
VincentVega has quit [Remote host closed the connection]
perrierjouet has quit [Quit: WeeChat 3.4]
occ has joined #commonlisp
perrierjouet has joined #commonlisp
igemnace has joined #commonlisp
hashfunc1336 has quit [Remote host closed the connection]
s-liao has joined #commonlisp
lisp123 has joined #commonlisp
s-liao has quit [Quit: Client closed]
lisp123 has quit [Ping timeout: 256 seconds]
mon_aaraj has quit [Ping timeout: 256 seconds]
xsperry has quit [Remote host closed the connection]
random-nick has quit [Ping timeout: 256 seconds]
s-liao has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Client Quit]
iamFIREc1 has joined #commonlisp
s-liao5 has joined #commonlisp
iamFIREcracker has quit [Ping timeout: 256 seconds]
s-liao has quit [Ping timeout: 256 seconds]
lambdart has quit [Remote host closed the connection]
dre has quit [Ping timeout: 250 seconds]
iamFIREcracker has joined #commonlisp
iamFIREc1 has quit [Ping timeout: 256 seconds]
s-liao5 has quit [Ping timeout: 256 seconds]
s-liao has joined #commonlisp
lisper29 has joined #commonlisp
<mfiano>
Is there anything to be said about how conditions shall be named? I see it is somewhat common to name error conditions suffixed with "-ERROR", but this seems redundant to me. Are there any other arguably conventions regarding the hierarchy/structure/naming of conditions? This topic isn't talked about very much, and I'd like to provoke some sort of discussion on the matter for those (very few)
<mfiano>
of us that have experience with one of the most powerful features of the language.
IPmonger has quit [Remote host closed the connection]
AeroNotix has quit [Quit: WeeChat 3.4]
lisp123_ has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
semz_ has joined #commonlisp
semz has quit [Ping timeout: 250 seconds]
semz_ is now known as semz
lisp123_ has quit [Remote host closed the connection]
lisp123_ has joined #commonlisp
lisp123_ has quit [Ping timeout: 240 seconds]
jealousmonk has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 27.1)]
dre has joined #commonlisp
lisp123 has joined #commonlisp
dre has quit [Ping timeout: 250 seconds]
jeosol has joined #commonlisp
lisp123_ has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
tyson2 has quit [Remote host closed the connection]
Oladon has quit [Quit: Leaving.]
occ has quit [Ping timeout: 256 seconds]
occ has joined #commonlisp
pranavats has joined #commonlisp
shka has joined #commonlisp
aartaka has joined #commonlisp
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
<jackdaniel>
mfiano: usually I'm defining abstract types: foo-warning, foo-error etc., and after that concrete conditions that are signaled inherit from them and are named like bar-doesnt-exist and such
ogamita has joined #commonlisp
lisp123_ has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
rgherdt has joined #commonlisp
karlosz_ has joined #commonlisp
ogamita has quit [Ping timeout: 240 seconds]
lisp123 has quit [Ping timeout: 260 seconds]
karlosz has quit [Ping timeout: 256 seconds]
karlosz_ is now known as karlosz
lisp123 has joined #commonlisp
treflip has joined #commonlisp
ogamita`` is now known as ogamita
blacked has joined #commonlisp
blacked is now known as pingpongball
<pingpongball>
!hi
<beach>
Hello pingpongball.
<pingpongball>
hello
<pingpongball>
beach :)
<pingpongball>
What gui library does that NYXT browser uses?
<pingpongball>
as it is made from common lisp.
<moon-child>
nyxt is a chrome over webkit
<lisp123>
Docs say GTK / Qt
<lisp123>
looks like GTK
<lisp123>
Re QT: "Qt is only required if you want to build Nyxt over the WebEngine renderer."
<lisp123>
I think its a very impressive project that seems to be getting more popular every day
lisp123_ has joined #commonlisp
<pingpongball>
oh yeah
<pingpongball>
i was thinking as like javafx,swing - java, arent there native on common lisp?
<moon-child>
mcclim?
<beach>
Yes, CLIM.
treflip has quit [Remote host closed the connection]
<beach>
pingpongball: McCLIM is a free implementation of the Common Lisp Interface Manager (CLIM) specification.
<jackdaniel>
to beat the dead horse - nyxt doesn't use clim, it uses a foreign toolkit
<pingpongball>
if i compare with gui that popular languages provides , with CLIM what do you think?
lisp123 has quit [Ping timeout: 256 seconds]
<beach>
pingpongball: CLIM is way more impressive and way more adapted to Common Lisp.
<beach>
pingpongball: CLIM has the concept of "presentation types" which I understand is still unique.
<pingpongball>
oh :
treflip has joined #commonlisp
lisp123 has joined #commonlisp
lisp123_ has quit [Ping timeout: 240 seconds]
pingpongball has quit [Quit: Client closed]
pve has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
cosimone has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
silasfox has joined #commonlisp
s-liao has joined #commonlisp
cage has joined #commonlisp
Dynom has joined #commonlisp
tfeb has joined #commonlisp
lisp123 has joined #commonlisp
<saturn2>
i really wish i could use and recommend McCLIM over GTK, but unfortunately it seems to have too many rough edges
tfeb has quit [Quit: died]
<ogamita>
saturn2: use it, iron out the rough edges.
<jackdaniel>
well, it's still progress, the casual remark 3y ago was "it is a shame that McCLIM is dead in the water"
wacki has joined #commonlisp
<jackdaniel>
(similar 8y ago for ECL)
attila_lendvai has joined #commonlisp
<jackdaniel>
that said, I wouldn't recommend gtk either, last time I've used it it was confusing at best with its unstable api(s). I'd be more confident to recommend qt
lisp123 has quit [Ping timeout: 250 seconds]
OlCe has joined #commonlisp
xsperry has joined #commonlisp
Guest4425 has joined #commonlisp
gjvc_ is now known as gjvc
<mfiano>
jackdaniel: Thank you.
<mfiano>
That seems to be the consensus
<mfiano>
and, I wasn't aware of that idiom
<mfiano>
I have another condition question. I have a design issue I have been deferring that I need to solve in a good enough way.
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
<mfiano>
I am developing an image processing library. So far, I have been working on the color package, manipulating invidividual pixels, rather than images as a whole or in part. One thing I can do is convert from one color space to another, or perform color correction algorithms. These can both go "out of gamut", resulting in a pixel's channel that is outside the [0, 1] range. When processing an image
<mfiano>
or region of one, I would like to handle a condition that was signaled. The actual behavior depends on what the user wants, but two possible choices will be "continue but clamp the channel", "error, and undo the entire history as to not leave the image in a partial, inconsistent state", and maybe some other strategies. I'm not sure what a good way to handle these would be. I'm thinking I would
<mfiano>
at least want the dynamic catch/throw, but I am unsure if I would need to keep a back-tracking history of events for the second solution, and other questions arising from these.
notzmv has quit [Ping timeout: 260 seconds]
karlosz has quit [Quit: karlosz]
hhdave has joined #commonlisp
<mfiano>
The easiest solution sounds like to double-buffer, at the expense of much memory wasted for large images. I'm thinking keeping a history of previous pixel values to revert to, as out of gamut errors are likely to occur sooner than later.
igemnace has joined #commonlisp
<mfiano>
As for the best way to "signal" when to revert that, I'm still thinking throw/catch, unless someone has a better idea.
<mfiano>
moon-child: That sounds wasteful, if I can hold one large image, it may not be very likely I can hold two.
<phoe>
where the first restart sets NEW-VALUE to something meaningful and continues
<mfiano>
Especially since out of gamut errors will happen likely much before the middle of the image...for photographs anyway.
amb007 has quit [Ping timeout: 256 seconds]
<phoe>
and the second restart erases stuff and THROWs to prevent further processing
<mfiano>
It's the "erases stuff" I'm really trying to think about.
<moon-child>
say extreme case. 8kx8k image, 128bpp is 1gb
<phoe>
mfiano: what do you mean, think about
<mfiano>
moon-child: That is not so extreme for HDR panoramic images. 24K is common :)
amb007 has joined #commonlisp
<moon-child>
sure. So 10gb
<moon-child>
vs 20
<phoe>
at this point it's less a question about the condition system and more of a question about what would be meaningful to do algorithmically and UX-wise
aeth has quit [Ping timeout: 250 seconds]
<phoe>
if you want to undo the partial operation then you need to have an undo facility of some sort
<mfiano>
phoe: think about, as in, whether to keep a history or to double buffer, and what to do for image algorithms that already require double buffering...that would be triple buffering?
igemnace has quit [Remote host closed the connection]
<phoe>
yes
<phoe>
and, as I said, that's no longer a condition system question :D
<mfiano>
Yeah there are multiple questions here. Thanks for your input though :)
aeth has joined #commonlisp
<phoe>
I'd assume that if someone tries to work on huge images then they have enough RAM and swap space to back these attempts up
<mfiano>
Yes
<mfiano>
I mean, I don't plan on extremely huge images myself, but I can't discount them.
<mfiano>
The undo system sounds much more efficient, and easier to reason about wrt algorithms that already need to double buffer.
<mfiano>
To me, anyway.
<phoe>
well then, make a copy of your image before attempting to frob it
<phoe>
there, you have a one-step undo
<mfiano>
If the first scanline goes out of gamut, out of 16k scanlines, that's a huge memory and performance savings.
amk has quit [Read error: Connection reset by peer]
<mfiano>
Ok, thanks for the suggestions everyone. I'll let it simmer a bit.
<jackdaniel>
mfiano: perhaps leave the descision to the user (with a sensible default - i.e having a "revert copy")
<mfiano>
jackdaniel: Yeah, I think I mentioned that in the long description above. Definitely.
<jackdaniel>
ah, sorry, I must have missed it
<mfiano>
and I haven't read phoe's condition system book yet, though I am quite familiar with the condition system already. I am looking forward to learning a thing or two though, as it's on my next to-read list.
<phoe>
jackdaniel: I think that's the idea wrt having multiple restarts - abort and revert to the image copy, continue and clamp the values, etc.. whatever is meaningful in the context
<phoe>
and that's doable with a (when invalid-state-p (restart-case (error ...) ...)) in a proper place
<phoe>
more restarts can be added along the way too
<jackdaniel>
I understand how restarts work but I don't understand how this refers to what I've said above
Lord_of_Life has quit [Ping timeout: 256 seconds]
attila_lendvai has quit [Ping timeout: 250 seconds]
Lord_of_Life has joined #commonlisp
amk has joined #commonlisp
<phoe>
"leave the decision to the user" - such a restart-case would be an implementation of that choice
<jackdaniel>
no, because you decide whether you copy the buffer before you perform any operation - erroneous or not
<jackdaniel>
as in (with-manipulation-buffer (buffer :save-copy *save-copy-default*) …)
<mfiano>
Right, you would have to decide before a restart was invoked.
cosimone has quit [Remote host closed the connection]
<mfiano>
Or the condition was signaled rather.
cosimone has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
<phoe>
right, you need to decide whether you want to make the operation undoable every time before you make an operation
<phoe>
I assume that one copy is made before every operation and it's always possible to revert to it
<phoe>
if that's not the case then one restart needs to be moved elsewhere
<phoe>
(along with copying the image)
iamFIREc1 has joined #commonlisp
<mfiano>
So the undo system (partial history instead of full buffer) conflicts with this.
<mfiano>
It would have to be a user choice at program start
<mfiano>
For those low on RAM
<moon-child>
(I will add one more thing: I find snapshotting both more coherent and robust than diffing. But I am going to bed now so can not argue this point!)
iamFIREcracker has quit [Ping timeout: 256 seconds]
<mfiano>
Yes, I found backtracking to be difficult to make robust in another image library of mine.
<mfiano>
THanks for the suggestions!
OlCe has quit [Ping timeout: 256 seconds]
iamFIREcracker has joined #commonlisp
iamFIREc1 has quit [Ping timeout: 256 seconds]
Dynom has quit [Quit: WeeChat 3.4]
lisp123 has quit [Remote host closed the connection]
shka has quit [Ping timeout: 256 seconds]
s-liao has quit [Quit: Client closed]
amb007 has quit [Ping timeout: 256 seconds]
lisp123 has joined #commonlisp
amb007 has joined #commonlisp
silasfox has quit [Quit: WeeChat 3.4]
pranavats has left #commonlisp [Error from remote client]
amb007 has quit [Ping timeout: 256 seconds]
iamFIREc1 has joined #commonlisp
amb007 has joined #commonlisp
iamFIREcracker has quit [Ping timeout: 250 seconds]
<beach>
mfiano: Do you know about the library "opticl"?
Andrew has joined #commonlisp
<mfiano>
Of course. I contributed pngload to it.
<beach>
OK. Just checking in case there might be some overlap with what you are working on.
<mfiano>
There might be some but not much, but thanks!
<beach>
Great!
SR-71 has joined #commonlisp
<SR-71>
Is there a way I can get in touch with slime devs?
<phoe>
SR-71: slime-devel mailing list, or the slime issue tracker
notzmv has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
random-nick has joined #commonlisp
aartaka has quit [Remote host closed the connection]
aartaka has joined #commonlisp
tyson2 has joined #commonlisp
Guest4425 has quit [Ping timeout: 256 seconds]
amb007 has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
s-liao has joined #commonlisp
amb007 has joined #commonlisp
cosimone has quit [Read error: Connection reset by peer]
cosimone has joined #commonlisp
lisp123 has joined #commonlisp
mon_aaraj has quit [Ping timeout: 240 seconds]
lisp123 has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #commonlisp
<beach>
ASDF insists that operations be created with MAKE-OPERATION. It also caches these operations so that each time MAKE-OPERATION is called with the same symbol, the same instance is returned. Does anybody know why ASDF does it this way, as opposed to letting the user call MAKE-INSTANCE to create an operation?
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
<beach>
I am asking because the operation instance would have been the ideal place to put things like options to the compiler/loader/whatever, to be applied for each component in a system. But this caching technique makes that idea impossible.
mon_aaraj has quit [Ping timeout: 256 seconds]
<phoe>
I assume that in the ASDF way these options should go into system instances rather than operation instances
<phoe>
so you can specify things like around-compile-hook for compile-op, and so on
mon_aaraj has joined #commonlisp
<beach>
But the system is not available to methods on PERFORM.
Oddity has quit [Remote host closed the connection]
<beach>
PERFORM takes an operation and a component.
<phoe>
yes, and I see plenty of methods EQL-specialized on systems
<phoe>
TEST-OP first and foremost, since these invoke particular test suites
<phoe>
as in, the second argument (the component) is EQL to a particular system
<beach>
But if I want to specify in a method on PERFORM that it should call the compiler with particular options on a component that is a source file, the system is not available.
<beach>
Then the component is the source file, not the system.
<phoe>
yes, I see now
<phoe>
I think the ASDF solution is to define a different component class, either as a default for all source files or per-component
<beach>
But that would mean rewriting the system definition, no?
<phoe>
yes
<beach>
The thing I am after is not specific to a system definition, but to an invocation of operate-on-system.
pranavats has joined #commonlisp
<phoe>
I see
<beach>
Plus, I can't rewrite ASDF system definitions for external libraries that I want to process with my own ONLY-COMPILE-OP.
<beach>
It would have been ideal to stick those options in the operation instance to be created by OPERATE-ON-SYSTEM.
<beach>
Anyway, thanks for listening, phoe.
<phoe>
it does not seem that ASDF swings that way - operations seem to be singletons
<phoe>
no idea why, but that's the way it is
occ has quit [Ping timeout: 256 seconds]
<etimmons>
That decision was made before I got really involved. But I suspect it was in large part the difficulty in synchronizing options with the dependency operations
<etimmons>
For example, forcing should require all its dependencies to force as well.
<beach>
I guess I'll just bypass ASDF and just ask for a list of components in dependency order.
<beach>
Then I can do what I want with that list.
<beach>
It is sad though. There is that OPERATION argument, and all it can be used for is generic dispatch.
<etimmons>
beach: I must be missing something in what you're trying to do. What options do you need to add in addition to your operation?
<beach>
I would like to store the compilation environment in the operation, so that I can pass it to the compiler.
<etimmons>
Ah. Makes sense
<beach>
That way, I could share the compilation environment with all components.
<phoe>
hm, would subclassing some existing operation work? you'd be able to put some slots in that singleton operation object thatn you can then use
<phoe>
like, (defclass my-load-op (asdf:load-op) (compilation-env)) and then some DEFMETHODs and then (asdf:oos 'my-load-op ...)
<beach>
But then I get the same singleton for each system that I compile.
<phoe>
yes, that's a pain
<phoe>
you'd need to put a hash table in that singleton or something
<beach>
I could define an operation subclass for each system I guess.
<beach>
phoe: Sure that's another possibility.
<beach>
I could put the environment in the operation, and assign to it before I call operate-on-system, but that's unappealing to me.
<phoe>
yes, that's ugly - hence me mentioning a hash table of some sort
<beach>
I understand.
<phoe>
where you can at least SETF GETHASH of some component as the key, so you don't have a single slot that you overwrite every time
<etimmons>
If you'll always pass your operation to OPERATE, you could shove it in a special variable bound around the rest of OPERATE
<etimmons>
That's basically how force works, IIRC
<beach>
That's what I do now.
<etimmons>
I see
<beach>
But then I got worried that ASDF might create a thread to do things in parallel.
<beach>
So then my special variable will no longer be bound.
s-liao has quit [Quit: Client closed]
<beach>
etimmons: I am not sure what "force" refers to.
<etimmons>
At the moment it does not use threads. And if it did, I think a lot of other things would break horribly as well
<beach>
I see.
<phoe>
beach: AFAIK it's "ignore the fact that some operations are already done/cached and re-do them"
<etimmons>
phoegot it
<beach>
Oh, OK.
<phoe>
so basically, IIUC, if :foo is loaded then (asdf:load-system :foo :force t) ignores the fact that it's loaded and re-loads it along with all dependencies, so compiling the files in full again, etc..
<etimmons>
Also, not sure how strict you want to be with compile only, but I imagine that any system with a :defsystem-depends-on actually needs to have those dependencies loaded
<beach>
phoe: Sure, but I don't see the relation between forcing and the necessity for a singleton operation.
<phoe>
beach: neither do I (yet)
<phoe>
but I assume it's a case of Chesterton's fence
<beach>
etimmons: I am willing to do some manual dependency management. It doesn't have to be all automatic.
<beach>
But I think it is more work to convince ASDF to do what I want, than to just call the compiler on a list returned by ASDF.
<etimmons>
Forcing a load-op forces the compile-op as well. So the value of the force slot would need to be copied to every instance of compile-op.
<etimmons>
ASDF can probably make sure that happens for every operation and option it knows about
<beach>
Ah, yes, that makes sense.
<etimmons>
But I imagine extending that to arbitrary user defined ops and options was deemed too hard
<beach>
Sounds plausible.
_73 has joined #commonlisp
<_73>
Is there a way that I can query for a current optimization level? For example say I set (DECLAIM (OPTIMIZE (DEBUG 3))) is there a function like GET-DEBUG-LEVEL that would return 3?
<_death>
not in the standard.. for sbcl you can look at sb-ext:describe-compiler-policy
<phoe>
or, to avoid Serapeum, trivial-cltl2:declaration-information 'optimize
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
silasfox has quit [Ping timeout: 240 seconds]
lisp123 has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
occ has quit [Ping timeout: 240 seconds]
AeroNotix has joined #commonlisp
occ has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
hobo has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
raeda has quit [Ping timeout: 256 seconds]
mon_aaraj has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
mon_aaraj has joined #commonlisp
blacked has joined #commonlisp
blacked is now known as pingpongball
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
raeda has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
morganw has joined #commonlisp
pingpongball has quit [Quit: pingpongball]
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
SR-71 has quit [Remote host closed the connection]
<phoe>
is there a LOOP variant available as a library that is actually extensible by the end user?
<phoe>
suppose I'd like to add preorder/inorder/postorder traversals for binary trees and I'd like to (loop for x inorder-in tree ...) - is there a quickloadable library that provides its own LOOP that I can extend in this way?
<phoe>
and, no, I'm not interested in ITERATE
Guest74 has joined #commonlisp
<White_Flame>
you mean one that's syntactically the same as LOOP as a basis?
<phoe>
yes - that's fully backwards-compatible with CL:LOOP but also extensible by the user
lisp123 has joined #commonlisp
<phoe>
asking because MIT LOOP is clearly written in a way that is meant to be extensible, but that extensibility is not a part of ANSI CL
<phoe>
and I am tempted to explore this area
lisp123 has quit [Ping timeout: 272 seconds]
<mfiano>
phoe: Shinmera's "for"?
<Shinmera>
that ain't LOOP compatible
<mfiano>
Oh
<Shinmera>
phoe: Only thing I can think of is SICL's loop.
<mfiano>
I misread then, sorry
<phoe>
Shinmera: hmmm
<phoe>
that's an option, yes
<Shinmera>
I *do* wish CL loop had a keyword for sequences
<Shinmera>
because then it would also automatically work with extensible-sequences
<phoe>
I know, right?
<Shinmera>
Anyway, I just use FOR in those situations :^)
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #commonlisp
<jackdaniel>
fwiw mit loop derivatives have an unexported api for extensions
<Guest74>
anybody have any thoughts on what would be useful for an input api? I'm already set on per device bindings so my touchpad click would be different than mouse or pointer or touchscreen.
hineios5 has joined #commonlisp
<phoe>
jackdaniel: yes, that is what I am thinking of
hineios has quit [Ping timeout: 260 seconds]
hineios5 is now known as hineios
mon_aaraj has quit [Ping timeout: 256 seconds]
<Guest74>
also thinking of user definable modifiers and locks for keyboards but nobody commented on that.
mon_aaraj has joined #commonlisp
<Guest74>
per keyboard keymaps.
OlCe has joined #commonlisp
<jackdaniel>
imo your questions are too vague
<Guest74>
They're general questions looking for general answers.
<Guest74>
like any thoughts on handling input whatsoever.
<Guest74>
anything you like/dislike about input apis. about how keyboards are handled, about anything input related.
<Shinmera>
I find it's more useful to design things to solve a particular problem rather than trying to design something that might solve some problems at some point.
<Shinmera>
I'll leave it at that
<Guest74>
Yes, I know what problems I'm trying to solve.
<phoe>
but we don't
<Guest74>
I'd like to know what others think as well.
<phoe>
hence the communication problem
<Guest74>
I don't know what others problems dealing with input are. How else will I know without asking?
<AeroNotix>
Guest74: 'what are you problems with input' is such a vague and broad question though
<AeroNotix>
where to begin
<Guest74>
I think in general, it's nice to have a sense of what the general problems/wants are in an area before dealing with only my needs.
<AeroNotix>
and are the problems you're solving, even related or in-scope of the problems people will have
<Guest74>
How can I know without asking?
<jackdaniel>
input should have delightful api, correct implementation and that intangible something which makes it great
<phoe>
"input" is a topic that's pretty damn broad though - starting from "why cannot I input unicode characters on this ABCL" going through "why cannot I input several megabytes of Lisp code into an emacs buffer without it locking up" finishing on "how can I capture keyboard input on SBCL from the linux terminal"
<AeroNotix>
Guest74: what are your thoughts on libinput?
<Guest74>
jd: I would expect more from a clim person who gets complaints about input.
<Guest74>
aero: that it's foreign.
<AeroNotix>
Guest74: irrelevant
<AeroNotix>
Guest74: what are the issues in the past you've had with libinput?
<jackdaniel>
well, general answer to general question ;)
<AeroNotix>
You've _used_ it right?
<phoe>
Guest74: what is the problem that you are trying to solve?
<Guest74>
handling all inputs in linux from lisp.
<AeroNotix>
because it'd be interesting for someone to develop a brand new input library without first using the existing, well-tested, thoroughly implemented and widely-used libraries which are solving the exact same problem
<AeroNotix>
additionally, "it's foreign" is a poor reason to not use something from lisp
<phoe>
what do you mean by "all inputs"? network, filesystem, terminal, Unix signals, keyboard/mouse/touchpad in X, keyboard/mouse/touchpad in Wayland, what else?
<AeroNotix>
alien code is such a dream to work with from Lisp that it has practically zero developer overhead once the alien interface libraries are learned
<Guest74>
ok, forget I asked.
<AeroNotix>
ok
<phoe>
ok
<Shinmera>
AeroNotix: it's a nightmare to work with when your memory gets fucked on, which happens to happen a lot.
<jackdaniel>
ok
<AeroNotix>
Shinmera: get good
<Shinmera>
hilarious
<Guest74>
I also think it's stupid to suggest foreign libraries in a common lisp channel.
<AeroNotix>
it's all I can suggest.. it's C at the end of the day
<AeroNotix>
it's not particularly safe
<Shinmera>
no shit
<AeroNotix>
Guest74: there's millions of lines of code written in languages which aren't Lisp
<phoe>
Guest74: if all you have is a foreign library then it makes no sense to avoid suggesting it
<AeroNotix>
if you limit yourself to using only Lisp code you are doomed to rewrite a tonne of shit unnecessarily
<Shinmera>
"it's very easy to work with" "ok here's a reason why it's not" "oh you're just not good"
<phoe>
if there's something native, then sure; if the native solution is better, then it's even more so
<Guest74>
I have lisp. What do I need a foreign library for?
<AeroNotix>
embrace foreign code and a whole world of libraries opens up to you
<Shinmera>
oh sod this I don't have time for dumb internet arguments.
<AeroNotix>
Guest74: to save your self time
<phoe>
Guest74: SSL
<AeroNotix>
Shinmera: it's easy to work with doesn't imply you don't need to be aware of a few things
<mfiano>
To save yourself time at the expense of even more future time
<AeroNotix>
Shinmera: it's why i added "when you're familiar with the interface libraries"
<mfiano>
This argument is pointless
<phoe>
there's no SSL library that's both pure-CL and good
<Guest74>
Imagine people dissuading others from building the ecosystem. I don't get this guy.
<phoe>
s/pure-CL/pure-portable-CL/
<Shinmera>
AeroNotix: programming is super easy, just don't make any mistakes :)
<AeroNotix>
Shinmera: exactly
<Shinmera>
AeroNotix: fuck off
<AeroNotix>
???
<phoe>
Guest74: "building the ecosystem" versus "using an existing library"
<phoe>
the former requires time to build and test and optimize the native CL solution, the latter doesn't
<Guest74>
using a foreign library.
<Guest74>
and I'm building the library.
<phoe>
Guest74: "building the ecosystem" versus "using an existing foreign library"
<Guest74>
So what's the problem??
<phoe>
no doubt that people prefer to go for the latter in order to save time
<phoe>
and if you're building the former, then
<phoe>
what do you mean by "all inputs"? network, filesystem, terminal, Unix signals, keyboard/mouse/touchpad in X, keyboard/mouse/touchpad in Wayland, what else?
<phoe>
I seriously want to know what do you consider to be "input"
<Guest74>
all evdev inputs
<aeth>
input -> program -> output
<aeth>
that's all you need to know :-p
<phoe>
Guest74: OK, that narrows it down a lot
<Guest74>
perhaps all user input would be better.
<aeth>
Guest74: I think if people need to use foreign libraries to handle input in a portable way, they prefer things like SDL to abstract over OS-specific interfaces.
<aeth>
This definitely skews towards certain kinds of applications, though.
<phoe>
it has a wee bit of C code though that calls ioctls and such
<aeth>
interfacing with C to interface with Linux feels like the wrong layer of abstraction unless you're going to write an elaborate set of libraries to also interface with Windows and macOS with the same API
<phoe>
...oh, wait, it does not seem like this C layer is necessary
<Guest74>
That's just a basic reader. It does not handle things like key/button bindings, languages, key macros, etc...
<phoe>
yes
<phoe>
I assume that's the part that would need to be written in CL
<phoe>
interface with /dev/input/eventX, parse the events that are received, write a higher-level layer for it
<Guest74>
and deal with things like gestures. come up with a good gesture defining api.
<phoe>
like mouse gestures?
<phoe>
or multitouch touchpad gestures too?
<Guest74>
things i don't like about cl-evdev is creating a clos class for every single event, whether you're interested in it or not.
<Guest74>
there should be some common ground for touchpad/mouse/touchscreen/pen.
<Guest74>
though some gestures might be easier for touchpad as there are special events for how many fingers are touching.
<AeroNotix>
imho the propensity for Lisp programmers to treat Lisp as some kind of higher-plane, extraterrestrial platform which solves literally any and all problems is its biggest downfall. Some Lisp programmers tend eschew all alternatives preferring to re-implement.
<AeroNotix>
It's why (imho) we've ended up with a billion and one poorly implemented, single-maintainer re-implementations of trivial basic stuff which could've been wrapped or imported from elsewhere
<AeroNotix>
so this is why I brought up libinput
<AeroNotix>
if you are even talking about an input library, you should at least look at such a widely-used thing which solves the same problem
<phoe>
Guest74: I don't understand, BINARY-TYPES:DEFINE-BINARY-CLASS only expands into a single DEFCLASS
<phoe>
so, only one class defined too
<AeroNotix>
re-implementing things as a matter of course is fine from a pegagogical perspective - but it's just poor engineering practice if you want to solve real problems
<phoe>
I still don't know what you mean by "cl-evdev is creating a clos class for every single event"
<Guest74>
instance of a class.
<phoe>
oh, an instance
<AeroNotix>
Guest74: what should it be?
<Guest74>
though it seems possible it can go to structs.
<phoe>
oh, I think I know the problem
<phoe>
you want some sort of filtering? like, to ignore some events before they are even created?
<Guest74>
but then evdev in the reader they provide then makes an instance of another class.
<Guest74>
yes, that's what I do. allow filtering of events.
<phoe>
then what's the problem with forking cl-evdev and adding that filter? should be simple enough in there I think
<Guest74>
well I'm not sure why I would when I already have all that functionality?
<phoe>
add a test before L304 that checks if the event is filtered; if yes, silently drop the event and go back to READ-RAW-EVENT; if not, then proceed with creation
<phoe>
oh wait, you already have it written?
<AeroNotix>
'why would i contribute something to the library if I have already paperd over it elsewhere' - eh?
<phoe>
no problem then, you've just NIHed another evdev accessor library
<phoe>
now that you can read evdev, what's the next sub-problem that's left to be tackled in the input library? gesture recognition and API?
<Guest74>
maybe format of state history.
<Guest74>
or format of intermediary events if different from end events served/accessible to clients.
<Guest74>
single server of events or allow clients to have their own listeners.
<phoe>
sure, I assume it would take a while to get these written in a performant way
<Guest74>
which is the problem with gestures.
<Guest74>
just having a cursor/pointer location and simple key press release isn't much of a problem.
<phoe>
so the real problem is some sort of algorithm for recognizing gestures, right?
<AeroNotix>
libinput
<AeroNotix>
at least take a look at it :)
<Guest74>
or how that should be exposed so people can write their own gestures.
<Guest74>
or maybe people aren't interested in that.
<Guest74>
and just the standard gestures are enough for them.
<Guest74>
aeronotix: what makes you think I haven't? I even have an implementation of xinput2.
<phoe>
there are some simple shapes in there; I guess some lisp code could be written to try and recognize these based on a list of e.g. mouse events
<phoe>
and then provide some sort of hook mechanism, or GF dispatch, that decides what to do on what gesture in what context
<Guest74>
yes, I already have that pdf.
<phoe>
and make that specializable by the user so they can program the behavior
pranavats has left #commonlisp [Error from remote client]
<phoe>
like (defgeneric execute-gesture (gesture window start-pos end-pos)) and so on; I don't know what would be a good lambda list for that, maybe more parameters would be needed
<phoe>
but I think that the part that accepts a list of mouse positions/events and returns a recognized gesture is kind of a black box from the end user perspective
<Guest74>
I'm not sure how that would work with something like pieces of gestures.
<Guest74>
like line-east, curve-down, line-up.
<phoe>
oh, you also need to recognize pieces? what's the use case?
<phoe>
compositing a gesture from smaller sub-shapes?
<Guest74>
For building gestures.
<phoe>
yes, I see
<Guest74>
yes, at least that's my thinking.
<phoe>
have it return a list of sub-shapes, then, and have another part of the code accept a list of sub-shapes and return some sort of "final" gesture
<phoe>
and that can be specialized upon by the end user I guess
<Guest74>
it seems that would be an easier way to 'teach' the system gestures.
<phoe>
yes, and the user could (define-gesture square mid-line-south mid-line-east mid-line-north mid-line-west) or something
<phoe>
and then attach some meaning to the gesture SQUARE
<phoe>
and the MID- is line length relative to something like screen size or something
<Guest74>
I guess then I need some method of creating a signature for each unique combination.
<phoe>
an EQUAL hash table where keys are lists of symbols? :D
<Guest74>
or just dispatch on eql keyword-of-named-gesture.
<phoe>
e.g. (mid-line-south mid-line-east mid-line-north mid-line-west)
<phoe>
where MID-LINE-SOUTH is a predefined gesture
<phoe>
most likely a library primitive
<Guest74>
I see, relative sizes might be necessary.
<phoe>
or yes, what you suggest, dispatch on SQUARE or (EQL 'SQUARE) or something
<phoe>
yes, relative sizes will be necessary
<phoe>
so you can tell apart a square from e.g. a spiral
<Guest74>
though relative to each other maybe? Because a similiar size gesture on a touchpad would be made on a touchscreen.
pranavats has joined #commonlisp
<phoe>
relative to each other makes sense, yes
<phoe>
and also you'll get to tell apart inwards spirals from outwards spirals and so on
<phoe>
concrete sizes shouldn't matter much in this case, unless it's something like "short line west" and "long line west"
<Guest74>
well, that's something to think about.
<phoe>
and I can imagine the user wanting to tell these apart
<phoe>
when they move the mouse a little versus when they make a wide swipe
<phoe>
that's what I meant by the MID- prefix
<Guest74>
yes, I can see side screen swipes being different from mid screen
<Guest74>
ok, thanks for bouncing some ideas phoe: will give me some things to think about while I'm tying keymaps to user/system defined ones.
<phoe>
ultimately you could provide the absolute total size of each gesture
<phoe>
or sub-gesture
<phoe>
and let the user do the ratios themself
<Guest74>
I'm guessing I'll just allow simple remapping using lisp chars.
<phoe>
no problem
<Guest74>
I'll certainly want to have a gui interface for that. shouldn't need to build gestures at the repl. Will give some feedback as to if the sub gestures/fragments are recognized.
<phoe>
well, you can tell the user to draw their favorite gesture
<phoe>
and then show them how it was recognized and allow them to edit it
<phoe>
if you have the recognizer then you can use it after all :D
<Guest74>
I'm not sure what you mean by edit? unless I transform the gestures into vectors?
<phoe>
make it easily editable by them in some way
<phoe>
turn it into a Lisp list or something
<Guest74>
I'll have to experiment with that. Need to add that for my drawing app anyways.
<phoe>
if someone can draw a square and get something like that, it's already much easier than typing all that by hand
<phoe>
mostly because it takes 0.5s rather than 10s
<Guest74>
that's my thinking.
<Guest74>
while on the right side of the input box is an output list of the recognized fragments.
Guest4414 has joined #commonlisp
<phoe>
I guess that gesture → printed list is a decent first approximation
<phoe>
yes
<phoe>
once you have something like that you can build something funkier
<Guest74>
that'll be the fun part. I'm a little tired of writing basements.
<phoe>
:D
<phoe>
good luck
<Guest74>
I'll need it.
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
lisp123 has joined #commonlisp
parjanya has quit [Ping timeout: 256 seconds]
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
Nselm has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
alejandrozf has quit [Remote host closed the connection]
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
wacki has quit [Quit: Leaving.]
<mon_aaraj>
hey, i am thinking of trying to use common lisp to interact with dbus, any idea how i should do it? I found 2 libraries, one with last activity being in 2010, another with latest activity in 2020, both unmaintained - or maybe libraries dont make interacting with dbus easier? what do you think?
<scymtym>
i'm pretty sure libraries make it much easier. _death's dbus library is pretty good but since it uses iolib, you may have to install "libfixposix" to use it. i can't comment on the other library
<Guest74>
the nice thing about death's, if you can get past the libfixposix is that it generates the interfaces.
<mon_aaraj>
alright! thank you very much for your input! i'll use death's library
<Guest74>
mon_aaraj: are you writing an interface or interacting with one? If the latter, which? dbus seems kinda empty.
<scymtym>
i guess freedesktop notifications is most frequently used one
<Guest74>
yeah, one of the few I noticed. I dislike notifications so that wasn't encouraging for my efforts. keep forgetting to check if pipewire has a dbus interface.
<mon_aaraj>
Guest74: I'm using dbus to try to handle tray applications
<Guest74>
ah, i thought the systray spec was x based.
<Guest74>
or you mean interacting with specific tray apps that have a dbus interface? could you provide a link? I'm always interested in desktop stuff.
Nselm has quit [Quit: Client closed]
<Guest74>
though i guess wayland stuff wouldn't be x based.
<mon_aaraj>
here's an example way to use it for trayers: https://github.com/taffybar/status-notifier-item the whole taffybar uses it to handle tray applications, and it looks like a nice way to do it
<dieggsy>
moon-child: ah, cool. thanks. ...i still feel like unbind would have made sense but something about if my grandma had two wheels lol
mon_aaraj has quit [Ping timeout: 272 seconds]
<Alfr>
dieggsy, naming it make-unbound wouldn't meet the usual expectation for functions called make-* .
mon_aaraj has joined #commonlisp
<dieggsy>
right, i see why that one doesn't make sense
<Guest74>
for sequential integers that map to keywords, I wonder at why point does a hashtable become more performant than doing (position :keyword array)? Anybody ever written any tests for this?
<Guest74>
s/why/what/
<moon-child>
which hashtable?
<Guest74>
I don't understand. one that uses keywords as keys.
<moon-child>
sure. But how is the hash table implemented?
<Guest74>
however an implementation implements it.
mon_aaraj has quit [Ping timeout: 256 seconds]
<moon-child>
I can imagine a hash table implementation for which lookups are faster in all cases than (position :keyword array), and one for which lookups are slower in all cases than (position :keyword array)
mon_aaraj has joined #commonlisp
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
<aeth>
Guest74: The documentation mentions Suse and Debian, but I can confirm that it's on Fedora.
<aeth>
And if it's on Fedora, it's (eventually) on CentOS and RHEL
<Guest74>
I can confirm it's not on ubuntus :)
cosimone has quit [Quit: ERC (IRC client for Emacs 27.1)]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
OlCe has quit [Ping timeout: 272 seconds]
<Guest74>
welp, as long as I'm not doing anything significantly wrong in my testing, eql hashtables with keywords for keys are significantly faster than using position on a simple-vector even with as little keys as 10. at least on sbcl.
mrcom_ has quit [Quit: This computer has gone to sleep]