<jasom>
We were talking about qt5 bindings. The Go QT bindings has a tool that auto-generates extern "C" functions for everything in QT. They can't be used directly though because all callbacks are in autogenerated go files that export a C header through cgo. However, that could be used as a basis for a lisp qt5 generator certainly.
<jasom>
It seems to do so by parsing the xml API documentation
FreeBirdLjj has quit [Ping timeout: 276 seconds]
brettgilio_ has joined #lisp
lavaflow has joined #lisp
lucasb has quit [Quit: Connection closed for inactivity]
<elderK>
How's it going? Gosh, it's been a long time since I was last here.
<beach>
Me? I'm doing fine. Progress is slow but steady. But I don't think that what I do is representative for #lisp.
<beach>
How about you?
<ck_>
What is representative for #lisp?
<White_Flame>
no progress, because people are arguing edge cases of the CLHS
<elderK>
I'm not quite sure how things are. They could be a lot worse, so at least there's that.
<elderK>
White_Flame: Heh :D
moon-child has joined #lisp
<beach>
elderK: Ouch. Doesn't sound great.
<beach>
ck_: A lot of bickering about elementary software-engineering ideas is one thing.
<beach>
ck_: And problems due to the use of foreign code seems to be a popular topic as well.
<drmeister>
Damn - ASDF appears to require fasl files to be files and doesn't allow them to be directories.
<beach>
ck_: A lot of discussion about which of several GUI libraries written in C or C++ to choose, is another.
<elderK>
beach: The problem might be with me. I'm not sure yet. I actually came here to ask advice: What have you guys done in the past when you needed to talk to like, I guess what you'd call an older-role-model. Someone who knows you, but isn't *too* close to you. Someone who's opinion you can trust, without it be influenced by the stuff you're talking about? You might say, talk to a senior colleague. That was my
<elderK>
first idea, but I haven't yet established strong enough connections with my colleagues to make that sufficiently safe.
<elderK>
Sorry about double message. Seems Weehat breaks large messages.
<ck_>
beach: oh, the last point I hadn't witnessed yet. But you make it sound quite bleak in general.
<beach>
ck_: Nah, it is no worse than usual.
sauvin has joined #lisp
<beach>
elderK: That seems quite off topic. Maybe try #lispcafe. I don't go there myself because I don't have time for random chat.
<elderK>
beach: Thanks beach :)
<beach>
ck_: But as I realized a few weeks ago, it's a perfect example of the prisoners dilemma.
malfort has quit [Ping timeout: 276 seconds]
<beach>
ck_: Ideally, Lispers should collaborate to fill the gaps in our collection of libraries and applications, but instead, everyone prefers to work on an immediate individual problem that needs to be solved. As a result, the collective effort is much higher than it could be.
<beach>
ck_: I am not blaming anyone. Just observing a fact.
<ck_>
beach: well like I said in an earlier conversation -- "I'm trying"
<beach>
Absolutely. And that's good! Thanks again!
<ck_>
I meant that as an attempt to nudge the focus towards doing that again. I know this channel isn't fertile ground for that, but one can hope.
<beach>
Ah, I see, yes.
<fe[nl]ix>
drmeister: you're better off going the JVM route: make your fasl a zip-encoded file which you can treat as a virtual file-system
<drmeister>
fe[nl]ix: That's a PITA - the problem is dsymutil on macOS.
<fe[nl]ix>
what do they do ?
<drmeister>
Could I generate a fasl inside of a zip-encoded file and then run dsymutil on it to generate a .dwarf file that also goes into the zip-encoded file?
<drmeister>
Oy vey - don't get me started. It's a shit show.
<fe[nl]ix>
so you essentially want to post-process fasl files, of some sort ?
<lukego>
Xach: Yeah clbuild. I think that worked as an "executable problem statement" i.e. a really quick and easy way to confirm that the latest version of everything is broken and incompatible. In those days I'd regularly "sit down to try some McCLIM hacking" and several hours later still be fighting with installation problems. Quicklisp is a hell of a better experience B)
<drmeister>
Yeah - and I get it. We talked about zip files. We thought directories would be less trouble. Now I'm not so sure.
<fe[nl]ix>
why not do all that while generating the fasl itself ?
<drmeister>
Do what?
ardoc has joined #lisp
<fe[nl]ix>
have compile-file output various intermediate files to a temp directory, call dsymutil, then package verything up in a zip fasl
<fe[nl]ix>
there's something I'm missing here
<drmeister>
We are having a problem with multiple processes compiling the same asdf systems and clobbering each others builds. We need fasl generation to be atomic - so we are going to use rename-file as the atomic operation.
<drmeister>
The problem on macOS is building the fasl and debug info is two steps, not atomic.
<drmeister>
Yeah we could do that.
arduo has quit [Ping timeout: 252 seconds]
<drmeister>
PITA
JohnMS_WORK has joined #lisp
<fe[nl]ix>
of course, as long as each compile-file a) creates a uniquely named temp dir b) creates the fasl in there and c) commits this "transaction" by an atomic rename-file
<drmeister>
We can do that.
<drmeister>
I'll need a zip library I guess.
<fe[nl]ix>
this is a standard way of operating
<fe[nl]ix>
you can even create a zip with compression level 0
<fe[nl]ix>
which means the files are simply appended
<fe[nl]ix>
if you do things right and ensure page-level alignment, you could even mmap directly from the zip file
<drmeister>
Sorry - I'm a bit disgusted at the moment. It's not just this - we found a bug in ld64 that is causing us grief with our compile-file-parallel.
<fe[nl]ix>
without copying the code into anonymous pages
<drmeister>
Things will look better in the morning.
<fe[nl]ix>
sounds good
<fe[nl]ix>
I'm going to sleep as well
slyrus_ has quit [Remote host closed the connection]
slyrus_ has joined #lisp
enrio has joined #lisp
zaquest has quit [Quit: Leaving]
varjagg has joined #lisp
slyrus_ has quit [Ping timeout: 240 seconds]
zaquest has joined #lisp
quazimodo has quit [Ping timeout: 265 seconds]
scymtym has quit [Ping timeout: 250 seconds]
dale has quit [Quit: My computer has gone to sleep]
ardoc has quit [Ping timeout: 250 seconds]
varjagg has quit [Ping timeout: 265 seconds]
epony has quit [Quit: QUIT]
elderK has quit [Quit: WeeChat 1.9]
Duuqnd has joined #lisp
ggole has joined #lisp
epony has joined #lisp
earl-ducaine has joined #lisp
davepdotorg has joined #lisp
zaquest has quit [Quit: Leaving]
zaquest has joined #lisp
Bourne has quit [Ping timeout: 250 seconds]
<earl-ducaine>
I was just reading the SBCL style guide and noted that package prefexes were discouraged. Not a strong prohibition but I was surprised by it.
frgo has joined #lisp
<earl-ducaine>
In my own code I tend to use them quite a bit, i.e. it makes it clear that a set of functons are from the same package and probably are documented there in how they work together.
frgo has quit [Remote host closed the connection]
<pjb>
earl-ducaine: package names can be quite long.
frgo has joined #lisp
mathrick has quit [Read error: Connection reset by peer]
<earl-ducaine>
I'm curious what other's practice is.
<pjb>
earl-ducaine: when you are in the context of a local development, where you control the name of all the packages, you can choose short package names and be happy with qualified symbols.
davepdotorg has quit [Ping timeout: 245 seconds]
<earl-ducaine>
I've noticed that there are a number of aspects to using package prefixes that are problematic.
<pjb>
earl-ducaine: but in the context of internet based development, where you use hundreds of libraries and dependencies, package names need to be unique and long, such as com.informatimago.common-lisp.cesarum.array etc, and then using qualified symbols is bad for readability.
<pjb>
earl-ducaine: note that it's the same problem with nicknames. If you want to publish your code, you cannot use shortnicknames.
<pjb>
earl-ducaine: Only the end-user that won't be publishing his code, can add short nicknames and use them.
<pjb>
earl-ducaine: one solution would be package-local nicknames or relative package names, but there's no complete portable solution yet.
<pjb>
earl-ducaine: have a look at com.informatimago.common-lisp.lisp.relative-package
<earl-ducaine>
Iterate is also a problematic example, it relies on a number of symbols being imported that are neither fuctions, macros or specials. Trying to prefix every one makes it an unreadable mess.
<beach>
earl-ducaine: I only ever :USE the CL package. So I use explicit package prefixes a lot.
scymtym has joined #lisp
<beach>
earl-ducaine: As pjb pointed out, using package-local nicknames would be the right thing, once they are widespread.
<Shinmera>
I've started using PLNs in libraries.
<Shinmera>
ECL,ABCL,CCL,SBCL is good enough coverage for me, and I hope pressure from libraries can convince the commercial implementations to catch up
<earl-ducaine>
beach: thanks! That was actually my next question.
<Duuqnd>
IIRC trivial-package-local-nicknames has support for Clasp too, so it's got almost everything but the commercial ones.
<Shinmera>
Oh, right, Clasp, too.
<Duuqnd>
I checked, it's got support for SBCL, CCL, ECL, Clasp and ABCL.
<earl-ducaine>
Shinmera: I saw you tweet regarding that a while back. I've been meaning to take a look at some of your projects to see how you're using them.
<Shinmera>
I just use the defpackage expression for it. That's portable across all implementations that support PLNs without needing a dependency.
<Duuqnd>
I didn't know SBCL had package-local nicknames built in!
<Duuqnd>
Or did I load trivial-package-local-nicknames without noticing?
Bourne has joined #lisp
mathrick has joined #lisp
<earl-ducaine>
Shinmera: Awesome. Thanks!
mingus has joined #lisp
Kevslinger has quit [Quit: Connection closed for inactivity]
<jackdaniel>
Duuqnd: no library could bring packagle-local nicknames on its own
<jackdaniel>
it may be supported only on implementations which implement the extension
<jackdaniel>
trivial-* libraries are usually portability layers which simply import symbols to a single package so the access to the protocol is uniform for the programmer
<jackdaniel>
so instead of writing #-sbcl ext:foo #+sbcl sb-ext:foo you may write trivial-foo:foo
<jackdaniel>
so if tpn s on the implementation than means this implementaiton have this extension\
MetaYan has quit [*.net *.split]
Ankhers has quit [*.net *.split]
Lord_Nightmare has quit [*.net *.split]
azrazalea has quit [*.net *.split]
mister_m has quit [*.net *.split]
jurov has quit [*.net *.split]
Kabriel has quit [*.net *.split]
<Duuqnd>
Oh, I see. Thanks for explaining! I'm not that experienced with the Common Lisp ecosystem yet.
<jackdaniel>
sure
MetaYan has joined #lisp
Lord_Nightmare has joined #lisp
mister_m has joined #lisp
Ankhers has joined #lisp
azrazalea has joined #lisp
Kabriel has joined #lisp
jurov has joined #lisp
libertyprime has quit [Ping timeout: 240 seconds]
Fare has quit [Ping timeout: 250 seconds]
<phoe>
pjb: package-local nicknames are cross-implementation enough now in the FLOSS Lisp world.
slyrus has joined #lisp
<pjb>
ok then.
<phoe>
The only remaining significant effort I see is to port them to CLISP.
libertyprime has joined #lisp
<boeg>
If I want to push to an empty list, how do I do that? I can easily do it with `push` if the list i initialized with something like `(list 1 2)` but if the list is empty, like `(list)`, I get the error the value nil is not of type cons
<beach>
boeg: You can't turn NIL into a CONS if that is what you are asking.
<phoe>
boeg: you can't push to an empty list, you push into a place
<phoe>
what is the place that you push into?
<beach>
boeg: What phoe is saying. What is the second argument to your push?
<phoe>
(let ((x nil)) (push 1 x) x) ;=> (1)
<phoe>
so it works well for me
<phoe>
X is the place I push into; in this case, it is a lexical variable
<boeg>
so... What I'm trying is that I run through a bunch of things, and if I find what I seek, I push the position of the thing I seek to a list of positions and then continue until I have a list containing all the positions. At the start, the list of positions is empty because I know no positions
<phoe>
boeg: where is your list of positions placed
<phoe>
I can push into a CAR of some cons, into a GETHASH of some hash table, into a SLOT-VALUE of some instance, et cetera, et cetera
<phoe>
what is the place at which your list of positions is located in your code?
<boeg>
beach: ah, what I'm doing right now is `(cdr (last positions))` as second argument to push
<beach>
boeg: Just push onto the beginning of the list instead.
<phoe>
boeg: 1) this is not a place if LAST is not a cons, 2) pushing to the end of the list is inefficient
<boeg>
where positions is just `(defparameter positions (list)`
<boeg>
ah, of course, makes sense
<beach>
boeg: What you are doing is a quadratic algorithm where a linear one exists.
<phoe>
instead, push into the front of the list and nreverse it at the end if you want a reversed list
<beach>
boeg: And you can use '() to initialize the parameter. It is more idiomatic.
<boeg>
I guess I was just caught up in the mindset of "adding to the end of the list" when it really doesn't matter
<boeg>
thank you
<beach>
Anytime!
<phoe>
boeg: adding to the end of the list only works if the end of the list exists as a place
<phoe>
if the list is empty, the list *is* the end of the list
<boeg>
phoe: yeah, I understand that now, makes sense :)
<phoe>
a CDR of some cons is a place, but a CDR of NIL is not - that's the trick here
hhdave has joined #lisp
<boeg>
yes, it's clear to me now, thank you
gxt has quit [Ping timeout: 260 seconds]
<pjb>
phoe: do you know exactly what is required to hook PLN into a new implementation?
<pjb>
(usually we only need to patch a couple of CL functions).
<pjb>
phoe: if you do know, it'd be nice to mention it in the issue.
davepdotorg has joined #lisp
<pjb>
boeg: first, you have a fundamental misconception here. One cannot "push ont a list" in lisp, since there is no list ADT in lisp! What we do, is to create a new lisp with a new element in the car of the new cons cell, and the old list in the cdr of the new cons cell. Then we rePLACE the binding of the PLACE considered with this new list.
<pjb>
boeg: ie. we push onto a PLACE. (push element PLACE).
<boeg>
pjb: yes, I think I'm getting it now, we'll see if it sticks, thank you :)
<pjb>
boeg: we can as well push onto a PLACE that is not bound to a list! (let ((x 42)) (push 33 x) x) #| --> (33 . 42) |# this just create a new cons cell as said above.
<phoe>
pjb: noted, thanks.
<pjb>
boeg: Finally, I shall mention that while most lists are represented by cons cells which are potentially mutable (if they're not literal cons cells), the case of the empty list is special since it's represented by a SYMBOL which is essentially IMMUTABLE. This is why we cannot mutate lists (chains of cons cells OR the symbol NIL), since the symbol NIL cannot be changed, notably, cannot be changed into a cons cell.
<pjb>
boeg: hence delete, remove, etc having to return the new result, instead of mutating the argument value, and hence POP and PUSH working on places instead of lists.
<pjb>
boeg: a good exercise would be to implement a list ADT (eg. using CLOS standard-objects).
<boeg>
pjb: interesting - i'm still only trying to properly understand the specifics of cons cells, symbols and so on, so I shall keep that in mind
<phoe>
pjb: I commented on that issue and mentioned that I have the background to perform the task. Thanks.
<pjb>
phoe: great! (I thought the random phoe was a different phoe ;-)).
<pjb>
boeg: note that in practice (in actual programs), you can avoid NIL as a representant of the empty list, by storing your list in a cons cell (perhaps a temporary cons cell). Then you can work with the list by using cons cell MUTATION, since all the values are always cons cells.
<boeg>
pjb: i'll keep that in mind
<phoe>
that's a hack though - a list is always placed somewhere, and you can mutate that place
<pjb>
boeg: it's kind of like the use of guard values in iterations, that simplies the tests.
<pjb>
Indeed.
<phoe>
the only thing you do is standardize that the lists are going to reside in CDRs or CARS of conses
<phoe>
but CDRs and CARs of conses are places anyway, so literally nothing has changed from the technical point of view
<pjb>
Only the code is simplified because you deal only with cons cells. You don't have to special case for NIL anymore.
<phoe>
pjb: only if, for any reason, you want to mutate lists without dealing with places
<phoe>
which is weird since places exist exactly for the reason of solving this problem
<phoe>
so it's like, implementing an alternate solution when for any reason we don't want to use the existing one
<beach>
That is called "concrete" vs "abstract" data types.
<beach>
Common Lisp lists are concrete. You need concrete data types to implement abstract ones.
karlosz has joined #lisp
<beach>
If you want to create a protocol for use by client code, usually you want an abstract data type.
<beach>
But for its implementation, it is fine to use concrete data types.
<pjb>
For example, compare the two functions in https://pastebin.com/WaL0tTvw ; the first needs to test inside the loop for NIL; the second doesn't. It will be faster, if the consing of a temporary cons cell can be amortized.
<pjb>
err, s/collection/coll/ where needed…
<phoe>
pjb: I'd also do a version with that PUSHes into collection to show the difference
<phoe>
I abstract away the whole "is COLLECTION empty or not" and just push into it
<pjb>
Even push itself doesn't need to test for the old value in the place.
<phoe>
that's the convenience of places
<phoe>
in this last case, COLLECTION is a place
<pjb>
No, just of push which just needs to do cons without testing for the list.
<pjb>
It's when you need to mutate the list, ie. the actual cons cells, that the trick of using a prefix cons cell can be good, to avoid testing for nil.
<phoe>
pjb: one second, need to parse this
<pjb>
Because (length (cons x list)) > 0 even when (length list) = 0.
<jackdaniel>
tracking the last cons is also beneficial if you want to push at the end of the list
<phoe>
oh right, correct - but COLLECT-IF is a bad case of showing how to mutate a list
<jackdaniel>
you just replace cdr of the stored cons
<phoe>
since it doesn't really mutate the contents of any lists, other than NCONCing stuff onto them which doesn't change the tail
<lottaquestions>
So does that mean that the code generated by the macro will run OK with the NIL
<lottaquestions>
instead of the ()
<lottaquestions>
in the parameter list section of the function?
<pjb>
lottaquestions: it means that there's no difference! The object read when you read NIL or () with the default read-table is exactly the same symbol CL:NIL.
<pjb>
there are a lot of representations of CL:NIL…
<lottaquestions>
oh thanks. A newb learns another thing :-)
<pjb>
lottaquestions: you should not confuse the textual representations from the actual lisp objects that are read to, or printed from.
<_death>
(format nil "~A is identical to ~:A" '() nil)
<lottaquestions>
pjb I blame it on my algol based background :-)
Fare has joined #lisp
omarish has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
anewuser has joined #lisp
didi has quit [Ping timeout: 276 seconds]
kmeow has joined #lisp
kajo has quit [Ping timeout: 265 seconds]
<kmeow>
is there a built in function that produces a sequence from a sequence, but with elements meeting a condition removed?
<kmeow>
I could have sworn I saw one used somewhere
<_death>
remove-if
brettgilio has joined #lisp
<kmeow>
thanks!
skeuomorf has quit [Ping timeout: 268 seconds]
brettgilio_ has joined #lisp
_paul0 has joined #lisp
paul0 has quit [Ping timeout: 246 seconds]
<drmeister>
fe[nl]ix: the problem with the zip file idea is that macOS needs the dwarf file to be out in the open file system alongside the fast
<drmeister>
Fasl
Fare has quit [Ping timeout: 250 seconds]
Posterdati has quit [Ping timeout: 252 seconds]
lucasb has joined #lisp
ironbutt has joined #lisp
FreeBirdLjj has joined #lisp
lottaquestions has quit [Remote host closed the connection]
ljavorsk has quit [Ping timeout: 240 seconds]
FreeBirdLjj has quit [Ping timeout: 265 seconds]
Posterdati has joined #lisp
<froggey>
drmeister: what is compile-file-parallel? what bits does it do in parallel?
patlv_ has joined #lisp
elfmacs has quit [Ping timeout: 246 seconds]
kajo has joined #lisp
Bike has joined #lisp
enrio has quit [Ping timeout: 240 seconds]
tourjin has quit [Ping timeout: 252 seconds]
<drmeister>
Everything after the ast compilation
<drmeister>
We get about a 2x speed increase and with our slow llvm based compiler i desire very much to get it online.
orivej has joined #lisp
omarish has joined #lisp
<froggey>
neat, sounds similar to what I implemented. though I only got a 10-15% speedup
<drmeister>
So one source file generates multiple object files. That’s a problem on macOS - the ld64 linker will only reference one object file per source file.
<drmeister>
Our compiler is llvm based and probably has higher latency than yours.
mathrick has joined #lisp
<drmeister>
The amount of parallelism is HIGHLY variable. So 2x is a rough estimate.
<froggey>
probably, still 15% is good. took me to sub-30 minute build times
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 265 seconds]
rgherdt has quit [Remote host closed the connection]
Lord_of_Life_ is now known as Lord_of_Life
rgherdt has joined #lisp
pfdietz has joined #lisp
shifty has quit [Ping timeout: 265 seconds]
omarish has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cosimone has quit [Quit: Terminated!]
omarish has joined #lisp
enrio has joined #lisp
clothespin has quit [Ping timeout: 240 seconds]
brown121408 has quit [Ping timeout: 240 seconds]
brown121408 has joined #lisp
rgherdt has quit [Ping timeout: 246 seconds]
brettgilio has quit [Ping timeout: 250 seconds]
Lycurgus has joined #lisp
clothespin has joined #lisp
clothespin_ has joined #lisp
patlv_ has quit [Ping timeout: 268 seconds]
Duuqnd has quit [Ping timeout: 240 seconds]
clothespin has quit [Ping timeout: 245 seconds]
<drmeister>
You compile to native code - right? If you had to describe how you do that in an elevator ride - how would you?
<pjb>
drmeister: what bothers you with the separate dwarf file?
<drmeister>
It's not atomic to generate it.
<drmeister>
We are running cando in jupyterlab.
<pjb>
File generation is not atomic either.
<drmeister>
When jupyterlab starts up - you can have several cando instances startup at once. They all start building asdf systems and stomp all over each other.
<pjb>
So you might solve it either by exchanging the order of generation, or by generating the fasl file under a different name and renaming it after the dwarf file is created.
<drmeister>
So we compile-file to a temporary target and then rename it - that is atomic.
<drmeister>
But we can't rename two files atomically.
<pjb>
drmeister: you will have to solve the cando problem in a different way, given 1- file generation is not atomic, and 2- you won't want to mix fasl files from different (versions of the) sources either.
kritixilithos has joined #lisp
<pjb>
drmeister: you only need to rename the fasl file.
<drmeister>
Why do we only need to rename the fasl file?
<pjb>
But really, you cannot solve your problem without a more general lock.
<drmeister>
We thought we could use a directory as a fasl file. Then we can put whatever inside of it and rename the directory atomically.
<pjb>
drmeister: because asdf only tests and deals with the fasl file. It doesn't care about the other files.
<froggey>
for compile-file: forms are read, top-level form processing is performed (eval-when, etc), then anything that needs to be saved is fed into the compiler which produces a regular compiled-function (along with a set of relocations). compile-file accumlates the compiled functions until it finishes reading the input file, then writes out everything to the fasl
kajo has quit [Ping timeout: 240 seconds]
<pjb>
file writing is not atomic!
<pjb>
If two processes try to write the same file, you get problems anyways.
<drmeister>
Yes - so the two processes write to temporary directories and then each tries to rename its directory overwriting whatever target was there.
<drmeister>
That was the theory at least.
malfort has joined #lisp
zaquest has quit [Ping timeout: 245 seconds]
<drmeister>
And it works well enough for clasp - although I haven't tried multiple processes doing competitive compilation.
<drmeister>
ASDF explicitly checks that fasl files are files and not directories. I disabled that for clasp.
<drmeister>
Now I'm running into ASDF's own version of writing to a temporary fasl and then renaming it causing problems.
<pjb>
drmeister: The point here is to keep consistency. You may want to keep files consistent. But I'm saying that you will also want to keep whole directory hierarchies consistent. You don't want half the fasl files compiled by one instance of cando, and the rest by another, because then the fasl files can be inconsistent, either by way of the compilation process itself (assuming the sources are the same; eg. perhaps different optimi
<pjb>
levels), or because the sources are different between the two cando.
<drmeister>
This is really just a problem on macOS. They do this thing where they separate out code from debug info. It's causing me grief.
<pjb>
drmeister: so you must manage it at this higher level, forbiding the two initializations to occur at the same time.
<pjb>
drmeister: this can be a problem everywhere. jupyterlab & tar xvf sources.tar && jupyterlabe
<pjb>
boom!
<pjb>
Why do you have two jupiterlab instances running?
<drmeister>
Not two jupyterlab instances. One jupyterlab instance with multiple sessions running. That's very common.
<pjb>
ok. So the solution is to be solved in jupiterlab, which must prevent the launching of new session when the old ones are not finished initializing and compiling stuff.
<drmeister>
Much of the cando source code is written using ASDF systems and loaded using quicklisp.
<pjb>
You can have the same problem if you M-x slime several instances at the same time.
<drmeister>
So if I edit the source code and start up jupyterlab I get like five cando instances starting up at the same time trying to build the same code. It's trample town.
enrio has quit [Ping timeout: 265 seconds]
<pjb>
Exactly.
<pjb>
The cando instances must not start at the same time.
<drmeister>
It works because they keep crashing and starting up again automatically and picking up where the whole mess left off. But it's not pretty.
<pjb>
Perhaps we could put a global lock at the system level with asdf.
<pjb>
when asdf is compiling a system, another asdf must not try to compile the same system.
<pjb>
But synchronizing at a finer level than the system level won't be a good solution.
kmeow has quit [Quit: Leaving]
<drmeister>
These are running in different unix processes - how would you do a lock like that?
<pjb>
You can create locks by creating a file in the system directory.
dddddd has joined #lisp
<drmeister>
Why not just use directories as fasls and rename (atomic) of the fasl/directory?
<drmeister>
Locks are a PITA and modifying ASDF to handle concurrency - gah.
<pjb>
drmeister: the alternative, is to compile your system before launching the cando instances!
cosimone has joined #lisp
vap1 has quit [Read error: Connection reset by peer]
<boeg>
A loop using :for, :with and such, what is it called? I see it used in some code, but I can't find documentation for it and don't really understand how its supposed to work
<pfdietz>
LOOP is part of the Common Lisp standard.
<aeth>
ITERATE was a great disappointment when I tried it because it's its own thing.
<pfdietz>
(although I think you should get that from quicklisp, not the links at that page)
<pjb>
a loop not using anything is a simple loop (there's an implicit block nil): (let ((i 0)) (loop (print 'hi) (when (< 3 (incf i)) (return 42)) (print 'lo)))
<boeg>
I gotta get used to the documentation cause I find it a bit confusing at the moment
<aeth>
All I want is a lispier LOOP so I'll have to eventually write one myself
<pjb>
aeth: the lispiest loop is loop!
<pfdietz>
My sadness with ITERATE was it broke COVER.
<pfdietz>
That's COVER's fault, though.
mhcat has joined #lisp
<pjb>
as in the simple loop.
cosimone has quit [Quit: Terminated!]
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
vaporatorius has joined #lisp
<aeth>
pjb: not really, LOOP is kind of a demo of what macros can do in Lisp rather than the Lispiest way to write such a macro
<dlowe>
I'm a SERIES fan for the idea (if not the implementation)
<dlowe>
I think complex loops could be expressed best in a series-type system
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.2)]
<boeg>
What I'm currently interested in is that is that I saw something like this somewhere: `(loop :with (a . b) = c ....` where I'm guessing that c, a list, get's "deconstructed" into the variables a and b, so a contains car and b cdr, to be used the loop, but I'm not succesful in looking that up in the documentation. I guess it'll be easier as I can more used to the customs of common lisp :D
<aeth>
pjb: If I had to implement LOOP, what I would do is I would make each of its clauses be its own s-expression and I would use plist tails to implement its vocabulary via DESTRUCTURING-BIND, which is common in macros. This would also mean that ordering within a clause wouldn't matter past the first. e.g. (:for x :from 1 :below 10) vs. (:for x :below 10 :from 1)
<mhcat>
Hi Lispers, does anyone have a recommended threading macro implementation for CL? I found alexandria's COMPOSE which solved one of my discomforts (I'm a habitual clojurist) but threading would be super useful for controlling my cascading indentation.
<aeth>
pjb: I have written something that does some limited parsing (for HTML generation), I guess sort of like what LOOP does, and it's its own thing and doesn't quite feel as right.
<aeth>
Josh_2: it is but no one can read DO for whatever reason
<Josh_2>
¯\_(ツ)_/¯
cosimone has joined #lisp
<aeth>
Josh_2: The most spirit-of-Lisp kind of thing to do is to write your own DO-FOO on top of DO (or on top of another macro that probably itself uses DO like DOLIST or DOTIMES)
<aeth>
If your DO is unclear, that's just a hint to write a new DO-FOO
<dlowe>
I mean, the lispiest loop is schemes named-let recursion
<aeth>
well, that's the Schemiest thing to do
<aeth>
In CL, macros that compile to do DO seems more like the right thing.
<aeth>
Of course, no need to do the right thing. :-p
<dlowe>
CL has lots of right things
<pjb>
aeth: no, loop, when it contains only compound forms, is a very simple macro!
<aeth>
dlowe: well, the other "right thing" that seems CLish is to use higher order functions like MAP and REDUCE
<aeth>
pjb: Having written macros where you have a "vocabulary" to parse like LOOP and macros where you just have a bunch of lists to DESTRUCTURING-BIND, I can definitely say that the latter is waaaaay easier because &key does most of your work for you
gravicappa has quit [Ping timeout: 240 seconds]
<aeth>
The only reason why D-B has some haters is because its condition is inconsistent across implementations so you can't really handle it, afaik.
<phoe>
aeth: condition?
<pjb>
aeth: Not only the extended loop is what you say, but it's an example of a generic macro, that dispatches to TWO different macros, depending on the arguments!!!
warweasle has quit [Client Quit]
gravicappa has joined #lisp
EvW has joined #lisp
<aeth>
phoe: (destructuring-bind (a) (list)) ; [Condition of type SB-KERNEL::ARG-COUNT-ERROR]
<phoe>
aeth: what about it?
<phoe>
that is a valid error
<dlowe>
there's no standard error for it
<aeth>
phoe: The standard doesn't specify destructuring-bind conditions, so there's no way for you to handle them programmatically in a portable way.
<phoe>
I knew that I'd have a chance to post that library during my lifetime
<aeth>
phoe: oh, good solution, it looks like you eventually just generate a destructuring-bind so it shouldn't hurt efficiency
<phoe>
as much of an edge case that it is
rippa has joined #lisp
<phoe>
anyway, feel free to use this one and/or test it and/or file a bugticket if something is broken
<phoe>
I have some tests there, but there might be more bugs lurking.
<pfdietz>
Ah, it uses a flag to determine if the error comes from the destructuring or the body.
brown121408 has quit [Read error: Connection reset by peer]
brown121408 has joined #lisp
<aeth>
phoe: doesn't someone have a random tester for standard CL? you could run that but adding a * after destructuring-bind and see what comes up
<pfdietz>
Who would write such a thing.
DGASAU has joined #lisp
<pfdietz>
Anyway, the random tester is limited to mostly integer valued forms, so it doesn't test destructuring-bind much.
<pfdietz>
(if at all)
smazga has joined #lisp
didi has quit [Remote host closed the connection]
kajo has joined #lisp
Davd33 has joined #lisp
mhcat` has joined #lisp
mhcat has quit [Ping timeout: 265 seconds]
efm has joined #lisp
port1024 has joined #lisp
<aeth>
pfdietz: that's unfortunate, I'm sure there are probably some nice, fun binding bugs out there, especially with the more advanced binding forms like destructuring-bind and defmacro
<Davd33>
Some lispers in France maybe?
jonatack has joined #lisp
ironbutt has quit [Ping timeout: 246 seconds]
gxt has quit [Ping timeout: 260 seconds]
<pjb>
Davd33: some. Even in Bordeaux.
<Davd33>
Cool! Do you know how to contact them?
<pjb>
Here, if you need interactive contact.
<pjb>
Do you need a Lisper in France?
theBlackDragon has quit [Quit: Boom.]
<pjb>
I'm in Paris. beach is in Bordeaux. There are others.
dale_ has joined #lisp
dale_ is now known as dale
<beach>
Davd33: There are also a bunch of others that don't hang out here, like Didier Verna and Jim Newton. They are at EPITA.
<Davd33>
Alright, I’m from Bordeaux but currently in Luxembourg
<pjb>
Do you need a lisper in Luxembourg? I'm free…
EvW has quit [Ping timeout: 245 seconds]
<Davd33>
I’m currently employed, not as lisp dev unfortunately. ^^
<pjb>
Ok.
vaporatorius has quit [Read error: Connection reset by peer]
anewuser has quit [Quit: anewuser]
<beach>
Davd33: So was it just out of curiosity that you asked about Lispers in France?
<beach>
Davd33: If you go to ELS2020, you will meet a few. I highly recommend going.
<Davd33>
Oh yes I would like to go to ELS
<aeth>
France seems to be the most popular European country for Common Lispers.
<aeth>
At least from my limited perspective that might not see the full picture.
<pjb>
And this year, it's close, Zürich, you can go in train.
<Davd33>
But registrations are not yet opened I think
<beach>
aeth: Germany and Sweden are well represented too.
Fare has quit [Ping timeout: 268 seconds]
<beach>
Poland.
<pjb>
And cheap. TGV Paris-Zuerich 7:22-11:26 in April is only 29 euro…
<Shinmera>
Very fast too :)
<pjb>
Shinmera: it's faster than any plane, since you can work non-stop during 4 hours with your laptop. You cannot do that when you take a plane…
<boeg>
Right now i'm running my scripts with simply "sbcl --load file.lisp" but this current one is taking a looong time to finish when I use the real input to the program instead of just the test input. Can I tell sbcl to optimize the compilation - like remove debug info and so on - to run faster?
<pjb>
boeg: foremost, you could just launch sbcl and use the REPL!
<Xach>
boeg: it is likely doing a pretty good job by default. if it takes a long time to do its work it may be the algorithm needs attention.
<boeg>
pjb: well, in actually, i am, from emacs, with sly
<pjb>
boeg: (load (compile-file "file.lisp")) and (load "file") if it's already compiled.
<Xach>
there are certainly settings to improve the margins after you have done lots of other low-hanging fruit
<pjb>
boeg: You can put (declaim (optimize (safety 3) (debug 3) (space 0) (speed 0) (compilation-speed 3))) in ~/.sbclrc
<boeg>
Xach: Well, it's surely my algorithm - I haven't optimized at all, just wanted to see if the real input gave the real output
<boeg>
and thanks, ill try some of those things
<pjb>
boeg: and when you want to generate a binary, use (declaim (optimize (safety 3) (debug 0) (space 3) (speed 3) (compilation-speed 0))) in your generation script.
<boeg>
thanks!
<boeg>
Also another question that might be part of my speed problem
<boeg>
I have a list ((1 2 3) (5 3 6)) and I need to find the items in the two list that are in both lists. So that would be the `3` only. Right now, I just loop the first list and on each item loop the next, check if theres a match and collect the match if there is. This is probably why it takes so damn long with the real input.
<_death>
do these lists represent sets?
oxford has quit [Remote host closed the connection]
vaporatorius has joined #lisp
<boeg>
_death: no, right now they are just normal lists
<boeg>
but I use pushnew so there should only be uniques
<_death>
if you wanted to write your own, a hash table may be useful
Josh_2 has quit [Read error: Connection reset by peer]
<boeg>
Yeah, I was actually looking for a hash table in the beginning, but I'm pretty new to common lisp, doing advent of code to learn it, and couldn't find anything immediately, so just went with list
<pjb>
boeg: the question is what result you want for (3 3 3) (3) ?
<boeg>
but I just confirmed that the algorithm works as it should, its just slow, so now i just need to optimize it
<boeg>
pjb: just (3)
<Davd33>
boeg: I’m also doing the advent of code in cl
<pjb>
boeg: so basically they are sets.
<Davd33>
We should share answers afterwards 😊
<boeg>
Davd33: :P
<boeg>
pjb: yes they are, but i dunno if lisp has sets
<boeg>
I just went with lists :P
<boeg>
common lisp*
<pjb>
boeg: CL has no list. It has no set. But it has functions that work on lists built with cons cells, and on sets built with lists.
<boeg>
pjb: well, see what little I know :)
<pjb>
boeg: it may be a good idea to read the dictionaries TOC in CLHS.
<pjb>
So instead of writing #*0001011, you write 𝔟7(3 5 6)
<boeg>
yes
<arichiardi>
Hi there, I have submitted an email patch to alexandria-cvs but I think it got stuck. I was wondering who I can reach out for un-stuck it :D
<arichiardi>
_death: that's a good idea thank you!
arichiardi has quit [Remote host closed the connection]
<galdor>
regarding Alexandria, it says in a PR that "Well, as ALEXANDRIA is so widely used, we cannot put new (exported) symbols in its package." I don't get it, why is this a problem ? removing symbols would be a problem, adding them should not be
<Xach>
galdor: it could cause conflicts for people that :use alexandria
<_death>
galdor: I guess many people :use it, so if they have a defined name that alexandria will now export, redefinition may happen and you may not be so lucky as to detect it
<Xach>
I want to try building the quicklisp world with everything package-locked to see what breaks
slyrus_ has joined #lisp
Fare has quit [Ping timeout: 268 seconds]
slyrus has quit [Ping timeout: 250 seconds]
Davd33 has joined #lisp
<dlowe>
use-package was a mistake
Davd33_ has joined #lisp
<Shinmera>
nah
<Xach>
I think local package names bridge a gap in that regard.
<Xach>
You can do as alexandria did and version your names, and for a given version, the set of external symbols is fixed.
<Shinmera>
PLNs are great, but sometimes :use is still better.
<Xach>
Consumers can pick a version and give it a name they like
<Xach>
Joe Marshall wrote a thing about never ever putting package prefixes in code and that was kind of interesting
Davd33 has quit [Ping timeout: 265 seconds]
<_death>
you can :use alexandria.version.3.141592 in ordinary common lisp
cosimone has quit [Quit: Terminated!]
<Xach>
Right. I am conflating unrelated things. Sorry.
<Xach>
the thing I was thinking of is using a package prefix for a versioned package with a "nice" local name
<Xach>
I think inherited symbols are different and ok too
<_death>
personally I :use only cl or packages I control.. for the rest I :import-from.. if the symbols are generic, I tend to :import-from with no symbols (so that it depends on the library; package-inferred-systems) and use the FQLN
<Shinmera>
Xach: while using versions in packages is great in concept, in practise asdf can't deal with it at all so it would be a kludge at best.
cosimone has joined #lisp
<Shinmera>
*asdf can't deal with multiple versions at all
<Shinmera>
until ASDF is replaced, of course.
mercourisj has joined #lisp
<Xach>
Shinmera: ??? it's nothing to do with asdf and all about the interfaces supported by a project. the project offers multiple versions of the external symbols.
buffergn0me has joined #lisp
<Shinmera>
yes, but you won't be able to load the same project at different versions, so what's the poitn?
<jackdaniel>
Shinmera: you can use alexandria.314 and they can use alexandria.42
<Xach>
Why not? A project can define any number of packages.
<_death>
Shinmera: alexandria v123 may provide 123 packages, one for each version
<Shinmera>
I don't count that as a practical solution.
Davd33_ has quit [Remote host closed the connection]
<Xach>
Why not?
<_death>
Microsoft did it with COM
<Shinmera>
Because it should be the job of the build system to determine the versions required and only load those.
<Shinmera>
not every version in the universe.
<jackdaniel>
*that* would be impractical, because two different libraries may depend on different versions
<Xach>
I don't think alexandria should provide every version, but as a mechanism to ease the transition from one version to another (at possibly multiple levels of supporting older interfaces) I think it is practical.
<jackdaniel>
unless you have first class global environments as beach proposed
mercourisj is now known as jmercouris
<Shinmera>
jackdaniel: what would be impractical?
<Xach>
If versions are additive, especially, a v2 package with a few more symbols is not, I think burdensome.
cosimone_ has joined #lisp
<jackdaniel>
Shinmera: having build system determine versions -- you could have two incompatible versions as dependencies of different libraries, and without global environments you wouldn't be able to depend on both
cosimone has quit [Ping timeout: 250 seconds]
<Shinmera>
if you version your packages I don't see the problem?
<jackdaniel>
having different packages for different sets of exported symb0ols makes more sense
kajo has quit [Ping timeout: 250 seconds]
<jmercouris>
I think this is a non-problem not even worth solving
EvW has joined #lisp
<Shinmera>
I'm saying package versioning is a good idea /if/ the build system can determine which of those versioned packages to provide.
<jmercouris>
people like to imagine that such functionality would be super useful, and it really wouldn't be
<_death>
we could just design perfect software and be done with it.. no need for versioning
<jmercouris>
it would just be a convoluted overengineered mess
<jmercouris>
I'm not saying that, I'm just saying that your versions should be backwards compatible
frgo has joined #lisp
<jmercouris>
at least with regards to API
<jackdaniel>
Shinmera: if library provides mutliple packages with different sets of symbols it makes sense and it is already solved then, do I misunderstand what you are picking at then?
<jackdaniel>
and if there are multiple packages, then depending on alexandria is good enough and I don't see a purpose of special handling by a build system
<jackdaniel>
you simply USE the correct package version
<Shinmera>
jackdaniel: I'd like to be able to publish a library at version 1 and 2, and have those versions in the package name. Each release ships one of those versions. Now the build system should determine which of those to load (or both) as needed, and people can then safely rely on their versioned package always being available.
<Shinmera>
currently I would have to roll my own version management system because ASDF cannot do it.
<jackdaniel>
so you suggest essentially loading two different systems (potentialy with the same name), so you have a version-per-system?
<Shinmera>
yes
<jackdaniel>
and each system version has different package names?
<Shinmera>
yes
cosimone_ is now known as cosimone
<_death>
if the packages names are different, why not system names?
<Shinmera>
_death: because ASDF already has :version fields and :version constraints
<jackdaniel>
OK, now I understand you better and it makes sense (however I think that having multiple packages for single project is better, having incompatible versions of the system (imo) would justify naming it differently)
Davd33 has joined #lisp
<_death>
does asdf define version syntax?
<Shinmera>
it does
<jackdaniel>
it does but it is indeed not very useful
<Shinmera>
you can only abort the build if the constraint fails and that's it.
<jackdaniel>
you may only specify, that version older than "FOO" is not good enough, and asdf will refuse to load your system
<Shinmera>
you can't even have multiple versions of the same system in your asdf system registry.
<jmercouris>
I agree that should your API change significantly enough, perhaps a new packkage name is in order
<jackdaniel>
jmercouris: nobody argues against that
<jmercouris>
I guess nothing is to stop you from extending ASDF itself
Davd33 has quit [Remote host closed the connection]
<jackdaniel>
the discussion is about multiple-packages-in-single-system vs different-packages-in-different-system-versions
<jmercouris>
if anyone would have the skill, it could be you
<jackdaniel>
asdf is a) constrained with backward-compatibility, b) nightmare to work with due to non-obvious class hierachies and gf specializations
<Xach>
i think it would be nice to make sbcl m-. work with asdf.lisp more precisely
<_death>
that with-upgrading macro..
<Xach>
that is one of the things that irritates me most about looking into asdf behavior
<_death>
*upgradability
<jmercouris>
that makes me super annoyed as well
<jmercouris>
there's that stupid macro with-upgradability or something
<jmercouris>
that you always get jumped to
<jmercouris>
why is this?
<Xach>
jmercouris: it is to allow new asdf to be loaded by old asdf
<jackdaniel>
to be able to update older asdf *in the image* by loading newer one
<jmercouris>
is that necessary?
<jackdaniel>
no :)
pjb has quit [Remote host closed the connection]
<Xach>
i'm sure it was an interesting challenge but the cost seems very steep to me
<Xach>
there are multiple papers and presentations on the topic
<_death>
even if this feature is desired, this macro just translates defun/defgeneric to defun*/defgeneric*
<_death>
why not just write the latter
<jmercouris>
who has control over asdf? only fare?
<_death>
(with an eval-always)
<Xach>
jmercouris: robert goldman is the current maintainer
<jmercouris>
Shinmera: why not contact Robert Goldman with your feature request?
<jackdaniel>
_death: shadowing import of defgeneric / defun would be also an option
<_death>
jackdaniel: yep
<Xach>
jmercouris: I don't think Robert is adding more features at this time.
<_death>
jackdaniel: I'm not sure why it wasn't the first idea popped.. maybe there's a reason that I'm not aware?
<_death>
jackdaniel: then there are other terrible ideas, like this nest macro :/
<jmercouris>
The repository does seem to accept merge requests though, so there is that
<Xach>
some people really like the nest macro (not me, but it's a matter of taste i suppose)
<_death>
it just obscures the structure of code
<jackdaniel>
I would be fine with uiop if it weren't such a pita to deal with (independent from asdf my ass; as preloaded system it is hard to deal with - you must acquire newer version manually)
<_death>
yeah.. there are other things I dislike about asdf/uiop, but.. what can ya do?
lucasb has joined #lisp
kritixilithos has quit [Quit: quit]
<jackdaniel>
well, I'm actively opposing propositions to put uiop in dependencies for systems I maintain
sauvin has quit [Read error: Connection reset by peer]
<_death>
one issue about versions in package names is that you need to inform the user when the version is "finalized", i.e. when the set of names will no longer change
amerigo has joined #lisp
<_death>
maybe it could be something like alexandria.2020.. so users should not use it before 2020
<_death>
alexandria.2100 will have a dwim symbol
<Xach>
a full universal-time would be better and more precise
<Xach>
alexandria.3784563027
<_death>
yeah, and you could use fractions if necessary
<Xach>
oh, good call!
jmercouris has quit [Ping timeout: 250 seconds]
<_death>
one issue with this scheme is that we're bad at deadlines
<_death>
always multiply by pi..
kajo has joined #lisp
akoana has joined #lisp
kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
<_death>
names are only one facet of the versioning problem.. I don't know that there exists a satisfactory solution, other than designing perfect software..
<_death>
and why does alexandria have to grow new functionality? put things in your personal library.. but alexandria could definitely be improved in what it already does
kajo has joined #lisp
<pfdietz>
The reason to stick things in a de facto standardized library is to enable others to more easily understand your code.
EvW has quit [Ping timeout: 250 seconds]
<_death>
pfdietz: ok, but how do good standards come about? I think the way is you have a bunch of approaches and then one prevails and becomes a defacto standard.. CL got lucky with innovation (when they unified a bunch of things)
<_death>
pfdietz: so such a library must be conservative.. and it needs to be stable
<pfdietz>
The benefit arises regardless of how the standardization comes about, so that's a separate issue.
enrio has quit [Ping timeout: 240 seconds]
cosimone has quit [Quit: Quit.]
<_death>
maybe a CDR needs to be evolved that specifies what could go into alexandria.2
<_death>
last CDR is from 2013..
hiroaki has joined #lisp
<jackdaniel>
I'm sure they would be more frequent if implementers were implementing them
<_death>
pfdietz: maybe for understanding a good specification/manual is more useful for understanding
<phoe>
_death: yet another solution for CLtL4 would be to deprecate :USE in DEFPACKAGE now that PLNs are ubiquitous
<phoe>
this way you cannot break code by adding new symbols
<_death>
jackdaniel: well, here I'm talking about a CDR for a new version of a library, not an implementation
<_death>
jackdaniel: it could in principle have different implementations, but you don't need to convince multiple vendors, just the authors of the single library
<sjl_>
phoe: (common-lisp:defun square (x) (common-lisp:* x x)) seems unpleasant.
<galdor>
Xach: the whole :use thing feels silly to me, it's a death sentence if libraries cannot be extended because they might break someone
<galdor>
if someone updates, it's up to them to check the new version
<phoe>
sjl_: that's the obvious downside, yes.
jonatack has quit [Ping timeout: 240 seconds]
<galdor>
I do not like :use anyway, I wish the standard could be updated so that package local nicknames become universal
<_death>
phoe: personally I've no experience with PLNs, and I'm not sure about others.. also I remember criticizing it on theoretical grounds..
<phoe>
galdor: they are universal enough already. From the alive FLOSS implementations, only CLISP needs to implement them, and someday I may do that myself.
<phoe>
_death: I know a few lispers who are using them commonly now that they are available mostly everywhere
<_death>
phoe: are there any large systems that use PLNs
<jackdaniel>
one could argue, that packages are not very flexible and all that use pln and stuff are just workaround over their quirks
<phoe>
mfiano's stuff, I guess
<phoe>
Shinmera's as well AFAIR
buffergn0me has quit [Ping timeout: 250 seconds]
<_death>
phoe: where is the spec for PLN?
jmercouris has joined #lisp
<jmercouris>
jackdaniel: what is your problem with UIOP?
<jackdaniel>
I've said it, read above
<jmercouris>
all you said is that it was a PITA
<jmercouris>
you didn't say why
<phoe>
_death: oh boy, here we go again
<jackdaniel>
no, I've said more, I recommend more careful reading ;)
<jmercouris>
that you have to manually accquire a new version?
<jackdaniel>
that and that it is a preloaded system
<jmercouris>
what does that mean? what is a 'preloaded system'?
varjagg has quit [Ping timeout: 265 seconds]
<copec>
merkle tree based loading by hash
<jmercouris>
that is a thing in Lisp?
<jackdaniel>
common lisp does not specify things like systems
<pjb>
Well, it defines some system construction operators :-)
<jackdaniel>
preloaded system is asdf concept
<phoe>
basically UIOP is already there whenever you load ASDF since ASDF depends on UIOP
<phoe>
and almost literally everything depends on ASDF
<_death>
*a variant of UIOP
<jmercouris>
I don't understand how that is a problem
<phoe>
so you can treat UIOP as preloaded and/or always available that way
<pjb>
Chapter 24. System Construction
* jackdaniel
wishes jmercouris enlightenment to understand, in a meantime he goes to rest
<copec>
jmercouris: CL itself only has packages and symbols
DGASAU has quit [Read error: Connection reset by peer]
<jmercouris>
copec: yes
<jackdaniel>
phoe: preloaded-system is actually a class in asdf
<phoe>
jackdaniel: oh!
<phoe>
pjb: that chapter is funny, it is named System Construction but it doesn't define what a system is or how to construct it
<jmercouris>
so a preloaded-system is a type of system?
DGASAU has joined #lisp
<jmercouris>
I assume that UIOP cannot be loaded as a normal system since ASDF needs it to load systems
<jmercouris>
and I guess that this has some limitations
<pjb>
phoe: definitely. No definition of a system in view.
<jackdaniel>
there is also an immutable-system and such
<jackdaniel>
jmercouris: you are wrong, it can be loaded
<jackdaniel>
you may even load a newer version
<jmercouris>
hm
<jmercouris>
well, I guess it doesn't matter enough to me to know
<jackdaniel>
good!
<jmercouris>
I don't kknow if that is good, but I'm not particularly interested in cl systems as a computer scientist
<jmercouris>
I think of the tools as a means to an end
<jackdaniel>
wow, I believe that's unique
<copec>
A lot of individuals have thought about the concepts that made it into the standard
<copec>
over a long period of time
<jmercouris>
jackdaniel: are you being sarcastic?
bitmapper has quit [Remote host closed the connection]
<_death>
so that's a good candidate for a CDR, and it will be a success - vendors already adopted it :)
<jmercouris>
yes, I know I am just tired and a bit confused
<jackdaniel>
jmercouris: one strategy to deal with inner confusion is not to make statements to avoid risk of sarcasm ,-)
<jmercouris>
I'm not worried about people being sarcastic
jfrancis has quit [Ping timeout: 265 seconds]
<jmercouris>
every truck driver from my village knows how to make 'clever' sarcastic comments
<jackdaniel>
but you may be worried with spreading misinformation due to lack of knowledge (or confusion)
manualcrank has joined #lisp
<jmercouris>
I'm not so worried about confusing _death
<jmercouris>
but in general, I try to avoid spreading misinformation, yes
<jmercouris>
however that doesn't mean I don't make mistakes!
<phoe>
_death: no, I'm not aware of one, and it would be good if one existed.
<copec>
Is there any sort of a shim library/de-facto-standard in between loading packages and build systems?
efm has quit [Ping timeout: 265 seconds]
<copec>
so like, multiple build systems
<copec>
or package systems
<phoe>
copec: yes, and it's called ASDF
<mfiano>
hooks like perform-op
<jmercouris>
what was there before asdf? just loading files from one 'main' file?
<jackdaniel>
defsystem was not uncommon in lisp history
<jackdaniel>
asdf is just one of a few incarnations
<jackdaniel>
i.e mk-defsystem created by Mark Kantrovitz
gravicappa has quit [Ping timeout: 268 seconds]
<jackdaniel>
sbt - simple-minded build template is another (less popular)
<jmercouris>
what makes ASDF better than the others? why is it the 'de-facto' standard?
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<jackdaniel>
I suspect taht some pre-common-lisp implementations could have defsystem builtin
<_death>
asdf used to be a simple, portable library that solved deficiencies in previous solutions
<jackdaniel>
it is a de facto standard because almost all libraries 2000+ use asdf to define their systems
<jmercouris>
_death: what happened to it to make it not so?
<phoe>
_death: now it is a complex, somehow portable library that has invented its own deficiencies to make up for all the deficiencies of older systems that got forgotten
<_death>
the basic human need to grow things beyond its control
<jmercouris>
jackdaniel: well yeah, that which is used extensively is be definition a de-facto standard, my question is *why* is it a de-facto standard? why was it so heavily adopted?
<jmercouris>
_death: can you name some things it grew which in your opinion were not necessary?
<jackdaniel>
I don't know why, popularity is a matter of luck and marketing
<_death>
for each feature you can find a locally good rationale
<jmercouris>
does it have any 'killer-features' as compared to other defsystem tools?
<_death>
maybe you'll be interested in reading a book called Tools for Conviviality
<jmercouris>
_death: given your power of hindsight, which features are, in your opinion, a bad idea
stepnem_ has joined #lisp
<mfiano>
uiop
<_death>
jmercouris: the killer feature is being adopted by implementors
<jmercouris>
hm, not a lot of love for UIOP it seems
<copec>
It seems to have been the first defsystem tool that solved most of the major problems and was usable
<copec>
Like most pieces of software in their respective area that become de-facto
<jmercouris>
is it a winner-take all type system?
<jmercouris>
the 'system' being the CL eco system
<jackdaniel>
since many people do uneducated decisions mere veolcity gives you a big bonus for popularity
<jackdaniel>
like: commit last day vs no changes for last year
<jmercouris>
I'm just wondering if some other tool could usurp ASDF by perhaps providing compatibility but with a new codebase
<phoe>
the question is how do you implement a thing like ASDF without a UIOP beneath it
stepnem has quit [Ping timeout: 276 seconds]
<jackdaniel>
mimicing asdf api for 95% of systems in QL is fairly easy
<phoe>
or rather, without something that will abstract away some of the filesystem and OS details
<_death>
jmercouris: personally I'm avoiding complex use of asdf, so I don't have much trouble with it.. when it annoys me, it's small things
<jackdaniel>
200 lines of code is enough to a) fool ql, b) load systems
<|3b|>
_death: sbcl package-local-nicknames was based on my spec, but i'd say sbcl's docs/implementation is the current 'official' definition
<jmercouris>
_death: I noticed you'd used package inferred systems in d-bus
<jmercouris>
at least I believe it was that library
malfort_ has joined #lisp
* |3b|
isn't sure how much if anything was changed in sbcl's version though
malfort_ has quit [Remote host closed the connection]
<_death>
jmercouris: but I remember reading the old asdf and feeling that I understand most of it.. nowadays I wouldn't bother reading asdf to understand it, just the parts I need to understand
<jmercouris>
my biggest complaint with ASDF is the M-. we had talked about, and the very cryptic error messages when things don't load
<_death>
3b: ok
<jmercouris>
why was the link to your spec considered funny?
<jmercouris>
I don't understand that
malfort has quit [Read error: Connection reset by peer]
<_death>
jmercouris: guess because it's from 2013 or so
<jmercouris>
I'm not incapable of humor, I just don't see how that would be funny in any circumstance
<_death>
jmercouris: when it was not yet polished
<jmercouris>
still, I've never laughed at reading the draft of an essay 'lol! this document in progress!'
<jmercouris>
I just don't get it
<mfiano>
The biggest issue with a CL build system is in a modern internet-connected age, is no missing feature of ASDF - it's packages loaded into a flat, global namespace. RENAME-PACKAGE hacks can only get you so far. If we ever moved beyond Quicklisp to support features such as multiple versioned transitive dependencies, maybe even some files LOAD'ed at runtime, we have some issues that can only really be
<mfiano>
solved by another convention like PLN that needs to be widely adopted by implementors.
<_death>
jmercouris: yes, dbus uses package-inferred-systems... I think that's a good feature of asdf for many kinds of projects
<jmercouris>
mfiano: yeah that's the challenge, not every implementation supports PLN
<jmercouris>
_death: why do you think so? I was under the exact opposite feeling, I would be interested in your rationale
<jackdaniel>
mfiano: beach wrote a specification for global environments which may be different for different code
<jackdaniel>
I find it very appealing from the perspective of creating multi-versioned systems in a single image
<jmercouris>
is it something that could be built on-top of current implementations?
<phoe>
jmercouris: only CLISP of the FLOSS world doesn't support PLNs.
<phoe>
and I plan on fixing this one day
<jmercouris>
phoe: does anyone actually use CLIPS?
<jmercouris>
CLISP*
<phoe>
jmercouris: yes
<jmercouris>
I still don't understand why anyone would, we've had this conversation before
<jmercouris>
I can't imagine using it when SBCL exists
<phoe>
and even if no one did, this only strengthens PLN position
<jmercouris>
can someone explain why the icon is a menorah?
<phoe>
jmercouris: yes, the CLISP manual
<|3b|>
clisp can (usually) be used to build sbcl from just a c compiler if nothing else
<mfiano>
jmercouris: Not every implementation ever will. Some are abandoned, or aren't even conformant yet (GCL)
<mfiano>
But 6 popular choices do, and it's enough
<jackdaniel>
from examples: clisp is the only implementation which works on minix
<|3b|>
and lower memory usage/executable size still matters for some things, also possibly supports some more platforms than the others
<phoe>
mfiano: six? I only counted 5 last time
<jmercouris>
why would anyone use minix in 2019?
scymtym has joined #lisp
<phoe>
why would anyone use CL in 2019
<mfiano>
SBCL, CCL, ECL, Clasp, ABCL...yeah i should learn to count
<phoe>
seriously, it's the same class of stupid questions that we are iterating on now
<jmercouris>
phoe: I'm sorry, but CL can still be ran on modern hardware
<phoe>
jmercouris: so can minix and CLISP
<jmercouris>
Minix offers literally no advantages, but OKK
<phoe>
see your favorite modern Intel CPU for an example of hardware that runs minix by default
<jmercouris>
yes, we are all aware of that
<phoe>
so, let's kindly take this discussion to #lispcafe
<phoe>
mfiano: CLISP will be the sixth when PLNs get implemented there
<jackdaniel>
"it doesn't meet my needs hence it is not needed at all"
<jmercouris>
every CL has some unique feature and reason for existing, in my opinion, the ones for CLISP are not there
<jmercouris>
and it has no justification for continued existence
<|3b|>
jmercouris: regarding humor of that pln spec, if nothing else, the ratio of "how should this work" to "it should work this way" is amusingly high now that i look at it again :p
<mfiano>
CLISP supports arbitrary floating point reprentations. You can calculate pi to the Nth digit if you want just by printing PI with some arbitrary precision. It also has very nice memory profiling support for #'room, and a bunch of other niceties.
iovec has joined #lisp
<phoe>
> and it has no justification for continued existence
<phoe>
what the fuck, seriously, today I learn that software needs to be justified in order to exist
<Xach>
jmercouris: things exist because people who want to work on it continue to work on it, and effort and enthusiasm go a long way (and are not easily conjured up or transferred around)
<_death>
jmercouris: basically each file defines its own package, so you don't feel like you may be stepping on some other module's toes when defining names.. with principled use of :use and :import-from you know exactly the symbols available.. you export just the names you want to export, and it's easy to import them in another file.. factoring a project to use package-inferred-systems sometimes leads you to discover issues of modularity, e.g.,
<_death>
you didn't expect this piece of code to use that functionality from the other piece of code, but it happened because it's too convenient when they define symbols in the same package.. also each file becomes a system you can load, and loads just the stuff it needs.. also, some modules may only use :cl and not import any other stuff.. those are now self-contained modules, where in ordinary use they would start with in-package and the
<jackdaniel>
I find it silly to think that worthwile endavours are directed by reasons for existing -- I wouldn't use CL if I weren't taking the fun factor into account :)
<copec>
clisp compiles on every architecture, it is in every netbsd pkgsrc tree, for instance
<jmercouris>
_death: I guess it could be a very effective way of debugging your own code :-D converting to them and back! I do find it however very unnatural, maybe if I give it a try for 3 months or something I would change my mind though, I have half a mind to try to do so after what you wrote
<jmercouris>
phoe: firstly, I think that is a bit too aggressive, secondly I did not say software needs justification to exist, I simply said that CLISP has no justification to exist
<phoe>
jackdaniel: I kinda agree, a surprising lot of free software exists because someone wanted to write it for no particular reason
<phoe>
jmercouris: CLISP is software, hence you implied that
<phoe>
jackdaniel: this, plus software that scratched someone's itch and then grew, plus some happy accidents, plus someone's personal frustrations
<phoe>
and we have a pretty huge chunk of free software
<_death>
jmercouris: it also makes it easier to thing about interfaces explicitly, since you have to decide what to export and from where
<_death>
*think
<jmercouris>
phoe: so what, why does that make you so angry? it is my belief that software *should* have a purpose for existing, even if that purpose is the amusement of the authors. When we are talking about CLISP as an implementation though, if it has no greater purpose beyond the author's amusement, why should the community care if it implements PLN or not?
<phoe>
> if it has no greater purpose beyond the author's amusement
<jackdaniel>
jmercouris: the one who is agitated is you. clisp has multiple unique featues, one is that it is the most portable
<jmercouris>
_death: CL has made me very lax with that regard, I used to consider that a lot more back in high school when programming in basic :-D
<jackdaniel>
second is that it is the only one I'm aware of which implements JIT (not ahead of time compilation)
<jmercouris>
jackdaniel: I'm not angry at all, phoe was the one who swore
<phoe>
jmercouris: falsum sequitur quodlibet
<jackdaniel>
I'm saying taht you are agitated and "amused" why people do use clisp
<jmercouris>
I didn't say that at all
<phoe>
CLISP likely exists to conform to ANSI CL, for me that is a purpose good enough
<_death>
I think clisp is a cool implementation.. it has a good manual, quite portable, the code is not hard to understand.. was the first implementation I used
<jackdaniel>
note that you've brought the topic that "you don't understand why people do use clisp"
<jmercouris>
I just think it is pointless
<jmercouris>
naja, seid nicht so sauer!
<phoe>
it's trivial to neglect the upsides of any piece of software and, from that point on, proceed about how it has no right to exist
<jmercouris>
right != justification
<phoe>
s/right/justification/
<Xach>
Is anyone here present going to SBCL 20 next week?
<jackdaniel>
one could argue, that next browser has no real justification to exist ,-)
<jmercouris>
well, they would be 100% correct :-D
<phoe>
I could do a low kick and start rambling about how nextbrowser is pointless purely for the purpose of demonstrating what I just said, but that's as pointless as rambling about clisp
<pjb>
jmercouris: Why would the lack of diversity in an ecosystem be bad, in 2019?
<jmercouris>
pjb: I didn't say that!
<pjb>
Just to explain why it's importan to run minix and other systems!
<pjb>
+t
<jmercouris>
phoe: well, saying you could do a low kick and then not doing it is effectively the same thing :-D
<_death>
only clisp has a menorah.. which will be useful soon
<jmercouris>
will the menorah light our way after the apocalpyse?
<phoe>
OK then, clisp exists e.g. to increase diversity in the CL ecosystem
<pjb>
jmercouris: When I'll be retired, I will switch to openbsd instead of linux…
<phoe>
purpose? purpose. OK, let's move on
<jmercouris>
pjb: start today! BSD > Linux
<pjb>
Customers…
brettgilio_ has quit [Ping timeout: 250 seconds]
orivej has quit [Ping timeout: 252 seconds]
ArthurStrong has quit [Quit: leaving]
orivej has joined #lisp
jmercouris has quit [Remote host closed the connection]
Jesin has quit [Quit: Leaving]
malfort has joined #lisp
Jesin has joined #lisp
<mister_m>
does anyone know if the SBCL 20 talks are going to be put online?
ebrasca has joined #lisp
amerlyq has quit [Quit: amerlyq]
kajo has quit [Remote host closed the connection]
libertyprime has quit [Remote host closed the connection]
kajo has joined #lisp
malfort has quit [Remote host closed the connection]
malfort has joined #lisp
amerlyq has joined #lisp
Fare has joined #lisp
travv0 has joined #lisp
Fare has quit [Remote host closed the connection]
shifty has quit [Ping timeout: 268 seconds]
ljavorsk has joined #lisp
jfrancis has joined #lisp
quazimodo has joined #lisp
jonatack has joined #lisp
pilne has joined #lisp
EvW has quit [Ping timeout: 245 seconds]
Bike has quit [Quit: Bike]
uplime is now known as Rudolph
Guest75462 has quit [Read error: Connection reset by peer]
Guest75462 has joined #lisp
rgherdt has quit [Remote host closed the connection]
rgherdt has joined #lisp
amerlyq has quit [Quit: amerlyq]
bitmapper has joined #lisp
dim has quit [Ping timeout: 264 seconds]
zotan has quit [Ping timeout: 240 seconds]
dim has joined #lisp
omarish has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
EvW1 has joined #lisp
varjagg has quit [Ping timeout: 246 seconds]
efm has joined #lisp
efm has quit [Ping timeout: 265 seconds]
rgherdt has quit [Ping timeout: 276 seconds]
random-nick has quit [Ping timeout: 250 seconds]
cosimone has quit [Quit: Quit.]
malfort has quit [Remote host closed the connection]
malfort has joined #lisp
malfort has quit [Remote host closed the connection]
malfort has joined #lisp
malfort has quit [Remote host closed the connection]
malfort has joined #lisp
malfort has quit [Remote host closed the connection]