jackdaniel changed the topic of #commonlisp to: Common Lisp, the #1=(programmable . #1#) programming language | Wiki: <https://www.cliki.net> | IRC Logs: <https://irclog.tymoon.eu/libera/%23commonlisp> | Cookbook: <https://lispcookbook.github.io/cl-cookbook> | Pastebin: <https://plaster.tymoon.eu/>
amb007 has quit [Ping timeout: 268 seconds]
lcn__ has quit [Ping timeout: 256 seconds]
varjag has quit [Ping timeout: 264 seconds]
EsoAlgo811 has quit [Remote host closed the connection]
ymir has joined #commonlisp
EsoAlgo811 has joined #commonlisp
edgarvincent has joined #commonlisp
yitzi has joined #commonlisp
<yitzi> NotThatRPG: I wrote an ASDF groveller for Clasp https://github.com/clasp-developers/clasp/tree/main/src/lisp/modules/asdf-groveler
<yitzi> It walks the source without perform-op stuff, which what some of the other grovellers do. This is done so it can impersonate the Clasp *feature* list while bootstrapping from SBCL.
bubblegum has joined #commonlisp
bubblegum has quit [Read error: Connection reset by peer]
bubblegum has joined #commonlisp
ronald has quit [Ping timeout: 276 seconds]
rgherdt has joined #commonlisp
ronald has joined #commonlisp
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
bubblegum has quit [Remote host closed the connection]
hirez has quit [Ping timeout: 256 seconds]
rgherdt has quit [Quit: Leaving]
bubblegum has joined #commonlisp
<BrokenCog> is there anything in the sbcl repl like Unix's head or tail commands??
hirez has joined #commonlisp
pfdietz has quit [Quit: Client closed]
rtypo has quit [Read error: Connection reset by peer]
<scymtym> ALEXANDRIA:REQUIRED-ARGUMENT is declaimed as (ftype (function ... nil) required-argument) which CCL doesn't like, presumably because of this: ,(lambda () (the nil (error "foo"))). any ideas?
<ixelp> (lambda () (the nil (error "foo"))) ;Compiler warnings : ↩ ; In an anonymous lambda form: Conflicting type declarations for (THE NIL (ERROR "foo")) ↩ => #<Anonymous Function #x14413F36>
dra has quit [Ping timeout: 240 seconds]
pfdietz has joined #commonlisp
<Mondenkind> BrokenCog: subseq?
<Mondenkind> scymtym: seems like ccl bug
<BrokenCog> Mondenkind: not familiar ... let me read up.
<BrokenCog> thanks.
<BrokenCog> ahh, no. its json data in an alist. I have to figure out the partitions etc.
<BrokenCog> scrolling is just tedious ... I was hoping to have some sort of paging mechanism.
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life has joined #commonlisp
random-nick has quit [Ping timeout: 240 seconds]
bjorkintosh has quit [Ping timeout: 246 seconds]
<scymtym> Mondenkind: thanks
ymir has quit [Read error: Connection reset by peer]
ymir has joined #commonlisp
<kagevf> BrokenCog: check out this: it shows how to do scripting with sbcl ... maybe you can pipe the output to bash head/tail: https://lispcookbook.github.io/cl-cookbook/scripting.html#parsing-command-line-arguments
<ixelp> Scripting. Command line arguments. Executables.
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
yitzi has quit [Remote host closed the connection]
villageidiot has joined #commonlisp
<piethesailor> Also I have a new nyxt problem. I have solved or had help solving everything but this.. How do I get quicklisp in the nyxt-user> namespace
<piethesailor> ?
ronald has quit [Ping timeout: 256 seconds]
ronald has joined #commonlisp
<kagevf> there's a #nyxt channel btw ... the devs are on there
<kagevf> but it seems like the nyxt image would include QL
<kagevf> (ql:quickload "some-lib") doesn't work?
<kagevf> piethesailor
pfdietz has quit [Quit: Client closed]
jmdaemon has joined #commonlisp
rdrg109_ is now known as rdrg109
<piethesailor> Yeah its pretty dead over there
<piethesailor> correct
Inline has joined #commonlisp
<piethesailor> (ql:quickload ...) is returning an unknown symbol
<piethesailor> which is weird
<piethesailor> you'd think that be the number one package to include in a cl repl
<piethesailor> yeah, more specificaly it says ql doesn not exits
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
pfdietz has joined #commonlisp
<beach> BrokenCog: You can't implement first-class environments natively in current Common Lisp implementations. So in any particular Common Lisp image in a current Common Lisp implementation, there is a single global environment.
<beach> BrokenCog: This environment is not in the form of an object. It is spread out all over the place. Typically, for instance, each symbol contains a slot for the global value as a function, if any.
<beach> clothespin: I am hardly ever here after 19:00 UTC+1.
<BrokenCog> beach: thanks for the comment. I was just starting into that PDF you linked ... can't help but think of the Python inner lock issues of yore.
<BrokenCog> have a good weekend if we don't cross paths again :).
<beach> Thanks! Take care!
<josrr> BrokenCog: maybe you could inspect your data (C-c I)
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
<BrokenCog> josrr: it's a good reason to learn that process better.
pranavats has joined #commonlisp
<beach> I recommend Clouseau over the SLIME inspector.
<BrokenCog> roger. thanks.
meritamen has joined #commonlisp
occ has quit [Read error: Connection reset by peer]
meritamen has quit [Remote host closed the connection]
josrr has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 240 seconds]
ymir has quit [Ping timeout: 268 seconds]
piethesa` has joined #commonlisp
piethesa` has quit [Client Quit]
ymir has joined #commonlisp
piethesailor has quit [Ping timeout: 246 seconds]
piethesailor has joined #commonlisp
piethesailor has quit [Ping timeout: 264 seconds]
edgar-rft has quit [Quit: don't waste your life by reading this]
villageidiot has quit [Quit: Client closed]
gorignak has joined #commonlisp
mooncat has joined #commonlisp
edgar-rft has joined #commonlisp
wacki has joined #commonlisp
gorignak has quit [Quit: quit]
pillton has joined #commonlisp
piethesailor has joined #commonlisp
bilegeek has joined #commonlisp
bjorkintosh has quit [Ping timeout: 260 seconds]
ymir has quit [Ping timeout: 268 seconds]
msavoritias has joined #commonlisp
King_julian has joined #commonlisp
King_julian has quit [Read error: Connection reset by peer]
bilegeek has quit [Quit: Leaving]
bilegeek has joined #commonlisp
semarie has quit [Quit: WeeChat 4.1.3]
semarie has joined #commonlisp
Lycurgus has joined #commonlisp
bubblegum has quit [Ping timeout: 268 seconds]
piethesailor has quit [Ping timeout: 255 seconds]
igemnace has joined #commonlisp
awlygj has joined #commonlisp
<younder> McClim uses Motif widget set with Xt.. Really what museum did you find that in?
<beach> It does not.
<beach> Where did you get that idea.
<beach> s/./?/
<younder> Just bound the McClim Clouseau to C-c I in sly and inspected a array.
<beach> And how did that tell you that Xt is used?
<younder> No, it gave me a Motif WS look and feel.
<beach> That's different from what you said, now isn't it?
<beach> You really should investigate before making such assertions.
epony has joined #commonlisp
<ixelp> Clousau - Image on Pasteboard
<beach> That confirms that it looks as you pointed out. But that is not what you asserted to begin with.
<younder> Well I was using it, not implementing it.
<beach> younder: And how does using it make you so sure that Xt was used when it isn't?
<beach> younder: Again, you really should investigate before making such false statements. They hurt the McCLIM project when some people might believe you.
<beach> younder: The right thing to do now is to admit that you said something that you had no evidence for, and that you will avoid that in the future. Then we can move on.
<beach> younder: This is not the first time you attempt something like this. You said the other day that CLIM modifies CLOS, and again you had no evidence. That time, you also did not admit your error, so I suspect you won't do it this time either.
<beach> younder: Either you have something against CLIM or McCLIM, and you want to influence others to avoid them. This is typical behavior of a fixed or closed mindset as described by Carol Dweck. Or else you just have a habit of uttering stuff without evidence for it.
<beach> younder: Maybe I'll give you the benefit of doubt and say it is the latter. Because that is much easier to fix than the former.
<younder> Sorry, I guess.
istewart has quit [Quit: Konversation terminated!]
<beach> Apology accepted.
epony has quit [Read error: Connection reset by peer]
occ has joined #commonlisp
meritamen has joined #commonlisp
Inline has quit [Ping timeout: 276 seconds]
epony has joined #commonlisp
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
zetef has joined #commonlisp
zetef has quit [Read error: Connection reset by peer]
azimut has quit [Ping timeout: 255 seconds]
mooncat has quit [Quit: Connection closed for inactivity]
Pixel_Outlaw has joined #commonlisp
Pixel_Outlaw has quit [Remote host closed the connection]
shka has joined #commonlisp
clothespin has quit [Ping timeout: 264 seconds]
rgherdt has joined #commonlisp
scymtym has quit [Remote host closed the connection]
scymtym has joined #commonlisp
lcn__ has joined #commonlisp
tok has joined #commonlisp
pve has joined #commonlisp
danse-nr3 has joined #commonlisp
danse-nr3 has quit [Remote host closed the connection]
danse-nr3 has joined #commonlisp
bendersteed has joined #commonlisp
dino__ has joined #commonlisp
rogersm has joined #commonlisp
<aeth> wow, look how big and 3D those scrollbars are... a better design than 98% of UIs today!
<aeth> maybe one day, the other UIs will learn about 3D
danse-nr3 has quit [Read error: Connection reset by peer]
danse-nr3 has joined #commonlisp
dra has joined #commonlisp
waaron has quit [Ping timeout: 268 seconds]
traidare has joined #commonlisp
waaron has joined #commonlisp
dra has quit [Ping timeout: 256 seconds]
dino__ has quit [Ping timeout: 264 seconds]
meritamen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waaron has quit [Ping timeout: 264 seconds]
waaron has joined #commonlisp
crumbles has quit [Ping timeout: 268 seconds]
crumbles has joined #commonlisp
zetef has joined #commonlisp
<beach> At some point, users should probably be given a choice between "good" and "modern".
clothespin has joined #commonlisp
mm007emko has joined #commonlisp
lagash has quit [Ping timeout: 260 seconds]
zetef has quit [Remote host closed the connection]
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
easye has joined #commonlisp
jack_rabbit has quit [Ping timeout: 268 seconds]
bilegeek has quit [Quit: Leaving]
igemnace has quit [Quit: WeeChat 4.2.1]
igemnace has joined #commonlisp
azimut has joined #commonlisp
traidare has quit [Ping timeout: 264 seconds]
mgl has joined #commonlisp
jmdaemon has quit [Ping timeout: 276 seconds]
traidare has joined #commonlisp
<Demosthenex> or how about we stop optimizing to the lowest common denominator. oooh shiney
yitzi has joined #commonlisp
epony has quit [Remote host closed the connection]
pillton has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.2)]
<mm007emko> Is there anything wrong with it? Sorry for a dumb question, all my GUI work was done in WPF or JavaScript (and only because I was paid for it :) ). But I have an impression that whatever "modern" I do nowadays on web might not work in 10 years. I run a McCLIM demo the other day, in WSL2 and in native build of SBCL for Windows 11 (having X installed
<mm007emko> of course) and ... it seemed it worked.
dcb has quit [Quit: Connection closed for inactivity]
danse-nr3 has quit [Ping timeout: 260 seconds]
epony has joined #commonlisp
mm007emko has quit [Quit: Client closed]
lagash has joined #commonlisp
mm007emko has joined #commonlisp
varjag has joined #commonlisp
meritamen has joined #commonlisp
mm007emko has quit [Quit: Client closed]
mm007emko has joined #commonlisp
yitzi has quit [Remote host closed the connection]
waleee has joined #commonlisp
green_ has quit [Quit: Leaving]
dra has joined #commonlisp
varjag has quit [Ping timeout: 268 seconds]
danse-nr3 has joined #commonlisp
varjag has joined #commonlisp
danse-nr3 has quit [Remote host closed the connection]
danse-nr3 has joined #commonlisp
varjag has quit [Ping timeout: 264 seconds]
kenanb has joined #commonlisp
pfdietz has quit [Quit: Client closed]
<beach> McCLIM is great. I use it every day. Some things need to be worked on, but they are, so McCLIM is constantly improved.
jon_atack has joined #commonlisp
jonatack has quit [Ping timeout: 256 seconds]
jack_rabbit has joined #commonlisp
random-nick has joined #commonlisp
<Odin-LAP> mm007emko: I found it easier to get a 30 year old piece of Pascal code (a language I _don't_ know) running than it was a 3 year old JavaScript implementation of the same.
ronald has quit [Ping timeout: 255 seconds]
ronald has joined #commonlisp
dnhester has quit [Ping timeout: 252 seconds]
dnhester` has quit [Ping timeout: 252 seconds]
rogersm has quit [Remote host closed the connection]
yitzi has joined #commonlisp
rogersm has joined #commonlisp
szkl has quit [Quit: Connection closed for inactivity]
pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
igemnace has quit [Read error: Connection reset by peer]
rogersm has quit [Ping timeout: 264 seconds]
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
josrr has joined #commonlisp
dra has quit [Ping timeout: 268 seconds]
mm007emko has quit [Ping timeout: 252 seconds]
igemnace has joined #commonlisp
dnhester` has joined #commonlisp
mm007emko has joined #commonlisp
dnhester has joined #commonlisp
kevingal has joined #commonlisp
kevingal_ has joined #commonlisp
mm007emko has quit [Ping timeout: 260 seconds]
rogersm has joined #commonlisp
mm007emko has joined #commonlisp
triffid has quit [Quit: triffid]
epony has quit [Remote host closed the connection]
cdegroot has quit [Remote host closed the connection]
waaron has quit [Ping timeout: 252 seconds]
waaron has joined #commonlisp
dra has joined #commonlisp
rogersm has quit [Remote host closed the connection]
dino__ has joined #commonlisp
cdegroot has joined #commonlisp
waleee has quit [Quit: updating stuff]
rgherdt has quit [Remote host closed the connection]
rgherdt has joined #commonlisp
ymir has joined #commonlisp
ymir has quit [Ping timeout: 240 seconds]
piethesailor has joined #commonlisp
dra has quit [Ping timeout: 260 seconds]
zephyr has quit [Quit: The Lounge - https://thelounge.chat]
zephyr has joined #commonlisp
zephyr has quit [Client Quit]
zephyr has joined #commonlisp
piethesailor has quit [Remote host closed the connection]
bendersteed has quit [Quit: bendersteed]
zephyr has quit [Quit: The Lounge - https://thelounge.chat]
zephyr has joined #commonlisp
<NotThatRPG_away> beach: What are you using McCLIM for? I'm curious -- I haven't been tracking it much in the past 5 years or so
NotThatRPG_away is now known as NotThatRPG
danse-nr3 has quit [Read error: Connection reset by peer]
danse-nr3 has joined #commonlisp
<beach> Well, I use Clouseau all the time. But McCLIM is so easy to use in order to whip up some fairly sophisticated applications. So I have used it for an AST visualizer, a visualizer for intermediate code in SICL, a "backtrace inspector" to be used during SICL bootstrapping, an application that helps me translate Vietnamese texts to English as part of my attempt to learn Vietnamese, etc.
meritamen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<beach> Vietnamese is interesting because syllables are separated by space, and a "word" can contain 3 or more syllables. So it is not obvious which syllables go together. By using the mouse to hover over a syllable, I get all possible suggestions of "words" starting with that syllable, sorted from longest to shortest.
<beach> What takes seconds in the application would take tens of minutes to do manually with a paper dictionary.
<beach> I wrote the basic version of that application during a three hour train trip from Bayonne to Bordeaux. I have improved it since, of course.
<beach> Oh, and Second Climacs is using McCLIM for its GUI.
piethesailor has joined #commonlisp
<clothespin> beach: are you going to have a buildable release of sicl sometime soon?
<beach> clothespin: Not soon, no. But remember that the purpose of the SICL project is first of all to provide modules for creators of Common Lisp systems. And we are making great progress there.
<clothespin> just something cohesive that runs in sbcl
<beach> clothespin: I am working on a new version of the bootstrapping procedure that uses lots of the new extracted libraries.
<clothespin> I need cleavir and the common lisp runtime working in the same image
<beach> clothespin: Perhaps you can remind us what it is you are trying to do?
<beach> Perhaps some of the extracted libraries would be enough.
gorignak has joined #commonlisp
tok has quit [Remote host closed the connection]
tok has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
azimut has quit [Ping timeout: 255 seconds]
BrokenCog has quit [Quit: leaving]
<clothespin> I want to try to compile some runtime functions to GPU IR
<beach> I see. And how do you think SICL would help you do that?
<clothespin> SICL has a runtime and sicl has an IR compiler
<beach> Perhaps you should look into Common Boot. We use it to create ASTs that can then be fairly easily turned into whatever IR you want. We currently use it to create host code that can work with a Clostrum environment to define stuff, and it can also generate code for MACROLET and such.
<beach> Common Boot uses the s-expression-syntax library for checking syntax at the s-expression level, and Iconoclast to turn S-expressions into ASTs.
igemnace has quit [Quit: WeeChat 4.2.1]
epony has joined #commonlisp
rogersm has joined #commonlisp
rogersm has quit [Remote host closed the connection]
rogersm has joined #commonlisp
<bike> the sicl runtime, in the sense of the choices about tagging, representation of objects, etc., wouldn't immediately run on a GPU anyway
<beach> Indeed.
yitzi has quit [Ping timeout: 264 seconds]
<beach> And if the purpose is to create GPU IR, then the SICL IRs would not be useful.
<bike> Well, part of the thinking here is that in Clasp we convert the IR to LLVM-IR, and LLVM-IR is what GPU SPIR-V and such are based on
<beach> I see.
<beach> So why not use Clasp instead?
<beach> SICL has no ambition to use LLVM.
<bike> Because the clasp runtime would also not immediately run on a GPU, probably
<clothespin> apple intermediate representation is LLVM, SPIRV is not
<bike> isn't spir-v based on llvm-ir? i mean, it isn't llvm-ir, but
<clothespin> no
tok has quit [Remote host closed the connection]
<clothespin> SPIR used to be, but SPIRV is not
<bike> "SPIR prior to the 2015 SPIR-V release was based on the LLVM Intermediate Representation." iiiii see.
<bike> i am very out of date then.
<bike> well, if i were you i would decide on this runtime stuff, like what tags there are, what's in an array, how calls work, bla bla bla, and then think about converting cleavir IR to SPIR-V with those choices in place
<beach> clothespin: I suspect that you won't be able to use anything in SICL beyond what Common Boot provides. Common Boot runs in SBCL.
<clothespin> i think your reasoning is out-of-date
<bike> later, parts of SICL could probably be used to implement whatever pieces of the standard library you want on the GPU?
tok has joined #commonlisp
<bike> my reasoning in relation to what?
<clothespin> not you...beach
<bike> oh, okay.
<clothespin> nvidia has made a lot of progress with cuda and the hardware it runs on
<clothespin> it's basically like an SMP environment with heterogeneous hardware
kevingal has quit [Ping timeout: 260 seconds]
kevingal_ has quit [Ping timeout: 260 seconds]
<NotThatRPG> beach: Thanks, that's very interesting. I have also found McCLIM good for viewing large data structures in the past, building on the graph/tree view.
<beach> clothespin: Sounds likely.
<beach> clothespin: Not that I understand why.
<bike> it's just, SICL is only planned to target what, x86-64 and RISC-V now? and even those are a way off. GPU architectures aren't those, so there'd be some work to do
<clothespin> it would be important to see what is representable with SPIRV and AIR
<beach> I was hoping someone would take on the suggested code-generation library, so that we can use it to generate code for several architectures in an implementation-independent way.
<bike> That would be good to do. But we'd need more than code generation to actually run Lisp. That would involve those representational kinda choices
<beach> Absolutely.
occ has quit [Ping timeout: 276 seconds]
X-Scale has joined #commonlisp
danse-nr3 has quit [Ping timeout: 256 seconds]
lucasta has joined #commonlisp
cage has joined #commonlisp
<beach> Some day I hope to learn in what way my reasoning is out of date.
<clothespin> you're thinking about GPUs as they existed in 2004
<clothespin> this is 2024
<bike> i don't think beach really said much of anything about GPUs?
<beach> I am not thinking about GPUs at all.
<clothespin> yet you're making judgements about what will and what wont work on a GPU
<beach> I did?
dra has joined #commonlisp
dra has quit [Changing host]
dra has joined #commonlisp
<beach> That would be a mistake since I don't know much about GPUs at all. Maybe something I said was misinterpreted to be about GPUs.
<clothespin> sorry that was bike
mm007emko has quit [Ping timeout: 268 seconds]
pranavats has joined #commonlisp
<bike> I mean I don't think SICL or Clasp would run on a GPU without a good amount of work, is all. And you were talking yourself about using a subset of the language.
<younder> Read up on the new H200 to be released this year. 141GiB of even faster RAM
<clothespin> by the time anything gets implemented the target hardware will have moved that much further forward, and it already supports cuda
<clothespin> cuda is almost like SMP C++
csos95_ has quit [Quit: ZNC 1.8.2 - https://znc.in]
mm007emko has joined #commonlisp
<clothespin> it's becoming a numa smp environment with heterogeneous instruction sets
<beach> Isn't the "symmetric" in SMP kind of the opposite of "heterogeneous"?
<clothespin> smp-like
<younder> lparallel with lambdas with one thread pr. CUDA/SMP core?
<clothespin> your GPU runtime is going to have to understand the internal binary layout of lisp objects
<clothespin> so you can't have one design for your CPU and another design for your GPU
<younder> Compile that lisp lambda to IIR and translate to SPIRV?
<clothespin> maybe
<clothespin> SPIRV may not be ready yet for what nvidia is doing
<clothespin> but it's a starting place
<clothespin> it allows you to use non-nvidia gpus
<clothespin> I have only one nvidia gpu
<clothespin> the other two are AMD
<younder> That's kinda up to NVIDIA. SPIRV allows extensions. There are already a extension (since 2019) for tensor cores for example.
<clothespin> yes, but you only control half of the spirv extension equation
<clothespin> the rest is up to the driver
gorignak has quit [Quit: quit]
<clothespin> apple doesn't even publish details for AIR
<bike> i think you would still need to put some thought into representation. For example I have no earthly idea how you would share first class functions across different machines.
<clothespin> right now i write in GLSL and translate to metal shading langauge for mac
<clothespin> that's a pretty poor environment for lisp programming
<beach> bike: Well, if the memory is shared, it's not problem. I took NUMA to mean that it is still shared, even though it is not uniform.
<clothespin> what I'd like to take a crack at is compiling the sicl runtime to SPIRV and see how well that works out
<bike> beach: i mean, what if a function is compiled? presumably you couldn't share machine code if they don't use the same ISA
<beach> clothespin: There is not going to be much left of the SICL runtime when we are done. The memory manager and a few functions like CAR, CDR, STANDARD-INSTANCE-ACCESS, ALLOCATE-INSTANCE, etc.
<beach> bike: Oh the not symmetric part. Sure.
<younder> There is a spirv-dis to take code compiled with glslc and translate to spirv bytecode.
<clothespin> what about the sequence functions
<beach> clothespin: Already extracted: Consecution
<clothespin> so whether it's sicl or not is nomenclature
<beach> clothespin: I mean, you don't have to wait for SICL the implementation to compile most of those extracted libraries.
mm007emko has quit [Read error: Connection reset by peer]
<clothespin> trying to compile consecution to spirv would be an interesting experiment
mm007emko has joined #commonlisp
<clothespin> beach: I'm not planning on waiting for SICL the implementation
rogersm has quit [Remote host closed the connection]
<beach> clothespin: Oh, I thought that's why you asked your initial question. I misunderstood. Sorry.
<clothespin> no
ec has quit [Read error: Connection reset by peer]
azimut has joined #commonlisp
ec has joined #commonlisp
<beach> My (admittedly small) family just announced that dinner is served. I'll be back tomorrow.
rogersm has joined #commonlisp
<clothespin> just when i perused the source code of SICL, the sequence functions were in that repository
X-Scale has quit [Quit: Client closed]
yitzi has joined #commonlisp
mm007emko has quit [Ping timeout: 246 seconds]
rogersm has quit [Ping timeout: 255 seconds]
mm007emko has joined #commonlisp
BrokenCog has joined #commonlisp
piethesailor has quit [Remote host closed the connection]
<BrokenCog> I'm tyrying to use the Clouseau inspector ... (ql:quickload "clouseau") hangs without any output/change. Do I need some preliminary dependency to install or something?
ronald has quit [Read error: Connection reset by peer]
<younder> For my case plenty. Most of McClim. But quicklisp should have installed them.
amb007 has quit [Ping timeout: 260 seconds]
<BrokenCog> hmm ... it's not doing anything.
rgherdt has quit [Ping timeout: 246 seconds]
amb007 has joined #commonlisp
doyougnu- has quit [Quit: ZNC 1.8.2 - https://znc.in]
doyougnu has joined #commonlisp
ronald has joined #commonlisp
ymir has joined #commonlisp
amb007 has quit [Ping timeout: 268 seconds]
<aeth> Imo, trying to support both SPIR-V and Apple is a losing game because SPIR-V itself is complicated enough. Just build awesome things for the portable standard and either people support it or they don't. If they don't, their loss.
amb007 has joined #commonlisp
kevingal has joined #commonlisp
kevingal_ has joined #commonlisp
<clothespin> yes since you believe apple is 1.4% of the market
mgl has quit [Ping timeout: 256 seconds]
csos95 has joined #commonlisp
<aeth> Apple is 1.5% of the gaming market (Steam hw survey) at one extreme or 25.38% of the US (16.13% global) web browsing traffic on StatCounter on the opposite extreme. Either way, you can safely ignore that market if it makes them hard to support it. Clearly, they act like a monopolist when it comes to standards to protect their majority-of-the-profits share (and now finally majority-of-users, but only in
<aeth> the US) in mobile.
<aeth> They sacrifice desktop (not using portable standards that makes porting easy) to protect mobile (where they don't want you to write portable code, only code for them).
<clothespin> aeth: don't ever give me statistics on the gaming market. i don't make games, i don't play games and that has little to do with me
<aeth> 1.5%, 16.13%, either way, I don't have to support them if they make it 10x harder to support them than Linux and Windows.
<BrokenCog> why isn't it both? 1.5% of gaming and 25% of browsing?? that's not an either or. One reason for a commercial product to support that platform is because users of an expensive gadget are likely to pay for an expensive add-on.
<clothespin> you do your thing
<aeth> Maybe you live in a particularly hipster Silicon Valley bubble where they have > 50% market share, though
<BrokenCog> i suspect at a higher ratio than other platform users.
<BrokenCog> the relevant metric would be developers using the platform.
<aeth> BrokenCog: 1.5% global gaming market share (people may not even bother to game on Apple and have a second gaming device, etc.) vs 25% US (16.13% global) browsing OS share
<BrokenCog> aeth: what do you think those stats are showing? to me it shows clearly that 1.5 percent of gamers use their mac (irrespective of other platforms they use) and that 1/4 of the world uses Mac's for "most of their usage" if we take "browsing" as an indicator of their primary platform. Neither says anythign about developers platforms.
<aeth> At any rate, this is tangential. Back to the more relevant part on SPIR-V, you also have to consider which SPIR-V because the standard is a kernel one and a shader one glued together with different semantics in places and with the shader one arbitrarily more restricted. I think I've linked to it once before, but there already is an effort to compile (full, Clang/LLVM) C++ to Vulkan SPIR-V here:
<ixelp> Index | Vcc - the Vulkan Clang Compiler
<aeth> Note that they state that they had to implement their own call stack in their function calls.
<BrokenCog> ah, there it goes. Clouseau finally loaded.
<aeth> And I would trust the experience of people who have already been there over people just reading random documentation PDFs
<BrokenCog> not surprisingy they needed to create their own infrastructure. What GPU does the Mac even use these days??
<aeth> BrokenCog: < 1/6, not 1/4... I bring up 1/4 share in the US because I assume that people who talk about Apple as if it is relevant have a US bias, where it is far above the global average. I would assume that certain parts of California would have even higher share!
<aeth> There may be ZIP codes in the US where Apple has a majority!
<BrokenCog> ah, okay, thought that 25% was global.
<scymtym> BrokenCog: if you loaded Clouseau and McCLIM for the first time, it is likely that compiling took most of the time. loading should be comparatively fast (and should be the only required step in the future since the compilation happens only once)
<BrokenCog> scymtym: yes, I was expecpting the .... and such output from CL ... but nothing was happening I guess while it pulled sources.
<aeth> BrokenCog: But in gaming in particular, Macs seem to select for non-gamers, gamers who use Macs tend to have a secondary gaming device (game consoles are huge! and many may have a PC just for gaming because it's only like $800 if you don't care about high-end), and Apple makes it hard to port to them (though they recently put together a Game Porting Toolkit, where if past experience indicates anything,
<aeth> there will be about 6-12 months of a push for AAA ports to Apple platforms that will then get neglected). What hasn't helped Apple is that they have a (justified) grudge against Nvidia and that they tend to favor higher resolutions than the PC market (harder to push more pixels! and they don't have the market leader Nvidia to power it!)
<aeth> But this is quite verbose and almost entirely off-topic and only at all relevant because clothespin is taking my 1.4% (now 1.5%; hooray!) out of context
mm007emko has quit [Read error: Connection reset by peer]
<aeth> For me, Apple is, yes, 1.5%, but even at the more accurate global 1/6 market share for general purpose computation, it's not worth having a complicated two-entirely-different-backend system for rather elaborate GPU support for a language, whereas Linux/Windows and AMD/Nvidia/Intel can share one single backend.
mm007emko has joined #commonlisp
lucasta has quit [Quit: Leaving]
<BrokenCog> I missed anything with that convo, but was just trying to suggest that the support might stem from them perceiving a value, but as you suggest it coudl simply be a mistaken effort of some obligatory "cross-platform support".
<aeth> Anyway, with SPIR-V, you can have one system for {Linux, Windows} x {AMD GPU, Nvidia GPU, Intel GPU} x {AMD CPU, Nvidia CPU, Intel CPU} and maybe even hope to support some rarer combinations with Android and some BSDs, etc., or maybe even Mezzano in the mix. And then there's one company that's ~1/6 of the desktop market that may even be ~1/60 if you're doing a game and it demands an entirely different
<aeth> architecture for an already very hard (doomed for failure, really) problem. But apparently clothespin is in that 1/6 and is particularly hostile to me about this conclusion I've made (thus making me seem like a fool for even mentioning 1/60).
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
lucasta has joined #commonlisp
varjag has joined #commonlisp
<BrokenCog> they do be fanatical.
rogersm has joined #commonlisp
unl0ckd has joined #commonlisp
<aeth> The way I see it, ideally, market pressure forces Apple to support Vulkan and SPIR-V before Common Lisp is even running on the GPU, which saves a project from more than doubling the effortf for < 50% market share in the first place. Or Apple gets a majority market share because Windows 12 or 13 or 14 sucks so badly and thus justifies more than doubling the work. It'll be, like, what? 2034?
rogersm has quit [Ping timeout: 252 seconds]
<BrokenCog> maybe sooner the rate at which MS is pushing ads/subscriptions/etc into Windows.
ronald has quit [Read error: Connection reset by peer]
<aeth> Yes, I've seen the Windows 11 setup process and it is awful. They really do want cloud/account stuff everywhere. It's strange how I always wind up arguing with Mac fans on IRC because I don't really have much against Apple, whereas I really don't like Microsoft. The difference is that Microsoft's market share in 2024 is still high enough to force me to support it.
<aeth> Setting up an already installed Windows 11 takes longer and is more involved than literally just installing Linux :-p
attila_lendvai_ has joined #commonlisp
notzmv has quit [Ping timeout: 268 seconds]
<aeth> And the start menu corner (because 29 years of muscle memory doesn't really matter, does it?) got replaced by clickbait news stuff (the actual start menu is now near the bottom middle) in a strange return to Windows 98's Active Desktop because that sure was a great idea.
dcb has joined #commonlisp
rogersm has joined #commonlisp
msavoritias has quit [Remote host closed the connection]
ronald has joined #commonlisp
rogersm has quit [Client Quit]
<BrokenCog> interesting that they even kept a disrtinct Start from the adclicker ... I was anticipating a requirement to go through the ads to get to Start.
<BrokenCog> presumably the WinKey still opens Start?
<aeth> I think there's actually tremendous opportunity for Common Lisp UIs in just how bad UIs have gotten in the past 10 years by flat minimalism overstaying its welcome and becoming ultraflat ultraminimalism. Fashions change and dinosaurs are slow, so by not going with modern styles, Common Lisp will be ahead of the curve when average tastes finally catch up to people who are already sick of minimalism (and
<aeth> it really was refreshing when it was new).
<aeth> I think the problem with UIs is that the average UI is quite bad no matter the style, so whatever everyone is doing will seem ugly and whatever is in a brand new style is probably done close to the very best that that style can be done. So I think any CL toolkit should focus heavily on looking both good and different.
<BrokenCog> what's an example of a current CL UI?
waleee has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
cosimone has joined #commonlisp
<varjag> aeth: material design is the least laborous option and as such is at least a local optimum
<varjag> nothing's easier than throwing a few solid filled rectangles
<varjag> so it's going to stay with us for a while
<jcowan> varjag: It's even easier if said rectangles have the background color as foreground. I find myself rolling the mouse all around the label of a control trying to figure out where the actual control is.
<jcowan> ... and sometimes clicking randomly because mere mouse movement is not enough
prokhor has joined #commonlisp
bilegeek has joined #commonlisp
bilegeek has quit [Remote host closed the connection]
<Shinmera> BrokenCog: Kandria uses Alloy for its UI
josrr has quit [Remote host closed the connection]
azimut has quit [Ping timeout: 255 seconds]
kevingal_ has quit [Ping timeout: 276 seconds]
kevingal has quit [Ping timeout: 276 seconds]
jeffrey has joined #commonlisp
ymir has quit [Ping timeout: 252 seconds]
<aeth> varjag: what frustrates me about many things in tech, including design, is that one company does something and then they all converge on it, sometimes fast, sometimes slow, but there's no point avoiding it because the slow movers eventually move, it's just that they're slower getting there
<aeth> a dozen choices, all an illusion
<aeth> Which is why any GUI I do will look very different from what everyone else is doing, intentionally. I don't use the same programming language as everyone else, either.
<aeth> Modern (c. 1950) design is bland and soulless, without any kind of decoration or fun. That's why people move away from it (and then periodically come back to it, I guess, because it's clean). I want programming to be fun and colorful. By contrast, if minimalism keeps getting more and more minimalist, colors will mostly be gone from UIs because that's next.
rgherdt has joined #commonlisp
jmdaemon has joined #commonlisp
jelewis2 has joined #commonlisp
<aeth> (Go to Google.com in dark mode if you think the minimalists can't take away color!)
<bjorkintosh> aeth, so you must like scratch then?
<gilberth> Well, I keep saying it: Not long and Xaw is modern again. Though me personally never liked too baroque UIs of the Motif era. And I implemented a Motifsh look for McCLIM gadgets only because it was fashionable at that time, not because I liked it particularly.
lewisje has quit [Ping timeout: 268 seconds]
<varjag> i'm not even sure there's particular ui tech that i really like
<aeth> bjorkintosh: Scratch seems kind of... almost Windows XP in its design language. There are many ways to do not-minimalism.
<varjag> it's always bit of a struggle one way or another
<bjorkintosh> aeth, lively kernel? https://lively-kernel.org/
<ixelp> Lively Kernel - Home
<aeth> gilberth: "Baroque" to me would be late OS X before they went minimalist
<aeth> though anything with highly detailed icons may count
<aeth> Those sorts of icons fell out of favor when people moved to vector images, not knowing the DPI or screen size or viewing distance of their target screens. But I think you could add some anti-flatness into a UI by making it 3D in the literal uses-a-3D-renderer sense.
<aeth> I personally think that a Common Lisp IDE should go full 3D with fancy effects that are easy to do in (shader) code but entirely alien to both the traditional and modernist way of thinking about UI.
<aeth> It's, like, a tool bar and a scrollbar that you can disable, and not much else, so it's easier than the general case of UI.
mgl has joined #commonlisp
<bjorkintosh> what would 3D add to the experience, aeth?
<aeth> maybe I could have a big icon in the upper right that just animates sometimes, like really old Netscape
<aeth> when e.g. your code is compiling and your tests are running
<aeth> but where you could really go fancy is the REPL
kenanb has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.2)]
<aeth> wouldn't be the first... DrRacket supports a lot
<aeth> And in general, CASes (including Macsyma) tended/tend to have very fancy REPL-like things with potentially e.g. animated graphs, etc. Jupyter Notebook has inherited this line of thinking.
<bike> not really paying attention, but we use jupyter notebooks with clasp in order to model molecular structures, which you definitely want 3D for
<aeth> I'd think, really, that the anti-minimalist way to go would be to go all out in making a rich multimedia REPL as SLIME alternative, including embedded 3D animations (though you'd only want to animate one thing at a time, when the user wants it animated).
rgherdt has quit [Ping timeout: 240 seconds]
rgherdt has joined #commonlisp
ymir has joined #commonlisp
<bjorkintosh> bike, that's neat, would it help to render it in VR too?
unl0ckd has quit [Ping timeout: 268 seconds]
mariari has quit [Ping timeout: 268 seconds]
<Odin-LAP> REPLs with embedded multimedia seem to be confusing to most people.
<Odin-LAP> "But ... it can't be modern, it's a command line!"
<bjorkintosh> racket does it quite nicely.
<Odin-LAP> The irony is that more and more programs are adding what is effectively a command line interface.
<Odin-LAP> "command bar" or suchlike
<bike> bjorkintosh: i don't know that we would need that. maybe someone does
<bike> Odin-LAP: jupyter at least is pretty recognizably not a terminal repl
<bjorkintosh> bike, "immersive" visualizations.
<gilberth> Indeed. Like with programming languages, also GUIs will eventually converge to what we already had in the late 70s.
<gilberth> That hamburger menu icon? Old hat: <https://www.youtube.com/watch?v=_OwG_rQ_Hqw&t=3895s> Mind the time index.
<ixelp> The Final Demonstration of the Xerox 'Star' computer - YouTube
<bike> huh, what do you know.
<gilberth> btw, that whole bar is the pointer documentation.
mariari has joined #commonlisp
<Odin-LAP> bike: Granted, those seem able to avoid the confusion, but I think that's partly because they often get presented as "documents with embedded code" rather than as a user interface.
<bike> maybe. we pretty much use it as a cheap UI, though.
<bike> to be clear i was responding to the "confusing to most people" bit. it's still effectively a command line interface, especially if that's going to include command bars
<Odin-LAP> That's how I read it.
<aeth> I think the main difference with a CAS, Jupyter, etc., is that their "REPL" lets you go backwards and edit an old input+result, which lets your state get even harder to follow if you didn't evaluate things in order.
<aeth> SLIME lets you go back, too, but if you edit it, it adds it to a new line, but, confusingly, seems to keep the old line edited so the log is no longer accurate
<aeth> so if you do CL-USER> (defun foo () (+ 1 2)) => FOO
<aeth> then call (foo) and then change that to (+ 3 4) it will produce two (defun foo () (+ 3 4)) and make the middle result look like some sort of bug
<aeth> although it's still there in the REPL history (and probably the written logfile)
<Odin-LAP> I just have noticed more than once that anything where a typed in command results in pretty pictures, let alone something interactive, focuses people's attention more to the UI being "weird" than it does whatever the command was actually supposed to do.
<aeth> Oh, and you're also not expected to ever have to replay a SLIME REPL log. In fact, idk if you can save and load an old REPL session.
<aeth> Though I wouldn't be surprised if you can somewhere because Emacs loves having tons of hidden bloat
<bike> part of this might be that the people using this jupyter stuff here are mostly chemists, so they're not as used to terminals as grognards like us
<bjorkintosh> emacs is a floating island with many occupants. it's not bloated.
<Odin-LAP> Which is kinda silly because even the ANSI terminal control standards were kind of designed with the potential for this sort of thing in mind.
<bike> so they see an image pop up and they just take it in stride
<bike> /i/ get a little weirded out, but i'm not the target audience
<aeth> CASes behave like this, even the old Macsyma if you look up an image search
<aeth> consider MAPLE, Mathematica, etc., too
<aeth> in part because visualizations are part of the point
<aeth> Though Jupyter+Python seems to have clearly won this sort of thing by not costing $x,xxx
<aeth> And running in any web browser
<bike> that certainly helps.
<Odin-LAP> aeth: This kind of UI was really the standard until the mouse was everywhere.
notzmv has joined #commonlisp
<aeth> yes, CASes are old and then glued a proper GUI on later, and then kept their REPL-ish thing as a worksheet
<Odin-LAP> aeth: It's easy to forget that there were terminals capable of pretty powerful bitmapped graphics considerably before there were pointer devices.
<aeth> and there's basically a direct heritage of Common Lisp > Macsyma > Maple > Sage > Jupyter
<aeth> with the cousin DrRacket
<aeth> Odin-LAP: yes, terminals got stuck on least-common-denominator for too long... well, at least they supported (a few) colors and then retrofitted in UTF-8, too
<Odin-LAP> (Rather like it's easy to forget that ASCII was really principally designed for communicating _typewriters_, with all the neglect of typesetting that implies.)
rgherdt has quit [Ping timeout: 260 seconds]
<aeth> Ideally a multimedia REPL could SSH tunnel for remote editing access so you never have to use a basic terminal. So e.g. lem having an Emacs-like in-terminal mode is the wrong approach imo.
yitzi has quit [Remote host closed the connection]
<aeth> Just have something like eshell (but still multimedia at its heart!) if you want something more shell-like
<aeth> Some terminals (including iirc xterm?) do support images, but some weird clearly-the-wrong-approach one.
<aeth> though there are some like e.g. https://sw.kovidgoyal.net/kitty/
<ixelp> kitty
<Odin-LAP> aeth: The madness IMO is that using UTF-8 and the ANSI escape code standards would probably enable you to do that. Just not in a way that current terminal emulators would support.
<Odin-LAP> It's the common story ... it's needing to cater to the crappy implementations that holds a lot of functionality back. :p
<bjorkintosh> emulate it!
<aeth> A lot of circa 1990 cool tech charged too much money (not one but at least three Lisps included) and the cheap/free was "good enough"
<aeth> Ironically, Lisp hacker RMS doing a really good job killing Lisp by making a "good enough" $0 C with $0 Unix/shell stuff bundled in, too
<aeth> (initially not quite $0 because GNU charged for distribution in the very old days!)
* Odin-LAP is not convinced.
<Odin-LAP> The 80s had a lot of stuff happening on very expensive computers, and that was very clearly getting disrupted by the whole PC scene.
<aeth> right, Lisps aren't great on 16-bit and you see the legacy of 16-bits to this day by the Common Lisp standard (as immutable as Lycurgus's laws for Sparta) setting the minimums of almost anything as far, far too small (and any CL that actually was minspec probably would be painful to use)
<bjorkintosh> lycurgus is muerte.
<Odin-LAP> You could argue that the combination of GNU and the PC was what ensured the death of approximately everything between mainframe and PC hardware, but I really think minicomputers were on the way out as soon as the PC was more than just a toy.
<aeth> This is why you see a surprising amount of investment into VR, AR, XR, MR, "spatial computing", etc... Everyone in tech knows that eventually the next thing is going to disrupt the current thing (but despite being defensive about it, most if not all of them will get disrupted eventually, anyway)
zxcvz has joined #commonlisp
zxcvz has quit [Client Quit]
<aeth> But more on topic, I definitely think that a proper CL RPEL needs to basically do anything. Load an image. Generate a 2D/3D graph. Open an application as a "window" within the REPL. Maybe even much harder things like PDFs or videos or web browsing.
<bjorkintosh> sounds like CLIM
<jcowan> Servers basically fill the minicomputer niche
<jcowan> it's just that there's no reason for them to have a fundamentally different architecture from personal (i.e. client) computers.
<aeth> or workstations, which use hardware very close to servers, but usually with a tower form factor
<jcowan> Indeed. It's a continuum now.
<Odin-LAP> jcowan: Yes, but they're upscaled PCs rather than derived from the minicomputers.
<aeth> Odin-LAP: which in particular here means most of the software is also "upscaled PC" software
<aeth> nobody is going to buy some proprietary UNIX OS for it
<Odin-LAP> jcowan: In terms of manufacturers, engineer culture, all that, it has more to do with the development of the PC than it does the old minicomputers.
<jcowan> Linux isn't upscaled PC software
<jcowan> and neither is VMS + 1 = WNT.
<bjorkintosh> eh. was the irix an upscaled PC?
<bjorkintosh> or the sun workstations?
<aeth> The Unices we're stuck with (Linux, BSDs) were written for the 386 originally.
<aeth> They may not be Wintel, but they're definitely part of PC culture
<Odin-LAP> aeth: Yes, but the irony is that the PC software currently used was "downscaled minicomputer" systems, so there is a connection.
<jcowan> But architecturally they are Unix, which is a minicomputer OS.
<Odin-LAP> bjorkintosh: No, but you will notice that those systems are by and large not around anymore.
<jcowan> and so is Windows
<Odin-LAP> jcowan: By way of PC ports, however.
<jcowan> Which preceded DOS (a PC OS) on the 386
<Odin-LAP> Xenix, anyone?
<bjorkintosh> wintel pcs are the zerglings of computing: everywhere all at once.
<jcowan> Yup.
<bjorkintosh> they were too cheap to ignore.
<jcowan> I used Xenix System III on a PC/AT.
<gilberth> Odin-LAP: Here!
ronald has quit [Remote host closed the connection]
<gilberth> Even ported X11 to it.
<jcowan> I used it to develop software for DOS using MS C
<gilberth> Which was a pain.
ronald has joined #commonlisp
<ixelp> Desktop Operating System Market Share Worldwide | Statcounter Global Stats
<jcowan> I'll bet.
<aeth> The '90s and '00s were the Windows era, with Windows having 95.42% desktop share at the start of 2009. And now it's 72.99%. And that's just desktop share. Android is more popular of an OS now.
<Odin-LAP> jcowan: My point isn't "minicomputers ultimately had no impact", it's "the history of the PC is at least as relevant to understanding large servers as minicomputers are, and probably more".
<splittist> I think it was Xenix that we used for our COBOL programming class
<gilberth> Just because of that MS C compiler, which couldn't cope with it. So I ported gcc. But that MS couldn't cope with version 2.something, so I first ported gcc version 1.ihaveforgotten to compile gcc 2.whatever to compile X11.
<jcowan> Odin-LAP: I grant that's true for the hardware, but I'm not so sure about engineering culture.
<aeth> Outside of gaming and enterprise, you may already live in a world where Windows is irrelevant, so it would be great to start seeing what we can bring back from the pre-1995 computing world.
<Odin-LAP> jcowan: It's because of the engineering culture that I'm allowing that minicomputers have any relevance. :)
<jcowan> And I definitely disagree that current server software has anything to do with *DOS.
<aeth> There are two distinct OSes still around: NT (not DOS! took until XP for consumer desktops to get it, though) and Unix clones
<jcowan> It's software that was born on minicomputers.
<Odin-LAP> aeth: Valve seems pretty intent on taking gaming out of that, too.
<bjorkintosh> aeth, and the IBM mainframe OSes. specifically AS/400.
<aeth> Odin-LAP: yes, because if everyone has a first party store, then there's no place for Steam.
<bjorkintosh> it is its own damned world far removed from common experience.
<jcowan> And Z/OS, which still makes more money.
<Odin-LAP> jcowan: Yes, but software that could be downsized to the less capable PC hardware of the nineties with relative ease.
<varjag> aeth: outside desktop windows software is pretty much irrelevant
<aeth> bjorkintosh: its market share must look like a rounding error
<aeth> except maybe in banking?
<bjorkintosh> aeth, you only need a handful of C130s.
<bjorkintosh> bicycles will always outnumber them. but they have their place.
<Odin-LAP> Actually, games consoles are another really interesting area in regards to engineering culture, hardware and the influence of x86.
<jcowan> It depends. It was pretty shocking when Linux became more common on Azure than Windows Server.
<bjorkintosh> the OS/400 and the AS/400 is quite unique and extraordinarily capable.
<aeth> I definitely think Microsoft's going to spin off Windows one day just to separate the declining-monopoly part of its business from the hype-growth cloud/AI part. Or maybe move it to a chrome on top of Linux and outsource compatibility to the wine team.
<jcowan> Particularly since you can take an image and migrate it to a different AS/400 architecture and your program doesn't notice.
<varjag> aeth: they'll just rename WSL into LSW and voila
<Odin-LAP> aeth: I think either of them will involve enough work that they might as well end up just open sourcing the damn thing.
<aeth> Odin-LAP: they may not have the rights to all of the middleware
<jcowan> Windows is declining, but it's still huge.
<bjorkintosh> it doesn't get mentioned among academics and hipsters alike, so it seems to not exist. but it does: https://vimeo.com/93836342
<ixelp> IBM Tembo Roadshow 2014 #5 Dr Frank Soltis on Vimeo
<Odin-LAP> aeth: Yes, and teasing that out might not end up being more work than the two options you mentioned.
<morganw> The desktop version of Windows is now referred to as "Windows Client", which tells you the future direction of it. (Service consumption platform.)
<aeth> jcowan: Right, but in finance, people don't want huge, they want growth, which means Microsoft + WindowsCorp > Microsoft in market cap, perhaps significantly so, and Microsoft's already $3 trillion.
<Odin-LAP> Eh, who cares anyway? It's all going to burn in a fire in a couple of decades anyway.
<jcowan> The original read-write Linux driver for NTFS was a wrapper around the Windows driver, which was legitimate because essentially all PCs (and this is sitll true) are licensed to run Windows.
<Odin-LAP> Faster, if the financiers get their way.
<jcowan> Fortunately, a native driver was written before MS said you couldn't use Windows drivers on machines not running a Windows kernel.
<jcowan> Odin-LAP: The human race will do the same. Fortunately for me, I'll be dead. Unfortunately, my descendants are going to suffer from it.
<aeth> hopefully our future robot overlords will be built on Lisp
* jcowan chuckles
ronald has quit [Read error: Connection reset by peer]
ronald has joined #commonlisp
<aeth> Odin-LAP: I find it hard to have a "who cares" attitude toward the future because certain software must be made
<Odin-LAP> Undoubtedly JavaScript, having been cobbled together by LLMs.
<aeth> Odin-LAP: idk if it happens within the next 2 years, it's Python on top of C++/Fortran
<bjorkintosh> I don't think so. people will eventually realize that Python is hideously complicated. More complicated than C++ and BF combined.
<bjorkintosh> it sneaks up on you too.
<Odin-LAP> I doubt it.
<Odin-LAP> That realisation should have come ages ago.
<bjorkintosh> the advantage is that a realization that python 4.whatever-to-come would be orders of magnitude more difficult to program with, than Common Lisp, might lead the masses back this way.
cage has quit [Quit: rcirc on GNU Emacs 29.1]
<jcowan> Other than the transition from assembly language to non-assembly languages, I haven't seen any difference involving even a single order of magnitude, never mind multiple orders.
<jcowan> other than specialized tools like make (it would be horrible to write a makefile in C)
<aeth> bjorkintosh: anything with a lot of users becomes hideously complicated... a lot of Common Lisp's warts are to maintain compatibility with stuff nobody uses anymore, but that were relatively popular in the 1980s
<Odin-LAP> See also: Microsoft Windows.
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<jcowan> Or were expected to be, per the 16-bit CLs that never caught on
<bjorkintosh> aeth, I stand corrected. so the shedding of those bits should lead to ... (un)Common Lisp!
<aeth> You can't just break compatibility to fix flaws (Python 3 almost killed Python and gave most of the 2010s to JS, while Perl 6 basically killed Perl)
<Odin-LAP> Which has done a _way_ better job of maintaining backwards compatibility than Linux has, it must be conceded.
<jcowan> If by Linux you mean the kernel, then no. Its competitors don't even have stable APIs.
<aeth> Linux-the-kernel does a good job maintaining backwards compatibility... GNU, on the other hand, has the attitude that since you have access to the source code anyway you should just continuously recompile
hineios2 has quit [Quit: The Lounge - https://thelounge.chat]
<aeth> which is why Linux containers can be a thing
shka has quit [Ping timeout: 256 seconds]
<bjorkintosh> I don't get the fetishization of backward compatibility _at_all_! why is it even a thing to consider, when one can just spin up a VM?
<bjorkintosh> speaking of OSes, not languages.
<Lycurgus> bjorkintosh: yo no muerte
<Odin-LAP> bjorkintosh: Because that latter was not a "just" until very recently.
<bjorkintosh> IBM has been doing exactly that sine the late '60s!
<aeth> Because the Linux kernel is stable, you can use containers that share the kernel instead of using the heavyweight overhead of a VM for most things
<bjorkintosh> Lycurgus, hahaa. I meant the historical Law giver!!
<Lycurgus> ah
<bjorkintosh> Lycurgus, lo siento.
<jcowan> The Uncommon Lisp is R2RS Scheme.
<Lycurgus> bjorkintosh: np
<aeth> of coursea a Lycurgus would be here...
<bjorkintosh> hahah. aeth yes. a spanish speaking one... i only commented in jest.
<aeth> the parallels between Sparta and the never-changing CL standard are too strong
<Lycurgus> was it in reference to the legend of him dying so his reforms wouldn be altered?
<aeth> yes
<Lycurgus> ah
<jcowan> Nowadays, the distinction between (cross-platform) containers and VMs is practically nil
<Lycurgus> not to me it isn
<aeth> containers on Linux, VMs elsewhere
mgl has quit [Ping timeout: 255 seconds]
ec has quit [Remote host closed the connection]
hineios2 has joined #commonlisp
<Lycurgus> VM/CMS, smalltalk, etc. VM; docker and what not container
<Lycurgus> if it's just a pass thru to understuff: container
ec has joined #commonlisp
<Lycurgus> if it presents its own machine model: vm
<bjorkintosh> it's the future of retro computing and future computing.
<bjorkintosh> a hyperVM to host everything you can imagine.
<jcowan> you can run Linux containers on Windows
<Lycurgus> and yeah vm/cms, xen hypervisor etc: vm facilities
<aeth> the future of LispOSes is Linux containers
<Lycurgus> whereas smalltalk and many other langs with a vm are just a single vm
ronald has quit [Ping timeout: 256 seconds]
<Lycurgus> then there's the implicit vm which a compile generates code for without there actually being a coded vm
<bjorkintosh> Lycurgus, according to its Father, smalltalk is all about messaging between objects. so a bunch of smalltalk VMs exchanging messages should scratch the necessary itches.
<Lycurgus> *compiler generates native code for
<Lycurgus> yeah my first st was in '85
<Lycurgus> won't bore you with links
<bjorkintosh> smalltalk/v?
<Lycurgus> well methods actually at first
<jcowan> It's not *just* implicit either, because current ISAs are effectively VMs
<Lycurgus> but yeat digitalk until squeak
<Lycurgus> *yeah
ronald has joined #commonlisp
<Lycurgus> the first digitalk smalltalk was character oriented believe it or don't
* jcowan nods
<jcowan> My first ST was Actors
<Lycurgus> in '86 they came out with a fully graphical black and white and that's when methods became smalltalk/v
<jcowan> GNU ST is still character-oriented
synchromesh has joined #commonlisp
<Odin-LAP> I wouldn't be surprised if all the x86-64 processors have a full translation layer between the advertised instruction set and what the hardware actually executes.
<Lycurgus> well and headless squeak is too
<jcowan> Odin-LAP: Be unsurprised then
<jcowan> Actors was a from-scratch reimplementation of ST, but it didn't do actors.
<bjorkintosh> jcowan, Actors? never heard of it.
<bjorkintosh> mine was Dolphin. it's obsolete.
jack_rabbit has quit [Ping timeout: 256 seconds]
<jcowan> (not Actors, my bad)
jack_rabbit has joined #commonlisp
<Lycurgus> there's an actor pkg for squeak fwiw
<jcowan> that's the actor model, which is not the same
<jcowan> Actors was built directly over the Win16 API, so an Actors application looked exactly like a C application.
<Lycurgus> true, if a detail. CAF is the best i've found
<Lycurgus> (c++ actor framework)
<jcowan> Both God and the Devil are in the details, depending on who you ask
<jcowan> s/Actors/Actor/, dammit
cosimone has quit [Remote host closed the connection]
<bjorkintosh> wow jcowan. it's such a rare animal that it has just one comment: https://en.wikipedia.org/wiki/Talk:Actor_(programming_language)
<bjorkintosh> de(vil, tails)
<Lycurgus> there's a failry baroque but good cl implementation too
cosimone has joined #commonlisp
<Lycurgus> (nclos)
mgl has joined #commonlisp
* Lycurgus doesn believe in either of fictional characters
awlygj has quit [Quit: zZzZ]
<Lycurgus> and feels morally compelled to be a lil bit of a jerk about it
cosimone has quit [Remote host closed the connection]
dustinm` has quit [Quit: Leaving]
<bjorkintosh> hahaha
<Lycurgus> and least insofar as not keeping mouf shut
<Lycurgus> *at least
<Lycurgus> i wonder if anybody but the author ever used nclos
<Lycurgus> pretty sure lparallel is dominant at far as share of that use niche
<bjorkintosh> which niche?
<Lycurgus> *as far as
<Lycurgus> multi image distributed cl
<Lycurgus> cl-oud is prolly unoccupied if anybody wants to take a crack at it
bilegeek has joined #commonlisp
dustinm` has joined #commonlisp
<aeth> But if you call it "cl-oud" then the "Cloud to Butt" extension doesn't work on it.
<Lycurgus> lol
mgl has quit [Ping timeout: 256 seconds]
rtypo has joined #commonlisp
tok has quit [Remote host closed the connection]
<pl> bjorkintosh: IBM mainframe VMs were not about backwards compatibility - they for example didn't emulate hardware, especially different hardware than the one you had in machine
<bjorkintosh> but it was possible.
<bjorkintosh> you can run a 360 on a 370.
amb007 has quit [Ping timeout: 260 seconds]
* Lycurgus runs MCS and VM/CMS under herc
* Lycurgus *MVS
X-Scale has joined #commonlisp
rgherdt has joined #commonlisp
ronald_ has joined #commonlisp
ronald has quit [Read error: Connection reset by peer]
cosimone has joined #commonlisp
cosimone has quit [Remote host closed the connection]
ronald_ has quit [Ping timeout: 256 seconds]
traidare has quit [Ping timeout: 256 seconds]
cosimone has joined #commonlisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
prokhor has quit [Remote host closed the connection]
bjorkintosh has quit [Ping timeout: 268 seconds]
cosimone has quit [Remote host closed the connection]
prokhor has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
mgl has joined #commonlisp
X-Scale has quit [Quit: Client closed]
cdegroot has quit [Ping timeout: 252 seconds]
dino__ has quit [Ping timeout: 264 seconds]