<minion>
Remembered. I'll tell doomlist3 when he/she/it next speaks.
<phoe>
flip214: that's a good solution, too
<flip214>
phoe: just keep on talking
<beach>
flip214: I think this newcomer would want an update of the standard.
nightfly has quit [Ping timeout: 258 seconds]
<phoe>
beach: honestly, so would I
nightfly has joined #lisp
<phoe>
that's not going to happen without significant work though, so it needs to stay in the domain of dreams for now
<beach>
For \n?
<beach>
You must be joking.
<phoe>
oh! not for \n, in general
Cymew has quit [Ping timeout: 256 seconds]
<Shinmera>
Whenever I learn new things I always wonder: man why isn't everything just the way I already knew??
orblu has quit [Ping timeout: 260 seconds]
Cymew has joined #lisp
ark has quit [Ping timeout: 244 seconds]
<aeth>
\n is pretty useful though
ark has joined #lisp
<aeth>
Note that they're distinct, though. "Foo~%" is in a format string and is processed. "Foo\n" is part of the syntax of a string, and can be used anywhere without having to do something like #.(format nil "Foo~%")
<boeg>
What is a very good source to learn CLOS?
<phoe>
boeg: Sonja Keene's book
<boeg>
and is it pronounced C-LOS or KLOS?
<beach>
As you wish.
<boeg>
beach: well alright
<boeg>
:P
<boeg>
phoe: what was the title?
<LdBeth>
Komoon lisp
<phoe>
Object-Oriented Programming in COMMON LISP: A Programmer's Guide to CLOS
<LdBeth>
so klos
<boeg>
phoe: thank you
|SomeB| has joined #lisp
<beach>
LdBeth: Both pronunciations exist.
<flip214>
Come-On Lisp, by C.O.Moon
<boeg>
LdBeth: alright, thats how i've been saying it, but i listened to a podcast where they said "c-los" and i thought it was weird but maybe correct :P
jayde has quit [Quit: quit]
<beach>
I say C-loss myself. But I say Klimm (for CLIM) and some people say Kloss and C-limm.
rawr is now known as grumble
<aeth>
phoe: I'm not sure why you think that a new standard is hard, though. You don't need a new official Standard. Scheme has 1 official standard and like 7 unofficial ones, and the unofficial ones are the authoritative ones.
<aeth>
Although, seeing how long R7RS-large is taking to complete, it might take a decade...
<boeg>
beach: indeed, i'm all for letting people pronounce things as they wish, however I just wanted to get an idea about if there *are* infact people like me that says "klos" instead of "c-los". I dont mind people saying either, though :P
<phoe>
aeth: adoption.
<beach>
aeth: A standard is hard because it requires some smart, knowledgeable, and dedicated people with lots of time on their hands.
SomeB has quit [Ping timeout: 256 seconds]
<White_Flame>
or just 1 person to do a lot of work
<aeth>
Or lots of time (see: R7RS-large)
<no-defun-allowed>
In a more perfect world with a less inconsistent English, CLOSOS being pronounced as "colossus" would suggest CLOS is pronounced /kə-ˈläs/
<aeth>
I mean, a little bit of time over a long period of time
<aeth>
rather than a lot of time in a short period
<beach>
aeth: I don't think you can compare it to Scheme. Performance has traditionally not been a big deal for Scheme. It is a HUGE deal for Common Lisp. And if you get it wrong, you will ruin many possible compiler designs.
<White_Flame>
plus, the fad of ANSI/ISO languages is over
<aeth>
phoe: your point is pretty valid, though, because you need implementors on board or else you just reinvented CDRs, which never took off like SRFIs did
<phoe>
aeth: yes, if CDRs never really took off then how can CLtL4 take off
<beach>
SRFIs are much easier, because they started with such an impoverished language that it was easy to come up with additions.
<boeg>
phoe: oh, said state of affairs regarding Sonya Keenes book. Yet another thats only available in a terrible format digitally. It's too bad
<phoe>
;; I am purposefully skipping CLtL3 because it already started and went nowhere
<White_Flame>
yeah, and any opinions on how to basically mutate CL instead of purely extend it is going to be problematic
<White_Flame>
and even extension runs into a large cartesian of integration issues
<phoe>
boeg: yes, it's an old book. I sometimes wish it was reworked and published anew, also using modern libraries for e.g. multiprocessing.
<aeth>
The base CL language is missing many things. It's pretty easy to find them. Look at portability libraries, like e.g. http://portability.cl/
<beach>
Even extensions can be very tricky.
<boeg>
phoe: would you still say it is the best source to your knowledge?
|SomeB| has quit [Ping timeout: 265 seconds]
<aeth>
White_Flame: "foo\n" is actually probably one of the hardest things to add because it requires modifying the reader. Most things would be pretty easily extensible through the existing package system.
<beach>
boeg: I learned object-oriented programming with CLOS from reading and implementing the CLIM specification.
<White_Flame>
yeah, I stopped using the reader for my stuff, and have my own lexer/parser. The fact that you can't have multi-character punctuators is really annoying to me, and that there's no unread-char past a 1 char buffer
<phoe>
boeg: yes, the knowledge there aged pretty well - compared to the way it is physically presented, sadly.
<boeg>
beach: i guess thats another way to go about it :)
<White_Flame>
I run the lexer/parser right on the lisp input stream
<beach>
boeg: That's how I really understood CLOS. Keene's book was not good for me.
<boeg>
beach, phoe: right, so either I should get a physical copy of the Keene book, or implement the CLIM specification :)
<boeg>
or stumble upon a third route to enlightenment regarding CLOS
<beach>
You just have to read it.
jonatack_ has joined #lisp
<boeg>
beach: yes, it wasn't meant in a sarcastic tone, no offense meant
Cymew has quit [Ping timeout: 260 seconds]
<beach>
Sure, I understand.
Cymew has joined #lisp
momozor has joined #lisp
<momozor>
hi
<beach>
Hello momozor.
jonatack has quit [Ping timeout: 264 seconds]
<aeth>
phoe: there won't be a new standard until the major implementors want it... but if that's the main reason why people don't want one, then it enters the zeitgeist and discourages implementors from wanting one, thus becoming a self-fulfilling prophecy.
<aeth>
that being said, "foo\n" would probably be voted down because CL 2.0 (or 4.0?) would then have a separate reader
<flip214>
aeth: perhaps the readtable might be changed by a (in-package) line
pjb has joined #lisp
<momozor>
So uh..I want to ask on how do you guys document your function and variable types? Is it by letting declare, check-type, and declaim to do the job for you or document them inside a function docstring, parameter, etc?
<aeth>
beach: Performance, yes, that's a major issue. It makes certain things very controversial in language design, like dependent types
<momozor>
but I'm not sure if this is the best practice
<beach>
aeth: But unless the committee consists of smart, knowledgeable people with lots of time on their hands, there are going to be tons of suggestions like that, which would then have to be voted on. And some of them would then likely pass.
* momozor
this makes me look obsessive with types
sam68 has joined #lisp
<momozor>
*obsessed
<phoe>
momozor: not necessarily, docstrings like that are informative and I've seen them used around the Lisp world.
<beach>
momozor: Often, mentioning precise types can become a maintenance burden.
<flip214>
momozor: your [SRC] links use file:///
<phoe>
momozor: I usually use CHECK-TYPE for verifying function arguments.
<no-defun-allowed>
It's more common to use a documentation string for documentation than declared types in Lisp.
<flip214>
and there's a lone "ody>" at the end
<aeth>
CHECK-TYPE is safer, DECLARE is potentially faster/smoother. The issue is that implementations can (and SBCL with (safety 0) does) assume type declarations are valid rather than checking.
<flip214>
momozor: I suggest describing what it does in a docstring, and then to use check-type or an explicit function declaration for the types.
<aeth>
On the other hand, with a CHECK-TYPE instead of a DECLARE in SBCL, you have the situation where SBCL correctly type infers that any input is valid, up until the point of the CHECK-TYPE
<aeth>
so the parameters are correctly inferred to be T
<aeth>
So you can't really programmatically get that type information if it's in a CHECK-TYPE
<phoe>
aeth: even if CHECK-TYPE is at the toplevel of the function body? lemme check
<phoe>
huh!... correct
<aeth>
phoe: and beyond that, you can't access the inferred type... Although SLIME somehow does it for SBCL, so maybe I shouldn't say it's impossible.
<boeg>
also is there like a resource that takes you through actually implementing your own lisp so to get the enlightenment that i'm sure such an endeavor will reveal?
<jdz>
boeg: You might start with an existing implementation. I've heard ECL is very approachable.
<beach>
boeg: But, depending on your objectives, even such a great book is only going to tell you about a very small part of what you need to know.
<boeg>
beach, jdz: thanks!
<aeth>
phoe: What I'm probably going to do with my DEFINE-FUNCTION macro is make the default behavior different on different implementations, i.e. only defaulting to using DECLARE on implementations where it is safe/good to do so. But with SBCL, that still leaves the (safety 0) problem.
<no-defun-allowed>
What Lisp?
<aeth>
And it's not hard (but it is a bit verbose) to manually set DEFINE-FUNCTION to CHECK-TYPE or DECLARE...
<boeg>
beach: I can imagine - but I guess you cannot answer the questions you yet haven't discovered. Maybe reading LiSP is a good starting place
<no-defun-allowed>
And I believe it's only yours if you pick the implementation techniques and semantics yourself, honestly. That's where the fun is.
<beach>
boeg: It is a great book, and the English translation is better than the original, thanks to the brilliant translator.
mathrick has quit [Ping timeout: 244 seconds]
<boeg>
beach: good to know!
akoana has left #lisp ["Leaving"]
<boeg>
there is also LISP System Implementation. Maybe that's a good second read
<beach>
boeg: I absolutely can't recommend that book.
<boeg>
oh
<boeg>
how come?
<no-defun-allowed>
I think beach would have thought about "the questions [he] yet haven't discovered", having only written a great deal of the SICL Common Lisp implementation...
gxt has joined #lisp
<beach>
boeg: It is basically a commented listing of a C implementation of a particular Lisp system that is implemented in ways that no other implementation follows, and for good reasons.
SGASAU has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
<aeth>
beach: That's the first time I'm hearing about criticism of the book!
<boeg>
no-defun-allowed: not to be snarky, but i don't think even beach can ask a question he hasn't yet discovered :)
<beach>
aeth: Have you read it?
gxt has joined #lisp
<aeth>
beach: Unfortunately, no. It's expensive and rare.
SGASAU has joined #lisp
<beach>
Oh?
duncan_ has joined #lisp
<beach>
I don't think I paid that much for it.
<no-defun-allowed>
aeth: Are you thinking of Lisp in Small Pieces right now?
<aeth>
no-defun-allowed: oh, I see, I guess beach was talking about the other one there
<no-defun-allowed>
Yeah.
Kundry_Wag has joined #lisp
<phoe>
it was Sonja's CLOS book, and then the t3x book
<beach>
aeth: Like I said, LiSP is great, and the translation is fantastic, due to an excellent translator.
<aeth>
ah, okay, sorry, I got confused
<aeth>
I haven't heard of the other book
<no-defun-allowed>
The source code is available at http://www.t3x.org/lisp9/lisp9-20200220.tgz, and I guess I might be able to glean some things from the 5.6 thousand line C file that the interpreter resides in.
<aeth>
What does it do unusually?
<beach>
Memory management is one thing.
<beach>
Object representation.
<LdBeth>
no-defun-allowed: it’s actually a native code compiler
<no-defun-allowed>
It has one vector of CARs and one of CDRs, which I guess make caches happy.
<no-defun-allowed>
LdBeth: Really? The "blurb" says "LISP9 compiles to abstract machine code".
<jdz>
no-defun-allowed: how is two separate vectors for cars and cdrs cache-friendly?
<no-defun-allowed>
jdz: Sorry, I missed a (with-sarcasm ...) there.
<LdBeth>
Well, means you have to figure out abstract machine to native part (
<aeth>
how is that cache-unfriendly?
<aeth>
A modern CPU is probably used to reading several vectors in parallel...
Kundry_Wag has quit [Ping timeout: 256 seconds]
<no-defun-allowed>
I guess so. I was thinking that having the CDR next to the CAR in memory would be preferable for pre-fetching.
<jdz>
aeth: I'd expect processing two vectors (sequentially) to have twice the load on cache than one such vector.
<no-defun-allowed>
LdBeth: Maybe you're right, in the table of contents I see a "24.3 Compiling to Machine Code" in Part 3 of the book.
<aeth>
jdz: You could probably benchmark that with specialized arrays (e.g. :element-type single-float) where one function loops over one and one function loops over two, but half the size.
<beach>
The title of the book is highly misleading and suggests that there will be discussions about pros and cons of different ways of doing things like memory management, object representation, bootstrapping, evaluation, etc.
<momozor>
phoe, beach, flip214, no-defun-allowed, aeth: thanks! I guess describing the function to give a high-level POV and declaring types using CHECK-TYPE might be a good idea in my case. It's true that it can be a burden to maintain the precise types declaration in the docstring manually.
<no-defun-allowed>
There is also a lot of C in the book.
<jdz>
aeth: That would be a good exercise, yes. But I imagine these vectors being way bigger than the caches, so the size would not matter.
jprajzne has joined #lisp
<aeth>
momozor: If you generate the CHECK-TYPE or DECLARE TYPE in a macro, you could have that macro scan for docstrings and append the type information at the end.
<aeth>
The docstring (afaik) has to be a literal string, so you can just do (concatenate 'string docstring ...) at replace it in the generated DEFUN
<jdz>
Allocating conses from pools specialized on the type of CAR contents seems mildly interesting.
<beach>
aeth: Sure you can. Use the #. reader macro.
<aeth>
jdz: I've considered doing that for a stack machine for an interpreter
SGASAU has quit [Read error: Connection reset by peer]
<jdz>
Or even specialized on both CAR × CDR being pointer into the next cell (kind of CDR-coding).
<beach>
jdz: And what happens when you do a RPLACA?
<no-defun-allowed>
Iterating over one vector seems to be no faster or slower than two vectors of half the size in parallel.
SGASAU has joined #lisp
<flip214>
no-defun-allowed: well, beware of cache performance ... lots of non-linearities there
<jdz>
beach: Maybe cooperate with GC and evacuate the cell. I said "mildly" interesting; sure smart people have thought about this and found the idea not worth the trouble.
SGASAU has quit [Remote host closed the connection]
<beach>
jdz: Very likely, and that's what I would expect to see discussed in the book.
<jdz>
no-defun-allowed: I'm concerned about the "two vectors of half the size" part.
<aeth>
it sounds like one of those interesting things you might want to try in a language with immutable conses, which unfortunately, CL doesn't and never will have
<beach>
aeth: See, that's a typical suggestion that might come up in a standards committee!
<beach>
aeth: Now, figure out how to implement that efficiently without sacrificing performance in existing implementations.
<aeth>
beach: Immutable versions of every data structure would be very useful for compilers that want to optimize without forcing optimizations... which seems very CL to do.
SGASAU has joined #lisp
pjb has quit [Ping timeout: 265 seconds]
<beach>
aeth: Lots of stuff is useful. But you have to provide an efficient implementation technique that won't have any negative impact on existing techniques for mutable conses.
<aeth>
Immutable conses/vectors/strings wouldn't hurt anything, unless you reinterpret literal conses/vectors/strings to be the immutable versions, which would arguably help catch bugs, at the expensive of making everything a little bit more generic.
<beach>
aeth: And that is PRECISELY the problem with a new standard.
<LdBeth>
Why immutable then?
Bourne has quit [Read error: Connection reset by peer]
<momozor>
aeth: that's a great idea! I will look into implementing such macro.
<beach>
aeth: OK, so suppose you pass sometimes and immutable CONS cell sometimes an immutable one, to arbitrary functions.
<beach>
And suppose somewhere down the line, some function does a RPLACA.
<beach>
aeth: How do you check that this function has the right to do that.
<aeth>
momozor: be careful, though, because detecting docstrings is harder than it looks. e.g. (defun foo () "foo") doesn't (afaik) have a docstring, it returns a string. And the other complication is that afaik docstrings and DECLARE are interchangable, e.g. (defun foo () (declare ...) "foo" 42) and (defun foo () "foo" (declare ...) 42)
<aeth>
momozor: probably a few more, too
<beach>
aeth: Without sacrificing the existing performance with only mutable CONS cells.
<flip214>
well, if data could be annotated (cough types cough) as being immutable that's something the compiler could already check for.... atleast a SSC in some cases ;)
orblu has joined #lisp
<phoe>
you'd need another tag bit for that, most likely
<flip214>
beach: there'll be a segfault that'll be caught, of course ;)
<beach>
So another test?
<LdBeth>
I don’t think a immutable arrary would in anyway more performant then a mutable one
<beach>
aeth: And that is precisely what I mean by the people making decisions would have to be knowledgeable people who know how to evaluate stuff like that.
<flip214>
LdBeth: having immutable data means quite a few more optimizations for the compiler...
<flip214>
that's why fortran libraries are still in use
<beach>
flip214: You can't compare a static programming language to a dynamic one that way.
<aeth>
beach: Immutable conses would have to be their own sequence subtype, yes. As I said, you might want to reinterpret literal conses like '(1 2 3) to be immutable, but now you either break or slow down code that does (car l) where l is ultimately '(1 2 3)
<momozor>
aeth: ah I see..
<aeth>
(It breaks if CAR only applies to mutable conses, and it's slowed down if CAR can apply to either cons type)
<beach>
aeth: So you are saying that YOU are willing to accept a performance penalty for this new feature?
<LdBeth>
flip214: if that just means data can copied
<beach>
aeth: Again, that is EXACTLY the problem with an updated standard.
<White_Flame>
LdBeth: immutable means you avoid copies
<White_Flame>
and rather share old versions of stuff taht didn't "change"
<aeth>
beach: Well, no, if you resist the temptation to redefine literals to be immutables (which is very tempting) then it would only potentially slow down already generic stuff, sequence-generic stuff.
<beach>
aeth: New features would have to be carefully considered in terms of possible implementation techniques. And that requires detailed knowledge about memory management, compiler techniques, computer architecture, etc.
<LdBeth>
White_Flame: maybe could reduce gc overhead, but in principle still the same as the mutable version. And there’s generational gc
narimiran has quit [Ping timeout: 264 seconds]
gabiruh has joined #lisp
<White_Flame>
GCs are FAR easier to write for immutable systems as well
<White_Flame>
since you never have to worry about the references changing during scan
<beach>
In other words, whenever I see a "this would be good to have in an updated standard" and that phrase is not accompanied by some serious research into how it would possibly break existing things and/or slow things down, I must ignore it.
<beach>
White_Flame: Provided every object is immutable, sure.
<LdBeth>
Although might be helpful to provide pragmas that instructs compiler how to allocate the data
<beach>
But that would be a very radical new Common Lisp version.
doomlist3 has joined #lisp
<LdBeth>
White_Flame: even in GHC not everything in the heap is immutable
<aeth>
beach: It's a feature that people use often in similar programming languages and there's probably demand for it, and if implemented as a library it will be slower than at the implementation level, so there is specifically a demand for immutable conses. I think that's sufficient at this point.
<aeth>
beach: Obviously if we actually did Common Lisp 4.0 we'd have to research it, come up with the pros and cons, debate it, write a concrete proposal, etc.
<aeth>
And that's why a wishlist is so much faster than actually doing a new standard...
<White_Flame>
LdBeth: but do they separate areas of immutable data vs not?
<LdBeth>
Simple answer is then don’t
<White_Flame>
aeth: or make your own take on it, and screw consensus. But at least implement contentious ideas well
<LdBeth>
It involves update thunks due to lazy eval
<White_Flame>
the thing is, what is the "common" part of a new CL?
<phoe>
there's none
<White_Flame>
the most obvious things are standardization of the most common libraries, especially the trivial-* portability ones
<aeth>
Absolutely.
<phoe>
the new language doesn't have to be a compromise to unify existing dialects, hence it's not really "common" anymore
Bourne has joined #lisp
<aeth>
And then the controversial things would be things like new sequence types... Or \n in strings.
<White_Flame>
but in terms of totally new features, not really much has congealed
<phoe>
if anything, it can do what you say - unify the various extensions to the standard that have then been covered by the various portability libraries
<White_Flame>
however
<aeth>
White_Flame: A new CL would be "common" if (most of) the major implementations agree to it.
<White_Flame>
pre-CL, there was fracturing and exploration within the Lisp space that CL brought together
<White_Flame>
that exploration with a language stops to some degree with the introduction of a standard
frgo_ has joined #lisp
<White_Flame>
really, we need things that deviate from CL, such that those that seem good ideas could be reintegrated into the standard
<White_Flame>
the fear of deviating from it stops basic language innovation
Lycurgus has joined #lisp
<White_Flame>
CL was not 100% compatible with the lisps that came before it, either
<beach>
aeth: Faster, but also a very discouraging read, because often the person has not done the slightest research into the feasibility.
mathrick has joined #lisp
frgo has quit [Ping timeout: 244 seconds]
<aeth>
beach: Idk, that seems a bit too negative. There are two phases: breadth then depth, and breadth is a higher priority early on because it doesn't matter how well-researched a feature is, no one's going to make a new standard just to add one thing.
<aeth>
Although I guess the "depth" approach gives it the chance of implementing it as a portability library over multiple implementations' implementations of it
<White_Flame>
I mean, lexical variables was a pretty breaking language feature, that violated the design of purely dyamically scoped lisps. But without that violation, the innovation wouldn't have happened
<beach>
aeth: That can't possibly be the way for a committee to work, i.e. wading through tons of uniformed proposals, and then have to write motivated rejection messages to each one.
<beach>
aeth: I for one would not participate in such a committee.
<aeth>
White_Flame: CL doesn't really need breaking changes. Ideally, you would just (:use #:cl2020) instead of (:use #:cl) although yes that does still restrict some things
<flip214>
White_Flame: but breaking backwards compatibility is awkward. look at perl5/perl6 (raku), python 2=>3, java 8 vs. 11 vs. 14 (standard libraries changed), C++, Go 1 => 2, ...
<flip214>
aeth: well, there's CL21 already, yes.
<White_Flame>
microsoft fears breaking backwards compatibility in many thigns, and they end up with a nightmare mudball
<aeth>
flip214: yes, CL21 is a terrible name for a library because names like "CL21" should be reserved for... if implementations want to make a new version of CL in 2021.
<flip214>
that's the other side of the story, right
<White_Flame>
aeth: that'd be y2.1k incompatible
<aeth>
C++ has no issue with that...
<flip214>
aeth: getting a new CL for the 21st _century_ would be good enough... then there could always be a CL22, CL2021, or whatever
<beach>
aeth: I think every proposal should be accompanied by documented research into how it can be implemented efficiently (among other things).
rgherdt_ has joined #lisp
<White_Flame>
beach: or by being explored in non-CL compatible separate implementations
<aeth>
beach: I agree, but we're not at the stage of proposals yet, afaik.
<White_Flame>
or breaking forks to explore concepts
<beach>
White_Flame: Sure, if it is compatible with performance requirements in that implementation.
<aeth>
Or, rather, the only completed proposals for a new standard are things that already exist as portability libraries
<aeth>
Perhaps that's really the way to go, though.
<beach>
aeth: Oh, but I see frequent proposals like that here, with no research what so ever.
<White_Flame>
aeth: yep, that's the low hanging fruit for new versions (or even just addendums)
<White_Flame>
and should be taken
<beach>
aeth: And it is discouraging, because it is basically just noise, until the research is shown as well.
<White_Flame>
especially since the real CL implementations already have implemented tons of these things in extension packages
rixard has quit [Read error: Connection reset by peer]
<beach>
White_Flame: Now, that's a different story. I am all in favor of an updated standard that basically just documents what all implementations already do.
<White_Flame>
right, hence teh trivial-* portability sims exploring what the interfaces woul dbe
<beach>
Immutable CONSes is not one of them.
<White_Flame>
*shims
ljavorsk has joined #lisp
rixard has joined #lisp
<beach>
White_Flame: In fact, WSCL is such an idea.
<aeth>
beach: Unfortunately, extensible sequences is only supported by SBCL, ABCL, and Clasp, which is probably why we don't see a lot of experimentation in sequences. (And even that is probably going to be a performance loss)
<flip214>
beach: I guess such proposals without research are called "brainstorming" or "wishes" ;)
gabiruh has joined #lisp
<beach>
flip214: Which is very tiresome when done by uninformed people, because of the large amount of work to refute the suggestions.
<beach>
aeth: No, there is no performance loss in extensible sequences.
<beach>
aeth: Typically, CONS and VECTOR are tested for first, and if it is neither, then, instead of calling error, a generic function is called.
<flip214>
beach: I understand that. quite a sizable part of my job is to say "no" to people as well
<flip214>
sadly that normally takes quite a lot more words
<beach>
Exactly.
<beach>
But you are paid to do that then.
<beach>
A committee would be working for free.
momozor has quit [Quit: Lost terminal]
<beach>
aeth: Not only is there no performance loss. It is trivial to implement too.
<beach>
The hardest part is to decide the name of the package in which to stick the name of the generic function.
<beach>
Now, with the SICL fast generic-function dispatch technique, you would do the first two tests in the generic function as well, so you would simplify the implementation that way. And it is just as fast.
<Fare>
beach: I was thinking about doing a MOP for prototype OO and/or for class-on-top-of-prototype, or best-of-both-world, etc.
<Fare>
maybe having implemented MOP things in SICL gives you ideas about that.
<beach>
Sounds great!
<beach>
Not really. I think one would have to study what the Self people did.
<beach>
I have intended to do that in the past, but haven't found the time.
rgherdt has quit [Ping timeout: 265 seconds]
roelj has joined #lisp
shifty has quit [Ping timeout: 260 seconds]
<Fare>
My reading list is super long
orivej has joined #lisp
<flip214>
I've got a list of reading lists
<aeth>
I have a reading vector instead, for better cache performance.
<shangul>
Recommended ncurses library for Common Lisp supporting colors?
<no-defun-allowed>
I apparently have some kind of Bloom filter for reading, because I can't remember what to read, but when I find something I say "oh, I've been meaning to read that".
<jmercouris>
shangul: there is one but beware of the license
peterhil has quit [Read error: Connection reset by peer]
<shangul>
Yeah that's a problem
<shangul>
MIT/X11 style is better for my application I guess
MerlinTheWizard has quit [Ping timeout: 244 seconds]
<shangul>
I need a good tutorial and docs, too. I have never worked with ncurses before.
orblu has quit [Ping timeout: 240 seconds]
doomlist3 has quit [Ping timeout: 246 seconds]
heisig has joined #lisp
Nilby has joined #lisp
nika has joined #lisp
<jdz>
jackdaniel is working on terminal backend for McCLIM, and I'm pretty sure he said he's doing that without curses by using a subset of escape sequences.
<jdz>
I'll probably need something like this in the near future, so I'm interested in the answers.
Lycurgus has quit [Remote host closed the connection]
reggie__ has quit [Read error: Connection reset by peer]
<jackdaniel>
you could call these rendering algorithms implemented for characters an art;-)
<jdz>
I discovered yesterday that Unicode box drawing glyphs don't have arrows.
Kundry_Wag has quit [Ping timeout: 258 seconds]
<jackdaniel>
brb
<jdz>
I.e., it's impossible to draw a box with an arrow pointing to it (to the edge).
karlosz has quit [Quit: karlosz]
amerlyq has joined #lisp
milanj has joined #lisp
<pjb>
There's:
<pjb>
but it's not a box element.
<Nilby>
This │←── isn't good enough?
<jdz>
Nope.
<jdz>
It's way worse for vertical axis.
<White_Flame>
and is horribly unaligned on my screen
<jdz>
Might be because of missing glyphs in your font.
<White_Flame>
the arrow stem doesn't align with the horizontal line
<Nilby>
Looks fine in mine. ☹
<no-defun-allowed>
Not here, that ←is lower than the —
<White_Flame>
I doubt unicode defines them as needing to connect
<jdz>
But that is one of the problems with no arrows in box drawing page.
<jdz>
*block
<jdz>
Maybe they'll add a few "combining arrows" in a future version.
marcoxa has joined #lisp
<marcoxa>
Hi... anybody here now?
<phoe>
marcoxa: yes
<jdz>
marcoxa: Do you want an answer from everybody?
leo_song has quit [Ping timeout: 246 seconds]
<phoe>
and even if they aren't, they'll come back sooner or later and read the backlog
<marcoxa>
Nope. Just pinging... :)
<phoe>
therefore: pong
<marcoxa>
:)
SGASAU has quit [Remote host closed the connection]
SGASAU has joined #lisp
leo_song has joined #lisp
gabiruh_ has joined #lisp
gabiruh has quit [Read error: Connection reset by peer]
<jackdaniel>
o/
<jackdaniel>
I'm back
<phoe>
welcome back
<jackdaniel>
jdz: writing a console backend already resulted in numerous bugs fixed
<jackdaniel>
because when a pixel is not the square, you see plenty of invalid assumptions on the screen
<jackdaniel>
also it shows that measurement unit which depends on a device unit is very inadequate, because once 200px is around 3cm and once it is half of the 4k screen
<jackdaniel>
(and that 100px x 100px is not always a square!)
gabiruh has joined #lisp
ayuce has joined #lisp
<MichaelRaskin>
Full (double) width characters in monospace fonts sometimes solve that latter problem, but this 100×100 square is usually still not what you would want
<Nilby>
I use (code-char #x2580) for terminal graphics.
<jdz>
Or use ultra wide font (like Inconsolata Ulra-Expanded).
<jdz>
*Ultra
<Nilby>
▀ instantly makes things look better, but it makes rendering code a little more annoying.
scymtym has quit [Ping timeout: 256 seconds]
ayuce has quit [Remote host closed the connection]
<Nilby>
jackdaniel: You probably know that PDF/Postscript uses it's own device independent made up unit, and that browsers try to do that, but usually fail.
<jdz>
Nilby: Characters from "Block Elements" Unicode block can increase resolution two times; in case of upwards and rightwards growing blocks — eight times.
<jdz>
The braille block increases horizontal resolution two times, and vertical four times.
<jackdaniel>
the point is that it reveals problems, it is not a font what is at fault :)
<Nilby>
Hmmm. Using that upwards and rightwards would really complicate the rendering.
<jackdaniel>
Nilby: I do, but thanks for pointing this out. they use points, 1/72in
<jdz>
Nilby: it does not work for general rendering, only when drawing horizontal and vertical bar graphs with one end having higher resolution.
<jackdaniel>
there is also dp unit proposed by the material design guidelines, that is 1px on 160dpi screen, a physical size which maps well to the "average case" when assuming pixels are small squares on a monitor
* jdz
notices this is #lisp and not #clim
<no-defun-allowed>
An anti-climactic observation.
<jackdaniel>
clim is still ontopic on lisp luckily
<jackdaniel>
it is not that it is written in ruby
<jdz>
Now that you mentioned Ruby, I want to bring up the following issue:
<jdz>
(end of joke)
* jackdaniel
slowly starts laughing ;)
<jdz>
I added that so that people holding their breath stop doing that.
specbot has quit [Read error: Connection reset by peer]
minion has quit [Read error: Connection reset by peer]
minion has joined #lisp
specbot has joined #lisp
<jmercouris>
(end joke)
<jmercouris>
(with-joke ("How that you mentioned Ruby, I want to bring up the following issue:"))
peterhil has quit [Read error: Connection reset by peer]
peterhil` has joined #lisp
SGASAU has quit [Ping timeout: 260 seconds]
scymtym has joined #lisp
varjag has joined #lisp
stoneglass has joined #lisp
<flip214>
jdz: does that mean you see no issues with Ruby? Or that there aren't any?
<phoe>
I'm bootstrapping a series of online Lisp meets that will hopefully gain traction, since the ELS formula this year turned out to be surprisingly nice. I'll try to kick the series off myself and talk about condition systems - more details at https://www.reddit.com/r/lisp/comments/ga7kfk/online_lisp_meeting_series/
Lord_of_Life_ has joined #lisp
theosvoitha has quit [Quit: Connection closed for inactivity]
Lord_of_Life has quit [Ping timeout: 260 seconds]
Lord_of_Life_ is now known as Lord_of_Life
didi has left #lisp ["O bella ciao bella ciao bella ciao, ciao, ciao."]
jonatack has quit [Read error: Connection reset by peer]
grumble has quit [Quit: Well, would you look at the time. I've almost missed my ambiguous, non-existent appointment that I have scheduled just when I start to lose interest in my current conversation.]
<phoe>
the only unknown is who would like to talk next
monokrom has joined #lisp
<phoe>
_death suggested a very good idea, organizing lightning talk series with multiple short presentations
jonatack has joined #lisp
Nilby has joined #lisp
grumble has joined #lisp
<MichaelRaskin>
phoe: I guess you can always up the level of crazy of the demos invited if you feel like not having enough talks?
jonatack has quit [Ping timeout: 256 seconds]
<phoe>
MichaelRaskin: what do you mean, how crazy are you thinking, and why do I feel that you are about to propose something related to hardcore code walking
jonatack has joined #lisp
<phoe>
I mean, I, personally, would like to see some of that
<MichaelRaskin>
I refuse to recognise code walking as crazy! We need to make it Lisp-mainstream to regain our talking points like «we can just build it on top of the language»
<phoe>
I have to admit that I enjoy this attitude of yours
<phoe>
you're hired
<MichaelRaskin>
I dunno, I think QueryFS is kind of crazier, but apparently I need to wait a bit more with it.
<Nilby>
What's not to like about "crazy" Lisp demos? Even if you don't want to use it, it's fun to see.
<MichaelRaskin>
There seems to be some expansion of «come on, Swank ≠ Emacs» but not yet enough for people to recognise «random other stuff» as worth integrating with in a uniform way. (FS API is exactly the way of integrating with «randome other stuff» without specificity)
* p_l
is suddenly reminded of "json-metaclass go brrrr"
<MichaelRaskin>
Nilby: well, specifically with QueryFS there are too many people who think that everything is always inside Emacs, so of course the appeal is lost on them
luckless has joined #lisp
Lycurgus has joined #lisp
<Nilby>
Yeah, I don't even use swank/slime, I'm probably on the "crazy" side.
gabiruh has quit [Ping timeout: 246 seconds]
gabiruh has joined #lisp
<MichaelRaskin>
I write Common Lisp (but also POSIX shell) code in Vim, and I do not even use SLIM-V/VLIME.
monokrom has quit [Remote host closed the connection]
<phoe>
madness
<Lycurgus>
"crazy" that's short for "thinks for themselves" innit
<Lycurgus>
also would tend to be the case if you used a commercial lisp with an ide
ayuce has quit [Remote host closed the connection]
<MichaelRaskin>
Well, if one wants to expand Common Lisp usage, one needs to target people who want to use «also Common Lisp», not just people actually committed to focus on Common Lisp and do it right.
flip214 has quit [Read error: Connection reset by peer]
<phoe>
right
monokrom has joined #lisp
jruiz has joined #lisp
flip214 has joined #lisp
<shangul>
jmercouris, I just realized that "The API is not yet stable."
rgherdt has joined #lisp
<shangul>
I still wait for an answer from people with experience with ncurses and CL together.
peterhil` has quit [Read error: Connection reset by peer]
stoneglass has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
peterhil has joined #lisp
stoneglass has joined #lisp
<_death>
shangul: I wrote something for that, that uses acute-terminal-control
toorevitimirp has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
rogersm has joined #lisp
Domaldel has joined #lisp
Domaldel has quit [Remote host closed the connection]
<shangul>
flip214, Thank you. Will look into that
<shangul>
Xach, Cellular Automata
<shangul>
_death, For my purpose. Got link or something?
ahungry has joined #lisp
sunwukong` has joined #lisp
sunwukong has quit [Read error: Connection reset by peer]
<_death>
shangul: it's part of a larger system that's not ready for publishing, but I updated a gist with code for the relevant mechanism.. it should not be hard to make it use cl-charms (or have multiple backends...) .. one thing I'm not sure about is how colors are represented (due to acute-terminal-control)
<_death>
(what I mean about colors, is I'm not sure I like how they're represented at the moment)
amerlyq has quit [Quit: amerlyq]
toorevitimirp has quit [Remote host closed the connection]
<shangul>
_death, Thanks anyway. Will look into that soon
toorevitimirp has joined #lisp
ljavorsk has quit [Ping timeout: 246 seconds]
cantstanya has quit [Remote host closed the connection]
cantstanya has joined #lisp
sjl_ has joined #lisp
reggie__ has quit [Remote host closed the connection]
reggie__ has joined #lisp
SGASAU has joined #lisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
efm has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.2)]
bitmapper has joined #lisp
amerlyq has joined #lisp
SGASAU has quit [Ping timeout: 256 seconds]
gko has quit [Remote host closed the connection]
__jrjsmrtn__ has joined #lisp
_jrjsmrtn has quit [Ping timeout: 244 seconds]
toorevitimirp has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
cmack has joined #lisp
fourier has joined #lisp
jprajzne has quit [Quit: Leaving.]
rippa has joined #lisp
xkapastel has quit [Quit: Connection closed for inactivity]
fourier has quit [Ping timeout: 244 seconds]
toorevitimirp has quit [Remote host closed the connection]
roelj has quit [Read error: Connection reset by peer]
sunwukong` has quit [Quit: Leaving]
rogersm has quit [Quit: Leaving...]
rgherdt_ has quit [Remote host closed the connection]
ralt has quit [Quit: Connection closed for inactivity]
EvW has quit [Ping timeout: 244 seconds]
jprajzne has joined #lisp
<mgr_>
asdf doesn't support good old logical-pathname-translations anymore? what a shame. I finally noticed why some packaged would load with my updated system because I set up my asdf:*central-registry* with logical pathnames...
<mgr_>
and that fails for asdf systems with dots, like cepl.build or com.gigamonkeys.binary-data
<mgr_>
*why some packages would NOT load*
<mgr_>
or is that an sbcl bug... I get a [Condition of type SB-KERNEL:NAMESTRING-PARSE-ERROR]: "parse error in namestring: logical namestring character which is not alphanumeric or hyphen #ß. com.gigamonkeys.binary-data"
<mgr_>
why does sbcl then complain about the digit?
<mgr_>
ah, sorry. :) digit not dot.
<mgr_>
so these names with dots cannot be described with logical pathnames it seems?
lavaflow has joined #lisp
<mgr_>
hm, yes, the problem is really a filename like com.gigamonkeys.binary-data.asd or cepl.build.asd
dale_ has joined #lisp
dale_ is now known as dale
<jmercouris>
so I have a restart
<jmercouris>
how can I etner some arbitrary code instead of selecting a restart?
<jmercouris>
I want to inexpect the value of some variable
<jmercouris>
I just type form instead of restart
<beach>
In SLIME?
<jmercouris>
in shell
<jmercouris>
Shinmera: I tried cffi:*foreign-library-directories* and I got NIL
gabiruh has quit [Ping timeout: 260 seconds]
marcoxa has quit [Ping timeout: 246 seconds]
MerlinTheWizard has joined #lisp
rtvdenys has quit [Quit: Leaving]
scymtym has quit [Ping timeout: 240 seconds]
decent-username has joined #lisp
hiroaki has joined #lisp
asarch has joined #lisp
EvW1 has joined #lisp
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
jprajzne has quit [Client Quit]
jprajzne has joined #lisp
schjetne has quit [Ping timeout: 246 seconds]
SGASAU has joined #lisp
shifty has quit [Ping timeout: 246 seconds]
shifty has joined #lisp
<phoe>
jmercouris: in shell? you should have a REPL
<phoe>
I mean, if you are in the debugger
vivit has joined #lisp
<vivit>
Is there any way to inherit a class allocation?
<Bike>
what do you mean?
<phoe>
vivit: other than the fact that you inherit the whole slot?
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
IRC-Source_21 has quit [Quit: Connection closed]
<vivit>
If you have some class FOO and some class BAR which inherits FOO, can you have a slot A on both which is class-allocated, but individually for each class? So if I have objects *FOO-1*, *FOO-2*, *BAR-1*, and *BAR-2*, such that (A *FOO-1*) and (A *FOO-2*) reference the same thing, and (A *BAR-1*) and (A *BAR-2*) reference a different same thing
<vivit>
And can you do this without duplicating the slot definition
<jackdaniel>
you should name the slot differently and have the accessor of the same name
<Bike>
i think you need to duplicate the slot definition.
<vivit>
rats
jprajzne has quit [Client Quit]
jprajzne has joined #lisp
ntqz has quit [Ping timeout: 246 seconds]
ntqz has joined #lisp
theseb has joined #lisp
ntqz has quit [Remote host closed the connection]
<theseb>
Why are you able to define functions in any scope but macros can only be defined in the top level?
<Bike>
what do you mean? you can define macros at any scope.
<theseb>
i don't see hell will break loose if someone does defmacro in some random location
<theseb>
Bike: i can look up the link but i read that macros must be in the "toplevel"
<Bike>
if you're compiling a file, the compiler won't notice macro definitions that aren't at top level. is that what you mean?
<theseb>
Bike: maybe that is what they meant
<theseb>
Bike: but why can't the compiler see macro defs anywhere?
<Bike>
for the compiler to be able to use a macro, it has to be able to define it at compile time. if your macro definition tries to close over a variable or something, the compiler couldn't use it anyway, since that variable doesn't exist at compile time.
kristof has joined #lisp
<Bike>
and if a macro doesn't close over anything, it might as well be at top level
<jackdaniel>
it is to keep things sane for the compiler developers
emacsomancer has quit [Read error: Connection reset by peer]
<theseb>
Bike: when you say "close" to you mean..."have access to the variable's value"?
<theseb>
s/to/do
<Bike>
like a closure. you know what a closure is, right?
<theseb>
no
<jackdaniel>
(let ((foo 42)) (defmacro bar …))
<jackdaniel>
macro bar closes over a variable foo
<Bike>
you should figure that out first. it's a fundamental concept of the language.
buffergn0me has joined #lisp
<theseb>
ok
<theseb>
Bike: how do you know if some expressions is "at the toplevel"?
ahungry has quit [Read error: Connection reset by peer]
<Bike>
a complex set of rules defined in 3.2.3.1
<Bike>
to sum up, forms are not contained in another form are top level, as are subforms of operators such as progn, locally, and macrolet, but not let or flet
<Bike>
provided the operator form is itself toplevel
<kristof>
Oh, I see another person has already linked that.
emacsomancer has joined #lisp
<theseb>
Bike: when you define a function with lambda it may have free variables....the values those free variables take must be defined using the environment WHEN THE FUNC DEF was evaluated if you are using lexical scoping
<theseb>
Bike: the func + necessary environment = closures! yes?
<Bike>
yeah.
<theseb>
w00t!
<theseb>
thanks
scymtym has joined #lisp
<Bike>
so, the point is that when you do defmacro or whatever, you're defining a function in the same way, so it could be a closure
<Bike>
this is a pretty unusual thing to do, but it's allowed, and that's what a non toplevel defmacro would be like
rwcom has joined #lisp
SGASAU` has joined #lisp
prefixt has joined #lisp
prefixt has joined #lisp
SGASAU has quit [Ping timeout: 256 seconds]
kristof has quit [Ping timeout: 246 seconds]
kristof has joined #lisp
SGASAU` has quit [Remote host closed the connection]
SGASAU` has joined #lisp
dnaeon has joined #lisp
SGASAU` has quit [Remote host closed the connection]
<dnaeon>
hey Lispers!
kristof has left #lisp [#lisp]
jprajzne has quit [Quit: jprajzne]
<dnaeon>
Just got SBCL updated on my macOS Catalina to version 2.0.4 and got this error when trying to start the REPL
<dnaeon>
core was built for runtime "Mojave-2.local-brew-2019-04-04-00-24-50" but this is "dnaeon-a03.local-dnaeon-2020-04-29-21-24-19"
<dnaeon>
Anyone else got this, or is it just me?
<dnaeon>
For whatever reason it seems like I got a build from Mojave, while I'm actually on Catalina
<dnaeon>
Using `brew` to install it, first time I got this problem during update.
jprajzne has joined #lisp
choegusung has joined #lisp
SGASAU has joined #lisp
schjetne has joined #lisp
<boeg>
I have installed sbcl via roswell, and are now trying to build a project that looks for "sbcl" in $PATH in my shell, but there is none - is there a way to have roswell place a symlink or something for the default sbcl binary?
msk has joined #lisp
hiroaki has quit [Ping timeout: 260 seconds]
marcoxa has joined #lisp
<mgr_>
poing
ay has joined #lisp
Lycurgus has joined #lisp
<phoe>
boeg: the easiest way I've found myself is to `apt install sbcl` that will drop a separate system-wide sbcl
<phoe>
dnaeon: which Lisp implementation?
<mgr_>
(sorry, wrong channel)
<boeg>
phoe: that just seems a bit weird to install sbcl twice :/
<dnaeon>
phoe: SBCL
<phoe>
boeg: it is, but I have no idea how to configure roswell like that
<boeg>
phoe: alright :)
efm has quit [Ping timeout: 244 seconds]
<phoe>
dnaeon: huh, it seems that cores got mixed up during upgrade?... I mean, it seems to try to load a core from the older version