<gilberth>
The arguments are new-byte, byte-spec and "old value". So for instance (DPB x (byte 8 4) y) would deposit x in the bits 4 to 12 in y and return the new integer.
<gilberth>
It basically is the same as your LOGIOR/ASH combination. But for my taste it is clear, once you understood DPB.
<gilberth>
moldybits: Well, you understood LDB, right?
<moldybits>
who knows!
<gilberth>
moldybits: A byte here means a sequence of bits within an integer as specified by (BYTE size position)
robdog has joined #lisp
<gilberth>
moldybits: Like a field within an integer, so to speak.
<ebrasca>
(byte 1 10) is like 1 bit place 10
<ebrasca>
moldybits: ^
phenoble has joined #lisp
<moldybits>
ah ok. that makes sense. i was confused because it first made use of the bytespec for first argument, so i thought bytespec referred only to that.
robdog_ has quit [Ping timeout: 264 seconds]
<ebrasca>
gilberth: Now I can rewrite some of my code using DPB.
<Xach>
i like logior sometimes because it takes many arguments if you like
robdog has quit [Ping timeout: 264 seconds]
mange has joined #lisp
<gilberth>
Xach: That is true. DPB gets a bit nested, when you, say, combine four octets to a 32-bit word. But I still like it.
<ebrasca>
If you combine 2 numbers I think DPB is fine.
<gilberth>
Xach: As in an LOGIOR/ASH combination, the size of the byte to stick in is not communicated.
<Xach>
gilberth: a wrapper of logand can sometimes clarify
<gilberth>
Xach: Yes. But still pretty much C'ish as you have to remember that #xFF has eight bits turned on.
<Xach>
#xFFFFFFFFFFUUUUUU
akoana has left #lisp [#lisp]
robdog has quit [Ping timeout: 264 seconds]
<Xach>
(1- (expt 2 bits))
<gilberth>
Xach: Did you mean 0xFFFFFFFFFFFFFFFFULL? I like the "full" in there :-)
<gilberth>
Xach: (LDB (BYTE bits 0) -1)
smasta has quit [Ping timeout: 259 seconds]
<Xach>
so many options! that is why every person is a lisp unto themselves
<Xach>
i do think the number of options and the personal choices made between them can fingerprint lisp hackers
<no-defun-allowed>
obviously this is why lisp is dead, cause there's too many options, argh! how do you ever get any work done! /s
<gilberth>
Xach: Sure. And perhaps I am indeed a bit old fashioned. I still use CAR and CDR. And sometimes even DO and DO*
<Xach>
so much work is done because my way is the best
<Xach>
gilberth: how about rplaca/d? :)
<gilberth>
Xach: Indeed, it seems like every lisper suffers from the not-invented-here-syndrome.
smasta has joined #lisp
<gilberth>
Xach: I discovered the SETF macro recently.
<Xach>
gilberth: it has promise. i think it will not be deprecated in the next cl standard.
<ebrasca>
gilberth: Why it is old fashioned to use do?
<gilberth>
Xach: Will there ever be a next CL standard?
<verisimilitude>
Oh, you think there's going to be a new CL standard?
jb__ has quit [Ping timeout: 245 seconds]
<verisimilitude>
Tell me some more jokes, if you've any.
<gilberth>
ebrasca: We have LOOP now! And by the way, functional programming seems to fashionable these days.
<ebrasca>
gilberth: I like do , iter , loop and others.
<gilberth>
ebrasca: So better use LABELS to formulate your loops. :-)
<verisimilitude>
The next CL standard should support Unicode, have built-in HTTP support, and let's do away with pathnames, because it's all Windows and UNIX anyway, right?
<ebrasca>
What about mezzano OS?
<gilberth>
verisimilitude: pathnames are fine IMHO. But drop logical pathnames.
<Xach>
gilberth: yes
jb__ has joined #lisp
<gilberth>
Xach: OK, who will write CLtL3 then? Or would that be CLtL4?
<verisimilitude>
Also, the next Common Lisp standard should rename FORMAT to printf and change parentheses to curly braces, to attract C programmers that Common Lispers care so much about.
<ebrasca>
I like to have someting like (read-le/byte vector offset byte-size)
<gilberth>
verisimilitude: That lisp you are thinking about is called JavaScript.
<Xach>
gilberth: kent pitman???
<aeth>
Both sides of the new CL standard debate are wrong. (1) there can and will be a new standard eventually because it doesn't have to be through one of those expensive official standards bodies: it can just be organized over the Internet like with Scheme
<aeth>
and (2) it won't be very radical at all when it happens, it will just solidify features that the major implementations are slowly adding anyway and the most radical changes will probably be aimed at the FP crowd
<ebrasca>
verisimilitude: (never I like my parens)
smasta has quit [Ping timeout: 255 seconds]
<verisimilitude>
I'd like to have my own implementation by that time any such thing happens, so I can properly resist and kneecap anything I don't like.
<Xach>
ebrasca: it is not hard to get what you like
<aeth>
verisimilitude: the only implementation with real weight in a new standard will be SBCL, unless things change significantly between now and then
<ebrasca>
I like parts of cl21 but there are parts I don't like ...
<gilberth>
Xach: Really? Has he plans to do that? Or are you just kidding?
<verisimilitude>
Fortunately, aeth, Common Lisp has multiple implementations.
<Xach>
gilberth: i am just kidding. who knows what the future holds?
notzmv has joined #lisp
<verisimilitude>
It's not as if SBCL has any issue with adding whatever it wants now, anyway.
<aeth>
ebrasca: the worst part about cl21 imo is the name. What if the new standard of Common Lisp is released in 2021?
<Xach>
aeth: i don't think the people who make and use allegro and lispworks would agree.
<Xach>
gilberth: we might get seven new CL standards in two years! all written by peter norvig and rms!
<aeth>
Xach: good point, their apparent lack of market share can be made up for by their money so they'd probably have near-equal standing to SBCL
<gilberth>
Well, a lot of CL implementations share features like unicode support and multithreading. And we have some libraries, which abstract about the several implementations.
<ebrasca>
mmm
<gilberth>
Xach: Has RMS been replaced by aliens recently?
<verisimilitude>
There's a difference between supporting Unicode characters and supporting Unicode, gilberth.
<ebrasca>
maybe some automatic systax for cl
<Xach>
gilberth: i have not checked
<ebrasca>
you can have your cl systax or c one.
<verisimilitude>
I know this is unintuitive, but the Unicode consortium is run by idiots, so that should have it making sense.
<aeth>
gilberth: unicode is a lot weaker than threads. Afaik, there is no portable equivalent to sb-unicode
<ebrasca>
aeth: Why you can't port sb-unicode to all others?
<aeth>
ebrasca: That would be the correct solution imo
<gilberth>
aeth: Well, I can live with the minimal requirement, that I can read and write UTF-8 files and have an :EXTERNAL-FORMAT argument to OPEN. In 1998 or so, it was real pain. In my web browser I resorted to treat every stream as an octet stream and used integers for characters, because everything was just 8 or 7 bit. [Which really is more about bivalent streams.]
* ebrasca
can't read 12bits bytes LE from octet vectors ...
<moldybits>
didn't you just implement that?
wanz has joined #lisp
<gilberth>
aeth: Yes, and digraphs and trigraphs. Which I actually used in Pascal in the 80ies as my computer displayed german umlauts, where [,],{,},|, and \ are.
<verisimilitude>
I can see Unicode being made pseudo-standard, but not standard.
<ebrasca>
aeth: Yea I am doing 3 by 3 and save 2 by 2
dale has quit [Ping timeout: 245 seconds]
<White_Flame>
I have a very simple format in my 8bit stuff that lets you stream 1, 2, 4, 8 bit values without ever crossing bytes
<White_Flame>
not sure if that would be applicable for reading 8bit + 4bit fields
<aeth>
no-defun-allowed: If CL gets revised in 2021, it will be called CL22 to avoid name conflicts.
<White_Flame>
CL revisions shoudl be called (CL) then ((CL)) etc
<aeth>
Fortunately, this theoretical issue is increasingly unlikely because a 2021 release would probably need to be organized *now* and there's no indication of such a thing going on in #sbcl and #ccl and #ecl
<no-defun-allowed>
I'd rather use the TAKE-NEW restart myself.
<ebrasca>
We can start now!
<no-defun-allowed>
Though, that's not portable. Hopefully CL2021 will cover that.
smasta has joined #lisp
eschatologist_ is now known as eschatologist
<gilberth>
I think the only chance is, that some writes down CLtL3, alone. Because I guess there will never be agreement. Everybody could do that. Just provide a CLTL3 package and be set.
<no-defun-allowed>
Also, hopefully it will include the WITH-YEET macro to fully utilise the newly standardised Unicode support.
<aeth>
ebrasca: You would need to get beach, drmeister, jackdaniel, stassats, and several other key people to agree on starting the process for coming up with a new standard. You would also need a way to contact people not on IRC that would be nice to involve, like one representative each from LispWorks and Allegro.
<ebrasca>
aeth: I have 1 email server.
<aeth>
(Of the two, LispWorks is far more important because they host the de facto standard, the HyperSpec, so you would probably want them to host or link to a copy of any successor document.)
jack_rabbit has quit [Ping timeout: 264 seconds]
<gilberth>
aeth: I do not believe, we would need the vendors.
<moldybits>
ebrasca: aren't you doing BE?
<verisimilitude>
I think we can all agree to disagree.
<gilberth>
It is not like new features are really needed, just a _common_ API. There is a reason Common Lisp is called _Common_ Lisp.
groovy2shoes has joined #lisp
<ebrasca>
moldybits: No idea if BE of LE.
<ebrasca>
Is common lisp now common of all lisp?
<verisimilitude>
It's certainly not Clojure or one of the Schemes.
<gilberth>
That was the original idea of Common Lisp.
<aeth>
gilberth: new features really *are* needed, though... mostly in immutability and other things that languages have focused on post-CL that can't really be easily added as a library.
<gilberth>
Clojure is a mental sickness and no Lisp.
<moldybits>
ebrasca: lines 10-12 you're placing byte0 and upper half of byte1 into the most significant half of the 24-bit byte?
<gilberth>
I mean they took the fun out of Lisp with spelling DEFUN without an #\U.
<gilberth>
aeth: This is too far fetched for my taste. I really would like a common API for multithread, for instance.
<gilberth>
aeth: ing, even.
<ebrasca>
moldybits: It is someting left from my first try.
<verisimilitude>
The biggest issue with standardizing much of anything such as this, gilberth, is standardizing it correctly.
<moldybits>
ebrasca: maybe try splitting it up into smaller functions?
<verisimilitude>
What's the correct multiple thread API?
<no-defun-allowed>
verisimilitude: Sure, but Scheme is far detached from most Lisps, and Clojure is a truckload of shite that came out close to twenty years after CLtL.
<no-defun-allowed>
bordeaux-threads?
<aeth>
gilberth: bordeaux-threads is a fairly solved problem. Some things simply can't be solved easily via portability libraries, like immutable strings or typed (i.e. non-generic) conses
<verisimilitude>
What's the correct network API; Common Lisp could've ended up standardizing Chaosnet support, couldn't it? Where would that be then?
<gilberth>
Much more important is: What are the semantics? What is atomic and what not? What are the sequence points.
<gilberth>
aeth: Guess, who proposed bordeaux-threads.
CrazyEddy has joined #lisp
<moldybits>
why does this need to be standardized?
<aeth>
no-defun-allowed: scheme and common lisp would, with the exception of call/cc, basically be the same thing with different names for the shared features if it wasn't for the lack of guaranteed TCO in CL.
<no-defun-allowed>
Really?
<aeth>
no-defun-allowed: I won't judge the quality of Clojure, but it's very, very different and I wouldn't describe it as "basically the same thing with different names"
<moldybits>
like, what would standardization solve?
<verisimilitude>
Clojure doesn't have proper error handling or even good parameter support.
<no-defun-allowed>
Scheme is a lisp-1, CL is a lisp-2, CL is probably more useful for imperative/procedural code if you need it, etc, etc
<no-defun-allowed>
Though, Scheme solves that by making iterative functions very convenient, but I don't think Maclisps and Scheme are particuarly reconcilable.
<gilberth>
aeth: bordeaux-threads basically is CLIM-SYS.
<aeth>
moldybits: Common Lisp's culture is very big on portability between implementations. If SBCL alone implements something, you probably won't see it used directly or indirectly in Quicklisp.
<aeth>
moldybits: Standardization lets you use stuff that's (probably) already there in some implementations
<verisimilitude>
ABCL lacks TCO, as one good example of how even standardizing that would be poor.
<no-defun-allowed>
However, I wouldn't mind the lack of a thread API in CLtL3/CL2021/etc, since threads are quite hairy to work with and there are probably better ways to manage parallelism.
<gilberth>
IMHO Common Lisp also is about compatibility with the past. I love it, that I can run old code of mine from say 1992 in a current implementation.
<aeth>
verisimilitude: "Standardizing TCO" would probably work a lot like how :element-type in an array works. If an implementation doesn't support :element-type (complex double-float) it will just be a T array instead of breaking things.
<verisimilitude>
That's already how it works, then.
<verisimilitude>
It's already an optional optimization.
jack_rabbit has joined #lisp
<aeth>
verisimilitude: So the best way to standardize TCO, which would still kind of be bad, would be to simply be able to say something like e.g. (declare (optimize (tco t))) which would only work if TCO is even available, but which would force TCO on even if e.g. (debug 3)
<gilberth>
TCO is a hard topic, as you would need to specify exactly, what is a tail position.
<verisimilitude>
About the only nonstandard thing in Common Lisp I regularly use is a stream element type of (UNSIGNED-BYTE 8), because it seems supported everywhere and fighting over that generally isn't worth it.
<aeth>
verisimilitude: essentially a standard TCO would still be optional, it would just be portable, deterministic, and explicit about how to turn it on if it's available at all, imo
<no-defun-allowed>
Although, TCO might not be so useful if CL already supports possibly clearer iteration constructs like LOOP and REDUCE.
<verisimilitude>
When a function is called in a tail position, it's optimized to a jump instead of a call, effectively
<verisimilitude>
.
<ebrasca>
I like TCO.
<aeth>
verisimilitude: oh, and (unsigned-byte 8) being added to the required list next to bit and character would be an important thing to add to the next standard
<Duns_Scrotus>
aeth: just write a billion-deep recursion before the defun
<djeis[m]>
You can kinda solve it with macros anyway.
<verisimilitude>
I'd go further than that, aeth.
<verisimilitude>
I'd want any UNSIGNED-BYTE to work properly, not just 8.
<djeis[m]>
There are macros for writing loops in tail-recursive style.
<verisimilitude>
I should be able to write a file bit-by-bit.
<gilberth>
TCO is not just about loops.
<verisimilitude>
I should be able to nibble-by-nibble or hextet by hextet.
<djeis[m]>
That's why I said kinda solve it 😅
<verisimilitude>
It's a general optimization, not just concerning recursion, yes, which many don't understand at first.
<aeth>
verisimilitude: two issues. stuff above 8 that aren't multiples of 8 are unlikely to work exactly in existing implementations unless there's some quirk (like it's the 32-bit fixnum size for that implementation even if you're in the 64-bit version of it) and you basically can only go up to the word size (32 or 64) atm afaik.
<aeth>
verisimilitude: right now element-type is essentially just a space optimization... i.e. types-for-performance, not types-for-reliability
<gilberth>
I actually do not like the idea to, say, support to read hextets. We live in a world, where "bytes" are octets. Every system adopted that. The times, that you find 6-bit bytes or 18-bit words are long gone.
<aeth>
Personally I'd love arrays of (integer 5 97) or whatever, even if obviously they can't be stored like that internally. That's just not how implementations think of element-type, though.
<aeth>
More typed slots/storage like that means less type declarations/checks in your code.
<aeth>
I'd also like :type in defstruct and defclass to be a mandated check (atm, defclass in SBCL is only checked if the defclass is defined with (debug 3) or some non-default thing along those lines because, again, types-for-performance, not types-for-reliability)
<verisimilitude>
You can have an eight bit buffer, aeth.
<verisimilitude>
I just don't like that, in my Common Lisp, I need to buffer this manually if I want I/O not in terms of eight bit bytes.
<verisimilitude>
Anyway, the same arguments in support of whatever the current machines do is the same argument against things such as bounds checking.
<no-defun-allowed>
Using MIPS 1, one cannot read words smaller than 32 bits to my knowledge.
<no-defun-allowed>
Does it use 32 bit bytes then?
<gilberth>
verisimilitude: I disagree here. When you say, :ELEMENT-TYPE 'BIT to OPEN. What would the endianess be?
<no-defun-allowed>
Oh, it wasn't MIPS 1. I remember some architecture had larger "bytes" though.
<verisimilitude>
It would be big endian; I can argue for it.
<gilberth>
no-defun-allowed: It does. Like in B, 'char' was a function.
<aeth>
no-defun-allowed: You can go 32 -> 8 and 32 -> 16 fairly easily.
<gilberth>
verisimilitude: I'd argue for little endian. Big endian is the wrong way around :-)
<aeth>
verisimilitude: I don't think a new standard would help you even if you participated. I have a feeling you'd be in the minority of a vote a lot of the time.
<verisimilitude>
Frankly, aeth, I expect it would blow up in everyone's face as it has in any other attempt.
<no-defun-allowed>
I also recall PIC16 microcontrollers use 12-bit program ROM.
<verisimilitude>
The simple fact is ANSI CL is what's actually a standard and so what everyone would still use unless all or most implementations supported it.
<gilberth>
Yeah, and this is the problem. We are discussing _new_ features here. I won't go for new features, but I would like to standardize, what almost all implementation already offer and not create a new language with new semantics.
<aeth>
verisimilitude: You would need the developers of SBCL and CCL on board to any new standard. Without them, you cannot have one with any legitimacy. With just them (though obviously you'd want more involved), they could probably push forward against any opposition and get the features to a supermajority (or close) of CL programmers.
<verisimilitude>
This is beginning to sound like what happened to the WWW, aeth.
<verisimilitude>
Replace SBCL and CCL with Google and Mozilla.
<aeth>
Well, yeah, with the WWW you have something that can only be implemented by like 4 groups.
<aeth>
And soon 3 since Microsoft gave up
<gendl>
This University of Genova system for paying for ELS is a goddam nightmare.
<gilberth>
You could always open a new buffer and say (defpackage :cltl3 ...)
<verisimilitude>
Sure, gilberth, and I could agree with adding some primitives that certain libraries need, but when you get to things such as supporting Unicode you get something that's going to upset most everyone.
<verisimilitude>
Do you support UTF-8, as most UNIX-likes use, or UTF-16, as Windows has?
<gilberth>
Perhaps.
<no-defun-allowed>
Yeah, CL isn't impossible to implement from scratch, unlike HTML+CSS+JS.
<aeth>
gilberth: as far as new features go, I would personally support them, but only for things that could not be efficiently implemented as a library (including one involving elaborate regular macros and reader macros)... probably involving things like the type system, e.g. immutability
<gilberth>
aeth: You still want to extend the language, don't you?
<verisimilitude>
Now, gilberth, when it comes to octet output, how would you write a big endian or little endian value? You write out the octets in the order you really want. The same can be written for bits.
<gendl>
half in Italian and half in broken English...
<gendl>
and apparently I can't use my Dutch ATM card with Maestro...
<gilberth>
Take weak pointers for instance. Most implementations support at least weak hash tables. I'd like that to be standardized. And be it a CLTL3 package.
<gendl>
have to pay from U.S. dollar credit card even though the fee is in Euros and I have Euros sitting in a Dutch account...
<verisimilitude>
It seems good to specify big endian for bits, since that's the ``left-to-right'' order you'd use for reading or writing and let that be that.
<gilberth>
verisimilitude: Sure, and that is what I usually do, even in C.
<aeth>
gilberth: This is Common Lisp, so a standard should be thinking one level more meta... not extending the language but providing ways to extend the language. By this standard, incf shouldn't even be there (obviously it's grandfathered in, though) because define-modify-macro alone is sufficient.
jbayardo has quit [Quit: Bye!]
<aeth>
gilberth: stuff like weak hash tables *do* have to be there, though, because hash tables are built-in
<gilberth>
verisimilitude: But, that is not the order you process them. I do not want to argue about this big/little-endian debate.
<verisimilitude>
Sure, it's not worth arguing over.
<gilberth>
verisimilitude: BTW the arabic script is right to left. :-)
<verisimilitude>
Sure, but Common Lisp is an English language.
<verisimilitude>
FORMAT has standard support for generating English.
<gilberth>
verisimilitude: Still we write our numbers the wrong way :-)
<verisimilitude>
How?
<aeth>
verisimilitude: when you add or multiply, you go right-to-left.
<gilberth>
Because we use arabic digits and arabic is written from right to left.
<gilberth>
Since we write the numbers the same way as they do, we read them the wrong way.
<verisimilitude>
When you subtract, you go the other way.
<gilberth>
verisimilitude: Since when?
<aeth>
Addition and multiplication are more fundamental than subtraction and division, though.
<gilberth>
I substract from the right.
<aeth>
(And I think division is left-to-right but subtraction is right-to-left, so it's 3/4 rtl)
<gilberth>
division on paper is fake anyway.
<verisimilitude>
Also, the network order is big endian.
<verisimilitude>
Big endian is much nicer to read if you're looking at a memory dump, you know.
<aeth>
Again, though, mixed/middle/pdp endian is the one true endian, the debate was settled years ago, we shouldn't keep it going.
<gilberth>
verisimilitude: Yeah and my machine is little endian. This is the reason, why I am always explicit about the byte order, even in C. You find external formats (file formats) either way. But the octet as the unit of transfer of information stuck. And I believe it will stick for a long time.
<verisimilitude>
Well, we both agree that octets suck for this.
<ebrasca>
My machine is both little endian and big endian.
<aeth>
gilberth: I think the file formats one is more important. I wouldn't be surprised if it's 50/50
<ebrasca>
You can change from big to little with 1 instruction of cpu.
<gilberth>
aeth: Perhaps as folks like verisimilitude like to be able to "directly" read their numbers in a hex dump.
<ebrasca>
I like to , it help to write FS support and other thinks.
<gilberth>
ebrasca: Yes, but I don't do that. I am always explicit about that. I just hate this "#if LITTLE"/"#if BIG" business. The files comes in octet per octet, right?
<aeth>
gilberth: I suspect that the split you see in file format is between people who think like the network (or think naively) vs people who think like the (probably little-endian) machine.
<aeth>
s/file format/file formats/
<gilberth>
aeth: Well, actually I do not care. If the file format is specified as big endian, so be it. And I do not care, which endianess my machine has.
<gilberth>
aeth: My code always is formulated in a way, that you could throw that at a big endian machine, and it would still work. Besides, this is not so much an issue in Common Lisp because you cannot have these horrible casts like in C.
<moldybits>
i'm reading from a stream with read-byte. is there some way i can construct a binary input stream from an array or string, for testing purposes?
<Xach>
some formats mix both endianness
<Xach>
moldybits: flexi-streams can do that.
<gilberth>
My point really was, that these days, you have a hard time to find an 18-bit machine, with 6-bit characters.
<gilberth>
moldybits: Not in a portable fashion.
<aeth>
gilberth: not true, you just need to be more clever about it, probably through CFFI abuse to mimic C-style casting
<aeth>
I hope I uploaded the correct version. I did it a long time ago
<fiddlerwoaroof>
aeth: Allegro and Lispworks lack of market share is mostly a illusion from working in the open source lisp community
<aeth>
Oh and I did (safety 0) just to make it semantically identical to C. Iirc, it is not required to be (safety 0) to function.
<verisimilitude>
>in pure CL through CFFI abuse
<verisimilitude>
That's not pure CL, then.
<fiddlerwoaroof>
The lispworks mailing list is pretty active, for example
<aeth>
fiddlerwoaroof: But they're in their own ecosystem, so they're irrelevant to what we do.
<fiddlerwoaroof>
Well, I like submitting issues for lispworks support because I bought a license
<aeth>
verisimilitude: It is, afaik, pure but not portable CL.
<aeth>
Well, it's portable, but not standard. CFFI is probably the most implemented portability library, though
<verisimilitude>
I usually use ``pure'' to mean ``standard'', but alright.
<fiddlerwoaroof>
And, at this point in time, it's the best implementation if you want to write cross-platform GUIs
<aeth>
verisimilitude: what I meant is that I'm not calling to C
<aeth>
which is what you're supposed to do with CFFI :-)
<fiddlerwoaroof>
(and, given the emphasis on standards compliance among lispers, one generally doesn't need to do much work to maintain compatibility)
<gilberth>
aeth: Also here i disagree. Only because I am into free software, does not imply that I won't consider say Lispworks to write a Lisp application, which runs under Windows to pay my rent.
<fiddlerwoaroof>
Anyways, I'm happy to pay for a Lispworks license because it's a high-quality implementation of an standard with open source alternatives.
<fiddlerwoaroof>
It's not like Ada or Eiffel where the only reaonable implementations are locked away (if you don't want to write GPL software)
<verisimilitude>
I've been mulling over buying a license, but I don't know if I should pick Lispworks or Allegro; I suppose you recommend Lispworks, fiddlerwoaroof?
<fiddlerwoaroof>
CAPI makes me prefer Lispworks. Also, should I ever try to make money with lisp, the LW license is much more reasonable than the Allegro one
<fiddlerwoaroof>
(allegro charges a percentage of revenue)
<aeth>
I only support 64-bit implementations so I explicitly don't support the commercial implementations. I think they both require a purchase for 64-bit.
<gendl>
fiddlerwoaroof: in our case, Allegro is reasonable.
dale has joined #lisp
<verisimilitude>
Well, Grammarly just uses SBCL, but they also don't deliver the actual program, which helps.
<fiddlerwoaroof>
aeth: /shrug as long as you accept patches...
<aeth>
If I went commercial, I'd use SBCL. It has the best licensing terms.
<gilberth>
aeth: GUI? I still didn't finish my CLIM implementation.
<gendl>
Yes Allegro uses a revenue-sharing arrangement, but you can also depend on their support and know that you're not going to be nickel-dimed for support. The cost is predictable and commensurate with revenue.
<fiddlerwoaroof>
gilberth: I'm not sure if you're aware, but there's been a recent uptick in activity on McCLIM
<gendl>
sometimes a long time goes by and we don't need support, but when we need it, we need it NOW.
<aeth>
gilberth: If I went commercial with CL it would either be (1) web or (2) a game using cl-opengl, neither of which requires a GUI.
<gilberth>
aeth: If I were to implement some web based application or something like that, I would be happy with the free implementation.
<fiddlerwoaroof>
gilberth: there's even an irc channel #mcclim
<aeth>
s/requires a GUI/requires a GUI framework/
<fiddlerwoaroof>
gilberth: there's even an irc channel #mcclim
<fiddlerwoaroof>
gilberth: there's even an irc channel #mcclim
<fiddlerwoaroof>
... #clim
<fiddlerwoaroof>
sorry, editor malfunction :)
<gilberth>
fiddlerwoaroof: I am aware of that. But McCLIM has the wrong license.
<gendl>
but i would not dissuade anyone from going with LispWorks either for commercial endeavors.
<fiddlerwoaroof>
GPL? I think there's also some work on making the Franz implementation of CLIM portable
<gilberth>
And then CLIM2 is free software now.
<gilberth>
Well, it is no _that_ hard to get CLIM2 running. It still is _slow_.
<aeth>
Iirc mcclim is LGPL so it would be complicated for commercial use. You couldn't do the typical all-in-one binary shipment because the LGPL wants you to do a separate file and try to emulate dynamic linking in whatever language you're using... so you'd have to ship the McCLIM .FASLs or .LISPs (or turn it int one .FASL or .LISP)
<gendl>
McCLIM is LGPL.
<aeth>
At least McCLIM is LGPL and not LLGPL, though, which is an unknown and untested custom license and so is entirely unsuitable for commercial use due to the questions involved imo. At least you *can* just do the .FASL or .LISP workaround with LGPL.
<fiddlerwoaroof>
or just quickload it on startup :)
<gendl>
aeth: LLGPL is more permissive than LGPL.
<aeth>
gendl: Revenue-sharing is problematic if you're working in an area of software where the potential upside is essentially unlimited, though.
<gilberth>
About then years ago, I decided to only publish under a BSD or MIT license.
<aeth>
gendl: LLGPL is untested, so I wouldn't want the risk
<fiddlerwoaroof>
gilberth: yeah, that's mostly my policy
mathpacka has joined #lisp
<verisimilitude>
Why, gilberth? I prefer AGPLv3 for most of my things.
<gendl>
aeth: Revenue-sharing is problematic if you're greedy and working in an area of software where the potential upside is essentially unlimited.
<aeth>
verisimilitude: now *THAT* is a license completely unusable for almost every commercial use :-p
mathpacka has quit [Remote host closed the connection]
<fiddlerwoaroof>
Yeah, I'm with Linus on GPL > 2
<gilberth>
Left hand side is CLIM2, right hand side is me.
<gendl>
AGPL is perfectly acceptable for commercial use as long as you're willing to distribute your application source code.
<verisimilitude>
It's perfectly fine for use in proprietary software; you'd just need my explicit permission, which I'd charge for.
<fiddlerwoaroof>
gilberth: is there source anywhere?
<moldybits>
how big a byte can read-byte read?
<Bike>
whatever size the implementaiton supports
<Bike>
it's based on the stream element type i think
<fiddlerwoaroof>
Also, is that OSX?
<aeth>
gendl: It's not an issue of greed, though, since there are alternative choices. It's a matter of keeping external costs as low as possible, which might not even be greedy since then you can e.g. afford to pay higher salaries
<gilberth>
fiddlerwoaroof: No, ask me, when I get sane again. I suffer from depression for quite some time now.
<aeth>
gendl: AGPL is de facto an anti-commercial license without actually being an anti-commercial license
<gendl>
AGPL is a defacto anti-closed-source license. Not anti-commercial.
<aeth>
Generally commercial software, even if open source, wants e.g. like 3% of it to be closed off.
<gilberth>
I pick BSD or MIT becaus it is liberal. If you could make money from my code: Congratulations! I am fine with that.
<fiddlerwoaroof>
I'd really be greatful if someone would release a nice CLIM implementation with Cocoa integration
<verisimilitude>
I chose CC0 for one of my libraries, just because I didn't want anyone to be discouraged from using it, though, and because it was a small library.
<gilberth>
fiddlerwoaroof: Actually I am not so fond of CLIM (presentations and stuff) anymore. But the Silica is nice.
<fiddlerwoaroof>
My favorite use of the GPL is what Adacore does: release an Ada runtime under GPL so people that use your free compiler have to distribute their source with their binaries and then charge $10k+ for a compiler suitable for commercial use
<fiddlerwoaroof>
gilberth: interesting, what don't you like about it?
<verisimilitude>
If you get it from the FSF, you don't have that in place, fiddlerwoaroof.
smasta has quit [Ping timeout: 245 seconds]
<aeth>
The way I see it is that the stricter your license the more people you discourage from using it. So if your main goal is popularity, use something like BSD or MIT.
<fiddlerwoaroof>
verisimilitude: yeah, but then you're always behind
<aeth>
And I think focusing on popularity, even if it encourages closed source users, might not be a bad thing for a niche language.
<gendl>
aeth: being allergic to revenue-sharing is indeed a matter of greed. If you're making unlimited money but have a problem with the vendor on whose back you got there sharing in that windfall, I consider it greed.
<fiddlerwoaroof>
Adacore's tactics here are really shrewd
<gilberth>
fiddlerwoaroof: The grammar. It is verb-object, which is fine by itself, but just alien to any casual user as every other GUI uses object-verb. Also CLIM mixes typesetting with display lists.
<aeth>
fiddlerwoaroof: One valid argument against CLIM would probably be performance.
<fiddlerwoaroof>
aeth: only for certain classes of application
<gilberth>
fiddlerwoaroof: As the bounding box for redisplay is not the correct bounding box for typesetting.
<verisimilitude>
It's the same approach Redis and other projects were using until they decided Amazon was taking too much of their business and they needed to ``fix open source''.
<ebrasca>
I think GPLv2 is fine.
<gilberth>
aeth: Well, that could be fixed, as you see.
<fiddlerwoaroof>
My policy is BSD/MIT/Apache v2 for libraries, GPL for applications
<fiddlerwoaroof>
GPLv2, though
<gendl>
revenue-sharing makes the vendor into a virtual partner. It results in everyone pulling in the same direction.
<ebrasca>
I don't understand GPLv3.
<aeth>
gendl: Capped revenue sharing might be better. When I say "unlimited upside" in some areas of software I do mean quite literally unlimited. As in, it could even be $1,000,000,000,000. I'm not sure anyone contributes that much value.
<fiddlerwoaroof>
gendl: my main objection is that when you're just starting out, the vendor cut could mean you don't make anythign
<gendl>
revenue-sharing means if you're not making money, neither is the vendor.
<aeth>
gendl: But I think that de facto caps exist because big players probably *do* negotiate some known fixed rate for these sorts of things because known expenses (and known income, from the vendor's perspective) are good
<fiddlerwoaroof>
Yeah, but 10% of $1k revenue hurts a lot more than 10% of 100k
<aeth>
gendl: So you'd only see unlimited upside in some really rare hits, like if Minecraft was written in Allegro or something
<fiddlerwoaroof>
(I haven't looked at the ACL license terms, so perhaps they solve this)
<ober>
their license for distribution is expensive.
<gendl>
aeth and fillerwoaroof are making conflicting arguments
<aeth>
gendl: fiddlerwoaroof is completely wrong here :-p
<gendl>
one is saying "revenue sharing is bad when you're small because $100 is so much money when you're only making $1000"
<fiddlerwoaroof>
Honestly, if you're making billions from a commercial compiler and/or library, you should pay a share of your revenue to the people upstream
<fiddlerwoaroof>
gendl: obviously we have opposite issues with it ;)
<aeth>
gendl: revenue sharing is absolutely better than some fixed huge rate (like $1k or whatever big language vendors tend to do) if you're small
<gendl>
the other is saying "it's bad when you're big because the vendor might make too much money and make me jealous"
<gendl>
the fact is that the vendor is taking the risk with you when you're small
<gendl>
so they are entitled to share in the upside when you get big.
<gilberth>
gendl: What risk, actually? They are selling you a copy of what they already have.
<moldybits>
is there a bitstream library for lisp?
<aeth>
gendl: At some point, though, it makes more sense to just hire all of the core SBCL developers. And that point is probably around $300,000-$2,500,000
<gilberth>
gendl: It is not like every copy is hacked from scratch.
<gendl>
i mean, they don't necessarily want to be "hired."
<fiddlerwoaroof>
The main risk their taking is investing staff into the support contracts
<ober>
if sbcl was your only implementation you had to use, you'd be grumpy too :P
<fiddlerwoaroof>
The great thing about CL is there are half a dozen reasonable implementations for some definition of reasonable
<gilberth>
fiddlerwoaroof: Right. But then I would not offer unlimited support and perhaps charge by the hour or something like that.
<aeth>
gendl: The deal is pretty good from both perspectives, though. A good salary and full time development on something they like enough that they're probably doing without it being their full time job, and the only cost is adding certain features and doing certain support. And if SBCL devs refused it, there's CCL or ECL etc.
<aeth>
gendl: A Google of Common Lisp totally would try that.
* fiddlerwoaroof
would love to be paid to write CL instead of Clojure
<gilberth>
fiddlerwoaroof: You could always found.
<aeth>
gendl: A more extreme alternative, if you really wanted ACL would simply be to buy the company, because at some point *that* is cheaper than revenue share
<gendl>
gilberth: they are taking the risk of supporting you. If you're doing anything at all substantial, you will need support. They are also taking the risk that you are a trustworthy customer.
<gilberth>
gendl: Yeah, because I don't have the source code, right. When I use SBCL or CCL [which I prefer] I could always help myself.
<gendl>
gilberth: you could help yourself get into a mess.
<fiddlerwoaroof>
aeth: maybe, but there's always a danger in getting distracted from your core business in those situations
<gilberth>
gendl: The mess already is there. :-)
smasta has joined #lisp
<fiddlerwoaroof>
Honestly, the bigger you get, the more it makes sense to pay a significant amount to vendors so you can focus on user complaints
<gendl>
Allegro source code is available for those who have a legitimate need and ask for it.
<verisimilitude>
Look at Google; they're big and they still ignore user complaints.
<ober>
yeah they ship it with the blowfish encrypted source code.
<gilberth>
gendl: Ah, that is news to me.
<fiddlerwoaroof>
verisimilitude: yeah, and their consumer products tend to fail in the market
<ober>
source license is very expensive
<gendl>
a lot of programmers, especially CLers, have this fantasy that they can do everything themselves.
<fiddlerwoaroof>
+1
<gendl>
ober: where did you get that information?
<gilberth>
gendl: Well, we usually actually can. :-)
<ober>
gendl: yeap. support is worth a lot to regular humans.
<aeth>
fiddlerwoaroof: It depends on what you do. If you're a big airline using CL, spending on a vendor makes sense at any scale. If you're a big tech company, eventually, you want to move the language tech in house, or at least that seems to be how they operate.
<ober>
gendl: umm go download it and look
<gendl>
Allegro CL source license does not cost money as far as I know - you just have to sign an NDA.
<verisimilitude>
Do you think some can't, gendl?
<fiddlerwoaroof>
What I really wish would be for the ability to buy Lispwork's "Enterprise" Features a la carte
<fiddlerwoaroof>
Even if they had restrictions, I'd like to play with things like Knowledge Works, without an enterprise license
<gendl>
Anyway I just finally managed to pay for ELS with the demented University of Genova's payment system.
<ober>
acl10.1-smp.64/src/srclisp.blf. there is also a instsrc command for it. but it's clearly encrypted with blowfish
<gendl>
or i should say the University of Genova's demented payments system
<verisimilitude>
Good for you, gendl. I almost had one of my employers purchase a proprietary CL license so I could play with it.
<verisimilitude>
Things largely decayed before then, though.
<ober>
verisimilitude: go with lw
<gendl>
ober: You have to sign some documents with Franz to get the decryption key. But I don't think it costs money.
<ober>
umm we had a quote at one point, pretty sure there was a fee associated with it. but this was commercial not edu.
<gendl>
ober: maybe if it was associated with being able to build & deploy runtimes using the sources somehow.
<fiddlerwoaroof>
The Allegro thing I'm most interested in is AllegroGraph
<gendl>
But just to have the source for reference while using normal commercial Allegro CL, I'm pretty sure doesn't cost money.
<verisimilitude>
The CAPI is the thing I'm most interested in, as well, so I'll likely go with Lispworks if I get the chance.
Aruseus has quit [Remote host closed the connection]
<ebrasca>
gendl: Freedoom is more important.
marvin3 has joined #lisp
<gendl>
ebrasca: more important than what?
<ebrasca>
gendl: Features
marvin2 has quit [Ping timeout: 255 seconds]
<ebrasca>
gendl: Everiting come from freedoom to make and live.
<gendl>
ebrasca: I wasn't aware I was arguing otherwise.
<moldybits>
djeis[m]: thanks.
<gendl>
ebrasca: that is the great thing about CL. You have freedom to switch to so many different implementations, if you follow proper conventions and standards.
<moldybits>
Xach: gilberth: thanks re flexi-streams.
<ober>
gendl: well they have mysql/odbc/oracle/srclisp
<gendl>
you can use and benefit from a commercial implementation, and still have the freedom to keep your application code alive in other implementations if/when that becomes appropriate.
<ober>
also corba
<fiddlerwoaroof>
Yeah, imo, the best idea is to write the core of your application in conforming CL (or using compatibility libraries like Bordeaux-Threads, Usocket, etc.) and then write a thin wrapper using implementation-specific features that make your life easy
<gendl>
ober: yes Allegro has a lot of add-ons accumulated over the years. Many of them are from pre-Quicklisp days when it wasn't reasonable to assemble that stuff yourself from free open-source components.
<gendl>
and from a business point of view it still makes sense to use such an implementation, to have a one-stop shop for all that supported add-on functionality
<gendl>
but the reality is that most of that stuff can be achieved these days with Quicklisp libraries, if you're willing to do some reading and fiddling
<gendl>
My main point: Freedom to choose from so many options.
<gendl>
that's why they can't kill CL.
<gendl>
no matter how hard "they" try, it can't be killed.
<verisimilitude>
That's one reason why I wouldn't support a ``standard'' only implemented by one or two of them.
Bike has quit [Quit: Lost terminal]
<gilberth>
Well, CL isn't going to go away. The very last key I will ever type in my life will be ")".
<aeth>
you type your )s?
<ebrasca>
yea I fixed my 12bit byte problem
<gilberth>
aeth: Yes, I do. Do you speak them?
<gendl>
gilberth: lol.
<gendl>
very last key will be ')'. I like that.
<gilberth>
gendl: But that on my tombstone: "At least he closed his parens."
<gendl>
or the opposite to what I said above - you can tinker around with your application in free implementations, then move to commercial when it makes business sense. There are just so many combinations of use-cases which can make sense.
abhixec has quit [Ping timeout: 272 seconds]
<gilberth>
Put, even.
<fiddlerwoaroof>
I do wish LW would update their personal edition somewhat
<aeth>
gilberth: paredit autocompletes the ()s and keeps them balanced, i.e. typing ( makes Emacs do ()... that way my parens stay balanced even if I die of a heart attack or brain aneurysm in the middle of programming.
<aeth>
gilberth: that also makes my last key most likely to be (
<gilberth>
aeth: I hate that.
smasta has quit [Ping timeout: 245 seconds]
<gilberth>
Because I need to skip over the auto-closed parens by c-f.
<ober>
gendl: who is trying to kill CL?
<verisimilitude>
You can just type ``)'', gilberth.
<ober>
lw needs utf8 support
<fiddlerwoaroof>
gilberth: on emacs at least, ) moves through parens
smasta has joined #lisp
<aeth>
I hated that feature in IDEs for other languages, e.g. foo( becoming foo() but I don't hate it in paredit. probably for two reasons (1) it ensures things are balanced and parens are everywhere and (2) I think the feature I hated wasn't consistent with my muscle memory. () will also produce () because ) takes you to the )
<beach>
Good morning everyone!
<fiddlerwoaroof>
But, I almost never type )
<gendl>
ober: The Man.
<loke>
gilberth: I think he was referring to the fact that many people use things like paredit
<gilberth>
verisimilitude: Still I do not like that, but then I am old, as Xach pointed out.
<ober>
Franz? :P
<fiddlerwoaroof>
I mostly do "wrap-sexp, type operator" style editing
<ober>
they push constant updates
<gendl>
Franz is supporting CL in many ways.
<loke>
gilberth: With paredit you don't have to skip past the ). Not saying you have to like it, just wanting to clarify that it's smarter than tht.
<aeth>
oh and finally (3) writing () is very uncommon in CL (but '() is decently common in Scheme) because foo() is written as (foo) in CL.
<aeth>
foo() is pretty common so I probably use () more in non-CL languages than I do in CL
<verisimilitude>
Writing () is uncommon?
<ebrasca>
beach: Good morning!
<loke>
verisimilitude: Much more uncommon than in C
<aeth>
verisimilitude: you use () mainly in macros
<gilberth>
verisimilitude: It is, I spell that like NIL.
<ober>
gendl: if only they would get thread support in their mac gui
<aeth>
verisimilitude: at laest ime the only time () makes more sense than NIL in most contexts is in macros for lists-as-syntax e.g. (let () ...)
<aeth>
*least
<loke>
aeth: not even when definiing a function with no arguments? I don't think I've ever seen anyone do (defun foo nil (do-something))
<gilberth>
aeth, loke: True.
<aeth>
loke: defun is a macro too, and would have been a better example than my nonsensical let
<gilberth>
But, hmm, isn't that (defun foo [] ...) these days?
<verisimilitude>
Not in CL, no.
<gendl>
Oh, is beach here? That's unfortunately my cue that I'm up way past my bedtime..
<loke>
gilberth: That's clojure. And clojure syntax is plain stupid, IMHO
<gilberth>
I am making fun of Clojure.
<gendl>
good night ladies & gents.
<fiddlerwoaroof>
I like the old lisps where ] closes all the open parens :
<fiddlerwoaroof>
:)
<aeth>
loke: Defining functions of zero arguments are pretty rare in CL, though. What would they do? They could return a constant value or return access to global state with some wrapper to some global.
<fiddlerwoaroof>
good night gendl
<aeth>
loke: Both seem decently niche.
<fiddlerwoaroof>
aeth: usually side efects
<aeth>
(lambda () ...) is pretty common, though
<fiddlerwoaroof>
or thread entry points
<loke>
aeth: CL is not a pure functional language.
<gilberth>
loke: Two idiots, same idea.
<verisimilitude>
There's also HANDLER-CASE when you don't need the CONDITION.
<aeth>
s/return access to global state/return or set access to global state/
<verisimilitude>
I just looked through some of my code and, aside from functions without arguments, that was the use of ().
<aeth>
I think usually people directly set globals, though. Probably not the best idea, though
<aeth>
I'd say 90% of my ()s are (lambda () ...) and the other 10% are probably in macros where there's something that needs to be left blank that's a list-as-syntax.
<gilberth>
At least we have dynamic binding, so it is not that bad.
<verisimilitude>
There's also defining a variable as an empty list.
<gilberth>
verisimilitude: This goes with a quote.
<aeth>
I don't build lists up from empty lists often in CL. I usually just use loop when I need to list-build.
<verisimilitude>
I don't use it that way, gilberth.
<loke>
In Climaxima I define 11 functions that take no arguments.
<verisimilitude>
Why would I write '() when I could write ()?
<verisimilitude>
It's the same constant value.
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]
<ober>
thunks are always lambdas?
<gilberth>
verisimilitude: Because it also is '(1 2 3), so '() feels much mor symetric to me.
<verisimilitude>
Well, that's not how I do it, so that's an example of using (), for me.
<aeth>
verisimilitude: '() is () is NIL but I usually use '() as the empty list, () as the empty subexpression (e.g. in (lambda () ...)), and NIL as false or quasi-null (it's not a real null if it's also *the* false value imo) or in misc uses.
<loke>
verisimilitude: I do it the same as you... Hopwever, I wonder what you do if you have code that reads '(1 2 3) and then you decide to remove the 1 2 3. Do you also remove the ' or do you leave it, giving you '()?
<gilberth>
It just is my style. Same applies to NOT versus NULL.
<fiddlerwoaroof>
I've been doing (serious-condition (c) (declare (ignore c)) ...)
* fiddlerwoaroof
facepalm
<aeth>
no-defun-allowed: I have never seen 'nil but that makes sense.
<gilberth>
loke: Yes, it depends on what I want to communicate.
<loke>
gilberth: same.
<no-defun-allowed>
I don't think many people use NIL as a symbol, honestly.
wusticality has quit [Ping timeout: 264 seconds]
<gilberth>
loke: I use NOT for booleans and NULL for testing for an empty list. and (NOT (NULL ...)) is common.
<aeth>
no-defun-allowed: It probably is used in the internals of implementations
<loke>
gilberth: I tend to shortcut by typing (when foo ...) more often than I should.
<verisimilitude>
I'd normalize it to (), loke.
<gilberth>
loke: There also is UNLESS :-)
<loke>
gilberth: indeed
ltriant has quit [Quit: leaving]
<gilberth>
loke: And I have the habit of using AND, where WHEN would be called for. But then: As Xach pointed out: I am old. :-)
<loke>
gilberth: Probably bad example on my part. (NOT (NULL ...)) usually happens with COND
wusticality has joined #lisp
<verisimilitude>
I never use QUOTE or ' with NIL or ().
<verisimilitude>
If anything, those are two constants you can expect everyone to know, so I take advantage of that.
<verisimilitude>
I don't use QUOTE with KEYWORDs, either.
<aeth>
verisimilitude: your style doesn't seem entirely idiomatic, though
<loke>
gilberth: I use AND when the return value is significant. I try to avoid WHEN and UNLESS when I need the return value, opting for (IF FOO BAR NIL) instead.
<gilberth>
loke: Yes, this is subtile. WHEN is for effect and AND is for value.
jb__ has quit [Ping timeout: 272 seconds]
<loke>
verisimilitude: Noone uses ' with keywords, no?
<verisimilitude>
Exactly.
<loke>
When are we getting to the use of keywords with LOOP? Now _that_ makes my eyes bleed :-)
abhixec has joined #lisp
<aeth>
verisimilitude: I think the reason why '() is used on empty lists is to cause the least surprise. Especially if someone is coming from a similar language, where () might be equivalent to (funcall) instead of '()
<gilberth>
Mine too.
<no-defun-allowed>
Only Zetalisp user do ':FOO to my knowledge.
<no-defun-allowed>
*users
<verisimilitude>
I don't bother if I'm at the REPL, but I prefer to minimize useless symbols in actual programs, so I'd change it to KEYWORDs then.
<no-defun-allowed>
Or, maybe in a macroexpansion, it'd be easier to quote the name of something anyway.
<loke>
no-defun-allowed: why is that? Zetalisp didn't have keywords?
<verisimilitude>
Then again, I also go through my parameter lists looking for synonyms in COMMON-LISP I can use to eliminate otherwise useless symbols taking up space.
<aeth>
Of course, CL does () as NIL instead of (funcall) probably to mirror how it's treated in macros with empty syntactic lists like in (lambda () ...)
<no-defun-allowed>
They did, but they weren't self-quoting.
jb__ has joined #lisp
wusticality has quit [Ping timeout: 244 seconds]
<loke>
no-defun-allowed: the self-quotingness of keywords seems to be its main feature. What else sets them apart from regular symbols?
<verisimilitude>
If I have a numerical argument representing a count, why use WHATEVER::N when I can use CL:COUNT?
<loke>
verisimilitude: I'd turn it around and ask why not?
<gilberth>
There is IN-PACKAGE :-)
<no-defun-allowed>
Or, maybe I'm thinking of the wrong Lisp.
<verisimilitude>
It wastes space on a useless symbol, so I think of it as cleaning up, loke.
<loke>
About historical Lisps, which Lisp did not have the LAMBDA macro? Maclisp? I see the Maxima code base full of #'(lambda...)
<no-defun-allowed>
Well, what Lisp did the CADR run?
<no-defun-allowed>
That one has keywords that don't self-quote.
<verisimilitude>
If the symbol is already BOUND or FBOUND, I could use it without fretting, though.
<gilberth>
verisimilitude: You hack on a PDP-11 with only 64kB of RAM? Poor you.
space_otter has joined #lisp
<loke>
verisimilitude: to each their own. It does seem like a crazy amount of microoptimisations for no practical value.
<verisimilitude>
I've done the math, CL wouldn't fit in 64KB, gilberth.
<verisimilitude>
Well, it helps that I'm particularly obsessed with space optimizations in CL, since every other implementation seems obsessed with only speed.
<verisimilitude>
Space optimization is more interesting, in general, because it's a more inherent quality.
<no-defun-allowed>
So, if one evals (defun f (x &key y) (list x y)) first, then (f 2 ':y 3) is the correct way to pass X = 2 and Y = 3
<verisimilitude>
The space doesn't change when the processor makes an instruction faster.
<fiddlerwoaroof>
verisimilitude: because of symbol sizes?
<gilberth>
verisimilitude: No, that is not true. Try CLISP or ACL. Or heck the CADR.
<aeth>
verisimilitude: Space optimization? Are you targeting embedded?
<verisimilitude>
Yes, fiddlerwoaroof, just the symbols alone would consume several dozens of kilobytes, although I don't recall the precise figure offhand.
<verisimilitude>
That's too large, gilberth.
<fiddlerwoaroof>
Because you could encode the symbols in CL as consecutive integers or something
<verisimilitude>
I want to design a Common Lisp that fits in well under a megabyte.
<no-defun-allowed>
Wait, are you the weirdo that wanted to make everything not reflective?
<verisimilitude>
I don't want to cut corners like that either, fiddlerwoaroof.
<verisimilitude>
I don't recall that, no-defun-allowed.
<aeth>
verisimilitude: "well under a megabyte" would be hard. 1-2 *might* be possible.
<gilberth>
verisimilitude: CLISP used to run on an Atari ST.
<verisimilitude>
It's possible, aeth, so I want to aim for that.
<gilberth>
But then it was CLtL1 back then.
<no-defun-allowed>
Hmm...well then. Someone came on #sicl talking about a concrete CL or something like that for "deployment" purposes.
<fiddlerwoaroof>
I wonder what a huffman encoding of CL symbols
<fiddlerwoaroof>
would do to space
<verisimilitude>
Also, CLISP doesn't compile to machine code, which is something I'd do.
smasta has quit [Ping timeout: 245 seconds]
<verisimilitude>
I wouldn't want to ``cheat'' by cutting corners such as that.
<gilberth>
verisimilitude: Well, you cannot have both.
<verisimilitude>
I think I can.
<aeth>
gilberth: Atari ST has 512 KB to 4 MB memory according to Wikipedia. So it's possible that CLISP was never under 1 MB in footprint
<gilberth>
aeth: It was, my machine only had 1MB of RAM and ran CLISP.
<verisimilitude>
Again, CLISP doesn't compile to native code.
* no-defun-allowed
wonders if any CPUs have "huffman coded" instruction sets
<gilberth>
verisimilitude: As I said, you cannot have both.
<verisimilitude>
Have you ever taken a look at what Chuck Moore does, no-defun-allowed?
<gilberth>
no-defun-allowed: x86 could be considered a bit like that.
<no-defun-allowed>
I've heard of Chuck Moore. Doesn't he do FORTH machines?
<verisimilitude>
Yes.
<verisimilitude>
He created Forth.
<no-defun-allowed>
Sure, x86 has variable-length encoding, but nothing on the bit level.
<no-defun-allowed>
Oh. Well, that explains why he'd make a FORTH machine.
<no-defun-allowed>
I've also heard of that, but never really studied it.
<aeth>
gilberth: Okay, it looks like that's definitely possible. And CLISP looks like it's 5-6 MB on my machine right now so it's not that much more bloated than it used to be (maybe 8x as bloated?).
<gilberth>
no-defun-allowed: Sure. Also CLISP with its byte code has a lot of instructions which are like DOTHIS&THAT in a single byte. That still is not Huffman-encoded. But the idea is to there (also in x86) to give common operations shorter codes.
<aeth>
I wasn't aware that CLISP was that light on RAM even today.
<aeth>
I'll definitely choose speed over space, though.
<verisimilitude>
There's 978 symbols in package CL.
<fiddlerwoaroof>
depending on your application, both might come together
<verisimilitude>
If each consumed even a kilobyte, that would be under a megabyte, but in actuality each could consume far, far less, on average.
<aeth>
gilberth: It does make sense that it's lightweight because it's an interpreter, though
<gilberth>
IIRC CLISP was about 700kB in circa 1993 or so.
<no-defun-allowed>
Fair enough, but I think a truly Huffman coded instruction set would be an interesting project. The instruction register would be some kind of shift register.
<verisimilitude>
So, you ignore outliers such as FORMAT, LOOP, et al. and you have a good chance at getting the majority of the symbols and their functions in very little space.
<gilberth>
no-defun-allowed: Well, given that a x86 CPU translates the ancient CISC-code to something RISC-like already, that should be feasible.
<aeth>
verisimilitude: as an interpreter, yes, that's easy
<no-defun-allowed>
(Oh, Moore also edits his blog in Notepad. Coincedence?)
<verisimilitude>
I figure roughly half a megabyte is good for a full system and you could have options for getting it lower by ignoring documentation strings and other such things.
<aeth>
verisimilitude: At what performance cost, though? Aiming for sub-5-MB would mean a lot fewer compromises
<verisimilitude>
I've thought of ways to compress storage greatly, yes.
<gilberth>
And CLISP is not an interpreter. Not in the sense, that it is a Lisp interpreter. It is a byte coded implementation.
<aeth>
verisimilitude: what platform are you targeting?
<verisimilitude>
As an example, why store a list of external and of internal symbols, when you could store them in the same list and have a pointer to inside of this list for the internal, say, meaning you only need one list.
<verisimilitude>
I'd probably be targeting MIPS starting out, aeth.
<fiddlerwoaroof>
a 32 bit clisp should be significantly smaller, right?
<gilberth>
When you read the original proposal for the CADR Lisp machine, you figure, that at those times, the folks where concerned with code size as memory was still pretty expensive at that time.
<aeth>
verisimilitude: so probably routers?
<verisimilitude>
No, I just own some exotic MIPS hardware.
<fiddlerwoaroof>
I assume there's a lot of space taken up by pointer size
<gilberth>
But these days, I find that a bit silly.
<fiddlerwoaroof>
verisimilitude: interestingly, the kindles run on MIPS and you can root older ones and get a nice linux system perfectly capable of running sbcl
<aeth>
fiddlerwoaroof: I thought 32 bit was about half RAM usage, but I haven't looked it up so I could be completely wrong
<fiddlerwoaroof>
I assume the instruction size is smaller too
<verisimilitude>
Similarly, you usually don't need function and property list slots for KEYWORDs and you don't need a package slot if KEYWORDs are a distinct tag from SYMBOL, so you could store just the name and property list for KEYWORDs and, instead of having these other slots in KEYWORDs, using the CAR of the property list if you ever actually use it, just treating the CDR as the real property list if you need that.
<verisimilitude>
This is a tiny optimization that would save a good deal of space.
<fiddlerwoaroof>
And the frame-buffer interface in Linux isn't horrible to work with to put graphics on the Kindle screen
<aeth>
verisimilitude: I honestly thought implementations represented symbols as integers, rather than pointers to these symbol plists that (almost) no one uses. I was apparently wrong.
<verisimilitude>
Generally, a SYMBOL is a record with several pointers to a string, a package, a function, a value, and a property list.
<verisimilitude>
That's twenty bytes if each pointer is four bytes.
<fiddlerwoaroof>
verisimilitude: that's its conceptual structure
<verisimilitude>
Optimizing this way would have a KEYWORD consume just eight, though.
<fiddlerwoaroof>
the memory layout isn't specified, though
<verisimilitude>
Of course not, but that's what it likely actually is.
<no-defun-allowed>
What about FLET then? How would the scoping of the defined functions work there?
<aeth>
verisimilitude: if lookup of any of those is very rare you could just e.g. use symbols as keys to hash tables so you could e.g. have a hash table of strings, a hash table of plists, etc.
<fiddlerwoaroof>
no-defun-allowed: I believe that, since it's lexical scope, it's all handled by the compiler + the strategic allocation of closures
<aeth>
verisimilitude: but you're right, it's not just a pointer to a plist, it's a pointer to an entire data structure, probably a struct or standard-object
<verisimilitude>
Really, it would perhaps be worthwhile to store all SYMBOLs this way, though.
<verisimilitude>
So, a SYMBOL would have a name and a property list, with the CAR of that property list storing the other slots when used and the CDR being the real property list.
<gilberth>
Hey. When I say (defun foo (x) (+ x 1)) and I compile the file and load the fasl in a fresh Lisp image, will there be an "X" symbol in the package?
<fiddlerwoaroof>
aeth: you can always do thing, though, like storing the symbol as an index and putting the various slots in contiguous arrays
<verisimilitude>
Yes, gilberth.
<gilberth>
Why?
<verisimilitude>
You've INTERNed X.
<gilberth>
When loading the fasl?
<verisimilitude>
I don't believe I'm wrong here.
<gilberth>
It is compiled code. So it perhaps is just a reference to an %r0 register to some such.
<fiddlerwoaroof>
I think you'll get a symbol in the package, but compiler optimizations might mean that that symbol is never used
dale has quit [Quit: dale]
<gilberth>
[We forget for a moment, that Lisp implementations like to keep argument list information and such. We say (DEBUG 0) here.]
<verisimilitude>
You write that, but SBCL doesn't bother storing much for FUNCTION-LAMBDA-EXPRESSION in any of those dozens of megabytes.
pierpal has joined #lisp
<fiddlerwoaroof>
Honestly, I'd like to be able to reconstruct my source from a lisp image
<fiddlerwoaroof>
I'm hoping that SICL will make my dream come true :)
<aeth>
fiddlerwoaroof: the complicating factor is macros
<aeth>
A proprietary Common Lisp program on some implementation that didn't obfuscate could be "reconstructed", but if it used elaborate internal-only macros, you'd never be able to reconstruct the true original.
<fiddlerwoaroof>
aeth: that's not complicated: you just make sure you record the source before running any macros ;)
<gilberth>
Ah, my mistake :-(
<fiddlerwoaroof>
including reader macros
* gilberth
wonders what the standard says.
<fiddlerwoaroof>
Anyways, if I ever find the time, I would do away with the entire concept of storing code in the filesystem
dddddd has quit [Remote host closed the connection]
<fiddlerwoaroof>
Just store it in the image and append all modified definitions to the end of the executable
<fiddlerwoaroof>
And then have some system for marking definitions obsolete, etc.
<fiddlerwoaroof>
And implement Git (or some other DVCS) in CL for sharing code
<fiddlerwoaroof>
Make lisp a proper smalltalk
<gilberth>
Heck, but it works in CLISP. Stick (in-package :foo) in compile the file, load the FASL and there is no Y in package FOO.
<fiddlerwoaroof>
gilberth: interesting, I always assumed that the reader would intern it before the compiler had a chance to make a decision
<gilberth>
So, yes symbols used for lexical do not need to be kept in the package system.
<fiddlerwoaroof>
Because, my mental model is that symbols get interned at read-time.
<gilberth>
fiddlerwoaroof: It does. But, when you load the fasl in a fresh image, the reader is not involved.
<fiddlerwoaroof>
Oh, if that's the question, you can delete the package and garbage collect everything without interrupting threads that are actually running the code in the thread
<fiddlerwoaroof>
I've done that before: delete the package, reload the corresponding system, kill the old version and startup the new version
<fiddlerwoaroof>
And, that works pretty well
<gilberth>
SBCL somehow keeps the Y. But CLISP for instance does not.
nalkri has joined #lisp
<fiddlerwoaroof>
I don't really trust clisp to be conforming, though
<fiddlerwoaroof>
doesn't Naggum rant about this somewhere?
<gilberth>
fiddlerwoaroof: It is pretty conforming, IMHO.
<gilberth>
Anyhow, if you think about it: Why would such lexical variables be needed to be kept in the package system. It is just some CPU registers or stack locations after compilation, anyhow.
<gilberth>
Debugging aids would be the only reason.
<fiddlerwoaroof>
That part makes sense, it's just that it doesn't make sense (to me) to not persist the package "whole"
<fiddlerwoaroof>
with all the symbols at the time at which the FASL is generated
<gilberth>
Well, Y has no properties, is unbound, and undefined. Why keep it?
makomo has joined #lisp
<fiddlerwoaroof>
Hmm, maybe the GC collects symbols in this case?
<fiddlerwoaroof>
because, if the indirection is optimized away, then there's nothing referring to the symbol anymore
<gilberth>
fiddlerwoaroof: Well the times, when GCs did that are long, long gone.
<fiddlerwoaroof>
And then, CLISP runs the GC before saving a FASL
<gilberth>
Because there still is FIND-SYMBOL.
<fiddlerwoaroof>
gilberth: I don't mean directly, it's still a unreferenced pointer, right?
<gilberth>
It doesn't. It writes the fasl. And the fasl has no reference to that symbol. We load in a fresh image.
smasta has joined #lisp
<aeth>
That makes complete sense
<fiddlerwoaroof>
what I don't understand is how the fasl could have no reference to the symbol, if it contains the package object
<gilberth>
Because in compiled code, the Y is just a stack location.
<fiddlerwoaroof>
but, maybe that's my bad assumption
<gilberth>
Why would the fasl contain the package object itself?
<aeth>
If it's internal to the function it doesn't necessarily have to exist later on
<fiddlerwoaroof>
gilberth: something has to, to reconstruct the package system when the image starts up again, right?
<fiddlerwoaroof>
It might be a load-form, etc.
<gilberth>
That is the DEFPACKAGE. A fasl is a stream of instructions to execute.
<gilberth>
Not objects per se saved.
skeuomorf has joined #lisp
<gilberth>
This is unlike SAVE-LISP-AND-DIE.
<gilberth>
CLISP fasls are ASCII. Perhaps you try that and look at what actually is in the fasl.
<fiddlerwoaroof>
Hmm, interesting, I wonder if I have clisp somewhere
<gilberth>
Its byte code, but native compilers do work the same in principle.
<gilberth>
DEFPACKAGE expands to a form, which creates the FOO package afresh. There is nothing in the compiler, which would somehow dump the package object.
<gilberth>
Oh, my english is getting bad, perhaps I need to crash. :-(
<fiddlerwoaroof>
I assume there'd be some specification about what the load-form for a package should contain, though?
<gilberth>
That is a red hering.
<gilberth>
The package is not saved to the fasl.
<gilberth>
It is what ever DEFPACKAGE expands to. And that is code, which is run, when the fasl is loaded. And it creates the package anew.
<verisimilitude>
Naggum did complain about CLISP's lack of conformance, yes, fiddlerwoaroof.
<verisimilitude>
I've seen the code that would signal an error if you tried to use the People's Republic of China's timezone.
<no-defun-allowed>
see A.1.2.2 and A.1.2.3 in the Implementation Notes for GNU CLISP
<no-defun-allowed>
oh dear, the documentation writer is on something quite potent
<gilberth>
BTW. CCL also skips the Y symbol.
<no-defun-allowed>
(fun fact: Albert Einstien's theory of relativity was dismissed by the CIA as a Communist plot to confuse Western physicists.)
<gilberth>
Bruno has a pretty strong opinions at times. Floating point also used to work different from the standard. I have no idea, what CLISP currently does.
<aeth>
CLISP is a pretty bad implementation for float usage unless you need its arbitrary-precision long-float
<aeth>
e.g. it doesn't have specialized arrays for single- or double-float
<no-defun-allowed>
(Also, the Tiananmen Square protests were because of market liberalisation, ironically for Bruno.)
<aeth>
And it's probably the slowest
<gilberth>
Well, Bruno refused to coerce single floats to double floats implying a precision, that is not there. Which from the interval arithmetric point of view is correct.
<gilberth>
I have no idea, what CLISP does these days. It is almost 20 years since I last hacked it.
emaczen has joined #lisp
rippa has joined #lisp
<verisimilitude>
It's my understanding the code about the timezone was removed.
<verisimilitude>
An implementation of Common Lisp isn't the place for such, though.
<gilberth>
I considered it quite appropriate at that time, but then I was young.
<verisimilitude>
That would be akin to signalling an error if you had a symbol named NIGGER or something else in your program.
<verisimilitude>
Then again, history repeats and some think Rust people may eventually pull something such as that.
<gilberth>
That is PC, which I never considered appropriate. :-)
jb____ has joined #lisp
<gilberth>
But, I was young at that time. These days I am much more calm and could "accept" more unjustice.
<no-defun-allowed>
Well, I have seen that code appear before, and it wasn't by a polite person.
<gilberth>
Sorry, I do not figure, what you are trying to say.
<no-defun-allowed>
That the programmer's Lisp reader probably should signal a few warnings to the intent evaluator if it interns a symbol like the one verisimilitude described.
<gilberth>
Hmm. Yes, these days I also think that a CL implementation is not the right place for that.
jb__ has quit [Ping timeout: 268 seconds]
<no-defun-allowed>
It wouldn't be conforming or polite in general to error if such a symbol appears, it could have been generated, as there's only 308 million 6-letter upcased symbol names to go around.
<no-defun-allowed>
Of course, it's not the compiler's business, but I think the human reader should be wondering why it would appear in someone's code.
<no-defun-allowed>
(One similar discussion occured around the terminology of "killing" threads, and Bordeaux-threads sidesteps that by "destroying" them. I like that, since threads aren't alive...yet.)
<verisimilitude>
You can make the argument for the human, but the machine's algorithm is no place for such things.
<no-defun-allowed>
Yeah.
<gilberth>
Well (intern (let ((*print-base* 36)) (prin1-to-string (random (expt 36 6))))) could turn this up :-)
<verisimilitude>
That would be a good way to scam idiots, though, I suppose. Check your Common Lisp image for racism in one easy step!
<gilberth>
:-)
<no-defun-allowed>
Point is, I don't consider it a needlessly "PC" action to slap the person who wrote that in the face and ask "couldn't you think of a better variable name?"
<verisimilitude>
I can see an ironic scenario where a Common Lisp program being used to control machines for murdering others is scanned and, lacking these words, passes.
zhlyg has joined #lisp
<verisimilitude>
Yes, there's never really a good place to use such a symbol, if one wants to use meaningful symbols, no-defun-allowed.
<gilberth>
Well, I still get angry at the 15% or so people around here that vote right-wing. But then a CL implementation is not the place to fix that. I am repeating myself: I am much calmer these days than 20 years ago.
<no-defun-allowed>
My story is that that in a programming channel, someone used that as a variable name and asked what was wrong with the code. They turned out to be a very rude person and attacked my girlfriend and I.
<gilberth>
And then: CL programmers are usually smart and not the right audience. :-)
<gilberth>
no-defun-allowed: Ouch! That sounds pretty bad.
<verisimilitude>
I've met intelligent people I agree with and intelligent people I disagree with.
<verisimilitude>
But sure, let's pretend everyone we disagree with politically is stupid.
<no-defun-allowed>
And then everyone /ignore-d him and we lived happily ever after. The end.
<gilberth>
verisimilitude: Sure intelligence does not save from idiotic ideas.
<no-defun-allowed>
So...back to CL?
igemnace has joined #lisp
<verisimilitude>
Sure; what do you think of a Common Lisp implementation where the entire COMMON-LISP package is written in a different language?
<gilberth>
no-defun-allowed: Sure, do we start CLtL3? Or would we rather plan world dominance?
<no-defun-allowed>
World dominance using CLtL3?
<gilberth>
Perhaps. Sounds like a feasible plan.
<fiddlerwoaroof>
I feel like part of what makes CL great is that the standard hasn't chagned for 25 years or so
<verisimilitude>
I agree, fiddlerwoaroof.
<no-defun-allowed>
`(mapc #'dominate-thing *things*) ;; run in case of lossage of #lisp topic coherency`
<fiddlerwoaroof>
22, that is
<verisimilitude>
I also think part of it is how CL isn't married to any particular operating system or whatnot.
<fiddlerwoaroof>
I think the real merit of the standard is that it defines enough to make writing conforming programs pleasant and it also defines a way to implement language extensions in CL itself
<verisimilitude>
I like using a language where I'm just writing my program and not caring if it runs under UNIX, Windows, or anything else.
<no-defun-allowed>
However, in CLtL3 all the arguments to PRINT must have extra parentheses around them, and integer division by default should return a float.
<fiddlerwoaroof>
So, we don't end up with a Haskell/GHC situation
<no-defun-allowed>
Give the old CLtL2-era people, I dunno, ten years or so and everything will sort itself out and we'll have an absolutely seamless and unfragmented transition to CLtL3
<gilberth>
Why a float? I like my rationals!
<fiddlerwoaroof>
When getting a float is as easy as (FLOAT (/ 5 3))
<verisimilitude>
I'd think floats should be cut out more than they already are. An operation using only rationals should never return a float.
<no-defun-allowed>
fiddlerwoaroof, gilberth: that was a terrible joke about Python 2 and 3, sorry
<fiddlerwoaroof>
:)
<fiddlerwoaroof>
verisimilitude: of course you'll have issues with SQRT in that case...
<gilberth>
Python does 10/3 -> 3, doesn't it?
<no-defun-allowed>
What about trigonometric values? I think the only implementation to return ratios is Movitz.
<verisimilitude>
Your PRINT note only made me think of ALGOL, no-defun-allowed.
<no-defun-allowed>
Py2 gives 3, Py3 gives 3.33...
<fiddlerwoaroof>
Ah, :)
<gilberth>
This is crazy.
<fiddlerwoaroof>
I think it makes sense to return floats when the result of an operation can't be represented exactly by rationals
<fiddlerwoaroof>
Because the reason to return rationals is that they represent the exact quantity
<fiddlerwoaroof>
So, CLTL3 should standardize symbolic math, so we can have an exact representation of (sqrt 2)
<gilberth>
Question: Do they smoke or inject their stuff?
emaczen has quit [Ping timeout: 264 seconds]
<buffergn0me>
Python 2 to 3 is going to turn out like Perl 5 to 6
<gilberth>
But, I think JavaScript is pretty clever about this issue. It is double floating point only. Period.
<verisimilitude>
So many times I learned about some Python quality and thought it was a joke at first.
<verisimilitude>
That's an awful part of the language, gilberth.
<gilberth>
I figure that.
<verisimilitude>
It poses optimization issues, as well. I'd rather have only integers than only floats.
<aeth>
gilberth: JavaScript is a language practically designed to be inefficient and impossible to optimize, somehow made into a decently efficient/optimized language through massive resource investment
<gilberth>
Well the first 2^53 integers can be represented exactly by doubles.
<buffergn0me>
Also problems with boxing
<aeth>
Common Lisp is meant to be (potentially) efficiently implemented
<verisimilitude>
I like my arbitrarily large integers.
<gilberth>
When I am clever with pointers, I do not need to box on a 64-bit machine.
jprajzne has joined #lisp
<fiddlerwoaroof>
Honestly, for JS, double floats only makes sense
<gilberth>
As there also 2^53 NaN, which I could use for pointers.
<fiddlerwoaroof>
real math shouldn't be done client-side anyways :)
<no-defun-allowed>
The JS object system rivals that of the impromptu closures plain Scheme programmers make.
dyelar has quit [Ping timeout: 246 seconds]
shrdlu68 has joined #lisp
<verisimilitude>
Hello, shrdlu68.
<verisimilitude>
Move the green box onto a larger box and then place both on an even larger box.
<shrdlu68>
verisimilitude: Hello.
Oladon has joined #lisp
<no-defun-allowed>
verisimilitude: that's my joke, how dare you
<makomo>
morning
space_otter has quit [Remote host closed the connection]
<shrdlu68>
Holy hell, what if there's more than one "even larger box"? Was SHRDLU smart enough to just pick one?
<buffergn0me>
Doesn't NaN tagging require more bit shifting instructions to decode than having the lower bits used for tags?
<no-defun-allowed>
maybe it asks?
<gilberth>
You could either "tag" floats or pointers. NaNs are indicated by the MSB being one. So you could use XOR to turn one into another.
<shrdlu68>
Oh yeah, something like "By 'an even larger box', do you mean a or b?"
mange has quit [Remote host closed the connection]
orivej has joined #lisp
<verisimilitude>
It's also my understanding shrdlu would ask for clarification, yes.
<verisimilitude>
I've never had an opportunity to actually use shrdlu, unfortunately.
<no-defun-allowed>
Seems it just says "I don't understand which pyramid you mean."
<verisimilitude>
Oh, you have one running, no-defun-allowed?
<no-defun-allowed>
No, but Wikipedia has a transcript.
<no-defun-allowed>
Ooh, the citation has the code for it, and a CL port.
<shrdlu68>
Seems to me we haven't made much progress beyond SHRDLU and LogicTheorist.
<verisimilitude>
It would be stupid, but the idea just crossed my mind to have an edited shrdlu that would occasionally deny commands in a menacing way.
skeuomorf has left #lisp ["Killed buffer"]
<verisimilitude>
That would be good for a laugh, at least.
<fiddlerwoaroof>
Doesn't that have a fancy name in ML?
<no-defun-allowed>
Oh hell yes! We get lambda list errors and PROG to debug!
<fiddlerwoaroof>
"hill-climbing" or something
<fiddlerwoaroof>
real lispers use prog
<verisimilitude>
I use PROG.
<fiddlerwoaroof>
KING-OF-CONFUSION
<moldybits>
gilberth: py3: 10 // 3 => 3
<no-defun-allowed>
Ooh, I got it to load after continuously invoking the CONTINUE and IGNORE-LOCK restarts.
<no-defun-allowed>
This is very well written, conforming CL code in my eyes.
<fiddlerwoaroof>
That's what I usually discover with old code
<shrdlu68>
Looks like it would be a lot of fun playing around with.
<beach>
verisimilitude: Why did you exclude the class, the SETF function, the type, and the method combination from your list of "pointers in a symbol record"?
<verisimilitude>
It's elementary, beach.
<verisimilitude>
My mental model has those elsewhere.
<beach>
Got it. I hadn't realized that you were talking about your mental model.
<verisimilitude>
Less jokingly, my knowledge of Lisp implementations has SYMBOLs as described and so that's how I most often think of them. Generally, I imagine other such things are held elsewhere, as they're less common.
<verisimilitude>
Still, my use of the property list pointer for such is a valid application.
<verisimilitude>
In the common case, you wouldn't have any of that and no property list, so it would just contain NIL and so the CAR and CDR would also be NIL and all of that.
<beach>
I wonder what fraction of symbols in a typical image have a function or a variable defined.
<verisimilitude>
The vast majority of symbols in CL are FBOUND and not BOUND.
<verisimilitude>
That is, 752 are FBOUND and only 116 BOUND.
<no-defun-allowed>
Yeah, I wouldn't expect more than, say, three of the "slots" in most symbols used, as described.
<gilberth>
verisimilitude: I really wonder, why you are so obsessed with the size of symbols. Most of these go away anyway and I figure that code size is much larger.
<beach>
I meant all symbols, not just the ones in the COMMON-LISP package.
<verisimilitude>
It's just more interesting to me than speed, gilberth.
<gilberth>
verisimilitude: Have you actually looked at some Lisp image and counted how much space is take by symbols compared to other stuff?
<verisimilitude>
In my SBCL image, 4,869 are BOUND and 13,859 are FBOUND.
libertyprime has joined #lisp
<verisimilitude>
I've done some of the math, gilberth. I've not only considered SYMBOLs, if that's what you're wondering.
<no-defun-allowed>
So, if we have ten properties, and usually only no more than three are used, it'd be more space-efficient to use alists for symbol properties, I think.
<verisimilitude>
As an example, a CL implementation concerned with size should clearly have an optimization for short strings, if only due to all of those symbol names.
<gilberth>
OK. What is the actual image size? We talk about what? 20k symbols. Each having, what, five pointers, which is 40 bytes, given 8 bytes per pointer, that how many of your 20 to 40 MB image size?
<verisimilitude>
That would be less than one in forty, gilberth.
<beach>
fiddlerwoaroof: Thanks.
<gilberth>
verisimilitude: Correct.
<gilberth>
Even CCL, which is pretty compact in general takes 60MB core size on my installation.
<verisimilitude>
That's not at all compact.
<fiddlerwoaroof>
with compression, I get sbcl images to about 17M
<gilberth>
Freshly started, with no code loaded.
<verisimilitude>
In no way is that compact, unless you want to seriously compare it to a node.js program.
<fiddlerwoaroof>
What about to GCC + libc?
<gilberth>
Then use CLISP. It'll perhaps gets away with 5MB or so.
<fiddlerwoaroof>
+ the half-dozen system libraries your average C program uses
<verisimilitude>
I never said those were small.
<fiddlerwoaroof>
verisimilitude: it's just that most things these days are in that range
<verisimilitude>
Most things are bloated, yes.
<fiddlerwoaroof>
I'm generally greatful when an application isn't >200MB or so
<verisimilitude>
I'm not happy when any program on a machine with not just one but two gigahertz takes more than a fraction of a second to load and start.
* fiddlerwoaroof
runs too many things at once to expect that
robdog has joined #lisp
<gilberth>
time ccl --eval '(quit)' gives me 40ms; which is fast enough
frodef has joined #lisp
<verisimilitude>
Part of the reason I'm rewriting an extremely wasteful interactive program of mine isn't to make it faster, since it's instantaneous even under CLISP, but to make it use less memory. It consumes dozens of megabytes of memory when a quarter of a megabyte is more than enough.
<verisimilitude>
I'm not even going to be optimizing as much as I could, but I want to do it right.
<gilberth>
verisimilitude: Why, verisimilitude, I do not get it. You trade compression for speed. Memory is cheap. There is a reason, we have RISC machines these days and not CISC machines.
<verisimilitude>
Well, part of it is I'd like for a compiled version of the program to be small to download easily.
<verisimilitude>
Even a five megabyte download is huge, gilberth.
<gilberth>
Yeah, that is what compressed archives are for. But that does not imply that the execute is optimized for the very last bit.
<verisimilitude>
Surely you've had the satisfaction of writing a program well, gilberth.
<verisimilitude>
There's doing something good enough and there's doing something well.
<gilberth>
I used to squeze the last microsecond out my code. These days I am almost 45 and my time is limited and it is easier for me to just throw some more money out to get a faster machine or more RAM than to spend my time optimizing the hell out of my code. Long learned hard lesson of mine.
<verisimilitude>
Perhaps I should point out that this tool is an interactive machine code development tool of my own design, created in part so I can write very efficient machine code.
<verisimilitude>
You already wrote that, fiddlerwoaroof.
<fiddlerwoaroof>
I'm not sure what's happening :)
<verisimilitude>
Are you using Emacs as your IRC client?
<fiddlerwoaroof>
yeah, I think I had a hanging prefix when I switched back
<aeth>
fiddlerwoaroof: I'm happy with 50-125 MB in a non-game/non-intense program... SBCL is just a bit too large. I'd prefer if it was closer to 50 MB. SBCL as a key component of the OS would be tricky with its high footprint, though. It would have to do a lot of services in one process to save on RAM.
<beach>
fiddlerwoaroof: Yes, so it's interesting. If only around 1/7 of all symbol are bound, why would an implementation put the symbol value in a slot in the symbol?
<fiddlerwoaroof>
I'm not really sure
<verisimilitude>
Care for a link, gilberth?
<gilberth>
verisimilitude: What kind of link?
<beach>
fiddlerwoaroof: It is mostly a rhetorical question.
orivej has quit [Remote host closed the connection]
<gilberth>
beach: Perhaps because in ancient times the symbol value slot was important. Or it was important to quickly access it. These days lexicals aren't accessed through the symbol value slot anymore. [Deep binding versus shallow binding.] But then I still think this is a non-issue.
<verisimilitude>
I mean a link to the machine code tool I've been working on.
<verisimilitude>
It's my understanding symbols once only had a property list and eventually the function and value slots were added as an optimization.
orivej has joined #lisp
<beach>
gilberth: Like I said, it's mostly a rhetorical question.
igemnace has quit [Quit: WeeChat 2.4]
<beach>
gilberth: ... since SICL stores everything except the package and the name in the first-class global environment.
<gilberth>
beach: Sure. I already figured that.
<gilberth>
beach: Yes, and given multithreading and dynamic binding, there really isn't a plain value slot anymore.
igemnace has joined #lisp
<beach>
Exactly.
<beach>
But such considerations require careful contemplation.
milivoj has joined #lisp
vibs29 has quit [Ping timeout: 272 seconds]
vibs29 has joined #lisp
scymtym has quit [Read error: Connection reset by peer]
_whitelogger has joined #lisp
abhixec has quit [Ping timeout: 250 seconds]
ggole has joined #lisp
actuallybatman has joined #lisp
nowhere_man has quit [Ping timeout: 258 seconds]
<splittist>
good morning
<loke>
hello splittist
keep_learning has quit [Quit: Ping timeout (120 seconds)]
lumm has joined #lisp
varjag has joined #lisp
flamebeard has quit [Remote host closed the connection]
scymtym has joined #lisp
<beach>
Hello splittist.
jruchti has quit [Ping timeout: 245 seconds]
moldybits has quit [Quit: WeeChat 2.2]
Arcaelyx has quit [Ping timeout: 272 seconds]
smasta has quit [Ping timeout: 245 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
jruchti has joined #lisp
schweers has joined #lisp
moldybits has joined #lisp
hhdave has joined #lisp
Zaab1t has joined #lisp
smasta has joined #lisp
Zaab1t has quit [Client Quit]
wanz has quit [Quit: wanz]
smasta has quit [Ping timeout: 255 seconds]
smasta has joined #lisp
schjetne has joined #lisp
heisig has joined #lisp
defaultxr has joined #lisp
smasta has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
rozenglass has quit [Ping timeout: 255 seconds]
robdog_ has joined #lisp
Oddity has quit [Read error: Connection reset by peer]
peterhil has quit [Read error: Connection reset by peer]
stackspace has quit [Ping timeout: 245 seconds]
thijso has quit [Ping timeout: 245 seconds]
mrSpec has quit [Ping timeout: 245 seconds]
phenethylamine has quit [Ping timeout: 245 seconds]
cmatei has quit [Ping timeout: 245 seconds]
thijso has joined #lisp
AdmiralBumbleBee has joined #lisp
datajerk has joined #lisp
macbug has quit [Remote host closed the connection]
sz0 has quit [Quit: Connection closed for inactivity]
Oddity has joined #lisp
robdog has joined #lisp
isoraqathedh has quit [Disconnected by services]
isoraqathedh has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
macbug has joined #lisp
jb__ has joined #lisp
ggole has quit [Quit: Leaving]
jb____ has quit [Ping timeout: 245 seconds]
robdog has joined #lisp
smasta has joined #lisp
wanz has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
smasta has quit [Ping timeout: 255 seconds]
robdog has joined #lisp
arpunk_ has joined #lisp
arpunk has quit [Ping timeout: 255 seconds]
robdog has quit [Ping timeout: 264 seconds]
volkov has joined #lisp
status402 has joined #lisp
robdog has joined #lisp
jb__ has quit [Ping timeout: 250 seconds]
wanz has quit [Quit: wanz]
robdog has quit [Ping timeout: 252 seconds]
cmatei has joined #lisp
surrounder has quit [Remote host closed the connection]
Inline has quit [Read error: Connection reset by peer]
Inline has joined #lisp
Inline has quit [Client Quit]
smasta has joined #lisp
lumm has quit [Quit: lumm]
smasta has quit [Ping timeout: 272 seconds]
Zaab1t has joined #lisp
wanz has joined #lisp
nirved has quit [Read error: Connection reset by peer]
patrixl has joined #lisp
lumm has joined #lisp
makomo has quit [Quit: WeeChat 2.2]
sbarbit has joined #lisp
nirved has joined #lisp
schjetne has quit [Ping timeout: 272 seconds]
robdog has joined #lisp
karlosz has quit [Quit: karlosz]
lumm has quit [Read error: Connection reset by peer]
lumm has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
lumm has quit [Ping timeout: 258 seconds]
lumm_ has joined #lisp
lumm_ is now known as lumm
gxt has quit [Ping timeout: 250 seconds]
Patternmaster has joined #lisp
smasta has joined #lisp
wanz has quit [Quit: wanz]
smasta has quit [Ping timeout: 250 seconds]
Patternmaster has quit [Quit: leaving]
Zaab1t has quit [Ping timeout: 272 seconds]
Patternmaster has joined #lisp
wanz has joined #lisp
m00natic has joined #lisp
shrdlu68 has quit [Ping timeout: 246 seconds]
Lycurgus has joined #lisp
lumm has quit [Remote host closed the connection]
schjetne has joined #lisp
smasta has joined #lisp
robdog has joined #lisp
schjetne has quit [Read error: No route to host]
smasta has quit [Ping timeout: 255 seconds]
robdog has quit [Ping timeout: 250 seconds]
schjetne has joined #lisp
volkov has quit [Quit: volkov]
tripty has quit [Ping timeout: 264 seconds]
robdog has joined #lisp
tripty has joined #lisp
skeuomorf has joined #lisp
skeuomorf has left #lisp [#lisp]
aerique has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
Lord_of_Life_ has joined #lisp
patrixl has quit [Remote host closed the connection]
Lord_of_Life has quit [Ping timeout: 255 seconds]
Lord_of_Life_ is now known as Lord_of_Life
Lycurgus has quit [Quit: Exeunt]
Zaab1t has joined #lisp
ggole has joined #lisp
hhdave_ has joined #lisp
specbot has quit [Disconnected by services]
minion has quit [Disconnected by services]
specbot has joined #lisp
minion has joined #lisp
liead has joined #lisp
robdog has joined #lisp
peterhil has joined #lisp
nalkri` has joined #lisp
benkard has joined #lisp
lavaflow has joined #lisp
stux|RC has joined #lisp
defaultxr has quit [Ping timeout: 245 seconds]
Zaabtop has joined #lisp
juristi_ has joined #lisp
status402_ has joined #lisp
malm has joined #lisp
vertigo_ has joined #lisp
zigpaw has quit [Ping timeout: 246 seconds]
ft has quit [Ping timeout: 246 seconds]
DGASAU has quit [Ping timeout: 246 seconds]
vertigo has quit [Ping timeout: 246 seconds]
drewlander has quit [Ping timeout: 246 seconds]
status402 has quit [Ping timeout: 246 seconds]
peterhil` has quit [Ping timeout: 246 seconds]
nalkri has quit [Ping timeout: 246 seconds]
easye has quit [Ping timeout: 246 seconds]
vibs29 has quit [Ping timeout: 255 seconds]
hhdave has quit [Ping timeout: 255 seconds]
jprajzne has quit [Ping timeout: 255 seconds]
malm_ has quit [Ping timeout: 255 seconds]
CrazyEddy has quit [Ping timeout: 255 seconds]
Zaab1t has quit [Ping timeout: 255 seconds]
dmiles has quit [Ping timeout: 255 seconds]
arpunk_ has quit [Ping timeout: 255 seconds]
sbarbit has quit [Ping timeout: 255 seconds]
mulk has quit [Ping timeout: 255 seconds]
rippa has quit [Ping timeout: 255 seconds]
juristi has quit [Ping timeout: 255 seconds]
jfb4 has quit [Ping timeout: 255 seconds]
edgar-rft has quit [Ping timeout: 255 seconds]
Necktwi has quit [Ping timeout: 255 seconds]
adlai has quit [Ping timeout: 255 seconds]
aerique has quit [Ping timeout: 255 seconds]
Lord_of_Life has quit [Ping timeout: 255 seconds]
schjetne has quit [Ping timeout: 255 seconds]
Patternmaster has quit [Ping timeout: 255 seconds]
datajerk has quit [Ping timeout: 255 seconds]
lavaflow_ has quit [Ping timeout: 255 seconds]
frodef has quit [Ping timeout: 255 seconds]
masterdonx has quit [Ping timeout: 255 seconds]
aindilis has quit [Ping timeout: 255 seconds]
vaporatorius has quit [Ping timeout: 255 seconds]
Jesin has quit [Ping timeout: 255 seconds]
bobby has quit [Ping timeout: 255 seconds]
hhdave_ is now known as hhdave
Zaabtop is now known as Zaab1t
benkard is now known as mulk
MasterdonY has joined #lisp
Necktwi_ has joined #lisp
logicmoo has joined #lisp
vibs29 has joined #lisp
DGASAU has joined #lisp
arpunk_ has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
Jesin has joined #lisp
bobby has joined #lisp
schjetne has joined #lisp
Lord_of_Life has joined #lisp
datajerk has joined #lisp
juristi_ is now known as juristi
Zaab1t has quit [Quit: bye bye friends]
lucasb has joined #lisp
robdog has joined #lisp
Essadon has joined #lisp
Essadon has quit [Max SendQ exceeded]
Essadon has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
nalkri` is now known as nalkri
easye has joined #lisp
nowhere_man has joined #lisp
gareppa has joined #lisp
robdog has joined #lisp
q3d has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
arpunk_ is now known as arpunk
xkapastel has joined #lisp
dddddd has joined #lisp
smasta has joined #lisp
robdog has joined #lisp
smasta has quit [Ping timeout: 258 seconds]
smasta has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
igemnace has quit [Quit: WeeChat 2.4]
smasta has quit [Ping timeout: 250 seconds]
robdog has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
schjetne has quit [Ping timeout: 250 seconds]
grumble has quit [Quit: in lieu of the innuendo in the end know my intent though]
grumble has joined #lisp
q9929t has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
amerlyq has joined #lisp
wanz_ has joined #lisp
igemnace has joined #lisp
nowhere_man has quit [Ping timeout: 250 seconds]
Inline has joined #lisp
wanz has quit [Ping timeout: 245 seconds]
robdog has joined #lisp
wanz_ has quit [Remote host closed the connection]
robdog has quit [Ping timeout: 264 seconds]
wanz has joined #lisp
robdog has joined #lisp
<pfdietz>
fiddlerwoaroof: I was thinking your security conditions (or, rather, their negation) could be expressed and given to Z3, and it would tell you if it was possible to violate them.
<jmercouris>
i've updated it with more information
<jmercouris>
you can see the original function that I'm hoping to trim down via usage of this macro
xkapastel has quit [Quit: Connection closed for inactivity]
nowhere_man has quit [Ping timeout: 257 seconds]
<verisimilitude>
I suppose that would clearly be an improvement, yes.
FreeBirdLjj has joined #lisp
<jmercouris>
within a macro, how can I iterate through a list and emit code as I iterate through that list
<jmercouris>
in this case, I have a list of dotted pairs, slot/value
<Bike>
macro functions don't "emit", they're pure. so you probably want to collect a bunch of forms.
<verisimilitude>
You have a body that you're expanding to and it's fairly obvious how you can collect a list of forms created with each element of that list to later dump into the body.
<jmercouris>
so a loop with a collect will do it?
<verisimilitude>
I have an example of my own of this, if you're interested.
<jmercouris>
let me give it a try and if I fail I will post what I've been doing
<verisimilitude>
Macros aren't necessarily pure, Bike.
<verisimilitude>
A macro can cause I/O, change global state, etc.
cgay has quit [Remote host closed the connection]
<Bike>
do you think that such rare things are relevant here
FreeBirdLjj has quit [Ping timeout: 240 seconds]
<verisimilitude>
If you're going to claim otherwise, yes.
<jmercouris>
Bike: alright, so I've updated the gist
<Bike>
okay so you're deeply confused here.
<jmercouris>
not sure where to go from here
<Bike>
the macro function needs to return a form.
<jmercouris>
yeah, I'm trying to return this big let
<Bike>
in the gist you have the macro function returning a form with a loop in it
<Bike>
but you don't want a loop to happen at runtime. you want to return a bunch of setf forms. right?
<jmercouris>
correct
<verisimilitude>
You need to splice things in, jmercouris.
<verisimilitude>
You're familiar with , and ,@ right?
<Bike>
so you don't want to return a loop form, you want to return a bunch of setf forms
<jmercouris>
I'm familiar with , but ,@ has always confused me
<jmercouris>
I only use ,@body for effectively capturing the rest
<Bike>
try `(1 2 ,@(loop for 3 below 6) 6 7) and see whatcha get
<Bike>
obviously you don't want a literal SLOT symbol there.
gxt has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
logicmoo is now known as dmiles
<jmercouris>
It feels quite close
<jmercouris>
at least the first part, and I've learnt a lot about macros in the past 10 minutes
<verisimilitude>
Are you ready for the GENSYM help?
<jmercouris>
not yet
beach has joined #lisp
<jmercouris>
I've edited it again
<jmercouris>
I have a most interesting condition being signalled
<jmercouris>
The value LIST is not of type LIST
<jmercouris>
not sure how that would be possible, but here we are
<jmercouris>
it happens when I try to do my macroexpansion
robdog has joined #lisp
<verisimilitude>
I'll explain.
<verisimilitude>
You don't need that LIST there.
<verisimilitude>
Macros don't evaluate forms given to them like a function does.
<verisimilitude>
Just remove that and then you'll have a list of lists and the error will go away.
<jmercouris>
hmm ok
<jmercouris>
right, they don't evaluate the forms, I remember reading that
nowhere_man has joined #lisp
<jmercouris>
one final issue
<jmercouris>
it generated (SETF (REVIEW-TEXT OBJECT) (REVIEW-VALUE))
<jmercouris>
obviously it would try to execute review-value
<verisimilitude>
You didn't use the . syntax in the CONS you passed in.
<jmercouris>
ah, yes
<jmercouris>
ok, now gensym, generates a unique symbol to avoid clashes right?
<jmercouris>
basically to make sure that within the lexical context if object is bound to something there won't be shadowing and strange behavior?
robdog_ has joined #lisp
<verisimilitude>
Yes.
<verisimilitude>
Here's what you do; Surround the body of your macro with this, where ... is what's currently there:
<verisimilitude>
(let ((object (gensym)))
<verisimilitude>
...)
<verisimilitude>
Then replace every instance of object with ,object and you'll have a unique symbol referred to in every necessary place.
<jmercouris>
right
robdog has quit [Ping timeout: 258 seconds]
liead is now known as adlai
<jmercouris>
very interestingly random symbol it came up with
<jmercouris>
anyways that is good
<jmercouris>
now comes the second challenging part
<jmercouris>
doing the make-instance
<jmercouris>
so in my objects, I have the convention of an accessor for slot fish being fish and the :initarg being :fish
<jmercouris>
so I would need to somehow transform fish to :fish
<jmercouris>
to do the make-instance part of the macro
<jmercouris>
does that make sense?
<Bike>
sure.
<jmercouris>
can I just do string concatenation?
Arcaelyx has joined #lisp
<Bike>
no, because these are symbols, not strings.
<jmercouris>
what if I convert the symbol to a string and back
robdog_ has quit [Ping timeout: 259 seconds]
<beach>
And `:' is not part of the symbol name.
<jmercouris>
or better yet, is there a better solution?
<Bike>
no, that's pretty much how it goes.
<Bike>
you'll want the SYMBOL-NAME and INTERN functions.
<jmercouris>
beach: it just means being part of the keyword package, right?
<verisimilitude>
You can just INTERN the SYMBOL into the KEYWORD package and use the result.
<verisimilitude>
The SYMBOL-NAME, that is, yes.
<beach>
jmercouris: Yes, `:' is known as a package marker. It is not part of the name.
<jmercouris>
but because it is not prefixed with anything else it is special
<jmercouris>
so it would be like cl-user:fish
<jmercouris>
but when you do just :fish, it is an implied thing
<verisimilitude>
You can think of the default as being KEYWORD, yes.
<jmercouris>
why isn't it something like keyword-package:fish?
<Bike>
keyword:fish is the same as :fish
<Bike>
since you mention it
<jmercouris>
aha, good to know
<jmercouris>
so should I do the string conversion or intern the symbol?
<Bike>
you have to get the symbol-name, and then intern that
<Bike>
so both i guess
<Bike>
it's not really "conversion" though
<jmercouris>
how not?
<jmercouris>
isn't (symbol-name 'some-symbol) converting a symbol to a string?
<Bike>
no, it's retrieving the name.
<jmercouris>
makes sense
<Bike>
you're discarding the package, for instance
<jmercouris>
otherwise it would be something like (parse-symbol-name 'some-symbol)
<jmercouris>
right?
<Bike>
dunno what you mean.
<jmercouris>
are symbols objects?
<Bike>
everything is an object.
<Bike>
an exciting tautology
<jmercouris>
is symbol-name the slot accessor for the string representation of a symbol?
<pjb>
well types are not first class objects.
<Bike>
basically. though you can't set it.
<pjb>
any lisp value is a lisp object.
<jmercouris>
alright, before this gets too off topic, let me try my hand at the make instance part of the macro
<pjb>
jmercouris: symbol-name is a reader, not an accessor, and it's only for the symbol name, not any representation of the symbol.
<beach>
I often say that phrases like "everything is an object" do not make much sense.
<pjb>
jmercouris: for example (symbol-name 'foo) #| --> "FOO" |# but "foo" is also a representation of foo when (readtable-case *readtable*) is :upcase.
<Bike>
symbols are not objects that you can make-instance and such, necessarily, if that's what you had in mind, jmercouris
<Bike>
but it can be sensible to think of them as having slots in a similar fashion
<jmercouris>
that is what I had in mind
<Bike>
right. sorry to confuse.
<pjb>
Bike: the constructor for symbols is make-symbol. How is that different from make-instance?
<jmercouris>
why isn't it make-instance 'symbol?
<Bike>
well it's spelled with an "s" and a "y" and so on
robdog has joined #lisp
<Bike>
because the make-instance parts of the language were bolted on later.
<pjb>
jmercouris: because symbols are not standard-object.
<verisimilitude>
Well, I held back from arguing with Bike for jmercouris' sake over nothing, apparently.
<jmercouris>
:D
<jmercouris>
ok, I need to focus, let me try and brb
<Bike>
yes, thank you for that.
q3d has quit [Ping timeout: 256 seconds]
nalkri has quit [Ping timeout: 272 seconds]
<jmercouris>
ok, so first speedbump
<jmercouris>
I can't collect a set of forms to create the make-instance
<Bike>
you're collecting the initargs, no?
<jmercouris>
because (make-instance 'reviews :fish fish) has only one form
<jmercouris>
I don't understand, slot is bound above, yet not bound below
<jmercouris>
and it also complains about class being unused, but there is mot definitely a ,class within the defmacro body
lumm has quit [Client Quit]
<jmercouris>
I am not doing any interning or anything yet to :fish, just trying to output an incorrect form of make-instance first
<beach>
Because you have nested backquotes.
lumm has joined #lisp
<jmercouris>
so what does that mean? what are the consequences?
<jmercouris>
do I have to do something like ,,class?
<beach>
My immediate fix would be to avoid nested backquotes.
<Inline>
errm
<beach>
I don't see why you need the inner one here.
<Inline>
who has put $(shell bla) in Makefiles ?
<jmercouris>
ok, how else would I do it?
<Inline>
you can only count on $SHELL not shell
<Inline>
so shell = $SHELL
<jmercouris>
Inline: you can't count on anything, and I don't know what that has to do with #lisp
<beach>
jmercouris: What is the nature of the argument to save-dao?
<Inline>
clsql's Makefile
<jmercouris>
it's just an object that subclasses another
<Inline>
is problematic
<Inline>
i got db-mysql stuff failing to create an .so file
<jmercouris>
so I make the object, and then invoke save-dao on that object to save it to the database
<beach>
jmercouris: Then don't quote the (make-instance...) form.
robdog has quit [Ping timeout: 264 seconds]
<Bike>
jmercouris: this will result in passing a make-instance FORM at runtime, but you want to pass an actual instance. you don't want that quotation around make-instance.
<Inline>
and i thought the command line gcc spec was false but that's not the case
<Inline>
it's failing for another reason
<beach>
jmercouris: If you quote the form, then save-dao will be passed a form.
<verisimilitude>
You don't need the , in the second LOOP, jmercouris.
<Inline>
and i found that to be the $(shell blah) construct
<jmercouris>
verisimilitude: how not? do I not want to collect a set of :fish fish :salmon salmon?
robdog has joined #lisp
<jmercouris>
beach: trying to understand what you are saying here, it will be passed the form instead of the form being evaluated, yes?
Zaab1t has joined #lisp
varjag has joined #lisp
nanoz has joined #lisp
milivoj has quit [Remote host closed the connection]
<Inline>
give a man a fish .....
<Inline>
or give a man fishers daughter....
<Inline>
lol
nalkri has joined #lisp
gxt has joined #lisp
robdog_ has joined #lisp
mulk has joined #lisp
froggey_ is now known as froggey
schweers has quit [Ping timeout: 264 seconds]
xkapastel has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
smasta has quit [Ping timeout: 246 seconds]
robdog has joined #lisp
Aruseus has quit [Read error: Connection reset by peer]
robdog_ has quit [Ping timeout: 264 seconds]
smasta has joined #lisp
Zaab1t has quit [Quit: bye bye friends]
m00natic has quit [Remote host closed the connection]
LiamH has joined #lisp
nanoz has quit [Read error: Connection reset by peer]
karlosz has joined #lisp
robdog_ has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
robdog_ has quit [Ping timeout: 250 seconds]
froggey has quit [Remote host closed the connection]
<jmercouris>
if only I had known the loop macro supports append
<jmercouris>
then I would have been done like 30 minutes ago :(
<jmercouris>
or two collect statements, that I also did not think about, that at least I knew about
robdog has quit [Ping timeout: 264 seconds]
robdog has joined #lisp
paul0 has quit [Ping timeout: 240 seconds]
paul0 has joined #lisp
scymtym has quit [Ping timeout: 252 seconds]
<jmercouris>
thanks for the tips everyone!
robdog has quit [Ping timeout: 264 seconds]
hiroaki_ has quit [Ping timeout: 258 seconds]
<verisimilitude>
It's no issue.
robdog has joined #lisp
kyby64 has joined #lisp
edgar-rft has joined #lisp
robdog has quit [Ping timeout: 257 seconds]
nalkri has quit [Ping timeout: 245 seconds]
lumm has quit [Ping timeout: 255 seconds]
<_death>
why do you use an alist for the "values"
karlosz has quit [Quit: karlosz]
<_death>
also, order of evaluation is not what one would expect
paul0 has quit [Ping timeout: 246 seconds]
robdog has joined #lisp
bgardner has quit [Read error: Connection reset by peer]
hiroaki_ has joined #lisp
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]
<_death>
also, it looks like a race condition.. if you want to do it right it needs to be atomic
bgardner has joined #lisp
eschulte has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
mercourisj has joined #lisp
Necktwi has joined #lisp
Necktwi_ has quit [Ping timeout: 246 seconds]
zigpaw has quit [Read error: Connection reset by peer]
jmercouris has quit [Ping timeout: 255 seconds]
datajerk has quit [Ping timeout: 246 seconds]
Jesin has quit [Ping timeout: 246 seconds]
rozenglass has quit [Ping timeout: 255 seconds]
AdmiralBumbleBee has quit [Ping timeout: 255 seconds]
rozenglass has joined #lisp
Jesin has joined #lisp
Arcaelyx has quit [Ping timeout: 255 seconds]
dddddd has quit [Ping timeout: 255 seconds]
datajerk has joined #lisp
dddddd has joined #lisp
AdmiralBumbleBee has joined #lisp
Arcaelyx_ has joined #lisp
jkordani has joined #lisp
sauvin has quit [Read error: Connection reset by peer]
Elronnd has joined #lisp
Jesin has quit [Quit: Leaving]
Krystof has joined #lisp
robdog has joined #lisp
igemnace has quit [Read error: Connection reset by peer]
okeg has joined #lisp
<mercourisj>
_death: ?
robdog has quit [Ping timeout: 264 seconds]
mrSpec has joined #lisp
robdog has joined #lisp
Jesin has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
ismay has quit [Ping timeout: 264 seconds]
mercourisj has quit [Remote host closed the connection]
libertyprime has quit [Ping timeout: 245 seconds]
igemnace has joined #lisp
rozenglass has quit [Ping timeout: 245 seconds]
smasta has joined #lisp
gxt has quit [Ping timeout: 245 seconds]
<_death>
you should run it inside a transaction.. and looks like postmodern has upsert-dao
vilivulpine has joined #lisp
libertyprime has joined #lisp
jb has joined #lisp
kyby64 has quit [Quit: Leaving]
Lord_of_Life has quit [Excess Flood]
Lord_of_Life has joined #lisp
robdog has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
defaultxr has joined #lisp
gxt has joined #lisp
zhlyg has joined #lisp
robdog has joined #lisp
scymtym has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
milivoj has joined #lisp
DGASAU has joined #lisp
robdog has joined #lisp
ckonstanski has joined #lisp
izh_ has left #lisp [#lisp]
Aruseus has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
pierpal has quit [Remote host closed the connection]
Josh_2 has joined #lisp
robdog has joined #lisp
lumm has joined #lisp
skidd0 has joined #lisp
<skidd0>
hello. When i use drakma to GET an xml page, the uri has a \ in it. drakma uses PURI and it's messing up the string. e.g. http://two\words.com becomes http://twowords.com
<skidd0>
i tried two\\words but then PURI complains of an illegal char
<skidd0>
i'm trying to pull up PURIs homepage but it's down?
robdog has quit [Ping timeout: 250 seconds]
pfdietz has joined #lisp
<dlowe>
surely backslashes can't be in domain names?
<dlowe>
they'd need to be url-encoded even if they can
<skidd0>
that's the path i'm trying now
<skidd0>
franz has docs for PURI
<skidd0>
and parse-uri says excaped encodings of the form %<hex><hex> are converted
<skidd0>
so i tried to put in a %5c (html hex encoding for \)
rozenglass has joined #lisp
<skidd0>
and \%5c
<skidd0>
nether worked
milivoj has quit [Quit: milivoj]
lumm has quit [Read error: Connection reset by peer]
zhlyg has quit [Read error: Connection reset by peer]
robdog has joined #lisp
<skidd0>
those franz links seem to be for Allegro CL
<skidd0>
would that be too differenct from sbcl?
aeth has quit [Ping timeout: 250 seconds]
robdog has quit [Ping timeout: 264 seconds]
aeth has joined #lisp
<ober>
as different as two can be outside the spec
lumm has joined #lisp
robdog has joined #lisp
<skidd0>
okay so i figured it out
<skidd0>
drakma has a :preserve-uri keyword
<skidd0>
so that plus doing two%5Cwords gets a correct url
<skidd0>
yay!
<skidd0>
thanks for letting me talk it out i spose
skidd0 has quit [Quit: o/]
jstypo has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
robdog has joined #lisp
lumm has quit [Ping timeout: 264 seconds]
rumbler31 has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
nowhere_man has quit [Read error: Connection reset by peer]
nowhere_man has joined #lisp
lumm has joined #lisp
robdog has joined #lisp
<Inline>
oO
robdog has quit [Ping timeout: 250 seconds]
amerlyq has quit [Quit: amerlyq]
robdog has joined #lisp
robdog_ has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
robdog_ has quit [Ping timeout: 264 seconds]
robdog has joined #lisp
hiroaki_ has quit [Ping timeout: 240 seconds]
robdog_ has joined #lisp
rumbler31 has quit [Remote host closed the connection]
robdog has quit [Ping timeout: 264 seconds]
rcosta has joined #lisp
robdog_ has quit [Ping timeout: 264 seconds]
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rumbler31 has joined #lisp
gxt has quit [Quit: WeeChat 2.3]
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
rumbler31 has quit [Remote host closed the connection]
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
varjag has quit [Ping timeout: 240 seconds]
gxt has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
powerbit has quit [Ping timeout: 268 seconds]
robdog has joined #lisp
rcosta has quit [Remote host closed the connection]
lucasb has quit [Quit: Connection closed for inactivity]
hhdave has joined #lisp
rcosta has joined #lisp
rcosta has quit [Remote host closed the connection]
rcosta has joined #lisp
Bike has quit []
robdog has quit [Ping timeout: 264 seconds]
rcosta has quit [Ping timeout: 250 seconds]
abhixec has joined #lisp
rcosta has joined #lisp
hhdave has quit [Ping timeout: 255 seconds]
robdog has joined #lisp
rcosta has quit [Ping timeout: 240 seconds]
<stylewarning>
Suppose I have a generic function F of one argument and a class named C. What's a good way to see if F can be called on an instance of C in SBCL?
<stylewarning>
(i.e., that the method is compatibly specialized)
robdog has quit [Ping timeout: 250 seconds]
sjl_ has quit [Ping timeout: 244 seconds]
Essadon has quit [Quit: Qutting]
robdog has joined #lisp
<aeth>
stylewarning: I think I had/have a similar issue. I don't care what class C is as long as it implements F, and F runs last (in an unwind-protect... it's actually called cleanup) so I would prefer for it to fail before the whole thing starts if F can't be called on an instance c of C rather than the actual runtime error at the end.
<aeth>
stylewarning: Is that similar to your issue?
<stylewarning>
aeth: yes, i want to verify C implements the (simple!) protocol of just F
<stylewarning>
(or whatever the right way to say that sentence is)
<aeth>
stylewarning: I think it would be something like this, but I'm not 100% sure. (defun implements-cleanup-p (instance) (closer-mop:compute-applicable-methods-using-classes #'cleanup (list (class-of instance))))
<stylewarning>
let me check that out
rcosta has joined #lisp
actuallybatman has quit [Read error: No route to host]
<aeth>
stylewarning: note that Bike noted that it should be avoided "in the middle of a program" so if you're planning on doing it every call instead of validating on startup, that might not be the best idea
rcosta has quit [Ping timeout: 255 seconds]
lumm has quit [Quit: lumm]
<aeth>
It does seem to be pretty fast for me, though.