<opalvaults2>
phantomics: sorry for the delayed response. I just want a simple web interface to interact with a server-side ticketing system + sqlite DB
lisp123 has quit [Ping timeout: 268 seconds]
<phantomics>
That should be an easy project, React could work or you could just write a simple HTML form posting to a CL server
<opalvaults2>
I'm a bit stuck between Racket and Common Lisp. I'd like to stop spinning my wheels and just make it in Common Lisp because it's got a better REPL.
<rotateq>
but Racket and all the libs and subdialects are great
<Guest74>
thoughts on font:glyph (char font) or font:glyph (font char) ?
<opalvaults2>
_death: this looks really interesting! thank you, i'll research a bit
<opalvaults2>
rotateq: i'm having trouble grokking the web server lib surprisingly.
<opalvaults2>
racket web server lib*
Algernon666 has joined #commonlisp
<rotateq>
hmm, i can't help you, this is absolutely not my topic
<opalvaults2>
it's okay, I think I am going to do it in common lisp. caveman2 has been an actual breeze to set up and get working.
Algernon91 has joined #commonlisp
Algernon666 has quit [Read error: Connection reset by peer]
<opalvaults2>
I'll see if I can make clog work as well, because that's an excellent resource.
<rotateq>
but maybe in the future when i need to I'll use clsql plus cl for the backend and elm for the frontend. or i don't know, we'll see
<opalvaults2>
is elm another lisp?
<rotateq>
okay let me see what clog is for ... (or logging?)
<rotateq>
no, it's an alternative to javascript for having runtime save code
<rotateq>
ahh it's for GUIs
Algernon91 has quit [Ping timeout: 240 seconds]
<rotateq>
or I build another backend with Erlang or Haskell, when concurrency is needed. or or or, many sane possibilities, even using ZeroMQ for distributed applications that shall scale
<hayley>
opalvaults2: Elm is Haskell without the type classes, and a BDFL who takes the dictator part too seriously.
<hayley>
rotateq: I don't see why, as you can write concurrent programs with (common extensions to) Common Lisp.
<rotateq>
or doing it like NASA and embedding a CL REPL everywhere for more debugging capabilities from 100 million miles away
<rotateq>
i know that hayley ;)
taiju has quit [Ping timeout: 252 seconds]
<rotateq>
yes of course
<hayley>
"Is Common Lisp webscale?"
<rotateq>
don't know, is the web lispscale?
<dbotton>
<opalvaults2> see the clog db demo 4 and the database tool that uses sql
<opalvaults2>
hayley: sounds like something I want to avoid.
<opalvaults2>
dbotton: I was actually just recommended that in #scheme actually. thanks! :)
<opalvaults2>
oh wait that was here
<opalvaults2>
too many rooms open
<rotateq>
haha ^^
<hayley>
Given that the Web is not a distributed version of Symbolics Concordia, all signs point to "no".
rgherdt has quit [Ping timeout: 268 seconds]
<rotateq>
and too much is still centralized structured
<hayley>
Yeah, well, I retired.
<dbotton>
<opalvaults2> I am working on a gui builder currently still believe I'll have something working by Jan 1
<dbotton>
the ability to design and drop controls working, working on basic code gen now
<opalvaults2>
sounds great! my e-mail is ry@opal.sh. i'd be happy to hack around on it.
unixlisp has quit [Remote host closed the connection]
unixlisp has joined #commonlisp
unixlisp has quit [Remote host closed the connection]
unixlisp has joined #commonlisp
<unixlisp>
parameter. What is the exact result?
<White_Flame>
(cons *a* nil) evaluates the value of *a* when the DEFPARAMETER is evaluated, and you're never changing the cons cell at *M* after defparameter
<White_Flame>
you're only ever changing the cons cell referenced by *L*
_73``` has joined #commonlisp
<unixlisp>
Acording spec, is that exact result?
<White_Flame>
what do you think it is?
<unixlisp>
not sure.
<White_Flame>
well, this is basically (and I haven't done C in like a decade or two):
<White_Flame>
int a = 0; //toplevel/static/global/whatever
_73`` has quit [Ping timeout: 252 seconds]
<White_Flame>
l = new Cons(a,NULL);
<White_Flame>
m = new Cons(a,NULL);
<White_Flame>
l.car = 1;
<White_Flame>
(and yeah, I know that "new" is C++, sue me ;) )
<White_Flame>
CL's *A* is different than C's int a in that the former can have dynamically scoped, thread-local bindings of the globally-named value *A*
<White_Flame>
(primarily)
perrierjouet has joined #commonlisp
<White_Flame>
also, #clschool is a great place to ask introductory questions, they might get lost here
<unixlisp>
spec absolutely define this behavior? such as a highly optimised situation?
<White_Flame>
yes
<White_Flame>
now, also DEFPARAMETER is not a declarative statement as a toplevel "int a" is to the compiler. DEFPARAMETER changes the runtime to now have *A* declared & allocated properly
<White_Flame>
C can't do any runtime compilation natively
<White_Flame>
so there can be load ordering & initialization effects, but that's beneficial in that you get the entire Common Lisp language at compile-time, too, to generate code or precalculate anything you want
unixlisp has quit [Remote host closed the connection]
unixlisp has joined #commonlisp
AndrewYu has quit [Remote host closed the connection]
<unixlisp>
I just not see the specifation at spec. not sure all possible situations.
Oladon has joined #commonlisp
unixlisp has quit [Remote host closed the connection]
unixlisp has joined #commonlisp
unixlisp has quit [Remote host closed the connection]
unixlisp has joined #commonlisp
unixlisp has quit [Remote host closed the connection]
unixlisp has joined #commonlisp
unixlisp has quit [Remote host closed the connection]
<unixlisp>
Binding is abstract, high level, the best terminology that describes variable in CL. Yet I am not sure it is not same as C at some situations, still standard conforming.
abrantesasf has quit [Read error: Connection reset by peer]
<White_Flame>
which C situations in particular?
<rotateq>
aren't the details of such things more a question of the implementation rather than the specification?
abrantesasf has joined #commonlisp
<White_Flame>
depends on how specific it is, so far the questions are only about "is it different" which could have a million different answers
<rotateq>
yes then first talking about the specification of the question ^^
<unixlisp>
Really? I really care about this detail, it is a *big* feature of LISP.
<hayley>
Yes, the semantics of Lisp are described in terms of a high level, abstract "evaluation" machine. To the best of my knowledge, the semantics of C are described in a similar way.
<White_Flame>
right, C goes through great lengths to avoid the actual memory layout of what it's doing, and any code that relies on it is technically undefined behavior
<White_Flame>
much of it is defining clear pointer math operations, though it's still separate from memory layout technically
<unixlisp>
Then this is an undefined behavior in CL? Maybe I need to read spec word by word.
<hayley>
The nature of how binding is implemented is irrelevant for a language standard.
<hayley>
The other part of your example is object identity.
<hayley>
As per the standard, CONS creates a "fresh" cons cell, which never appears as the result of another call to CONS. So we know that the result of (CAR C) is unaffected by (SETF (CAR B) 1).
abrantesasf has quit [Remote host closed the connection]
<White_Flame>
unixlisp: no, all you're doing is evaluating a variable to get its value, there's nothing weird at all. The only learning curve here would be dynamic bindings, which you're not using
<White_Flame>
what aspect do you think is suspect in being UB?
<unixlisp>
variable can *own* value like c.
<unixlisp>
(declare (optimize (speed 3) (safety 0))) (let* ((a 0) (b (cons a 2)) (c (cons a 3))) (setf (car b) 1) (car c)) => ?
<White_Flame>
safety 0 could eliminate tests to see if B and C are actually cons cells
<White_Flame>
when accessing the CAR
<White_Flame>
but variables do not "own" values, nor in C. If "int a=1; int b=a;", then both are independently 1. Changing one doesn't change the other, nor can you change the value of "1" in C
<White_Flame>
(as you can do in some other languages)
<White_Flame>
((to your own peril))
<unixlisp>
(car c) *must* be 0? *sure* is this behavior?
<hayley>
Yes.
<hayley>
Disabling safety checks doesn't change the semantics of programs which don't trip those safety checks.
<White_Flame>
unixlisp: yes. what manner of execution do you think it wouldn't be 0? obviously you're suspecting something, but I'm not sure what it is you suspect
<White_Flame>
especially since there's zero difference between CL and C in these simple conditinos
<White_Flame>
*conditions
<unixlisp>
yes. I suspect it *can* be 1 and standard conforming.
taiju has quit [Ping timeout: 240 seconds]
<edgar-rft>
unixlisp: only this code does what you suspect: (let* ((a 0) (b (cons a 2)) (c b)) (setf (car b) 1) (car c)) => 1, because c is now a pointer to b
<White_Flame>
and the value at b is a composite that is referenced
<White_Flame>
but this was about changing a number, or a variable holding a simple number
opalvaults2 has quit [Remote host closed the connection]
<White_Flame>
unixlisp: also note that large numbers can be referenced instead of immediate as well, but that doesn't change the semantics, since number values themselves are immutable
makomo has quit [Ping timeout: 260 seconds]
lisp123 has joined #commonlisp
igemnace has quit [Remote host closed the connection]
taiju has joined #commonlisp
karlosz has joined #commonlisp
<beach>
Good morning everyone!
<unixlisp>
number value are immutable, spec can guarantee it?
<beach>
unixlisp: There is no defined operation that will modify a number.
<beach>
unixlisp: What is the purpose of this exercise?
<unixlisp>
clear every point about spec. first of all is binding.
<beach>
Do you mean "clear" as in making sure you understand it?
<unixlisp>
yes
<beach>
Got it.
<unixlisp>
Recently I am reading mail archive (cddddr.org) and it is helpful.
<beach>
Common Lisp semantics is typically much simpler that that of languages with manual memory management, because Common Lisp uses what I call "uniform reference semantics", so that there is no need to distinguish between an object and a pointer to an object.
<unixlisp>
(let* ((a 0) (b (cons a 2)) (c (cons a 3))) (setf (car b) 1) (car c)) => ? all possible conforming implementations.
<hayley>
0. Again.
<beach>
Indeed.
<unixlisp>
standard defined behavior?
<beach>
Yes.
<hayley>
SETF on a variable name replaces the object in the appropriate binding. It does not modify the object.
<beach>
hayley: But here the place is (CAR B).
<hayley>
SETF on a place like (CAR something) does modify an object, but in this case, it modifies a different object.
<beach>
unixlisp: B and C will contain distinct CONS cells, so setting the CAR of B does not have any effect on the contents of the CONS cell that is the value of C.
<beach>
unixlisp: What kind of semantic model would give a different result? I can't even imagine such a thing.
<unixlisp>
setf modify object but conform standard
<beach>
The object is indeed modified. The CAR slot of the CONS cell that is the value of B will initially contain 0, and then after the SETF form has been evaluated, it will instead contain 1.
<White_Flame>
beach: there are languages where you can change the value of the canonical integers
<White_Flame>
but that would be something like (setf 0 1) to redefine the notion of 0, not (setf a 1)
<White_Flame>
unixlisp: setf of a variable modifies the value in the binding
<White_Flame>
it doesn't mutate any value itself
<beach>
White_Flame: The only such "language" I know was an early implementation of Fortran where all functions were called by reference, so that passing a literal to a function created a cell in which the literal was stored, and it could be modified inside the function.
perrierjouet has quit [Quit: WeeChat 3.3]
<White_Flame>
unixlisp: or to be more clear, it replaces which value the binding is holding
tyson2 has quit [Remote host closed the connection]
<beach>
White_Flame: But in this example, it is not the variable binding that is modified. It is the place (CAR B).
<White_Flame>
oh wait, right :)
<White_Flame>
the first half of this discussion was all about the reading of A
<beach>
So rather "SETF of a place replaces the object contained in that place. It does not modify the object previously contained in that place".
<White_Flame>
unixlisp: did my pseudotranslation into C help you understand it at all?
<White_Flame>
beach: yes, much clearer
perrierjouet has joined #commonlisp
semz has quit [Ping timeout: 268 seconds]
<unixlisp>
White_Frame: binding is the best terminology about variable. But I want to know the exact behavior spec specifies. every detail.
<beach>
unixlisp: Is it that you are planning to use Common Lisp, but only if the standard is clear about the semantics?
<beach>
unixlisp: I am asking because this desire of yours to know "every detail" is very unusual.
semz has joined #commonlisp
<unixlisp>
Because I believe Common Lisp is the best programming langauge, the best Lisp dialect at present.
<beach>
So you want to make sure that you are right in your belief? Are you trying to convince other people of this belief as well?
lisp123 has quit [Remote host closed the connection]
<unixlisp>
Surely I will if I have a chance. But there are many things about CL spec I do not exacly know.
<unixlisp>
exactly.
<beach>
Of course. It may take many years to know every detail of the standard. But it would be very unusual to avoid using the language until all those details are understood.
yewscion has joined #commonlisp
<rotateq>
you can also learn much by trying things out :)
<unixlisp>
Acturally I use it frequently. I use Lem rather than Gnu Emacs + Slime.
<unixlisp>
because it is written by Common Lisp. Hemlock, Climacs do not work sadly.
<beach>
We are working on Second Climacs, but progress is slow.
varjag has joined #commonlisp
karlosz has quit [Ping timeout: 260 seconds]
<unixlisp>
I know. Second Climacs uses clim3.
<beach>
No, CLIM3 has been abandoned.
<beach>
McCLIM is now so good that there is no need for it.
<rotateq>
Do we maybe get a great book about McCLIM some day as an additional resource? :) Or for FreeCLIM ...
<beach>
rotateq: The manual is being worked on, but perhaps too slowly for your taste.
<beach>
The issue, as usual, is available people-power.
<unixlisp>
The most important app of McCLIM is the Listener, now it is bare bone, Second Climacs should integrate with it.
<rotateq>
Yes already great resources where much effort flowed in are there, just about me that I'm so slow learning it and understanding the concepts/capabilities. ^^
<beach>
unixlisp: The plan is rather to create components of an IDE of which Second Climacs, the listener, the backtrace inspector, Clouseau, a real debugger, etc. will be some of those components.
<rotateq>
I would also like to help non-trivial in projects like SICL, but I'm with most things still lightyears away.
<rotateq>
s/away/behind
<unixlisp>
Inspector is good now. but editor is not , the most important.
<beach>
rotateq: Sure, some projects require detailed knowledge of specific domains.
<beach>
unixlisp: I am fully aware of that.
<unixlisp>
You can not just use Gnu Emacs, use Common Lisp Emacs, many (if not most) common lisp hackers do not care about it.
<beach>
unixlisp: Most Common Lisp programmers don't seem to care much about the shortcomings of the development tools. The plan for Second Climacs is to make it irresistible for Common Lisp programming by having it analyze the Common Lisp source code with much better precision and in much more detail than any other editor is capable of.
varjag has quit [Ping timeout: 250 seconds]
<unixlisp>
Just like GNU HURD, that is the most important Gnu project. Lem is very easy to extend. Second Climacs is like Gnu Emacs + Slime more than Hemlock?
<beach>
Hard to say. The idea is to use Eclector as an incremental Common Lisp reader to parse the buffer contents. This way, it will be more precise than any other technique that I can think of. We have a paper published on that technique. But the plan is then to go further, and use the first stages of a compiler for further analysis of the buffer contents.
<beach>
This way, we can do things like get the role of each symbol, as opposed to treating all symbols the same, based only on the package.
<hayley>
GNU Hurd is so important that the last release was released five years ago, and the Free Software Foundation pretty much only recommends GNU/Linux-libre systems.
taiju has quit [Ping timeout: 250 seconds]
<rotateq>
Do you have the link to that paper or do I find it via the repo?
<unixlisp>
Short sight GNU. GUILE should be GCL or some CL implementation.
taiju has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
<unixlisp>
beach: How do you think about Mezzano. I think it as a breakthrough.
<beach>
I think it is a great project. But I want to go further, with first-class global environments and such.
<White_Flame>
yep, all of these can certainly build on each other, because of CL as the common basis
<White_Flame>
mezzano on the low level, etc
lisp123 has joined #commonlisp
<hayley>
SICL already uses the stream implementation from Mezzano.
<unixlisp>
I think SICL will fininsh about one or two years. But I worry about the performance of SICL because CLOS compared with SBCL.
<unixlisp>
because of
<White_Flame>
a big thing in sicl is improving clos dispatch performance
<hayley>
beach thought a working image was a year away a year ago, but he's come up with a fair few optimisations which would make CLOS faster.
lisp123 has quit [Ping timeout: 240 seconds]
<White_Flame>
so yeah, I'd expect clos sicl to be faster than clos sbcl, if/until the latter adopts the optimizations of the former
s-liao has quit [Ping timeout: 256 seconds]
<unixlisp>
How about number crunching? SBCL is the best.
<beach>
unixlisp: But have you read the papers on fast generic dispatch and call-site optimization? I am convinced those techniques are going to make a big difference, especially call-site optimization.
<hayley>
SICL doesn't have any optimisations for number crunching yet, since we are more focused on getting a working image first, rather than a fast image. But there is room for improvement.
<unixlisp>
consider bigfloat? only CLISP have it.
<hayley>
Most C compilers are capable of some auto-vectorisation, and can at least handle the obvious cases, such as parallel sums. No one is working on it for SICL, but I've kept the idea at the back of my head.
<rotateq>
unixlisp: you mean like this "Decimal" type in other langs? with 128-bit
<hayley>
Could do. All the arithmetic functions in SICL bottom out at generic functions, so introducing big floats probably isn't too hard.
<hayley>
Well, it's not entirely true that no one is focusing on optimisation; I'm working on global value numbering at the moment, and GVN can handle common subexpression elimination if configured correctly.
<beach>
rotateq: CLISP has a LONG-FLOAT type with a precision that can be parameterized.
<rotateq>
okay much nicer then, like in the package computable-reals, I like it
* hayley
waits at "Satiating all generic functions in E5..." for the fifth time today.
<unixlisp>
complete number tower without bigfloat? Email archive show Fateman even did not want the ratio.
ad-absurdum has joined #commonlisp
<beach>
unixlisp: You never answered my questions regarding whether you had seen those papers.
Guest74 has quit [Quit: Connection closed]
<unixlisp>
beach: sorry, I know these papers exist, but have not read. I should read it. But CLOS is slow by essence, are there magic?
<hayley>
What essence? Does the standard say "a generic function must be at least 5 times as slow as a standard function"?
<loke[m]>
unixlisp:
<beach>
unixlisp: I don't know where you got that idea.
<rotateq>
CLOS choosing four out of power, elegance, efficiency and usefulness.
<unixlisp>
no. thumb rule :)
* hayley
scratches head
<beach>
unixlisp: I think this idea is based on assumptions that just aren't true.
<rotateq>
must be short thumbs then
<beach>
unixlisp: On the other hand, in a typical Common Lisp implementation, parsing keyword arguments can be very expensive, making a call to a function with keyword parameters not very fast. The paper on call-site optimization shows how this cost can be largely eliminated.
Oladon has quit [Quit: Leaving.]
<beach>
It is sad to see how Common Lisp programmers might avoid generic functions because of the technique (usually based on PCL from a few decades ago) for generic dispatch of the Common Lisp implementation they currently use.
<unixlisp>
PCL of SBCL is slow compared with CLOS of LISPWORKS
<beach>
Good to know.
<unixlisp>
not every item about clos of cl-benchmark
Lycurgus has joined #commonlisp
igemnace has joined #commonlisp
<unixlisp>
keyword parameters are absolutely necessary about high lever interface, whether ordinary function or generic function.
<unixlisp>
offset the cost of parsing keyword arguments seems not be good point.
<Lycurgus>
yeah I assume the old was qualitatively current, the changes you mention are consistent with that
<Lycurgus>
also pcl in the currentish sources looks sorta unchanged
<Lycurgus>
2.1.something
<Lycurgus>
(i.e for sbcl)
<Lycurgus>
*assummed
<beach>
unixlisp: My point is that, just as some people might avoid generic functions because the way generic dispatch is implemented in the system they use, some people might avoid keyword arguments for similar reasons. But in fact, the way most systems handle generic dispatch and keyword arguments is not optimal and can be improved upon a lot.
<beach>
unixlisp: But I think I have now said everything I want, so I'll be quiet.
<unixlisp>
better there is a good benchmark
<unixlisp>
Lycurgus: lispworks personal edition 7.1.2 really is impressive about number computation.
<Lycurgus>
yes I know using it now
<Lycurgus>
(looking for heap limit)
<Lycurgus>
looks like 1GB
<unixlisp>
incredible, lispworks is close to sbcl at some number test.
lisp123 has joined #commonlisp
<Lycurgus>
nope, apparently 100MB unless it expands when you reach that
rain3 has joined #commonlisp
lisp123 has quit [Ping timeout: 268 seconds]
aartaka has joined #commonlisp
Algernon69 has joined #commonlisp
poselyqualityles has joined #commonlisp
poselyqualityles has quit [Ping timeout: 240 seconds]
Lycurgus has quit [Quit: Exeunt]
asarch has quit [Quit: Leaving]
pve has joined #commonlisp
scymtym has quit [Ping timeout: 252 seconds]
<unixlisp>
Anyone uses GARNET? It is lispy, playful, fast, though many bugs exits unavoidably.
igemnace has quit [Remote host closed the connection]
<unixlisp>
exist
frgo has joined #commonlisp
lisp123 has joined #commonlisp
ahc has quit [Quit: Client closed]
<unixlisp>
Garnet stands for Generating an Amalgam of Real-time, Novel Editors and Toolkits. Really a great lisp GUI toolkit.
<jackdaniel>
unixlisp: I think that Earl Ducaine took the maintainership of then-bitrotten codebase
<jackdaniel>
but I haven't heard much about it later
<jackdaniel>
I see, good for you that the other version did not have this problem, that seems like an annoying issue
s-liao has quit [Ping timeout: 256 seconds]
gaqwas has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
<unixlisp>
lisp123: McCLIM is surely better than Garnet, thanks for jackdaniel and other hackers.
<unixlisp>
But Garnet complements McCLIM, far better than LTK.
<unixlisp>
It does not use CLOS, but use hashtable pervasively :)
makomo has joined #commonlisp
<jackdaniel>
is there something wrong with clos?
<beach>
jackdaniel: Oh, you missed an enlightening discussion about that.
<jackdaniel>
ah, I see /me skims the backlog
rgherdt has joined #commonlisp
<jackdaniel>
whether generic functions are a bottleneck worth sidestepping by using something pervasively is something that would need to be proven - i.e that gf dispatch dominates the effective methods bodies (even if we assume the technique currently used in ecl which is indeed slow)
<unixlisp>
different OO, seems be prototype.
<hayley>
Yes, the trick is to prototype with prototype OO, and then use classes when you need a classy release.
<jackdaniel>
also if we talk about clos it is hard to not talk about mop these days - making dumbed-down non-standard generic function metaclass that dispatches very fast is not hard
<unixlisp>
"The main reason is that Garnet uses a prototype-instance model, rather than the conventional class-instance model supported by CLOS. We have found the prototype model to be more effective for user interface prototyping and construction. A second reason is performance: it appears that KR is more efficient than CLOS for most standard operations."
<hayley>
beach: No, I didn't actually get banned, I was just telegraphing my terrible joke about "prototype object oriented programming" and the act of prototyping.
<flip214>
unixlisp: I understand prototype-instance models so that you can't use mixins, right?
<beach>
hayley: Oh, OK.
<hayley>
flip214: You can have "mixins" in Self, as it allows multiple inheritance by multiple parent slots.
<flip214>
ie. you can't simply add a parent class to extend behaviour
<flip214>
oh, multiple parents, okay.
<flip214>
and there are method combinations like PROGN, +, APPEND, etc. as well?
<hayley>
There's no method combinations in Self (or Newspeak, which has mixins as a language feature); they're still doing Smalltalk-ish message passing. Or is that question about Garnet?
<flip214>
I asked about Garnet, sorry for being unclear.
<hayley>
Okay.
<flip214>
reading up on it now.
s-liao has joined #commonlisp
<jackdaniel>
if you find garnet pleasent to use then that's perfectly fine; I'll only point out that some points made in 1996 may not be valid today; that said it would be probably hard to change an underlying abstraction for it
<jackdaniel>
the fact that they've decided to rewrite it in c++ shows a certain mindset
<beach>
WHAT???
<jackdaniel>
authors of garnet decided that they will rewrite it in C and C++
<Nilby>
The probably wanted people to use the software. I'm a fan of Garnet, but it was slow AF in 1990's.
<jackdaniel>
beach: you may read in the linked faq points [10], [11] and [12], that will make a nice source material for an addendum to your training course about programming languages
<jackdaniel>
and [9] of course
<flip214>
12 is enlightning
<beach>
jackdaniel: Thanks. Let me have a look.
<jackdaniel>
the point [9] is a compelling argument in favor of MOP (I gather that cmucl didn't have it back then)
<beach>
I don't see any such FAQ points on that page.
<beach>
That does look like good material for my industry talks, yes. Thanks again.
<jackdaniel>
sure
<Nilby>
It would be cool if Lisp UIs or even more of any UI would use Brad Meyers (& others), research. I especially like semantic zooming, lenses, and demonstrational scripting.
<Nilby>
Garent had gestures before we had devices that could input them well.
Algernon69 has quit [Ping timeout: 268 seconds]
lisp123 has joined #commonlisp
<unixlisp>
flip214: garnet prototype is not so advanced like CLOS.
<Nilby>
With speed less of an issue now, it's not hard to add a prototype mixin to CLOS objects and have both.
<unixlisp>
"Why the change to C++?" best points explain CL was not popular at 90's.
scymtym has joined #commonlisp
cosimone has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
Lord_of_Life has quit [Ping timeout: 260 seconds]
VincentVega has joined #commonlisp
Lord_of_Life_ is now known as Lord_of_Life
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
s-liao has joined #commonlisp
waleee has quit [Ping timeout: 252 seconds]
lisp123 has quit [Remote host closed the connection]
<hayley>
You don't just have a prototype mixin though; there are no classes in prototype OO. Just slots for state and methods, and parent slots for inheritance.
karlosz has joined #commonlisp
<jackdaniel>
reading carefully into the faq one could find a certain kind of dishonesty there (if read unfavourably)
<jackdaniel>
they claim that they switch to c++ for some reaons (including technical ones) in [12], but earlier they admit that all people who knew garnet left
<jackdaniel>
so which is it - were that the garnet creators who decided to switch, or a new (possibly less competent) team? of course it could be that garnet devs left because of the forced switch
<jackdaniel>
or some other reason
s-liao has quit [Ping timeout: 256 seconds]
<Nilby>
C/C++ UIs had hideous APIs at the time, but as cool as Garent was, it sadly couldn't keep up with my mouse or typing on a decent machine. The rewrite in C++ lost features, but at least it could type and click. Lisp was still popular for real projects in Pittsburgh (CMU & U.Penn) until web browsers ate everything. As is typical in academia, the students moved on, faculty who definitely were Lispers, stayed, but would have to re-cultivate
<Nilby>
expertise.
varjag has joined #commonlisp
<Nilby>
It's very hard to resist both practical and political pressure.
<unixlisp>
Python compiler have been developed more than 30 years, though not are so intensively. I guess the performance of SBCL can rise 50% within next ten years
* jackdaniel
only points out the rationale inconsistency, not that the rationale doesn't make sense
<jackdaniel>
for example gimp was originally started in cl, but they've decided that it is atraciously slow (however I think that they've used lists instead of arrays)
<unixlisp>
Performance is really important about Common Lisp.
<unixlisp>
That is why we respect SBCL.
<hayley>
Nilby: Be realistic, and demand the impossible.
<jackdaniel>
it is not that sbcl is the only performant implementation (or that it outperforms each implementation in every metric)
Jing has quit [Remote host closed the connection]
Jing has joined #commonlisp
<Nilby>
hayley: I do :) I keep working on the impossible.
<semz>
Maybe less mindboggling if you keep in mind they were students at the time, but still
Jing has joined #commonlisp
<jackdaniel>
heh :)
<Nilby>
Also keep in mind I can now run Garent on my slow phone, and previously it required a $30k workstation thingy.
s-liao has joined #commonlisp
cosimone has quit [Quit: ERC (IRC client for Emacs 27.1)]
<jackdaniel>
either way on the benchmark I've linked you could see, that even ecl, abcl and clisp outshine others /in places/ :)
cosimone has joined #commonlisp
<jackdaniel>
(or did in 2016)
<unixlisp>
jackdaniel: most items at cl-bench, sbcl stand up.
<jackdaniel>
I did not say that it doesn't, but your previous statement seemed to imply that sbcl is the only implementation that is performant
* pl
puts on evil hat
* jackdaniel
gets back to work
<pl>
That's because in CL, out performance floor is "still faster than CPython" ;-)
<unixlisp>
As said, lispworks personal edition 7.1.2 really is impressive about number computation.
cage has joined #commonlisp
<unixlisp>
Nilby: Tha Garnet was rewrited to Amulet was silly decision. You lost interactivity.
attila_lendvai has joined #commonlisp
<unixlisp>
That Garnet. Python Compiler can improve performance continuously.
s-liao has quit [Quit: Client closed]
waleee has joined #commonlisp
<Nilby>
unixlisp: I have a strong fondness for Garnet. It was ahead of it's time. You could try it on 30 year old computer to see. But now we can use it very quickly if we want. :)
<unixlisp>
I like Garnet, it is lightweight :)
<jackdaniel>
I have mixed feelings about grokking someone else code - on one hand it feels like reading a book where you feel deep connection with the author (one sided), on the other hand it is like letting someone else into your head
<Nilby>
jackdaniel: Yes, especially code that you get that "can't unsee" feeling
waleee has quit [Ping timeout: 260 seconds]
<phadthai>
it can be educational too
<jackdaniel>
as I said, on one hand it is kind of exciting, on the other it is kind of discomforting
lisp123 has joined #commonlisp
<unixlisp>
Nilby: Garnet is playful, but has many bugs now.
<unixlisp>
It is still far ahead of GTK, QT.
lisp123 has quit [Ping timeout: 252 seconds]
srji has quit [Quit: leaving]
VincentV` has joined #commonlisp
VincentVega has quit [Ping timeout: 256 seconds]
<VincentV`>
Nilby: Does garnet have semantic zooming you mentioned?
VincentV` is now known as VincentVega
<Nilby>
VincentV`: I don't think explicitly. But it can do arbitrary transformation of UI elements and widgets.
waleee has joined #commonlisp
<VincentVega>
Nilby: Well, that's already not bad, especially if you can customize it per "widget" or what has it. Any other cool features about it, perhaps? What makes you fond of it?
<unixlisp>
Garnet give me a hint: class just like alist.
<unixlisp>
live gui object.
<VincentVega>
unixlisp: I gathered from the discussion it has it's own class system. Any class can be represented as a data structure you can hack? Interesting.
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<unixlisp>
kr knowlege representation
<VincentVega>
unixlisp: OK, I will read up on it.
<VincentVega>
thanks
<unixlisp>
enjoy it.
<unixlisp>
in kr-macros.lisp (defstruct (schema (:predicate is-schema) (:print-function print-the-schema) name bins)
<unixlisp>
All Garnet objects are implemented as KR schemata.
<VincentVega>
unixlisp: cool, I will search for that than
<VincentVega>
unixlisp: But a practical example would be nice, or maybe there's some resource you could point me to? KR seems like a pretty general concept. Or is it something that has to be explored simply by tinkering with garnet?
<unixlisp>
look at garnet manual. chap 3: garnet tutorial.
<Nilby>
VincentVega: It had a constraint system for making size adaptive UIs, it had a declarative seeming UI contruction style, but that could mix with functional code, in a way which seemed to work well with interface builders. It unfortunately didn't have ‘presentation’ classes like CLIM, but it was more suited to a standard non-Emacs style UI. It's quite a bit simpler than CLIM, but still very flexible in look and function, allowing total
<Nilby>
customization. It had themes, and tried to look like the platorm UI.
<rotateq>
i should rewatch the last about Chaitin's constant and many other of the smaller ones
<rotateq>
A year ago he made a 40min one with "Teaching computers how to differentiate or: Why Lisp?"
<Lycurgus>
it's clear hochdeutsch, thankfully
<Lycurgus>
but no face
lisp123 has joined #commonlisp
<rotateq>
yes he has a clear style of speaking and writing. how much time it must have taken creating all those high quality animations/pictures/presentations for the hundreds of videos, but sure tools like LaTeX-beamer have benefit in the long run
<rotateq>
no no face :)
<Lycurgus>
ah, hamburg, that explains
lisp123 has quit [Ping timeout: 268 seconds]
<Lycurgus>
the topic is less interesting than seeing or hearing the person
<rotateq>
haha yes, but not really northern german accent ^^
<rotateq>
yes this year a not too expert-like topic
ad-absurdum has joined #commonlisp
Jing has quit [Read error: Connection reset by peer]
taiju has quit [Ping timeout: 268 seconds]
taiju has joined #commonlisp
* Lycurgus
*weitz
Jing has joined #commonlisp
Lycurgus has quit [Quit: Exeunt]
attila_lendvai has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
perrierjouet has quit [Ping timeout: 260 seconds]
attila_lendvai has quit [Ping timeout: 252 seconds]
perrierjouet has joined #commonlisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
amb007 has quit [Ping timeout: 250 seconds]
amb007 has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
dra has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
igemnace has quit [Ping timeout: 252 seconds]
gaqwas has joined #commonlisp
jeosol has joined #commonlisp
karlosz has quit [Ping timeout: 252 seconds]
voltron has joined #commonlisp
floguard has joined #commonlisp
<floguard>
Would you recommend slime or sly for a beginner?
voltron has quit [Remote host closed the connection]
<varjag>
more people likely know how to help you with slime in case you have an issue
<floguard>
that is probably more important than most technical differences
yewscion has quit [Quit: Connection closed]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 250 seconds]
Guest74 has joined #commonlisp
floguard has quit [Quit: Client closed]
srhm has joined #commonlisp
waleee has quit [Ping timeout: 250 seconds]
waleee has joined #commonlisp
scymtym has quit [Remote host closed the connection]
Oladon has joined #commonlisp
ad-absurdum has quit [Quit: Leaving]
b1_xt has joined #commonlisp
b1_xt has quit [Remote host closed the connection]
sjl has joined #commonlisp
waleee has quit [Ping timeout: 268 seconds]
Guest74 has quit [Quit: Connection closed]
treflip has quit [Quit: good night ✨]
hobo has joined #commonlisp
peterhil_ has quit [Remote host closed the connection]
peterhil_ has joined #commonlisp
peterhil_ has quit [Ping timeout: 260 seconds]
peterhil has joined #commonlisp
peterhil has quit [Ping timeout: 260 seconds]
tyson2 has joined #commonlisp
peterhil has joined #commonlisp
Algernon69 has quit [Ping timeout: 268 seconds]
cage has quit [Ping timeout: 260 seconds]
Inline has quit [Remote host closed the connection]
scymtym has joined #commonlisp
tyson2 has quit [Ping timeout: 268 seconds]
lisp123 has joined #commonlisp
Inline has joined #commonlisp
voltron has joined #commonlisp
lisp123 has quit [Ping timeout: 268 seconds]
Inline has quit [Quit: Leaving]
robin has joined #commonlisp
Inline has joined #commonlisp
cage has joined #commonlisp
voltron has quit [Remote host closed the connection]
voltron has joined #commonlisp
voltron has quit [Remote host closed the connection]
voltron has joined #commonlisp
cjb has joined #commonlisp
voltron has quit [Remote host closed the connection]
rain3 has quit [Ping timeout: 252 seconds]
Oladon has quit [Quit: Leaving.]
aartaka has quit [Ping timeout: 268 seconds]
elderK has joined #commonlisp
<phoe>
the clnet mailman is still not working correctly, so I'll make a small reminder here: Online Lisp Meeting #12 is announced, see https://www.reddit.com/r/lisp/comments/reahby/ for details
<rotateq>
thank you again
<fiddlerwoaroof>
Has anyone else run into differences between cl+ssl in emacs vs. command-line on mac?
<phoe>
seems like some sort of dynalib loading issue
<phoe>
could you post the condition report and/or slots?
<fiddlerwoaroof>
the libs in CFFI::*FOREIGN-LIBRARIES* are identical
<phoe>
I would assume so, but this is likely some stuff on OS level
<phoe>
macos is infamous for such breakages
<fiddlerwoaroof>
If I had to guess, I think there's probably some access rules for the system cert store that is causing problems
<fiddlerwoaroof>
Anyways, I've attached the condition info to the issue
<phoe>
"Certificate Verification: Error (20): Unable to Get Local User Certificate."
<phoe>
woah! you were right
cage has quit [Quit: rcirc on GNU Emacs 27.1]
<fiddlerwoaroof>
I'm going to try upgrading openssl, but I doubt that's the problem
tyson2 has quit [Ping timeout: 252 seconds]
<fiddlerwoaroof>
Maybe I'll try using a different implementation first
<phoe>
what is your openssl version?
<fiddlerwoaroof>
1.1.1k
<fiddlerwoaroof>
but just upgraded
<fiddlerwoaroof>
The reason I don't think this is the problem is that it works from the terminal
<fiddlerwoaroof>
Hmm, it works in ECL from slime
<fiddlerwoaroof>
I now need to double-check that sbcl is still broken, since I upgraded
<phoe>
maybe for whatever reason the openssl binary that is loaded differs between these two sessions
<phoe>
that's the only explanation that comes to my mind, honestly
<phoe>
try to pull a fresh cl-plus-ssl maybe, like, from git
<phoe>
there were some macos-specific patches to it recently
shka has quit [Ping timeout: 252 seconds]
<fiddlerwoaroof>
Good idea, I haven't updated my quicklisp dists recently
<phoe>
it's not about the quicklisp dist
<phoe>
these were changes that were pushed like days ago, they likely are not on quicklisp
<phoe>
...yet
<fiddlerwoaroof>
Yeah, it's just I'm not necessarily with the most recent released version of CL+SSL
<fiddlerwoaroof>
Using the git version doesn't help, though
<phoe>
hmmmm
<phoe>
no idea now
<fiddlerwoaroof>
Well, I have a workaround, thanks!
aartaka has joined #commonlisp
backquotehelp has joined #commonlisp
<backquotehelp>
Why does ``(+ ,,(+ 1 4)) evaluate to `(+ ,5)?
<backquotehelp>
I'm mostly confused about the stray comma behind the 5
<backquotehelp>
(And if I was writing a macro that used double backquote, how would I get rid of the stray comma? The suggestion of ,', I found elsewhere doesn't appear to work in sbcl, at least)
<White_Flame>
`(... ,(+ 1 4)) => (... 5)
<White_Flame>
so, add in the 2nd layer of ` and , and you get what you got