ravenousmoose has quit [Ping timeout: 250 seconds]
Zanitation has joined #lisp
cpape has quit [Quit: ERC (IRC client for Emacs 26.1)]
cpape has joined #lisp
ravenousmoose has joined #lisp
EvW has quit [Ping timeout: 245 seconds]
_jrjsmrtn has quit [Ping timeout: 252 seconds]
__jrjsmrtn__ has joined #lisp
ravenousmoose has quit [Ping timeout: 276 seconds]
ebzzry has quit [Ping timeout: 246 seconds]
ssake has quit [Ping timeout: 250 seconds]
X-Scale` has joined #lisp
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
ssake has joined #lisp
akoana has joined #lisp
<equwal>
Roswell is a game changer for CL scripting.
<equwal>
I was able to hack together a build script for these font variants in a few hours, whereas I have no idea how I would have done it without Roswell.
jackdaniel2 has quit [Read error: Connection reset by peer]
xkapastel has joined #lisp
amerigo has quit [Quit: Connection closed for inactivity]
stepnem_ has joined #lisp
stepnem has quit [Ping timeout: 276 seconds]
ebzzry has joined #lisp
lxbarbosa has joined #lisp
<_death>
I think a script should be two forms: load the system, apply a function with command line args.. the rest belongs in the system, which can be depended upon by other lisp code
<equwal>
Indeed, my script I linked conflates such things.
<equwal>
It is the first time I have used Roswell.
ebzzry has quit [Ping timeout: 265 seconds]
makomo has quit [Ping timeout: 240 seconds]
igemnace has joined #lisp
lxbarbos` has joined #lisp
lxbarbosa has quit [Ping timeout: 246 seconds]
<_death>
anyway, been using terminus (with modified lambda) for a decade now, methinks.. all other fonts are unbearable :d
<drmeister>
Hmm, maybe that's why - maybe I'm parsing 2020-01-01 in GMT and I'm in EST and so it's printing 2020-01-01/GMT in EST and the world is a sphere?
<drmeister>
Flat earther's - checkmate!
<ck_>
the -5 looks weird to me
<ck_>
oh, no, sorry -- it's because I'm too used to GMT+1. My fault.
<ck_>
but it's the other way around, you're parsing 2020-01-01 as EST, which gets printed as GMT-offset
xkapastel has quit [Quit: Connection closed for inactivity]
<drmeister>
Thanks for the feedback. Hmmm.
<drmeister>
If I parse 2020-01-01 midnight EST wouldn't that be 2020-01-01 5:00 am in the GST timezone?
<Bike>
do you mean GMT
<drmeister>
GMT - right.
<Bike>
or you could be doing things in the unitd arab emirates, i guess
<ck_>
yes, you're right
<drmeister>
I'm reading up on the time zone stuff in local-time.
<ck_>
I described what I thought was the case, not what your printout said :|
<drmeister>
That's ok - I always have to think hard about different timezones.
<drmeister>
All I'm sure about is you europeans disappear from IRC in my evening and show up just before I collapse in bed. :-)
zmt00 has joined #lisp
<drmeister>
If I force my timezone to UTC then parsing and printing gives the expected result.
jackdaniel2 has quit [Read error: Connection reset by peer]
<ArthurStrong>
Sometimes my prank can last 3-5 lines until interlocutor starts to suspect something
<aeth>
ArthurStrong: I don't think my application of your technique even lasted one line
<zhouzihao>
i what to achieve on kernel does any information helps?
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
brown121408 has quit [Read error: Connection reset by peer]
brown121407 has joined #lisp
jackdaniel2 has joined #lisp
rumbler3_ has quit [Ping timeout: 265 seconds]
ironbutt has joined #lisp
oxford has joined #lisp
CloseToZero has quit [Ping timeout: 245 seconds]
retropikzel has quit [Quit: Leaving]
<ArthurStrong>
What are your favorite educational micro-LISP implementations? Like Norvig wrote in Python?
CloseToZero has joined #lisp
Davd33 has quit [Remote host closed the connection]
<Shinmera>
This all has very little to do with Common Lisp.
karlosz has quit [Quit: karlosz]
Davd33 has joined #lisp
<no-defun-allowed>
Probably sl3.c, which floats around in several places. It even has a proper reader (somehow in C). I can't think of many small Common Lisp implementations.
<ArthurStrong>
no-defun-allowed: thanks, googled it
karlosz has joined #lisp
<zhouzihao>
thanks
<no-defun-allowed>
zhouzihao: What do you want to achieve with the kernel?
<ArthurStrong>
By the way. Once upon a time I was reading a book about Lisp. ANd there was something like this in preface: "LISP is a good prototyping language..." Can anyone remember what book called LISP prototyping language in preface or somewhere near beginning?
jackdaniel2 has quit [Read error: Connection reset by peer]
<zhouzihao>
I want to create a new OS , when boot over just run a lisp env
hhdave has joined #lisp
Davd33 has quit [Remote host closed the connection]
<jackdaniel>
please stick to the channel topic which is Common Lisp (other lisps may be discussed on ##lisp)
<zhouzihao>
okay you are right ~
<ArthurStrong>
What is the point of having two similarly named channels? :)
<zhouzihao>
But I love CL better than others. And hope to implement the syntax of CL
<phoe>
ArthurStrong: backwards compatibility with the 20th century
<jackdaniel>
to have a channel for common lisp and to have a channel for "any" lisp
patrixl has joined #lisp
<ArthurStrong>
jackdaniel: mabe #clisp would be a better name then...
<Shinmera>
This topic has been beaten to death.
<Shinmera>
#lisp is common lisp, and that's that, deal with it.
<ArthurStrong>
OK, OK
* ArthurStrong
zipped mouth
<jackdaniel>
maybe, but people interested in common lisp and operators of this channel decided that moving would be a lot of effort for little gain
<no-defun-allowed>
CLISP is an implementation of Common Lisp, the only acronym that I believe is widely accepted as that is CL.
<jackdaniel>
to complete the picture, there is also #lispcafe for chitchat not necessarily related to lisp
<edgar-rft>
ArthurStrong: here's a list of irc lisp channels and what they're good for: https://www.cliki.net/IRC
brown121408 has joined #lisp
<ArthurStrong>
On a completely unrelated note, I once heard about (jokish?) band named Duran Duran Duran :)
Davd33 has joined #lisp
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
brown121407 has quit [Ping timeout: 276 seconds]
<zhouzihao>
You guys confused me.
<zhouzihao>
The speed of my Google translation can't keep up
jackdaniel2 has quit [Read error: Connection reset by peer]
Lycurgus has joined #lisp
karlosz has quit [Quit: karlosz]
vaporatorius has quit [Read error: Connection reset by peer]
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
vaporatorius has joined #lisp
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
vaporatorius has joined #lisp
vaporatorius has quit [Read error: Connection reset by peer]
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
vaporatorius has joined #lisp
<zhouzihao>
thanks i see . and i want do it by myself~~ :)
<zhouzihao>
and i don't want to create a new cross complier for CL
<zhouzihao>
so i want to do it in a anthor way
<Duuqnd>
Well, good luck. I don't know of any CL system that compiles freestanding code.
<Duuqnd>
compiles to*
<phoe>
mostly because you need the system runtime for ANSI CL to function
<beach>
Who said anything about "freestanding code"?
<beach>
... whatever that might mean.
stepnem_ has quit [Ping timeout: 250 seconds]
<Duuqnd>
beach: "freestanding code" means code that does not rely on an already established environment.
<beach>
Duuqnd: OK, but why did you bring it up?
rgherdt has joined #lisp
<Duuqnd>
Because it's more or less required for running code on bare-metal.
<zhouzihao>
yes
<beach>
Duuqnd: So then, Mezzano and Movitz don't exist?
stepnem has joined #lisp
<jackdaniel>
why wouldn't you be able to estabilish environment on "bar metal"?
<jackdaniel>
i.e linux kernel also relies on its own estabilished environment to function correctly
<zhouzihao>
Mezzano has a cross complier f
<Duuqnd>
jackdaniel: That environment would need to be freestanding.
<Duuqnd>
beach: I'm not sure how Mezzano works, but I think it includes a compiler that can do freestanding code.
<Duuqnd>
I know very little about Mezzano, though.
<jackdaniel>
can't compiler be a part of a freestanding environment?
<phoe>
Duuqnd: what do you mean "freestanding"
<beach>
Duuqnd: That curious, since you just said you don't know of any system that compiles to freestanding code.
<zhouzihao>
Hardware-independent
<Duuqnd>
beach: Not any standalone system. And they probably exist, I just haven't heard of them.
<jackdaniel>
I'm lost now
<beach>
Me too.
<phoe>
so code that can run on x86, amd64, armv6, armv7, armv8 and so on
<phoe>
wtf
<zhouzihao>
No system call required
<phoe>
what is a "system call" in this case
<beach>
Duuqnd: Either you have heard of Mezzano or you have not. You can't have it both ways.
<jackdaniel>
the facts are: there are examples of CL running on bare metal (Mezzano and Movitz as beach mentioned); there were full featured operating systems written in Lisp (on specialized hardwer, so called lisp machines)
<Duuqnd>
beach: Mezzano isn't a standalone CL system like SBCL is.
<jackdaniel>
and these examples relied on the concept of environment
<phoe>
Duuqnd: wtf!?
<phoe>
how isn't it a standalone CL system
<beach>
This discussion is rapidly becoming surreal.
<Duuqnd>
Yeah, I'm getting confused too.
<jackdaniel>
Duuqnd: making such uneducated statements doesn't make you look serious
<zhouzihao>
SBCL is run for a user
<zhouzihao>
but not a kernel
<Duuqnd>
I don't know much about Mezzano tbh. I should probably take a closer look at it.
<jackdaniel>
then on what basis do you state things as they were facts?
<jackdaniel>
as if they were*
<phoe>
Duuqnd: "I don't know how things work, so I'll pretend that I do"
<phoe>
please figure out how things work before publicly stating how they work.
FreeBirdLjj has joined #lisp
<Duuqnd>
How about I rephrase what I said before. Mezzano includes a CL implementation, but Mezzano itself it more than that.
<jackdaniel>
if what you say is: Common Lisp standard does not specify drivers and operating system then you are correct
<phoe>
well, yes, SBCL doesn't include code for dealing with hardware or graphics or its own thread scheduler
<jackdaniel>
but neither C standard does
<Duuqnd>
Actually, just disregard everything I've been saying, it doesn't make much sense.
Davd33 has quit [Remote host closed the connection]
<beach>
Duuqnd: That's correct, it doesn't.
<phoe>
you could theoretically add all those to SBCL and have a functional SBCL-OS
* jackdaniel
is tempted to throw in a statement like "but lisp is interpreted" and watch the world burn ;-) see you later
<no-defun-allowed>
What did I miss?
<Duuqnd>
no-defun-allowed: Me being an idiot.
<Duuqnd>
So nothing interesting, really.
<no-defun-allowed>
I doubt you were being an idiot.
FreeBirdLjj has quit [Ping timeout: 250 seconds]
amerigo has joined #lisp
<no-defun-allowed>
At the very least, if you acknowledged it, you aren't being an idiot.
cosimone has joined #lisp
<no-defun-allowed>
But my 2¢ is that code generated by Mezzano (and I do think Movitz interpreted any functions defined in the OS) isn't freestanding, but the runtime which it utilises works directly with hardware, rather than calling into some other kernel or libc or anything like that.
<phoe>
it isn't freestanding, but neither is GCC-generated code
<phoe>
or clang, or cpython, or ghc, or sbcl, or whatever
<Duuqnd>
phoe: GCC has the -freestanding switch.
jackdaniel2 has joined #lisp
<Duuqnd>
At that point it only relies on the statically linked libgcc.
<no-defun-allowed>
Yeah, there's a very large list of options you have to give to GCC to create "freestanding" code, and you probably want to set up your own cross-compiler to generate proper freestanding code.
<Duuqnd>
This ^. Making freestanding code with normal GCC often ends in disaster.
<no-defun-allowed>
Then I would suggest that CL is more meaningless to compile freestanding than C, but all of the C specific uses of C that you C in kernels are undefined behaviour that the kernel writer likes.
<beach>
It appears that we do not have an agreed-upon definition of "freestanding", so discussing whether some compiler generates such code is not going to lead anywhere until such a definition is established.
<Duuqnd>
beach: I agree. It's hard to discuss things that nobody can agree on the definition of.
jackdaniel2 has quit [Read error: Connection reset by peer]
<phoe>
beach: it seems that it means that freestanding code cannot depend on anything in the OS because there is no OS to depend on - so you cannot call into libc or make syscalls and so on.
cyraxjoe has joined #lisp
MightyJoe has quit [Ping timeout: 276 seconds]
<beach>
phoe: So then, the Mezzano system is freestanding because it *is* the OS, but the Mezzano compiler does not generate freestanding code, because it relies on the Mezzano operating system for its execution.
<phoe>
gcc solves this by bundling/statically linking libc into the generated executables - in theory, so could a Lisp implementation, except it would need to e.g. use BIOS/EFI calls to write/read from standard input and storage
<phoe>
beach: yes, exactly
<phoe>
you don't need to call into the OS if you *are* the OS
<phoe>
Mezzano as an OS is as freestanding as Linux is as an OS
<phoe>
so one could argue that SBCL can generate freestanding code
<phoe>
after all, it can compile Mezzano (;
<beach>
Sure.
makomo has quit [Ping timeout: 252 seconds]
pjb has quit [Read error: No route to host]
Davd33 has joined #lisp
Davd33 has quit [Remote host closed the connection]
davepdotorg has joined #lisp
Davd33 has joined #lisp
<phoe>
okay
* phoe
grabs his scuba gear, takes a dive into CCL's FORMAT implementation
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
<easye>
phoe: Don't forget to time your return to the surface. Don't want to get the Bends from going that deep...
<clothespin_>
good morning
<jackdaniel>
hey
CloseToZero has quit [Ping timeout: 245 seconds]
Davd33 has quit [Remote host closed the connection]
<zhouzihao>
morning?
<zhouzihao>
okay
<clothespin_>
4:30 am
<zhouzihao>
I almost forgot that I am at the other end of the earth.
<jackdaniel>
on IRC people come from different timezones
brown121407 has joined #lisp
brown121408 has quit [Read error: Connection reset by peer]
retropikzel has joined #lisp
<phoe>
good morning/afternoon/evening/day/night are muddy terms on the Tnternet waters
<no-defun-allowed>
"It states that it is always morning when person comes into a channel, and it is always late night when person leaves. Local time of any member of channel is irrelevant. Resistance is futile. Your ass will be laminated."
jackdaniel2 has joined #lisp
jackdaniel2 has quit [Read error: Connection reset by peer]
pfdietz has quit [Remote host closed the connection]
<gaqwas>
I propose good mafendaght as a neutral greeting, independent of timezones
<phoe>
good ,(local-time:now)
ebzzry has quit [Ping timeout: 240 seconds]
<patrixl>
I think "hello" also works ;)
zhouzihao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davepdotorg has quit [Remote host closed the connection]
Guest31 has joined #lisp
Guest31 has quit [Client Quit]
davepdotorg has joined #lisp
maxxcan has joined #lisp
Guest31 has joined #lisp
Guest31 has quit [Client Quit]
orivej has quit [Ping timeout: 265 seconds]
Davd33 has joined #lisp
test1600 has joined #lisp
Guest31 has joined #lisp
Guest31 has quit [Client Quit]
Davd33 has quit [Remote host closed the connection]
wiselord has joined #lisp
CloseToZero1 has joined #lisp
<phoe>
(format nil "~1f" 1234.5) ;=> "1000."
<phoe>
that is on SBCL and CCL
CloseToZero1 has quit [Ping timeout: 240 seconds]
<phoe>
the single trailing zero is not printed
<phoe>
CLHS ~F says: If it is impossible to print the value in the required format in a field of width w, then one of two actions is taken. (...) If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
<Duuqnd>
phoe: That doesn't happen for me.
CloseToZero has joined #lisp
<jackdaniel>
1000. ?
<Duuqnd>
I get "1234.5"
<phoe>
oh wait - on CCL I get 1000.0
<phoe>
I misclicked
<phoe>
on SBCL I get 1234.5 indeed
<jackdaniel>
how 1234.5 is 1000.0 anyway?
test1600 has quit [Quit: Leaving]
<phoe>
I have no idea
flamebeard has joined #lisp
<jackdaniel>
try (format nil "~0,0f" 0.0) :-)
<phoe>
doh
<jackdaniel>
that's a fun one ,)
flamebeard has quit [Remote host closed the connection]
retropikzel has quit [Quit: Leaving]
<phoe>
does that conform though?
<jackdaniel>
no
<jackdaniel>
I've spent some time to fix these issues on ecl
<jackdaniel>
also (format nil "~0f" 14.0) should print 14.0, not 14.
<phoe>
well then, hello from inside CCL
jackdaniel2 has joined #lisp
<phoe>
exactly this, I am now trying to tackle ANSI-TEST format.f.
<phoe>
... format.f.5
<phoe>
oh the irony, I lost a decimal place
<phoe>
anyway, (format nil "~2f" 1.0) ;=> "1." on CCL
CloseToZero has quit [Ping timeout: 240 seconds]
retropikzel has joined #lisp
<jackdaniel>
zero after . should be stripped only and only when d=0
<jackdaniel>
otherwise it msut be printed, because 14. is not a float, minimal number of characters is four not 3 (in that case)
<phoe>
hmm
<jackdaniel>
(unless the part before . is also 0)
<jackdaniel>
then i.e .0 is appropriate
<phoe>
this is some complex machinery that we are touching here
<jackdaniel>
you may take a look at ecl's log, thing was also discussed on this channel
<jackdaniel>
ecl's repository log*
<phoe>
repository log? you mean git log?
<jackdaniel>
yes
<phoe>
OK, I'll consult it if I need to
<phoe>
for now I'll try to understand CCL's format-fixed-aux
retropikzel has quit [Client Quit]
isBEKaml has joined #lisp
retropikzel has joined #lisp
jackdaniel2 has quit [Read error: Connection reset by peer]
ggole has joined #lisp
<phoe>
I assume that (format nil "~1f" 1234.5) should return "1234.5"
<phoe>
since that is what I understand from the above CLHS reading that I've posted
retropikzel has quit [Quit: Leaving]
<jackdaniel>
I don't know what you have posted but your assumption imo is correct
<phoe>
if the float doesn't fit in the required width and no overflow character is provided, then we print everything
<phoe>
CLHS ~F says: If it is impossible to print the value in the required format in a field of width w, then one of two actions is taken. (...) If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
retropikzel has joined #lisp
fanta1 has joined #lisp
<phoe>
-0.0 also shouldn't be printed as "-." I assume
<jackdaniel>
-.0
<jackdaniel>
if 0s are signed
<phoe>
OK
madage has quit [Ping timeout: 260 seconds]
kobain has joined #lisp
davepdotorg has quit [Remote host closed the connection]
davepdotorg has joined #lisp
madage has joined #lisp
kobain has quit [Ping timeout: 252 seconds]
ravenousmoose has joined #lisp
ravenousmoose has quit [Client Quit]
momofarm has quit [Quit: Connection closed for inactivity]
lxbarbosa has joined #lisp
jackdaniel2 has joined #lisp
hjudt has quit [Quit: leaving]
jackdaniel2 has quit [Read error: Connection reset by peer]
Davd33 has joined #lisp
Davd33 has quit [Remote host closed the connection]
ravenousmoose has joined #lisp
jeosol has quit [Remote host closed the connection]
ravenousmoose has quit [Ping timeout: 252 seconds]
ravenousmoose has joined #lisp
<phoe>
oookay, FLONUM-TO-STRING is borked on CCL
<phoe>
it doesn't return five values as its comment-docstring says, but only three
ravenousmoose has quit [Ping timeout: 250 seconds]
jackdaniel2 has joined #lisp
questionq has joined #lisp
jackdaniel2 has quit [Read error: Connection reset by peer]
hjudt has joined #lisp
questionq has quit [Remote host closed the connection]
sammich has quit [Read error: Connection reset by peer]
<ck_>
sigh, what are you doing, phoe? First you spoil the integers with the (loop .. finally) bug. Now this. What are we supposed to retreat to? Character-based programming?
sammich has joined #lisp
sammich has quit [Read error: Connection reset by peer]
<phoe>
ck_: blame ANSI-TEST
<phoe>
if it didn't exist, then I wouldn't have got the idea of fixing CCL up to pass more of these
<phoe>
it is all pfdietz's fault, I tell you
sammich has joined #lisp
<ck_>
your blame redirector is corporate-level. congrats ;)
<phoe>
ck_: no, that is merely startup level
<phoe>
corporate level would be to blame X3J13 for standardizing the behaviour that we are now forced to comply with in order to pass ANSI-TEST
<phoe>
at a startup level, responsibility is individual, so blaming individuals is permitted; at a corporate level, responsibility belongs to groups of people, and so we must grab larger cannons - preferably these who lay the closest to the corporate legal team.
goulix has quit [Remote host closed the connection]
jonatack has joined #lisp
<ck_>
I meant the swiftness of your reply more than its contents -- but the point is taken
Duuqnd has quit [Ping timeout: 245 seconds]
rixard has quit [Ping timeout: 240 seconds]
amerlyq has joined #lisp
Davd33 has joined #lisp
rixard has joined #lisp
bitmapper has joined #lisp
Davd33 has quit [Remote host closed the connection]
lxbarbosa has quit [Ping timeout: 276 seconds]
Josh_2 has joined #lisp
flamebeard has quit [Remote host closed the connection]
jackdaniel2 has joined #lisp
flamebeard has joined #lisp
mark1 has joined #lisp
jackdaniel2 has quit [Read error: Connection reset by peer]
ravenousmoose has joined #lisp
Davd33 has joined #lisp
q9929t has joined #lisp
jackdaniel is now known as JackBea
JackBea is now known as jackdaniel
mark1 has quit [Quit: WeeChat 2.6]
Davd33 has quit [Remote host closed the connection]
mark1 has joined #lisp
ravenousmoose has quit [Ping timeout: 246 seconds]
mark1 has quit [Client Quit]
mark1 has joined #lisp
mark1 has left #lisp [#lisp]
Remavas has quit [Ping timeout: 250 seconds]
Zanitation has joined #lisp
Remavas has joined #lisp
makomo has joined #lisp
manualcrank has joined #lisp
superjudge is now known as mjl
Bourne has quit [Read error: Connection reset by peer]
flamebeard has quit []
Bike has joined #lisp
pjb has joined #lisp
dddddd has joined #lisp
LiamH has joined #lisp
enrio has joined #lisp
<beach>
I am reading this page: metamodular.com/CLOS-MOP/instance-structure-protocol.html and I have a question...
<beach>
Does this page try to tell me that the location of the first slot is 0, or is it giving me the option to start at any other positive integer?
makomo has quit [Quit: WeeChat 2.4]
<beach>
"Locations are non-negative integers. For a given class, the locations increase consecutively, in the order that the directly accessible slots appear in the list of effective slots."
<pjb>
beach: I thought the MOP allowed you to implement objects where the storage of the slots wasn't even in-line!
<beach>
That has certainly been done.
<beach>
But let's restrict ourselves to STANDARD-CLASS.
<jackdaniel>
beach: that paragraph doesn't seem to force starting from 0
<pjb>
beach: this page only says that location>=0 and that for all slots in the effective slot list, location[i+1]=1+location[i]
<pjb>
beach: So if you use 1000, 1001, 1002, AFAIUI, it would be good.
<beach>
Yes, but we also know that the AMOP is not a fantastic specification, so I would like to know whether they just missed that part.
<nirved>
pjb: location[i+1] > location[i]
<pjb>
beach: on the other hand, strangely, this prevents 0 4 8 9 12…
<pjb>
"the locations increase consecutively," What does "consecutively" mean?
brettgilio has quit [Ping timeout: 245 seconds]
<nirved>
pjb: yes, you are correct
ebzzry has joined #lisp
<pjb>
beach: perhaps they meant to start counting from 0. But in presence of superclasses, one could assume that lower slot numbers refer to the slots of the superclass.
<beach>
That's definitely true.
<beach>
It is the effective slots they are talking about.
<pjb>
beach: but the important point is that those "location" indices are purely an API convention. It doesn't mean the slots are stored at corresponding memory location, or in the memory at all.
<beach>
For STANDARD-CLASS I think they are stored in memory.
<beach>
I just tested it in SBCL. They start at 0 there.
<Bike>
technicaly i guess they could be stored in an out of line vector or something. like you have a hash table from objects to storage vectors? that would be a ridiculous implementation, of course
<Bike>
i don't think there's much else in mop that relies on any properties of the instance slot locations, though
<beach>
For my current question, where they are stored is unimportant.
<Bike>
there's slot-definition-location, and (funcallable-)standard-instance-access, and I think that's it?
<beach>
I just need to decide whether I ought to start at 0.
<pjb>
beach: also note that this concerns only "directly accessible slots" which are :allocation :instance and :type t <<< slots of other types could be allocated elsewhere and otherwise.
<pjb>
and are not indexed by those locations!
<Bike>
well, nothing in the text says zero that i can see
<Bike>
and i don't think anything's going to break if you don't start at zero
<beach>
Bike: Correct. If it did, I would not ask advice.
<beach>
Bike: Correct again. Currently SICL slots start at 2. :)
<beach>
And nothing breaks.
<Bike>
the only reason for starting at zero and improving consecutively that i can think of is making it possible to copy an object by iterating from 0 to the effective slot count, and using (funcallable-)standard-instance-access
<Bike>
but that doesn't seem like something library code should be doing anyway, in my opinion
<pjb>
Bike: this would copy only the slots of type T.
<Bike>
...oh huh, i didn't know standard-instance-access didn't work on non-t slots
<Bike>
makes sense of course
<beach>
OK, I think I have all the relevant information to make a decision. Thanks everyone!
sjl_ has joined #lisp
EvW has joined #lisp
igemnace has joined #lisp
Bourne has joined #lisp
jackdaniel2 has joined #lisp
<phoe>
CLHS, ~F: If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
jackdaniel2 has quit [Read error: Connection reset by peer]
<phoe>
What does "the scaled value" mean? If we want to print 1234.1234 in a field of length 3, do we print 1234.1 since that is the minimum, or 1234.1234 since that is literally the value?
<phoe>
pjb: I am talking about the spec, not about what the implementations do.
<phoe>
Because it seems that neither SBCL or CCL complies here, as there are float-formatting ANSI-TESTs that both fail.
<phoe>
So either the tests are broken, or the implementations are.
<phoe>
I'm trying to rule out the first option now.
<jackdaniel>
scale is for multiplying the flat with 10^k
<jackdaniel>
k defaults to 0
<phoe>
jackdaniel: I understand that part.
<phoe>
My question is whether the spec means that we should print the scaled value - in that case, 1234.1234
<jackdaniel>
it should go after the minimum
<phoe>
this might lead to a case when we print 1234.1234 for fields with width 5 but print 1234.1 for fields with width 6
<jackdaniel>
w and d parameters refer to the string lengths
<pjb>
the question is whether the standard specifies w as a width as in number of characters printed, or as a significant digits+dot displayed?
<phoe>
> The parameter w is the width of the field to be printed;
<phoe>
this reads like number of characters printed
<jackdaniel>
that's how it is imo
<pjb>
because once you admit that you will use as many character as you need to print the number (ie. more than w), why should the number still be rounded to w (-1) significant digits?
<pjb>
phoe: not in (format nil "~3F" 1.234567e30)
<phoe>
that was exactly my original question
<phoe>
the moment we the field is too small, what *exactly* do we do
<pjb>
The standard is contradictory: It contains both: "Exactly w characters will be output." and "If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed."
<phoe>
> If it is impossible to print the value in the required format in a field of width w, then one of two actions is taken. If the parameter overflowchar is supplied, then w copies of that parameter are printed instead of the scaled value of arg. If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
<phoe>
pjb: it doesn't contradict itself
<phoe>
"If it is impossible to print the value in the required format in a field of width w..."
<phoe>
> If it is impossible to print the value in the required format in a field of width w, then one of two actions is taken. If the parameter overflowchar is supplied, then w copies of that parameter are printed instead of the scaled value of arg. If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
<phoe>
uh worry
<phoe>
uh sorry*
<pjb>
(format nil "~3F" 1.234567e30) #| --> "1200000000000000000000000000000." |# more or less as specified.
<pjb>
but contradictory.
<phoe>
> If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
<phoe>
if w is too small, then "the scaled value is printed using more than w characters, as many more as may be needed."
<jackdaniel>
"120000." is not a float number
<pjb>
Furthermore!
<phoe>
that seems clear to me except I do not know what "the scaled value" refers to
<phoe>
if w is too small and overflowchar is nil, then we print using as many characters as we need.
<pjb>
the scaled value is 1234567000000000000000000000000.0 for 1.234567e30.
<phoe>
the question is, print *what* exactly
Finnfinn_oops has quit [Quit: The humanity!]
<pjb>
ie, it's not a value, it's a representation of a value.
<pjb>
The scaled value will be printed.
<phoe>
OK
<jackdaniel>
we print the original number times 10^k
<pjb>
well, the scaled value, modulo the rounding to w (-1) significant digits…
<phoe>
so in the original question we print 1234.1234
<phoe>
since that's the original value times 10^0
<pjb>
which is not written down in the specification…
<phoe>
thanks, that solves my issue
<jackdaniel>
phoe: yes, and that, if we take w and d parameters may get shortened
<jackdaniel>
like 1234.1
<phoe>
we already know that w is too small
<phoe>
so in that case we would always need to limit ourselves to the first decimal place
<phoe>
since we can't skip it, because 1234. is not a float
<jackdaniel>
if it is too small than yes
<phoe>
and we can't add any more since that would be more than absolutely necessary
pfdietz has joined #lisp
<phoe>
yes, I only consider the case when w is too small
<phoe>
if we want to "~1F" 1234.1234
<phoe>
then that would result in 1234.1 if I understand it correctly
<pjb>
The problem is that rounding is specified only in the presence of d, but here, we have some rounding done also just for w.
<jackdaniel>
phoe: yes
<phoe>
pjb: there is no rounding done in case of digits before the decimal point, and CCL is wrong.
<pjb>
phoe: probably, yes.
<phoe>
if we can print 1200.0 we could as well print 1234.1 without losing accuracy
<pjb>
yep.
<phoe>
this is exactly CCL's ~F that I am trying to fix right now
<pjb>
phoe: so "~3F" 1.234567e30 should print as 1234567000000000000000000000000.0
<phoe>
yes
<pjb>
ie just like ~F.
<phoe>
that is yet another consequence of CCL ~F being broken
saravia_ has quit [Quit: Leaving]
oni-on-ion has joined #lisp
cosimone has quit [Quit: Terminated!]
cosimone has joined #lisp
random-nick has joined #lisp
bitmapper has quit [Ping timeout: 276 seconds]
jonatack has quit [Ping timeout: 240 seconds]
frgo_ has quit [Remote host closed the connection]
Gnuxie[m] has quit [Ping timeout: 250 seconds]
Jachy has quit [Ping timeout: 250 seconds]
gxt has quit [Ping timeout: 260 seconds]
no-defun-allowed has quit [Ping timeout: 250 seconds]
oxford has quit [Ping timeout: 260 seconds]
sshirokov has quit [Ping timeout: 265 seconds]
madage has quit [Ping timeout: 260 seconds]
igemnace has quit [Quit: WeeChat 2.6]
nonlinear[m] has quit [Ping timeout: 250 seconds]
slyrus has joined #lisp
brettgilio has joined #lisp
sshirokov has joined #lisp
gxt has joined #lisp
madage has joined #lisp
slyrus_ has quit [Ping timeout: 240 seconds]
oxford has joined #lisp
<beach>
phoe: This is silly. We should have an external and implementation-independent library for FORMAT.
isBEKaml has quit [Quit: Quitting...]
EvW has quit [Ping timeout: 250 seconds]
cosimone has quit [Quit: Terminated!]
<phoe>
beach: obviously we should, but I do not suspect that I can convince the implementors to use "the one #'FORMAT to rule them all"
<beach>
You are probably right.
<phoe>
as much as I'd like it to happen, it would be a pretty huge burden to maintain a loadable FORMAT module that suits all implementations
astronavt___ is now known as astronavt
<phoe>
an even larger one to adapt all of them to use that library
<beach>
I am not sure it would be a huge burden to maintain such a thing.
<phoe>
and an even even EVEN larger one to actually construct a library that has all the #+sbcl or #+ccl or #+ecl or #+sicl or #+whatevercl things
<phoe>
there's a lot of implementation-specific declarations in the FORMAT implementations that I've seen so far
<beach>
I can believe that. But are they necessary?
<phoe>
I cannot answer that one - I'm not fluent enough in the internals of all the implementations
<beach>
Sure. It was a rhetorical question.
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.2)]
<phoe>
then also comes the bootstrapping question of when the theoretically-loadable FORMAT is needed inside the implementation's build process
<phoe>
s/loadable/pluggable-in/
<beach>
Indeed.
<phoe>
so that question gets quite complicated quite quickly
<beach>
I have been giving that kind of stuff some thought lately, not for FORMAT but for READ.
<phoe>
eclector, right
<pfdietz>
FORMAT already allows invocation of external functions.
<phoe>
the best system of pluggable modules that we got for Common Lisp implementations is ASDF - that itself depends on Common Lisp
<beach>
pfdietz: What are the implications of that observation?
<phoe>
but using ASDF to swap our components of CL itself runs into the same sort of metastability problems
<phoe>
unless we're willing to have a "secondary" CL running on top of the base one, and ASDF depending on the base one
<phoe>
but that in turn generates a clusterfuck of issues and dependencies that are not easily solvable without first-class environments
<beach>
phoe: I have been thinking that for an implementation that is written in C or C++, a READ is needed to read the code, but that READ can be fairly primitive, because code does not contain all the variations that READ allows for.
<pfdietz>
If you want to extend FORMAT, you can do it that way. Perhaps I'm not understanding the conversation.
<phoe>
pfdietz: the question is about having a FORMAT/READ/whatever implementation that you can swap out for an external one.
<copec>
One FORMAT to rule them all
jackdaniel2 has joined #lisp
<pfdietz>
Ok
<beach>
phoe: Similarly, if FORMAT should be needed during bootstrapping, I am willing to bet that a small subset would be sufficient.
<phoe>
for some self-contained parts of the language such as FORMAT or LOOP that would be easier than for more wired ones
<phoe>
beach: sounds correct
<phoe>
so basically we'd then create a set of DUMB-FORMAT, DUMB-READ, ..., that can be then used to bootstrap a Lisp implementation that can then bootstrap FORMAT, READ, ...
<phoe>
and the DUMB-* ones would be much simpler, just contrived enough to bootstrap stuff
<beach>
phoe: No, that would be up to each implementation to do.
<beach>
phoe: For a new implementation, that could be contemplated from the start.
<phoe>
right, that's what I meant
rgherdt has quit [Remote host closed the connection]
<phoe>
but then again, each implementation would then need to modularize itself
<phoe>
and make LOOP, READ, FORMAT, whatever, easily swappable
<phoe>
that's more work that someone would need to do
<beach>
I think that is the real problem. I think lots of code is specific for reasons of laziness on the part of the original creator.
<phoe>
or they just didn't think that someone would ever want to swap those components out
<beach>
Or that there would ever be any other Common Lisp implementation than theirs worth considering.
<phoe>
I wouldn't attribute it to laziness if there was never a credible *need* for modularity in that matter.
<beach>
The need for modularity arises because we are currently overwhelmed by the collective maintenance burden or all the implementations.
<beach>
Your current work is a very good example.
<phoe>
I still disagree - even if there are ten implementations of a language, it might still be a novel idea that one could want to *dynamically* swap parts of the *language* around
random-nick has quit [Ping timeout: 265 seconds]
<beach>
Er, what?
dale_ has joined #lisp
<phoe>
like, grab FORMAT code from SBCL and plug it into CCL
<pjb>
Having common components wouldn't prevent implementations to try their own versions if they can justify them (eg. for performance or size).
dale_ is now known as dale
<phoe>
FORMAT is a part of the language, and I want to swap it over from one implementation to the other
<phoe>
as an example
<beach>
I'm lost, but it is not terribly important.
<phoe>
okay, backtracking now
<phoe>
yes, modularity would be a decent consideration now
<beach>
If you are right about how specific the code is, swapping that way would be totally out of the question.
jonatack has joined #lisp
Inline has joined #lisp
<pjb>
Well, you can always remove implementation specific code with a standardized API and replace it with implementation independent code.
<beach>
phoe: And why would it be more interesting to completely swap in a different FORMAT than to have a format implemented the way Eclector is, i.e., that there is a CLIENT argument that allows for implementation-specific variations?
<beach>
phoe: Then CCL could create an SBCL client instance and instantly have the SBCL behavior.
<pjb>
There may be difficulties if there are breaches of modularity.
<phoe>
yes, modularity would be a decent consideration for that
<phoe>
but then you would need to define a common format for the modules and a common API for utilizing, loading, unloading them and so on
<phoe>
and enforce that each implementation, internally, respects those
<pjb>
Particularly, in the case of format, it is expected that there is a compiler-macro to deal with it, and this may be implementation dependent.
<phoe>
this does smell ridiculously close to ASDF
<pjb>
(ie. the implementation compiler macro could call implementation:internals-of-format instead of cl:format).
<beach>
pjb: Why would there be breaches of modularity in a freshly implemented library designed to be configurable and modular?
<pjb>
beach: so you would have to modify also the compiler-macro.
<phoe>
if one ensures that ASDF doesn't depend on the implementation's READ, LOOP, FORMAT et al (for instance, by bundling its own ones) then it would be able to load modules for FORMAT, LOOP, READ and such and expose them to the underlying implementation
<beach>
pjb: The compiler macro would be part of this imaginary implementation, of course.
<pjb>
beach: the breach would be in the old code, jumping into the internals of the implementation specific format.
<phoe>
but that already means that we marry ASDF close to each Lisp implementation and use it to load parts of the CL package.
<phoe>
and that already sounds ridiculous enough
<pjb>
beach: one example, with READ, is that to implement the dotted lists, you cannot use CL:READ. You need an internal function. So you cannot replace the reader macro for #\( without having access to the internals of the implementation specific reader.
<phoe>
pjb: why internals?
jackdaniel2 has quit [Read error: Connection reset by peer]
<beach>
OK, I guess I was wrong. Sorry for bringing it up.
<Bike>
the format compiler macro is commonly implemented using internal functions rather than formatter. beach is right that you'd just also defiend the compiler macro for your library, though.
<Bike>
define*
<Bike>
i don't see any problem there
<pjb>
beach: you may be right. It depends on the implementation. With old code (implementations tend to have old code) surprises are common.
<beach>
Obviously, if an old implementation does not want any of its code base to be altered, then it can not take advantage of any external configurable, implementation-independent, modular library to replace its own code.
<beach>
That seems pretty obvious to me.
<phoe>
beach: SICL seems like the only implementation that is not "old"
<beach>
phoe: Notice that "does not want any of its code base to be altered".
<phoe>
beach: that is a function of people, time and money - I don't think maintainers have these galore
<phoe>
or else there might be a big disparity between "want" and "can"
<beach>
But, I already said I was wrong. All implementations are old. None of them would want a single line of code to change. They all use internal stuff for good reasons.
<Bike>
you don't need to be passive aggressive about it
<phoe>
okay, away with the sarcasm for a second
<phoe>
it's more than possible that a lot of that code is just cruft and junk that's accumulated through years of modifications by multiple people
<phoe>
I'm digging through CCL codebase right now and I see kilolines of this stuff
<beach>
Bike: Sorry. Discussions like this make me tired, and I realized I started it, so I wanted to say that I am not interested in continuing.
<phoe>
it would certainly be nice to modularize, document, refactor and otherwise modernize a lot of that code
<Bike>
well that's fine of course
<phoe>
and to make it more sanely bootstrappable - CCL can't even build itself without itself and it will need tons of unspaghetting the code to make even the CCL compiler loadable in SBCL
<beach>
rme hinted that it would be possible, but fairly complicated to remove the dependence on itself.
<phoe>
it would be more than lovely to have all of these features, since, frankly, CCL works and is free software - and that are the only two nice things about its source
sjl_ has quit [Ping timeout: 240 seconds]
<phoe>
it is a massive pile of spaghetti code called the CCL package where everything and the kitchen sink (sans LOOP and parts of the compiler) depends on itself
<phoe>
is it the authors' or maintainers' fault? hell no I don't think so
<phoe>
but up until some point it directly is a function of how much time people are willing and able to spare on making the source code better
<phoe>
at some point when everything is perfectly defined and modular there is little more to do
<beach>
I don't think it is useful to assign blame to any particular individual.
<phoe>
yes, correct
<phoe>
it is not a function of blame at all
ggole has quit [Quit: Leaving]
<phoe>
it is a function of how much time and energy people have to invest into CCL or any other implementation
<beach>
There is one other aspect of all this...
<beach>
It is possible that overall programming style and developer experience evolves over time.
<phoe>
and a bit of anticipation how much foresight into what might be used or useful in the future
<phoe>
that too
<phoe>
CL style has evolved greatly over time, just like the language did
<beach>
And most implementations have roots in pre-ANSI Common Lisp.
<beach>
... so pre-CLOS.
<phoe>
and these roots mean tons of source code
<phoe>
that is also correct
<beach>
Indeed.
<Bike>
thus the totally-not-methods subtypep system phoe has been digging through
<jackdaniel>
format implementations (at least in cmucl, ecl and sbcl) grown from a fairly portable format implementation in cmucl
jackdaniel2 has joined #lisp
<beach>
jackdaniel: Interesting.
<phoe>
a lot of LOOP code is similar, too
<Bike>
all fits in one file too, so that's nice, probably because it was a library at some point in the distant pats
<Bike>
past
<jackdaniel>
fact that code diverges with time is an entropy problem ,)
<jackdaniel>
same goes for PCL CLOS
<phoe>
since there were several prominent LOOP implementations that were then pulled into CL implementations
<jackdaniel>
MIT loop etc
<Bike>
i've already done nontrivial rewrites to the format code clasp got from ecl. ha ha
<phoe>
haha
<Bike>
and clasp's loop code has some #+genera conditionals i haven't bothered removing
<jackdaniel>
and code changes because it has bugs. coming up with a new thing as a portable replacement will be similar with an exception, that the code will use current consensual coding style
<phoe>
well, one ambitious project would be to write a set of common CL modules - FORMAT, LOOP and so on, that are then pullable into CL implementations
<phoe>
and the ambitious part is to make it good enough for the implementors to consider and them perform an actual switch
<jackdaniel>
phoe: that's what SICL project is about
<phoe>
s/them/then/
<phoe>
jackdaniel: I am aware
<beach>
phoe: Er, what do you think some of us are currently doing?
<jackdaniel>
I'm not saying "beach's project" because at this point there are more people involved (vide eclector)
<phoe>
I wanted to stress the second line though
<beach>
phoe: Eclector is a prime example, I think. scymtym is doing a great job.
stepnem has quit [Ping timeout: 240 seconds]
<phoe>
I have seen it, yes
<beach>
phoe: And Xach was able to load SICL LOOP directly into SBCL with the purpose of catching LOOP forms that violate the standard.
<jackdaniel>
my point is that many parts of implementations which are currenlty dubbed "old" grown from independent portable modules (with some conditionalization)
<phoe>
the second point I've made still stands though - the implementations will need to ditch their old code and use the common one
<phoe>
so we'd literally need to reverse the entropy
<beach>
jackdaniel: I think that is right, and I also think it is done that way because they were not written to be configurable.
stepnem has joined #lisp
<phoe>
beach: they weren't - likely no one back in the day thought of that
<phoe>
seems like it's our turn to do that
<beach>
And the reason they aren't configurable may well be that they didn't have the CLOS machinery at the time.
<Bike>
xerox loop is configurable. i don't think anyone's done anything with that besides adding sequence iteration, though
<Bike>
cmucl format is too, really, you should be able to add new characters reasonably easily, if you want
<Bike>
probably not as easy as like a fulll on clos protocol obvs
<beach>
So then I don't understand why it is done the way it is, i.e., copy code and modify it locally.
<phoe>
ease of building
<phoe>
also known as local forks that never get merged into master
<jackdaniel>
beach: I think that there were some object oriented machinery at the time, but from performance perspective there could have been a penalty compared to ordinary functions
<phoe>
"let's just copy format.lisp into our repo and use it"
<jackdaniel>
with fast gf dispatch it will be considerably lower, but still
<phoe>
<ten years of code maintenance pass>
<phoe>
"well shit"
<phoe>
also performance, yes
smazga has joined #lisp
<beach>
jackdaniel: Very plausible.
<phoe>
computers ten years ago were choking on generic functions much more than they do now
<phoe>
twenty, even more
<phoe>
add less-optimized CLOS implementations on top of that
<jackdaniel>
and regarding copying code, well, imagine that the sacred format is maintained by someone somewhere -- that would make building lisp implementations considerably more painful: you need to download implementation and sacret modules to build common lisp
jeosol has joined #lisp
<phoe>
jackdaniel: git has made it much less painful nowadays
<phoe>
but we didn't have git twenty years ago
stepnem has quit [Ping timeout: 240 seconds]
stepnem_ has joined #lisp
<jackdaniel>
still it is painful
<Bike>
clasp had... experiences... with submodules
<phoe>
that is correct
<jackdaniel>
when you fix a bug you'd need to knock and ask nicely
<jackdaniel>
to merge
<phoe>
this is another big issue - you depend on other people for maintenance
<jackdaniel>
etc, having your own copy is far more practical (at least from a local perspective)
mrcom has quit [Quit: Leaving]
<Bike>
we still have eclector as an external sort of module and it's okay, though
<phoe>
even if you find it, you can't fix the bug yourself unless you do what?
<phoe>
surprise - a local fork
<phoe>
and then you leave it there since it's convenient, and so it diverges
<Bike>
with cleavir it's definitely been aided by my having commit access to sicl as well, so i can just fix bugs i find
<phoe>
Bike: so all implementors would need to have commit access to the theoretical LOOP repo
<phoe>
and that is likely to become a mess
* jackdaniel
said everything he had to say, later \o
<Bike>
well, like i said, i don't have commit to eclector and it's been alright.
<Bike>
mostly because scymtym is quite responsive
<phoe>
Bike: that's a complex social issue arleady
<Bike>
well. yeah?
<Bike>
we're all adults here. probably
<phoe>
if the maintainers are responsible and capable and there are no interpersonal wars, then things are easy
<phoe>
but this isn't a guaranteed standard in the software development world
<phoe>
and this is where it becomes complex.
<jackdaniel>
not really, if you have popular software and there is not enough capable developers then review is a time-consuming bottleneck
<Bike>
it's not like implementations are one-person affairs either, usually.
<phoe>
jackdaniel: mancount is also an issue, yes
<jackdaniel>
not mancount but scalability
<phoe>
especially for popular software where you have more issues per day than you can easily count and read.
<phoe>
jackdaniel: yep
<phoe>
okay - anyway
<phoe>
time to do exactly what I shouldn't - copy some SBCL code into CCL to fix some bugs and introduce new ones
* phoe
afk
ravenousmoose has joined #lisp
jackdaniel2 has quit [Read error: Connection reset by peer]
gxt has quit [Ping timeout: 260 seconds]
ravenousmoose has quit [Ping timeout: 245 seconds]
stepnem has joined #lisp
stepnem_ has quit [Ping timeout: 240 seconds]
stepnem has quit [Read error: Connection reset by peer]
stepnem has joined #lisp
orivej has joined #lisp
EvW1 has joined #lisp
stepnem has quit [Ping timeout: 265 seconds]
stepnem has joined #lisp
brown121407 has quit [Remote host closed the connection]
q9929t has quit [Quit: q9929t]
oni-on-ion has quit [Remote host closed the connection]
sjl_ has joined #lisp
Lycurgus has joined #lisp
xkapastel has joined #lisp
brown121407 has joined #lisp
brettgilio has quit [Ping timeout: 250 seconds]
jbreitma has joined #lisp
orivej has quit [Ping timeout: 265 seconds]
stepnem has quit [Ping timeout: 240 seconds]
stepnem has joined #lisp
jbreitma has quit [Quit: Leaving.]
orivej has joined #lisp
bitmapper has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
hhdave has quit [Quit: hhdave]
ravenousmoose has joined #lisp
jackdaniel2 has joined #lisp
seok has joined #lisp
jackdaniel2 has quit [Read error: Connection reset by peer]
<seok>
which json library should i use?
ravenousmoose has quit [Ping timeout: 252 seconds]
<seok>
moving from yason as its documentation site has been down for ages
<fiddlerwoaroof>
scymtym: This traits prototype is amazin
<scymtym>
fiddlerwoaroof: erm, thanks. i didn't really expect anyone to find it. it isn't cleaned up, documented, finished or tested in the slightest
<Xach>
it's in the github lisp rss
<Xach>
you can't escape
<scymtym>
apparently
<ck_>
uh oh, that's a thing?
<fiddlerwoaroof>
Also at least one #lisp person I follow forked it
<fiddlerwoaroof>
Anyways, I appreciate seeing early-stage proofs of concept
<jackdaniel>
I've forked it to not lose track of the project
Necktwi has quit [Ping timeout: 240 seconds]
sjl_ has quit [Ping timeout: 276 seconds]
<fiddlerwoaroof>
I like seeing uses of the MOP that solve problems I've already had :)
<fiddlerwoaroof>
I spend a lot of time attempting to imagine use-cases for funcallable objects, custom method combinations, custom metaclasses, etc., but I usually find it hard to come up with applications that aren't just a different way of doing something that's solved almost as well another way.
<pjb>
fiddlerwoaroof: for method combinations, just realize they are just monads. See how monads are useful in programming in general.
<fiddlerwoaroof>
perhaps, but I find that the standard method combination solves 90% of the problems I already have
<pjb>
Of course. This is why it's in the standard.
<pjb>
But lisp is the language where the 90% that is easy is trivial, where the 9% that is hard in other language is easy, and where the 1% that is impossible in other languages is possible.
fanta1 has quit [Quit: fanta1]
<Lycurgus>
lincoln
<Lycurgus>
sorry
<LdBeth>
There’s nothing impossible given the ability to do meta programming
<Lycurgus>
was thinking about the truth of 'lincoln was the 16th president'
<phoe>
Which part of the standard defines the case in which exponent markers are printed?
<phoe>
I am seeing ANSI-TEST failures because 1.0e+0 was expected but 1.0E+0 was printed and I want to see the part of the standard that defines this behaviour.
<jackdaniel>
I think that you overuse word broken/borked/etc. incorrect would be more appropriate imo
<phoe>
jackdaniel: OK, thanks for the remark
<phoe>
and if that is true, this implies that the ANSI-TESTs that tests exponent marker case are incorrect
<pjb>
phoe: no. It could have, but no.
<pjb>
phoe: sbcl, ecl and abcl use e, ccl and clisp use E.
akoana has joined #lisp
xuxuru has joined #lisp
orivej has joined #lisp
rippa has joined #lisp
bitmapper has quit [Remote host closed the connection]
bitmapper has joined #lisp
rpg has joined #lisp
bitmapper has quit [Remote host closed the connection]
bitmapper has joined #lisp
rgherdt has joined #lisp
ironbutt has quit [Read error: Connection reset by peer]
ravenousmoose has joined #lisp
jackdaniel2 has joined #lisp
bitmapper has quit [Remote host closed the connection]
jackdaniel2 has quit [Read error: Connection reset by peer]
bitmapper has joined #lisp
ironbutt has joined #lisp
ravenousmoose has quit [Ping timeout: 246 seconds]
jackdaniel2 has joined #lisp
jackdaniel2 has quit [Read error: Connection reset by peer]
ravenousmoose has joined #lisp
hiroaki has joined #lisp
vlatkoB has quit [Remote host closed the connection]
bars0_ has joined #lisp
Zanitation has quit [Ping timeout: 240 seconds]
brown121408 has joined #lisp
clothespin_ has quit [Ping timeout: 240 seconds]
brown121407 has quit [Ping timeout: 276 seconds]
bacterio has quit [Read error: Connection reset by peer]
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
mathrick has quit [Ping timeout: 252 seconds]
raghavgururajan has joined #lisp
bars0_ has quit [Ping timeout: 240 seconds]
bars0_ has joined #lisp
jonatack has quit [Ping timeout: 276 seconds]
sauvin has quit [Ping timeout: 252 seconds]
sjl_ has joined #lisp
bars0_ has quit [Ping timeout: 250 seconds]
gxt has joined #lisp
rpg_ has joined #lisp
rpg has quit [Ping timeout: 240 seconds]
cosimone has quit [Quit: Quit.]
mathrick has joined #lisp
cosimone has joined #lisp
brettgilio has joined #lisp
gravicappa has quit [Ping timeout: 265 seconds]
clothespin has joined #lisp
amerigo has quit [Quit: Connection closed for inactivity]
jackdaniel2 has joined #lisp
ark has joined #lisp
jackdaniel2 has quit [Read error: Connection reset by peer]
shifty has quit [Ping timeout: 265 seconds]
<pfdietz>
About json libraries: I've found jsown is much faster than cl-json.
bitmapper has quit [Remote host closed the connection]
bitmapper has joined #lisp
<pfdietz>
cl-json turns names into keywords, jsown leaves them as strings, but even converting them to keywords manually leaves jsown much faster.
<pfdietz>
phoe: it could be those tests should use string-equal
<pfdietz>
(or equalp)
<phoe>
pfdietz: let me prepare a patch then.
<phoe>
string-equal sounds better because of string typechecks
cosimone has quit [Quit: Terminated!]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
gxt has quit [Quit: WeeChat 2.6]
gxt has joined #lisp
doublex is now known as doublex_
puchacz has joined #lisp
<puchacz>
hi, to pass values of dynamic variables (these defparamter / let, I think they are called special variables) to a new thread, I first bind them to local variables in the parent thread like (let ((x1 *x1*)) etc. and then rebind to global symbols again from local variables in the child thread: (let ((*x1* x)) etc. it seems to work.
<puchacz>
can somebody confirm that it is correct please? and is it a portable Common Lisp way or SBCL specific?
<phoe>
if you want to pass literal objects from outside
<puchacz>
phoe, okay, so like in macro
<phoe>
since it calls EVAL on each cdr
<phoe>
so you need a quote to inhibit that
<puchacz>
I see - and it is portable across Lisps I take?
<puchacz>
like the rest of bordeaux?
<puchacz>
and if I just want the same name in car and in cdr of alist elements, it begs for a macro :)
scymtym_ has quit [Ping timeout: 245 seconds]
<phoe>
yes
<puchacz>
phoe, and the way that I described first, is it correct and portable?
<puchacz>
(if you happen to know)
<phoe>
yes, it should be okay
<phoe>
and work across implementations
<puchacz>
thanks!
<puchacz>
is there anything in the standard that (let ...) variables are visible in the child thread or it just a convention that happens to be followed in all major Lisps?
<phoe>
the standard says absolutely nothing about threads
<jackdaniel>
standard does not discuss threads, so it is implementation dependent
<phoe>
the practice is that dynamic variables are invisible unless you explicitly bind them
<puchacz>
I see, so convention that is followed
<phoe>
and lexical variables are visible by standard means - closures
<jackdaniel>
lisp in small pieces discusses various implementations of dynamic bindings
jeosol has quit [Remote host closed the connection]
<jackdaniel>
various /possible/ implementations
<puchacz>
thanks - I am happy to know how the *actual* implementations are to be used :)
<jackdaniel>
then use what bordeaux threads gives you
<jackdaniel>
alternatively you may pass a closure
<puchacz>
jackdaniel - pass a closure from the parent thread to the child thread in a (let ...) variable and it will work, no matter what variables the closure refers to?
<phoe>
exactly what jackdaniel posted, if for some reason you don't want to use bt:*default-special-bindings*
<puchacz>
jackdaniel - that's exactly what I do
<phoe>
these two ways are equivalent
<phoe>
so using bt:*d-s-b* will clean up your code a little bit
<jackdaniel>
phoe: technically speaking they are not. special bindings may tap into implementation mechanism without creating a closure
<puchacz>
yes, I should have read the manual :)
<jackdaniel>
in practice though bt seems to do just that it seems
<phoe>
jackdaniel: tapping into implementation details - how exactly do they pass values into thread functions then?
<phoe>
I mean, if not via a closure
<puchacz>
for a while I thought you were saying I could (let ((x (lambda() (do-something)))) (bt:make-thread (lambda () (funcall x))) - pass a closure like this
<phoe>
puchacz: you could, but that would be roundabout
<jackdaniel>
phoe: I can imagine an interface (silly (format t "going over ~s~%" col)
<jackdaniel>
and then run-process of course, but nvm that
rpg_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<phoe>
jackdaniel: I see
<phoe>
doesn't seem practical, but does seem plausible
<jackdaniel>
closures may be more expensive than ordinary functions and given a particular implementation of a dynamic environment it may be practical (performance wise)
rpg has joined #lisp
<puchacz>
on another note, I rented a (virtual) 32 core server, exported image on my ubuntu there, with an intention to run some numerical computations (driven from my PC, invoked via simple http calls to the remote computer), and the whole thing managed to crash with messages like "CORRUPTION WARNING in SBCL pid 27983(tid 0x7f8ea266f700):" 2 or 3 times
<jackdaniel>
do you by chance run jsown or other library which sets safety to 0 in some functions?
<puchacz>
it is supposed to calculate a goal function for numerical minimisation, each calculation takes parameters via hunchentoot handler, splits work between many threads and then merges result, the calculation takes about 4 seconds.
<puchacz>
jsown, never heard of
<jackdaniel>
I'd grep in my dependencies for (safety 0) to find the culpirt
<jackdaniel>
of course it may be something else
<puchacz>
however it seemed as it was hunchentoot that crashed last time, previous incidents, I did not check - "Session secret is unbound. Using Lisp's RANDOM function to initialize it." and then "Memory fault at 0x7f94e68f8000 (pc=0x536bf253, fp=0x7f8ea266c158, sp=0x7f8ea266c138) tid 0x7f8ea266f700
<puchacz>
The integrity of this image is possibly compromised."
clothespin has quit [Ping timeout: 246 seconds]
<puchacz>
is sbcl stable in true multicore environment?
jackdaniel2 has joined #lisp
<phoe>
on linux, it should be
<phoe>
are you sure that your code is correct and not running with safety off?
<puchacz>
I tried now 16 core virtual computer, I can swap them as they charege per hour
<phoe>
you could (sb-ext:restrict-compiler-policy 'safety 3 3) and recompile all of your code to make sure it is compiled with highest safety
<puchacz>
phoe: will it work and override even if there are "optimised" functions somewhere with safety 0?
<phoe>
puchacz: restrict-compiler-policy is stronger than DECLARE OPTIMIZE
<puchacz>
good
<puchacz>
I shall do it then :)
<phoe>
your code would need to restrict-compiler-policy itself to override it
<phoe>
but that is an absolutely dick move and I'd call it a bug any time I see it
<puchacz>
I can grep all libraries that I use
<phoe>
no sane libraries should do that. I haven't seen any that did such a thing.
<puchacz>
okay :) the thing is that sbcl image loads libssl when hunchentoot starts - I think
<phoe>
so that is a bit of foreign code that can screw things up
<phoe>
give us a backtrace if you get another corruption warning
<puchacz>
yeah.
<phoe>
that will tell us much much more about what is going on
<puchacz>
there is not much, I can paste it somewhere - what I got.
jackdaniel2 has quit [Read error: Connection reset by peer]
enrio has quit [Ping timeout: 240 seconds]
<puchacz>
I typed (sb-thread:release-foreground), the rest is sbcl output
<ark>
puchacz : Are you running this from a lisp image/executable? If foreign memory is still allocated when the image is created (i.e. when `save-lisp-and-die` is called) it will likely crash the image when you start up again.
<puchacz>
maybe safety and debug?
<phoe>
type BACKTRACE
<phoe>
and press enter
<puchacz>
phoe: next time it happens
<puchacz>
and the restrict compiler policy, maybe add debug?
<phoe>
debug 3 and safety 3, sure
Bourne has quit [Ping timeout: 265 seconds]
varjag has joined #lisp
scymtym has joined #lisp
<puchacz>
ark - it is possible that libssl is being loaded when hunchentoot is loaded from quicklisp, not started later. I don't know. it happened only after few thousand calls, unfortunately few times already
<phoe>
puchacz: one second, did you deploy from a binary instead of from source?
mn3m has quit [Ping timeout: 276 seconds]
<phoe>
if yes, how did you deploy your binary? did you close the foreign library before freezing and reopened it after thawing?
<puchacz>
yes, I generated binary on my computer, copied sbcl over to the virtual server and used a command line like this:
<phoe>
HOW did you generate the binary?
<phoe>
did you use Shinmera's deploy or anything else? or just raw save-lisp-and-die?
<phoe>
when you thaw the image, the pointer that refers to that foreign library is no longer valid
<puchacz>
I did what you asked me to do - manually started sbcl with the same memory settings, executed forms one by one except for "deliver")
<phoe>
hence segfaults.
<puchacz>
phew!
<puchacz>
I wanted to try another Lisp in desperation on weekend...
<puchacz>
good old sbcl
<phoe>
another lisp would give you similar results
<puchacz>
how to get rid of it please? maybe I shall read ark's blog entry
<phoe>
there are two ways of doing this
<phoe>
one: in your dumping function, manually close the foreign library; in your reloading function, manually reopen the foreign library before you bring hunchentoot up
<fiddlerwoaroof>
To release a portable linux binary on github releases
<fiddlerwoaroof>
The "easy way" to do this is to use my fiddlerwoaroof/sbcl-static:1.5.8 docker container, because you need to rebuild sbcl with the right options
<puchacz>
doesn't sound like a picnic. I will try ark's solution to unload and load back. but obviously I risk a crash when a user has different library versions