<holycow>
art as code, presenter strings us along through interesting art / code experiences from game of life through languages designed as drawings or rock songs
<holycow>
on the one hand its fun
<holycow>
on the other hand it's like watching slowly realize that we are about to be exterminated by machines like a giant cosmic joke
<beach>
Thanks for the description.
zooey_ has quit [Ping timeout: 240 seconds]
<holycow>
hope it peaks peoples interest.
zooey has joined #lisp
<holycow>
like watching HUMANITY slowly
sdumi has quit [Ping timeout: 272 seconds]
sdumi has joined #lisp
karlosz has joined #lisp
karlosz has quit [Client Quit]
<no-defun-allowed>
not Common Lisp, don't care
buffergn0me has joined #lisp
Cymew has joined #lisp
sauvin has joined #lisp
fbmnds has joined #lisp
fbmnds has left #lisp [#lisp]
rwcom341 has quit [Remote host closed the connection]
rwcom341 has joined #lisp
louxiu` has joined #lisp
fishdev has joined #lisp
ayuce has joined #lisp
Oladon has quit [Quit: Leaving.]
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
JohnMS_WORK has joined #lisp
<fishdev>
I can't seem to find the ansi common lisp standard draft, it is down on the common-lisp.net site
gravicappa has joined #lisp
buffergn0me has quit [Ping timeout: 240 seconds]
karlosz has joined #lisp
louxiu` has left #lisp ["ERC (IRC client for Emacs 25.3.1)"]
<beach>
I remember that it was tricky to find.
ayuce has quit [Remote host closed the connection]
ayuce has quit [Remote host closed the connection]
quazimodo has joined #lisp
<doomlist3>
(dolist (met ((2 3) (4 5))
<doomlist3>
(format t "~{~a and ~a~%~}~%" met)))
<doomlist3>
what is the right code.
<doomlist3>
gigamonkeys chapter 2 has : (dolist (cd *db*)
<aeth>
quote the list
<doomlist3>
(format t "~{~a:~10t~a~%~}~%" cd))
<doomlist3>
no in *db* list is not quoted at all... in gigamonkeys.com
<aeth>
yes, that's a variable
<aeth>
((2 3) (4 5)) is an attempt to call the function (2 3)
ayuce has joined #lisp
<aeth>
you would need (list (list 2 3) (list 4 5)) or '((2 3) (4 5)) to get a list as a data structure.
<aeth>
(or any other combination, e.g. (list '(2 3) '(4 5)))
<doomlist3>
(dolist (cd *db*) ... is an attempt to all the function cd?
<phoe>
nope, DOLIST has a special syntax
<aeth>
no, because dolist is a macro so it doesn't have to evaluate its forms
<phoe>
CD is the variable that is bound to the successive values of *DB*
<aeth>
*db* is getting evaluated, though. Or ((2 3) (4 5))
<aeth>
You just kind of have to know what the macro is doing. In this case, binding each successive value of the list to the variable cd
<doomlist3>
but writing *db* is the same as writing it's value
frgo_ has quit [Remote host closed the connection]
<beach>
doomlist3: If you look at the description of DOLIST, you see that it says (dolist (var list-form) ...)
<beach>
doomlist3: The list-form is a FORM meaning it is evaluated.
frgo has joined #lisp
<aeth>
doomlist3: ((2 3) (4 5)) can't be written without being quoted or the language will attempt to evaluate it, unless in the correct spot of a macro. Even if *db* returns ((2 3) (4 5)) in the REPL, you can only get it directly with something like '((2 3) (4 5))
<beach>
doomlist3: When you write *DB* as the form, the form is a variable, and evaluating it means to take its value.
<aeth>
s/you can only get it directly/you can only run it directly/
<beach>
doomlist3: But when you write ((2 3) (4 5)) the form is a list, meaning it's a function applications.
<beach>
doomlist3: So you attempt to call the function named (2 3), giving it an argument which is the value of the form (4 5), which is another function application.
<no-defun-allowed>
You are missing a paren on the right of your list.
<phoe>
doomlist3: mismatched parens
<phoe>
(dolist (met '((2 3) (4 5)) )(format t "~{~a and ~a~%~}~%" met))
<phoe>
or even (dolist (met '((2 3) (4 5))) (format t "~{~a and ~a~%~}~%" met))
<beach>
doomlist3: Even though you now have something that works, it is important that you read and understand what people told you.
<beach>
doomlist3: Otherwise, you will never learn, and you will ask essentially the same questions over and over again.
<aeth>
doomlist3: '(foo) is syntactic sugar for (quote (foo)) and macros and special operators do not have to evaluate their arguments. But they can, and DOLIST happens to evaluate the list-form part of its syntax (as well as the body part)
<beach>
doomlist3: And that, in turn, means that people are going to get fed up with helping you.
<aeth>
doomlist3: Quote more or less uses the distributive property of an algebra, so '(a b c) is the same as (list 'a 'b 'c) with the caveat (that's not too important right now) that the first list is "literal" and the second is not.
<jasom>
why-oh-why is CFFI missing a way to get "errno" :(
frgo_ has joined #lisp
frgo_ has quit [Remote host closed the connection]
frgo has quit [Read error: Connection reset by peer]
<aeth>
doomlist3: The important thing here is that a list either needs to be quoted (or quasiquoted with `) or written with LIST, or else the language is going to try to funcall the first element... unless it's in a special part of a macro that's not evaluated, which isn't the case.
<phoe>
with a note, "Note that accessing errno this way won’t work with every implementation of the C standard library."
<jasom>
phoe: does POSIX require that errno be a variable?
<Shinmera>
Isn't errno more complicated due to threading and crap
<phoe>
jasom: nope, that's why it's more complicated
<phoe>
also what Shinmera said
<jasom>
pho so cffi-posix doesn't do what I asked for :P
<phoe>
huh, well then
<jasom>
The proper way would be to compile a C function like "int get_errno() { return errno; }" but that's non-trivial
<phoe>
yes, it requires a C compiler, since errno is allowed to be a macro
<Shinmera>
Better question is: why oh why did they fuck up error mechanisms so bad
<White_Flame>
legacy knows no bounds of poor decision making
<aeth>
an error number makes sense in a 'low level' sense.
<aeth>
now, the execution of the concept is still messed up
<phoe>
White_Flame: except for (unsigned-byte 64) after which you go back to 0
mmkarakaya has joined #lisp
<jasom>
most lisp ffi implementations have a way of gettinr errno (which they would have to in order to do any system-calls that might yield EINTR properly)
<jasom>
which makes me wonder why CFFI doesn't wrap those
<aeth>
are they exposed?
ayuce has quit [Remote host closed the connection]
<doomlist3>
phoe: CL is too messy syntax, unlike scheme. (loop for x in L do...) instead of (for x in L...)
<no-defun-allowed>
So Scheme has (for x in l ...)?
<doomlist3>
idk
<doomlist3>
but python has neat syntax like that.
<beach>
doomlist3: I think you had better use Scheme instead then.
<aeth>
no-defun-allowed: Schemes can have for loops, but not portably.
<doomlist3>
no i wont scheme.
<aeth>
Well, I mean, not portably built into Scheme
pjb has quit [Ping timeout: 256 seconds]
<no-defun-allowed>
I'm very tempted to say "no", but in either case, you admit you're talking out of your butt.
<aeth>
Portably, Scheme uses tail recursion
<beach>
doomlist3: There is no point in complaining about Common Lisp syntax. It is what it is. It won't change.
<beach>
doomlist3: Besides, you are not in a position (yet) to have any valid complaints.
<aeth>
Yes. Lisp syntax will change. It isn't set in stone. Let's do a revision right now. (defmacro for (&rest forms) `(loop for ,@forms))
<aeth>
(for x in (list 1 2 3 4) do (print x))
toorevitimirp has joined #lisp
<aeth>
Problem solved. Next?
<no-defun-allowed>
doomlist3: Of course, you could write (defmacro for (&body body) `(loop for ,@body)) if you were upset about one symbol.
rogersm has quit [Ping timeout: 240 seconds]
ayuce has joined #lisp
<aeth>
(technically SBCL uses "keywords-and-forms" instead of "forms" and that's more accurate)
<doomlist3>
nice i got my for but I don't want 'do' at the end, i want it to be more pythonic
<aeth>
doomlist3: you have to have a do because you can have multiple FORs
<phoe>
doomlist3: seriously, write Python instead
<beach>
doomlist3: You had better use Python then.
<phoe>
you come to a CL channel complaining that CL is not Pythonlike enough
<no-defun-allowed>
Okay, now how would you simplify (for x in xs sum x)?
<aeth>
using the keyword style because it's clearer in a long one-liner: (loop :for x :in y :for i :from 0 :for alternating := t :then (not alternating) :do ...)
<jasom>
doomlist3: (defmacro for (var in form &body b) (assert (string= (symbol-name in) "IN")) `(loop for ,var in ,form do ,@b))
<doomlist3>
phoe: i do write python but I want to design my own language, and i want to implement my own lisp. hence I came here. I do python as a toy.
rogersm has joined #lisp
dale has quit [Quit: My computer has gone to sleep]
<beach>
Oh, another Lisp. Fantastic!
<phoe>
doomlist3: there's repositories for that, most famous being Make A Lisp (mal)
<aeth>
phoe: I don't think MAL is a good source for writing a Lisp in Common Lisp. I think it's an unusual Lisp.
<aeth>
I haven't looked into it closely.
<jasom>
doomlist3: implementing a lisp is probably off-topic for this channel unless you are implementing it in CL, or the lisp you are implementing is common lisp
<doomlist3>
I am naturally attracted towards the writing lisp interpreter in lisp. Of course I will implement by lisp in CL
<aeth>
jasom: I think doomlist3 is talking about the former, i.e. writing a Lisp in Common Lisp.
<aeth>
And it's a smart decision.
<aeth>
The best language for writing a Lisp is probably Common Lisp, followed by Racket.
<aeth>
Everything else is going to add a lot of friction.
<jasom>
anyway my suggested macro gets rid of the pesky "do"
<aeth>
If you write a Lisp in Common Lisp, you can just focus on the interesting bits.
<no-defun-allowed>
phoe: I am a simple woman, I see fn, I C-w the website
<phoe>
doomlist3: in that case you're welcome to design the syntax of your new lisp in any way you'd like
<jasom>
Everyone knows the only correct language for implementing a lisp in is that lisp itself :P
<aeth>
doomlist3: Instead of writing a Lisp interpreter, you can write something that compiles to Common Lisp, sort of like a super-macro.
<phoe>
but complaining about the syntax of the host language won't get you far, really
<phoe>
which is, in this case, CL
<aeth>
jasom: but if your Lisp is written in Common Lisp, then you can eventually rewrite it in the guest Lisp by using the CLFFI, but you first need to write it in CL itself to get started.
<jasom>
aeth: right, CL is a perfectly cromulent bootstrap language
<no-defun-allowed>
aeth: wait, Mal does that "Let's write EVAL without an environment, then screw you, write an environment and another EVAL cause I lied to you" thing
<aeth>
the correct way to implement an eval is to call the compiler from it.
<jasom>
LiSP is decent for writing a lisp in scheme, which is pretty close to writing a lisp in common lisp
<jasom>
minion: tell me about LiSP
<minion>
jasom: have a look at LiSP: "Lisp in Small Pieces". This book covers Lisp, Scheme and other related dialects, their interpretation, semantics and compilation. To sum it up in a few figures: 500 pages, 11 chapters, 11 interpreters and 2 compilers. <http://pagesperso-systeme.lip6.fr/Christian.Queinnec/WWW/LiSP.html>
<jasom>
aha, minion does know about LiSP
<aeth>
hmm, I wonder
<aeth>
minion: tell me about Lisp
<minion>
aeth: please look at Lisp: "Lisp in Small Pieces". This book covers Lisp, Scheme and other related dialects, their interpretation, semantics and compilation. To sum it up in a few figures: 500 pages, 11 chapters, 11 interpreters and 2 compilers. <http://pagesperso-systeme.lip6.fr/Christian.Queinnec/WWW/LiSP.html>
<aeth>
case insensitive
<beach>
I think minion used to answer "I am written in Lisp", or something to that effect, for that query.
<phoe>
"I am lisp, lisp is me"
rogersm has quit [Ping timeout: 240 seconds]
<aeth>
we are all Lisp
<phoe>
I got really annoyed at lisp-koans yesterday
<phoe>
bad indentation, "throwing" errors, calling QUOTE a function, having tons of dead code in the framework, etc., etc..
<aeth>
phoe: I am going to disagree with you a bit. Complaining about the syntax of the host language is exactly how you justify a new Lisp. Sure, a lot can be done with macros and utility libraries and so on, but defaults and idioms do matter.
<aeth>
However, interesting complaints about the language only come after years of experience and large projects.
<aeth>
So this might be a situation where you have to build one to throw it away
<aeth>
(Of course, ideally, it wouldn't just be the syntax. There are lots of other things you might complain about, like the type system, although if you go too radical then you have no choice but to target native code and your work is much harder.)
toorevitimirp has quit [Remote host closed the connection]
<aeth>
And, as we saw with Arc, if all you do is change the syntax to perfectly match your tastes, no one will switch. You need to offer something interesting.
toorevitimirp has joined #lisp
<jackdaniel>
A new Lisp dialect! KleptoLisp (KL), it shares the standard with Common Lisp but has different idioms! :-)
<aeth>
jackdaniel: I mean, yes.
<aeth>
jackdaniel: for example, the use of foo? instead of foop or foo-p
<jackdaniel>
aeth: I agree that defaults and idioms matter (I'm already comfortable with CL idioms, but I remember when I was not, and foo? looked way more elegant)
bendersteed has joined #lisp
<jackdaniel>
n.b, such shift resembles more "a new dialect" (as opposed to "a new programming language"), than saying that elisp and common lisp are "different dialects" of LISP
<jackdaniel>
they grew way beyond a "dialectical" difference
<jackdaniel>
but that's offtopic, sorry :)
<aeth>
Anyway, if you compile to Common Lisp and are mostly runtime compatible with Common Lisp with the ability to call libraries in your language from Common Lisp or vice versa, then you have an interesting project. Well, in theory.
<jasom>
aeth: only ClozureCL of what I tried does not expose a way of getting at errno (though the only way I could find on ECL was with ffi:c-inline)
cosimone has joined #lisp
<aeth>
Pretty much every language has at least one compile-to-CL implementation, but without much use. Python, JavaScript, Ruby, Clojure, etc.
<aeth>
Maybe because there wasn't that big of a focus on library interop or maybe because the languages differed too much for useful library interop
<jasom>
aeth: it has CCL::%get-errno, but that is a non-exported symbol that starts with %, so it screams "don't rely on me"
<jackdaniel>
nobody marvelled on a wonderful name KleptoLisp :(
<jasom>
phoe: that's great news
<jasom>
Now I just need to write trivial-errno
<phoe>
jackdaniel: I had some marvels but I don't know where I left them, maybe someone took them when I wasn't looking
<phoe>
jasom: do it, and please submit it to CFFI
ayuce has quit [Remote host closed the connection]
<jasom>
though I should note that the majority of lisp implementations do not provide access to errno on windows.
toorevitimirp has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
<aeth>
jackdaniel: Anyway, I think that a future for Common Lisp is mainly as a compilation target because it is very good at being a compilation target and languages that are much worse at doing so (e.g. JS) are already popular, successful compilation targets (obviously for different reasons).
<aeth>
In a sense, every time you write a macro, you're using Common Lisp as a compilation target, and sometimes macros are practically their own languages, anyway.
CommanderViral has quit [Quit: ZNC 1.7.1+deb1+bionic1 - https://znc.in]
mjsir911 has quit [Remote host closed the connection]
mjsir911 has joined #lisp
CommanderViral has joined #lisp
yankM has joined #lisp
phoe has quit [Ping timeout: 244 seconds]
<aeth>
CL gives you a lot of things for free: GC, the numeric tower, conditions, etc. But unless you have a tiny, underspecified language (e.g. Scheme) you're probably going to have too much of a mismatch using CL as a host language to take advantage of these features.
phoe has joined #lisp
<doomlist3>
I have an important generic query- is CL sbcl as optimized as scheme's best implementations?
<doomlist3>
it's fair to compare C is faster than python, so it's fair to compare different languages provided they execute same algorithms.
<aeth>
doomlist3: I would wager that SBCL is faster, with the caveat that it has different performance characteristics, being an AOT compiled language that heavily relies on type declarations in the fastest code
<aeth>
But 2x to 5x slower than microoptimized C (which you won't really see in the wild anyway) does sound about right...
<aeth>
pretty much anything within 10x is usable
<phoe>
oh wonderful, I go into the lisp koan file named special-forms
<phoe>
and what's inside? SETF, CASE, COND
* phoe
catches fire
<jasom>
... those are macros :(
<jackdaniel>
don't forget to halt first
<phoe>
jackdaniel: thanks for the reminder
<LdBeth>
WUT RINGS U GOT
* phoe
halts, then catches fire
<aeth>
doomlist3: the difference between CL and Scheme is that all of us can, if we choose to, choose whatever the fastest implementation happens to be, and we mostly have since SBCL is the most popular (although others have other interests, and use other implementations)
<aeth>
Portable Scheme is hard, and implementations differ, sometimes considerably. Scheme is more of a language family at this point.
<aeth>
Until Racket-on-Chez is complete, fast Schemes and popular (with libraries!) Schemes are different groups
* no-defun-allowed
extinguishes phoe
amerlyq has joined #lisp
<flip214>
aeth: so you advocate Common SCHEME?
<phoe>
flip214: not only advocate, he's been writing one for a long while
<aeth>
flip214: Yes. Unironically. You might not know who I am. :-p
<phoe>
aeth: you're the author of trivial-left-pad
<phoe>
(ql:quickload :trivial-left-pad)
<aeth>
but also in the other sense, too
<flip214>
aeth: That wasn't meant to be ironically.... I was more thinking about some remark that the better wording would have been "Garden Lisp"
<aeth>
Although it's a side side project and is taking its time to complete, R7RS-large is also taking its time to complete, so I might still have one of the first R7RS-larges
<flip214>
which also would have a nice "saving the trees" name
karlosz has quit [Quit: karlosz]
<no-defun-allowed>
Whoooooooo are--no, we've already done that joke before. aeth has another <type of scam> Scheme implementation though.
<aeth>
It also has a minor advantage of being first in alphabetical lists.
<LdBeth>
Better starts off with a number
<aeth>
or _
<aeth>
___xXx_Scheme_69_xXx___
<aeth>
That was my second choice in names
<aeth>
but I settled for Airship
toorevitimirp has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
<beach>
aeth: So what you are predicting that the future of Common Lisp is mainly precisely the way YOU use it?
<aeth>
beach: Yes. I am predicting that Common Lisp will be used for a game engine and as a compiler target.
<aeth>
These are safer predictions.
ayuce has joined #lisp
<aeth>
Since I am doing projects along these lines. :-)
ayuce has quit [Client Quit]
<beach>
I sincerely hope you were joking with that future prediction.
<aeth>
beach: I did mean to delete mainly, but I forgot to delete it, and I guess you noticed.
<aeth>
s/mainly/"mainly"/
<aeth>
In fact, I wonder what word I accidentally deleted instead. :-)
toorevitimirp has quit [Remote host closed the connection]
<LdBeth>
grilly
<aeth>
beach: I'm sure you could say that a future is writing compilers, but that's not really a future, that's a present, too.
vliss has left #lisp ["Leaving"]
<aeth>
beach: What I was meaning to imply is that a currently underutilized feature is taking advantage of mature, fast CL compilers as a compilation target for other languages.
<aeth>
That is, there's potential, but "no one" is using things that take advantage of this at the moment.
constptr has quit [Quit: Connection closed for inactivity]
ayuce has joined #lisp
milanj has joined #lisp
dddddd has joined #lisp
scymtym has quit [Remote host closed the connection]
heisig has joined #lisp
sdumi has quit [Ping timeout: 272 seconds]
doomlist3 has quit [Ping timeout: 260 seconds]
bendersteed has quit [Read error: Connection reset by peer]
bendersteed has joined #lisp
cosimone has quit [Quit: Terminated!]
scymtym has joined #lisp
sdumi has joined #lisp
pjb has joined #lisp
Bike has joined #lisp
tutti has joined #lisp
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 246 seconds]
mmkarakaya has quit [Quit: Connection closed]
Lord_of_Life_ is now known as Lord_of_Life
orivej has quit [Ping timeout: 272 seconds]
pjb has quit [Ping timeout: 272 seconds]
sdumi has quit [Ping timeout: 246 seconds]
jonatack_ has joined #lisp
sdumi has joined #lisp
jonatack has quit [Ping timeout: 256 seconds]
akoana has quit [Quit: leaving]
tutti has quit [Ping timeout: 260 seconds]
jonatack_ has quit [Quit: jonatack_]
jonatack has joined #lisp
shifty has quit [Ping timeout: 272 seconds]
jonatack_ has joined #lisp
jonatack has quit [Ping timeout: 272 seconds]
jonatack_ has quit [Client Quit]
jonatack has joined #lisp
ayuce has quit [Remote host closed the connection]
bendersteed has quit [Read error: Connection reset by peer]
bendersteed has joined #lisp
monokrom has joined #lisp
gko has joined #lisp
ggole has joined #lisp
ljavorsk has quit [Ping timeout: 264 seconds]
heisig has quit [Ping timeout: 264 seconds]
rogersm has joined #lisp
patlv has joined #lisp
jruiz has joined #lisp
sunwukong has joined #lisp
marcoxa has joined #lisp
refpga has joined #lisp
dyelar has joined #lisp
terrorjack has joined #lisp
SGASAU has quit [Remote host closed the connection]
<dlowe>
is there a difference between "unable to find" and "unable to load"?
<dlowe>
more detail would have been helpful on that message :p
<jmercouris>
there is not
<jmercouris>
I wish there was
<jmercouris>
I'm just wondering if I have set the relative paths correctly
<jmercouris>
and what's even stranger it couldn't find the shared libraries when they were at their original paths in /opt/local/lib
<jmercouris>
which makes no sense to me...
<jmercouris>
DYLD_PRINT_LIBRARIES=1 doesn't help either because if I hit the lisp debugger, nothing is shown
<jmercouris>
Aha!
<jmercouris>
unless I press continue
<phoe>
jmercouris: hah
bitmapper has joined #lisp
<jmercouris>
more joy :-)
lavaflow has joined #lisp
<jmercouris>
literally the worst part of programming is distribution
stoneglass has joined #lisp
Josh_2 has quit [Ping timeout: 240 seconds]
ayuce has joined #lisp
stoneglass has quit [Client Quit]
stoneglass has joined #lisp
<p_l>
jmercouris: everything that works for opening a dylib by Objective-C program will work CFFI
<lukego>
So here's a n00by question. I'm making a little database like (DEFVENDOR ACME) and (DEFPRODUCT FOO :VENDOR ACME) and I'm wondering how to maintain the links e.g. from product object to vendor object. Mostly if I re-evaluate (DEFVENDOR ACME) later I'd like the existing FOO object to reference the new ACME object. So, like, should I use symbols to get the necessary indirection instead of objects directly?
<p_l>
I believe symbols would be the classic approach
<lukego>
Guess that I like the idea of using objects directly so that the inspector can see them and know what they are. If I lose that with symbols it seems like an annoying side-effect.
<phoe>
lukego: either use symbols, or create an update protocol for the objects that will be similar to the one used in classes.
<lukego>
If this were Smalltalk I might use #become: to rewrite the heap with all references to the old object referring to the new one, but I don't think SBCL indulges us in such tomfoolery?
<phoe>
Like, if the vendor named ACME already exists, you update its slots instead of creating a new instance.
<splittist>
update-products-for-redefined-vendor?
<Bike>
the swank inspector is extensible... i dunno if users are supposed to do that, though
<phoe>
splittist: Not really, more like reinitialize-instance.
<Bike>
lukego: you could use reinitialize-instance
<Bike>
edits the existing object to have the new properties, basically
* lukego
reads about reinitialize-instance
bendersteed has quit [Ping timeout: 246 seconds]
<Bike>
the system uses this internally for, for example, defgeneric and defclass redefinitions
<dlowe>
you could also define a class vendor-ref that contains a symbol slot, and the print-object method looks up the reference in the vendor table
<phoe>
lukego: also read about ENSURE-CLASS and ENSURE-CLASS-USING-CLASS, since these are used heavily in the MOP to implement the class and GF redefinition behaviour
<phoe>
and ENSURE-GENERIC-FUNCTION{,-USING-CLASS}
theseb has quit [Remote host closed the connection]
<Bike>
well, i dunno if all the details are relevant
<lukego>
MOP scares me a bit, feels like it might be simpler to just roll my own mechanism e.g. walking my whole little database and patching things myself
<Bike>
basically you lookup the name (acme in this case), if there's no binding you make a new object, if there's an existing binding you reinitialize the object
<phoe>
nothing really scary in that part of the MOP though
<Bike>
no mop required, the mop is just an example of using this
<lukego>
simpler in the sense of allowing me to maintain more blissful ignorance about CLOS :)
<phoe>
DEFCLASS FOO expands into ENSURE-CLASS (FIND-CLASS FOO)
<phoe>
and this calls ENSURE-CLASS-USING-CLASS with either NIL or a class object
<phoe>
if called with NIL, a new instance is created and set
<lukego>
first glance at reinitialize-object bothers me a bit because if I drop some slots from the new definition they will retain their old values, right?
<phoe>
if called with a class object, that class object is mutated
<phoe>
lukego: yes
<phoe>
calling REINITIALIZE-INSTANCE with no keyword arguments is a no-op in the general case
<Shinmera>
lukego: CLOS is the best part about CL!
<Bike>
you could call shared-initialize yourself, i guess.
<lukego>
thanks for all the pointers. I will meditate on this and then probably do something dumb like revert to plists :)
<p_l>
jmercouris: I spent way too much time fixing paths using otool for CCL :P
<phoe>
Bike: or have reinitialize-instance call shared-initialize for you
<Bike>
i mean, to control which slots are filled with initforms again.
<phoe>
oh, I see, yes
<phoe>
reinitialize-instance calls shared-initialize in a way that causes no slots to be re-initform'd
<jmercouris>
p_l: do you know of a tool that will do it recursively?
<jmercouris>
p_l: for example lib A depends on lib B and lib B on C etc
<jmercouris>
p_l: to just take them all and copy them into the Resources dir
<jmercouris>
and then update their paths of course
<p_l>
jmercouris: not really, closest I did my own scripts. Some libs have the paths done right by default, some had tools to help correct code for that
<jmercouris>
I'm literally seconds away from writing such a tool
<jmercouris>
OK, that's it I'm going to write a tool called recursive-lib-copy or something
<p_l>
jmercouris: generally read up on the path variables, as there are some that are explicitly there to support your cause
<jmercouris>
like DYLD_LIBRARY_PATH
<Shinmera>
DYLD_LIBRARY_PATH will not work on recent macOS.
<Shinmera>
At least probably not in the way you expect.
<jmercouris>
ah, so I must make the tool
louxiu has joined #lisp
louxiu has quit [Client Quit]
pjb has joined #lisp
doomlist3 has quit [Ping timeout: 260 seconds]
jfrancis_ has joined #lisp
jfrancis has quit [Ping timeout: 260 seconds]
madage has joined #lisp
rogersm has quit [Ping timeout: 240 seconds]
ayuce has quit [Read error: Connection reset by peer]
<lukego>
Hey maybe REINITIALIZE-INSTANCE "just works" if the defining macros always provide values for all the slots i.e. put default values into the arglist to the defining macro (where it is picked up every time) instead of the class definition (where REINITIALIZE-INSTANCE will retrain old values by default)
Josh_2 has joined #lisp
rippa has joined #lisp
sdumi has quit [Ping timeout: 264 seconds]
<phoe>
lukego: one second though, it doesn't need to "just work"
<phoe>
the slots that you don't provide retain their value.
<phoe>
REINITIALIZE-INSTANCE only mutates the slots which you tell it to mutate
<phoe>
unless you have some custom methods defined, that is
sdumi has joined #lisp
jprajzne has quit [Quit: Leaving.]
<lukego>
phoe: Right. But when I re-evaluate a defining macro I expect it to set/reset every slot in the object. (You wouldn't want DEFUN to retain an old docstring if you didn't supply a new one for example.) And maybe I can achieve that easily with REINITIALIZE-INSTANCE even though it's not the default behaviour
<phoe>
lukego: yes, correct, that's doable.
<Xach>
lukego: defun doesn't mutate a function, though, it just drops the old and adds a new one under the same name.
<lukego>
true.
<Xach>
defclass is hairier for sure
<Xach>
there's a whole book about it
<lukego>
Maybe I'll reread some PAIP for back-to-basic lists-and-sometimes-structs inspiration.
<Xach>
noooo! embrace the complexity!
<selwyn>
there's a book about defclass?
<Josh_2>
theres a book about OO in CL yes
<phoe>
selwyn: there's two
<Xach>
selwyn: how to implement it (and everything around it), yes
<phoe>
Sonja Keene's, for using it; AMOP, for implementing it
<Xach>
i was thinking of amop
<phoe>
I kinda wish both of them were reprinted
<Josh_2>
phoe: you can get copies of both
<Josh_2>
I have physical copies of both that I got from Amazon
<Xach>
i have seen them on used book sites for relatively cheap prices (in the USA)
<phoe>
Josh_2: yes, but only dead-tree. I'm hoping for modern epub versions that also have working code; Sonja's book contains multiprocessing code that no longer compiles
<phoe>
aah, the legendary third symbol that does not deserve its own spec page
<phoe>
along with VARIABLE
ArthurStrong has joined #lisp
marcoxa has quit [Quit: Time to go home.]
<lukego>
Maybe indirecting through symbols and then extending the inspector with niceties is a good idea
EvW has joined #lisp
rgherdt_ has joined #lisp
pfdietz has joined #lisp
Achylles has quit [Read error: Connection reset by peer]
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
ArthurStrong has quit [Quit: leaving]
<scymtym>
lukego: is that the SLIME inspector or something else?
Bourne has joined #lisp
<lukego>
SLIME inspector is what I'm thinking of but I guess it's a made-up problem at the moment because I'm not actually running my code yet. Just a feeling that with object references I'd get a better amount of pretty-printing happening in various places easily. but maybe it's a data model mess and I should just write pretty printing methods
kpoeck has joined #lisp
<lukego>
hard not to overthink these small things sometimes...
<beach>
lukego: scymtym rewrite Clouseau to be highly configurable.
<beach>
rewrote
<lukego>
I should check that out. I've recently been burned by GUI stuff, on a sojourn into Smalltalk land, so I'm a little more oriented towards text at the moment e.g. Emacs and org-mode to generate static html/pdf
<lukego>
but I guess inspection might be a good use case for using GUI tools since I don't really need to generate publishable artifacts from the inspector and it doesn't need to play with org-babel etc.
refpga has quit [Remote host closed the connection]
<lukego>
will check it out, thanks for the nudge
<beach>
Sure.
<scymtym>
lukego: thanks. indeed hard to tell what the best approach is. the CLIM-based inspector (Clouseau) that beach mentioned could have an advantage in case you have to throw in non-text representations as can be the case for graph-but-not-tree data
refpga has joined #lisp
jruiz has quit [Ping timeout: 256 seconds]
<lukego>
Something more dynamic could be nice. I'm rolling a little database of electronic components that I'm considering to use in my n00b hardware projects and a bunch of it is effectively scraped from sites like mouser.com. but what was I saying about over-thinking before getting started...
asarch has joined #lisp
<lukego>
I'm not automating too much though because the database is supposed to represent my notes from actually reading and thinking about these things. optimizing away the "comprehension" part of the process could be suboptimal :)
sdumi has quit [Ping timeout: 272 seconds]
sdumi has joined #lisp
gelatram has joined #lisp
anewuser has joined #lisp
rogersm has joined #lisp
Cymew has joined #lisp
ggole has quit [Quit: Leaving]
ahungry has quit [Remote host closed the connection]
<phoe>
why am I mad at lisp-koans, abbreviated in two lines
<phoe>
; returns sign x
<phoe>
(defun sign-of (x) (if (< x 0) (return-from sign-of -1)) (if (eq x 0) (return-from sign-of 0)) 1)
<phoe>
there are at least three things that are wrong with this code, both style- and correctness-wise
scymtym has quit [Ping timeout: 244 seconds]
<jackdaniel>
let me try!
<phoe>
lo and behold, this is the flagship Google-branded beginner resource for people who would like to start learning Lisp
<_death>
why am I mad at series, in two forms.. (defun scan-lines (file) (declare (optimizable-series-function)) (scan-file file #'read-line)) (collect (scan-lines "/etc/passwd"))
<_death>
(I did implement a fix, but the code is likely suboptimal)
<phoe>
_death: uhhh, what did it do?
<_death>
what did what do
<phoe>
this SERIES stuff
<phoe>
I mean, I know the package
<_death>
try it?
* phoe
tries
<phoe>
I got a list of all entries from my passwd file, line by line
<_death>
you also need (series::install) to use series's defun
<phoe>
ooh
<phoe>
...it worked better with my previous defun
<_death>
phoe: if you just do (scan-lines ...) without the collect it will also work (return a stream)
<phoe>
I see
<_death>
see, series defines both a function and an "optimizer" that contains code fragments
<_death>
(collect ...) will macroexpand into a tidy loop, using the optimizer
<_death>
the code fragment has a slot for wrappers, like (with-open-file (...) ...) which scan-file defines
<_death>
there's also some argument name renaming going on, but the new names are not substituted in the wrappers :/
<_death>
otherwise, series is great.. I also played with arrows/nest + series.. for example defining a TSEN operator (defmacro tsen (&body things) `(uiop:nest ,@(reverse things))) is useful with simple series calls: (tsen (scan-fn ...) (map-fn ...) (choose-if ...) (collect))
<_death>
the TSEN operator is also named cl-arrows:->> .. now, more complicated series calls may have arguments both on the left and right.. so you'd need to use the diamond arrow cl-arrows:-<>
<pjb>
phoe: you can also use: (first (com.informatimago.common-lisp.unix.passwd:read-passwd)) #| --> #S(user :login "nobody" :passwd "*" :uid -2 :gid -2 :gecos ("Unprivileged User") :home "/var/empty" :shell "/usr/bin/false") |#
<phoe>
pjb: TIL, nice.
<_death>
then, you see that you could define small series functions that have conceptual value, and the arrows may get in the way of re-factoring.. but I suppose with series or clojure's lazy sequences they make a little more sense (but not much...)
<pjb>
_death: you should post a bug report on com.informatimago.common-lisp.unix.passwd since it uses a defstruct, you cannot add :after methods to (setf user-uid) to walk the file system…
Misha_B has joined #lisp
<dlowe>
one of my "if I ever get around to" projects is to make a sbcl-native version of series
<dlowe>
so it doesn't do the code-walker hackery of the library
<jackdaniel>
I like series in principle
<jackdaniel>
but using them in practice is hard
<jackdaniel>
not because of bugs or something in this spirit, the thing is that series objects are hardly composable with the rest of a language, so you either make "everything-series", or you have a hard time with marshalling/demarshalling objects between representations
<_death>
pjb: I'm not sure setf is the right place for such functionality..
<dlowe>
jackdaniel: right. an implementation-native version would fix this
<pjb>
_death: it depends on the level of the object you are setting.
<dlowe>
the other gotcha in series is that it's easy to break the efficient path
<jackdaniel>
dlowe: not really, it is about the fact that common lisp standard does not take into account series, so basically nothing works on them
mangul has joined #lisp
<jackdaniel>
(at least in my use case, of course it may fix your problems with the library)
<_death>
I think Joe Marshall wrote some interesting "experience reports" about series
choegusung has joined #lisp
<dlowe>
jackdaniel: just treat a series like a sequence
<Bike>
can't a series have no finite length?
<jackdaniel>
they can
<dlowe>
that's correct.
<pjb>
_death: see for example (setf (com.informatimago.common-lisp.cesarum.file:text-file-contents "/tmp/foo.txt") "Hello world") or (push :hello (com.informatimago.common-lisp.cesarum.file:sexp-file-contents "/tmp/counter.sexp"))
<Bike>
because if so most of the sequence functions are not going to work
<jackdaniel>
dlowe: series are not sequences, so you can't treat them as such
<jackdaniel>
(at least it is hard to imagine for me how that could work)
<dlowe>
itym most of the sequence functions will infinitely loop
<Bike>
i mean, not even in a good way
<dlowe>
like which?
<Bike>
like MAP might freeze on calculating a length before actually mapping anything
shangul has quit [Ping timeout: 256 seconds]
<dlowe>
a series-aware map wouldn't try to calculate a length
<Bike>
what if it's mapping into a vector? does map now have to just collect elements into a list and then make a vector after the fact?
<dlowe>
or use an adjustable vector
<_death>
in fact series is usually about transforming the code into a tidy loop
<pjb>
cl:map can expect a proper-list.
<pjb>
So it can call cl:length
<_death>
so what would be the point of using CL sequence functions?
<Bike>
adjustable vector still means a lot more consing
<dlowe>
you didn't claim that it would be inefficient, you claimed that it wouldn't "work"
<Bike>
especially since you still have to do a full copy if the result sequence type isn't adjustable
<pjb>
Bike: adjustability is not a type.
<dlowe>
by which I thought you meant that it couldn't fulfill its spec
<phoe>
dlowe: CL sequences need to be finite, even extensible ones. Hence an infinite series cannot be a sequence.
<Bike>
i meant that as these functions are written now they can't handle infinite sequences.
<Bike>
i don't know off the top of my head if they all work with infinite sequences, but i have my doubts, because the possibility clearly wasn't considered
<phoe>
I've been munching on the extensible sequence protocol for a while
<dlowe>
phoe: "an ordered collection of elements" doesn't specify finite
<phoe>
dlowe: CL:LENGTH must return a non-negative integer
<Bike>
well, okay, so obviously reverse and nreverse don't
<dlowe>
phoe: ok, got me there
<phoe>
you could hack the system and try to specify most-positive-bignum there, except that would not be correct
<Bike>
it's possible you could respecify the language to allow infinite sequences, but it's not anything obvious to do
<phoe>
like, it would be correct-like-in-C correct, but nothing that would suit Lisp
<Bike>
i mean, we HAVE infinite sequences, with circular lists, and they already break most things
<dlowe>
phoe: that didn't even occur to me
<Bike>
i read a language spec once where if you mapped on circular lists you had to calculate the least common multiple of all the cycle lengths and return a circular list with that cycle
<Bike>
pretty good stuff
<Bike>
hm, and there's some weird subtle stuff, like if you did SUBSTITUTE on a lazy sequence you could return another lazy sequence, but then does it count as still a "traversal" for the purposes of 3.6
sauvin has quit [Read error: Connection reset by peer]
<jasom>
I was trying to make a wrapper for each implementation's errno, but ran into a small hiccup: allegro-cl does not provide direct access to errno from lisp but rather you can declare a function to return the errno as a second value. When you request that it return errno as a second value, it seems to clear errno before calling the function.
<phoe>
jasom: what's the procedure of doing that?
<jasom>
So it might make more sense to extend cffi:defcfun to provide errno information mirroring allegro's implementation; thoughts?
<jasom>
phoe: if you do a def-foreign-call with :error-value :errno then it makes a function that returns (values result errno)
<phoe>
jasom: can you give me a minimal example of that that will work on Linux and set errno to some nonzero value?
<jasom>
under-the-hood doing :error-value :errno just seeps to set ep-flag-get-errno in the vector describing the foreign function, and the work is done in system::ff-funcall
<phoe>
jasom: I don't think one can easily hack around that by macroexpanding def-foreign-call.
<phoe>
Sadly.
<jasom>
phoe: I agree
<jasom>
I already looked into it a bit
<phoe>
other than defining a wrapper around CFFI's defcfun that, on allegro, always fetches that secondary value and sets it to some global variable.
<phoe>
Hacky as holy hell but it'll work as long as you have a non-multithreaded environment
<phoe>
for multiple threads, you'll want thread-local dynabindings
amerlyq has joined #lisp
<jasom>
phoe: see also my suggestion of changing defcfun to have an option to return errno in addition to the primary value
<phoe>
ooh - yes, that would be backwards compatible in total, but perhaps a bit overkill
<phoe>
perhaps when the defcfun has some sort of :errno t passed to it?
<jasom>
then for e.g. sbcl it's just (lambda (&rest args) (values (funcall wrapped args) (sb-alian:errno))
<jasom>
phoe: right, as an option
<phoe>
yes, correct
<phoe>
jasom: I'd dig that, that seems good enough
doomlist3 has quit [Quit: not part but quit]
<jasom>
jackdaniel: can you confirm that there's no way to get errno in ecl with the interpreter?
<jasom>
phoe: the other option is to just implement an errno wrapper for each existing libc; e.g. with glibc newer than 6-ish there is __errno_location() that returns the address of errno for the current thread.
<pjb>
jasom: well, I don't care about wrapping errno. I just process errno or anything else is specified after each call to a C function, and signal a LISP condition!
<jasom>
pjb: but you need to *get* errno in order to do that.
<pjb>
Yes.
<jasom>
jackdaniel: (c-inline "{ @(return) = errno; }") works when compiled, but obviously not interpreted
<jasom>
pjb: I can get errno on *nix for every lisp I've tried sofar except allegro (and ecl without the compiler). CLISP has errno in the POSIX package, which makes me less-than-hopefull it will work on windows, Lispworks errno-value is specifically *not* supported on windows per the LW documentation
<flip214>
extern int *__errno_location (void) __THROW __attribute_const__;
<flip214>
# define errno (*__errno_location ())
<jasom>
flip214: I already mentioned that will work for any version of glibc made in a while
<flip214>
jasom: oh, sorry. didn't read the backlog.
<jasom>
flip214: NP, all solutions welcome; particularly if you know the *BSD and NT versions of that :)
<pjb>
obviously, __errno_location is implementation and platform specific.
<flip214>
no idea about the BSDs -- especially, which one? NetBSD? FreeBSD? BSD4.4?
<jasom>
flip214: it's unclear to me that GetLastError will be the same as errno for the C standard lib
<Bike>
freebsd has __error(), apparently
<pjb>
flip214: if allegro doesn't provide an access to errno, you would have to use a C function stub. int get_errno(){return errno;} and cffi it.
<phoe>
pjb: we've discussed that.
<pjb>
also, report a bug to Franz…
<Bike>
and also darwin, so maybe it's some deep bsd thing
<phoe>
it requires access to a C compiler on the target machine.
shifty has joined #lisp
<pjb>
phoe: by definition. An alternative could be to parse the C header and implement a C compiler in lisp…
<jasom>
pjb: Allegro provides access to errno, just not in a way that is useful for CFFI.
<flip214>
a "portable" solution might be to disassemble perror() and find out what that reads ;)
<jasom>
pjb: you can request that errno be returned as a second value for a function, but it clears errno before calling the function, so I can't just call something that doesn't set errno (e.g. rand()) and get the errno from that.
efm has quit [Read error: Connection reset by peer]
<jasom>
I'm considering extending CFFI to offer the secondary-value solution because that will work on all implementations that provide any access to errno, and you usually want it as part of calling a C function anyways
<phoe>
pjb: except that's not a viable alternative, since it'd be shooting a fly with a cannon.
<pjb>
phoe: errno is not a fly.
<pjb>
phoe: consider threads!
<pjb>
it's a shitty C API.
<phoe>
still, implementing a C compiler in Lisp only to work around a shitty C API is kind of much.
<jasom>
particularly since the definition of errno is not required to be portable across C compiler implementations; it's permissible for the libc and compiler to be tightly coupled
ljavorsk has joined #lisp
amerlyq has quit [Quit: amerlyq]
not_a_seagull has joined #lisp
<not_a_seagull>
How do I "load" a file in the same directory as the file I'm currently in? (like NodeJS's require statement)
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pjb>
so it looks like disassembling a C function that gets at errno could be the best bet…
<pjb>
not_a_seagull: but it's more complex if you want to compile the file you're currently in, because then you have one more directory: where the compiled fasl file is.
<jasom>
looks like FreeBSD 5.3 had __error but the 4.4BSD errno was still not thread-safe
rpg has joined #lisp
kslt1 has joined #lisp
<jasom>
And NetBSDF-5.0.2 uses __errno()
not_a_seagull has quit [Quit: leaving]
refpga has quit [Read error: Connection reset by peer]
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
jfrancis_ has quit [Remote host closed the connection]
jfrancis has joined #lisp
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
<jasom>
not_a_seagull left, but usually if you want to do that you're better off using the asdf system path
SGASAU has quit [Remote host closed the connection]
Oladon has quit [Quit: Leaving.]
SGASAU has joined #lisp
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
theBlackDragon has quit [Ping timeout: 256 seconds]
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
theBlackDragon has joined #lisp
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
cosimone has joined #lisp
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
gelatram has quit [Remote host closed the connection]
Jesin has quit [Quit: Leaving]
choegusung has quit [Quit: leaving]
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
efm has joined #lisp
refpga has quit [Read error: Connection reset by peer]
ayuce has quit [Remote host closed the connection]
refpga has joined #lisp
Jesin has joined #lisp
refpga has quit [Read error: Connection reset by peer]
SGASAU has quit [Remote host closed the connection]
refpga has joined #lisp
narimiran has quit [Ping timeout: 272 seconds]
SGASAU has joined #lisp
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
SGASAU has quit [Remote host closed the connection]
SGASAU has joined #lisp
Jesin has quit [Quit: Leaving]
Jesin has joined #lisp
efm has quit [Excess Flood]
Inline has joined #lisp
efm has joined #lisp
scymtym has joined #lisp
karlosz has quit [Quit: karlosz]
<White_Flame>
interesting little goings on: I have nested dynamic bindings of a list, where the inner binding pushnew's values to the head. Now I'm in a situation where I want to compare the value I'm "popping" to the outer value, for some cleanup work, but the outer value really isn't visible.
<Josh_2>
What is the purpose of &allow-other-keys
jruiz has joined #lisp
<White_Flame>
Josh_2: passing remaining params via apply to another function that will handle more params than you do
<White_Flame>
regarding the dynamic bindings, is there a standard way of peeking up the chain? or is the most sane way to do it to allocate yet another special var to hold a copy of the parent binding?
<phoe>
White_Flame: the latter
<jasom>
White_Flame: most sane way is to allocate yet another special var to hold a copy of the parent binding
<phoe>
you can't access shadowed dynamic bindings in a standard way
<White_Flame>
yeah, thought so. A little annoying,b ut doable
karlosz has joined #lisp
<White_Flame>
at least it's all wrapped up in a scope macro for the most part
jprajzne has joined #lisp
<SAL9000>
White_Flame: you could make the special var (or extra special var) a stack
<Misha_B>
what's the premier lisp web framework/toolkit
<SAL9000>
(let ((*special* (cons new *special*))) ...)
<phoe>
should be done and hopefully merged by the end of the week
<White_Flame>
maybe not deployed, but code from the actual real official google account
<phoe>
it's not really google code; just published under google github
<phoe>
;; or so I've heard in PR comments
<White_Flame>
leave it up unchanged as public shame upon their name
<ralt>
if ironclad maintainer is around there, I'd love a quick look. I'm using a workaround (creating a new prng every time I'm requesting random bytes), but it's not great. https://github.com/sharplispers/ironclad/pull/29
<aeth>
what's the correct way to do a signum without using SIGNUM? Well, besides testing ZEROP first
<White_Flame>
or simply add comments as to how terrible & wrong it all is
vladomiro has joined #lisp
<aeth>
I mean, yes, the style is awful, but is the algorithm?
<markasoftware>
plusp zerop minusp?
<aeth>
ah
<White_Flame>
aeth: their specific algorithm will not work for floats
<White_Flame>
since it tests EQ 0
<aeth>
I guess specifically this: (cond ((zerop x) 0) ((plusp) 1) (t -1)) although idk how SIGNUM handles nan/inf/etc. that you can get if you disable float traps
<aeth>
s/plusp/plusp x/
<aeth>
White_Flame: oh EQ
<aeth>
White_Flame: I guess that's why you always have to write idiomatic code... because otherwise you can hide things like that
<markasoftware>
phoe: do you happen to moderate a certain highly entertaining lisp forum?
jruiz has quit [Ping timeout: 240 seconds]
<pjb>
aeth: I would use (cond ((minusp x) -1) ((plusp x) +1) (t 0)), but zerop should cover all the zero kinds…
<phoe>
markasoftware: uhhh which forum
<markasoftware>
r/lispmemes
<pjb>
Using signum would avoid thinking about which tests to use… (case (signum x) (-1 …) (0 …) (+1 …))
random-nick has quit [Ping timeout: 246 seconds]
<phoe>
yes
<aeth>
someone needs to make CLaaS, Common Lisp as a Service. Then the way to implement SIGNUM from scratch would be to query CLaaS and RPC their SIGNUM
Misha_B has joined #lisp
<White_Flame>
both fixnums and all ieee floats could be tested for +1/-1 by looking at their raw high bit
<White_Flame>
I guess bignums are more ad-hoc
<White_Flame>
(of course, that would have to come after the zero test)
<White_Flame>
(and assuming low tag bits instead of high ones)
rgherdt has quit [Ping timeout: 240 seconds]
rgherdt_ has quit [Ping timeout: 256 seconds]
rpg has joined #lisp
<LdBeth>
What’s typical bignum representation in CL? A linked chain of arraies of signed numbers?
ljavorsk has quit [Ping timeout: 240 seconds]
<White_Flame>
I think most bignum representations are arrays of machine-sized unsigned words, with a separate singular sign
<White_Flame>
(regardless of language)
<White_Flame>
*machine-word-sized (as machine-sized would only allow you to store exactly 1, and nothing else :-P)
asarch has quit [Quit: Leaving]
nchambers has quit [Read error: Connection reset by peer]
CrazyPython has quit [Read error: Connection reset by peer]
buffergn0me has quit [Ping timeout: 240 seconds]
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
housel has quit [Read error: Connection reset by peer]
<not_a_seagull>
I have a bash script that runs `sbcl --no-interactive --load $1` and I use this as the FCGI binary
<jasom>
okay, you'l want an if you mean --non-interactive, that will still have a repl; does the file you are loading enter an infinite loop at the end? If not, then you would expect to see this error
<not_a_seagull>
Yeah I think that's what's happening
<not_a_seagull>
Has anyone here successfully used cl-fcgi with lighttpd?
<jasom>
not_a_seagull: a *long* time ago I used some fcgi library with lighttpd
SGASAU has quit [Remote host closed the connection]
SGASAU has joined #lisp
<jasom>
derp, I misremembered fastcgi; stdin is set to a socket with fastcgi
<not_a_seagull>
Do I need to start any fcgi servers prior?
<jasom>
I *thought* with lighttpd that if there is no bin-path, it expects the fastcgi server to be already running
<not_a_seagull>
Mmm
<not_a_seagull>
How should I get around that?
<jasom>
so you need the bin-path to be set to your index.cl
<jasom>
or use spawn-fcgi, which I think ships with lighttpd
<jasom>
spawn-fcgi -s /path/to/socket program
<not_a_seagull>
Should I put that last command in my bash file?
<jasom>
However you want to run it. There needs to be a fcgi server running. cl-fcgi expects to be spawned with the socket already existing. You can use bin-path as shown in https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModFastCGI to have lighttpd run it automatically *or* you can do what it says under "External Spawning" on that same page
jonatack has quit [Ping timeout: 246 seconds]
<jasom>
setting bin-path is probably easier
<not_a_seagull>
So would I just set the bin-path to "/usr/bin/spawn-fcgi"?
<jasom>
no
<jasom>
if you use bin-path you *don't* use spawn-fcgi
jonatack has joined #lisp
<jasom>
either lighttpd or spawn-fcgi should start your program. Right now it looks like you are doing neither?
<jasom>
bin-path in your lighttpd configuration will tell lighttpd to start it,
arpunk has quit [Remote host closed the connection]
<not_a_seagull>
I'm sorry, I feel like I'm having trouble understanding; I tend to be dense. So if I'm using bin-path, what should I put in it?
<jasom>
the path to index.cl I would imagine
<jasom>
or the bash script wrapping it if you are using a bash wrapper