<Josh_2>
Well what I'm constructing comes from postgres database which comes as a list, and then I convert to an instance of my object, but now I'm thinking there is no point converting it other than when printing the contents for clarity
<Josh_2>
seems needless to convert from list to object, then take that object and create a list of its properties to dynamically generate some html
Essadon has quit [Quit: Qutting]
<didi>
Josh_2: As a counter point, I'm all for implementation hiding.
ealfonso has quit [Ping timeout: 252 seconds]
<Josh_2>
didi: what do you mean?
karlosz has quit [Quit: karlosz]
ealfonso has joined #lisp
<didi>
Josh_2: I like to separate the implementation detail of an object --list, vector, tree, etc-- from the functions that manipulate them. Even if the functions are a thin layer on top of standard functions.
robdog has quit [Ping timeout: 252 seconds]
<Josh_2>
So like generic functions?
<Xach>
Josh_2: not always.
<didi>
Josh_2: It can be. It doesn't have to. So you can define a struct of :type list on top of something that is implemented as list, for example.
<Xach>
Josh_2: more like, a function to get the name of a thing could be called NAME, and the object might be a vector with the first index being the name, or it might be a plist with a :name key, or it might be a hash table, or or or.
<Xach>
what it "really" is does not matter and is free to change if you don't poke it too directly in too many places
<Josh_2>
So the function would "know" where to look for the "name" in each of those instances?
<Josh_2>
so it would 'know' in an array, a plist or a hashtable etc
<Xach>
that is one reason why i don't like the style of naming that uses "NAME-OF" or "SOUP-NAME" (for soup objects)
<Josh_2>
hmmmmmmm
<Josh_2>
that's exactly what I've done Q_Q
<Xach>
what have you done!!?
<Josh_2>
I have a structure called sql-user and have called my functions that relate to it, things like sql-user-obj-to-html or sql-user-properties or get-sql-user-from-sql Q_Q
<Xach>
well, you are free to do that! but i don't like it for the reasons above
<Josh_2>
I'd like to have functions that handled a list or a object
ym555_ has joined #lisp
<Josh_2>
oof now I'm frustrated *sigh*
<Josh_2>
I'm not explicitely using clos, just defstructure
<Xach>
structures make it really easy to have functions named <thing>-<slot>
<Xach>
but i am not a huge fan of that style most of the time
<Josh_2>
what about classes?
<Josh_2>
I have been thinking this whole time "What do I do if I add properties to my structure" because I would have to go around and modify a lot of my functions to now work with the new property
<Josh_2>
I'm currently just prototyping
<Xach>
well, there are ways to make life easier in situations where the properties change, but they depend on the specific needs
ym555 has quit [Ping timeout: 255 seconds]
<Josh_2>
Like what?
<Xach>
like if you are mapping over properties without looking in detail at each one, but just as name/value pairs, you could isolate that to a function that returns the properties given an object, and work against that function.
<Xach>
but it depends on what you need to know about and in how much detail
* Xach
has to go back to cutting and welding angle iron - good luck!!
<Josh_2>
Thanks for the help :)
charh has joined #lisp
robdog has joined #lisp
<Josh_2>
Is there a way to setf with funcall?
<no-defun-allowed>
I think (setf foo) is a valid function name.
<Josh_2>
like (setf (funcall accessor object) to-this)
<Bike>
it's just (funcall writer property instance)
<Josh_2>
o
<Josh_2>
hmm
<Josh_2>
so I have to make the writer functions that perform the setf?
<Bike>
yeah. there's a reader and a writer, and they're separate functions
<Josh_2>
hmm alrighty
Autolycus has quit [Quit: Connection closed for inactivity]
robdog has joined #lisp
Oladon has quit [Quit: Leaving.]
themsay has quit [Ping timeout: 240 seconds]
themsay has joined #lisp
robdog_ has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
robdog_ has quit [Ping timeout: 252 seconds]
robdog has quit [Ping timeout: 255 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
karlosz has joined #lisp
wanz has joined #lisp
robdog_ has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
robdog_ has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
dale has quit [Quit: dale]
wanz has quit [Quit: wanz]
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
<pjb>
Josh_2: the question is why you keep working with structures when you need that level of introspection?
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
wanz has joined #lisp
karlosz has quit [Quit: karlosz]
spoeplau has joined #lisp
<spoeplau>
Grue`: It finally dawned on me why remove-duplicates is fast with your particular predicate: The algorithm is O(N^2) for lists of length N in general, but when you test for equality mod K on (alexandria:iota N), you always find a duplicate within the next K elements. So in that case the complexity is O(K*N), which should explain why you see linear behavior when keeping K constant...
Oladon has joined #lisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
robdog has joined #lisp
orivej has joined #lisp
flazh has quit [Ping timeout: 255 seconds]
wanz has quit [Quit: wanz]
robdog has quit [Ping timeout: 252 seconds]
wigust has joined #lisp
wanz has joined #lisp
robdog has joined #lisp
wigust- has quit [Ping timeout: 244 seconds]
abhixec has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
jkordani has quit [Read error: Connection reset by peer]
robdog has quit [Ping timeout: 252 seconds]
nalkri has joined #lisp
marvin2 has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
meiji11 has quit [Remote host closed the connection]
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
dale has joined #lisp
josemanuel has quit [Quit: leaving]
robdog has quit [Ping timeout: 252 seconds]
<beach>
Good morning everyone!
<Jachy>
Morning beach
Bike has quit [Ping timeout: 250 seconds]
ggole has joined #lisp
karlosz has joined #lisp
robdog has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
q9929t has joined #lisp
q9929t has quit [Client Quit]
rippa has joined #lisp
robdog has joined #lisp
la_mettrie has joined #lisp
<la_mettrie>
trying to test an example code on SLIME, sbcl. I get this message: /usr/bin/emacs24: /usr/local/bin/sbcl: No such file or directory <line change> Process inferior-lisp exited abnormally with code 127
<la_mettrie>
i wonder where i can change directories
<beach>
la_mettrie: Check the value of the Emacs Lisp variable inferior-lisp-program.
<beach>
It should be assigned to in your Emacs startup file.
robdog has quit [Ping timeout: 252 seconds]
ggole has quit [Ping timeout: 240 seconds]
ggole has joined #lisp
robdog has joined #lisp
<djeis[m]>
With bordeaux-threads does anyone know if there are any defined semantics for calling condition-notify more than once without releasing the lock?
robdog has quit [Ping timeout: 252 seconds]
<djeis[m]>
I ask because I'm hoping to be able to wake "at least n threads" while avoiding the possibility of waking every thread n times.
Oladon has quit [Quit: Leaving.]
robdog has joined #lisp
themsay has quit [Read error: Connection reset by peer]
themsay has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
ym555_ has quit [Quit: leaving...]
flazh has joined #lisp
robdog has joined #lisp
CCDelivery has quit [Remote host closed the connection]
robdog has quit [Ping timeout: 252 seconds]
* beach
suspects that la_mettrie was not satisfied with the answer.
<la_mettrie>
no, i am. thanks
<la_mettrie>
i was just trying example code. now it runs at some level but it does not give output. maybe i will try another
<fiddlerwoaroof>
la_mettrie: I'm not sure how you've tried to setup slime, but the easiest way I've found is to use quicklisp-slime-helper
<fiddlerwoaroof>
(ql:quickload :quicklisp-slime-helper) and follow the instructions
nanoz has joined #lisp
<fiddlerwoaroof>
If anyone uses montezuma to index text, do you happen to know how to search for a field value that contains colons?
<fiddlerwoaroof>
I'm reading the source-code right now, but queries like field:"foo:bar:baz" don't seem to work very well
robdog has joined #lisp
* edgar-rft
knows montezuma as a synonym for diarrhea
verisimilitude has quit [Remote host closed the connection]
<jackdaniel>
Xach: it seems that quicklisp stopped to pick up commit from clx repository (we had o hard-reset it around december, so that is probably a cause)
<slyrus__>
jackdaniel: he may be asleep, but you might try #quicklisp too
<jackdaniel>
minion: memo for Xach: it seems that quicklisp stopped to pick up commit from clx repository (we had o hard-reset it around december, so that is probably a cause)
<minion>
Remembered. I'll tell Xach when he/she/it next speaks.
parjanya has quit [Remote host closed the connection]
<Grue`>
idk if it's faster
<edgar-rft>
and using READ on unknown data opens the door for viruses
<Grue`>
besides, read is almost as bad as eval :)
<Grue`>
("almost" because it's possible to not make it execute random code with some tweaking of global variables)
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
<refpga>
Grue`: Thanks, I'll read up on security issues (idk if parse-integer internally uses read). But using read does seem to be faster for my quicksort function. Using your implementation took 0.005s, with read it took 0.001s. Thanks anyway.
<Grue`>
not sure why quicksort would need to read from string into a linked list, but ok...
<refpga>
I'm new to CL. I was testing building executable using ros, had to put in something there. :D
ebrasca has joined #lisp
random-nick has joined #lisp
<Grue`>
well I'm just saying that your quicksort is probably slowsort so you shouldn't be caring about its performance
<refpga>
Okay.
<no-defun-allowed>
i think insert sort is faster for linked lists?
<MichaelRaskin>
For linked list I would take merge sort
robdog has joined #lisp
quazimodo has joined #lisp
quazimod1 has joined #lisp
quazimod2 has joined #lisp
quazimod2 has quit [Client Quit]
quazimodo has quit [Client Quit]
quazimod1 has quit [Client Quit]
varjag has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
varjag has quit [Ping timeout: 252 seconds]
<beach>
Yes, MichaelRaskin is right, merge sort is the best when no additional storage is required, which is true for lists.
<beach>
no-defun-allowed: Insertion sort is O(n²).
<no-defun-allowed>
Gotcha, thanks.
robdog has quit [Ping timeout: 252 seconds]
heisig has joined #lisp
elazul has joined #lisp
robdog has joined #lisp
ravenousmoose has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
robdog_ has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
robdog_ has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
heisig has quit [Remote host closed the connection]
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
igemnace has quit [Quit: WeeChat 2.4]
<makomo>
MichaelRaskin: i came up with another version of WITH-OVERLOD, without having to write a custom WALKER-METAENV :D https://plaster.tymoon.eu/view/1240#1240
robdog has joined #lisp
<makomo>
it's the idea of replacing macro operators with a specially marked QUOTE form and then undoing that later on (since then no more macro expansions will be performed)
<makomo>
i had to extract the MACROP logic from AL though, but as we said, that's something that should be done anyway
<makomo>
as you can see, i just took METAENV-MACROEXPAND-1 and replaced parts of it with t and nil
space_otter has quit [Remote host closed the connection]
<makomo>
it could surely be made prettier, but i didn't bother yet
robdog_ has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
orivej has joined #lisp
<makomo>
the only remaining problem is backquote
<MichaelRaskin>
makomo: I think you have some repeating cases
<MichaelRaskin>
As macrop doesn't need the weird esoteric decisions for fallback vs. reconstructed, the decision logic can be made simpler
<makomo>
yeah, that's what i assumed
<MichaelRaskin>
You sometimes even dropped the conditions, but not the cases that became redundant
robdog_ has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
lumm has joined #lisp
<makomo>
yup, it was just a quick hack :-)
<MichaelRaskin>
I would gensym a marker with the name part with-overload-marker just to make intent clear
<makomo>
ah you mean, '#:with-overload-marker is a bit cryptic?
<MichaelRaskin>
Well, if you want guaranteed uniqueness, gensym is the function that has some guarantees
<makomo>
right, but do i really need guaranteed uniqueness?
<makomo>
hmm, maybe i do. i haven't thought about nested usages and weird macroexpand tricks one could do
lumm has quit [Client Quit]
<MichaelRaskin>
Do you want someone defining a macro with the name you use as a marker?
<makomo>
but can they do that, if the symbol isn't interned anywhere?
<MichaelRaskin>
That sounds like a challenge
<makomo>
actually, since i don't even expand any macros, no user code can be run while code walking
<makomo>
so i would think they couldn't even find my marker :-D
<makomo>
haha
<MichaelRaskin>
Hm, good question if that symbol can be stolen in some other way
<makomo>
yeah, i can't think of anything
<MichaelRaskin>
I can
<MichaelRaskin>
Although that's a bit of enemy action
<makomo>
i'mm all ears :D
<makomo>
i'm*
spoeplau has quit [Ping timeout: 245 seconds]
<MichaelRaskin>
Although maybe it won't work
<MichaelRaskin>
The idea is to call your code with a malicious enough metaenv
<MichaelRaskin>
(subclassed, of course)
<makomo>
ah lol
<MichaelRaskin>
Also, I am not even sure what are the guarantees about #: symbols
lumm has joined #lisp
<makomo>
but the way with-overload-3 is written, it doesn't allow any AL environments
<MichaelRaskin>
Hm maybe
robdog has quit [Ping timeout: 252 seconds]
<makomo>
even in with-overload-2, where i explicitly passed my no-macro-expansion-walker-metaenv, there's still no way for the user to provide his own metaenv
<makomo>
the user of the macro doesn't really need to know that we're using AL
<makomo>
MichaelRaskin: good point about #:, maybe some trouble could be made if you throw compilation/FASLs/etc. into the mix? i don't know
<MichaelRaskin>
Maybe what you wrote is correct, but gensym just feels safer
<makomo>
then again, maybe not, because i don't know how otherwise any gensym-using macro would work
<makomo>
MichaelRaskin: yeah, i guess i agree
<MichaelRaskin>
Well, with gensym each invocation is a fresh one
<MichaelRaskin>
With #: the same symbol is probably cached in the code
robdog has joined #lisp
<makomo>
right, but i was thinking of what happens when a FASL is produced (the FASL contains expansions of gensym-using macros). the symbol has to be stored somehow so that when it's loaded it doesn't conflict with anything that's already in the image
<MichaelRaskin>
Well, if gensym is guaranteed to create a new symbol object, and symbols are always compared via being the same object in the sense of pointer equality, then gensym is safe
<makomo>
right
<makomo>
ah, but also, WITH-OVERLOAD-3 never includes the marker within its expansion, it just uses it internally to produce the expansion
robdog has quit [Ping timeout: 252 seconds]
<MichaelRaskin>
Yes, so there is a chance it is safe…
<MichaelRaskin>
Unless #: symbols are just reused in some implementation
<makomo>
yeah, people can't just macroexpand with-overload-3 and get the symbol
<makomo>
what do you mean by reused?
<MichaelRaskin>
Can under some weird conditions (eq '#:a '#:a) be true?
<makomo>
ah. hmm, i hope not? i think of #: as being equivalent to a reader-level GENSYM call
<makomo>
i.e. #.(gensym (string <sym>)) i guess
<no-defun-allowed>
i don't think #:foo interns foo, otherwise it'd be pointless
<no-defun-allowed>
rather, it'd probably just invoke the "symbol" reader, get a symbol name and make a symbol with that name with package NIL
<MichaelRaskin>
Ah indeed it should be unique
<makomo>
true, so it should really be #.(gensym <sym-name>) or rather #.(make-symbol <sym-name>)
<makomo>
i also thought of another code walking macro. it would provide convenient syntax for accessing symbols whose package is not present yet
<makomo>
the usual situation that happens within ASDF's OPs where you have to use SYMBOL-CALL, etc.
elazul has quit [Ping timeout: 268 seconds]
<MichaelRaskin>
(Considering refusing to relicense AL for ASDF because using it in ASDF would be madness)
robdog has joined #lisp
<makomo>
LOL
<makomo>
hm right, there would be kind of a bootstrapping problem there. i wouldn't be able to access AL's package either
<makomo>
i mean i would, it just wouldn't exist at the time the defsystem form is read
<MichaelRaskin>
Well, AL is small, and can be used without dependencies, so you could in principle just force-load it in some way
<makomo>
hm, maybe if the project had a separate system that just served to load AL
<makomo>
and then the main system would actually load the project
<makomo>
but you couldn't specify it as a dependency within ASDF, because then the main system would get read first
<makomo>
the user would have to do it manually
<MichaelRaskin>
Or you could imperatively load AL as the first form in the .asd file
robdog has quit [Ping timeout: 252 seconds]
<MichaelRaskin>
Wait, what am I doing, I should stop arguing that this madness is feasible
<makomo>
oh hah, i guess that would work
puchacz has joined #lisp
<makomo>
no, continue :D
<puchacz>
hi, why would #<SB-INT:STREAM-DECODING-ERROR {10248F80B3}> not be caught by handler-bind serious-condition?
<puchacz>
i.e. (handler-bind ((serious-condition (lambda (e) (print-to-repl e) (log-errors -1 nil e nil))) ) .... )
robdog has joined #lisp
<puchacz>
I got something with this error message: the octet sequence #(161) cannot be decoded.
<makomo>
puchacz: maybe the error is coming from your handler, not the body of handler-bind?
<puchacz>
checking
Zaab1t has joined #lisp
<MichaelRaskin>
I hope you checked the the problem is runtime, not load-time
robdog_ has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
<puchacz>
the last (or first) line in backtrace is this
<puchacz>
does it mean that something happened during printing backtrace, i.e. in my error handler?
<makomo>
puchacz: oh also, if your handler doesn't perform a so-called "transfer of control", the condition remains unhandled and keeps looking for handlers higher up the stack
<puchacz>
makomo: it is probably the case
<makomo>
if the condition was signalled with SIGNAL, once it reaches the top (i.e. no more handlers are available), nothing happens. however, if it was signalled with ERROR, once it reaches the top, a debugger is (usually) invoked
<puchacz>
as it is my first use of handler-bind
<makomo>
yeah, you should take some time and check out the various pages regarding conditions in CLHS
<puchacz>
I want to catch serious conditions, log them and forget about them, like with handler-case
<makomo>
right, so use handler-case then
<makomo>
handler-case is just a wrapper around handler-bind that performs a transfer of control, effectively handling the condition
<puchacz>
makomo: I cannot use handler-case if I want to log full stack
<puchacz>
I want to see what function called what function etc... all the way from the top (http request handler) to the function that signalled serious condition
<puchacz>
I want to log it and then drop this thread, letting user see error page
robdog has joined #lisp
<puchacz>
like in Java try { body} / catch (Exception e) { log exception, show error page }
<puchacz>
I cannot do it with handler case because it unwinds the stack
robdog_ has quit [Ping timeout: 252 seconds]
varjag has joined #lisp
<makomo>
java's exceptions do the same thing
<puchacz>
in Java the stack is captured at the point of "throwing" an exception, so it can be reported later even if the stack is already unwound
<makomo>
you log the exception within your handler (you enter the "catch"), and then the handler performs a transfer of control to the form right after the handler-case (you exit the "catch")
<makomo>
right, that's a different thing
<makomo>
so you want to implement backtraces or something?
<makomo>
what about trivial-backtrace that you're using?
<puchacz>
there is trivial-backtrace library that I want to use
<puchacz>
yes
<puchacz>
but it will only stringify the stack information, providing I did not unwind it :)
<makomo>
i've never used that library so i don't know how it works nor what its requirements are
robdog has quit [Ping timeout: 240 seconds]
<puchacz>
so I think this is what happened in my application, I correctly used trivial backtrace to stringify the stack information to the log, but then I did not do "something" and the condition was still unhandled which killed the app (in production mode there is no debugger)
<puchacz>
makes sense?
<puchacz>
this "something" being the thing that handler-case does but not handler-bind
<makomo>
right, a "transfer of control" (clhs 5.2)
<puchacz>
okay, reading the link you pasted
barryjb has joined #lisp
lumm has quit [Read error: Connection reset by peer]
lumm has joined #lisp
<makomo>
it semes to be working fine for me. i see TRIVIAL-BACKTRACE:PRINT-TRIVIAL-BACKTRACE at the top just like you do
<makomo>
but because the type of the error is a stream error it's a bit confusing because it's not clear whether your app failed or TRIVIAL-BACKTRACE failed
<makomo>
try it with (error "hello") and you'll see it gets reported nicely
Adamclisi has quit [Remote host closed the connection]
<makomo>
maybe the fact that trivial-backtrace appears at the top is just a consequence of the mechanism they use to capture the backtrace? i don't know
<puchacz>
makomo: I don't think you will see a difference between unwinding and not unwinding stack if your error is at the high level
<puchacz>
I will stick to handler-bind just in case
karlosz has quit [Quit: karlosz]
ggole has joined #lisp
elazul has joined #lisp
<makomo>
puchacz: you're using SBCL right?
<makomo>
from what i can see, it is indeed due to the way trivial-backtrace gathers backtraces, at least on SBCL
<makomo>
they use sb-debug:print-backtrace, which includes in its backtrace the whole stack up to the moment at which it was called
<puchacz>
what you mean is that it is intended that the first/last entry is trivial backtrace printing function, isn't it?
<makomo>
yes, indeed
robdog has joined #lisp
<makomo>
when you call (f), you should see all of G1, G2, G3 and G
<makomo>
with DEBUG 0 you don't, because SBCL optimizes some of them out
<puchacz>
so what am I to do in handler bind to make it behave like handler case?
<makomo>
using a dummy dynamic variable *test* just for testing, it seems that functions which bind dynamic variables don't get optimized out (or at least they get included in the backtrace or something)
<makomo>
but set DEBUG to 3 and run (f)
<makomo>
you'll see the whole thing just before sb-debug:print-backtrace was called
<makomo>
so that's intentional, at least on SBCL
<makomo>
puchacz: well, why do it by hand when you can just use handler-case?
<puchacz>
because it would report stack trace after unwinding the stack
<makomo>
is the problem the fact that you don't see the calls to E1, E2, E3 and E?
<puchacz>
will check in a moment, I just replaced sbcl with 1.5.0 and it is not compiling my app
<puchacz>
:-)
<puchacz>
every now and then sbcl becomes stricter with new release
hhdave has joined #lisp
dddddd has joined #lisp
_whitelogger has joined #lisp
<puchacz>
and report it to log file, and then forget about the incident, like handler-case does
<makomo>
welp, sb-debug:print-backtrace won't help you then, because that print the backtrace at the point it was called
<makomo>
at that point, you're already in the handler for handler-case
<makomo>
the same thing would happen with handler-bind
<puchacz>
handler-bind reported it correctly
<makomo>
it did?
<makomo>
hmm
<puchacz>
yes
<puchacz>
just the app died after that
<makomo>
hm, let me see
<puchacz>
btw, I am reverting to previous sbcl. I have no patience today to think what it does not like
<makomo>
lol ok :-)
<puchacz>
invalid index 9 for (vector 1) or something
Bike has joined #lisp
<puchacz>
while it was about to report undefined function
<makomo>
hm, you're right about handler-bind. let me see what i said that was incorrect
<puchacz>
I guess you thought they report similar stack because your error was not deep enough
<makomo>
ahhh, i see
nowhereman has quit [Ping timeout: 257 seconds]
<makomo>
"... and if there is no intervening handler for a condition of that type, then control is transferred to the body of the relevant error-clause. In this case, the dynamic state is unwound appropriately ..."
<puchacz>
when I implement it, the next step will be to try to "fix" this 160 encoding problem
<puchacz>
as in debugger, there is a restart "try to skip this character and proceed to next character boundary" or something
cage_ has joined #lisp
<puchacz>
so I would like to invoke it programmatically, BUT I don't want to fall into indefinite loop if it is unable to fix it and keeps coming back at the same stream position
<puchacz>
indefinite = infinite
<makomo>
mhm
<puchacz>
in this case it proceeds
<puchacz>
but I can imagine broken encodings where it cannot proceed
<makomo>
basically the author used the condition system as the backbone of his software :D
<puchacz>
what is (setq #1# temp) in clhs example?
<puchacz>
shouldn't it be (setq #2# temp) in both handlers?
<makomo>
yup, there's a small typo there
<makomo>
nothing is perfect :-)
hhdave has quit [Quit: hhdave]
Lord_of_Life_ has joined #lisp
<makomo>
in this case, the TAGBODY/GO are the ones performing the transfer of control
robdog has quit [Ping timeout: 252 seconds]
Lord_of_Life has quit [Ping timeout: 245 seconds]
<puchacz>
also, it is just (go #3=#), not (go #3=#:g0003), right?
<puchacz>
sorry (go #3#)
<makomo>
i don't think so. that should be as it is
<puchacz>
okay
Lord_of_Life_ is now known as Lord_of_Life
random-nick has joined #lisp
wanz has quit [Remote host closed the connection]
robdog has joined #lisp
wanz has joined #lisp
wxie has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
barryjb has quit [Quit: Leaving]
scymtym has joined #lisp
robdog has joined #lisp
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
lucasb has joined #lisp
ravenousmoose has joined #lisp
Ukari has quit [Remote host closed the connection]
Aruseus has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
ravenousmoose has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
robdog has joined #lisp
refpga has quit [Ping timeout: 240 seconds]
ravenousmoose has joined #lisp
q9929t has joined #lisp
robdog_ has joined #lisp
igemnace has joined #lisp
q9929t has quit [Read error: Connection reset by peer]
robdog has quit [Ping timeout: 252 seconds]
Ukari has joined #lisp
robdog_ has quit [Ping timeout: 252 seconds]
izh_ has joined #lisp
flazh has quit [Ping timeout: 252 seconds]
robdog has joined #lisp
vutral has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
p9fn has quit [Ping timeout: 264 seconds]
FreeBirdLjj has joined #lisp
wxie has quit [Quit: Bye.]
robdog has joined #lisp
wxie has joined #lisp
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
robdog has quit [Ping timeout: 252 seconds]
wxie has quit [Ping timeout: 252 seconds]
troydm has joined #lisp
Oladon has joined #lisp
robdog has joined #lisp
elazul has quit [Ping timeout: 245 seconds]
<puchacz>
makomo: if you are still here, I just read PCL and I think it does not say anything about the need to go to tag or return from block if you don't want the condition to bubble higher
<puchacz>
which of course means PCL description is missing this aspect, not that you don't need to do it, as we observed today earlier
robdog_ has joined #lisp
<makomo>
hm, are you sure?
<makomo>
"To handle the condition, the function must transfer control out of SIGNAL via a nonlocal exit. In the next section, you'll see how a handler can choose where to transfer control."
<puchacz>
right, but there is no example :)
<makomo>
yeah, true :-)
<puchacz>
if I don't do anything, "control returns to the SIGNAL function" - this is what was happening to me
<makomo>
yeah, it doesn't really explicitly mention the stuff we did today
<makomo>
i agree
<puchacz>
"which will search for the next most recently established handler with a compatible type specifier." - and there was none
robdog has quit [Ping timeout: 252 seconds]
<puchacz>
so it was quitting, as sbcl was running without debugger
<puchacz>
got it
<makomo>
yup. note that in your case it was ERROR, not SIGNAL
<makomo>
using SIGNAL, even with a condition that "represents an error", will not enter a debugger
<puchacz>
yes, but I had a handler-bind on serious-condition, which covers errors
<makomo>
yeah, sure. just wanted to mention that it's important what you use to signal the condition :-)
<puchacz>
rly? if I signal serious-condition, and I have no handler for it, it will NOT invoke debugger or quit?
<makomo>
yeah, try it
<makomo>
(signal (make-condition 'error))
<makomo>
vs. (error (make-condition 'error))
<puchacz>
ha
<makomo>
that's one aspect that i haven't really seen explained very well anywhere (along with the transfer of control thing, i guess)
<Bike>
the error function basically just calls signal, and if it returns, then calls invoke-debugger.
<puchacz>
I thought (error ...) or another function that is automatically created when condition is created just does (signal (make-instance ....))
troydm has quit [Ping timeout: 268 seconds]
<makomo>
it takes some digging around CLHS to get all of the details
<puchacz>
right. and what's the difference between make-instance and make-condition?
<makomo>
makes sense
<Bike>
make-condition makes conditions
<Bike>
it might not go through initialize-instance or allocate-instance
<makomo>
conditions aren't necessarily guaranteed to be implemented as CLOS objects
<puchacz>
can't I use make-instance to make a condition?
<Bike>
not necessarily
<puchacz>
ha. Common Lisp can be hairy :)
<Bike>
conditions aren't fully integrated into CLOS, so condition types don't have to act like normal classes
<Bike>
they probably do, though
<puchacz>
Bike, the whole discussion started as I had incorrect bytes in stream which crashed whole lot of my program. when I started playing with it interactively, I noticed that sbcl gives a restart that will try to skip incorrect bytes to the next character boundary.
robdog_ has quit [Ping timeout: 252 seconds]
<puchacz>
is it safe to invoke it programmatically, without going into infinite loop, if it cannot proceed after all, and signals the problem in the same position in the stream over and over again, and I restart it?
<puchacz>
I was thinking about "heuristics" of say not invoking this restart more than 100 times.
<makomo>
aren't "skip" and "cannot proceed" contradictory here?
<makomo>
will it skip the incorrect data or not? :-)
<Bike>
if it tries to skip and fail does the new error still have the "skip" restart?
<puchacz>
in my case it fixed the problem, so I don't know
<puchacz>
it "failed" twice, but in the end it processed the whole page
<makomo>
i'm assuming that with enough skips you would eventually get to the end of the stream, right?
<puchacz>
so I guess it had 2 broken characters somewhere
<puchacz>
I would hope so
<puchacz>
okay, I will just try to do it
<makomo>
yeah, i don't see how you could get stuck in an infinite loop
<makomo>
only a "pretty long" loop
robdog has joined #lisp
flazh has joined #lisp
jjkola has joined #lisp
<jjkola>
hi
robdog_ has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
<puchacz>
will it be an error to handler-bind to generic serious-condition and (invoke-restart 'attempt-resync) in it? it will catch any serious-condition, but sbcl specific stream processing errors have this restart, so I don't know what happens if I get say "file not found".
<puchacz>
oh, good. otherwise I would have to bind on internal sbcl error
<puchacz>
are restart names in cl-user for example?
<makomo>
that's what i'm wondering as well, not sure
<puchacz>
the PCL examples were using the same package
<makomo>
"If identifier is a symbol, then the innermost (most recently established) applicable restart with that name is returned. nil is returned if no such restart is found."
<makomo>
so i guess the symbol's package doesn't matter?
<puchacz>
yeah, I was after 'attempt-resync from sbcl stream handling
heisig has joined #lisp
X-Scale` is now known as X-Scale
Oladon has quit [Quit: Leaving.]
robdog has joined #lisp
<puchacz>
okay, it is sb-int:attempt-resync
<puchacz>
undocumented :(
robdog has quit [Ping timeout: 252 seconds]
<puchacz>
just to reiterate please, if I DON'T invoke any restart, the serious-condition bubbles up, doesn't it?
<puchacz>
it is not like in Java that it is "swallowed" unless re-thrown or anything?
<puchacz>
if I don't invoke restart and don't exit nonlocally, e.g. by calling return-from
<Bike>
yes, it will keep invoking handlers until one transfers control.
nanoz has quit [Ping timeout: 240 seconds]
<Bike>
note that handler-case produces handlers that DO transfer control, so if it reaches a handler-case it will stop there.
<puchacz>
yes, but I switched to handler-bind few days ago. expanded my vocabulary :)
<puchacz>
as I wanted to record problems in log with proper stacktrace
<puchacz>
and now I also realised I can "fix" some problems like this one with encoding
<Bike>
right. handler-bind is the more primitive mechanism, and handlers won't transfer control unless you write that explicitly
<Bike>
fyi, sb-int is the sbcl internals package, so usually you're not supposed to use that stuff... buuuuut you're not the only person i've seen trying attempt resync
hiroaki has joined #lisp
<puchacz>
so if there is another handler-bind up the stack, it will take over if the lower one executes a function that is bound to a condition, but the function neither invokes restart nor returns non-locally?
<puchacz>
sorry if I sound repetitive, but I am finding it confusing
<Bike>
i'm not sure what you mean by "a function that is bound to a condition"
<Bike>
also, invoking a restart is a nonlocal exit.
<Bike>
if my-single-arg-function returns normally, the condition system will keep looking for handlers.
<puchacz>
looking up for more handler-bind constructs if this handler-bind has no more handlers?
<Bike>
no more applicable handlers, yes.
<puchacz>
so it will progress to another function bound to T first in the same handler-bind, and only then progress to another handler-bind up the stack
<Bike>
uh... i think so.
<puchacz>
okay :)
robdog has joined #lisp
<Bike>
i'm less clear on how it goes with multiple bindings in the same handler-bind.
<djeis[m]>
Conditions can have more complicated class hierarchies than just "decends from t".
<puchacz>
I think I will get it working the way I want, but - it is just too complex :(
<Bike>
so yes, it can hit multiple handlers from the same handler-bind
<puchacz>
okay
<dtw>
To "handle" a condition the handler function must not exit normally (locally). Use RETURN, INVOKE-RESTART and such things and that means to "handle" the condition.
<puchacz>
yup. lack of these killed my app, as I initiallly thought it would work as handler-case
<djeis[m]>
Ah, they're searched left-to-right (as opposed to class specificity order)
nalkri has quit [Ping timeout: 245 seconds]
<djeis[m]>
"If more than one handler binding is supplied, the handler bindings are searched sequentially from top to bottom in search of a match (by visual analogy with typecase). If an appropriate type is found, the associated handler is run in a dynamic environment where none of these handler bindings are visible (to avoid recursive errors). If the handler declines, the search continues for another handler.
<djeis[m]>
If no appropriate handler is found, other handlers are sought from dynamically enclosing contours. If no handler is found outside, then signal returns or error enters the debugger."
robdog has quit [Ping timeout: 252 seconds]
<puchacz>
another one please, is (format t ...) guaranteed to print somewhere in slime?
<puchacz>
repl or inferior-lisp?
<djeis[m]>
It depends a bit.
<djeis[m]>
Well, more than a bit.
<djeis[m]>
(format t ...) is just short for (format standard-output ...)
<puchacz>
so what's the best way to display a debug message when developing?
Essadon has joined #lisp
notzmv has joined #lisp
<dtw>
(format *error-output* ...) probably.
<puchacz>
tks
<djeis[m]>
debug-io
<djeis[m]>
Either works, but debug-io you can read from too.
lavaflow_ has quit [Read error: Connection reset by peer]
<djeis[m]>
None of these are guaranteed to go anywhere in particular b/c you (or other code) can redirect them arbitrarily, but for the most part you can just assume that they'll go somewhere convenient (like the repl)
<puchacz>
I also found *terminal-io*
<djeis[m]>
Unless you redirect them yourself.
<djeis[m]>
Ah, yea, that'll probably always go to the inferior lisp buffer.
<djeis[m]>
You're not supposed to rebind that one.
robdog has joined #lisp
<dtw>
Emacs slime/swank (re)defines those streams.
<puchacz>
oh, so they are not available without slime? like in production environment?
<djeis[m]>
Well, it rebinds them around your code.
<djeis[m]>
No, all of those streams exists.
<puchacz>
good
<djeis[m]>
s/exists/exist
<djeis[m]>
They're dynamic variables tho, not streams.
<scymtym>
i didn't read the whole conversation, but maybe this helps: SBCL allows external formats to be specified like '(:utf-8 :replacement #\Pile_of_Poo) to automatically replace non-decodable characters and continue. i'm not sure whether this includes attempting to re-sync or not
<djeis[m]>
They're just supposed to always be bound to streams with particular semantics.
<puchacz>
bound to anything in bare bones lisp?
<djeis[m]>
In the worst case they should all be synonyms for terminal-io.
<puchacz>
scymtym: it may help, thanks
<djeis[m]>
slime/swank rebinds those streams to places that make more sense for working from emacs, but it has to deal with multithreading nonsense and it doesn't have control over all of the code in the running program.
<djeis[m]>
So, code you run from the repl on the repl thread should have everything redirected to the repl (for example)
<djeis[m]>
(Except terminal-io)
robdog has quit [Ping timeout: 252 seconds]
<djeis[m]>
s/rebinds those streams/rebinds those vars/
charh has quit [Ping timeout: 255 seconds]
<puchacz>
yes. I got it working with *debug-io* btw
<djeis[m]>
Oh good :)
<puchacz>
phew. (when (find-restart 'sb-int:attempt-resync) (invoke-restart 'sb-int:attempt-resync) ) worked
<puchacz>
but. I am not surprised there are so few tutorials and examples about CL conditions :(
<puchacz>
sometimes I wish CL specs was refreshed after 30 or so years of experience accumulated now
<pjb>
(let ((*standard-output* (make-broadcast-stream))) (format t "Highway to nowhere!")) #| --> nil |#
robdog has quit [Ping timeout: 252 seconds]
<pjb>
puchacz: write a book about CL conditions and restarts.
nowhere_man has joined #lisp
<puchacz>
pjb :)
<puchacz>
I wish a committee of lispers smarter than me just polished CL specs into CL 1.1, to save me from traps and inconsistencies.
<pjb>
Also: there are a lot of tutorials about common lisp conditions and restarts out of google…
<puchacz>
and people would have a library that would still allow for executing CL 1.0 code
<pjb>
puchacz: what traps and inconsistency? there's the prog2 specified as prog1, but if we didn't tell you, you'd read it as prog2 anyways, so no harm.
lavaflow_ has joined #lisp
<puchacz>
PCL is excellent and it is one of these tutorials, but for example I missed the important piece of info that handler-bind does not "kill" the condition processing and I have to exit nonlocally otherwise it is not handled and bubbles up.
<djeis[m]>
The problem isn't making a better spec, it's getting implementations to adopt it.
<puchacz>
pjb: what inconsistencies? for example make-instance vs make-condition
<djeis[m]>
That's for performance reasons, more or less.
<pjb>
it's not inconsistent. It lets the implementation use CLOS or use something else to implement conditions.
<djeis[m]>
There are implementations where the condition system is totally divorced from CLOS.
robdog has joined #lisp
<Xach>
djeis[m]: do you know which ones offhand?
<minion>
Xach, memo from jackdaniel: it seems that quicklisp stopped to pick up commit from clx repository (we had o hard-reset it around december, so that is probably a cause)
<djeis[m]>
That's... a fair point, actually, I couldn't come up with a list off hand.
<djeis[m]>
There's a decent chance that at this point there aren't any.
<djeis[m]>
My point still stands tho- the problem isn't writing a better spec, it's getting that spec adopted by the implementations and the community.
<djeis[m]>
Changes break workflow, they invalidate decades of optimization work, etc.
CCDelivery has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
Bike has quit [Quit: Lost terminal]
<djeis[m]>
It took ten years to write the spec the first time.
<puchacz>
yes, but maybe people have discovered problems in the specs itself since.
<djeis[m]>
Sure, but not everyone agrees that those problems are worth a new spec.
<djeis[m]>
Or even agrees what those problems are.
<puchacz>
I am not saying write something from scratch that loosely reminds of Lisps (like Clojure) and call it "modernisation of Lisp". just go from 1.0 to 1.1, people would come up with compatibility layer, like in Javascript
<djeis[m]>
It's not a bad idea in principle. The problem is implementing it.
<puchacz>
the community has not enough manpower I guess
<djeis[m]>
Specifically, getting all of the popular implementations to agree to do it.
<djeis[m]>
You'd have to convince the maintainers of all of the popular implementations that every single change you want to make is a good idea.
varjag has joined #lisp
<makomo>
puchacz: regarding the various non-obvious things regarding conditions: you'll (most of the time) easily catch those if you start from CLHS itself, rather than tutorials :D
<djeis[m]>
And they're heavily swayed by their biggest users.
<makomo>
or maybe you don't have to start from CLHS, but at least read it afterwards to get the whole picture
gxt has quit [Quit: WeeChat 2.4]
<makomo>
but i agree that a tutorial that covers everything about conditions would be useful
<puchacz>
somebody (Christoph Rhode?) wrote unification interface for collections, I heard about it 10 years ago. not sure if it was adopted
<puchacz>
makomo: I achieved what I wanted today, but the road was bumpy :)
<puchacz>
unexpectedly bumpy
izh_ has quit [Quit: Leaving.]
<makomo>
puchacz: yeah, it wasn't the prettiest when i was first reading about conditions either
<puchacz>
sorry, Christophe Rhodes
<pjb>
sbcl is the only one where (subtypep (quote condition) (quote standard-object)) is false. In abcl, ccl, clisp and ecl it's true.
<makomo>
that's why it's important to write down your findings and assemble a set of notes that will help you refresh your memory if you forget the details :-)
<djeis[m]>
How about allegro or lispworks?
cage_ has quit [Remote host closed the connection]
<pjb>
djeis[m]: do it yourself: clall -r '(subtypep (quote condition) (quote standard-object))'
<Xach>
jackdaniel: ouch, sorry!
varjag has quit [Ping timeout: 250 seconds]
Aruseus has quit [Remote host closed the connection]
<minion>
Remembered. I'll tell Bike when he/she/it next speaks.
<makomo>
"Once a handler in a handler binding form (such as handler-bind or handler-case) has been selected, all handlers in that form become inactive for the remainder of the signaling process. While the selected handler runs, no other handler established by that form is active. That is, if the handler declines, no other handler established by that form will be considered for possible invocation."
<makomo>
(handler-bind ((simple-condition #'print) (condition #'print)) (signal "test")) prints twice for me as well, but how is that correct?
varjag has joined #lisp
robdog has joined #lisp
<pjb>
Yep, prints twice, in ccl too.
pankajgodbole has joined #lisp
<makomo>
so is that an error or?
<makomo>
i mean, from what i understand, it should be, but maybe i'm missing something
<pjb>
9.1.4. has contradictory statements: "While the selected handler runs, no other handler established by that form is active. That is, if the handler declines, no other handler established by that form will be considered for possible invocation."
<makomo>
right, i was just about to quote that
Oladon has joined #lisp
<makomo>
actually no, that's what i already quoted
<makomo>
i meant to quote this, from handler-bind's page: "f an appropriate type is found, the associated handler is run in a dynamic environment where none of these handler bindings are visible (to avoid recursive errors). If the handler declines, the search continues for another handler."
<pjb>
The first sentence concerns only the dynamic scope of execution of the selected handler. The second sentence talks about after the execution of the selected handler, once it has declined, but it uses "That is" which establishes an equivalence between the two sentences. Since the consequent is contradictory with the first sentence this specification is wrong.
robdog has quit [Ping timeout: 252 seconds]
<makomo>
right
<makomo>
the quote from handler-bind confirms the former, i.e. "*while* a handler is being run, no other handlers from the form that established the current handler are seen"
<makomo>
but for the latter, it says "If the handler declines, the search continues for another handler."
<makomo>
the search continues, but what handlers are active?
<pjb>
If we delete "that is" then we get: (during a => nh) and (after a => nh) so we're good.
<pjb>
It looks like the search should continue with the outer most recent handler bindings.
<pjb>
but clhs handler-binds lists thet two cases: If the handler declines, the search continues for another handler. If no appropriate handler is found, other handlers are sought from dynamically enclosing contours. If no handler is found outside, then signal returns or error enters the debugger.
<pjb>
so in the first case, another handler means the following handlers in the same handler-bind.
lavaflow_ has quit [Read error: No route to host]
<pjb>
puchacz: we don't really need a new specifications. What we'd need is a FORMAL specification.
<makomo>
pjb: "nh" meaning?
<pjb>
none of these handler bindings are visible (to
<makomo>
i assumed that, but i was wondering how you abbreviated it to "nh" :D
<pjb>
noh?
<makomo>
i guess, i don't know
<makomo>
but i'm still thinking about the "that is" part
<Josh_2>
Afternoon all
<makomo>
there's another sentence at the beginning of that paragraph
<pjb>
makomo: the "that is" must be deleted.
<makomo>
perhaps it wasn't establishing equivalence with the 2nd sentence, but the 1st
<makomo>
i.e. "Once a handler in a handler binding form (such as handler-bind or handler-case) has been selected, all handlers in that form become inactive for the remainder of the signaling process."
<makomo>
from that, the 2nd and 3rd sentence follow
<makomo>
pjb: how do you know this "another handler means the following handlers in the same handler-bind"?
robdog has joined #lisp
<makomo>
it doesn't say so explicitly, and 9.1.4 specifically contradicts that
Aruseus has joined #lisp
<pjb>
Yes. the two cases in clhs handler-binds: "If the handler declines, the search continues for another handler. If no appropriate handler is found, other handlers are sought from dynamically enclosing contours. If no handler is found outside, then signal returns or error enters the debugger." clarify it.
lavaflow_ has joined #lisp
dreamcompiler has quit [Ping timeout: 255 seconds]
<makomo>
hm, i guess it does, because otherwise it would say "if it declines OR no appropriate handler is found, they are sought from dynamically enclosing contours"
<makomo>
it wouldn't break the two apart
<makomo>
but still, doesn't this directly contradict 9.1.4?
<makomo>
which says that if a handler declines, "no other handler established by that form will be considered for possible invocation."
gareppa has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
* makomo
afk for some time
dreamcompiler has joined #lisp
CCDelivery has quit [Ping timeout: 250 seconds]
gareppa has quit [Quit: Leaving]
robdog has joined #lisp
<puchacz>
pjb: formal like what? written in a programming language so it can be "executed"?
<puchacz>
right. I think clhs is very carefully written anyway, as makomo said
robdog has joined #lisp
nowhere_man has quit [Remote host closed the connection]
nowhere_man has joined #lisp
<Josh_2>
Is there a more concise while still clear way to rewrite this? https://plaster.tymoon.eu/view/1244#1244 ? Just trying to enable/disable certain html elements
robdog_ has joined #lisp
<Josh_2>
but because cl-who is able to evaluate functions I used flet, but it just seems like a pita to write functions like that, as I need to write another but this time with every property from a structure Q_Q
robdog has quit [Ping timeout: 252 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
<puchacz>
now I will get back to my attempt to use sbcl 1.5.0, in the morning I tried but I got: Invalid index 9 for (SIMPLE-VECTOR 1), should be a non-negative integer below 1.
robdog_ has quit [Ping timeout: 252 seconds]
<puchacz>
in (SB-C::FIND-SOURCE-ROOT 9 #<SB-C::SOURCE-INFO {1011671843}>) while compiling
FreeBirdLjj has joined #lisp
<puchacz>
hmmm
<puchacz>
my app compiles fine with sbcl 1.4.13
nowhere_man has quit [Ping timeout: 258 seconds]
nowhereman has joined #lisp
FreeBirdLjj has quit [Ping timeout: 255 seconds]
<puchacz>
file-info indeed has an array of a length of 1, and I have no idea what 9 means
nowhereman has quit [Remote host closed the connection]
robdog has joined #lisp
pankajgodbole has quit [Ping timeout: 244 seconds]
<Josh_2>
Looks like I could make a macro but maybe later
Khisanth has quit [Ping timeout: 245 seconds]
ghard has joined #lisp
<Josh_2>
perhaps I will change from using keyword args to using a plist then I could map over and that would make it easier to change the low level structure and quickly adapt the whole program to match *thonk*
robdog has joined #lisp
Zaab1t has quit [Quit: bye bye friends]
robdog has quit [Ping timeout: 252 seconds]
groovy2shoes has quit [Quit: moritura te salutat]
Khisanth has joined #lisp
robdog has joined #lisp
Woazboat has joined #lisp
robdog has quit [Ping timeout: 252 seconds]
Fare has quit [Ping timeout: 255 seconds]
dreamcompiler has quit [Quit: dreamcompiler]
robdog has joined #lisp
ravenousmoose has joined #lisp
emaczen has joined #lisp
<emaczen>
I'm looking at *init-hooks* in the sbcl manual -- what good does calling functions in an unspecified order do?
<emaczen>
Or is there a different recommended way for initialization hooks
<jackdaniel>
emaczen: it gives a clear message: each init hook must be independent of each other
robdog has quit [Ping timeout: 252 seconds]
ghard has quit [Ping timeout: 240 seconds]
<LdBeth>
sup
<emaczen>
jackdaniel: Okay, I see what I have to do now
<Josh_2>
LdBeth: sdown
random-nick has quit [Read error: Connection reset by peer]
robdog has joined #lisp
elazul has joined #lisp
slightlycyborg has joined #lisp
travv0 has left #lisp [#lisp]
<slightlycyborg>
Hi. IYO, what is the best way to represent a tree in clear text. Also what is the best lisp structure to store it into?