freenode/#lisp - IRC Chatlog
Search
16:40:00
LdBeth
So, my plan is an assembler first, and a non-tradition GC subset of Lisp aims only for high performance, and then layers of Common Lisp for user space applications.
16:41:34
verisimilitude
The C language is used for operating systems because people don't know better and believe others who don't know better.
16:42:01
Xach
seemz: froggey wrote mezzano, which is a lisp os. perhaps that's what informs his perspective.
16:45:46
jackdaniel
maybe that's because I don't know better, but I find Unix philosophy (and implementaitons) decent and very usable
16:46:29
Xach
jackdaniel: the unix-haters handbook is pretty funny and written partly from lisp-machine users' point of view.
16:46:57
verisimilitude
You may as well claim that urinating follows the, say, jackdaniel philosophy; look at how popular and successful your philosophy is, jackdaniel.
16:50:36
jeosol
Anyone here running a CL application on AWS, if so how do you package things up there? docker? After power outage, I am thinking of starting move bits of my workflow to AWS or other options
16:51:01
jeosol
I tried installing SBCL, wine, etc, on an AMI instance, it was a pain doing this one by one
16:51:31
jackdaniel
jeosol: fpm for packaging, clon for binaries delivery and hand-written systemd scripts for daemoning
16:52:09
jeosol
after managing to install sbcl, i figured there as to be a better way of doing this.
16:53:44
jackdaniel
verisimilitude: I disliked you have used eristic 'argument', and yes, I disliked you have used my name in your 'example'
16:55:28
jeosol
ok, I searched google, and a fpm github showed up, no worries, i think he just titled his .README that
16:55:29
verisimilitude
I can be quite eristic when I want, jackdaniel; anyway, I'll avoid using your name, then.
17:01:43
ecraven
what's a good way to pretty-print lisp code into an epub or a black-and-white pdf for reading on an e-reader?
17:04:24
ecraven
the main thing is somehow fontifying strings and stuff, otherwise a plain text file would suffice
17:06:03
froggey
jmercouris: for performance, and then only really for things with tight time-constraints like audio
17:09:00
froggey
interrupts are another issue because the handlers run in a constrained environment (no allocation, no touching memory that might be paged out)
17:09:32
froggey
but this isn't a big deal because interrupt handler generally don't do much. usually they just acknowledge the interrupt on the hardware and wake up a worker thread to do the real work
17:15:10
epony
(regarding device drivers, I think earlier it was mentioned that the target is Common Lisp)
18:40:29
makomo
the relevant part is: `GNU emacs used to greet Symbolics users with the message "In doing business with Symbolics, you are rewarding a wrong."` :-)
19:11:36
_death
https://github.com/emacs-mirror/emacs/search?utf8=%E2%9C%93&q=symbolics&type= doesn't find it, so maybe before apr 1985
19:12:07
_death
does have "Symbolics killed the MIT AI lab; don't do business with them." in the changelog
19:32:31
phoe
Postmodern returns table names as keywords but column names as strings. Is it possible to have it return keywords instead?
20:07:22
phoe
Which ironclad digest should I use for hashing passwords? I don't want to go for SHA1 since it smells insecure to me as of late.
20:08:44
phoe
The current bit of code I have is https://plaster.tymoon.eu/view/754#754 - please bash the hell out of it if you see anything wrong with it.
21:37:00
jcowan
beach: I have just read the chapter on data representation in the SICL manual, and I would urge you to seriously consider the possibilities of nanboxing on 64-bit systems.
22:37:31
jcowan
It's a pretty fundamental decision, and controls whether 64-bit floats can be implemented as immediates.
22:38:59
Bike
is there any chance we could have the log links split up more? both clients i use mess it up
22:41:02
Shinmera
Bike: You can use the same site as for the #clasp logs. https://irclog.tymoon.eu/freenode/%23lisp
22:42:31
Bike
to be nan it has to have all 1s in the exponent, or no? seems like that's cutting down the number of bits a fair amount
22:43:48
jcowan
It's because 64-bit addresses are really only 48 bits wide, or only 47 bits if you exclude kernel space and are not on Solaris.
22:46:03
Bike
well i'm thinking of fixnums. shorter fixnums is fine, but not being able to do arithmetic immediately might be sorta painful.
22:48:12
Shinmera
if the exponent is all ones you can't just directly operate on integers like you can when they're lsb-0 tagged.
22:50:34
Younder
I saw jackdaniels McClim demo yesterday. Pretty cool. Is there a emacs style editor for McClim as the is in CLIM?
22:51:06
jcowan
I agree that doubles are less frequent, but I submit that is because Lisp defaults to single-float and single-float is typically IEEE 32.
22:51:41
Shinmera
Even if the read float type was double float I would still say that integers are far more common.
22:53:48
jcowan
Yes, certainly. I'm just wondering if there isn't suitable trickery for doing integer arithmetic without masking off the high tag.
22:56:53
Shinmera
I'm also not sure I like the idea that performing a bad float op that results in a NAN could suddenly produce something that is interpreted as something other than a double by the implementation.
22:59:02
Shinmera
I would think the quiet NAN is exactly the problem, no? Since then you get a value back that is NAN and might have whatever in the remaining bits.
22:59:23
aeth
I think double-floats are less common than they could be in part because CL is not the best language for double-floats.
23:00:50
jcowan
Shinmera: In this scheme, quiet NaNs are doubles (whose value is the abstract NaN); signaling NaNs are pointers, fixnums, characters, or whatever.
23:01:24
jcowan
Chicken uses a low-bit 1 tag for fixnums (no nanboxing) and does not appear to suffer much performance loss for it.
23:02:21
Shinmera
So how do you catch if a double op produces a nan? Check manually after every double op?
23:02:52
jcowan
this is certainly true of hardware operations, and you can make it true in software by construction.
23:03:02
Shinmera
Yeah but you, as a software man, would probably want to know when your ops suddenly produce nans
23:07:32
jcowan
FP signals are unrelated to signaling NaNs. As far as I can tell, nobody uses the latter for anything.
23:11:31
jcowan
(perhaps Either would be a better analogy, although it is not guaranteed that when you put a QNan through an arithmetic operation, you get the same QNan (in the sense of bits) back.
23:14:26
jcowan
"Unrelated" was too strong. Attempting to operate on an SNaN does indeed raise an FPE *provided* the processor supports that and the FPP is configured to raise SIGFPE (or equivalent) in that case.
23:34:20
jcowan
Shinmera: So no, I don't always want eager detection of problems. Sometimes retrospective detection is the Right Thing, as an invalidity in one part of a complicated operation may not affect the rest of it. But I hasten to add that I am not really a floating-point programmer myself, and am simply repeating what I have been told.
1:04:10
z3t0
hey all, last time I was here I was directed to a diagram flowchart for choosing whether to choose an array/vector etc.
2:23:45
jcowan
beach: My experience (approaching 60) is that I don't *need* less sleep, I just *get* less sleep
2:25:04
jcowan
Did you see my message about nanboxing? It would make fixnum arithmetic a little more expensive but allow IEEE double floats to be immediately represented.
2:26:33
jcowan
The idea is to hide a 48-bit pointer (and all nested spaces such as fixnums etc.) within the 2^52 bits of quiet NaNs
2:34:31
beach
jcowan: Current tagging schemes make fixnum addition and subtraction into a single instruction.
2:35:22
jcowan
Unfortunately I can't help you with that; I was last concerned with assembly language in PDP-11 days.
2:36:38
Bike
not that i'm not also concerned, but i do wonder. the way sicl does fixnum arithemtic now it always involves a branch anyway
2:37:38
Bike
and i mean, that'll probably be slower than a mere arithmetic operation like masking, right?
2:39:55
Bike
What I'm saying is that the additional cost from the nanboxing may be tiny compared to the cost of the overflow check, so using nanboxing might not be so bad.
2:41:23
Bike
I'm saying, if the overflow check is in there, it seems like it would be more expensive than the additional cost due to nanboxing.
2:46:20
Bike
I think you would have the exponent bits all be 1 for the NaN, so the fixnum is in the low 52 bits, maybe with the low two tag. For unsigned fixnums you could machine add them, and then check... some bit for overflow, and then maybe mask it so it's still a proper NaN.
2:47:39
Bike
Well... let's say the highest bit is still sign. Then if there's an overflow, it will carry over into the exponent and then into the sign, so maybe it will trip the machine overflow flag normally.
2:48:44
beach
So if the upper bits are 0 (not counting the sign) then the overflow would never be tripped.
2:51:31
verisimilitude
Wouldn't it be more pleasant and more efficient to implement integers seperately?
2:51:55
verisimilitude
That is, tell the machine to use integer instructions when only integers are involved.
2:51:59
beach
verisimilitude: You can't do it separately if you want every Lisp object to be a word.
2:53:02
verisimilitude
See, what I'd do is simply limit the precision of floats until it was convenient.
2:53:57
beach
verisimilitude: I mean, yes, you can do that, but then you would have your own float format.
2:54:25
rme
The good thing about single floats is that it's pretty easy to arrange to make them be iimmediate data on a 64-bit Lisp.
2:54:44
verisimilitude
The current suggestion seems to be to do what JavaScript implementations do, with careful checking.
2:56:09
jcowan
With machine performance *and* no boxing *and* decent precision, floats might be more popular
2:57:06
beach
My current thinking is that it is rare to do double-float arithmetic on values that are passed as arguments and return values. With so called "aggressive" inlining, my guess is that most such arithmetic would be on arrays or on unboxed lexical variables.
3:00:31
beach
Like I said, I think most double-float arithmetic in Common Lisp would be on arrays specialized to double float and on unboxed lexical variables.
3:03:09
beach
Anyway, since all of SICL is implemented in Common Lisp, the exact representation of things is visible in a very small number of places, I don't think this is a decision that has to be made a priori.
3:08:02
beach
In fact, one can even imagine several SICL variants. One could be optimized for double-float arithmetic and another for fixnum arithmetic.
3:08:43
beach
Such a thing would be much harder with a system that has representation information spread all over the code base.
3:48:39
beach
LdBeth: Why would start at such a low level, and why would you build a non-GC system first?
4:29:05
beach
epony: LdBeth wrote this: <LdBeth> So, my plan is an assembler first, and a non-tradition GC subset of Lisp aims only for high performance, and then layers of Common Lisp for user space applications.
4:31:59
beach
epony: I am worried that LdBeth is planning yet another implementation that is built up from some lower-level code. I have seen how writing such an implementation is very painful, and it results in code that is not very maintainable.
4:32:38
beach
epony: I am particularly worried, because there seems to be widespread belief that this is the only way to create a Common Lisp implementation.
4:34:18
epony
I would qualify that down-up approach an exercise in pre-processors for assembler though, with lisp driven something above it.
4:36:58
beach
Well, here is why I am worried: At some point, Common Lisp code has to be evaluated. That requires an interpreter or a compiler. A compiler can not be reasonably written in anything other than Common Lisp. So the bottom-up approach seems to call for an interpreter. But then, as we know, interpreters are slow. So then a compiler is needed anyway. And now you have two evaluators.
4:37:30
epony
It will be interesting to me for the sake of curiosity if this has any practical realisation, or it is a plan that may be difficult to follow up as you explain.