rogersm has quit [Read error: Connection reset by peer]
rogersm has joined #commonlisp
icer has joined #commonlisp
Mandus has joined #commonlisp
Mandus has quit [Ping timeout: 268 seconds]
Mandus has joined #commonlisp
icer has quit [Ping timeout: 264 seconds]
taiju has quit [Ping timeout: 252 seconds]
Mandus has quit [Ping timeout: 252 seconds]
Mandus has joined #commonlisp
Bike has joined #commonlisp
pranavats has left #commonlisp [#commonlisp]
pranavats has joined #commonlisp
Mandus has quit [Ping timeout: 252 seconds]
Mandus has joined #commonlisp
taiju has joined #commonlisp
molson has joined #commonlisp
azimut has joined #commonlisp
Guest-liao has joined #commonlisp
CrashTestDummy3 has joined #commonlisp
Bike has quit [Quit: Connection closed]
peterhil has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 252 seconds]
akoana has left #commonlisp [#commonlisp]
peterhil has quit [Ping timeout: 264 seconds]
Mandus has quit [Ping timeout: 252 seconds]
Mandus has joined #commonlisp
azimut has quit [Remote host closed the connection]
lottaquestions has joined #commonlisp
Bike has joined #commonlisp
Guest-liao has quit [Ping timeout: 256 seconds]
peterhil has joined #commonlisp
waleee has quit [Ping timeout: 265 seconds]
waleee has joined #commonlisp
<sukaeto>
late to the conversations, but I (think I) understand what beach is saying re: binding
<sukaeto>
the spec overloads the term
<sukaeto>
they sometimes use it the way a compiler writer would - as in "this variable is bound to this value"
<sukaeto>
they also use it in the logical sense - as in "this variable is not free in this form. It is bound."
<sukaeto>
in the second sense, you're saying the variable is bound by the *context*. (progv '(*x*) () (boundp '*x*)) <- *x* is bound in the sense that it won't be susceptible to variable capture, no matter where that progv is put
<sukaeto>
but not in the sense that it has a value associated with it
tyson2 has quit [Remote host closed the connection]
gaqwas has quit [Ping timeout: 268 seconds]
gaqwas has joined #commonlisp
waleee has quit [Ping timeout: 245 seconds]
<beach>
Good morning everyone!
Mandus has quit [Ping timeout: 264 seconds]
<beach>
sukaeto: Thank you. Good to see that someone understood what I was trying to say.
Mandus has joined #commonlisp
taiju has quit [Ping timeout: 265 seconds]
Guest-liao has joined #commonlisp
Bike has quit [Quit: Connection closed]
lottaquestions has quit [Ping timeout: 264 seconds]
winning-luser has joined #commonlisp
nature has quit [Ping timeout: 245 seconds]
taiju has joined #commonlisp
Guest-liao has quit [Ping timeout: 256 seconds]
robin has quit [Ping timeout: 265 seconds]
Guest-liao has joined #commonlisp
robin has joined #commonlisp
Patternmaster has quit [Remote host closed the connection]
johnjay has quit [Ping timeout: 264 seconds]
johnjay has joined #commonlisp
semz has quit [Ping timeout: 252 seconds]
aartaka has quit [Ping timeout: 265 seconds]
Mandus has quit [Ping timeout: 245 seconds]
robin has quit [Ping timeout: 245 seconds]
Mandus has joined #commonlisp
jasom has quit [Ping timeout: 245 seconds]
semz has joined #commonlisp
Patternmaster has joined #commonlisp
jasom has joined #commonlisp
robin has joined #commonlisp
jealousmonk has quit [Quit: sleep]
Guest-liao has quit [Ping timeout: 256 seconds]
jasom has quit [Ping timeout: 264 seconds]
lisp123 has joined #commonlisp
<lisp123>
Are :before, :after :around method qualifiers used a lot in practice?
<hayley>
Yes.
<hayley>
You almost always use :AFTER methods on INITIALIZE-INSTANCE, for example.
<lisp123>
I see, thanks
Guest-liao has joined #commonlisp
jasom has joined #commonlisp
<beach>
lisp123: You can figure out the answer by checking for those in existing code. So if I take SICL for instance, we seem to have 25 :before, 31 :after, and 53 :around.
<beach>
That's in 130kLOC or so.
<beach>
So that's what? One per 1kLOC or so?
<lisp123>
Interesting statistics, thanks. 1 per 1k sounds reasonably frequent
<beach>
What is the reason for your question?
<beach>
Cluffer has less than 3kLOC and there are 12 :before and 7 :after. No :around.
<lisp123>
I was wondering how useful they were since you could also bundle some of that code into the primary methods. In Sonja Keene's book, they note it as useful for code reuse (this was for :before and :after at least), where more specific classes can do some additional side effects on top of the primary method, either before or after
<beach>
So that's 1 per 100LOC.
<beach>
lisp123: When I taught a small class at the university of Auckland, I showed the students how, if you don't have auxiliary methods, then you might sometimes have to change the interface to obtain certain optimizations, so that's a no-no for stable APIs. They were totally convinced.
<beach>
lisp123: So you can obtain the same effect with only primary methods, but you can't then also have your software modular.
<beach>
You probably haven't seen that issue, since I bet your code is fairly small, and you write mainly for yourself.
<lisp123>
Yes, I don't use much state at all or have large code at all, hence wanted to ask what was used in bigger projects.
<lisp123>
So basically, the primary method gives the primary interface which clients use, and then you add some stuff before/after/around it?
<beach>
Then you just have to take my word for it, that auxiliary methods are a must for larger projects, and especially for stable libraries.
<lisp123>
Thanks!
<beach>
Yes, one common thing to do is to have the library define an :around method that can intercept the client call, and do special things then.
<beach>
Like return a cached value for instance
<lisp123>
Ah very cool
<beach>
Common Lisp has a lot of that kind of stuff, i.e., features that are almost never used, but when you need them, you really can't do without them. Since other languages often don't have these features, they have to sacrifice modularity, maintainability, performance, etc.
<beach>
For instance: custom metaclasses, custom method combinations, custom function types, reader macros, macros, etc., etc.
<lisp123>
Yes, its very well thought through. I basically assume anything in CL is there for a very good reason
<beach>
So the incorrect conclusion made by people who don't like Common Lisp is that, since these features are rarely used, they aren't really useful. Very wrong!
<lisp123>
Yes, and also sometimes, if they don't understand it, it becomes bad automatically
<beach>
Indeed.
Mandus has quit [Ping timeout: 245 seconds]
<jeosol>
beach: I do agree that for large projects, those auxilliary methods are a must. I application have non-trivial hierarchy and those :before, :after methods do help to implements things clearly.
Mandus has joined #commonlisp
<jeosol>
beach: these CLOS features are something I rely on
<jeosol>
I am you mention maintainability and modularity of the codebase, these are important for nontrival programs, otherwise, you get a mess that no one wants to deal with or maintain
<hayley>
I once used a lot of :after methods for a "reactive" programming style, but then hurt my head on concurrency. But I suppose that's orthogonal to the utility of auxiliary methods (though having behaviour in one place makes modelling marginally easier).
dec0d3r has joined #commonlisp
taiju has quit [Ping timeout: 252 seconds]
<beach>
jeosol: Exactly!
<beach>
Also, Common Lisp is designed to make these features easy to implement. There is no need to have a committee that votes on new syntax. It can all be done in the form of library code.
<beach>
Once the FUNCALLABLE-STANDARD-OBJECT was invented, the rest is straightforward.
<beach>
Not "easy" perhaps, but straightforward.
<jeosol>
beach: yes. I have coded in C++, not a huge program, but it was a pain. The CL project I have been working for a while, is way larger, but the logical and physical design is much easier to manager.
<beach>
I can very well see that.
<jeosol>
it's hard to make other see, the fact you don't have to fight the language and it does help you all the way
<jeosol>
not worrying about excessive compile/link-time issues with C++ header files otherwise, your build takes forever
<beach>
Right, people are so used to "fighting the language" and they think it's normal.
<jeosol>
beach: you are so right - this is something I have tried to explain to others why I use CL
<jeosol>
I am like the language is a joy to work in. I am only concerned about the concepts I am trying to implement, i have uniform syntax and don't have to worry about a specific, different language to use a given point
<beach>
My experience is that it doesn't work to explain. So I quit doing that.
<jeosol>
beach: very true, unfortunately, I still have to do that in the next few months while I discuss with others
<jeosol>
regarding the project.
<beach>
I wish you good luck. Perhaps you will find a better way than I have been able to come up with.
<jeosol>
reading large-scale C++ software design, the author mention a project that was taking the order of weeks to build - large software indeed, but with our incremental development, we get our changes integrated right there
<jeosol>
beach: I don't think so beach, I have tried the last few weeks and evening compiling some tidbits here and there to show how things are easier in CL
<beach>
While not discussing large-scale, the paper by Hudak and Jones is great.
<lisp123>
jeosol: Although "uniform syntax" sometimes can be a misnomer. Its true the basic syntax of lisp languages are relatively simple, But then, with special forms or certain macros, complexity creeps in
<beach>
lisp123: But it is nothing like the complexity of the surface syntax of most languages.
<jeosol>
I haven't even talked about macros with them because I use that to generate a lot of functions at compile-time so I don't have to code them by hand - a lot of my functions are generated this way (still have to estimate the amout, not sure how to do that)
<lisp123>
beach: Yes agree
<jeosol>
lisp123: good point, I was simplifying things by "uniform syntax". What I mean is that there are way fewer language syntax things I have to worry about - but it kind of goes to the fighting with the language do what you want, or just focus on the concepts you want to implement
<jeosol>
for me, it's been mostly the latter
wyrd has quit [Quit: leaving]
<jeosol>
beach: I should really look at the paper by Hudak and Jones
<lisp123>
Honestly, one of the issues for me initially was 'how can lisp be so simple and yet do what I want it to' -> especially with english-named variables and functions, it feels like reading pseudocode at times, but it actually works and works well
<jeosol>
lisp123: indeed, this simplicity is what got me to using lisp.
<lisp123>
jeosol: Yep agree. Just wanted to point it out since its worth mentioning to non-lispers that there is some syntax down the track that requires memorisation (but its more to do with having forms in certain places vs. punctuation etc)
<jeosol>
I work with optimization, and at the time (grad school) working with matlab (memory and speed issues) and C++ (moved because of speed), I saw a CL implementat of genetic algorithm - wow, it was so succint, the guy had my whole C++ header files and CPP files in a few pages of his theses
<jeosol>
I was sold, because of time, I used C++ to finish, but started looking into to CL then.
<lisp123>
jeosol: I still feel a bit uncomfortable reading what appears to be very simple code and it works. It feels like its _meant_ to be more complicated. Hopefully that misperception finally goes to rest as I use Lisp more and more.
<lisp123>
Now my biggest problem is I have no desire to program in other languages :-/
<hayley>
Is it a problem?
<jeosol>
beach: the finding better way is what I am trying to do - I don't have same background/expertise with CL but gotten more CL related books to read over the years.
<jeosol>
hayley: The problem is people don't like to use it or complain, it's an old language etc
<beach>
lisp123: Paul Wilson describes Lisp as having a 2-level syntax. One is the syntax defined by sequences of characters, and the other is the syntax at the S-expression level.
taiju has joined #commonlisp
<jeosol>
In a previous shop mostly using python, I got complaints for using CL ( for personal tasks) and for even using emacs editor when most people used vscode
<jeosol>
beach: good point. Thanks for that
<lisp123>
hayley: Work wise it can be off putting to others who don't use Lisp, so I need to bite my lip sometimes. Also I'm demotivated on some of their projects, if they are using python or something else, I don't feel the desire to improve their code (why not just do it in Lisp)
<jeosol>
lisp123: haha
<lisp123>
beach: That's a good way to put it. Hadn't heard of it before
kakuhen_ has joined #commonlisp
<jeosol>
well it was an ML/AI shop, so the use of python is sort of needed. But some of the older symbolic logic AI code, were CL (using SBCL and lispworks) but no one except a programmer from the 80s and myself knew lisp.
kakuhen__ has joined #commonlisp
<jeosol>
some good points on the thread regarding CL vs other languages. I know PG has this whole CL superiority thing, and once told me (when I was starting) to use clojure instead, that it's a modern lisp, but after I mentioned I need/was using CLOS, he then conceded that I should stick with CL
<lisp123>
jeosol: Yeah, my biggest gripe is when people say why are using Emacs over VSCode. Of all editors, VSCode might be the worst. I rather use notepad at this point (at least I assume there is no telemetry there)
<jeosol>
like beach, having language fights is not something I am interested in, but I have often needed to explain why CL was chosen for a project ...
<jeosol>
lisp123: haha, notepad
kakuhen has quit [Ping timeout: 264 seconds]
<lisp123>
There was someone here a while back programming CL in notepad, it was inspirational
<jeosol>
my OS and tools are: Linux (OS), Emacs + Slime + Paredit. I know there is sly and other emacs variant that my improve my workflow, but I just stuck with these
kakuhen_ has quit [Ping timeout: 264 seconds]
Nilby has joined #commonlisp
<jeosol>
beach: is the Paul Winston comment from his and Horn's book or paper . It is ok, if you don't remember
<hayley>
"For those who object to this use of functional languages, we suggest reading the rest of this paper as if it were about a video game."
aartaka has joined #commonlisp
<beach>
Wilson, not Winston.
kakuhen__ is now known as kakuhen
<beach>
... of "Allocator survey" fame.
<beach>
Yes, that's the paper.
<beach>
I spent a year with Paul Wilson and his research group at the University of Texas at Austin. I am not sure whether he published anything about the 2-level syntax. He may just have told me.
<jeosol>
beach: Apologies, I mixed up the names and went to pick up the Winston book from the shell
<jeosol>
*shelf
<jeosol>
beach: I will be interested in a collection of relevant references like the Hudak ones, references that talk about building programs, nontrivial ones in CL. I know this task is not specific, but I am just trying to study these more
<jeosol>
if only to help me put a name to the "syntax simplicity" issue as discussed above
<jeosol>
beach: You were at UT, during the summer months?
<beach>
An entire year.
Spawns_Carpeting has quit [Ping timeout: 268 seconds]
<jeosol>
beach: interesting. You witnesed the Texas summer heat
<jeosol>
beach: skimmed the Hudak and Jones paper - very interesting. Thanks for suggesting this
<beach>
Sure.
<beach>
Austin buses are air conditioned, and so are all the buildings.
Qwnavery has quit [Quit: WeeChat 3.3]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
icer has joined #commonlisp
pve has joined #commonlisp
selwyn_ has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
kdlv has quit [Ping timeout: 252 seconds]
kdlv has joined #commonlisp
Guest-liao has quit [Ping timeout: 256 seconds]
Guest-liao has joined #commonlisp
ski has quit [Ping timeout: 252 seconds]
selwyn_ has quit [Quit: Leaving]
lisp123 has joined #commonlisp
ski has joined #commonlisp
<beach>
UT Austin is also where J Moore (ACL2) and Gordon Novak (AKCL) work. And it was where Dijkstra had a chair position while I was there.
<beach>
I can't think of a better and Lispier way to spend a sabbatical year.
<beach>
Paul Wilson and Donovan Kolbly implemented a Dylan variant called RScheme.
<lisp123>
beach: Do you talk to J Moore sometimes?
<lisp123>
Seems like ACL is one of the biggest lisp projects out there
rain3 has joined #commonlisp
<beach>
Not anymore no.
rain3 has quit [Ping timeout: 265 seconds]
<beach>
But I remember that his office was as large as a small Paris apartment.
hendursa1 has joined #commonlisp
<lisp123>
Wow, thats nice
hendursaga has quit [Ping timeout: 276 seconds]
<beach>
lisp123: So the Common Lisp code you write is for your dayjob?
<lisp123>
beach: No, I use org mode at work for knowledge management (quite useful as a database). I experimented with Common Lisp at work, but the problem is if I leave, what the next person will do
<lisp123>
The other staff use python (we are not a tech company, in investment management, but cannot afford full time developers, so do a bit here and there).
<beach>
Learn Common Lisp? If they are serious developers they should have learned it already.
<beach>
I see.
<lisp123>
I just interviewed for a role at my old firm, which is much larger and has a dedicated tech team. It will be partly project management of their work...however again, Python and Java are the languages of choice there
<beach>
Choices are made by people, often ill-informed people. So choices can change.
<lisp123>
I will definitely try to do that! I think we will see more usage of CL going forward, many other languages already seem to be using similar concepts, so its just a question of jumping across
<beach>
To me, the main thing that the Hudak and Jones paper shows, is that the cost of teaching the developers a new language is ridiculously small compared to the waste of time that an inappropriate language creates.
kdlv has quit [Ping timeout: 252 seconds]
<lisp123>
That seems to make sense
<beach>
Well "shows" is a bit strong, so "suggests" may be more appropriate.
<lisp123>
However, some people are hard in their ways. That's the bigger issue sometimes
<beach>
Such people have no place in software development.
<lisp123>
I agree. And that's why there's a lot of suboptimal software flying around
<beach>
Carol Dweck calls it "closed mindset" and it is very dangerous for software development.
<lisp123>
Agree 100%
<lisp123>
Bad decisions compounded onto other bad decisions to justify them, can take away millions very quickly
<lisp123>
I'd be very curious to have insight into how big tech firms work (FAANGS). From all accounts, there are a lot of closed mindsets there, and a lot of wasteful development
<pve>
Is the "Relational Lisp" mentioned in the Hudak and Jones paper based on CL? Some searching suggests it might be the case..
<lisp123>
From what I have read online, they have become quite political. Which is interesting, because they also have some cutting edge technologies & software (partly now due to the massive R&D budget they have)
<Nilby>
I'm afraid I've developed a closed mindset about non-Lisp software.
<beach>
pve: I don't know. When I discuss this paper with students (for instance) I don't mention particular languages. I concentrate on what I think is the main lesson of the paper, namely that there can be a factor 20 difference in productivity depending on the language, and that's huge so should be taken into account in projects.
<pve>
beach: hmm, ok I see.. that is pretty significant
<beach>
pve: The way I put it is that a 5-year project could be completed in 3 months instead.
cosimone has joined #commonlisp
<pve>
beach: That's an interesting way to put it.
<beach>
So you can spend 4 years and 6 months training the staff on the new language. Of course, the paper shows that productivity can be obtained after two weeks.
<beach>
Er, 4 and 9
<Nilby>
But given all that time saved, who can resist doing something more ambitious? I can't.
<pve>
beach: 3 months vs. 5 years is so incredible that, when first hearing it, people's first thought (and response) must be something along the lines of "There's no way that's possible".
<beach>
Nilby: So you are saying we should try to be as little productive as possible to limit our level of ambition?
<mfiano>
I can confirm the 2 week figure
<beach>
pve: Right, so in the next phrase (to my students), I say that even if they don't believe a factor 20, even a factor 2 or a factor 1.2 is big enough to justify taking it into account.
<mfiano>
I came from several years of Python experience, which is known to boast "rapid application development". I read a Lisp book for a week, got dirty with some code for another week, and at that point I was already faster and writing better code.
<beach>
But that right now, decisions about languages are based on what existing programmers know.
<beach>
mfiano: There you go. That is consistent with the paper.
<Nilby>
beach: I don't know what to do about it, but nearly every time I do something in CL vs some blub-lang, I do it with 10x more features or more ambitious design.
<mfiano>
I used to do the same thing.
<mfiano>
What helped was to take a week, month, or even longer to write a complete design document before a line of code is even written.
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
<Nilby>
Except when I used to do boring stuff for work, then I would just put it off until the last hour before it's due, or do it in the first few hours then goof off for a week. Doing it in CL vs C++ allowed me to do that for years.
attila_lendvai has joined #commonlisp
<Nilby>
beach: But, I know non-lazy people, e.g. like you and Shinmera actually use that time to be more productive.
Guest-liao has quit [Quit: Client closed]
lisp123 has quit [Ping timeout: 268 seconds]
aartaka has quit [Remote host closed the connection]
frgo has joined #commonlisp
<pve>
My first task related to CL was porting an NLP application (between 50-100 kloc) from Allegro CL to CMUCL during a summer job. I remember it took me about a month to get comfortable with slime (already knew emacs) and complete the port, even though I didn't really know what I was doing at the time. It was mostly mechanical work.
<hayley>
There have been similar results with TLA+ (which also relates to having a good design process). "Engineers from entry level to principal have been able to learn TLA+ from scratch and get useful results in two to three weeks, in some cases in their personal time on weekends and evenings, without further help or training."
dec0d3r has quit [Remote host closed the connection]
Guest-liao has joined #commonlisp
<pve>
I should also mention that I was quite open to the idea of learning CL. Later, I saw other people join (to work on components written in Java) who were effectively unable to learn CL because they weren't open to the idea (i.e. they resisted).
<pve>
I used to joke that they had been corrupted by Java :)
<pjb>
lisp123: In general, I try to leave :before :after and :around methods to client code, but they can be very useful to implement some mechanisms. For example using an :around method to implement a mutex that will be automatically applied to the primary methods even if overridene.
<pve>
(to their faces, not behind their backs)
<beach>
pve: The "closed mindset" is a very powerful psychological force, so incredibly hard to combat.
<Nilby>
Sometimes I've cured people of the "closed midset", but some people are incurable.
<beach>
Yes, it is possible to change, but very hard.
lisp123 has joined #commonlisp
<pve>
beach: Yeah, no kidding! I (not an expert) spent a great deal of time showing CL, slime and interactive development to people there, but it just didn't stick. One guy did get it though, so there's that.
<beach>
Right, one has to settle for a modest success rate.
<beach>
I estimate that, during our 15 years of using Common Lisp in our teaching , on the average around 5 our of 125 annual students understood the message.
<beach>
But hey, that's 75 students already!
hendursa1 has quit [Remote host closed the connection]
hendursa1 has joined #commonlisp
<Shinmera>
Nilby: I object to being called a non-lazy person
<beach>
Right. Laziness is a virtue in software development.
<Nilby>
Shinmera: Sorry. I know laziness is efficiency.
<Nilby>
Shinmera: How about non-un-productive ?
<Shinmera>
I'd say I'm a person that somehow ends up making things sometimes :)
<Shinmera>
Not sure if there's a snappy moniker for that though.
<hayley>
Conscious laziness?
<Shinmera>
Anyway, back to Lisp
<Nilby>
^ that's probably why
lisp123 has quit [Ping timeout: 245 seconds]
<hayley>
Similar is that Max Stirner once wrote that everyone is an egoist, but few are "conscious" of it and make use of it. So I'd say "conscious laziness".
kdlv has joined #commonlisp
<pjb>
Sometimes the message is understood later. So the success count may be higher than you think (eventually).
hendursa1 has quit [Remote host closed the connection]
hendursa1 has joined #commonlisp
<madnificent>
Gnuxie: Adding that to the list things to check out. Thanks :D
gaqwas has quit [Read error: Connection reset by peer]
gaqwas has joined #commonlisp
<madnificent>
Shinmera: I'll check out Luckless. I'm looking for/at benchmarks and info now but may not find the benchmarks you mention. If you have a direct link, that'd be rad. I'm not sure what I'll learn exactly but I hope it will give me a rough idea on what to test for.
hendursa1 has quit [Remote host closed the connection]
hendursa1 has joined #commonlisp
scymtym has quit [Ping timeout: 252 seconds]
<madnificent>
thank you!
Guest-liao has quit [Ping timeout: 256 seconds]
<madnificent>
So, 42nd-at-threadmill would be an improved version of what is in luckless?
<mfiano>
I mean, they're both hash tables if that's what you're asking
<madnificent>
The readme states that the implementation is based off NonBlockingHashMap and its Common Lisp port in Luckless. But perhaps that's more "we read it".
<mfiano>
It's based off more than that
<madnificent>
understood
<mfiano>
"Improved" I suppose would depend on usage patterns, machine, and operating environment.
Guest-liao has joined #commonlisp
<mfiano>
hayley says it may have a bug and not recommended for use yet, but I still don't see that mentioned in the readme
<madnificent>
I should care about safety first, so by the time we're at the element of speed, this may be better known.
hendursa1 has quit [Remote host closed the connection]
hendursa1 has joined #commonlisp
voltron has joined #commonlisp
voltron has quit [Read error: Connection reset by peer]
wyrd has joined #commonlisp
voltron has joined #commonlisp
scymtym has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
voltron has quit [Remote host closed the connection]
igemnace has joined #commonlisp
random-nick has joined #commonlisp
rusua has joined #commonlisp
gaqwas has quit [Remote host closed the connection]
gaqwas has joined #commonlisp
zacque has joined #commonlisp
cage has joined #commonlisp
Guest-liao has quit [Ping timeout: 256 seconds]
<madnificent>
mfiano: I should have asked this way earlier. mu-cl-resources has a lot of multithreading going on in suboptimal ways too. These hash-tables might make a difference for the caches it uses.
* madnificent
should spend time cleaning up multithreading in there too
selwyn_ has joined #commonlisp
selwyn_ has quit [Remote host closed the connection]
winning-luser has quit [Quit: zzz]
theBlackDragon has quit [Remote host closed the connection]
tfb has joined #commonlisp
<hayley>
madnificent: Another difference is that resizing in Threadmill is not lock free, whereas it is in Luckless.
<hayley>
I basically made up the resize logic on the spot, so I'm not so sure it's correct...but it should be, based on what I watched about NonBlockingHashMap.
<hayley>
I think there might be a bug because decentralise2 sometimes drops like 1 in 10 million messages when using Threadmill, but not any other table. I'll test again tomorrow.
Bike has joined #commonlisp
Guest-liao has joined #commonlisp
<hayley>
Really, I do need to get my shit together w.r.t Telekons projects. There is also the concurrent-hash-tables portability library (which is portable in that it handles Luckless, Threadmill, and a table with sharded locks), but I haven't thought of a way to specify which table implementation to use at system load time.
<madnificent>
hayley: for mu-cl-resources the drops wouldn't be the worst. this is about caching so if a cache isn't stored it'll be calculated again at another time. not clearing would be more challenging.
tyson2 has joined #commonlisp
<hayley>
Sure. It's a bug to me though.
<madnificent>
and a hard to debug one at that
<hayley>
And FWIW I don't exactly know that "it drops values randomly"; I only know that decentralise2 drops messages, which might or might not have to do with the table dropping values.
<madnificent>
i kind-of feel sorry you'll have to hunt for that
<hayley>
It might not even have to do with the table at all - just going faster with concurrent programs might lead to more opportunities to expose a bug.
<hayley>
Oh, well, such is life. And I intend to simplify the code around the table, so we'll get to find out where the bug lays.
<hayley>
But, as Knuth said, "I have only proven [some of my code] correct, not tested it."
<madnificent>
also, i failed to find the time to further check out your work, but we're running a company around distributed web tech. mostly knowledge sharing with linked data, which is what ActivityPub is built on. we also co-run ipfs-search. if these 90's buzzwords or hipster-tech ring a bell and relate to your work do ping.
theBlackDragon has joined #commonlisp
<hayley>
I guess so - Netfarm is what you'd get if you gave IPFS schemas and some methods, and I've written a few (not very nice) things about the Fediverse.
<hayley>
But it's not going anywhere, so don't rush. I don't work on it these days.
<madnificent>
so we do a lot in terms of letting people define knowledge in a distributed fashion and sharing that. for instance, adding data to legislation. we have no clue what they'll add, but we can make sure they'll understand each other after the fact. that seems an important piece for distributed knowledge. would love to read about your negs as it helps me see faster where you want to go to :D
<hayley>
Okay, I wrote something about protocol translation (rather than schema translation, which looked hyped at one time), but it's not very good.
<mfiano>
hayley: If it's the table it shouldn't be difficult to produce an isolated test for that
<hayley>
mfiano: Yeah, probably. Wouldn't hurt to port the Luckless tests to my portability library.
<mfiano>
it might also be worthwhile to add options to disable avx2 etc
<mfiano>
basically, get the minimal code that exhibits the error
<hayley>
Right. I only use one AVX2 instruction (VPBROADCASTB) with 128 bit code, and I hope that's not buggy :)
<mfiano>
Also i would read conditionalize that library. Having something SBCL specific isn't much use, as its a moving target as it is lately
* mfiano
notices truly-the etc expected to exist at read time
<hayley>
Yes, I am planning to do that somehow.
<hayley>
It's SBCL-specific for the foreseeable future (no SIMD anywhere else?) so I would advise using Luckless instead.
<hayley>
The only thing going for Threadmill, now that Luckless is catching up in performance, is that I find Threadmill to work better with a lot of "churn" in adding and removing new mappings.
icer has quit [Ping timeout: 245 seconds]
<hayley>
The SIMD probing lets you skip over a lot of dead entries (which I can't reuse sadly - tried it, proof doesn't hold up), so you can run with a larger load factor and probe length with no problems.
azimut has joined #commonlisp
tfb has quit [Quit: died]
lisp123 has joined #commonlisp
rusua has quit [Quit: Connection closed for inactivity]
notzmv has quit [Ping timeout: 252 seconds]
<lisp123>
pjb: Thanks, that makes sense (leaving it client code) and definitely some advanced use cases, I guess not for daily use otherwise
makomo_ has joined #commonlisp
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 264 seconds]
amb007 has joined #commonlisp
makomo_ has quit [Ping timeout: 265 seconds]
notzmv has joined #commonlisp
<stacksmith>
Good morning
Spawns_Carpeting has joined #commonlisp
makomo_ has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
zacque has quit [Quit: Goodbye :D]
Guest-liao has quit [Quit: Client closed]
<beach>
Hello stacksmith.
Psybur has joined #commonlisp
icer has joined #commonlisp
waleee has joined #commonlisp
igemnace has quit [Ping timeout: 265 seconds]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 265 seconds]
lisp123 has quit [Ping timeout: 265 seconds]
Lord_of_Life has joined #commonlisp
makomo_ has quit [Ping timeout: 252 seconds]
igemnace has joined #commonlisp
nature has joined #commonlisp
Psybur has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
dec0d3r has joined #commonlisp
waleee has quit [Ping timeout: 260 seconds]
lisp123 has quit [Ping timeout: 260 seconds]
euandreh has quit [Quit: WeeChat 3.2]
euandreh has joined #commonlisp
euandreh has quit [Client Quit]
euandreh has joined #commonlisp
Nilby has quit [Ping timeout: 245 seconds]
Bike has quit [Quit: Connection closed]
gaqwas has quit [Read error: Connection reset by peer]
gaqwas has joined #commonlisp
mortemeur has joined #commonlisp
notzmv has quit [Ping timeout: 260 seconds]
Bike has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Client Quit]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
lisp123 has joined #commonlisp
<lisp123>
Is there a way to get the compiler notes from SLIME (that pop up when one C-c C-k's a file) during the ASDF load-file process?
jealousmonk has joined #commonlisp
<scymtym>
the *slime-compilation* buffer generally contains printed representations of these conditions (and can visit the corresponding source locations)
<jackdaniel>
I think that there is slime-asdf contrib
<jackdaniel>
perhaps that helps
tyson2 has joined #commonlisp
<lisp123>
jackdaniel: Thanks
<lisp123>
scymtym: Will check that out too
rain3 has joined #commonlisp
rgherdt has joined #commonlisp
aartaka has joined #commonlisp
icer has quit [Ping timeout: 245 seconds]
waleee has joined #commonlisp
lisp123 has quit [Quit: Leaving...]
Skyfire has quit [Quit: WeeChat 3.3]
rain3 has quit [Ping timeout: 260 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
winning-luser has joined #commonlisp
notzmv has joined #commonlisp
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #commonlisp
aartaka has quit [Ping timeout: 260 seconds]
varjag has joined #commonlisp
<varjag>
let's say i have a list of pairs in some container P, and these individual pairs can also be referenced elsewhere
<varjag>
i then have some 'child' container C, that can shadow some of these pairs (because its car or cdr are changed)
Qwnavery has joined #commonlisp
<varjag>
and i want the code referencing pairs in P use the values that are shadowed by C if C is supplied
<varjag>
rn am thinking to do shadowing in C via alist (keyed by original pairs of P) but it's not very pretty
pve has quit [Quit: leaving]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
<Alfr>
varjag, if P doesn't change while C is relevant, you could equip C with the same interface as P but with modifications only stored in C and reads backed by P if there's nothing appropriate in C.
<varjag>
Alfr: sounds good!
<varjag>
trying to figure out now how to do the read backed by P part now
<varjag>
problem is container family tree can be arbitrarily deep
<varjag>
and you're right P basically becomes immutable
mortemeur has quit [Quit: Leaving]
<Alfr>
varjag, you might want to look up persistent data structures; maybe there's something suitable out there already?
<varjag>
well i can surely graft something but would really love some memory efficient solution
<varjag>
(the key-value shadowing i mentioned doesn't strike me as one)
srhm has quit [Read error: Connection reset by peer]
srhm has joined #commonlisp
<varjag>
ok think i have an idea..
hendursaga has quit [Remote host closed the connection]
hendursaga has joined #commonlisp
rogersm has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
<nature>
Is there a way to change the permission bits of a UNIX file other than with (uiop:run-program "chmod something something") ?
icer has joined #commonlisp
<varjag>
nature: osicat?
pranavats has left #commonlisp [#commonlisp]
igemnace has quit [Ping timeout: 246 seconds]
pranavats has joined #commonlisp
cjb has joined #commonlisp
khrbt has quit [Ping timeout: 265 seconds]
defaultxr has joined #commonlisp
Skyfire has joined #commonlisp
<MichaelRaskin>
nature: iolib/syscalls:chmod ?
<MichaelRaskin>
Also note, that when you do use command line tools, (uiop:run-program (list "chmod" "u+r" "filename.ext")) is better because no catches with spaces in filenames
khrbt has joined #commonlisp
<fitzsim>
it'd be nice if UIOP included osicat and/or iolib functions under the hood
<fitzsim>
UIOP is supposed to be for this type of thing, but symlinks seem to be so difficult to deal with in CL
<fitzsim>
I guess permissions would be similarly difficult to wrap portably
taiju has quit [Ping timeout: 264 seconds]
taiju has joined #commonlisp
paule32 has quit [Quit: Leaving]
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
akoana has joined #commonlisp
icer has quit [Remote host closed the connection]
varjag has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
Qwnavery has quit [Quit: WeeChat 3.3]
<Xach>
fitzsim: iolib and osicat make some tricky assumptions about the availability of either specific foreign libraries or the ability to run a C compiler
gaqwas has quit [Ping timeout: 260 seconds]
theBlackDragon has quit [Quit: Boom.]
asarch has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
<fe[nl]ix>
you can't really have it any other way without being willing to hand-maintain struct and constant definitions
asarch has left #commonlisp [#commonlisp]
cosimone has quit [Ping timeout: 252 seconds]
random-nick has quit [Ping timeout: 265 seconds]
<defaultxr>
hi, is anyone aware of anything like py4cl or burgled-batteries but for interfacing with lua code instead of python? i'm considering attempting something along those lines but want to make sure there isn't prior art i'd be uselessly duplicating. neither cliki nor google seem to turn up any project that sounds relevant; the closest result is
<MetaYan>
Xach: Had a look at the quicklisp Failure report and noticed that SBCL 2.1.7.62 is used. For example adw-charting compiles cleanly with SBCL 2.1.9.
waleee has joined #commonlisp
<defaultxr>
^in addition to my question, does anyone have any suggestions for libraries that might be of use in implementing such a thing?
dra has joined #commonlisp
<hayley>
mfiano: As far as I can tell, the bug in decentralise2 is due to a bad hash function, and the hash table trying to resize indefinitely. Not a fun combination.
<hayley>
With the feature :LOG-COPYING I get hundreds of messages all reading "Creating a 1048576 element storage vector Finished copying 29783 entries after 1.667e-2 seconds"
<hayley>
Though...the decentralise2 benchmark is pretty damn fast even with the segmented lock table. Guess I did something right.
<hayley>
One trick I could use would be to randomize the initial state of the hash function on each resize, to get a different key distribution, but I'd have to write all the hash functions myself, as no one does that.
theBlackDragon has joined #commonlisp
srhm has quit [Read error: Connection reset by peer]
srhm has joined #commonlisp
dra_ has joined #commonlisp
dra has quit [Ping timeout: 268 seconds]
frgo has quit [Remote host closed the connection]
dra_ is now known as dra
<Xach>
MetaYan: i don't think so.
<Xach>
MetaYan: how are you compiling?
<Xach>
MetaYan: if you aren't compiling with warnings visible, it will seem like it works.
<MetaYan>
Xach: Alright, I understand now. ql:quickload passes, but asdf:load-system fails. Thanks.