tyson2 has quit [Remote host closed the connection]
s-liao has joined #commonlisp
VincentVega has quit [Ping timeout: 250 seconds]
_patrice has joined #commonlisp
orestarod has quit [Ping timeout: 240 seconds]
_73 has quit [Remote host closed the connection]
morganw has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
karlosz has joined #commonlisp
karlosz has quit [Remote host closed the connection]
mayuresh has joined #commonlisp
<mayuresh>
good morning everyone. :)
<mayuresh>
i had asked this on the 'hug' mailing list, didn't get an appropriate response.
<mayuresh>
so asking here; is there any way to provide 'gnu' "readline" like functionlity using portable "common lisp"?
<mayuresh>
NotThatRPG: what do you mean by a "forms interface" to commands?
patrice has quit [Quit: Leaving]
<NotThatRPG>
In CLIM, one can have widgets that pop up to prompt for the arguments to a command. Given the alphabet soup of arguments to shell programs, it would be great to have something like that.
<NotThatRPG>
One could take the information that is in bash completion to begin to populate such an interface.
<Xach>
mayuresh: no.
<Xach>
mayuresh: terminal interaction at that level is not specified in common lisp.
<NotThatRPG>
I guess one could use CLIM, which is sorta portable, but at the cost of giving you a whole new terminal!
_patrice has quit [Ping timeout: 272 seconds]
<NotThatRPG>
And CLIM requires a bunch of extensions that are outside of ANSI CL.
eugercek has quit [Remote host closed the connection]
eugercek has joined #commonlisp
eugercek has quit [Read error: Connection reset by peer]
Bike has joined #commonlisp
_patrice has quit [Ping timeout: 240 seconds]
beach` has joined #commonlisp
beach has quit [Ping timeout: 252 seconds]
karlosz has joined #commonlisp
Bike has quit [Quit: Connection closed]
random-nick has quit [Ping timeout: 272 seconds]
derelict has quit [Quit: bye]
derelict has joined #commonlisp
mayuresh has quit [Quit: Leaving]
parjanya has joined #commonlisp
<parjanya>
good evening! what am I missing for this not to work? (let ((filling '(:hr))) (spinneret:with-html-string filling))
mayuresh has joined #commonlisp
notzmv has quit [Ping timeout: 240 seconds]
akoana has quit [Quit: leaving]
amb007 has quit [Ping timeout: 256 seconds]
karlosz has quit [Quit: karlosz]
amb007 has joined #commonlisp
pjb has joined #commonlisp
mayuresh has quit [Quit: mayuresh]
mayuresh has joined #commonlisp
<mayuresh>
parjanya: hello. :)
waleee has quit [Ping timeout: 250 seconds]
<parjanya>
namo namaH : o )
<mayuresh>
namovah. :)
notzmv has joined #commonlisp
Devon has quit [Ping timeout: 272 seconds]
Bike has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
<mayuresh>
I'm unable to figure out how to accomplish the instruction mentioned below;
<mayuresh>
Make sure the top-level directory can be found by ASDF.
<mayuresh>
beach: are you around here at the moment?
zachel has quit [Quit: Quit: Leaving!]
<White_Flame>
mayuresh: if you're using quicklisp, you can symlink from ~/quicklisp/local-projects/ to your project _directory_ and it'll pick it up through ASDF
zachel has joined #commonlisp
<White_Flame>
the oldskool way is (push #p"path/to/my.asd" *asdf:central-registry*)
<White_Flame>
the oldskool way is (push #p"path/to/my/project/" asdf:*central-registry*)
<mayuresh>
White_Flame: thanks.
<mayuresh>
White_Flame: should I be placing a symlink to my project directory within ~/quicklis/local-projects/ ?
<White_Flame>
yes, if you have quicklisp installed
<White_Flame>
and if you don't have QL installed, then you should install QL instead of doing it oldskool ;)
<mayuresh>
White_Flame: cool. thanks again. got it this time. :)
<White_Flame>
cool
<mayuresh>
White_Flame: I did as you'd instructed.
<qhong>
phoe: The third return value from sb-cltl2:variable-information also has missing type declaration. type declaration is one of the standard declaration specified in cltl2 environment
<mayuresh>
White_Flame: I reached step 4 and did it, but SBCL threw-up an error stating; "Package ASDF does not exist."
<mayuresh>
I googled but couldn't find a proper answer, or rather one I could understand.
<mayuresh>
How do I install ASDF?
<mayuresh>
I'm running SBCL.
terrorjack has joined #commonlisp
<qhong>
phoe: inside a real eval, sb-cltl2:variable-information correctly return all available type declaration. Inside a sb-cltl2:macroexpand-all, this is not the case
<mayuresh>
And, have installed Quicklisp.
<mayuresh>
Is "beach" here at the moment?
<mayuresh>
beach: can you provide facility within "Second-Climacs" to be used at a terminal?
<parjanya>
mayuresh: how are you running it? how did you install it? if memory serves sbcl already ships with asdf, so you should be doing something quite heterodox to have that error
<mayuresh>
Component :SECOND-CLIMACS-CLIM not found
s-liao has joined #commonlisp
<parjanya>
mayuresh: have you opened sbcl after cloning the repository? if not, try (asdf:compute-source-registry) to force asdf to find the packages again
<mayuresh>
That's what I get when I'm compiling the editor system by doing (asdf:load-system :second-climacs-clim)
<parjanya>
if it doesn’t work you might have chosen a directory that asdf can’t find
beach` is now known as beach
_patrice has joined #commonlisp
<mayuresh>
Okay, I tried (asdf:compute-source-registry) and it says "debugger invoked on a TYPE-ERROR in thread ...".
jeosol has joined #commonlisp
<beach>
Good morning everyone!
<mayuresh>
beach: good morning. :)
<parjanya>
beach: morning!
<mayuresh>
beach: can you mould "second-climacs" to be usable without "clim"?
<mayuresh>
ofcourse, that would mean it can't be called "climacs". :)
azimut has quit [Remote host closed the connection]
<beach>
I made an attempt to make Second Climacs independent of the underlying GUI library. Not sure how well I succeeded.
<mayuresh>
beach: can you make it "not use" a "GUI library"?
azimut has joined #commonlisp
s-liao has quit [Quit: Client closed]
<mayuresh>
beach: are you still working on "Second-Climacs"?
<beach>
Slow down...
s-liao has joined #commonlisp
<mayuresh>
beach: okay. I'm gonna try again some months from now. :)
<beach>
I am still technically working on Second Climacs, but it is stalled because of my work on SICL. scymtym has done some work, but we are both very busy.
<mayuresh>
okay.
<beach>
mayuresh: I am not interested in making Second Climacs an Emacs clone. I want it to be an excellent editor for editing Common Lisp code.
<beach>
I think that requires a GUI library, and CLIM is a very good candidate.
<mayuresh>
beach: what led you to think I'm requesting that you make "Second-Climacs" an Emacs clone?
_patrice has quit [Quit: Leaving]
<mayuresh>
beach: Ah, okay, because I requested a GUI-less version!
<beach>
The fact that you want a terminal and not use a GUI library.
<beach>
A terminal is not the business of the editor, but it is for Emacs, because Unix can't really create a consistent set of tools with internal communication the way CLIM can with Common Lisp.
Bike has quit [Remote host closed the connection]
<mayuresh>
beach: getting it now.
dec0d3r has quit [Quit: Leaving]
Bike has joined #commonlisp
<mayuresh>
beach: can you and your collaborators try to get it to a running condition at least?
<beach>
So I see Second Climacs as a component of an IDE, probably around McCLIM. A Unix terminal could be one component of such an IDE.
* moon-child
sincerely hopes no one spends energy on Yet Another Vt Implementation(tm)
<mayuresh>
beach: I failed for almost 3 days prior to requesting help with getting second-climacs to work at my system.
<Guest7482>
moonchild: are there any in lisp?
<moon-child>
not that I know of, but I stand by my statement
<mayuresh>
thanks to etimmons and parjanya, I got somewhat close, though not succeded yet.
<beach>
mayuresh: It really isn't usable at the moment. And I am not working like that. I still don't know how to compute correct indentation, so that's the main priority. If you understand that my idea for Second Climacs is to be a Common Lisp editor, you will see that there is no point in working on other aspects until I have figured out indentation.
<mayuresh>
I understand that you want to have a Common Lisp focused/only editor component which would eventually be used by someone else to integrate with out McCLIM components to develop a Common Lisp IDE, right?
<beach>
Second Climacs is meant to be excellent for Common Lisp editing because it uses Eclector (which is a Common Lisp READer) to parse the buffer contents. If I thought it would be enough to use existing techniques based on text, I would never have started the project.
<parjanya>
mayuresh: might I say respectfully, if you are having problems with asdf, you have more urgent problems than thinking about adjusting complex IDEs
<mayuresh>
parjanya: I agree wholeheartedly. :)
<mayuresh>
parjanya: just that I've already developed IDEs (PalmPilot development) before, but using C++ with Microsoft's Foundation Classes. :)
<mayuresh>
And yes, I don't know "anything" about Common Lisp. :)
<mayuresh>
I have only worked with AutoLISP.
<mayuresh>
And I got introduced to CS using Logo (thoroughly) which is a Lisp (though a lot of people tend to disagree).
<beach>
Not again!
<parjanya>
mayuresh: have you read Practical Common Lisp?
<mayuresh>
beach: I was just pulling your Dosa. :p
<Guest7482>
beach: if you tried to make it gui agnostic, do you have some sort of format for rich text that other gui environments could parse?
<mayuresh>
parjanya: Not yet. I'm working through Touretzky.
<beach>
Guest7482: What purpose would the rich text serve? Again, the idea is to create something that is unbeatable for editing Common Lisp. For that purpose, it takes Common Lisp source code and gives it to Eclector (which again is a Common Lisp READer). It then transforms the text into some nested data structure. Where would rich text fit in?
tyson2 has quit [Remote host closed the connection]
<mayuresh>
beach: I think Guest7482 is approaching it from the Microsoft environment side, where most code editors are actually "rich-text editors".
<beach>
I am sorry to hear that.
<mayuresh>
beach: both of my IDEs (for PalmPilot and Baan Tools development) extended the rich-text editor component provided with Microsoft's Foundation Classes included with Visual C++.
<Guest7482>
I don't know about microsoft. I wondering about things like bold/italic/fonts etc.. Or if those are coupled directly with what's returned from eclector.
<mayuresh>
Guest7482: presentation is a different layer altogether. Isn't it?
<Guest7482>
it'd be a gui layer.
<mayuresh>
Guest7482: beach's work is "below" the GUI layer.
<mayuresh>
Guest7482: you could extend McCLIM to provide your visual elements as needed.
<Guest7482>
sigh, nevermind
<Guest7482>
In the future, please don't speak for others.
<beach>
I am not making myself clear here. Font size, color, family etc. would be supplied by the module that analyzes the Common Lisp code, and these characteristics would be based on the role of the elements of the Common Lisp code, such as whether it is a lexical variable, a function name, a package name, etc. But the result will then no longer be text, and instead consist of a tree of standard objects.
<mayuresh>
Guest7482: Sure, just tried to help you out of a ditch.
<beach>
mayuresh: CLIM already contains everything that is needed in terms of fonts.
<mayuresh>
beach: yes, I know. By extend, I meant, do whatever Guest7482 expects from "their" instance.
<Guest7482>
I obviously would not be using clim. Please don't try to help.
<mayuresh>
I refered to Guest7482 as "their" because I don't know if you are he, she, or it.
moon-child has left #commonlisp [#commonlisp]
<beach>
Guest7482: Why would you "obviously" not use CLIM? I may have missed some context.
<mayuresh>
beach: I'm as confused about all this as you are.
semz_ has joined #commonlisp
<mfiano>
This conversation is hard to follow. I'm missing a lot of context. All I know is I admire beach's patience.
<mayuresh>
mfiano: I agree with you on this wholeheartedly. Along with beach's devotion to helping others see the light.
<beach>
mfiano: Thanks. I am hanging in there only in order to correct any misconceptions about what I want for Second Climacs.
<mfiano>
Also, good morning.
semz has quit [Ping timeout: 245 seconds]
Bike has quit [Quit: Connection closed]
<Guest7482>
beach: if I were to use clim then I'd just use what you guys have written. Anyways I can work with trees of objects just fine.
<beach>
OK.
<Guest7482>
it would have been less confusing without maya interpreting what everybody has said.
<mayuresh>
Guest7482: it would have been interesting if you'd been smarter to express yourself more sensibly.
<beach>
Chill out please.
<parjanya>
what am I missing for this not to work? (let ((filling '(:hr))) (spinneret:with-html-string filling))
mayuresh has quit [Quit: Leaving]
<Josh_2>
Good morning
s-liao has quit [Quit: Client closed]
<masinter>
what did I miss?
<beach>
masinter: How long have you been gone? :)
<masinter>
30 years
<beach>
masinter: Can I assume you know about the channel logs?
<beach>
Heh.
<masinter>
I used to know more about common lisp than most people
<beach>
I am sure that's true.
<masinter>
i stopped following around '92. Now I can't make sense of most of the conversations here
<White_Flame>
I wonder if there are more people who know common lisp now than 30 years ago
<beach>
masinter: Feel free to ask questions if you want to brush up on your Common Lisp knowledge.
igemnace has quit [Ping timeout: 240 seconds]
<masinter>
30 years ago there were maybe 20 people in X3J13
<Guest7482>
Larry if it makes you feel any better I couldn't make sense of most of your works either :)
<Guest7482>
seriously though, nice work.
<masinter>
30 years ago IRC was in doddardhood. Now I need to dust off irc client
lisp123 has joined #commonlisp
<masinter>
i'm missing the protocol for discovering identities behind the idents
Oladon has joined #commonlisp
<masinter>
nicknames
<lisp123>
i dont think there is any
<Guest7482>
30 years ago learning irc was on my todo list. Just started using it last year, so sorry can't help.
<lisp123>
its anonymous unless people are willing to share their info
<masinter>
Dotardhood
<lisp123>
Guest7482 - any relation to Guest74?
<White_Flame>
the servers also tend to mask IP addresses, depending on if/how you're registered
<masinter>
even lambdamoo was more advanced
<Guest7482>
lisp123: same relation you have to lisp123_
<masinter>
in W3C people used their real names
<lisp123>
Guest7482: Ah, got it :)
<masinter>
i lived in emacs then, so i used erc
opcode has quit [Quit: hopefully not k:lined]
<Guest7482>
I'm not even sure if things like whois and finger even exist anymore.
<masinter>
telnet isn't a thing any more
<beach>
masinter: ERC is still fine.
<Guest7482>
I think there's actually still quite a few bbs that transitioned to telnet.
<White_Flame>
masinter: oh it is, there are telnet BBSes, and it's still a debug facility for textual protocols :)
<White_Flame>
gopher even has had a bit of a resurgence, as people reject the corporatastic manipulation of the web
<masinter>
medley runs ssh when you (chat 'hostname) except (chat 'il:shell)
<Guest7482>
masinter: are you involved in the interlisp/medley resurgence? I have to admit I haven't paid much attention.
<Guest7482>
ah, i guess that sort of answers that.
<masinter>
i hadn't thought about interlisp for 30 years either
<Guest7482>
is this a case of thinking you'll take a bit of time to help develop some tools that would make your work easier and finding out 3 decades have passed?
<masinter>
i'm interested in long-term archiving actually
<masinter>
how do you archive software for the long term
<masinter>
so a revival -- make it live again
<Guest7482>
does that not presuppose that the software of today will be of use to the problems of the future?
lisp123 has quit [Remote host closed the connection]
<beach>
Guest7482: Already, it would be an improvement to use software of yesterday for problems of today. At least when it comes to things like operating systems.
<Guest7482>
though I think an unchanging standard such as common lisp at least provides a foundation for such endeavours.
<masinter>
SEDIT is written in mainly common lisp
<Guest7482>
beach: though it seems the younger generation has different problems that past does not seem to hold relevance to.
<beach>
Guest7482: There is some of that, sure. But the younger generation must still struggle with the horrible interface that Unix imposed on us.
<masinter>
well, think of this as "open data" for CS Research
<Guest7482>
masinter: I think i read the sedit code before and it was a bit 'archaic' for lack of a better word.
<Guest7482>
beach: i think that's why they have legions of code monkeys. And there seems to be a terrible feedback loop between what the new generation wants and what programmers provide as an interface.
<masinter>
there's an export package for reformatting code so that it looks more like common lisp
<beach>
Guest7482: Sounds right.
jealousmonk has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 27.1)]
wacki has joined #commonlisp
azimut has quit [Remote host closed the connection]
GreaseMonkey has quit [Read error: Connection reset by peer]
shka has joined #commonlisp
<Guest7482>
archiving is easy. You just have to deal with the standard problems of the media surviving, having something to read it, and something to run it.
<Guest7482>
Making software alive, is another story. How to build a community? be the first to provide a solution to a problem?
<masinter>
We're working on lowering the cost of entry
<jackdaniel>
these are two values, do you mean to produce multiple values from a list?
<beach>
(apply #"values list)
<jackdaniel>
(values-list '((1 2 3) (4 5 6))) but I'm 80% you don't want that
<jackdaniel>
80% convinced
<beach>
hashfunc170a: I think you are approaching Common Lisp in a strange way. You are trying to write fairly sophisticated macros using the backquote facility, but you seem to be lacking in some basic understanding of the semantics of the language.
<hashfunc170a>
beach: ... (apply #'values list) ... works but doesn't work in my macro? is there a caveat to splicing lists within macros?
<beach>
hashfunc170a: Macros are no different from ordinary functions. What works in an ordinary function works in a macro function as well.
<beach>
hashfunc170a: You can't have two separate objects like that in Common Lisp. They are either bundled up in a list as you have, or they are multiple values.
<hashfunc170a>
beach: i totally understanding that i'm approaching it in a very unconventional way lol. but i'm trying to build a solid intuition around macros
<beach>
hashfunc170a: There is nothing to know that is separate about macros. A macro is just a function that transforms code into other code.
<jackdaniel>
that way you'll confuse yourself instead of building any intuition, I'd put macros for later if I were you
<beach>
hashfunc170a: And the backquote facility can be used anywhere; not just in macros.
<masinter>
it's hard to write good macros without screwing up order of execution
lisp123 has quit [Remote host closed the connection]
parjanya has quit [Ping timeout: 250 seconds]
<hashfunc170a>
beach: i understand what you're saying, and i understand that the backquote facility can be used anywhere. but what isn't intuitive to me is the evaluation of macros within macros within a quasiquoted form
lisp123 has joined #commonlisp
<beach>
hashfunc170a: Macros aren't evaluated. They can be defined or invoked. Only forms are evaluated.
<pjb>
More exactly, they are self-evaluating, like most lisp objects: (eval (macro-function 'cond)) #| --> #<Compiled-function cond Macroexpander #x3000009610BF> |#
<masinter>
to get a good sense of macros, get rid of quasiquotes. `(a b ,c) => (list 'a 'b c)
<beach>
masinter: That was suggested yesterday to hashfunc170a by (as I recall) moon-child.
<pjb>
hashfunc170a: or don't write your code in a macro, but in a normal function: (defun generate-my-code (name expression) `(block ,name ,expression)) then a macro calling your code-generating function (defmacro my-code (name expression) (generate-my-code name expression))
igemnace has quit [Remote host closed the connection]
<beach>
hashfunc170a: Did you figure out the COND code I wrote yesterday? If not, try just evaluating (eq *package* *standard-output*) and `(eq ,*package* ,*standard-output*) at the REPL. As you can see, the first form evaluates to false (NIL) and the second one to true (something other than NIL).
<phoe>
qhong: one difference is that you need to provide a variable name for VARIABLE-INFORMATION, this is not the case for your old VARS-OF-TYPE macro
<beach>
hashfunc170a: So in your macro, your COND has a test that looks very much like the second of my two forms, and it is always true.
lisp123 has quit [Remote host closed the connection]
MajorBiscuit has joined #commonlisp
<phoe>
qhong: but, yes, the macroexpansion does not show any TYPE declarations, which is weird
<hashfunc170a>
beach: i understand that macros aren't evaluated. but i also understand that (unquoted) forms can be evaluated within macros at compile-time. what i don't understand is how a macro with a ... &body ... parameter can be defined without the use of quasiquote. & yes, that was my first exercise today, i fully understand the COND code, in that the template list generated evaluates to truthy in the cond, thus the "yes" gets printed.
<phoe>
hashfunc170a: a macro must return some Lisp code, which will most likely be a tree of conses
<phoe>
you can use cons- and list-making functions to create that tree, rather than quasiquote
<s-liao>
what is (loop :for (value . input) :in (run parser input)
<s-liao>
:append (run (funcall function value) input))
<phoe>
s-liao:
specbot has quit [Remote host closed the connection]
<phoe>
clhs loop
minion has quit [Read error: Connection reset by peer]
<phoe>
it's pretty hard to explain all of LOOP via IRC, hence I'm linking you a book chapter
<hashfunc170a>
beach: "beach: i understand that macros aren't evaluated. but i also understand that (unquoted) forms can be evaluated within macros at compile-time." i'll backtrack on those statements. i understand that forms with the symbol 'macro as it's car are evaluated differently.
<phoe>
symbol 'macro as its car?
<hashfunc170a>
(list 'macro ...)
<phoe>
uh, no?
<phoe>
there is no symbol named MACRO in CL
<White_Flame>
technically, they're compiled differently, not evaluated differently
<White_Flame>
although both could be true
<phoe>
hashfunc170a: do you know how functions work? like, (lambda (x y) (list '+ x y))
<beach>
hashfunc170a: You can use APPEND to construct the code to return. No need to use the backquote facility.
<beach>
hashfunc170a: See, that's what I meant before. You lack a lot of basic knowledge, yet you are trying to do something fairly sophisticated, and the result is that you mix everything up and don't understand which part does what.
<phoe>
in CL, you grab a perfectly normal usual function, wrap it a little so it takes two arguments (the whole form and the environment object), and you (SETF MACRO-FUNCTION) it into place
hashfunc170a has quit [Ping timeout: 272 seconds]
<phoe>
that's some of the dirty technical details behind DEFMACRO
Dynom has joined #commonlisp
<beach>
dirty?
<jackdaniel>
very much so, I saw a stain on them :)
lisp123 has joined #commonlisp
s-liao has quit [Quit: Client closed]
aartaka has quit [Ping timeout: 272 seconds]
lisp123 has quit [Ping timeout: 260 seconds]
s-liao has joined #commonlisp
aartaka has joined #commonlisp
frgo has quit [Remote host closed the connection]
silasfox has joined #commonlisp
cosimone has joined #commonlisp
Catie has quit [Ping timeout: 240 seconds]
<s-liao>
phoe: Thanks
mgl has joined #commonlisp
s-liao has quit [Quit: Client closed]
treflip has joined #commonlisp
v88m has quit [Ping timeout: 256 seconds]
ec has quit [Ping timeout: 240 seconds]
pillton has quit [Quit: ERC (IRC client for Emacs 27.2)]
<phoe>
beach: "dirty" as in "not clean" - e.g. the transformation from the macro lambda list into (lambda (whole env) ...) is very much not a clean operation
<phoe>
or rather, s/dirty/ugly/
<phoe>
that would be even better
parjanya has joined #commonlisp
frgo has joined #commonlisp
lisp123 has joined #commonlisp
s-liao has joined #commonlisp
Jach has quit [Ping timeout: 245 seconds]
perrierjouet has quit [Ping timeout: 256 seconds]
perrierjouet has joined #commonlisp
Jach has joined #commonlisp
<pjb>
phoe: it's standard macrology.
<phoe>
pjb: I know it's standard macrology, but it isn't "obvious" macrology
<pjb>
It's obvious when you write the compiler and call the macroexpander.
<phoe>
it's not obvious if you are learning lisp and want to learn how macros work
<phoe>
people who are learning lisp do not usually write lisp compilers at the same time
<splittist>
I'm not sure 'dirty', 'ugly' or 'unnatural' really add much. Except in a trite phrase like "dirty little secret" to imply this is some behind-the-scenes machinery
<phoe>
hmm
<phoe>
point taken
<jackdaniel>
a natural language is relative; a person who learns macros doesn't need to know about this implementation detail (even if it is part of the standard)
<jackdaniel>
when someone wants to understand how macros are implemented, then we could say that they peek behind the abstraction scenes, so they /get their hands dirty/
<splittist>
A marvelous metaphor bouillabaisse
<jackdaniel>
it's not me who came up with 'dirty little secrets' ,)
<jackdaniel>
for someone who knows the standard very well some things are obvious, while for other people they may be obscure
lisp123 has quit [Remote host closed the connection]
Dynom has quit [Quit: WeeChat 3.4]
[w] has quit [Ping timeout: 240 seconds]
v88m has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
patrice has joined #commonlisp
random-nick has joined #commonlisp
eugercek has joined #commonlisp
<scymtym>
Guest7482: are you the author of the randr extension in clx?
patrice has quit [Quit: Leaving]
tyson2 has joined #commonlisp
igemnace has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
v88m has quit [Ping timeout: 256 seconds]
Bike has joined #commonlisp
jackdaniel has quit [Remote host closed the connection]
s-liao has joined #commonlisp
s-liao has quit [Write error: Broken pipe]
jackdaniel has joined #commonlisp
cage has joined #commonlisp
v88m has joined #commonlisp
igemnace has quit [Remote host closed the connection]
kevingal has joined #commonlisp
igemnace has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
patrice has joined #commonlisp
v88m has joined #commonlisp
Bike has quit [Quit: Connection closed]
Bike has joined #commonlisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
<Guest7482>
scymtym: Yes, the partial one that is there. I had the complete extension written but my hard drive crashed and I was becoming homeless and just uploaded what I could. So if there's problems just ask.
<Guest7482>
Also did the double buffer one, but I think the general consensus is not to use it, especially for gl as it uses up your stereo views.
<Guest7482>
and composite, which you can't really use without xfixes, which can't be used the way clx is written.
<scymtym>
Guest7482: thank you for the information. i'm experimenting with the events of the randr extension. i think RRNotify and its sub-events are not described correctly at the moment
<Guest7482>
possible. I can take a look.
v88m has quit [Ping timeout: 256 seconds]
<scymtym>
thanks, i can probably figure it out though. would you look over a pull request?
v88m has joined #commonlisp
<Guest7482>
anyone in particular? though I guess I'll just check against the xml. They do sneaky things like changing stuff in the xml and not updating the docs.
<Guest7482>
I could, but I don't really maintain that version and I have no write access to sharplispers.
<Guest7482>
also seems to be missing quite a few events.
ajnulo has joined #commonlisp
<scymtym>
the sharplispers version is maybe on randr 1.3 or so
<scymtym>
but those events would be good enough for me at the moment
<Guest7482>
ah, let me look at the repo, it's probably different from mine.
rm34D has joined #commonlisp
silasfox has quit [Quit: WeeChat 3.4]
<beach>
I would still love to see a new CLX-like library that is more CLOS-y and that uses the Xrender extension exclusively for drawing.
<Guest7482>
if it's one of the output events, i think the output requests were putting out the wrong information.
<beach>
Then, maybe this time it should be a more abstract library so that different types of display servers can be used.
<Guest7482>
beach: so would i! Though not exclusively xrender. Unfortunately there's quite a few things it is slower than software rendering.
<beach>
I see.
<Guest7482>
I was just thinking of having a vector drawing interface, despite the fun I had writing all the raster graphics stuff.
<beach>
I seem to recall that something like that has been worked on.
<beach>
Perhaps by me? :)
* beach
's memory is crap.
treflip has quit [Quit: rebooting...]
<Guest7482>
I just use what frederic wrote, and built an interface on top of that to make easy rendering of svg paths. I'm a little surprised, it's one of the few things I use someone elses library for.
<Guest7482>
Would love to see anything you've worked on. I find seeing multiple implementations helps to develop a backend agnostic layer over it.
ec has joined #commonlisp
<beach>
I suspect I didn't get very far. But let me have a quick check...
tyson2 has quit [Remote host closed the connection]
<Guest7482>
scymtym: atom in :rr-output-property-change should probably be declared an atom and not card32, so break up that sequence, and state should be an enum not a boolean.
ec has joined #commonlisp
<jackdaniel>
em, did the video got cut in the middle?
<jackdaniel>
let me rerecord the svg part
<beach>
jackdaniel: maybe. I haven't thought about things like this for a while. I think I was aiming for something lower level than the CLIM protocols.
<scymtym>
Guest7482: i think all but the first event are wrong and should instead share a single event code with three different sub-codes. i will report further progress later
<jackdaniel>
currently to implement a drawing backend without a concern for performance it is enough to define a port, a medium and a method for medium-draw-polygon* (along with relevant line styles, colors and such)
<Guest7482>
you guys really should factor that out. Maybe then I wouldn't have written a surface and drawing protocol.
<jackdaniel>
protocols are out there, specified
<Guest7482>
that makes no difference.
<jackdaniel>
that's a shame ,)
attila_lendvai has quit [Ping timeout: 256 seconds]
aartaka has quit [Ping timeout: 272 seconds]
<Guest7482>
it is, really wish you guys factored that out.
aartaka has joined #commonlisp
* jackdaniel
would rather see people adopting mcclim than maintaining himself small libraries he has no use for
<Guest7482>
perhaps there'd be more users if there were smaller pieces people could take advantage of without using the whole and that would consolidate effort in the community?
<jackdaniel>
I don't see how fragmentation fuels consolidation but mcclim is a free software, you can make a fork with things you like if you are willing to
<Guest7482>
it fuels consolidation of all the effort put into sub parts. There are much more people working on graphics related things that have nothing to do with mcclim.
rm34D has quit [Ping timeout: 272 seconds]
ec has quit [Ping timeout: 240 seconds]
lisp123 has joined #commonlisp
rm34D has joined #commonlisp
<NotThatRPG_away>
I see both sides of this discussion. On the one hand, it would be nice if McCLIM could centralize community effort. On the other hand, the CLIM model of GUI is so unusual, with such a high learning curve, that it's a very big ask. I should try it again, it's been years since I last tried.
NotThatRPG_away is now known as NotThatRPG
blacked has joined #commonlisp
<blacked>
if lets say emacs was made in c+lua instead of c+lisp, would it be still configurable?
ec has joined #commonlisp
<jackdaniel>
mcclim has many systems that may be used independent of gui.
<jackdaniel>
in the future I also want to make the lower level abstractions (known in genera as silica) as a framework to build your own toolkit (without clim "esoterics")
<beach>
NotThatRPG: I think that's merely a matter of how it is presented. I believe if the documentation were structured to start with the low-level parts and to present the upper layers as convenience, then people could start using it the way they use traditional GUI toolkits.
<beach>
blacked: Not exactly a Common Lisp question.
lisp123 has quit [Ping timeout: 250 seconds]
<random-nick>
why is the CLIM model of GUI unusual? clim's model doesn't seem to be far from the event loop model used in modern GUIs
<NotThatRPG>
beach: That might well be. The CLIM spec is not at all a tutorial! But I don't believe there is one?
<jackdaniel>
NotThatRPG: there is one in McCLIM manual
<beach>
NotThatRPG: There is stuff already in the McCLIM distribution, but I haven't looked at it lately.
<jackdaniel>
it doesn't cover everything, but it is a good start
<NotThatRPG>
What's the status of the emacs-style application stuff in McCLIM?
<beach>
random-nick: That's the lower level I was talking about. But that's not how it is typically presented.
<beach>
... pun not intended.
<beach>
NotThatRPG: ESA? Still working but should be split up and restructured.
<jackdaniel>
random-nick: most toolkits rely on widgets+callbacks while clim defines a frame as a model and presentations and commands that have semantic meaning
<NotThatRPG>
The last time I tried McCLIM the graph layout stuff worked poorly, and argument parsing for complex arguments didn't work properly (trying to remember exactly what was wrong, but I think I had a command that required two arguments off the graphics, and it just didn't work at all).
<NotThatRPG>
But again, that was a LONG time ago.
<beach>
blacked: For an application to be highly scriptable, it needs a dynamic programming language. I don't know Lua, so I can't say whether it would do the trick. Some applications are written in a static programming language, and then scripting capabilities are added in the form of a dynamic language.
<jackdaniel>
either way, mcclim is useful for other things than writing applications - i.e you may use it to produce raster images, pdf and postscript documents etc
<beach>
blacked: But it is a much better idea to have the entire application written in one dynamic language.
<blacked>
i'm looking like i know elisp is not lisp or common lisp
<blacked>
but i heard this quote
<blacked>
Emacs Lisp is probably the most featureless language you can think of; it doesn't even do basic threading and the async stuff is a joke. All the major programming language modes are implemented as ad-hoc Elisp regexp parsers making bugs impossible to fix. Virtually _everything_ is implemented in Elisp, because the C code is a gigantic
<blacked>
unmaintainable mess. This means that all the pretty high-level stuff like Magit is shit slow. Good features take ages to propagate to upstream, whose reasons are often more political than technical.
<blacked>
`doesn't even do basic threading and the async stuff is a joke` , how is for common lisp?
<phoe>
CL has decent threading support
* jackdaniel
gets back to work
<phoe>
nothing truly good for asynchronous programming though, since it just doesn't fit the language model very well
* jackdaniel
hints at lparallel and lfarm
Devon has joined #commonlisp
<beach>
blacked: It would have been better if Emacs were written in Common Lisp, as opposed to the way it is now written, but I understand Emacs Lisp is getting better and getting closer to Common Lisp in some respects. Then, I don't much like how Lisp mode is implemented in Emacs, which is why I started Second Climacs.
<blacked>
yes there is one :)
<blacked>
but nobody use it :(
<beach>
Nobody uses what?
<blacked>
Climacs
<beach>
Hold on a sec...
<blacked>
beach can i use doom emacs in climacs?
<jackdaniel>
there is more than one - hemlock and climacs come to mind. hemlock if I understand correctly is used as an ide for ccl
<_death>
blacked: this quote is not up to date.. e.g., ELISP> (make-thread (lambda ())) => #<thread 0x565065b4e198>
<_death>
<jackdaniel>
(or the ide is build on top of hemlock)
<NotThatRPG>
blacked: elisp and emacs are a scandal for software engineering. Everything is done wrong according to SE dogma, but somehow it works better than most software that's done right.
<random-nick>
phoe: why doesn't it fit the language model?
<NotThatRPG>
FSVO "right"
<beach>
blacked: (First) Climacs is not that much better than Emacs, but I am talking about Second Climacs, which is not ready to use, which is why it is not used.
<blacked>
`talking about Second Climacs` oh ok , i'll move to it if it is ready, but what about my already configured config
<Guest7482>
notthatrpg: Which is why planning out software almost seems like a futile endeavour. You never quite now why people will use things.
<beach>
blacked: It is not ready, as I said.
<beach>
blacked: And from your remarks, it sounds like you wouldn't want to be a user anyway.
<NotThatRPG>
Guest7482: Actually I was referring to things like namespacing, typing, heck, even lexical scope!
<semz_>
Was about to say, it's a bit weird to see "basic thread and async support" as a supposedly major shortcoming of elisp when there are so many much worse.
<blacked>
ummmm these language are slowly deteroiorating in the history, dont hate me but thats true.
<blacked>
people making lua, neovim :( not common lisp based vim
semz_ is now known as semz
<beach>
blacked: "these languages"?
<_death>
not sure what you're trying to get at, here in #commonlisp
<jackdaniel>
beach: I believe that you are being trolled by blacked
<blacked>
no no i'm not ranting
<beach>
jackdaniel: Yeah, possibly.
<blacked>
i'm covering my own conflicts of brain what would happen in future?
treflip has joined #commonlisp
<phoe>
random-nick: well, less of a language model issue, but I do not know if any CL implementation supports that out of the box; there is stuff like cl-async which requires foreign code and structuring your code around its async model
<phoe>
but yeah, elisp discussion would be more suited to #lisp
<Guest7482>
it's certainly been an issue when trying to deal with events/eventing.
<random-nick>
don't other async programming models have you also structure your code around the async model? from what I understand, async models are still callback-based, but now with async/await syntactic sugar instead of explicit callbacks/CPS, not unlike cl-cont/green-threads
poldy has joined #commonlisp
<random-nick>
but yes, in order to do these things in CL you either need to rely on an entire foreign async framework like cl-async does, or you have to manually build your own while interfacing with the OS directly which would probably require implementation-specific code in order to keep things compatible with the implementation's implementation of files and streams
<random-nick>
unless you write your own using gray streams, I guess
<Guest7482>
there seems to be some time penalties going with gray streams.
<_death>
there are much better ways to support parallelism and concurrency anyway.. Lisp has a long history with such ways
<NotThatRPG>
I wish that the concurrency stuff from portable allegroserve had caught on: they are more lispy than many of the alternatives.
<phoe>
_death: could you say a bit more? I'm curious
<_death>
phoe: just think about the actor model (scheme ;), connection machine (starlisp), qlisp, etc.
<phoe>
oh, you mean these! yes, I see
<_death>
the CSP book also used a Lisp-alike
<random-nick>
also, does async offer any advantages compared to a "lightweight" threading model?
<NotThatRPG>
_death: "CSP book" or did you mean "CPS book"?
<random-nick>
csp would be communicating sequential processes? what would be cps?
<phoe>
continuation passing style I guess
<Guest7482>
I'm just wondering how to deal with events across different lisp processes. You wouldn't want your event processor to execute callbacks in it's own process.
<random-nick>
why would you have different lisp processes in the first place?
<jackdaniel>
Guest7482: make a thread-safe event queue (i.e a mailbox) for each "consumer" and stick events there
<jasom>
Guest7482: yes, geocities e-mail addresses still work; I've been using mine since 1996 or so
<jackdaniel>
NotThatRPG: yes
<NotThatRPG>
@jackdaniel: Thanks!
<jackdaniel>
sure
<Guest7482>
you need privileges to read certain inputs. You don't want to run out of memory. you don't want people compiling binaries and having 20 different event processors running.
<random-nick>
jackdaniel: you'd need some IPC mechanism, presumably
Volt_ has quit [Quit: ]
<random-nick>
would you not run out of memory faster if you have more processes?
blacked has quit [Killed (ozone (No Spam))]
<jackdaniel>
ah, then I misunderstood, I thought that we talk about threads
<NotThatRPG>
@jackdaniel: Is there any tutorial for ESA?
<Guest7482>
if an sbcl process runs out of memory, it only crashes itself. Not the whole system.
<jackdaniel>
NotThatRPG: there is, but you need to build it yourself. it is in the directory Documentation/ESA
<Guest7482>
jd: I have thought of mailboxes for same process. or maybe just client supplies a thread and just interrupt and insert callbacks.
<jackdaniel>
NotThatRPG: that said while I'm happy to help with any clim problems I don't know ESA itself so I won't be of much help
<NotThatRPG>
@jackdaniel: Good advice. Probably I will stay away from that then.
v88m has quit [Ping timeout: 272 seconds]
<jackdaniel>
I'm not saying that it is bad, I'm just not accustomed it - it is a bundled library so I don't feel compelled to work on it (especially that there are no bug reports)
<Guest7482>
I wonder if security even needs to be thought about? Maybe people don't mind being able to keylog all passwords on their system.
<_death>
as long as you use agpl license for your passwords, it's fine
Common-Lisp has joined #commonlisp
<Guest7482>
just put it in the readme right? by use of this software you agree to licence all your passwords under the agpl?
<Common-Lisp>
I don't think that would work lol
<Common-Lisp>
What is the binary form of a password
mgl has quit [Quit: Client closed]
<_death>
if you distribute an encrypted file, you must also distribute the password
rm34D has joined #commonlisp
rm34D has quit [Ping timeout: 256 seconds]
pdo has joined #commonlisp
rm34D has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 256 seconds]
<Guest7482>
is it just me, or does sbcl's loop not handle nested conditionals properly, especially with regards to pairing up :else clauses?
<Bike>
how so
<Guest7482>
I'm trying to come up with an example. It's even more confusing because emacs doesn't line up the clauses properly. and :else will automatically indent to the outer if.
ec has quit [Quit: ec]
lisp123 has joined #commonlisp
<beach>
Guest7482: You need to use the slime-indentation contribution for LOOP clauses to be indented correctly.
<Guest7482>
it's in my slime-contribs
<beach>
Ah, OK. Strange that it doesn't work properly for you.
lisp123 has quit [Ping timeout: 240 seconds]
<Guest7482>
huh, my test works but my code which is the same thing with different functions doesn't.
<Guest7482>
still, doesn't change the bad indentation. Wonder if order of slime-contribs matters at all?
<jackdaniel>
perhaps you try to capture a loop variable?
<Guest7482>
ah, my bad, function was not returning what I was expecting it to return, i.e. what it is specified to return.
<Guest7482>
still wondering why it's not indenting properly if slime-indentation is supposed to take care of that.
attila_lendvai has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
rm34D has quit [Ping timeout: 250 seconds]
rm34D has joined #commonlisp
poldy has quit [Ping timeout: 245 seconds]
karlosz has joined #commonlisp
karlosz has quit [Ping timeout: 256 seconds]
jeosol has quit [Quit: Client closed]
amb007 has joined #commonlisp
Common-Lisp has quit [Remote host closed the connection]
v88m has joined #commonlisp
jeosol has joined #commonlisp
parjanya has quit [Remote host closed the connection]
phantomics has quit [Ping timeout: 256 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
eugercek has quit [Remote host closed the connection]
treflip has quit [Quit: good night!]
wacki has quit [Quit: Leaving.]
yewscion has joined #commonlisp
rm34D has left #commonlisp [ERC (IRC client for Emacs 27.2)]
<phoe>
TIL that WITH-OPEN-FILE has fun behavior wrt non-local jumps
waleee has joined #commonlisp
MajorBiscuit has joined #commonlisp
<Bike>
what behavior is that?
morganw has joined #commonlisp
<phoe>
if a new file is being written, and if control leaves the body via a non-local jump, then the file is not actually written
<White_Flame>
"If abort is true, an attempt is made to clean up any side effects of having created stream. If stream performs output to a file that was created when the stream was created, the file is deleted and any previously existing file is not superseded."
<White_Flame>
from CLOSE. Looking at SBCL's with-open-file, the :abort field is only NIL if the body finished
<White_Flame>
on its exiting CLOSE call
tyson2 has quit [Remote host closed the connection]
<White_Flame>
oh, and this is documented on with-open-file as well, sorry
jackdaniel has quit [Remote host closed the connection]
jackdaniel has joined #commonlisp
wacki has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
tyson2 has joined #commonlisp
v88m has joined #commonlisp
varjag has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 272 seconds]
Lord_of_Life_ is now known as Lord_of_Life
MajorBiscuit has quit [Ping timeout: 240 seconds]
<Guest7482>
how do you leave a message for someone?
<Bike>
::notify guest7482 like so
<Colleen>
Bike: Got it. I'll let guest7482 know as soon as possible.
<Guest7482>
thanks bike:
<Colleen>
Guest7482: Bike said 11 seconds ago: like so
<Guest7482>
::notify scymtym I've got to go now, but forgot to mention that to read those events properly you'd have to change the whole way extensions and events are declared, and how they are read. The easy hacky solution would be to name the second event notify-union and then just get a sequence of card8's that you can assemble into the events depending
<Colleen>
Guest7482: Got it. I'll let scymtym know as soon as possible.
<Guest7482>
on the sub-code, since none of them really have the same order or size of slots.
Guest7482 has quit [Quit: Connection closed]
Catie has joined #commonlisp
eugercek has joined #commonlisp
eugercek has quit [Read error: Connection reset by peer]
eugercek has joined #commonlisp
patrice has quit [Quit: Leaving]
morganw has quit [Remote host closed the connection]
igemnace has quit [Remote host closed the connection]
igemnace has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
attila_lendvai has quit [Ping timeout: 250 seconds]
igemnace has quit [Read error: Connection reset by peer]
igemnace has joined #commonlisp
Devon has quit [Ping timeout: 256 seconds]
igemnace has quit [Remote host closed the connection]
igemnace has joined #commonlisp
igemnace has quit [Read error: Connection reset by peer]
igemnace has joined #commonlisp
igemnace has quit [Read error: Connection reset by peer]
igemnace has joined #commonlisp
morganw has joined #commonlisp
euandreh has quit [Ping timeout: 250 seconds]
wacki has quit [Quit: Leaving.]
ec has joined #commonlisp
Alfr has quit [Remote host closed the connection]
Alfr has joined #commonlisp
igemnace has quit [Remote host closed the connection]
aartaka has quit [Ping timeout: 240 seconds]
greaser|q has joined #commonlisp
aartaka has joined #commonlisp
greaser|q has joined #commonlisp
greaser|q has quit [Changing host]
greaser|q is now known as GreaseMonkey
igemnace has joined #commonlisp
igemnace has quit [Read error: Connection reset by peer]
pillton has joined #commonlisp
kevingal has quit [Remote host closed the connection]
<dieggsy>
So I now I can print a space-delimited list using (format nil "~{~a~^ ~}" list) - is there a way to also specify the number of spaces to separate by as a format argument?
<dieggsy>
I tried something like (format nil "~{~a~^~va~}" list 5 " ") but my understanding of format isn't super deep and this doesn't work