morganw has quit [Remote host closed the connection]
hobo has quit [Read error: Connection reset by peer]
hobo has joined #commonlisp
perrierjouet has quit [Quit: WeeChat 3.4]
pillton has joined #commonlisp
igemnace has joined #commonlisp
jealousmonk has joined #commonlisp
<dbotton>
I am so in love with lisp.... it is so beyond to be update data structures and seeing your gui/web page change before your eyes or play with the gui/page and see the data change....
<AeroNotix>
sounds like react tbf
<dbotton>
when you can compile react, run it on the server side and see your changes on the client let me know :)
<dbotton>
that is also the case with presentations in CLIM
<dbotton>
at least what I gather for it
<dbotton>
of it
<AeroNotix>
dbotton: different feature altogether
<AeroNotix>
I'm aware of the existing projects CLOG models itself after
<AeroNotix>
just the gui/datastructure mirroring sounded similar to react
<White_Flame>
dbotton: yeah, I did the same thing back in the Flash days. It confused the customers ;)
<White_Flame>
we always got "yeah, well that's impossible to do" when we showed people stuff in lisp
<White_Flame>
really weird
<White_Flame>
it's undeniable cool stuff to do
<dbotton>
AeroNotix different feature CLIM and lisp object to gui linking?
<dbotton>
it is very possible I am not fully understanding presentations
<dbotton>
I admit I am having a tough time seeing its usefulness beyond this aspect of this link
<dbotton>
especially since there is no textual interface to the GUI in GNOGA
<dbotton>
sorry CLOG
<dbotton>
pl my next step with this feature is build forms quickly from data structures either at run time or in advance (which would allow customizing with the builder) so that is even closer to the Naked Objects idea
<dbotton>
anyway back to code, I am having so much fun
Lycurgus has joined #commonlisp
s-liao has joined #commonlisp
s-liao27 has joined #commonlisp
xsperry has quit [Remote host closed the connection]
Rue has joined #commonlisp
xsperry has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
perrierjouet has joined #commonlisp
s-liao27 has quit [Ping timeout: 256 seconds]
s-liao has joined #commonlisp
Rue has quit [Quit: WeeChat 3.4]
Rue has joined #commonlisp
Lycurgus has quit [Quit: Exeunt]
notzmv has quit [Ping timeout: 256 seconds]
lisper29 has quit [Read error: Connection reset by peer]
lisper29 has joined #commonlisp
lisper29 is now known as Guest8958
occ has joined #commonlisp
molson_ has quit [Remote host closed the connection]
<dbotton>
Looked back AeroNotix I was not saying anything harsh or strong regarding content about react just meant just joking lisp is cooler
<AeroNotix>
k
<AeroNotix>
don't care
<AeroNotix>
didn't even think that
<dbotton>
Text can’t tell much :)
<dbotton>
What did you mean about different features?
<AeroNotix>
browser/backend being interlinked
<AeroNotix>
i just meant the functional model is similar to how react does things
<dbotton>
Got it. Sorry thought then you were talking about clim
<dbotton>
Trying to understand how presentations is useful
<AeroNotix>
not familiar
<dbotton>
To either include or something similar
molson has joined #commonlisp
<dbotton>
So far the data gui link make sense and I like. The clicking of various graphic representations as input not understanding
<AeroNotix>
If you're making a pheonix/new rails clone, I'd err on the side of not introducing anything straying too far from that formula
<AeroNotix>
at least not on an initial release when you're trying to market it around
<dbotton>
Not what I am creating
<AeroNotix>
Seems to be
<dbotton>
It is modeled on Gnoga my Ada framework which is modeled on gwindows my Ada framework for windows so about 20 years old
<AeroNotix>
at least the features you're discussing above
<dbotton>
The basic idea is program the web in the style of a gui
<AeroNotix>
dbotton: I'm not sure that answers as many questions as you think
<AeroNotix>
there are myriad ways to program a 'gui'
<dbotton>
I know also because the model of web programming is also very different with kludges to maintain state
<dbotton>
The lower level of clog is just a widget kit
<dbotton>
What I am working on now are offering additional of the myriads of ways
<dbotton>
As you say
<AeroNotix>
alright... so it's xkcd 927 then
<AeroNotix>
any way good luck, have fun etc
<dbotton>
Good advice regarding presenting a single model though
<dbotton>
I’ll give it more thought
<dbotton>
I generally tend things to organically grow
<dbotton>
The builder is likely to be the main push though
<dbotton>
And was impetus for clog to start with
notzmv has joined #commonlisp
AeroNotix has quit [Quit: WeeChat 3.4]
<pillton>
Is it #2A((1) (2)) or #2A ((1) (2))? SLIME wants to insert the space and I am wondering if that is "right".
mon_aaraj has quit [Ping timeout: 272 seconds]
<pillton>
clhs 2.4.8.12 uses no space.
mon_aaraj has joined #commonlisp
Guest8958 has quit [Quit: Leaving]
cjb has quit [Ping timeout: 260 seconds]
<moon-child>
I would not use a space. But do whatever you like
s-liao has quit [Quit: Client closed]
occ has quit [Ping timeout: 256 seconds]
Bike has quit [Quit: Connection closed]
<beach>
Good morning everyone!
<semz>
good morning
<moon-child>
|3b|: with cl-opengl, how do I actually check if a shader compiled successfully?
<beach>
|3b|: Thank you. I'll experiment with that idea later today.
<moon-child>
I see a (defglextfun ("glGetShaderiv" get-shader-iv)), but that seems to be gles2-related; I do not have such a function defined
<moon-child>
oh, I see, I can use (gl:get-shader x :compile-status)
<beach>
In case anyone is interested. We (me and my (admittedly small) family) will arrive in Porto on Saturday March 19 and depart a week later, Saturday March 26. We will stay at Hotel ibis Porto São João which is near the conference site. We stay that long in order to get direct flights Bordeaux <-> Porto.
<beach>
If you bring your copy of Lisp in Small Pieces, the translator may sign it for you. I doubt the author will be there.
ec has quit [Quit: ec]
waleee has quit [Ping timeout: 250 seconds]
semz_ has joined #commonlisp
semz has quit [Ping timeout: 256 seconds]
igemnace has quit [Quit: WeeChat 3.4]
semz_ is now known as semz
karlosz has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
s-liao has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
mon_aaraj has quit [Ping timeout: 272 seconds]
s-liao has joined #commonlisp
mon_aaraj has joined #commonlisp
<pillton>
I really enjoyed that book. I see he has retired now.
<beach>
Yeah. He was an excellent teacher and an excellent researcher.
<pillton>
Sigh. So much to read. Alas, I can't find the pause time button.
<beach>
I know the problem.
s-liao has quit [Ping timeout: 256 seconds]
xaltsc has quit [Remote host closed the connection]
Guest74 has joined #commonlisp
stylewarning has quit [*.net *.split]
molson has quit [*.net *.split]
pillton has quit [*.net *.split]
mon_aaraj has quit [*.net *.split]
karlosz has quit [*.net *.split]
tyson2 has quit [*.net *.split]
perrierjouet has quit [*.net *.split]
edgar-rft has quit [*.net *.split]
psf has quit [*.net *.split]
cross has quit [*.net *.split]
hineios has quit [*.net *.split]
thomaslewis has quit [*.net *.split]
gpiero_ has quit [*.net *.split]
mister_m has quit [*.net *.split]
ullbeking_ has quit [*.net *.split]
Posterdati has quit [*.net *.split]
dbotton has quit [*.net *.split]
Colleen has quit [*.net *.split]
froggey has quit [*.net *.split]
danieli has quit [*.net *.split]
Shinmera has quit [*.net *.split]
stack1 has quit [*.net *.split]
russe has quit [*.net *.split]
les_ has quit [*.net *.split]
TMA has quit [*.net *.split]
hubvu_ has quit [*.net *.split]
materialfuture has quit [*.net *.split]
skyl4rk has quit [*.net *.split]
stylewarning has joined #commonlisp
karlosz has joined #commonlisp
mon_aaraj has joined #commonlisp
thomaslewis has joined #commonlisp
pillton has joined #commonlisp
molson has joined #commonlisp
perrierjouet has joined #commonlisp
les_ has joined #commonlisp
stack1 has joined #commonlisp
dbotton has joined #commonlisp
danieli has joined #commonlisp
tyson2 has joined #commonlisp
skyl4rk has joined #commonlisp
hineios has joined #commonlisp
materialfuture has joined #commonlisp
hubvu_ has joined #commonlisp
TMA has joined #commonlisp
russe has joined #commonlisp
Shinmera has joined #commonlisp
edgar-rft has joined #commonlisp
cross has joined #commonlisp
gpiero_ has joined #commonlisp
psf has joined #commonlisp
froggey has joined #commonlisp
Colleen has joined #commonlisp
mister_m has joined #commonlisp
Posterdati has joined #commonlisp
ullbeking_ has joined #commonlisp
hirez has quit [Quit: Later]
Inline has quit [Quit: Leaving]
bldr has quit [*.net *.split]
nckx has quit [*.net *.split]
bldr has joined #commonlisp
nckx has joined #commonlisp
jeosol has quit [Ping timeout: 256 seconds]
hirez has joined #commonlisp
gxt has quit [*.net *.split]
anticomputer has quit [*.net *.split]
azimut has quit [*.net *.split]
wyrd has quit [*.net *.split]
azimut has joined #commonlisp
anticomputer has joined #commonlisp
gxt has joined #commonlisp
hirez has quit [Quit: Later]
wyrd has joined #commonlisp
silasfox has joined #commonlisp
aartaka has quit [Ping timeout: 256 seconds]
aartaka has joined #commonlisp
jealousmonk has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 27.1)]
tyson2 has quit [Remote host closed the connection]
occ has joined #commonlisp
karlosz has quit [Quit: karlosz]
shka has joined #commonlisp
hirez has joined #commonlisp
igemnace has joined #commonlisp
<lisp123w>
dbotton: Thanks for the info, sounds good
<lisp123w>
beach: Would you say the Cluffer API is final?
<_death>
iirc it needs a way to efficiently erase a buffer
spiaggia has joined #commonlisp
<lisp123w>
beach: thanks
<lisp123w>
_death: cool, so perhaps something like erase-buffer will get added in the future
<lisp123w>
But for now, I'll just use that as a final list when comparing to LW or other editors I may try ipmlement (UITextField)
<_death>
the way I dealt with it back then was replacing the buffer wholesale
<spiaggia>
It sounds to me like such a thing could be implemented using the existing protocol.
<_death>
spiaggia: maybe I missed an operator?
<spiaggia>
I mean, you can just delete every line.
<_death>
then you need to delete them one by one (glancing at package.lisp I also don't see an operator to delete a line.. just items.. if so, line deletion means deleting item by item..)
<_death>
an erase-buffer would just amount to clrhash or two and be done with it
mon_aaraj has quit [Ping timeout: 256 seconds]
<_death>
maybe if it had operations on regions then such primitives wouldn't be needed
<spiaggia>
That's probably not true because of the update protocol.
mon_aaraj has joined #commonlisp
iamFIREc1 has quit [Ping timeout: 260 seconds]
iamFIREc1 has joined #commonlisp
hirez has quit [Quit: Later]
<spiaggia>
OK, so let's take this from the beginning.
<spiaggia>
It is not possible to just delete a line, because a time stamp has to be left in the buffer.
<spiaggia>
So the way line is deleted is to remove its contents and the merge it with the previous or the next line.
<spiaggia>
It is possible that the protocol doesn't have an operator for removing every object in a line, and it would be somewhat inefficient to do that item by item.
<spiaggia>
But such an operator can be added and it would be efficient.
<spiaggia>
Then you can add a DELETE-LINE operator that erases the contents and then merges the line.
<spiaggia>
But, I am thinking about the CLIM II specification that distinguishes between the "protocl" and the "API".
<spiaggia>
I think the protocol is the fundamental part, and there could be functions in the API that can (but don't have to) be implemented using the protocol functions
<spiaggia>
So the protocol is stable, but, sure, we might add functions to the API.
<spiaggia>
Feel free to suggest such functions and send me a pull request. But don't do it without taking the update protocol into account.
<spiaggia>
_death: Does that make sense?
<_death>
I feel that if the protocol doesn't support doing something efficiently, then you'd have a hard time writing an efficient "API" that makes use of it.. but I will need to re-read your protocols (especially the update protocol, which I didn't take into account at the time)
<spiaggia>
And feel free to implement an ERASE-BUFFER, but make sure you leave a time stamp.
<spiaggia>
_death: Recall "(but don't have to)".
<_death>
ok, but ideally you'd want to implement everything in terms of a protocol
<spiaggia>
You can erase the entire buffer in one go as long as you leave a time stamp.
<spiaggia>
No, why do you say that?
<spiaggia>
That's just a way to specify simple semantics.
wacki has joined #commonlisp
<_death>
that is the way I try to design my protocols.. so that I can implement things efficiently without fighting them or going around them
<spiaggia>
And there could be default implementations that use the protocol, but they don't have to be the final ones.
<spiaggia>
*sigh*
<spiaggia>
The update protocol makes it very efficient to erase by item, so even erasing the entire buffer item by item is not going to be very costly
attila_lendvai has joined #commonlisp
occ has quit [Ping timeout: 250 seconds]
<_death>
I hope I don't frustrate you too much :) my personal conclusion is that I need to do more research into the matter
<spiaggia>
You want me to take a PR for ERASE-BUFFER and declare that it's part of the protocol? Fine I'll do it
<Guest74>
delete-line seems like something so well named for specifically deleting lies, which seems like something that really should be part of a protocol.
<spiaggia>
You want me to take a PR for DElETE-LINE and declare that it's part of the protocol? Fine, I'll do it.
<_death>
spiaggia: no, I want to understand your protocols better
<spiaggia>
_death: OK, feel free to ask questions if you have any.
<_death>
and it's true that I didn't benchmark deleting item by item and an alternative
<spiaggia>
I carefully designed the protocol so that (say) deleting a region could be done relatively efficiently by doing it item by item.
<_death>
did you estimate typical bounds for the number of items?
<spiaggia>
But I probably didn't implement the DELETE-REGION API (or "protocol" if you prefer) function. I also didn't make things like UPCASE-REGION part of the protocol. I am sure someone will fell that particular operation is so fundamental it must be part of the protocol.
<spiaggia>
_death: The application is text editing, so imagine a big (but not huge) text file.
occ has joined #commonlisp
<spiaggia>
I said "text" editing, but in fact the buffer can contain any object.
<_death>
I usually think 100M (but probably 10M is closer in practice)
<spiaggia>
_death: It is my hunch (feel free to do the calculation) that updating a GUI window as a result of any amount of editing in a buffer is going to be more costly than deleting the entire buffer by item.
<spiaggia>
_death: I also don't see you deleting 100MB buffers at typing speed
<moon-child>
on the gpu, rendering is free
<Guest74>
lol, no
<spiaggia>
Who said anything about rendering?
<_death>
spiaggia: well, I used cluffer as a sort of window buffer, that's not always meant to be for interactive use.. so I might want to insert or delete many items at once.. so I had a clear-window operation where I wanted to erase the whole buffer
<spiaggia>
I am talking about invoking the update protocol, incrementally parsing the buffer contents using Eclector, then invoking Cleavir to analyze the new contents, then determine the position and color of every character
<_death>
spiaggia: would you say that I mistook cluffer for my purpose?
<moon-child>
sorry, I am not quite awake, and should probably go to sleep soon
<spiaggia>
_death: Then Cluffer is probably overkill. It was specifically designed to be an efficient substrate for things like editing Common Lisp code. It can be used for simpler things of course, but it was not designed for deleting 100MB buffers at typing speed
<spiaggia>
I mean "deleting one 100MB buffer each time you hit a key".
<_death>
spiaggia: there actually was an editor-window that allowed you to do text editing..
<spiaggia>
Where?
cosimone has joined #commonlisp
cosimone has quit [Remote host closed the connection]
<spiaggia>
Sure, like I said, it can be used for simple editing tasks.
aeth has joined #commonlisp
hirez has joined #commonlisp
<jackdaniel>
wasn't cluffer described as a general purpose text-editor buffer?
<spiaggia>
I'll change the description if you like.
<jackdaniel>
I don't mind if you don't, I'm just surprised given the above discussion
cosimone has joined #commonlisp
<jackdaniel>
raising doubts is not the same thing as disagreeing - I think that it is an important distinction
<spiaggia>
Let me say this one more time. Cluffer was carefully designed to be efficient with single-item operations, at least compared to any other operation that would need to be done at typing speed in a typical text editor.
<spiaggia>
But every design has compromises and one such compromise that that you can not reasonably delete one 100MB buffer for each keystroke at typing speed. Now, if you think that that's what you need, I personally don't think of that as a "general-purpose text-editing" requirement.
ante_ has joined #commonlisp
ante_ has quit [Client Quit]
Cymew has joined #commonlisp
<spiaggia>
I mean, "you can not delete a 100MB buffer..." using single-item operations. But it is trivial to add such an operation.
<spiaggia>
I even think the internal protocols expose the operations to do so.
<jackdaniel>
I've used cluffer and I agree, I was rather referring to "cluffer was designed specifically (...) to edit cl code"
<jackdaniel>
perhaps it was just unfortunate phrasing
amb007 has quit [Ping timeout: 272 seconds]
<jackdaniel>
or unfortunate interpretation
Guest74 has quit [Quit: Connection closed]
<spiaggia>
Yes, because any simpler design would not be adapted to that use case. I didn't use "exclusively" I said "specifically".
amb007 has joined #commonlisp
<jackdaniel>
I see
Dynom has joined #commonlisp
spiaggia has quit [Quit: ERC (IRC client for Emacs 26.3)]
cosimone has quit [Read error: Connection reset by peer]
cosimone has joined #commonlisp
s-liao has joined #commonlisp
random-nick has joined #commonlisp
Krystof has joined #commonlisp
Cymew has quit [Ping timeout: 272 seconds]
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
occ has quit [Ping timeout: 272 seconds]
occ has joined #commonlisp
treflip has joined #commonlisp
treflip has quit [Client Quit]
pve has joined #commonlisp
<beach>
|3b|: Perfect! Thanks again!
<beach>
|3b|: I will modify it a bit because I need to remove files of type STATIC-FILE and keep only Common Lisp source files.
rgherdt_ has joined #commonlisp
razetime has joined #commonlisp
mgl has joined #commonlisp
mon_aaraj has quit [Ping timeout: 252 seconds]
silasfox14 has joined #commonlisp
mon_aaraj has joined #commonlisp
occ has quit [Ping timeout: 272 seconds]
hhdave has joined #commonlisp
<phoe>
beach: I will be available in Porto from Sunday til Wednesday (inclusive), except on Sunday I will want to do an on-site test of the recording/streaming facilities
<phoe>
but that should not take long
<beach>
Great! Looking forward to seeing you again!
<phoe>
same :D been a long while
<beach>
Yeah.
occ has joined #commonlisp
attila_lendvai has quit [Quit: Leaving]
occ has quit [Read error: Connection reset by peer]
hhdave has quit [Quit: hhdave]
attila_lendvai has joined #commonlisp
attila_lendvai has quit [Client Quit]
attila_lendvai has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.4]
s-liao has quit [Quit: Client closed]
hhdave has joined #commonlisp
MajorBiscuit has joined #commonlisp
s-liao has joined #commonlisp
kurth4cker has joined #commonlisp
mon_aaraj has quit [Ping timeout: 252 seconds]
mon_aaraj has joined #commonlisp
frgo has quit [Ping timeout: 245 seconds]
<SR-71>
Are there any alternatives to StumpWM?
<beach>
There is a window manager called Eclipse, but I don't know how much it has bitrotted.
<beach>
It is not a tiling window manager like StumpWM. More like an ordinary window manager.
<SR-71>
I wonder, how much work is it creating a windowing system entirely in CL
<beach>
Depends on how much functionality you consider part of the windowing system.
<SR-71>
Display drivers would always be an issue.
pillton has quit [Quit: ERC (IRC client for Emacs 27.2)]
<beach>
If you are interested in stuff like that, I recommend you join #clim. The people there know quite a lot.
<SR-71>
thanks, i'll check it out
<beach>
SR-71: McCLIM has a framebuffer backend, but I don't know whether you consider that cheating.
<SR-71>
beach: My GPU drivers would not like that..lol
<scymtym>
for window managers (not entire windowing systems), there is also https://github.com/admich/Doors which is window manager and desktop environment in CL based on McCLIM
hhdave has quit [Quit: hhdave]
s-liao has quit [Quit: Client closed]
<SR-71>
sc
<SR-71>
scymtym: This looks cool.
<SR-71>
I'm currently using i3, I wanted more control over my workflow.
<SR-71>
Checked out xmonad, But lisp has it's own cham.
<SR-71>
*charm
wmblathe_ has joined #commonlisp
wmblathers has quit [Ping timeout: 245 seconds]
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
Lycurgus has joined #commonlisp
<beach>
Eclipse uses CLX directly. Using McCLIM seems like a better idea.
<jackdaniel>
frame-manager is the right abstraction to specialize for writing a window manager
<jackdaniel>
then "foreign" windows would be represented as something like foreign-sheet class
hhdave has joined #commonlisp
parjanya has quit [Ping timeout: 250 seconds]
ASau has quit [Read error: Connection reset by peer]
ASau has joined #commonlisp
silasfox has quit [Ping timeout: 250 seconds]
silasfox has joined #commonlisp
<mfiano>
It would be nice if we had a modern book/other resources on using the MOP to build interesting things. AMOP is quite dated, and the technical writing style very poor. I wish we had more books like Let Over Lambda but for the MOP, as it's sort of the other side of the same coin...extending the language beyond syntax.
<mfiano>
I've been looking, but resources seem to be scarce.
theBlackDragon has quit [Ping timeout: 256 seconds]
Brucio-61 has quit []
mgl has quit [Quit: Client closed]
theBlackDragon has joined #commonlisp
<phoe>
mfiano: please give me ideas and pointers for CLR2's new MOP chapter
<mfiano>
I have none other than the one you already know about, which is why I wanted to read about the topic.
<phoe>
#commonlisp: please give me ideas and pointers for CLR2's new MOP chapter
<phoe>
I might announce the hunt for MOP recipes on Planet Lisp and Twitter actually
rogersm has joined #commonlisp
* phoe
adds to TODOs for today
<jackdaniel>
adding new properties to slots like "required", "presentatin-type" and "encrypted"
<mfiano>
I think the topic deserves its own book, assuming there are enough ideas, to complement LOL
<mfiano>
People don't give the MOP enough credit over macros. They both extend the language in amazing ways.
<jackdaniel>
well, macros give you what you write while mop extensions often have ingrained performance penalty
<jackdaniel>
(when the implementation can't assume standard-<something> then it can't perform certain optimizations)
<mfiano>
That's sort of orthogonal though.
<jackdaniel>
to the question why macros are more popular than mop extensions?
<mfiano>
They both extend the language, yet most people are scared of the MOP, or know very little about it.
<mfiano>
I'd like to see it used more, talked about more, written about more...
<Lycurgus>
i think it's prolly more uncertainty about implementation status and history vs ready thing
<Lycurgus>
and there's considering OO obsolete
<mfiano>
Well I know why macros are more popular. For Common Lisp, I think the MOP can solve some remarkable problems, just like macros can. I think they complement an already very flexible language very well.
<Lycurgus>
or just antiquated
<mfiano>
OO is not a very well defined term.
<Lycurgus>
it used to be
<Lycurgus>
e.g. polymorphism, encapsulation, and inheritance
<mfiano>
You'd have a hard time using CL without using one definition of OOP, be it user-defined or builtin classes, or generic functions. Encapsulation means something much different in CL, and inheritance is handled different than most other languages too.
<Lycurgus>
it's the most baroque OO
<Lycurgus>
macros are the scruffy
<mfiano>
Ok
aartaka has quit [Ping timeout: 250 seconds]
<mfiano>
I dislike the newer attempts at generic functions, like Guile GOOPS, Julia, Rust, and some others. None of these provide a protocol. It's more like arity/type overloading.
<Lycurgus>
i wonder how sopel compares to maiden (common lisp)?
<Lycurgus>
sorry meant that for another channel
<mfiano>
If my protocol accepts a different arity than I specify I would cry.
<mfiano>
It's probably just bias. I can't imagine programming without a strict arity protocol though, and especially not class-centric OOP.
<phoe>
jackdaniel: will do
<mfiano>
Anyway, I was just browsing for my next book to read, after CLCS which I will be starting this week in my free time.
scymtym has quit [Remote host closed the connection]
Lycurgus has quit [Quit: Exeunt]
mon_aaraj has quit [Ping timeout: 272 seconds]
mon_aaraj has joined #commonlisp
igemnace has joined #commonlisp
mgl has joined #commonlisp
kurth4cker has left #commonlisp [ERC (IRC client for Emacs 27.2)]
Cymew has joined #commonlisp
aartaka has joined #commonlisp
tyson2 has joined #commonlisp
treflip has joined #commonlisp
<random-nick>
I thought GOOPS was pretty similar to CLOS?
Bike has joined #commonlisp
<mfiano>
random-nick: It has its differences, notably the lack of a strict protocol
Rue has left #commonlisp [WeeChat 3.4]
mepy has quit [Ping timeout: 250 seconds]
<mfiano>
From the Guile manual: "generic function are not obliged to have a fixed number of parameters"
<jackdaniel>
one example could be commands - they have typed arguments that ought to be parsed (by some processor), so inquiring the function for these types is convenient if they are stored with the object
<jackdaniel>
mcclim currently has a hash table for that, but it is one of planned improvements
<phoe>
but I have no idea if it is a good example
mon_aaraj has quit [Ping timeout: 252 seconds]
<phoe>
since in theory I could (defun run (petri-net &key compress ignore-errors) ...) and export RUN
<phoe>
and instead of that the net instances themselves are funcallable
<Bike>
i wonder if you could like... you could have a regex library that makes parser functions (like ppcre), but have the functions store information about the DFA so you can concatenate two parsers to get a parser for the concatenated language, etc
mon_aaraj has joined #commonlisp
<phoe>
the issue with funcallable instances are that they solve only one problem - the inability to FUNCALL arbitrary objects
s-liao has joined #commonlisp
<phoe>
s/are/is/
<jackdaniel>
I don't understand how that is an issue (and they don't solve it, you still can't funcall an arbitrary object)
<phoe>
jackdaniel: the issue of "how does one use them in practice and why and how useful are they"
<phoe>
and, yes - arbitrary is a wrong word here, more like FUNCALL not being extensible to user-provided objects
<jackdaniel>
so the issue with apl is that I can't use it?
<jackdaniel>
or is it an issue with me?
<phoe>
clarifying again: the issue is that IMO there are few good and convincing examples of how and why to use funcallable instances - GFs are probably the most convincing one, and then there's a question, "okay, and what else?"
<jackdaniel>
another example I have incorporated in a pet project once was a funcallable that checked the status of an external resource and accumulated results
waleee has joined #commonlisp
<phoe>
oh, interesting - so funcalling the instance caused some results to get added inside its slots?
<jackdaniel>
yes, and they could have be retrieved with a reader (i.e to display a health chart)
* phoe
takes notes
<jackdaniel>
the object also maintained url, some credentials and such
<phoe>
looking from this point of view, a Petri net also looks OK as a funcallable, since it can call other code itself and accumulate results inside itself
<phoe>
or possibly any other state-machine-esque construct
<scymtym>
emitting code like (funcall (load-time-value (register-funcallable-object (make-instance 'my-funcallable-object))) …) gets pretty close to an inline cache or, more generally, a relatively efficient way of allow subsequent updates to code
<jackdaniel>
another made-up example is having a funcallable that implements a processor running in a separate thread (in a loop) - partial results and messages could be stored in atomically updated slots and the caller could probe them
<mfiano>
Interesting ideas.
hhdave has quit [Quit: hhdave]
hhdave has joined #commonlisp
aartaka has quit [Ping timeout: 240 seconds]
frgo has joined #commonlisp
yewscion has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
frgo has quit [Ping timeout: 240 seconds]
<dbotton>
phoe there seems to be on net 2 cook books the one on the internet and a book one, the clr2 you are working on is a version 2 of which?
<jackdaniel>
'common lisp recipes' is a book originally written by Edmund Weitz (you may buy a paper version too)
<jackdaniel>
I believe that phoe works on a second edition (and it is a little confusing to me authorship wise)
<phoe>
dbotton: Common Lisp Recipes, 2nd Edition
<dbotton>
ok, I like that book helped me get started
<phoe>
jackdaniel: Edi Weitz is the author of the first edition, I'm responsible for the writing the second edition
<jackdaniel>
yes, I get that part
<phoe>
what's the confusing part then?
<jackdaniel>
I don't think I've encountered such arrangement that someone else than the original author wrote a second edition of a book
<jackdaniel>
(except this one of course)
<phoe>
it's certainly interesting, speaking from my point of view
<dbotton>
I was offered to write some peter norton books (pre-stroke and a lot younger)
<dbotton>
happens
kevingal has joined #commonlisp
lisp123 has joined #commonlisp
<lisp123>
Did Edi Weitz write most of the original cookbook too?
travv0 has joined #commonlisp
dbotton has quit []
dbotton has joined #commonlisp
<phoe>
lisp123: the CVS logs of the original cookbook seem to mention him a lot
<lisp123>
phoe: Got it
yagamisa1o has joined #commonlisp
treflip has quit [Remote host closed the connection]
_73 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
<_73>
Using DEFPACKAGE, is it possible to import symbols from multiple packages with one :IMPORT-FROM clause, or must each package get its own :IMPORT-FROM clause? Example: http://dpaste.com/9S3KBQB9F
<Bike>
yeah, looks like only one package per clause
<_73>
ok thanks
razetime has joined #commonlisp
Brucio-61 has joined #commonlisp
Guest74 has joined #commonlisp
Catie has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
karlosz has joined #commonlisp
<Guest74>
SR-71: 'display drivers' aren't really an issue unless you're writing an entire kernel and OS. If we take wayland as an example, all you really need is a way to handle input and a way to distribute buffers. Not a terrible amount of work, but definitely more than one person can handle quickly as I can attest to that.
<Guest74>
as for a simple window manager, I have a simple one written in ~500 loc. Though the one I currently use is quite a bit larger.
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
<scymtym>
Guest74: but wayland expects the client to do its own drawing so in addition to pushing buffers around (or sharing the memory) the clients needs a software rasterizer or something like OpenGL bindings
<Guest74>
true, but that isn't really part of a windowing system. But it's the reason why I've also got a drawing api for surfaces, such as raster buffers.
<Guest74>
or at least it's not part of wayland, and very many people were upset there is an ancient decaying drawing system attached to x11.
silasfox14 has quit [Quit: silasfox14]
<Guest74>
I do wish I could talk to the kernel in lisp, but until we have a lisp kernel it seems like ioctls to the linux kernel will have to be a necessary interface. My hope is that once I've got that done, creating a dumb buffer for use with wayland will be as simple as getting an x11 window, surface:create .
<scymtym>
why do you have to talk to the kernel to create a buffer for wayland? do you want to avoid the POSIX shared memory stuff?
<Guest74>
unless you want to use a foreign library, you need to talk to the kernel to manage them and handle things like resolution changes.
<scymtym>
ah, so frame buffer, not a buffer that backs a wayland surface
<Guest74>
I'm not sure if you can ask wayland to create the dumb buffer for you and give you an address to map. But seeing as how I'm writing the window system, I'd have to ask myself.
<scymtym>
i think the clients allocates the buffer via the share memory system and passes a file descriptor as ancillary data of a socket message
waleee has quit [Ping timeout: 272 seconds]
<scymtym>
(that's what i implemented, following the examples in C)
<Guest74>
ah, so easier for the client if you don't have to actually create the scanout buffer. Wish there was a simple way of passing file descriptors over sockets as well.
Inline has joined #commonlisp
<Guest74>
did you write the cl-wayland stuff?
<scymtym>
no, isn't that one ffi-based?
<Guest74>
I can't remember if that's what it was called tbh.
<Guest74>
Yes, there was one all ffi
<Guest74>
any links to code to see how you did the fd passing? I think it'd be usefull to have that for adding shared memory drawables to clx.
rogersm has quit [Remote host closed the connection]
<Guest74>
it's the onlymissing link for the mit-shm extension.
attila_lendvai has quit [Ping timeout: 252 seconds]
rogersm has joined #commonlisp
<Guest74>
i.e., I have the extension already written, just no way to pass the fd.
<scymtym>
the code is not public at the moment, but i basically use just enough ffi (no foreign library, though) to be able to call sendmsg with the required arguments. in principle, usocket or sb-bsd-sockets could be extended to provide this functionality
<Guest74>
that would be my hope. I don't like using cffi. But interfacing with the os through and implementation seems necessary to me.
<Guest74>
unfortunately, all examples are usually in C and my brain didn't really comprehend it.
lisp123 has joined #commonlisp
<Guest74>
I've just put it off hoping someone else would do it. hint hint
<scymtym>
yeah, fd passing seems needlessly complicated since, as far as i can tell, the caller is also forced to use the scatter/gather interface for the socket message
lisp123 has quit [Ping timeout: 272 seconds]
attila_lendvai has joined #commonlisp
karlosz has quit [Quit: karlosz]
<random-nick>
if you wanted to use graphics drivers you'd also have to use libdrm and mesa to make framebuffers and compose them
<random-nick>
the first one might have ffi bindings in quicklisp
<Guest74>
or drm ioctls, which is what I do.
<random-nick>
the other one, I'm not sure how much you need apart from the usual opengl calls which are wrapped with cl-opengl I'm guessing
<random-nick>
ah yes, I guess libdrm is just a wrapper for a bunch of ioctls
<Guest74>
plus a bunch of stuff to make an api that makes sense for them, i.e. c/c++ users.
<random-nick>
for input, wayland compositors almost universally use libinput, and I think Xorg uses it now, but it seems to be an entire input system and not just a wrapper for kernel interfaces, so I'm not sure how feasible it is to write pure CL input code instead of FFIing into libinput
<Guest74>
For basic input, pure cl isn't a problem. I've got most of that.
<Guest74>
reading properties or testing how many buttons a device has might need some evdev ioctls.
<Guest74>
though it seems a lot of the information might be in the /proc subsystem, but I haven't fully explored if I can get all the information from there.
yewscion has quit [Ping timeout: 252 seconds]
<Guest74>
Either way, I plan on have a pure cl interface, as well as augmented by evdev ioctls.
<random-nick>
I think /sys is supposed to be used and /proc is just for compatibility, I'm guessing you can usually use regular CL file operations on them
fitzsim has quit [Remote host closed the connection]
<random-nick>
but for opengl, I'm pretty sure you have to use ffi
<Guest74>
strange, everything I typed just disappeared.
<Guest74>
anyways, /proc contains a bunch of information from /sys in one file as opposed to across multiple subdirectories with sometimes recursive links.
<Guest74>
I haven't had time to check if the information is more complete in sys.
<|3b|>
i think for GL you could theoretically use GLX without FFI, but might be hard to get full performance, and might require X as well
<Guest74>
I haven't been able to get glx in clx to work. But admittedly I didn't try very hard.
<|3b|>
as far as i know, that is ancient in addition to any theoretical limits on performance/features :) though i haven't heard anything about it in ages, so maybe someone fixed it up
<|3b|>
don't think it even had textures last i heard
<random-nick>
I thought we were discussing writing something like a display server in CL?
<Guest74>
adding more modern features isn't a problem, there's an xml file out there with most of the new stuff. I just couldn't get any part of it to work. But didn't know if it was because I have an nvidia card.
<random-nick>
because with X11, you can just use a socket to ask the X server for buffers and inputs, no ioctls needed
* |3b|
usually wants absolute latest features from GL, and max performance (so i can be lazy about my code when experimenting but still be interactive), so never was really interested in glx
<Guest74>
I've wondered how slow it would actually be if you've got a large mmap'd buffer to send commands over, which are basically just some int followed by args.
<Shinmera>
FWIW, I haven't had any issues with the cl-opengl bindings. The issues I have had would not have been solved by using a non-ffi protocol, either (corrupt data, driver problems)
<Guest74>
random-nick: in my head at least I think a lisp window display manager would swallow both wayland and x11.
<|3b|>
Guest74: yeah, that's the part i wasn't sure if you can do with GLX to make it competitive
treflip has joined #commonlisp
<|3b|>
using shared mem instead of sockets i mean
<random-nick>
cl-opengl is (at least partially) generated from specification files
<|3b|>
though also working without x
<Shinmera>
I'm aware. Just saying that in this particular case I don't mind that it's doing it through FFI
<Shinmera>
Usually I'm wary of FFI because I know how nightmarish debugging that stuff can get.
<|3b|>
doing GL without X/wayland on linux is annoying though, not sure if trying to do so without FFI to wrapper libs would make it better or worse :p
<Guest74>
opengl seems to be very server/client that i've wondered if you could just get an address to dump commands into and just have lisp package up the simple format.
frgo has joined #commonlisp
<|3b|>
doesn't help that nobody can agree how everything works, so you will need like 3 backends :/
<Guest74>
well now that nvidia seems to finally be getting behind gbm, might be able to find out soon...ish.
<random-nick>
you generally can't use opengl on linux without interfacing with a C library, since it's implemented in userspace and the userspace is written in C
<random-nick>
well, that is of course if you don't reimplement mesa in CL
<|3b|>
yeah, at least it is a relatively nice C library :)
* |3b|
wonders if talking to systemd over a socket is considered better or worse than FFI to some C lib :)
<Guest74>
I just wonder in general if glx works at all anymore. I should probably find something that uses it and try that. I think it would be nice to at least get clx to be able to create and attach contexts to windows.
<Guest74>
3b: just replace systemd with a lisp system and done.
<|3b|>
i suspect it would take some hacks to mix non-ffi clx with ffi cl-opengl
* |3b|
also suspects a non-ffi lisp version of xcb might have better luck, but not sure i have any real basis for either suspicion :)
<Guest74>
ugh, that'd probably mean I need a copy of sharplispers clx.
<random-nick>
well presumably you have to modify cl-opengl in order to use the GLX calls
_73 has left #commonlisp [ERC (IRC client for Emacs 27.2)]
<|3b|>
nah, don't think there is anything in cl-opengl to modify
<random-nick>
also, I don't know if there was any work done on using the xcb xml specs in clx, you can ask in #clim
<|3b|>
(unless you want to replace cl-opengl's ffi with glx's network connection)
<jackdaniel>
random-nick: it was only discussed that it would be a) cool, b) less error prone
<|3b|>
and most serious cl-opengl use depends on ffi anyway
<jackdaniel>
but nobody volunteered to do that :)
<|3b|>
since nobody managed to make a magical "translate formats of huge buffers of octets into foreign memory without any overhead" library
<|3b|>
would you really want to stay using the CLX API, or could you make a better one given the abstractions in the xcb specs, like the C xcb vs c xlib?
<Guest74>
random-nick: I already have a parser for the xml.
<jackdaniel>
|3b|: compilation of xml files to request definitions doesn't contradict either
<jackdaniel>
s/either/neither/
<Guest74>
I just mentionned the sharplispers because my fork is sufficiently different that it's bothersome to contribute to sharplispers which everybody uses.
<jackdaniel>
but no, that discussion didn't go beyond "it would be totally doable and cool"
<|3b|>
jackdaniel: yeah, i guess improving clx internals is good either way :)
<jackdaniel>
I imagine that the old api could be retained as a legacy one and a new one could be provided under a separate package
<jackdaniel>
i.e xlib vs xcb
<random-nick>
along with getting all the xorg extensions for free, presumably
<Guest74>
though it doesn't have all the extensions. it has the ones people bothered to write xml for.
<Guest74>
and it's not much use for adding interesting extensions to clx since it requires a reworking of clx's buffer code.
MajorBiscuit has quit [Ping timeout: 252 seconds]
<jackdaniel>
I gather that it is not splendid given that it is inherited from a 1987 codebase, but whether extensions will work is an orthogonal issue, isn't it?
cage has joined #commonlisp
hhdave has quit [Ping timeout: 272 seconds]
rotateq has joined #commonlisp
yewscion has joined #commonlisp
<Guest74>
no. the buffer code is nice but it was specifically designed to work with the protocol, not with the later hacks to force things like large requests/events and multiple events for the same event code.
<Guest74>
I mean, it led me to question how much I need x11, hence all this interfacing to the kernel for input and buffers.
attila_lendvai has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
kevingal has quit [Remote host closed the connection]
<jackdaniel>
afair there is only a bigrequest extension and then if it is still to small then requests are send in chunks (and that it is not clx specific limitation)
lisp123 has joined #commonlisp
<Guest74>
big requests doesn't affect big receives.
<Guest74>
I don't remember specifically, but there were issues with big requests as well. I think I disabled them and left some comments.
<Guest74>
it also doesn't change the fact that things like the kbd extension either have normal kbd events, or larger ones, and clx doesn't know how to deal with that.
<jackdaniel>
clx doesn't know how to deal with many things, I wass curious why clx wouldn't work with extensions generated from an xml file
<jackdaniel>
s/wass/was/
<Guest74>
it works fine for the extensions that don't register more than one event or which put length as 0 and put the real length somewhere else.
<Guest74>
unfortunately, that's pretty much all the extensions we already have. ...though I haven't tested the generated glx extension.
cuz has joined #commonlisp
SR-71 has quit [Remote host closed the connection]
<Guest74>
oh, right, big requests needed larger buffer indices,card32, while all clx depended on card16 indices. which doesn't seem like a big thing, but it was pretty jammed in there.
lisp123 has quit [Remote host closed the connection]
<jackdaniel>
I see
karlosz has joined #commonlisp
utis_ has quit [Ping timeout: 240 seconds]
hhdave has joined #commonlisp
utis has joined #commonlisp
<Guest74>
it wasn't something I gave up on lightly. After a while it just seemed like less work to write something from scratch that could encompass x11 and wayland than to try and rewrite clx to work with extensions that were crammed rather inelegantly into the x11 protocol. I mean, xkb is a mess, and so is xinput.
<random-nick>
xinput2 too?
cuz has quit [Ping timeout: 252 seconds]
<Guest74>
yeah, that's what I meant.
tfeb has joined #commonlisp
mgl has quit [Quit: Client closed]
tfeb has quit [Quit: died]
cuz has joined #commonlisp
ec has joined #commonlisp
cuz has quit [Ping timeout: 240 seconds]
silasfox has quit [Quit: WeeChat 3.4]
cuz has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
treflip has quit [Remote host closed the connection]
eugercek has joined #commonlisp
jealousmonk has joined #commonlisp
travv0 has left #commonlisp [#commonlisp]
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
attila_lendvai has quit [Ping timeout: 250 seconds]
Guest74 has quit [Quit: Connection closed]
attila_lendvai has joined #commonlisp
morganw has joined #commonlisp
jealousmonk has quit [Remote host closed the connection]
Lord_of_Life has quit [Ping timeout: 272 seconds]
Lord_of_Life has joined #commonlisp
lisp123 has joined #commonlisp
Cymew has quit [Ping timeout: 272 seconds]
karlosz has quit [Quit: karlosz]
cuz has quit [Ping timeout: 272 seconds]
morganw has quit [Remote host closed the connection]
Brucio-61 has quit [Ping timeout: 252 seconds]
scymtym has quit [Ping timeout: 250 seconds]
tyson2 has quit [Remote host closed the connection]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
cjb has joined #commonlisp
perrierjouet has quit [Quit: WeeChat 3.4]
cuz has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
perrierjouet has joined #commonlisp
<masinter>
performance of X suffers because Lisp is so much faster now
<masinter>
with X, you have to send over the network every screen update, even if it's too fast for any display refresh
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
waleee has joined #commonlisp
mgl has joined #commonlisp
pve has quit [Quit: leaving]
karlosz has joined #commonlisp
Oladon has joined #commonlisp
jealousmonk has joined #commonlisp
morganw has joined #commonlisp
Dynom has quit [Quit: WeeChat 3.4]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
tyson2 has joined #commonlisp
scymtym has joined #commonlisp
Brucio-61 has joined #commonlisp
shka has quit [Ping timeout: 252 seconds]
Brucio-61 has quit [Ping timeout: 252 seconds]
hashfunc1aa5 has joined #commonlisp
perrierjouet has quit [Quit: WeeChat 3.4]
wacki has quit [Quit: Leaving.]
aeth has quit [Ping timeout: 272 seconds]
aeth has joined #commonlisp
pillton has joined #commonlisp
Oladon has quit [Quit: Leaving.]
Oladon has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
aartaka has joined #commonlisp
aartaka has quit [Read error: Connection reset by peer]
aartaka has joined #commonlisp
perrierjouet has joined #commonlisp
aartaka has quit [Ping timeout: 240 seconds]
cosimone has quit [Remote host closed the connection]
cuz has quit [Ping timeout: 240 seconds]
mgl has quit [Ping timeout: 256 seconds]
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
rgherdt_ has quit [Remote host closed the connection]
perrierjouet has quit [Quit: WeeChat 3.4]
Oladon has quit [Read error: Connection reset by peer]
yewscion has quit [Ping timeout: 252 seconds]
cjb has quit [Ping timeout: 260 seconds]
Inline has quit [Read error: Connection reset by peer]