<moon-child>
perhaps it is assuming that CONS might be nil? Obviously that can never happen, but
random-nick has quit [Ping timeout: 256 seconds]
thomp has joined #commonlisp
peterhil has joined #commonlisp
<Bike>
yeah i mean what it says is "This is not a CONS: NIL" and points out the loop.
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
gamaliel has joined #commonlisp
thomp has quit [Ping timeout: 250 seconds]
<lagash>
What do folks here use for a linter/code formatter for CL, particularly as a pre-commit hook?
<lagash>
So far I've tried trivial-formatter, but I'm not impressed really
<moon-child>
pre-commit hooked autoformat is dumb. Formatting can not always be applied automatically
Lord_Nightmare has quit [Ping timeout: 256 seconds]
<mfiano>
That is a bad idea.
<moon-child>
hence it should be an editor command, to be used at the editor's discretion
karlosz has joined #commonlisp
<mfiano>
Use SLIME or Sly. Formatting code correctly depends on the state of the Lisp image.
<moon-child>
mfiano: it also depends on the smarts of the formatter. Slime still can not indent moderately complex loops
<mfiano>
It also has a concept of "lossage"
<lagash>
mfiano: I have been using Sly, although come to think of it, not every time I've formatted my CL code, was Sly running.. that might be the issue?
<mfiano>
Stemming from its piggy-backing off of emacs-lisp, which does not have the concept of packages.
<mfiano>
Sly can indent moderately complex LOOPs just fine though, so I'm not sure about SLIME in this regard.
<moon-child>
sly, slime, same thing
<moon-child>
I had the same problem with both
pieguy128 has quit [Ping timeout: 256 seconds]
<EdLangley[m]>
Prettier makes a huge difference in JavaScript projects
<mfiano>
I have written hundreds of line loops before, and indentation has never been an issue.
<EdLangley[m]>
Because, even if the formatting isn’t always great, it reduces diffs if you apply it consistently
<lagash>
It's just that Emacs and/or Sly can't seem to make up its mind when I, say, format an entire file..
<lagash>
EdLangley[m]: yes! that's what's bugging me
<EdLangley[m]>
I’ve always just used aggressive-indent-mode for CL
<lagash>
Hmmmm... I wonder if I have that on..
<EdLangley[m]>
And, if slime is running, it works pretty wel
<EdLangley[m]>
s/wel/well/
<EdLangley[m]>
I’ve never had an issue with the indentation of LOOP either
<mfiano>
I also use aggressive-indent-mode, but should point out that the code and its dependencies should also be loaded; it isn't enough to just have SLIME/SLY running due to macro definitions.
<beach>
unixlisp: Why do you think that? I.e., that redefining a function is always undefined. I mean, is that an opinion of yours? Or something you concluded from reading the standard?
<unixlisp>
beach: I should carefully read 3.2.2.3, redefining function is not always undefined.
opc0de is now known as opcode
<beach>
That section is mostly unrelated to the issue.
<beach>
unixlisp: So let me ask you again. When you said "I think redefining function is always undefined", was that an opinion of yours, or something you concluded form reading the standards document?
<beach>
unixlisp: "think" in English can mean either, which is why I am asking.
karlosz has quit [Quit: karlosz]
<unixlisp>
Oh, I said the reading is not complete, so the conclusion is wrong. (that is my opinion from read spec.)
<unixlisp>
In general, I always wonder redefining is a defined behavior or not. uch as defparameter, etc.
<unixlisp>
such as
<beach>
It would be very strange for a language to include operators that always have undefined consequences.
<Bike>
the definition of defparameter literally describes the redefinition behavior
thomp has joined #commonlisp
s-liao has joined #commonlisp
<EdLangley[m]>
As a rule, Common Lisp is defined for a workflow that involves building up a program incrementally.
<EdLangley[m]>
There are exceptions (defstruct, defconstant), but it would be strange for most of the fundamental operations not to have well-defined redefinition semantics.
<unixlisp>
oh, redefining defstruct is really undefined.
<beach>
unixlisp: So here is a suggestion. The next time you "think" something like that, maybe phrase it as a question instead, like "Is redefining a function always undefined behavior"?
<unixlisp>
beach: ok.
thomp has quit [Ping timeout: 250 seconds]
kingofcsu has quit [Quit: kingofcsu]
lisp123 has quit [Quit: Leaving...]
pillton has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Client Quit]
occ has joined #commonlisp
<masinter>
What else would (setf (symbol-function 'foo) newdef) do besides redefine foo?
<beach>
masinter: It could be defined behavior only if the function is currently undefined. Also, consider SYMBOL-FUNCTION obsolete in favor of FDEFINITION.
thomp has joined #commonlisp
<beach>
masinter: DEFSTRUCT is pretty much like that. The first time you use it, it is defined behavior.
gamaliel has quit [Ping timeout: 256 seconds]
domovod has joined #commonlisp
<beach>
But the behavior of DEFSTRUCT is very strange for a dynamic language (which by definition is a language with semantics defined as a sequence of incremental modifications to the environment).
occ has quit [Remote host closed the connection]
<beach>
And that's why I advocate using standard classes instead of structure classes.
<EdLangley[m]>
Does uninterning the symbol first make a DEFSTRUCT with the same name defined behavior?
<unixlisp>
there is a performance considering about defstruct.
semz_ has joined #commonlisp
semz_ has quit [Changing host]
semz_ has joined #commonlisp
<beach>
EdLangley[m]: Good question.
semz has quit [Ping timeout: 250 seconds]
jeosol has joined #commonlisp
<beach>
unixlisp: Structure classes are defined so that the implementation can represent their instances in a very efficient way if it chooses to do so. Standard classes require instances to have some indirection that allows for instances to be altered when a class is modified.
<mfiano>
Note that if you are familiar with the MOP, you can make standard classes just as efficient as structure classes. IIRC, phoe is going to talk about my technique for doing so in the new revision of Common Lisp Recipes.
aartaka has joined #commonlisp
<mfiano>
One nice thing about Common Lisp is its extensibility. Just as macros extend syntax to form new language constructs by the user, the MOP extends CLOS to alter semantics of CLOS OOP.
<mfiano>
I really wouldn't recommend trying to make standard classes like structure classes though. They become less and less useful for iterative programming the more you do so, as beach mentioned.
<mfiano>
And a sufficiently smart compiler should be able to dispatch fast to an accessor/other method.
Bike has quit [Quit: Connection closed]
<beach>
That is partly why in SICL, instances of structure classes have the same structure as instances of standard classes.
<mfiano>
I recently started programming in Lisp again (after like 6 months!), and after using standard classes, I switched to structure classes, because a concise memory footprint and tagging of numeric fields was needed. I now realize that was foolish, and I should instead tag fixnums and unpack the individual bits I need.
Guest8330 has joined #commonlisp
<mfiano>
These structure objects with 2-6 numerical fields were to be stored in very large arrays. My plan now is to just bitwise or/shift the values together into a single fixnum, with a tag header to distinguish the different "classes"
<EdLangley[m]>
It’d be interesting if there was a way to “finalize” a class for performance
<EdLangley[m]>
Ideally in a reversible way where use-sites are tracked for recompilation.
<beach>
EdLangley[m]: You may be interested in heisig's work on fast generic functions and sealing.
<mfiano>
That is referred to as sealing a class
<EdLangley[m]>
Yeah, that’s sort of what I was thinking about.
<mfiano>
It is used in other languages to prevent monkey patching, but in CL, heisig's work, uses it for performance.
<EdLangley[m]>
Yeah, performance is where this makes sense to me.
<mfiano>
I can't stand behind semantics-altering generic function libraries anymore though. I think it too, goes too much against the interactive development style I like, and leads to very surprising behavior.
<EdLangley[m]>
My thought would be “sealing” would only happen in non-development situations.
<EdLangley[m]>
E.g. when I’m deploying a server, I’m often going to replace it by spinning up a second server in parallel and cutting over
<EdLangley[m]>
In this situation, sealing makes sense because you’re never going to encounter a redefinition in production.
<mfiano>
I mean it's not impossible.
<Guest8330>
Hey, is there an errata for the ANSI Common Lisp Spec?
<unixlisp>
It is good of "fast generic function", but it has a cost: "Once a fast generic function has been sealed, it is not possible to add, remove, or redefine methods within the sealed domain"
<mfiano>
One thing you could do is write a macro wrapper over defclass that expands to cl:defclass in development, and a custom metaclass that defines inlined regular function accessors that use c2mop:standard-instance-access in production.
<EdLangley[m]>
Yeah.
<mfiano>
Well that made more sense in my head, but maybe you get the idea
<mfiano>
Also fast generic functions has issues optimizing structure class specializers in my experience, so I wouldn't start there.
<mfiano>
f-g-f that is
<beach>
Guest8330: I think there is on on cliki.
<unixlisp>
in clx, *def-clx-class-use-defclass* default is nil. xlib::buffer is a structure.
<Guest8330>
nevermind I found it :)
<Guest8330>
Oh thanks beach
<beach>
Sure.
<mfiano>
About my idea above to use tagged fixnums though. I'm not sure if it is a good idea yet, as I may need methods dispatching on the type that is encoded in the MSB tag bits
<mfiano>
Which, would need a lot of MOP support for little gain. I'm not sure if a CASE jump table would be efficient enough for the number of types.
<EdLangley[m]>
Doesn’t beach’s generic functions paper use some sort of trick with numbers to make dispatch efficient? It’s been a while since I read it.
<mfiano>
My other thought is usually these arrays will be homogeneous, and if I can constrain that to _always_ be the case, the type can be encoded in the class wrapping the array
<beach>
EdLangley[m]: The essence of the paper is that register operations can be used where traditionally memory operations were.
<beach>
EdLangley[m]: It doesn't do anything about the indirection.
<mfiano>
I'm just rubber ducking here; prob can ignore me. I have been thinking about this all day while I do system administration.
<beach>
EdLangley[m]: There is still a lot of work to be done in the domain of language implementation, where in the past it was assumed that memory operations were roughly as fast as register operations, whereas that is no longer the case.
<beach>
C++ vtables would be interesting to examine for instance.
<mfiano>
So I can't pack any type tag into my integers anyway, so that idea is out. It turns out, the largest integer requires 64 bits of data without the type tag, and I surely don't want most implementations to upgrade the simple-array element type to T.
<mfiano>
It looks like my only option is indirection.
akoana has quit [Quit: leaving]
shka has quit [Ping timeout: 240 seconds]
domovod has quit [Quit: WeeChat 3.4]
shka has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
<masinter>
changing a defstruct both changes some defuns / compiler macros and the type name of existing data
jealousmonk has quit [Quit: ERC (IRC client for Emacs 27.1)]
<beach>
But the point is that existing instances are now obsolete, and attempting to access some slots in such an obsolete instance may give some arbitrary result.
<EdLangley[m]>
Has much thought been put into using the GC to optimize memory access?
<EdLangley[m]>
If you have a moving GC, in theory you could track the probability that two objects are accessed in order and then arrange them so they can be read more efficiently
<beach>
The GC literature discusses locality.
<EdLangley[m]>
In relational databases, for example, if you have an index on a column, you can tell the DB to use that index to sort the data on disk.
<unixlisp>
If GC is written completely by lisp, it is easer to custum.
<lisp123win>
I wanted to ask, if I have a collection of objects that I want to add to multiple hash tables (each hash table basically being an index of sorts)
<lisp123win>
I am right in my assumption the overall memory cost is not too big because all the hash tables will share the same objects (to the extent I am placing the same object in multiple hash tables and not re-creating them)
<lisp123win>
?
<jackdaniel>
yes
<lisp123win>
jackdaniel: Thanks!
<jackdaniel>
np
Doraemon has joined #commonlisp
NeoCron has quit [Ping timeout: 250 seconds]
s-liao has quit [Ping timeout: 256 seconds]
gamaliel has quit [Quit: Client closed]
Jing has joined #commonlisp
bollu has quit [Ping timeout: 250 seconds]
bollu has joined #commonlisp
thomp has quit [Quit: Konversation terminated!]
bollu has quit [Client Quit]
bollu has joined #commonlisp
dre has quit [Ping timeout: 250 seconds]
s-liao has joined #commonlisp
dec0d3r has quit [Quit: Leaving]
gaqwas has joined #commonlisp
Cymew has joined #commonlisp
unixlisp has left #commonlisp [#commonlisp]
thomaslewis has joined #commonlisp
Algernon69 has joined #commonlisp
Algernon91 has joined #commonlisp
Algernon666 has joined #commonlisp
Algernon91 has quit [Read error: No route to host]
thomaslewis has left #commonlisp [#commonlisp]
osp has joined #commonlisp
Algernon69 has quit [Ping timeout: 240 seconds]
mon_aaraj has quit [Ping timeout: 240 seconds]
pillton has quit [Quit: ERC (IRC client for Emacs 27.2)]
s-liao has quit [Quit: Client closed]
azimut_ has joined #commonlisp
<White_Flame>
Bike: it can't prove that the LOOP will always find a match, and so could return NIL
<White_Flame>
you'd have to declare that dat is a recursing list and thus would never terminate (if that's the intent)
<White_Flame>
which isn't a possible declaration
mon_aaraj has joined #commonlisp
<empwilli>
EdLangley[m]: I'm toying with this idea for compiled languages: Instead of having the class description in, let's say, c++ dictate how data is placed in memory, let is shuffle around (or do even fancier stuff, e.g. the things that databases do, in games terminology, this would be entity component systems)
<empwilli>
to optimize how they are accessed
<White_Flame>
(oh, Bike's gone :-P)
azimut has quit [Ping timeout: 276 seconds]
<White_Flame>
empwilli: I've had plenty of ideas similar to that as well. My notion would be that data tracks where it was allocated from, and usage feeds back into how it should be initially allocated/generated
rgherdt has joined #commonlisp
<EdLangley[m]>
So, what got me down this road was thinking about how, if the MMU were designed for the languages people like to program in (ones with lots of pointer chasing), it could use access patterns to transparently move data around in physical memory for better locality (sort of like how SSDs move data around on disk for wear leveling)
shka has quit [Quit: Konversation terminated!]
<EdLangley[m]>
Then, I realized that the GC already walks all the objects periodically, so if you had some sort of statistics about access patterns, a moving GC could take those into account when it compacts the heap
<empwilli>
The term that you're looking for is "page migration"
<empwilli>
I'm not too deep in this literature but I think it has been shown to be too expensive to bring a benefit
<EdLangley[m]>
The simple case here would be, if you have a list that's iterated over frequently, to move all the cells together
<empwilli>
the other issue is, that, generally speaking, the granularity of 4k pages is too big
biog has joined #commonlisp
<EdLangley[m]>
It might be too expensive to do all the time, but maybe there's some sort of profile-guided optimization you could do?
<EdLangley[m]>
e.g. run a bit of code with a profiler and store statistics about the actual observed access patterns
<EdLangley[m]>
And then pin that, sort of like pinning a query plan.
<EdLangley[m]>
(talking about a language runtime now)
<empwilli>
I'd have to think about this for a moment but work >.>
shka has joined #commonlisp
<EdLangley[m]>
So, a naive way to do this would be to attach a counter to every member of a class
<EdLangley[m]>
And increment it every time you follow the pointer from the instance -> the actual member
<EdLangley[m]>
Then, the gc picks a threshold and moves members close to the instance in memory, if the counter is above the threshold
<EdLangley[m]>
This probably has a bunch of disadvantages (turning reads into writes, etc.) but it'd improve the locality of instances and commonly used members.
<empwilli>
So what I can point you to is literature on NUMA systems where this is frequently a problem (at least from the perspective where to allocate memory to/from)
mgl has joined #commonlisp
lewisje has joined #commonlisp
peterhil has quit [Read error: Connection reset by peer]
peterhil has joined #commonlisp
MajorBiscuit has joined #commonlisp
peterhil has quit [Read error: Connection reset by peer]
peterhil has joined #commonlisp
karlosz has joined #commonlisp
treflip has joined #commonlisp
attila_lendvai has joined #commonlisp
pve has joined #commonlisp
Algernon666 has quit [Read error: Connection reset by peer]
Algernon666 has joined #commonlisp
dre has joined #commonlisp
xaltsc has quit [Remote host closed the connection]
unixlisp has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
asarch has joined #commonlisp
cosimone has joined #commonlisp
karlosz has quit [Ping timeout: 256 seconds]
mon_aaraj has quit [Ping timeout: 250 seconds]
treflip has quit [Remote host closed the connection]
s-liao has joined #commonlisp
<unixlisp>
Alfr: "3.2.2.3 also says that, apart form the listed exceptions the new definition takes precedence" That is "about minimize the observable differences between compiled and interpreted programs".
<Alfr>
unixlisp, I don't understand what you want to express with ^.
<unixlisp>
new definition is run-time, old is compile-time.
<Alfr>
I still don't get what you're trying to tell.
<unixlisp>
it is not about redefining a function at run-time.
kingofcsu has joined #commonlisp
asarch has quit [Quit: Leaving]
<beach>
Alfr: Frequently unixlisp seems to make statements without any context, and sometimes without any stated purpose. I think you need to get used to it.
<Alfr>
beach, I think the context is that question form earlier this morning.
<Alfr>
unixlisp, but what are you trying to say with those quotes? Or what's the problem/question?
<beach>
I think unixlisp now realizes that the page that was cited before as being about redefining functions, in fact is not. But I already said that.
<Alfr>
beach, I cited that, and I still think it's relevant. As it defines what conforming programs can expect, thus conforming implementations must arrange for.
<unixlisp>
beach: you said that. but I did not understand it at that time.
<empwilli>
EdLangley[m]: hm, given that GCs really are notorious sources for performance bottlenecs (at least my understanding, I mostly don't do GC programming, so please correct me): Moving around members in memory would really add a large amount of overheads
<Alfr>
beach, (okay for the other case where it simply happens during runtime, DEFUN's documentation already specifies the behavior as replacing.)
<beach>
empwilli: malloc()/free() are more expensive than a tracing GC in general.
<beach>
empwilli: So if you are avoiding GC for performance reasons, you may be doing the wrong thing.
<empwilli>
no worries there :) I'm avoiding it just for the convenience of the languages I feel comfortable in
<empwilli>
(and that I have to work in, for that matter)
<beach>
So not Common Lisp?
<empwilli>
I'm currently working on adding common lisp to my repertoire, but I'm far from fluent in it
<beach>
I see.
taiju has quit [Remote host closed the connection]
kingofcsu has quit [Ping timeout: 240 seconds]
<beach>
empwilli: It is too bad, though, that people seem to think that automatic memory management is a "notorious source for performance bottlenecks". They are then doomed to program in a way that makes it extremely hard to get both performance and modularity in their code.
<beach>
I wonder where such rumors come from.
<beach>
Maybe from the garbage collectors we had half a century ago.
<empwilli>
this sounds as if there were design patterns to program in favour of the GC. Is this the case? Can you point me to some resources?
<beach>
I had no design pattern in mind. I am just making a general observation that "liveness is a global property" [from Paul Wilson], so not a "modular" property. If your program is modular, you either need to copy all your objects, or use reference counters if you don't have automatic memory management.
<seragold[m]>
I think it was David Ungar back in early nights who showed that no sort of reference counting and its variants overall performed as well as state of art GC then. So why would you want such in your way of whatever the most efficient and elegant patterns are it is possible to come up with in a language that gives you all the power?
<beach>
Right, and reference counters are very very expensive.
biog has quit [Ping timeout: 240 seconds]
<empwilli>
Ah, then I misunderstood you :)
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life has joined #commonlisp
tfb has joined #commonlisp
skeemer has quit [Quit: Leaving]
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
<unixlisp>
beach: early about (setf (symbol-function 'foo) newdef), you said "It could be defined behavior only if the function is currently undefined". but in clhs about symbol-function entry, "setf may be used with symbol-function to replace a global function definition"
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
asarch has joined #commonlisp
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
ldb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
jeosol has quit [Quit: Client closed]
tfb has quit [Ping timeout: 240 seconds]
Algernon666 has quit [Ping timeout: 240 seconds]
ldb has quit [Quit: ERC (IRC client for Emacs 27.2)]
mgl has quit [Quit: Client closed]
<beach>
unixlisp: Yes, notice the word "could" in order to explain to masinter that the existence of that operator doesn't necessarily mean that the behavior is always defined. But as it turn out, it is.
<loke[m]>
beach: to answer your question, I think the answer is even simpler.
<loke[m]>
beach: Take your average C programmer: malloc and free "feels" free in terms of performance impact. So when someone suggests that a GC will run automatically and search for all the memory to be released, that feels "obviously" slower, since now it has to do stuff when before it didn't have to.
<unixlisp>
beach: I noticed the word "could". In clhs defun entry: "defun can be used to ... redefine an already-defined function", that word is "can".
<loke[m]>
Any argument that malloc/free are actually slow falls of deaf ears since their microbenchmarks all use stack allocation, which indeed is free.
<flip214>
loke[m]: not in terms of cache misses... alloca()te a few KB and you're out of your L1
<loke[m]>
flip214: Well sure, but that applies to all allocations, regardless of whether they are heap or stack. Unless I misunderstand your point?
pranavats has left #commonlisp [Error from remote client]
<beach>
loke[m]: Yeah, but it's disturbing to me that so many decisions in the software industry are based on "gut feeling" rather than research. And I can only imagine the amount of money wasted that way.
<beach>
unixlisp: The word "could" was in my phrase, not the Common Lisp HyperSpec.
<flip214>
loke[m]: no, you're understanding me correctly. My point is that stack allocation is not completely free either.
<flip214>
empwilli: "Faster list processing via automatically rearranging memory"
<flip214>
is the above paper
<flip214>
empwilli: and ELS2018 (https://www.european-lisp-symposium.org/2018/#programme) had "Dynamic Optimizations for SBCL Garbage Collection" which would switch a load balancer around before doing GC, so the equivalent to free() would be free here
Cymew has quit [Ping timeout: 240 seconds]
<beach>
unixlisp: Do I really have to spell this out to you? I mean to say "masinter, you are right that there is an operator (setf symbol-function), but you say that its existence is proof that redefining functions is defined behavior. However, it COULD very well be the case [but it isn't] that this operator is defined only when the symbol does not already have a function defined, in which case definition is OK, but REdefinition is not
<beach>
unixlisp: ... So the existence itself does not guarantee that redefining a function is defined behavior. However, redefining a function IS defined behavior, as the Common Lisp HyperSpec specifies".
<beach>
unixlisp: Is it clear now?
* beach
guesses probably not.
<empwilli>
flip214: thanks, gonna dig into that
<phoe>
beach: DEFCONSTANT would be a better example I think
<phoe>
DEFCONSTANT exists but redefining a constant is UB
<beach>
I give up.
<unixlisp>
beach: oh. "redefining a function IS defined behavior", acording to "defun can be used to ... redefine an already-defined function"?
<beach>
phoe: I didn't come up with the examples.
<phoe>
oh, okay
tfb has joined #commonlisp
semz_ is now known as semz
treflip has joined #commonlisp
mgl has joined #commonlisp
<unixlisp>
beach: I understand your meaning of the masinter case. don't give up :)
tyson2 has joined #commonlisp
kingofcsu has joined #commonlisp
random-nick has joined #commonlisp
kingofcsu has quit [Client Quit]
perrierjouet has joined #commonlisp
Algernon666 has joined #commonlisp
peterhil has quit [Remote host closed the connection]
kingofcsu has joined #commonlisp
Algernon666 has quit [Ping timeout: 240 seconds]
kingofcsu has quit [Client Quit]
mgl has quit [Quit: Client closed]
Algernon666 has joined #commonlisp
kingofcsu has joined #commonlisp
kingofcsu has quit [Remote host closed the connection]
s-liao has quit [Ping timeout: 256 seconds]
igemnace 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
jeosol has joined #commonlisp
unixlisp has quit [Remote host closed the connection]
varjag has joined #commonlisp
unixlisp has joined #commonlisp
mepy has joined #commonlisp
pranavats has joined #commonlisp
s-liao 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 has joined #commonlisp
unixlisp has quit [Remote host closed the connection]
unixlisp has joined #commonlisp
unixlisp has quit [Remote host closed the connection]
beach has quit [Ping timeout: 256 seconds]
unixlisp has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
unixlisp has quit [Remote host closed the connection]
unixlisp has joined #commonlisp
unixlisp has left #commonlisp [#commonlisp]
pranavats has joined #commonlisp
mgl has joined #commonlisp
tfb has quit [Remote host closed the connection]
tfb has joined #commonlisp
tfb has quit [Client Quit]
kevingal has joined #commonlisp
beach has joined #commonlisp
kevingal has quit [Ping timeout: 250 seconds]
kevingal has joined #commonlisp
kevingal has quit [Ping timeout: 250 seconds]
kevingal has joined #commonlisp
perrierjouet has quit [Quit: WeeChat 3.4]
ec has joined #commonlisp
perrierjouet has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
perrierjouet has quit [Quit: WeeChat 3.4]
wyrd has quit [Ping timeout: 276 seconds]
perrierjouet has joined #commonlisp
wyrd has joined #commonlisp
treflip` has joined #commonlisp
s-liao has joined #commonlisp
treflip` has quit [Remote host closed the connection]
VincentVega has joined #commonlisp
treflip has quit [Ping timeout: 240 seconds]
s-liao has quit [Quit: Client closed]
X-Scale has quit [Ping timeout: 256 seconds]
biog has joined #commonlisp
Bike has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
treflip has joined #commonlisp
Alfr has quit [Killed (erbium.libera.chat (Nickname regained by services))]
Alfr has joined #commonlisp
john__ has joined #commonlisp
gaqwas has quit [Read error: Connection reset by peer]
light has quit [Ping timeout: 256 seconds]
light has joined #commonlisp
jeosol has quit [Quit: Client closed]
light has quit [Ping timeout: 256 seconds]
Algernon666 has quit [Read error: Connection reset by peer]
Algernon91 has joined #commonlisp
ahlk has joined #commonlisp
Algernon91 has quit [Ping timeout: 245 seconds]
alvaro121_ has joined #commonlisp
alvaro121 has quit [Ping timeout: 256 seconds]
<Josh_2>
hineios:
<Josh_2>
oops
<Josh_2>
Meant to just write Hi
wacki has joined #commonlisp
Algernon91 has joined #commonlisp
lucerne has joined #commonlisp
<edgar-rft>
Common Lisp is a great language for oops-oriented programming :-)
Algernon666 has joined #commonlisp
<phoe>
In case of (loop for sym being the symbols of :bar collect sym) - is it possible that the list will contain duplicates?
Algernon91 has quit [Ping timeout: 245 seconds]
<moon-child>
maybe some interaction with unintern?
<Josh_2>
edgar-rft: exactly :)
<phoe>
hm, weird, I can't reproduce what I saw moments ago
<phoe>
oh well
<phoe>
okay, I can reproduce it
<phoe>
but still - is it expected to contain duplicates?
<phoe>
I know that DO-SYMBOLS can do that, but I wonder about LOOP FOR-AS-PACKAGE
<Bike>
phoe: do-symbols can hit symbols multiple times if they're inherited from multiple pa- right.
<phoe>
yes - so, just a question about LOOP in this case
<dim>
BTW has anyone tried shipping a software built with ECL: a C-core and some APIs exposed to a Lisp part of the application? -- I am thinking about doing that for pgloader, allowing me to use the existing C drivers for database sources etc
Catie has quit [Quit: sQuit]
Catie has joined #commonlisp
<dim>
EdLangley[m]: I can't say publicly that I am or that I am not ;-)
<jackdaniel>
dim: I've shipped a C application linked against ECL that allowed connecting via swank medling with a running C application (i.e recompiling functions), the api was available to the lisp world to test things out
<jackdaniel>
(can't share the source code though)
<EdLangley[m]>
There's an iOS app that embeds ECL in a Qt app
<dim>
jackdaniel: sounds a good starting point ; in the case of pgloader I would do the basic boring stuff in C (copy data around) and the interesting bits in Lisp (merge catalogs, parse commands, all the advanced / user-friendly stuff) ; would you have an opinion?
<jackdaniel>
btw pls works on qt6 continuation that qt-core and qt-widgets dependency
<dim>
I mean I would like to both simplify the build process and also have an eye to better perfs for the inner loops when written with the official database drivers in C
<jackdaniel>
dim: core written in C and linked against ECL sounds like a good fit for that, yes
<dim>
more important than perfs is also full protocol support even with new versions, including auth and encryption
<dim>
jackdaniel: awesome, I might look into how to implement that later then ;-)
<jackdaniel>
you could also write your own lisp libraries and compile them to shared objects (you may inline C code in Lisp functions too)
<EdLangley[m]>
It would be nice to keep postmodern up to date here
<dim>
it's either that or porting to Clojure to benefit from all those JDBC drivers out-there
<jackdaniel>
the only limitation is that if you want to recompile functions that have inline c code, then a c compiler must be available on the system
<dim>
maintaining qmynd for MySQL and patching Postmodern for Postgres SCRAM authentication and all those things, I believe it's too hard an ask for just maintaining pgloader
<jackdaniel>
(dynamic ffi works without that, also precompiling things works)
<dim>
yeah well I would like to ship a copy of pgloader that's all static built in the ideal world
<dim>
I like the dynamic aspects, but I prefer the “just works” story for end-users that don't even know lisp is involved in pgloader, and when they do, don't understand why
<jackdaniel>
ecl may be linked in statically, but you need to keep in mind that the license of the implementation is lgpl-2.1+
perrierjouet has quit [Quit: WeeChat 3.4]
<dim>
well I mean I can also build dynamically, my focus is easy-to-build, easy-to-ship, easy-to-use, don't need to know anything about lisp
perrierjouet has joined #commonlisp
<jackdaniel>
sure; the application I've mentioned earlier had ecl mostly for debugging, live patching and such, the end user was not concerned with any programming languages
<dim>
and to be fair the current pgloader story doesn't provide these when using either SBCL or CCL
kevingal has quit [Remote host closed the connection]
<jackdaniel>
deployment is a hard problem disregarding the language
<jackdaniel>
even if you have a C application linked only against libc
<dim>
I have no problem getting a debian package included in debian and apt.postgresql.org for pg_auto_failover and the latest tool I wrote, pgcopydb, that are written 100% in C...
<EdLangley[m]>
You can also link the native driver into the application statically
<dim>
I have tons of problems with pgloader where I bailed out and the current maintainers each time want to orphan it and find a way to update bits here and there and continue to maintain it but spend hours and hours on the package building and maintenance
<jackdaniel>
I need to go now, I'll read the log later
<dim>
thanks for your help already jackdaniel , I know I want to try with ECL now ;-)
<etimmons>
dim: ECL is probably great for this, but you can also link C code into the SBCL runtime. You can even deliver a fully static executable (I've got some patches floating around for that. I really need to work on getting them upstreamed)
kotshie has joined #commonlisp
<dim>
I have heard and keep hearing about that capability each time I bring the topic up, but I never got a clear documentation using maintained APIs to do that in pgloader myself, unfortunately
<dim>
think embedding OpenSSL and libpq, maybe, to get started
<EdLangley[m]>
CFFI has documentation for this
<dim>
rewriting the inner core of pgloader in C looks the easiest way around for me nowadays :/
<dim>
Thanks. someday I should try and understand CFFI. It has only been problems to me.
Algernon91 has joined #commonlisp
<mgl>
jackdaniel: In ECL, (let ((*print-pretty* nil)) (princ '(function foo))) prints #'FOO. Is this compliant? Is there a way around this?
Algernon666 has quit [Ping timeout: 245 seconds]
<etimmons>
I actually don't think CFFI's manual is great here. That static linking it talks about is really only for CFFI generated wrappers, not system libraries like OpenSSL
<etimmons>
I use a homebrewed system to build my static executables. But it's definitely not fit for others to use at the moment
<etimmons>
The current best (and I believe supported) way is to build SBCL with :sb-linkable-runtime option. Then link your libraries with sbcl.o to make a new runtime that has all your C libs already present
<EdLangley[m]>
I've used it for system libraries
<etimmons>
But, alas, I don't know of clear documentation that lays it out
<etimmons>
EdLangley[m]: How?
<EdLangley[m]>
But, it's a bit annoying.
<EdLangley[m]>
I forget, I'd need to find an old project
mgl has quit [Ping timeout: 256 seconds]
<etimmons>
Let me know if you do, I'd be interested in seeing it
<dim>
remember that I need something that builds on machine I have never seen and will never see, it needs to be built in debian systems and by users when they want to, most of them using a Docker image of some sorts...
<fitzsim>
etimmons: with that sbcl.o approach, is it possible to get a REPL on the running binary?
<dim>
anyway a C application that uses ECL to implement some of the higher form logic (decision making, etc) in Common Lisp sounds a good approach for my delivery needs here
<etimmons>
fitzsim: Definitely!
<fitzsim>
so SBCL can be used to provide Common Lisp as an extension language then
<Shinmera>
Not really, SBCL has quite specific requirements about the runtime (such as catching a bunch of signals)
<etimmons>
fitzsim: Shinmera's right. It sounds like you want the relatively recent additions to SBCL for producing a dynamic library
<fitzsim>
ah, yeah, I see
<phoe>
goodness
<phoe>
working on CLR2 really has me chasing some funny edge cases
<fitzsim>
SBCL is "in charge" in the current iteration, but the idea is to create a linkable libsbcl.so so that the C-based runtime can be in charge
<EdLangley[m]>
Setting CFLAGS during the build should let you link in additional libraries
<fitzsim>
something like that?
<EdLangley[m]>
I haven’t tried this, but I’ve done similar things manually
<etimmons>
fitzsim: I don't know, I haven't been following it closely
light has joined #commonlisp
mgl has joined #commonlisp
Lord_Nightmare has joined #commonlisp
cage has joined #commonlisp
Jing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
EsoAlgo has joined #commonlisp
<seragold[m]>
<dim> "remember that I need something..." <- I am confused. If it is run from docker image then the OS environment is already controlled by that image regardless of environment of machine the image in run on, right?
<seragold[m]>
<jackdaniel> "right, eql5 is a very cool..." <- I don't trust the Qt company folks enough to invest much here. Starting to look at CLOG
treflip has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 240 seconds]
varjagg has joined #commonlisp
<tyson2>
seragold[m]: what do you think of Clog so far?
varjag has quit [Ping timeout: 250 seconds]
<seragold[m]>
tyson2: too early in my journey to say so far as day job eating too much energy. more to say in about a month.
<tyson2>
ok thanks seragold[m] , same here, hope to look at it again shortly
<White_Flame>
I had built a few flash & html based GUIs, but not a general library yet. I tend to believe that having a desktop metaphor _inside_ a webpage isn't necessarily the most useful
<White_Flame>
but having multiple tabs/windows be part of the same lisp application (or server) context is quite important
kotshie has quit [Remote host closed the connection]
<Shinmera>
I'm sad that Clog is completely useless for my purposes :(
<Shinmera>
It looks really neat
<Shinmera>
I'm *also* sad that I've so far been unable to procure any real contributors for Alloy
<Shinmera>
Or had much time to work on it myself beyond emergency fixes
<moon-child>
alloy?
tyson2 has quit [Remote host closed the connection]
<Shinmera>
The toolkit I've been building and using for games
<EdLangley[m]>
I’ve been meaning to look into it, but my work schedule is a bit crazy
<Shinmera>
Isn't everyone's
<White_Flame>
hmm, how does it do layout without having any standard renderer?
<White_Flame>
or is everything of specified size instead of by flow?
<Shinmera>
It just does it. You only need the renderer once you enter text.
<Shinmera>
the interaction between that is one of the parts that's still a bit shakey.
<Shinmera>
Shakey as in I'm not happy with the protocol, not that it doesn't work at all.
<Shinmera>
Ime most elements are positioned in a way that does not require feedback from the text renderer.
<dim>
seragold[m]: I mean I have seen too many recipes/how-tos with manual fiddling or worse interactive adjustments along the years, and finding the so files for cffi and more generally in common lisp has always been a problem when I had to
<seragold[m]>
<Shinmera> "I'm sad that Clog is completely..." <- So what makes it so? Might be good information for the fond dreams of many of us.
Algernon91 has quit [Ping timeout: 240 seconds]
<Shinmera>
it requires a browser.
<White_Flame>
a browser is a huge heavy-lifting UI library :)
<Shinmera>
It is.
<White_Flame>
the other thing is that a browser-based frontend means you automatically have remote access and multi-user
<White_Flame>
so I tend to consider all those things positives
<White_Flame>
the browsers tend to have nicer looking rendering for plain fonts & layout, and easier "make it look good" options than native UIs
<White_Flame>
but their legacy-laden languages are kinda clunky and beg for a nice declarative lisp abstraction on top of them
<EdLangley[m]>
The downside is there’s a whole class of side-channel attacks that are ubiquitous now
<Shinmera>
I also just don't want to ship browsers.
<EdLangley[m]>
Because browser apps have to communicate any persistent data over the network.
<White_Flame>
EdLangley[m]: sure, and if somebody is snooping on your local machine, who knows what they can find
<White_Flame>
but those sorts of leaks in that link seem to be around centralized services where lots of statistics can be gleaned
<White_Flame>
as opposed to using it as a local termianl to your own applications
<EdLangley[m]>
They’re timing attacks on SSL connections
<White_Flame>
any time you hit the public net, you risk that
<White_Flame>
especially centralized services
<White_Flame>
I don't think you need to worry abotu that for private use
<EdLangley[m]>
By observing things like packet size and timings you can essentially decrypt information about a specific user
<EdLangley[m]>
With a local app, I can firewall data exfiltration
<EdLangley[m]>
And I don’t have to think at all about whether the middle boxes can run this sort of attack against me.
<White_Flame>
and that local app can use browser technologies to offload tons of really nice rendering & interactivity features
<White_Flame>
and there are no "middle boxes"
<EdLangley[m]>
Sure
<White_Flame>
and if using SSH tunnels to your own applications elsewhere, someone would have to be severely intimate with what you're doing on both ends to be able to gain anything, assuming you're not pouring multiple links of thnigs over such channels
<White_Flame>
meaning, using a single tunnel for more than 1 application at a time
<EdLangley[m]>
But, my main issue with non-native toolkits is that it ruins the cohesiveness of my desktop
<EdLangley[m]>
Cocoa on macOS has all sorts of nice stuff built in that the developers of these apps don’t know and/or care about
<White_Flame>
there isn't that much cohesiveness anyway. copy/paste/drag is basically just used for text and files across applications for the most part, and browsers support that
<EdLangley[m]>
And being forced to use Electron and stuff makes life bad
<White_Flame>
yeah, electron is a bad packaging model
masinter has joined #commonlisp
<seragold[m]>
Can I do electron like things with CLOG. I thought I saw that in some post I can't put my finger on. If so it might close some of the browser objections.
<EdLangley[m]>
You can bundle a web server in your electron app
<seragold[m]>
yeah it is heavy but to get something that looks runs the same everywhere I am not sure I have a strong objection.
<EdLangley[m]>
But my issue is that web tech has bad UX in my preferred desktop environments
<EdLangley[m]>
Because it doesn’t work like the native widgets
<White_Flame>
native widgets change between OS releases, too, so there really isn't a singular goal for a portable system
<EdLangley[m]>
This is also an issue with Qt, but less so with react-native
<seragold[m]>
I am sad desktop UX has largely been greatly lost to web and mobile UX today compared to a couple of decades ago.
<White_Flame>
yep
<EdLangley[m]>
The solution to this is to stop using technologies that increase fragmentation
<EdLangley[m]>
CAPI is nice here
<seragold[m]>
even my recent Mac OS desktop looks like candy colored mobile BS to a degree I find offensive
<Shinmera>
Cohesive LAF is overrated. It's really not important to users, and it's not like it ever really was very cohesive at all. There's always been tons of apps on any platform that break LAF either in small ways by using other icon sets, or in big ways by using completely custom styling.
<EdLangley[m]>
Because it uses real cocoa widgets
<White_Flame>
I, for one, like reusing solutions for complex problems, instead of reimlementing simpler hacks
<White_Flame>
and what a browser offers is some very complex stuff to reimplement
<EdLangley[m]>
Shinmera: I just want my keyboard shortcuts to work as expected
<EdLangley[m]>
There are a ton of them in macOS that don’t reliably work in non-cocoa UI toolkits
<seragold[m]>
along with a whole lot of constraints on kinds of UX you can even consider and constraints based on browser security needs that leak through
perrierjouet has quit [Quit: WeeChat 3.4]
rgherdt has quit [Read error: Connection reset by peer]
<EdLangley[m]>
Also, the other issue I have with browsers is that the development model prioritizes what the developer wants the app to look like over the user
<seragold[m]>
yeah you can open a Canvas and do whatever but still
<EdLangley[m]>
By having all these advanced layout features, etc. it takes LAF out of the hands of users and the desktop developers
<EdLangley[m]>
Which is the opposite of what I want
<EdLangley[m]>
The complexity supports a goal that is completely at odds with what I want
perrierjouet has joined #commonlisp
* seragold[m]
misses Smalltalk bitblt graphics and UIs
<seragold[m]>
Used to dream the good dream of "objects" that included how to render them in some generic rendering language that any machine with graphics capabilities would do the right thing with. Instead of the extraction of data from logical objects and separate creation of some rendering stuff in something completely different to talk to quite primitive base web browser tech. SIGH. Cohesiveness of data/code bodies lost. Local to data/code
<seragold[m]>
body rendering control not possible. Endless ugly hacks and specializations of wasted imho effort to make it sort of work.
<seragold[m]>
Vanity, Vanity. Verily there is nothing new under the Sun.
<White_Flame>
of course, that's the opposite of EdLangley[m]'s wish, too, if the rendering is encapsulated in the ojbect instead of controllable by the user, I think
<White_Flame>
and the OO model of tightly coupling code & data is not very appropriate for managing complexity, IMO
<White_Flame>
it can do very well when data is only in simple hierarchies
<EdLangley[m]>
It would depend on who’s providing the objects
<EdLangley[m]>
If the view-layer objects are provided by the OS, it would be fine
<EdLangley[m]>
(Or are based on OS widgets)
Lord_Nightmare has quit [Ping timeout: 256 seconds]
<seragold[m]>
OS should not own widget sets imho. If you think about WIMP non-multi-touch UI there aren't that terribly many fundamental concepts and visual bits. Make a good base DSL for that (no, HTML + CSS + JS in NOT that). HLL composes UI rendering/interaction using that. HLL language if serializable (like Lisp) is send between servers and clients and indeed P2P. Yes some OS renders the base DSL more prettily than others.
mgl has quit [Quit: Client closed]
<seragold[m]>
Mac GUI programming btw contains some of the worst spaghetti coded travesties I have run across.
<EdLangley[m]>
The OS (or desktop environment) should own the widget set because that way all the applications will use the same widgets
frodef has quit [Ping timeout: 256 seconds]
<EdLangley[m]>
And what you learn about interaction in one app will automatically transfer to the next app.
<moon-child>
seragold[m]: you have invented arcan
<moon-child>
EdLangley[m]: ui paradigm is different from widget set
<seragold[m]>
And why the heck is it OK for OS to dictate what widgets you can and cannot use? Why is it that this making portable rendering across devices and OSes impossible a good thing? This has been a plague on application development for decades.
<seragold[m]>
and on UI/UX innovation imho
frodef has joined #commonlisp
<EdLangley[m]>
Because the user picks the OS or Desktop Environment based on the experience they want
<EdLangley[m]>
I use a Mac, because I like a certain UI/UX model
<moon-child>
seragold[m]: the premise is not that the os dictates what widgets may be used, the premise is that it provides certain widgets. You are not required to use those widgets, and you may mix those widgets with widgets of your own devising
* moon-child
thinks the widget model should die, but will keep quiet about that
tyson2 has joined #commonlisp
<EdLangley[m]>
The thing I dislike the most about web apps is that every app developer thinks they can reinvent "dropdown list" or "button"
<EdLangley[m]>
And force whatever idiosyncratic styling they come up with on me.
<seragold[m]>
but I am a heretic. I think UI/UX is just a face/exposure/manifestation of some computational/world subparts. Hell I think appliacations are just a temporary grouping and interaction paradigm on some subparts that may be parts of very different "applications" as well. So many artificial boundaries that are less porous than I dream of
<White_Flame>
EdLangley[m]: yes, hard agree
<White_Flame>
the base model of the browser doesn't have enough vocabulary of elements, so people have to invent trees etc, and thus end up inventing the base ones, too
<seragold[m]>
True, CSS makes it trivial to change the style in whole or part on such things.
aartaka has quit [Ping timeout: 240 seconds]
<seragold[m]>
nothing against libraries of effective widgets as long as they are not a trap for thinking about and implementing best UI/UX possible or proprietary to one OS.
<EdLangley[m]>
"best UI/UX possible" is relative to an enviroment
<EdLangley[m]>
A UI/UX that works well on Windows or Linux doesn't necessarily work on macOS
<seragold[m]>
to some degree yes but preferably not to some artificial degree as it is today
<seragold[m]>
Then that seems a fault of the walled garden platforms to some degree and a fault of how we look at these things.
<seragold[m]>
and generally it would work but not necessarily look "native"
<jackdaniel>
what was this channel irc name again?
<Shinmera>
#ui-opinions
<jackdaniel>
right
<jackdaniel>
mgl: probably a bug
<masinter>
the browsers have managed to be consistent with the platform and users expectations
<masinter>
application/common-lisp
alvaro121_ has quit [Ping timeout: 250 seconds]
<jackdaniel>
nothing beats good old pen and paper for ui, who cares about computers anyway :)
<masinter>
i'm looking for some help with common lisp in Medley Interlisp.org
alvaro121 has joined #commonlisp
<masinter>
In particular, consistent keystrokes -- what do 'modern' users expect
<White_Flame>
EdLangley[m]: I would say the best UI/UX is relative to the application itself
<moon-child>
masinter: what do you mean by keystrokes?
<moon-child>
as in, keybindings, or ?
<masinter>
emacs, linux, windows, mac yes
<masinter>
that control-V control-T control-E control-x meta / alt etc
<moon-child>
can't help there, I have no idea what people expect :P
<masinter>
keybindings are especially hard because they are intercepted at too many levens
<masinter>
oh, the X server / client and VNC gateway too
xsperry has quit [Ping timeout: 256 seconds]
<moon-child>
well, some of those you can't do much about
<moon-child>
readtable is a language feature
alvaro121_ has joined #commonlisp
<jackdaniel>
whether this is #ui-opinions or #commonlisp this gets offtopic, please move to #lisp or #lispcafe
<mfiano>
^
alvaro121 has quit [Ping timeout: 240 seconds]
<moon-child>
jackdaniel: hey, readtable is explicitly a common lisp language feature!
<jackdaniel>
moon-child: don't play dumb.
waleee has joined #commonlisp
masinter has left #commonlisp [#commonlisp]
aartaka has joined #commonlisp
morganw has joined #commonlisp
VincentV` has joined #commonlisp
VincentVega has quit [Ping timeout: 240 seconds]
<Shinmera>
etimmons: regarding your blog post, the lack of a proper "community" is distressing to me as well, mostly because I maintain a *lot* of projects, many of which I just do not have the life-force to properly maintain anymore, and so far nobody has wanted to step up either. There's also many big projects that I have been almost wholly unable to find contributors for. Now, granted, these are
<Shinmera>
certainly very selfish reasons for being distressed, and I understand *why* there is no proper community -- there's few people spread all over the globe, all mostly doing things "for fun" and "in their way" because CL is very malleable. The piles upon piles of testing frameworks is, to me, a parallel to this. There keep being more made, either because people don't see the alternatives because
<Shinmera>
the ecosystem is too fragmented, or because they just want to do their own thing and don't want to bother contributing. Aside from just increasing the mass of people using CL, I don't know if there is a "fix" for this issue, and doing so brings its own problems that I personally am not very interested in solving. I'm happy, as many are, to just do my own thing for my part. I suppose that also
<Shinmera>
makes me part of the problem in a sense :)
alvaro121 has joined #commonlisp
john__ has quit [Remote host closed the connection]
shka has quit [Ping timeout: 256 seconds]
alvaro121_ has quit [Ping timeout: 250 seconds]
<phoe>
(incf Shinmera)
karlosz has joined #commonlisp
<yitzi>
(incf Shinmera 10)
<mfiano>
(incf Shinmera)
alvaro121_ has joined #commonlisp
alvaro121 has quit [Ping timeout: 256 seconds]
<EdLangley[m]>
There’s always this hard question of whether to shave a yak or put up with the hairy yak
<EdLangley[m]>
I’ve generally been happy to use other people’s libraries that are good enough and contribute back as best I can.
<EdLangley[m]>
My personal annoyance is the number of different JSON libraries
<phoe>
this and the testing frameworks
<morganw>
Would someone be able to link me to the blog post? (sorry to appear and ask mid-conversation)
<Shinmera>
The testing framework thing is personally stinging me, because I tried to solve the issue by making something that should be malleable enough to easily make it fit whatever personal aesthetic preferences you may have
<Shinmera>
Unfortunately it seems I was almost entirely unsuccessful in the attempt. OH WELL.
<phoe>
to the point where Sabra needs to make blog posts that compares them all
<semz>
EdLangley[m]: guilty as charged on the JSON one
<phoe>
and, worst of all, *update* them
<EdLangley[m]>
I’ve started to use parachute
<EdLangley[m]>
I had been using 5am
<EdLangley[m]>
So, I’ve had bad experiences with Jonathan in particular
<EdLangley[m]>
It looks like it’ll be fine
<EdLangley[m]>
But, it has (or had) some (safety 0) stuff in its public interface that’ll give you a bad time
* phoe
grabs the flamethrower
<Shinmera>
Jonathan managed to crash my SBCL fully when I ran it for a test one time and I haven't tried it since :v
<EdLangley[m]>
(If you search the logs circa 2015 in the freenode channel, you’d fine details)
<etimmons>
Yeah, these are certainly hard issues, probably well above what any single person can tackle
alvaro121_ has quit [Ping timeout: 250 seconds]
<phoe>
well, if we ever *hypothetically* wanted to settle for a single test framework used everywhere, we'd piss off like 80% of project owners no matter which one we choose
<etimmons>
And I've done my share of making new projects instead of trying to modify existing ones as well.
<phoe>
same with JSON libraries
<semz>
The thing is that since many libraries are not all too complete, it's often much easier to just roll your own instead of first understanding the library and then fixing it up.
<phoe>
still, I think it's worth doing
<phoe>
semz: I actually root for jzon since it was designed with correctness from the very start, and it's one of the few libraries which have 100% test coverage for the JSON scenarios from the main test suite
alvaro121 has joined #commonlisp
karlosz has quit [Quit: karlosz]
<phoe>
but that's just my private bias
<phoe>
;; this, and it has no (safety 0)
<semz>
see I didn't even know about that one before I made my own crappy one
<semz>
this one has (safety 0), that one doesn't handle errors properly, that one only parses objects and not literals
<phoe>
well, it's easy to roll your own in Lisp; the only real solution that's left is to make it infeasible to do so
<EdLangley[m]>
I’m a fan of yason because I’ve used it for years and have more or less figured it out
<EdLangley[m]>
And I like that it makes some of the “wrong” decisions but lets you adjust its behavior when it matters
<Shinmera>
I'm a fan of forgetting whichever it was I used last time and then getting confused and frustrated every single time
<phoe>
and the only way of achieving that that I know is to choose the best™ one(s) and promote it(them) in a somewhat aggressive way
<phoe>
and that pisses maintainers off
<phoe>
(understandably)
<EdLangley[m]>
I think turning false into nil, for example, is the right thing to do by default
<EdLangley[m]>
Because then (gethash “isFoo” parsed) is unsurprising
<White_Flame>
I decoded json arrays into cl lists, and false->nil is wrong in that scenario :)
Oladon has joined #commonlisp
<EdLangley[m]>
I don’t mind the type pun
<phoe>
your encoder will, however, if NIL can be both false and []
<EdLangley[m]>
As long as there’s a way to adjust the behavior when you really care about it
aartaka has quit [Ping timeout: 250 seconds]
<EdLangley[m]>
Sure, round-tripping is the exception here
<_death>
so what if there are a zillion libraries to do one thing in different ways.. some may see it as "inefficiency", others may see it as "diversity".. if you want to put effort into a single project, there's nothing stopping you.. the asdf problem is almost the opposite one.. a single implementation, where there should be a single specification and many implementations
<phoe>
and the worst thing is that [] is true in JS, which is at the same time acceptable, terrifying and off-topic here
<EdLangley[m]>
In a lot of cases you’re just trying to get the data into lisp and you don’t actually care too much
<moon-child>
phoe: so's #() in cl
<EdLangley[m]>
Because the are driven by the object key names not the types.
<phoe>
moon-child: that's the "acceptable" part
_73` has joined #commonlisp
<EdLangley[m]>
*the semantics are driven
_73` has left #commonlisp [ERC 5.4 (IRC client for GNU Emacs 28.0.90)]
<moon-child>
I wanna know why it's terrifying though :P
<phoe>
_death: that's the opposite problems, yes - in Lisp it's hard to make very hard things (like system loaders) and trivial to make hard things (like JSON parsers)
<_death>
to me the etimmons was half weird (why drag this issue on and on? stassats already added maintainers who merged the patches) half worrying (the "let's break things" vibe)
<EdLangley[m]>
What’s terrifying in JavaScript is that 0 is falsy
<phoe>
hence people go for the easy and not the hard, and we have ten json libraries and one ASDF (I'm rooting for CPLM)
<pjb>
EdLangley[m]: 0 was false in LISP 1.5
<semz>
to be fair the thing with asdf is also that a lot of people rely on random internals
<semz>
(and that ever since v3 it's a mess tbh)
<phoe>
semz: random internals of what exactly?
<phoe>
I need a bit more context
<semz>
of asdf, or implicitly rely on uiop
* semz
tried to run old ASDFs for fun once
alvaro121 has quit [Ping timeout: 250 seconds]
<_death>
actually we have more than one asdf.. there's the asdf that's bundled with sbcl and there's the asdf that continues to change.. personally I like the fact of the former one and don't care for the latter one, so my worrying about etimmons's breakage is a bit abstract
<semz>
my point being that even if you were to replace asdf, you'd end up reimplementing the existing one quite a bit
<phoe>
the main issue with the current CL world I see is that different people in it want two different things
<phoe>
long-term stability versus long-term progress
azimut_ has quit [Remote host closed the connection]
joast has quit [Quit: Leaving.]
alvaro121 has joined #commonlisp
azimut has joined #commonlisp
<EdLangley[m]>
I want both
<phoe>
and you simply *can't* have both without effort that is impossible to maintain with the few hands that are here
<yitzi>
I fail to see how reducing the number of JSON or testing libraries would achieve either.
<moon-child>
the _language_ is not going to progress either way. So as I see it, the people who want stability are not affected by the people who progress
<phoe>
hence we get thunderstorms and volcano eruptions
<_death>
I don't think it's an issue.. that's why "no single community" is a good thing.. everyone join the subcommunity (or not) that cares about the things they care about
<phoe>
hmm
<EdLangley[m]>
Yeah, I like CL because it’s the opposite of the JavaScript world I have to deal with professionally
<phoe>
maybe that's a good solution
<White_Flame>
"the JavaScript world" sounds like an underworld if programming was a fantasy setting
<moon-child>
tools, not communities
<_death>
because there aren't many people writing CL, sometimes it can seem lonely.. and survivorship bias results in people who don't mind
<White_Flame>
yeah, the size of the CL userbase is still under some critical mass point
<White_Flame>
IMO
<moon-child>
good
<Shinmera>
_death: What pains me is that I see it as wasted effort, at least if the project is published (if you just do it for yourself, whatever). Esp. for the testing frameworks, there's so many, and many of their differences are miniscule, that I can't help but think it would have been better to just improve an existing one instead.
<moon-child>
have you seen what happens to places on the internet that achieve scale?
<White_Flame>
but there is also the lisp curse side of things where stuff is quite easy to write yourself
<White_Flame>
s/quite/relatively/
<Oladon>
I coded JS for a long time... and stayed as far away from any kind of "JS world" as I could (which was pretty far).
<Oladon>
Consequently, I was able to enjoy JS as the functional-inspired Lisp derivative that it is. :)
<EdLangley[m]>
My professional life is continually fixing my app when a dependency breaks things
<drakonis>
Oladon: JS is actually not a lisp derivative
<Shinmera>
My professional life is continually fixing my app when I run into a bug I also wrote in the long line of shaven yaks.
<drakonis>
its a very impressive fabrication that has existed since its inception
<_death>
Shinmera: right, it may seem inefficient, especially if viewed as a collective.. but the people who wrote the test frameworks probably knew of the others and made the choice to write their own rather than fix and be dependent on others (why did you write parachute?)
<phoe>
_death: I don't believe that the only possible alternatives are the extremes of JS hellhole and the current CL situation
<Shinmera>
_death: I wrote parachute because I wanted to write one that could usurp them all. The specific goal was to write something that would be flexible enough to trivially extend to what people typically make a new one for (surface syntax changes)
<drakonis>
is scheme's approach not acceptable?
<phoe>
drakonis: scheme's approach, could you elaborate?
<_death>
phoe: but why do you think CL is at an extreme? there are still PRs going on.. it's just that many CL people are conservative and the language is stable so there's no pressure to break things fast
<EdLangley[m]>
I think the attitude “I want to replace all the alternatives” doesn’t reflect why the alternatives exist
<EdLangley[m]>
If I reimplement something it’s often because I want control
<drakonis>
CL has been frozen for ~28 years
alvaro121_ has joined #commonlisp
<aeth>
not really
<EdLangley[m]>
Collaboration has a cost too
<theothornhill>
to me it looks a little like the CL world needs to open up to maintainers. Surely there are many folks wanting to help. But seeing issues at GH lingering for years with no answer does not inspire for someone to help/take over, I think
alvaro121 has quit [Ping timeout: 256 seconds]
<drakonis>
scheme has reports every dozen years that serve to ratify a baseline of sorts and srfis for libraries
<drakonis>
aeth: please do correct me
<_death>
Shinmera: it's reminds me of that xkcd
<aeth>
drakonis: you can't write many meaningful CL applications without using de facto standards that are portably handled through libraries that deal with the differences
<aeth>
so you can't speak to the outside world without de facto extensions to the standard
<aeth>
other than through the POSIX shell, I guess
<drakonis>
but it is more of a commonly accepted way to do things
<Shinmera>
_death: Sure.
<moon-child>
aeth: you can write meaningful, portable _libraries_ though
<Shinmera>
_death: I'm just saying that was the goal, and it is not a goal I have seen other testing frameworks take, neither before I wrote it, nor now.
<_death>
Shinmera: anyway, personally I use parachute in my recent projects.. and the testing "frameworks" I wrote, I didn't publish.. so maybe I'm doing my part :)
<drakonis>
but it is not really "standardized"
<drakonis>
the portability matrix is basically "sbcl is the main implementation, everyone else barely exists"
<aeth>
drakonis: yeah, but the Scheme reports aren't ISO/ANSI/ECMA/etc. standards, either. Just non-authoritative PDFs. So an equivalent literally could just be someone specifying bordeaux-threads, CFFI, etc., in a PDF and "requiring" implementations to include that library instead of going through Quicklisp for them
<Shinmera>
_death: glad to hear :)
<drakonis>
sure
<Shinmera>
People have tried that kinda thing through CDR and other documents.
<phoe>
(multiple times)
<phoe>
and failed (multiple times)
<drakonis>
but that really shouldn't prevent a community local attempt
<Shinmera>
The problem is nobody really cares, so the only way to make it work is by literally doing all the legwork yourself
<phoe>
and there's still people longing for the CDR process (multiple people, multiple times)
<drakonis>
isnt it commonly held that spending millions on it is wasteful and therefore there shouldnt be sequels to ansi cl?
<aeth>
R7RS really is just a series of SRFIs, especially R7RS-large
<moon-child>
no interdependencies?
<Shinmera>
drakonis: The money isn't the issue. The issue is that most are complacent and there's no real problem to solve at the moment like there used to be.
<etimmons>
_death: I definitely don't want to "break things." I would love it if every library everyone wrote is always backward compatible. And yes, CL gives us tools to add new features while maintaining backward compatibility in most cases. But sometimes breakage is the best way forward. And I think that deserves to be acknowledged, especially when it's done right with a very long notification time.
<drakonis>
i see.
<semz>
"sbcl is the main implementation, everyone else barely exists" <- this has not been my experience
<drakonis>
apologies, let me reword it then
kevingal has joined #commonlisp
varjagg has quit [Remote host closed the connection]
<aeth>
the only thing stopping someone from "R7RSing" the CL standard and coming up with an "authoritative" PDF is that the author wouldn't own the copyright on the spec to start building off of. So you can't just do CLHS+CDR like you can do R5RS+SRFI for R7RS
<Shinmera>
aeth: Nobody would care about it being authorative
<drakonis>
sbcl ends being the primary option
<aeth>
well, that, and you'd need the major implementations to take you seriously.
<theothornhill>
Shinmera: but if someone wants to contribute to/fix/remake hunchentoot or something else, I'd be surprised if they were allowed within two feet of the source code
<Shinmera>
And it's not like fragmentation in the scheme space isn't also a big problem lol
<moon-child>
aeth: draft spec is public domain. And see wscl
alvaro121 has joined #commonlisp
<aeth>
Shinmera: in particular, many major Schemes seem perfectly fine with staying on R6RS instead of going to the more R5RSish R7RS
<Shinmera>
Does anybody even bother to write libraries that are portable in scheme?
<drakonis>
we have r7rs-large coming up next, so we'll see how that turns out
<Shinmera>
In the same way people always hand-wring about portability in CL
alvaro121_ has quit [Ping timeout: 240 seconds]
<moon-child>
I saw one recently
<aeth>
snow-fort's nothing compared to any popular implementation, though
<moon-child>
most don't, though
<drakonis>
but no, the handwringing hardly happens
<moon-child>
they build up communities around specific implementations (chicken, gerbil, chez...)
<Shinmera>
Right. Anyway.
<drakonis>
because the implementations are all very divergent
<drakonis>
except where you use srfis and rnrs
<Shinmera>
I gotta be off to do some late-night gamedev.
<aeth>
drakonis: importantly, they're divergent in a way that makes it hard to rectify, in how they do libraries
varjagg has joined #commonlisp
<drakonis>
there are srfis that get extracted off the various scheme dialects
<aeth>
CL has DEFPACKAGE, ASDF, and Quicklisp to work off of at various levels of abstraction, as well as a culture that encourages you to do it this way
<etimmons>
theothornhill: I agree about opening up to maintainers. (Sorry, I had to step out for a moment and am working through the scrollback)
<aeth>
drakonis: and, yeah, it looks like a huge chunk of snow-fort is just (chibi something), which just means that chibi was written in a portable enough way that someone could extract it as an R7RS package
mgl has joined #commonlisp
<_death>
aeth: right, same about bordeaux-threads and cffi
xsperry has joined #commonlisp
<drakonis>
that's correct and i'd like to point out that most of r7rs-small/large is chibi
<drakonis>
most of the reference implementations
<drakonis>
that and gambit
<theothornhill>
etimmons: Yeah, it just seems so futile trying to make an attempt, IMO. At least for less experienced people
<_death>
aeth: all these are not perfect, but are common denominators
joast has joined #commonlisp
<Shinmera>
Clearly this frantic discussion is going to lead to a revolution in the Lisp community and encourage hundreds to start contributing and helping out with existing efforts :)
<aeth>
the only thing where there's no common denominator is sb-unicode
<drakonis>
ha
<aeth>
afaik, there's no equivalent to sb-unicode elsewhere
<drakonis>
i wish that'd ever happen
<drakonis>
there's lots of sharp edges in lisp that folks have become complacent
djuber has joined #commonlisp
<moon-child>
I think somebody did a portable unicode thing, but it is out of date and bad
<drakonis>
since it is so easy to paper over them
<Catie>
thothornhill and etimmons: I can't speak for anyone else, but this very much resonates with me. The idea of maintaining an existing project is very intimidating as someone who is new to Common Lisp
<Catie>
theothornhill: ^ (and I apologize for misspelling your name)
<drakonis>
i find it difficult to get started with cl in 2022 because of those sharp edges
<theothornhill>
Catie: No worries, I do it all the time
<drakonis>
even if you were to read all of the material, its still there.
<semz>
what edges are these?
varjagg has quit [Ping timeout: 240 seconds]
<drakonis>
the usual when coming off from scheme
<drakonis>
and the kind of things that get excised in later lisps
<drakonis>
T and NIL, '() evaluating to nil
<semz>
eh
<drakonis>
defun/defvar/defparameter
<Shinmera>
That ain't no edge, that's a smoooth pillow!
<EdLangley[m]>
the things I like about CL?
<drakonis>
i mean, i can get #t and #f with schemes :V
<moon-child>
drakonis: if you care about #f and #t, then use scheme
<aeth>
to me, what seems bad in CL is inconsistent APIs e.g. (nth index list) or (gethash key table) VS (elt sequence index) or (aref array &rest indices) ; etc
<drakonis>
^
<theothornhill>
Catie: Yeah, this was one of the things I really liked about starting contributing to emacs. There was always someone responding to my stupid emails when I first started out. To me (from reading lots of cl issues) it seems like newbies often gets either pushed away, or ignored
<aeth>
stuff that can't really be avoided for basckwards compatibility...
<phoe>
(incf aeth)
<Shinmera>
drakonis: Your mistake was thinking they're the same
<etimmons>
Catie: theothornhill: an example: I was shying away from Dexador for quite a while. But now that fukamachi has added at least one more maintainer that seems motivated, I'm more likely to keep using it.
<Shinmera>
can't really call that "edges"
<phoe>
(incf theothornhill)
<semz>
now where is that post about how lisp dialects don't meaningfully exist
<Catie>
etimmons: Shying away from using it?
<drakonis>
they're really not, no.
<moon-child>
semz: lisp by the pound?
<semz>
yes that is the one
<drakonis>
i know that all three do different things :V
<semz>
I should keep proper track of the things I read
alvaro121 has quit [Ping timeout: 256 seconds]
<etimmons>
Catie: Yes. It had well known bugs that I didn't have time to fix and prior experience showed that even if I did, the PR would languish for a while
alvaro121 has joined #commonlisp
* theothornhill
thinks phoe deserves a shoutout for helping noobs
<drakonis>
aeth: that's indeed the problem
<semz>
I don't think these minor annoyances really have any effect. Look at the inconsistencies in stuff like Python or JS that people put up with. Or hell, PHP.
* semz
shudders
<EdLangley[m]>
Fukamachi used to be a lot more active
<etimmons>
Catie: But it now seems there's someone else with commit bits that is more active. Even if things don't get merged ASAP, having some activity or acknowledgement of issues keeps despair from setting in
<aeth>
semz: well, Python has its own problem in that it took its language's landmines, broke compatibility, and set the language adoption back a decade as the community fragmented in two
wacki has quit [Quit: Leaving.]
<aeth>
semz: So it does kind of show you that you can't really fix some things
<semz>
that kind of proves my point though doesn't it
<drakonis>
python recovered, in a way.
<theothornhill>
etimmons: Yeah, I can understand that problem, especially because forking most likely is not the solution
<aeth>
you just have to get it right at the start or live with it
<Catie>
etimmons: Very much understandable, I agree. It can be disheartening to depend on a project that may have long-standing bugs
<etimmons>
EdLangley[m]: Yeah, I don't mean any dig against him and I do know he/his family has some health issues.
<phoe>
theothornhill: *bows*
<drakonis>
Shinmera: everyone makes mistakes :V
<etimmons>
That's why I'm heartened by the fact he acknowledged that and added more people to help him out
<EdLangley[m]>
Yeah, I’m only saying that he used to review and accept pull requests relatively quickly
<EdLangley[m]>
I also think he switched jobs or something
<EdLangley[m]>
I’m still using drakma
<aeth>
drakonis: Machine learning saved Python from Python 3. Nothing came along to save Perl from the even more ambitious Perl 6 attempt. It does suggest that breaking compatibility can't really be done, though.
<Shinmera>
drakonis: Sure enough. I am making one right now!
<_death>
I don't mind my PRs languishing in other projects so much, because I just use my own fork.. if I submit a patch to a project and I get no reply, I just avoid submitting more patches, but I continue to patch my own fork
<drakonis>
ha, which one are you making :V
<Shinmera>
drakonis: making games for a living
<drakonis>
ah i concur there :V
<EdLangley[m]>
_death: did your CFFI PR ever get merged?
xsperry has quit [Read error: Connection reset by peer]
<EdLangley[m]>
The one necessary to make tree sitter usable?
<drakonis>
aeth: not ML alone but the scientific library stack has saved it.
<drakonis>
julia might kill off python in time however
<EdLangley[m]>
I’d like to see Julia beat Python
<EdLangley[m]>
Especially since it has multimethods
<drakonis>
julia is very interesting.
<_death>
EdLangley[m]: no.. the reason I submitted those in the first place was because I was asked.. but I don't mind that they weren't merged (though the other user of tree-sitter may feel differently?), and maybe there are better solutions to those problems in the future anyway
<_death>
EdLangley[m]: one of them breaks backwards compatibility, so indeed I hope there's a better solution
<EdLangley[m]>
I’ve been experimenting with tree-sitter to do some analysis of JS
<EdLangley[m]>
And I was happy to find your version of an API wrapper because I was running into some edge cases of passing structs around by value
<seragold[m]>
<aeth> "semz: well, Python has its own..." <- not so true today. everyone moved to python3 finally. Not that that is altogether good.
alvaro121_ has joined #commonlisp
<drakonis>
aeth: as far as i'm concerned, python has bigger problems than the move from 2 to 3
<moon-child>
jpm still has 30m lines of python code, and will continue to maintain the python2 interpreter because _it_ is only 3m lines of code
alvaro121 has quit [Ping timeout: 250 seconds]
<lagash>
moon-child: jpm?
<moon-child>
jp morgan
<EdLangley[m]>
So, my experience with Python 2->3 is the other reason I’m anti-breaking changes
perrierjouet has quit [Quit: WeeChat 3.4]
<lagash>
moon-child: you mean JP Flathead? :)
perrierjouet has joined #commonlisp
<_death>
EdLangley[m]: cool :).. I don't use tree-sitter nowadays (I wrote it one weekend when I discussed some source code transformation on another irc channel) but I think sel still makes good use of it
<EdLangley[m]>
It’s easier than attempting to maintain an ES6 or typescript parse
<seragold[m]>
much of the day job is in python. would give a lot if it would stop trying to kill lambda and would have every bloody function return something reasonable. and if they would make the python3 special collection wrappers work as the actual collections they replaced
<EdLangley[m]>
Plus, GitHub is maintaining it.
alvaro121_ has quit [Ping timeout: 256 seconds]
<lagash>
seragold[m]: out of curiosity, have you tried Hylang yet?
<drakonis>
see also hissp
alvaro121 has joined #commonlisp
<seragold[m]>
looked at it but its almost but not quite nature made me a bit uneasy. that and the rest of the day job team would likely string me up
<_death>
hmm, it appears some common-lisp.net mailing lists vanished :/
<_death>
ok, just their urls changed.. apparently they didn't bother with a redirect
<lagash>
seragold[m]: I mean, considering it's still unstable, yeah
alvaro121 has quit [Ping timeout: 240 seconds]
alvaro121 has joined #commonlisp
<Josh_2>
Teaching a fella with 0 programming experience Common Lisp using GICL
<Josh_2>
<phoe>
GICL?
<Josh_2>
GISC*
<Josh_2>
gentle introduction
<phoe>
ooh, Gentle
<phoe>
yes
erjag has joined #commonlisp
xsperry has joined #commonlisp
erjag has quit [Remote host closed the connection]
dre has quit [Quit: Leaving]
waleee has quit [Ping timeout: 250 seconds]
<dbotton>
That is what I am using to teach my kids programming
perrierjouet has quit [Quit: WeeChat 3.4]
<seragold[m]>
One of my first CS classes was a Survey of Programming Languages and they took us to Symbolics when they were still operational for a few glorious days. Left me rather disgruntled with the state of much of the software world ever since due to the early exposure.
perrierjouet has joined #commonlisp
<lagash>
Jealous!
Algernon91 has quit [Read error: Network is unreachable]
rgherdt has quit [Ping timeout: 240 seconds]
<seragold[m]>
They even had C and Fortran running as a layer on top of Lisp! So you had all their Lisp environment to use even working in those languages.
<seragold[m]>
On Lisp alludes to this "mere skin on top of Lisp" approach but was first time I saw it done.
Everything has joined #commonlisp
<White_Flame>
technically, I don't think they converted C and Fortran to Lisp, but compiled down to its CPU code. I could be wrong, though
<EdLangley[m]>
Mezzano has something like this
<EdLangley[m]>
Using iota, they managed to compile doom to some sort of lisp and run it on mezzano
<seragold[m]>
I remember once upon a time there was a C or was it Objective-C interpreter that could dynamically load and reload object files. IIRC Micro$loth bough them and the tech was never seen again.
<dbotton>
The C "compiler" is still available
<White_Flame>
yeah I'm sure that Mezzano has low-level operations exposed to lisp sexprs for C style stuff
<seragold[m]>
really? cool! where?
<dbotton>
I don't have link handy, but it is on github
mon_aaraj has joined #commonlisp
<dbotton>
I plan on using it in future to encourage people to use CLOG with C, Python etc running on top if CL
<EdLangley[m]>
Iota translates llvm bitcode to CL, so you should be able to use any LLVM language with lisp
<EdLangley[m]>
Unfortunately, it’s not entirely complete
<EdLangley[m]>
But it works well enough
<Shinmera>
Iota works in the same way Emscripten/etc work -- you compile instructions to operate on some sort of byte array, and then plug whatever extra ops you need to flush the relevant memory areas to screen and plug in other i/o bytes.
<EdLangley[m]>
Yeah
Common-Lisp has joined #commonlisp
<dbotton>
Vacietis works by loading C code into a Common Lisp runtime as though it were Lisp code"
<EdLangley[m]>
The advantage being that since the target is inside Lisp, it can’t crash your lisp process or cause memory faults
<seragold[m]>
EdLangley[m]: It may have made since with Symbolic early support international character sets. :)
<phoe>
it's half-joke until you scroll the readme down to the Duff's device - then you realize that it's half-joke half-terrifying
<dbotton>
There is also a similar tools for Basic
<moon-child>
bah. The hard part of implementing c is aliasing
<moon-child>
and afaik zeta cheated with implementation-specific exts
<White_Flame>
it could technically all be done, just the "pointers" would get big and there'd be a ton of runtime tests to figure out what the heck is being pointed at
<White_Flame>
without going to a full byte array heap like webasm does
<EdLangley[m]>
I think vacietis is designed to exploit a bunch of UB that people assume isn’t UB
<moon-child>
White_Flame: yes. Hence 'hard', not 'impossible'
<dbotton>
For my purposes it vacietis works, I want people to try out using CL even if they are using C to do it (or python), eventually people always want to dig more and will try the real thing
perrierjouet has joined #commonlisp
<seragold[m]>
s/It may have made since with Symbolic early support international character sets. :)/It may have made sense with Symbolic early support of international character sets. :)/
<moon-child>
White_Flame: NB. bytearray has its own problems. How do you do function pointers?
<EdLangley[m]>
I started writing a wasm interpreter
<EdLangley[m]>
moon-child: offset into array?
<EdLangley[m]>
Nvm
<White_Flame>
moon-child: yeah, at least in webasm, a function pointer's value is an index into an out-of-scope array that only the runtime has access to
<seragold[m]>
I gave up because I tried to get into it with Rust which I found way too frustrating.
kevingal has quit [Remote host closed the connection]
<moon-child>
White_Flame: I see
attila_lendvai has quit [Ping timeout: 256 seconds]
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #commonlisp
wyrd has quit [Remote host closed the connection]
wyrd has joined #commonlisp
mgl has quit [Ping timeout: 256 seconds]
cosimone has quit [Ping timeout: 250 seconds]
alvaro121_ has joined #commonlisp
alvaro121 has quit [Ping timeout: 256 seconds]
Common-Lisp has quit [Ping timeout: 240 seconds]
alvaro121_ has quit [Ping timeout: 250 seconds]
alvaro121 has joined #commonlisp
z3t0 has quit [Read error: Connection reset by peer]