pyericz_ has quit [Quit: This computer has gone to sleep]
pierpa has joined #lisp
random-nick has joined #lisp
amerlyq has quit [Read error: Connection reset by peer]
amerlyq has joined #lisp
amerlyq has quit [Ping timeout: 256 seconds]
amerlyq has joined #lisp
amerlyq has quit [Ping timeout: 240 seconds]
igemnace has quit [Quit: WeeChat 2.1]
amerlyq has joined #lisp
makomo has quit [Ping timeout: 248 seconds]
amerlyq has quit [Read error: Connection reset by peer]
amerlyq has joined #lisp
markong has joined #lisp
milanj has quit [Quit: This computer has gone to sleep]
kerrhau has quit [Ping timeout: 240 seconds]
Younder has quit [Remote host closed the connection]
nowhereman_ has joined #lisp
logicmoo has quit [Ping timeout: 268 seconds]
dmiles has quit [Ping timeout: 255 seconds]
nowhere_man has quit [Ping timeout: 240 seconds]
Kaisyu has quit [Quit: Connection closed for inactivity]
hhdave has joined #lisp
kushal has joined #lisp
jcowan_ has joined #lisp
Younder has joined #lisp
dmiles has joined #lisp
jcowan has quit [Ping timeout: 246 seconds]
logicmoo has joined #lisp
amerlyq has quit [Ping timeout: 264 seconds]
amerlyq has joined #lisp
ak5 has quit [Ping timeout: 256 seconds]
panji has left #lisp [#lisp]
Th30n has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 276 seconds]
fikka has joined #lisp
<phoe>
Is postmodern capable of handling multiple parallel requests to postgres?
fikka has quit [Ping timeout: 240 seconds]
<antoszka>
phoe: have you tried running them with, say, lparallel?
milanj has joined #lisp
fikka has joined #lisp
wildbartty has quit [Quit: Leaving]
<phoe>
antoszka: I have no idea how postmodern works on the inside. Even if I use multiple threads in my code, they may block on a single connection for example.
<phoe>
Hence my question.
<antoszka>
Well I'm sure you could easily find that out if you try (by even watching connections).
damke_ has joined #lisp
<antoszka>
I don't know whether the library is blocking or not.
<antoszka>
But I'd just experiment ;)
<phoe>
Okay, that's what I'll do (eventually).
<antoszka>
Just try 10 `sleeps` in parallel.
<antoszka>
And see if they complete within ~n seconds, or ~n*10 seconds.
<antoszka>
phoe: SELECT pg_sleep(10);
damke has quit [Ping timeout: 264 seconds]
Quetzal2 has joined #lisp
DVSSA has quit [Ping timeout: 255 seconds]
daniel-s has joined #lisp
igemnace has joined #lisp
raynold has quit [Quit: Connection closed for inactivity]
<flip214>
phoe: antoszka: the CONNECT function has a POOLED-P keyword argument...
<phoe>
normally, Database error: This connection is still processing another query.
<phoe>
[Condition of type CL-POSTGRES:DATABASE-ERROR]
<phoe>
that is what I get.
amerlyq has quit [Ping timeout: 252 seconds]
nika has quit [Remote host closed the connection]
<phoe>
In other words, I should create N connections manually with :POOLED-P T, correct?
amerlyq has joined #lisp
rumbler31 has joined #lisp
EvW has joined #lisp
rumbler31 has quit [Ping timeout: 260 seconds]
Younder has quit [Remote host closed the connection]
_cosmonaut_ has quit [Ping timeout: 256 seconds]
igemnace has quit [Read error: Connection reset by peer]
<flip214>
phoe: do you set *database*?
<flip214>
I guess you should be using (with-connection (... :pooled-p T) body) and not ever set *DATABASE* at all.
<flip214>
also note that (connect-toplevel) *does* set *database*
<flip214>
phoe: and also be aware of potential problems if you (need to) give the database connection up, eg. because of multiple independent requests via hunchentoot
<flip214>
a SELECT FOR UPDATE will not work, because a) the old transaction might/will be aborted, and b) you might get assigned some other connection
pyericz_ has joined #lisp
DVSSA has joined #lisp
orivej has quit [Ping timeout: 268 seconds]
<phoe>
flip214: thanks. I will use that one.
<phoe>
Also, only my worker threads will be using the connections.
<phoe>
And I know the amount of worker threads.
rumbler31 has joined #lisp
rumbler31 has quit [Remote host closed the connection]
_cosmonaut_ has joined #lisp
EvW has quit [Ping timeout: 276 seconds]
rpg has joined #lisp
jcowan_ is now known as jcowan
sindan has quit [Ping timeout: 276 seconds]
wheelsucker has quit [Quit: Client Quit]
sindan has joined #lisp
bjhx has joined #lisp
shka has joined #lisp
<shka>
hello!
milanj has quit [Quit: Leaving]
ghard has joined #lisp
<shrdlu68>
shka: Hi
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
EvW has joined #lisp
pyericz_ has quit [Quit: This computer has gone to sleep]
DVSSA has quit [Ping timeout: 264 seconds]
Bike has joined #lisp
agspathis has joined #lisp
thinkpad has quit [Ping timeout: 246 seconds]
thinkpad has joined #lisp
fzappa has quit [Remote host closed the connection]
DVSSA has joined #lisp
daniel-s has quit [Remote host closed the connection]
<phoe>
hey
BitPuffin has joined #lisp
warweasle has joined #lisp
Kundry_Wag has joined #lisp
varjag has joined #lisp
amerlyq has quit [Ping timeout: 260 seconds]
amerlyq has joined #lisp
jcowan has quit [Ping timeout: 276 seconds]
Kevslinger has joined #lisp
smokeink has joined #lisp
amerlyq has quit [Read error: Connection reset by peer]
amerlyq has joined #lisp
EvW has quit [Ping timeout: 256 seconds]
dcluna has quit [Ping timeout: 264 seconds]
<schweers>
is LAUNCH-PROGRAM a fairly recent addition to UIOP? I don’t have it on my machine.
<schweers>
As I’m running debian (read: ancient software) I suspect that I might need a newer version
<phoe>
schweers: yes.
<phoe>
ASDF 3.2, iirc
amerlyq has quit [Ping timeout: 268 seconds]
* schweers
sighs
<phoe>
fairly recent counting in lisp time, that is
<schweers>
Is anyone aware of other semi-portable ways to start asynchronous processes?
<schweers>
and recent in debian time too
dcluna has joined #lisp
<phoe>
schweers: only your implementation's support.
<schweers>
k
amerlyq has joined #lisp
<schweers>
upgrading asdf is supposed to be pretty painless, right?
<schweers>
so I don’t necessarily have to install a new version for the whole system, but can drop it somewhere where the installed asdf can find it?
<svillemot>
schweers: /usr/local/share/common-lisp/source should be the right system-wide path
<svillemot>
my understanding is that schweers uses the ASDF from the Debian package, not from its implem, which is 3.1.7 in Debian "Stretch" 9
<schweers>
I’m not entirely sure whether asdf comes from the implementation (sbcl) or from debian. Is there a way to check which version is currently loaded?
<schweers>
It seems that the cl-asdf package from debian testing is new enough, maybe I’ll use that or build a newer sbcl from source
<svillemot>
schweers: indeed you can install the one from testing, it will probably work
<svillemot>
schweers: (asdf:asdf-version)
<schweers>
thanks. it matches the version number aptitude gives me
<schweers>
right, cl-asdf/buster it is :D
<svillemot>
that one is 3.3.1
<schweers>
huh. I’ve installed the new version and I still get the old one in a new lisp image
<schweers>
there, now I have LAUNCH-PROGRAM. Thanks a lot for the help!
<svillemot>
np :)
agspathis has quit [Remote host closed the connection]
hiroaki has joined #lisp
sjl has joined #lisp
amerlyq has quit [Ping timeout: 264 seconds]
p9tet2 has joined #lisp
amerlyq has joined #lisp
sjl has quit [Ping timeout: 240 seconds]
sjl has joined #lisp
amerlyq has quit [Ping timeout: 256 seconds]
fikka has quit [Ping timeout: 260 seconds]
EvW has joined #lisp
makomo has joined #lisp
<phoe>
schweers: yay!
<schweers>
do I have to hold on to the return value of LAUNCH-PROGRAM?
<schweers>
It seems to me that the process dies in my program (where I do not care about the return value, other than the stream it contains)
fikka has joined #lisp
<phoe>
schweers: I don't think so, if you want it to be fire-and-forget
<phoe>
on my machine it gives me a process-info structure of some sort
<flip214>
schweers: you'll need to PROCESS-CLOSE or similar when it's done.
<schweers>
I want to compress my output with bzip2. So instead of just opening the file (as I did until now), I create a bzip2 process. I give it as output the filename I previously opened directly and return the input stream, promptly forgetting the process-info value itself
<flip214>
schweers: that won't work in practice.
<phoe>
schweers: why is that asynchronous?
<flip214>
what if it runs out of space when writing?
<schweers>
flip214: my experiments on the REPL showed me that CLOSE on the input stream is sufficient, how is that wrong?
<flip214>
how do you get a success/error value from bzip2?
<schweers>
I would assume that writing to the input stream then signals a condition
<phoe>
oh wait, you just launch a bzip2 program, write to its input, and read its output?
<flip214>
doesn't have to.
<schweers>
I let bzip2 write its output do the filesystem
<flip214>
imagine that it reads the last input block, but then writes and fails.
<schweers>
hmm
<flip214>
on the input side this is indistinguishable from "okay"
<flip214>
you HAVE to check the return code.
<schweers>
I get your point, but still: why do the processes seem to simply die? is it because the return value of launch-program is garbage collected?
<flip214>
or even HAVE TO
EvW has quit [Ping timeout: 276 seconds]
<phoe>
schweers: no
<flip214>
schweers: do you get zombies, or is the destination file not written correctly?
_cosmonaut_ has quit [Ping timeout: 240 seconds]
<phoe>
if the return value is GCed the process lives on
<flip214>
what's "simply die" to you, exactly?
<schweers>
I’m still not entirely sure, but the files don’t manifest themselves.
<flip214>
phoe: there's no return value until the process is dead ;)
fikka has quit [Ping timeout: 240 seconds]
<flip214>
schweers: do you call a shell with redirection, or pass the output filename to bzip2 as :output?
<phoe>
schweers: check all the output streams of bzip2, including stderr, for any data that might appear there.
<flip214>
if the latter, do you also have :if-output-exists etc. options?
<schweers>
the latter
<flip214>
also, use strace to check for the exact behaviour.
<schweers>
I pass :rename-and-delete, but they should never exist
<schweers>
strace, good point
<flip214>
perhaps you'd want RUN-PROGRAM?
<schweers>
no, I want it to be asynchronous
_whitelogger has joined #lisp
rann has joined #lisp
dmh has joined #lisp
gz has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
<schweers>
oh
<schweers>
is it possible that I’m not allowed to call LAUNCH-PROGRAM from a thread other than the main thread?
fikka has quit [Ping timeout: 260 seconds]
EvW has joined #lisp
<phoe>
weird
<phoe>
I can do that normally
<schweers>
its not that, I just tried, works fine
smokeink has quit [Remote host closed the connection]
nowhere_man has joined #lisp
DVSSA has joined #lisp
rumbler31 has joined #lisp
<schweers>
ugh. seems that I got tripped up again with sbcl and pathnames
<schweers>
I have a pathname which has no namestring
<schweers>
so that can’t work
heisig has quit [Quit: Leaving]
<schweers>
right, sorry guys, false alarm
fluxit has quit [Max SendQ exceeded]
fluxit has joined #lisp
fikka has joined #lisp
nowhereman_ has quit [Ping timeout: 264 seconds]
_cosmonaut_ has joined #lisp
Cymew has quit [Remote host closed the connection]
damke has joined #lisp
nika has joined #lisp
damke_ has quit [Ping timeout: 264 seconds]
smokeink has joined #lisp
m00natic has quit [Remote host closed the connection]
hiroaki has quit [Ping timeout: 240 seconds]
amerlyq has joined #lisp
nika has quit [Ping timeout: 240 seconds]
<flip214>
schweers: no problem, the important thing is that you got it working!
<flip214>
anyway, we're all just somebody's rubber duck
<phoe>
^
<schweers>
turns out that I am giving some wrong parameters in. I gave a broken pathname, gave :rename-and-delete (which is illegal), and :error-output t is also apparently illegal
<schweers>
yeah, thanks for that!
<phoe>
<3
* flip214
waits for phoe to give a downward arrow, so that I can write something useful there
hiroaki has joined #lisp
<phoe>
v
<flip214>
HOORAY
<flip214>
thanks
<flip214>
the suspension was nearly killing me
<phoe>
there, I'll be fancy
<phoe>
↓
<Shinmera>
#lispcafe
Kundry_Wag has joined #lisp
<flip214>
✓✔↵
yeticry has quit [Ping timeout: 268 seconds]
FreeBirdLjj has joined #lisp
nika has joined #lisp
yeticry has joined #lisp
scymtym_ has quit [Ping timeout: 264 seconds]
Kundry_Wag has quit [Ping timeout: 256 seconds]
<schweers>
is there actually a good reason why sbcl does not properly work with pathname types like "tar.bz2"?
<phoe>
schweers: yes, there was one - when you have "foo.bar.baz" it has no idea whether the file "extension" is "bar.baz" or "baz"
<schweers>
thats not what I mean
<phoe>
schweers: what exactly fails for you?
<schweers>
I construct a pathname like this: (make-pathname :name "foo" :type "tar.bz2")
fikka has quit [Ping timeout: 248 seconds]
<schweers>
it fails to give me a namestring
<rpg>
schweers: this isn't really SBCL's fault -- the ANSI spec really isn't clear about how file types should be parsed, because it was written in a time of greater filesystem diversity than today.
<schweers>
I know, but why did the sbcl devs decide to do it this way?
<rpg>
I am honestly a little surprised, though, that when you push a type in with MAKE-PATHNAME it doesn't do the right thing.
<Xach>
schweers: I suspect it is inherited from CMUCL, and the answer may be lost in the mists of time. or not!
<schweers>
oh, I didn’t know about that function
<rpg>
What do you get back from (describe (make-pathname :name "foo" :type "tar.bz2"))
<phoe>
schweers: just like the spec, uiop has many mysteries
<phoe>
rpg: the type is correctly set to be "tar.bz2" but NAMESTRING refuses to work with it.
<phoe>
I mean #'NAMESTRING
<rpg>
wow. That's weird
<flip214>
The pathname #<PATHNAME ...> does not have a namestring because the :TYPE component contains a #\.
<flip214>
is what current SBCL says.
<schweers>
rpg: regarding your point that the standard doesn’t specify how to do this: I know that, but it seems like a language lawer move. It seems to me to be an insane way of handling this, but I might be wrong. Hence my question about the rationale for this way of doing things.
<schweers>
so?
<Xach>
schweers: I think it is reasonable to say that the type is everything after the final "." and the name is everything before.
<Xach>
It is arbitrary, but reasonable.
<Xach>
I don't know why sbcl works that way.
<rpg>
Xach: but surely if you actually push a value into type as in this case, NAMESTRING ought to report it back.
<phoe>
yep, (namestring (make-pathname :name "foo.bar" :type "baz")) works
<dlowe>
can't have complex file types
<schweers>
Does the standard require namestring parsing and printing to be a bijective relation?
<rpg>
To refuse to parse this makes sense to me, but to refuse to emit it just seems weird.
<Xach>
rpg: I don't think so, because it can't round-trip.
<dlowe>
type sounds like a terrible thing to have as a pathname field anyway
<Xach>
rpg: if you parse-namestring you get a different object, and that's not what namestrings are for.
amerlyq has joined #lisp
<rpg>
Xach: In that case, I think SBCL should raise an error in response to setting type in that way.
<rpg>
I.e., if it's not legal to work with namestring, it should not be legal period.
<Xach>
Maybe!
<rpg>
"legal period" was not *intended* to be a pun!
<TMA>
it lacks a period then
<flip214>
this behaviour might have originated from a pre-unix period
<flip214>
schweers: just take a unicode point. here's one for you: ·
<flip214>
so foo·tar.gz
<schweers>
I have to follow this convention for other tools
<schweers>
and no, I will not confuse anyone with such a character
orivej has joined #lisp
<flip214>
schweers: ".tgz" is also popular
<rpg>
flip214: But that's for gzip and this is bzip
<schweers>
I only used "tar" and "bz2" because those are well known examples
<flip214>
tbz or tbz2, then
<schweers>
its actually about .osm.pbf and .osm.bz2
<rpg>
Double extensions aren't uncommon for compressed files these days.
<flip214>
well, in the end the tools don't care. name them ".schweers" and be done ;)
<schweers>
I’m afraid they do care
<schweers>
I think I can force the format, but then I’d rather stick to the convention
Kundry_Wag has joined #lisp
<flip214>
how about (CONCATENATE 'string filename ".tar.bz2") and avoid pathnames altogether?
pierpa has quit [Ping timeout: 260 seconds]
<Xach>
If it were me, I would make a function that makes a new suffix like .bz2 by combining the existing name and type into the name and making the new suffix the type. There are many other options.
fikka has joined #lisp
pierpa has joined #lisp
amerlyq has quit [Ping timeout: 256 seconds]
shrdlu68 has quit [Ping timeout: 264 seconds]
jcowan has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
<Shinmera>
pathname-utils has functions to get the "real" type and name of a file, but nothing to push/pop types. Should probably add that.
<Xach>
ccl had an approach where the namestring had an escape character distinguishing where the name ended and the type began. i don't remember exactly how it was shown, but it meant you would see something like "foo\.tar.gz" or "foo>.tar.gz"
scymtym has joined #lisp
jmercouris has joined #lisp
mflem has joined #lisp
schweers has quit [Read error: Connection reset by peer]
schweers has joined #lisp
fikka has joined #lisp
jmercouris has quit [Remote host closed the connection]
jmercouris has joined #lisp
pierpa has quit [Ping timeout: 260 seconds]
k-stz has joined #lisp
Cymew has joined #lisp
raynold has joined #lisp
scymtym_ has joined #lisp
<rpg>
Pathnames were a reasonable idea, but these days namestrings are more portable. :-/
ak5 has joined #lisp
<jasom>
uiop has some tools for manipulating unix namestrings as well, FWIW
LiamH has joined #lisp
<rpg>
If you think type is bad, wait until you look at HOST and DEVICE!
Cymew has quit [Ping timeout: 256 seconds]
scymtym has quit [Ping timeout: 276 seconds]
<Shinmera>
Well DEVICE is at least somewhat reasonable still due to Windows
<jasom>
Shinmera: but how it works with default pathnames is annoying
pierpa has joined #lisp
lnostdal has quit [Ping timeout: 260 seconds]
<jasom>
see e.g. uiop:merge-pathnames* documentation string
<jasom>
also HOST makes sense with UNC
bjxbmc has quit [Ping timeout: 260 seconds]
lnostdal has joined #lisp
<jasom>
\\HOST\SHARE\PATH
smokeink has quit [Ping timeout: 264 seconds]
bjxbmc has joined #lisp
zacts has quit [Quit: WeeChat 1.9.1]
EvW has quit [Ping timeout: 245 seconds]
DVSSA has quit [Ping timeout: 264 seconds]
<jcowan>
The Python path library is a pretty good model, actually
nsrahmad has joined #lisp
<beach>
jcowan: Maybe you missed it, but I told you that SICL and Clasp are very very different implementation.
<jcowan>
I did see that, yes.
<jcowan>
I don't think I ever supposed otherwise.
<beach>
Well you said <jcowan> yes, I was conflating SICL and Clasp there
<jcowan>
Ah. That was a problem of names.
<jcowan>
(forgot for a moment which label was attached to which)
<beach>
I see.
<beach>
Just wanted to set things straight.
<jcowan>
Sure.
<jcowan>
so "conflating" was a poorly chosen word on my part
<beach>
Yes, I see.
<jcowan>
Clasp has a backend, viz. LLVM; SICP doesn't.
fikka has quit [Ping timeout: 240 seconds]
<beach>
Among other things, yes. SICL will have one eventually, of course.
<beach>
Also SICL does not have a line of C or C++ in it.
bjhx has joined #lisp
<raynold>
ahh it's a wonderful day
bjxbmc has quit [Ping timeout: 276 seconds]
<jasom>
does SICL have an IR yet?
<beach>
Yes. That part (Cleavir, the compiler framework) is working, and Clasp uses it for its main compiler.
hhdave has quit [Ping timeout: 255 seconds]
<beach>
The first intermediate representation is AST. Then the AST is translated to HIR (High-level Intermediate Representation).
<jasom>
Is HIR at about the level of SBCL's IR1?
<beach>
HIR is pretty much a standard flow graph as in other compilers, except that only Common Lisp objects are manipulated by the instructions, so address calculations are not exposed at that level.
<beach>
By doing it this way, we can do things like type inference in HIR.
<beach>
I haven't looked at the details of SBCL's intermediate representations.
<jasom>
IR1 is a flow graph and it preserves type information.
<beach>
OK. Sounds like they are similar then.
fikka has joined #lisp
<jcowan>
But there is nothing wrong with the idea of writing a back end that outputs Scheme and invokes Scheme procedures that implement the primops.
<jcowan>
(afaict)
<jasom>
jcowan: scheme isn't necessarily an optimal kernel language for CL, but it's certainly ported to everything.
<beach>
jcowan: Well, the entire compiler is written in Common Lisp, but if you don't mind having a Scheme compiler written in Common Lisp, then that's fine.
<jcowan>
It would be a Common Lisp compiler that generates Scheme (as opposed to C or C++ or LLVM), not a Scheme compiler.
<beach>
Oh, I see.
<dlowe>
might as well just emit guile bytecode, and have a common lisp frontend to guile
<phoe>
jcowan: it's essentially about writing a compiler from beach's HIR to Scheme
<phoe>
or to Guile bytecode
<beach>
jcowan: Well, SICL has a similar backend already. It takes HIR and translates it into a very simple subset of Common Lisp.
<jcowan>
dlowe: Yes, but generating Scheme means you can use more capable Scheme systems than Guile
<dlowe>
true
<beach>
jcowan: That way, I can execute SICL code inside a Common Lisp host, in this case SBCL.
* jcowan
nods.
Karl_Dscc has joined #lisp
rumbler3_ has joined #lisp
<jcowan>
This is distinct from aeth's desire to have a Scheme compiler that generates Common Lisp.
fikka has quit [Ping timeout: 256 seconds]
fourier has joined #lisp
energizer has joined #lisp
<cgay>
What does SI stand for in SICL?
<beach>
Nothing.
<beach>
SICL doesn't mean anything. It is just easy to pronounce.
<beach>
"sickle".
<cgay>
I see, thanks.
<phoe>
...I just realized that if someone tried to make a Common Lisp successor and if they called it Uncommon Lisp, it would be pronounced like "uncle".
<jcowan>
Unfortunately aeth and I were discussing the two ideas at the same time, and I occasionally lost track
<phoe>
UnCL
<jcowan>
Scheme is already "an uncommon Lisp"
<phoe>
jmercouris: correct, but not necessarily a CL successor
<warweasle>
I'm slated to learn it in 100 years...
rumbler3_ has quit [Ping timeout: 256 seconds]
<jcowan>
Scheme has also been thought of an as an UNCOL (Universal Computer Oriented Language), or mechanism for translating between any two other computer languages
<semz>
rpg: Thanks for recommending CCL the other day. After a few hours of beating it with a stick it worked without any visible trouble.
SlowJimmy has quit [Client Quit]
SlowJimmy has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
SlowJimmy has quit [Client Quit]
<phoe>
semz: you have an uncommon definition of no visible trouble
<semz>
phoe: Well, monkeypatching C code for a while beats random runtime failures
<phoe>
semz: what did you need to patch?
fikka has joined #lisp
<jmercouris>
phoe: no problem
<jmercouris>
so let's say we implemented this ficticious CL -> Scheme compiler
<jmercouris>
could we still do the same stuff in CL that we can do now?
puchacz has joined #lisp
<jmercouris>
could we redefine functions, and have this interactivity or no?
<jmercouris>
would the REPL be as capable as it is now?
<jasom>
jmercouris: that is entirely up to how you translate to scheme
<jmercouris>
jasom: I see
<Shinmera>
If you can't redefine functions it's not a standards compliant CL.
shka_ has joined #lisp
<jmercouris>
so CL should be able to run on anything that runs C, correct?
<jmercouris>
considering that ECL exists and it can output shared c libs
<jmercouris>
so why would anyone bother making a compiler to scheme?
<jmercouris>
what might some advantages be?
<semz>
phoe: There were four problems. The first was the usual missing glibc-specific includes, <mcheck.h> and <fpucontrol.h>. Interestingly enough, fpucontrol.h didn't seem to be actually used anywhere.
<Shinmera>
scheme interop
<jasom>
jmercouris: well that's complicated. It does not generate portable C
<jmercouris>
it doesn't generate portable C, that's true
fikka has quit [Ping timeout: 260 seconds]
<semz>
The second was a missing definition of struct _libc_xmm, or more accurately the fact that this struct has no name in musl. A somewhat ugly way to fix that was to define struct _libc_xmm in the same way in the source file
<jasom>
e.g. IIRC it won't run under emscripten, since it assumes a C stack.
<jmercouris>
Shinmera: why would anyone want scheme interop?
<semz>
The third was a glibc-specific function to get a version string which I just replaced with a placeholder
<jasom>
or rather a traditional C stac, (C doesn't specify how the stack is implemented)
<Shinmera>
I don't know, I don't use Scheme.
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jmercouris>
it seems to me, if anything the most useful would be Lisp -> X86 compiler
<phoe>
semz: oooooh, correct, you ported it to musl! that's a pretty damn nice thing.
<phoe>
jmercouris: there already exists one
<phoe>
it's called SBCL
<Shinmera>
multip,e ones
<jmercouris>
ah, then there is no point in making any others then :D
<phoe>
and also CCL
<semz>
Finally, the kernel would compile but segfault during relocation (do_relocs wrote to j_SPjmpsym which is readonly). This was fixed by disabling PIC though this might bite me later
<jasom>
cmucl, sbcl, and ccl all do that.
<jmercouris>
I had no idea that they did that
<phoe>
jmercouris: if we all had your mentality, we'd still be stuck with punch tapes
<jmercouris>
I just assumed they made fasls and had a specialized "kernel" that could load their own fasls
<semz>
for the time, i have a working CL on here and that's all i care about :)
<jasom>
jmercouris: in sbcl (disassemble (lambda (x y) (+ x y)))
<jmercouris>
phoe: but they would be incredible, plus retro is cool these days
<phoe>
we can compute everything computable by writing programs on punch cards or whatever, there's no point in making any other input device
<jmercouris>
I don't think we can compare punch cards to my compilation ideas
<jasom>
jmercouris: they all have a runtime that implements things like GC, I/O and such, but when you compile a function it generates machine code that only assumes the existence of that runtime.
<jmercouris>
one is the medium you start in, the other is the medium you go to
moei has quit [Quit: Leaving...]
fisxoj has joined #lisp
<jmercouris>
jasom: wow, it actually made asm on my screen with disassemble, very interesting
<jcowan>
jmercouris: Schemers would like Scheme interop, at least some of them would
<jcowan>
er, CL interop
<jasom>
jmercouris: if you run a profiling run first than disassembly will also have instruction level profiling information
<jmercouris>
jasom: so a FASL is machine code, in SBCL at least
<jmercouris>
so can we run it without the kernel?
<Bike>
nope.
<Bike>
those are separate concerns.
<Shinmera>
SBCL's FASL is a stack machine
fikka has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
<Bike>
most compiled c programs do not run on bare metal either. there's no need for them to.
<jasom>
fasl is not machine code, because FASL's do more than just load code.
<jmercouris>
Okay, so this compilation then
<jmercouris>
where is it piped to?
<jmercouris>
persisted?
<jmercouris>
when we "compile" a program, where does that asm live?
<jasom>
and that's like asking if you can run a compiled C function without libc...
<Bike>
in the fasl
<jasom>
jmercouris: RAM
<jasom>
jmercouris: and when you save an image, it dumps all of ram to disk, including the compiled functions
<Bike>
do you know what a compiled c program looks like? you get an elf or a mach-o or whatever, which has code, and a bunch of other stuff
ak5 has quit [Ping timeout: 256 seconds]
<jasom>
the FASL does (among other things) include machine code for the toplevel DEFUNs
<jmercouris>
Bike: yes, I do
<Bike>
ok, so a fasl is like that
<Bike>
it's got code and it's got a bunch of other stuff
<jmercouris>
I see, makes sense
<jmercouris>
I was imagining a completely standalone binary
<Bike>
cooperating with an operating system is cool actually
<jmercouris>
though I assume on embedded devices, for microlisp? ulisp? there is a way to make JUST the instructions that run the program, right?
<Bike>
probably
<Bike>
i don't think there are CLs on embedded though
<phoe>
CL is too huge to be properly embeddable in kilobytes or even megabytes of ram
<Shinmera>
There was Movitz
<jasom>
jmercouris: a "Tree Shaker" will remove all the unused parts of the runtime
<Shinmera>
Well, for bare metal.
<Shinmera>
But yeah, CL won't run embedded.
<jasom>
sbcl does not currently have a working tree shaker (though there was a prototype one about 10 years ago)
<phoe>
Mezzano is bare-metal nowadays
<jasom>
This is odd because embedded devices now adays are much beefier than a mid-80s lisp machine.
<jmercouris>
jasom: "Tree Shaker"? is that referring to the AST?
<jasom>
jmercouris: no, tree of live objects
<jmercouris>
What is the tree of live objects?
<jmercouris>
google doesn't return anything useful
<dlowe>
you have root objects that are always accessible. Those objects refer to other objects that must be kept live.
<Bike>
(cons a b) returns a thing. the thing has a and bin it, or points to them, or whatnot
<Bike>
the cons is a component of the graph of objects in memory
<dlowe>
and those objects refer to other objects, etc.
<jmercouris>
are you telling me that every object in CL has a reference to some root object?
<Bike>
no
<jmercouris>
and they are all interconnected in some tree?
<Bike>
that is actually the opposite of what dlowe said
<dlowe>
sure. how would you reach it otherwise?
<jasom>
jmercouris: well actually it's a graph, but it's a directed graph with known roots. If you remove e.g. the common-lisp package from the roots, then any functions in common-lisp not referenced from your program will "fall out" of the tree. Hence a tree shaker
<jasom>
jmercouris: you have it backwards. All objects in CL are reachable from a set of root objects.
<jmercouris>
Okay, fine, so it is a directed graph and therefore only one way
<dlowe>
right.
<jmercouris>
but nonetheless links exist outwards from some "root object"
<Bike>
root objects.
<jmercouris>
what is that root object?
<jasom>
jmercouris: this is how garbage collectors work. any objects not reachable from the set of root objects are no longer in use, and thus freed.
<Bike>
plural.
<dlowe>
like global variables
<dlowe>
top level functions
<Bike>
packages.
<dlowe>
packages
<jmercouris>
I assume global variables and top level functions are tied to some plist?
<jasom>
jmercouris: the current call stack.
<Bike>
no.
<Bike>
fuck plists.
<Bike>
implementation can store them however it wants.
<jmercouris>
okay, so there is no root object, but a set of root objects that all CL implementations implement?
<jasom>
40 years ago they were probably in plists
<jasom>
er more like 50 rather
<phoe>
jmercouris: packages are such root objects
<Bike>
the set is variable.
<dlowe>
anyway, a tree shaker lets you specify, explicitly, which root objects you *actually* care about, and then prunes objects that don't have a reference to them.
<jmercouris>
jasom: I'm familiar with several types of garbage collection
<jmercouris>
so we kill everything downstream of whatever roots we aren't interested in?
<dlowe>
theoretically if you don't use the CL compiler, say, it would eliminate that.
<jmercouris>
is there a list of roots that a CL implementation must implement?
<Bike>
no.
<phoe>
jmercouris: no
<phoe>
everything you can reach is alive
<phoe>
everything you cannot reach is dead
<phoe>
that's the basis of all GC algorithms
<phoe>
like, in general
<jmercouris>
phoe: well... :D
<jmercouris>
let's not get into that, especially not when we begin talking about distributed systems
<Bike>
you're already into that
<jmercouris>
that's true, it is an interest of mine
<Bike>
i mean
<jmercouris>
:P
<Bike>
that's what this conversation is about
<Bike>
things being alive
<jmercouris>
no, I know, I'm just joking
<Bike>
so as an example, in lispworks, you usually distribute images that don't include the compiler
<Bike>
because you don't usually need the compiler at runtime
<jmercouris>
okay, so let's say a given implementation, how do they decide what the root objects will be?
<Bike>
so the lispworks whatevermacallit shakes out the compiler functions and stuff that's dead if those aren't in.
<jasom>
jmercouris: everything reachable from the global environment. e.g. everything in all of the packages defined by the implementation (including, but not limited to the COMMON-LISP package)
<jmercouris>
thank you for the information everyone
<jasom>
For tree shaking, you just remove all of the non-user-defined packages from the root set, and then anything not used by user-defined packages is no longer reachable, and can be safely deleted.
<dlowe>
The after-tree-shaking image is not guaranteed to be a conforming implementation of CL. :)
<jasom>
It's actually somewhat trickier than that (the devil is always in the details), but that's the idea.
<jmercouris>
jasom: what if the user didn't import a symbol
<jmercouris>
and they were just accessing like ::
<dlowe>
it's worse - what if the user interns symbols by concatenating strings
<jasom>
jmercouris: then it is still *referenced* by their code, and thus usable.
<jmercouris>
ah right, this is already loaded code
<jmercouris>
so the image should know that
<jmercouris>
or whatever it is called
<jmercouris>
I am never sure of which terms to use when
<jmercouris>
I have these nebulous images in my mind of the different components working together
<jasom>
if they try to convert strings to symbols at runtime (e.g. they are implementing an interpreter) it won't work right, but if you have an interpreter then you need the whole runtime anywas and shouldn't be using a tree-shaker.
<jmercouris>
so a tree-shaker, how does it remove these branches/root objects we don't want?
<jasom>
jmercouris: there is already code to do this; it's called the "garbage collector"
<jmercouris>
does it free them from memory? is there some special process? is it tied to the implementation? is there a CL command?
<jmercouris>
okay, so you are telling me we can invoke the GC ourselves in Lisp?
<pierpa>
Scissors
FreeBirdLjj has joined #lisp
<Bike>
usually you can invoke the gc, sure.
<Bike>
sb-ext:gc for one
<jmercouris>
via some sort of ext?
<jmercouris>
ok
<jasom>
jmercouris: It is not built into the standard, but almost all implementations provide it.
<phoe>
jmercouris: (trivial-garbage:gc)
<jasom>
jmercouris: plus, most implementations usually run the GC implicitly before saving an image (Because it would be stupid to not to)
<jmercouris>
jasom: I see, yeah that makes sense
<jmercouris>
no need to persist garbage memory
<dlowe>
You could in theory have a conforming CL with manual memory management.
<jmercouris>
I think that would be really cool
<dlowe>
(ext:free obj)
<jmercouris>
is there an sb-ext to disable the GC?
<phoe>
jmercouris: yes
<Bike>
there's a without-gcing
<jasom>
jmercouris: yup
<Bike>
is it exported?
<Bike>
i thought that was an internal interface
<jmercouris>
so you could already do it today then, no?
<jasom>
if you run out of ram with it disabled it panics though.
<Bike>
do what
<phoe>
Bike: I think it is not exported.
<jmercouris>
run lisp with manual memory amangement
<jasom>
and there is no manual free
<jmercouris>
ah, well
<jmercouris>
that is problematic
<dlowe>
jasom: that's what while true; do sbcl; done is for :D
<Bike>
manual memory lack of management
nsrahmad has quit [Quit: Leaving]
<jasom>
ECL with the boehm collector disabled would work; you can use free() to free the objects.
<Bike>
a system with manual memory management but without fixed addresses sounds pretty weird.
<Bike>
like it still copies whenever, you just have to free stuff
<jmercouris>
you could free by symbol or something
<jasom>
Bike: there could be a manually invoked compact() command.
<dlowe>
a big problem with that is dealing with fixnum->bignum promotion
<jasom>
The Raven memory system can sort of work that way.
<dlowe>
you'd have to free your bignums, but you don't actually know when it stops being a fixnum without checking.
nika has quit [Quit: Leaving...]
<Bike>
could just have free on fixnums be a no-op.
<Bike>
of course then you still have to free every number you use which is shit.
<Bike>
jasom: can it? the manual side of mps seems a little underdeveloped
<onion>
reference counting
<phoe>
can't deal with cycles that way
<jasom>
One day a student came to Moon and said: “I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons.”Moon patiently told the student the following story: “One day a student came to Moon and said: ‘I understand how to make a better garbage collector...
<phoe>
jasom: was thinking of posting that
<onion>
cycle = reference
<Bike>
use sentences
<onion>
[you are] missing [a] noun. i would really like the opportunity to organize and lay out my own memory and addresses, that was my favorite thing
<phoe>
onion: there's no way to refer to cycles *as* references without traversing the whole reference tree each time you modify a pointer.
knicklux has joined #lisp
varjag has joined #lisp
<phoe>
because a single modification of a reference can either create a cycle or break a cycle or both.
<onion>
the reference count is just a number, starts at 1 on instance create, free object when its at 0
<Bike>
we know what reference counting is
orivej has quit [Ping timeout: 256 seconds]
<onion>
just got to match up the open and close. we lisp dont we? parenthesis...? eh?
<phoe>
onion: no.
jcowan has quit [Ping timeout: 264 seconds]
<jasom>
onion: #1=(A . #1#) <== this will never be collected because it will always have a reference count of at least 1
<onion>
great work showing me how to english while we give great examples
<onion>
nah, no to all, lets not share or cooperate
<makomo>
i added the quicklisp loading code into my .sbclrc but it seems i can't use any of ql's functionality directly after (load quicklisp-init) is evaluated?
<makomo>
i get "Package QL does not exist."
<phoe>
makomo: are you using symbols from the QL package in the same form where you do the LOAD?
<makomo>
i wanted to add a few lines of code which would automatically push a path onto ql:*local-project-directories* and call (ql:register-local-projects)
<makomo>
phoe: nope, after
<makomo>
the whole thing is wrapped in a let which contains the (load ...) and then my stuff
<jasom>
that's all in the same toplevel form then
<phoe>
makomo: that's in the same form.
<jasom>
QL doesn't exist when the LET form is read
<makomo>
oh i see
<phoe>
(let (make-package :foo) 'foo:bar)
<phoe>
uh sorry
<makomo>
hm yeah, true...
<phoe>
(progn (make-package :foo) 'foo:bar)
<phoe>
this will error at read-time because at read time there is no package FOO
<makomo>
ah i see, it's looked up at read-time
<makomo>
mhm, got it
<phoe>
onion: the problem of reference counting has been solved many times and there are no sane ways of turning cycle information into reference counts, which are numbers.
<phoe>
each time you modify a pointer, you have to traverse the tree and see what changed. so basically after every modification of a reference, you run GC.
<Baggers>
the slime-repl code says 'This used to be the default REPL for SLIME, but it was hard to maintain' what is the default repl used in slime now?
<cgay>
heh, now it's hard to maintain AND mysterious.
<Xach>
Baggers: inferior-lisp, I think, is the default. my impression is that few go with it.
warweasle has quit [Quit: later]
<Baggers>
Xach: Cheers. So the common case is probably still slime-repl then? I've just been using slime-fancy for ever without thinking about it
<fourier>
phoe: it is sort of solved via using different kind of reference counted pointers and by thinking about objects life time and ownership. to solve cycle problem you just have to think if the object is allowed to hold the life cycle of another object or not, and use weak pointer if not
<jasom>
fourier: weak pointers work for many useful types of data structures, but not for the general case
<jasom>
e.g. a tree with parent pointers, it's obvious that the parent pointer can be weak; a doubly-linked list, one of the two links can be weak &c. But if it's "I represent a bunch of nodes that may be a coset of other bunches of nodes, and they are directed" there is no solution
<Xach>
Baggers: that's my impression, yeah. slime-fancy is the easiest way to get it
SaganMan has quit [Quit: WeeChat 1.6]
<Baggers>
Xach: thanks, that helps a bunch
Kundry_Wag has quit [Remote host closed the connection]
fisxoj has quit [Quit: fisxoj]
Kundry_Wag has joined #lisp
<rme>
the tracing gc is a brilliant invention.
* beach
totally agrees.
<asarch>
"A half abstraction is expressed in code by a manifestation of the pattern, you're guaranteed to have massive code duplication with all the normal bad consequences that implies for maintainability." —Practical Common Lisp
<asarch>
Are patterns only for OOP programing?
<jasom>
asarch: the GoF patterns are very Java specific
<jasom>
e.g. the visitor pattern goes away if your language has closures.
fikka has quit [Ping timeout: 276 seconds]
<jasom>
asarch: with- is a pattern used in lisp, for example.
<jasom>
for manually managed resources that tend to have dynamic scope.
<onion>
phoe: okay, i see and didnt know that; havent come across many cycling stuff in my time of refcounted platforms
<jackdaniel>
patterns (in GoF sense) are considered unnecessary in CL, where you have macros which can capture such patterns in a good abstraction
<jackdaniel>
(at least I've encountered such opinion and I tend to agree with it)
<jasom>
jackdaniel: I gave a counterexample to that just a few lines earlier; the with- macro pattern.
nowhere_man has joined #lisp
<jackdaniel>
I see
<jackdaniel>
Common Lisp could use of some design patterns though, not GoF like though
<jackdaniel>
arranging libraries around protocols could be one
<jackdaniel>
having separate package for interface and for implementation is a nice idea too
rpg has joined #lisp
<jackdaniel>
having plugins which could be loaded into existing system could be 'standarized' if we had protocol-oriented libraries for instance
<jackdaniel>
"avoid macros if you can express something as a function" is a pattern too (sadly some programmers doesn't follow it)
<phoe>
I wouldn't call proper style conventions patterns
<jackdaniel>
it's not a style convention. programs behave differently depending on that
<phoe>
they are repeatable, in a way, but they definitely do not mean the same as design patterns in more javalike programming languages.
disumu has joined #lisp
<jackdaniel>
design patterns are some clues how to arrange things to make them work. it would be suprising if same design patterns would apply to fundamentally different languages.
<Bike>
sometime i should actually flip through that book on architecture and see how it got so big on programming of all things
<aeth>
jackdaniel: I would say "if you can express something as an inline function" rather than "as a function". If people are doing macros for performance, the only persuasive alternative is inline functions.
EvW has joined #lisp
sindan has quit [Quit: Leaving]
voidlily_ has quit [Remote host closed the connection]
sindan has joined #lisp
fikka has joined #lisp
voidlily has joined #lisp
knicklux has quit [Quit: Leaving]
galdor2 has joined #lisp
ghard` has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
gz_ has joined #lisp
<aeth>
I think design patterns are more architectural, though.
<scymtym_>
there are multiple kinds of patterns in the OOA/D space. general responsibility assignment patterns (GRASP) are more general guidelines like in jackdaniel's macro example, design patterns in the GoF sense are actually patterns with a name, problem statement, etc. and specific roles that match parts of the design model and architecture patterns are yet another thing
fikka has joined #lisp
felideon_ has joined #lisp
dlowe_ has joined #lisp
gz has quit [*.net *.split]
dmh has quit [*.net *.split]
jasom has quit [*.net *.split]
rotty has quit [*.net *.split]
galdor1 has quit [*.net *.split]
ghard has quit [*.net *.split]
dddddd has quit [*.net *.split]
segmond has quit [*.net *.split]
quazimodo has quit [*.net *.split]
felideon has quit [*.net *.split]
spectrumgomas[m] has quit [*.net *.split]
gbyers has quit [*.net *.split]
vert2 has quit [*.net *.split]
dlowe has quit [*.net *.split]
eschulte_ has quit [*.net *.split]
felideon_ is now known as felideon
dmh_ is now known as dmh
gz_ is now known as gz
gbyers_ is now known as gbyers
dlowe_ is now known as dlowe
pierpa_ has joined #lisp
dlowe has quit [Client Quit]
fikka has quit [Ping timeout: 256 seconds]
varjag has quit [Ping timeout: 240 seconds]
dlowe has joined #lisp
dcluna has quit [Ping timeout: 240 seconds]
FreeBirdLjj has quit [Ping timeout: 240 seconds]
dcluna has joined #lisp
jasom has joined #lisp
segmond has joined #lisp
dddddd has joined #lisp
rotty has joined #lisp
logicmoo has quit [Ping timeout: 263 seconds]
spectrumgomas[m] has joined #lisp
fikka has joined #lisp
slyrus has joined #lisp
makomo has quit [Ping timeout: 276 seconds]
fikka has quit [Ping timeout: 264 seconds]
damke_ has joined #lisp
damke has quit [Ping timeout: 264 seconds]
Kundry_Wag has quit [Read error: No route to host]
Kundry_Wag has joined #lisp
puchacz has quit [Quit: Konversation terminated!]
random-nick has quit [Remote host closed the connection]
Kundry_Wag has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
makomo has joined #lisp
jcowan has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
rumbler3_ has joined #lisp
rumbler3_ has quit [Remote host closed the connection]
Kundry_Wag has quit [Read error: Connection reset by peer]
fikka has joined #lisp
p9tet2 has quit [Quit: .]
fikka has quit [Ping timeout: 240 seconds]
disumu has quit [Remote host closed the connection]
pierpa has quit [Ping timeout: 260 seconds]
Mutex7 has joined #lisp
bjhx has quit [Ping timeout: 252 seconds]
random-nick has joined #lisp
bjhx has joined #lisp
Bike has quit [Ping timeout: 260 seconds]
Bike_ has joined #lisp
Winterschlaf has left #lisp ["Leaving"]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
phf has joined #lisp
Lord_of_Life has quit [Excess Flood]
shka_ has quit [Ping timeout: 276 seconds]
<phf>
what was the name of the project of implementing most of the Standard in portable lisp, that i believe beach was working on and that the c++/llvm lisp compiler is using?
<phoe>
phf: SICL?
Lord_of_Life has joined #lisp
<phf>
ah that's it, thank you very much
Kundry_Wag has quit [Remote host closed the connection]
fikka has joined #lisp
phf has left #lisp [#lisp]
Bike_ is now known as Bike
<onion>
is it possible to.... link symbols, like a symbolic link in the filesystem? for eg 'this-symbol points to whatever 'this-other-symbol points to
<Xach>
onion: no
<Xach>
onion: not like a symbolic link, anyway.
<onion>
hm ok., nothing like symbol alias ?
<phoe>
onion: non-evaluated symbols? nope
<phoe>
but wait a second
<phoe>
what do you mean by "point"?
<phoe>
you can define a symbol macro if that is what you want
<cgay>
symbol-macrolet?
jcowan_ has joined #lisp
<cgay>
But it sort of sounded like onion wanted something more permanent / global.
<onion>
in smalltalk its totally cool, to change system stuff, undefined behavior is kind of assumed to do that stuff too. people are a bit self conscious when they find themselves changing system core guts ...
logicmoo has joined #lisp
<jcowan>
Programs are allowed to redefine built-in procedures.
<jcowan>
Doing so will not change the behavior of
<jcowan>
other built-in procedures." (R5RS)
<Xach>
I like changing internal behavior in my favorite implementation but I don't expect it to work on anything but the version of the implementation I changed.
<onion>
jcowan: ah cool, so in scheme, the stuff that already "links" or refers/points to system builtins, they are still ok ?
Folkol has joined #lisp
<jcowan>
Well, redefining car may or may not change the behavior of user code
<phoe>
onion: so it is permitted to tweak your implementation's internals - just don't expect any kind of support when you do so on your own
<jcowan>
e.g. in a pure interpreter it probably will
<jcowan>
in a native code compiler it probably will not
wigust has quit [Ping timeout: 240 seconds]
<jcowan>
In R6RS and R7RS it is an error to mutate an identifier that has been imported
<aeth>
Clearly, the solution with a native code compiler is to recompile everything that uses car so that the desirable new behavior is used.
<pierpa_>
isn-t the compiler broken, if redefining a function has no effect?
hiroaki has quit [Ping timeout: 260 seconds]
<jcowan>
A *standard* function.
<jcowan>
aeth's approach is the only thing that would actually work
<aeth>
pierpa_: I suspect that car is always inlined
<onion>
yea, recompile
<onion>
hm cool
<pierpa_>
aeth: I suspect this too
<jcowan>
and if car is redefined to return a newly created car object, the likelihood of the compiler continuationg to work after a pervasisve change is small
<aeth>
But, hey, with my method at least you might get a compilation error.
<pierpa_>
jcowan: I seem to remember that it is possible to redefine CAR. No standard function must change behaviour because of this change.
<pierpa_>
has this changed recently?
BlueRavenGT has joined #lisp
<pierpa_>
so, IIRC, redefining CAR can't break the compiler
<jcowan>
pierpa_: That's what R5RS says.
<pierpa_>
it can only break user code
<pierpa_>
aha!
<jcowan>
In R6RS and R7RS systems, car is imported from a library, and that makes it an error to redefine it
<pierpa_>
ok. got it
<jcowan>
"an error" = undefined behavior
<pierpa_>
k
<onion>
so for ex., i could modify the symbol lookup stuff a bit, hackish, and add my own little symbol list for lookup. not that symbol links/aliases have any practical use, im just curious
<jcowan>
beach: What is the compilation unit of Cleavir?
<oleo>
welp, it's better when you write a compiler for your hacks....
<oleo>
and spawn/create/bootstrap the real thing....
comborico1611 has joined #lisp
<oleo>
instead of trying to fiddle with the runtime system
dented42 has joined #lisp
<onion>
yeah =)
<onion>
CL especially being one of the least tempting runtimes to 'customize' considering its purpose. albeit general =)
<oleo>
yah, the when the runtime system says it's UBER it doesn't have to be UBER when you port your ideas....
<oleo>
and implement it correctly....
<oleo>
s/UBER/UB/
<oleo>
meh
<aeth>
I wouldn't trust a runtime system written by Uber
pagnol has joined #lisp
logicmoo has quit [Ping timeout: 240 seconds]
<oleo>
welp, he can supplement the standard, just like any other implementor does.....
hiroaki has joined #lisp
logicmoo has joined #lisp
<pagnol>
I'm looking for something that would allow me to verify that an s-expression has a certain structure in a declarative fashion
<fourier>
destructuring-bind ?
<|3b|>
check-type ? (for relatively simple structures at least)
<|3b|>
or typep
<pagnol>
hmm.. maybe I underestimated destructuring-bind, I'll take another look
<pagnol>
I was thinking of something along the lines of json schema
<phoe>
pagnol: pattern matching library, like trivia
<sjl>
If you give an example, folks can give better recommendations.
<|3b|>
(typep '(1 (b)) '(cons number (cons (cons (member b c))))) -> t
<pagnol>
take something like what defpackage or defsystem takes as an example
<|3b|>
typep doesn't scale very well though :)
<pierpa_>
I think they want a schema checker. Can't do with a simple destructuring-bind.
<aeth>
right, you need do-destructuring-bind
<oleo>
isomorph-p
<pagnol>
I would like to declaratively specify that what follows :depends-on should be a list of keywords, for example
<aeth>
i.e. dolist and then destructuring bind on each sublist
<oleo>
but that's not declarative
<aeth>
you can combine destructuring-bind and the 5-line do-destructuring-bind to write a declarative macro that essentially combines them. Probably < 40 lines.
<aeth>
I'm not aware of a current implementation, but I wouldn't be surprised
<oleo>
(defun isomorph-p (a b) (cond ((atom a) (atom b)) ((atom b) nil) ((isomorph-p (car a) (car b)) (isomorph-p (cdr a) (cdr b))) (t nil)))
* |3b|
wonders if there are any better parsers available for lists than last time i looked. most of the ones i found only worked on character input
onion has quit [Ping timeout: 264 seconds]
<jasom>
which is more idiomatic: (apply #'funcall foo) or (apply (car foo) (cdr foo))
<Bike>
i'm gonna say the latter, but i've never seen it outside of an evaluator
<pierpa_>
I don't know about idioms, but the second one is way more perspicuous
<Xach>
I'd be more likely to use first/rest.
<Xach>
also: (eval foo) (not really)
<jasom>
(eval foo) has different semantics than the others
<jasom>
Bike: In this case it's a trampoline for a state machine.
<pierpa_>
(it was a joke. I think :)
Kundry_Wag has joined #lisp
<Xach>
jasom: in the case of function objects vs symbols in the car? Or something else?
<jasom>
Xach: in the case of the environment (e.g. flet)
fikka has quit [Ping timeout: 240 seconds]
<Bike>
apply doesn't know any more about the environment than eval does.
<jasom>
actually I'm not sure flet makes a difference
<jasom>
hmm, I'm sure there's a difference. Let me think.
<Xach>
jasom: that seems to be a variation of what i said. (which does not bother me...just want to make sure i understand.)
Kundry_Wag has quit [Ping timeout: 264 seconds]
travv0 has joined #lisp
<aeth>
Something like this is more idiomatic imo: (let ((foo `(+ 1 2 3))) (destructuring-bind (symbol &rest arguments) foo (check-type symbol symbol) (apply symbol arguments)))
<aeth>
car/cdr is unsafe!
<aeth>
destructuring-bind makes your assumptions concrete and that gives you more useful errors when they're wrong!
whonion has joined #lisp
<jasom>
ah function object in the CAR does not work certainly
<aeth>
car/cdr/caaddr/cdddadr/etc. are just ways to get a random NIL. And in CL (car NIL) => NIL and (cdr NIL) => NIL so you don't know where the NIL was introduced, so you don't know where the s-expression was malformed.
<jasom>
doesn't work with eval, but does work with funcall/apply
<jasom>
(eval (list (lambda () 1))) doesn't work, for example
fikka has joined #lisp
Karl_Dscc has quit [Remote host closed the connection]
<_death>
but (eval (list '(lambda () 1))) does
whonion has quit [Ping timeout: 255 seconds]
<_death>
anyway, (apply (car list) (cdr list)) is what I always use
fikka has quit [Ping timeout: 256 seconds]
scymtym has joined #lisp
Kundry_Wag has joined #lisp
fikka has joined #lisp
varjag has joined #lisp
onion has joined #lisp
onion is now known as whoman
fikka has quit [Ping timeout: 256 seconds]
Kundry_Wag has quit [Ping timeout: 264 seconds]
attila_lendvai has joined #lisp
whoman has quit [Ping timeout: 255 seconds]
<cgay>
(eval '(list x y)) => error if x or y unbound. (apply #'funcall '(list x y)) => '(x y) Or did I misread the question...it seems too obvious.
fikka has joined #lisp
<jasom>
cgay: you have a list that is of the form (FUNCTION ARG*) and you want to call the function with the arguments.
<cgay>
Isn't '(list x y) a list of that form?
<jasom>
cgay: yes, but so is `(,(lambda () 1))
<jasom>
cgay: and that works with funcall, but not eval
<cgay>
ok, I'm just pointing out that eval also evaluates all of the args as well, whereas apply/funcall will happily pass along the symbols.
<jasom>
this is also a good point, if any of the arguments are non-self-evaluating
fikka has quit [Ping timeout: 268 seconds]
python476 has quit [Ping timeout: 260 seconds]
<jasom>
hmm, what other than lists and symbols are non-self-evaluating in lisp
<jasom>
well conses and most symbols
<jasom>
*most non-keyword symbols
<Bike>
lists and symbols are the only non self evaluating things.
<jasom>
nil is both a symbol and a list and is self-evaluating
<Bike>
the only non self evaluating things are lists or symbols.
frgo has quit [Ping timeout: 256 seconds]
<jasom>
I couldn't think of any others, but it's good to know
<Bike>
i guess an implementation could define others, probably.
EvW1 has joined #lisp
<jasom>
though make-load-form could mess with that, right?
<Bike>
mess with what's self evaluating?
<jasom>
yeah
<Bike>
stuff with a load form is still self evaluating, it just has arbitrary effects at load time.
<Bike>
the load forms have arbitrary effects, rather
EvW has quit [Read error: Connection reset by peer]
attila_lendvai has quit [Read error: Connection reset by peer]
EvW1 is now known as EvW
attila_lendvai has joined #lisp
attila_lendvai has joined #lisp
attila_lendvai has quit [Changing host]
<jeosol>
Morning guys
<jeosol>
Need some help on condition system to make my code not blow up depending on input. I am calling a function (evaluation solution ..) which does a bunch of calculation steps. One of these steps could fail making the whole evaluation invalid
<jeosol>
and would stop the evaluation, and that error makes the whole run fail
<jeosol>
so I want to wrap this top function with conditions so if it fails, I assign some variables and move on.
<jeosol>
Based on what I read, I have to throw some error (could be same error type for simplicity) in the different steps and just invoke a predefined restart. Does this sound right
k-stz has quit [Remote host closed the connection]
<Bike>
So you have something like (loop for run in runs do (compute run)), and compute sometimes fails, but in that case you want to continue to the next run?
<jeosol>
More or less Bike, that is right. Sometimes, I ship the runs via parallel function, but let's discuss the serial case
<Bike>
alright, well for that you might not need restarts.
<|3b|>
yeah, sounds like you just need to catch the existing errors
<jeosol>
There are several other functions things might fail at and I can't instrument each sub function with conditions/restarts
<Bike>
sure.
<jeosol>
If I call the function, and error results because of some incompatability in parameters, I just given a high objective function value (disregard case) and move on to next
<|3b|>
restart would let you do things like change a value and continue a particular calculation (or configure how you wanted to handle errors at the top level if you have multiple options for that)
<Bike>
you probably want to use handler-case.
<jeosol>
yes |3b|, I have some other code using restart, but I was thinking there is a probably a simple way to do this
<jeosol>
I have something with handler-bind that invokes one of the automatic restarts for a simple test case.
frgo has joined #lisp
travv0 has quit [Ping timeout: 248 seconds]
fikka has joined #lisp
<jeosol>
I worked through the log file analyzer example in PCL and have a case that works for that example. I still have to consider instrumentation with parallel call.
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jeosol>
But that example, has a way to test if the entry is even valid. Then proceed with normal proceed or have a restart-case. There are two points of failure, with my CL code when processing the parameters, and then another black-box I call that could also fail
<jeosol>
even if the CL side executed fine. I just want to call everything one error and be done. Not much time to really instrument code and identify failure points and type.
<Bike>
you can just handle, like, 'error'
<Bike>
superclass of any error
attila_lendvai has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 255 seconds]
rpg has joined #lisp
whoman has joined #lisp
attila_lendvai has joined #lisp
attila_lendvai has quit [Changing host]
attila_lendvai has joined #lisp
<jeosol>
Bike: that sounds like it, I was thinking a different type of error that inherits for 'error'
<jeosol>
sorry guys if this not clear, haven't slept much later.
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #lisp
attila_lendvai has quit [Changing host]
attila_lendvai has joined #lisp
<jeosol>
It seems the idea is go near the potential failure points and throw the error, then wrap my function evaluation code with handler-bind where I specify one restart to invoke automatically.
<|3b|>
presumably the failure points already ERROR
<jeosol>
|3b|, I am wondering if have to do that
fikka has joined #lisp
<|3b|>
so if you just want to completely ignore a run, (handler-case (compute run) ((error (e) (format *error-io* "run ~s failed" run)))) or similar
<|3b|>
yeah, i usually just use ignore-errors rather than handler-case on ERROR
<|3b|>
just store the 2nd value so you can see what the error was in the output :)
<|3b|>
(but same with handler-case, don't just drop it there either)
<jeosol>
not sure if I explained correctly. If run is good F(X) = value from successful run, if bad, F(X) = 1e9. So what I do is initial F(X) variable to 1e9, and if call was sucessful, it will have the correct value.
moei has joined #lisp
<|3b|>
though if you have time to find specific expected failures, handling those specifically reduces chances of missing some typo and getting more failures than the input would normally cause on its own
<jeosol>
specbot and pierpa: I checked that link
<jeosol>
I think for now, ignore-errors is the quicker and easier solution
fikka has quit [Ping timeout: 255 seconds]
<jeosol>
|3b|: yes, I do plan a full instrumentation with condition system so as identify other recovery mechanisms,
Bike has quit [Ping timeout: 260 seconds]
<|3b|>
ignore-errors also could be useful for finding the errors you would want to eventually handle explicitly, if you store them and make a report at the end or whatever
fourier has quit [Ping timeout: 246 seconds]
<jeosol>
and better identify the failure points. But this option should really work.
sendai___ has joined #lisp
<jeosol>
|3b| makes a lot of sense.
<|3b|>
or handler-bind + something like trivial-backtrace
EvW has quit [Remote host closed the connection]
EvW has joined #lisp
<|3b|>
to find failure points in bulk rather than 1 at a time :)
travv0 has joined #lisp
fikka has joined #lisp
EvW has quit [Ping timeout: 276 seconds]
EvW has joined #lisp
kerrhau has joined #lisp
kerrhau has quit [Changing host]
kerrhau has joined #lisp
<rpg>
Fare added backtracing functionality to UIOP, because needed in ASDF.
<Shinmera>
Don't use trivial-backtrace, use Dissect!
<jeosol>
|3b| what do you mean by failure points. My evaluations are serial, so there should be one failure point. Or you mean it will keep track of callers
<jeosol>
Merci Shinmera/Colleen
<|3b|>
i mean ignore-errors/handler-case will just tell you what the errors were, not where they were signalled (which may be enough to find the problems, depending on the code)
nowhereman_ has joined #lisp
<|3b|>
handler-bind and dissect will let you store a stack trace at each error, so if it fails in different places with different inputs, you can find all of those at once
<jeosol>
|3b|, sure eventually I need to be able to identify there the errors are, so I will have to come up with some error hierarchy eventually.
<|3b|>
whether that is worth the extra effort or not depends on your worlkflow
fikka has joined #lisp
<jeosol>
|3b| that will be useful eventually.
<jeosol>
for me on the development side, but for users, I would use some automated option, e.g., handle the error smartly, repair solutions, etc
<jeosol>
guys, I am happy to say, I ran small test case twice, after wrapping my F(X) code within (ignore-errors ..) and both times it ran to completion.
nowhere_man has quit [Ping timeout: 260 seconds]
<drmeister>
What is a good documentation system for Common Lisp API's?
<Shinmera>
drmeister: You mean something that gathers symbols and docstrings and smashes them into a document?
<pierpa_>
IIRC
<pierpa_>
IRC
<drmeister>
Say I had a technical writer and I want to write documentation for functions and classes or an API?
<drmeister>
Then generate web pages, DESCRIBE strings, PDF files
random-nick has quit [Remote host closed the connection]
* jasom
thought pretty much everyone had written a build system.
<jasom>
Shinmera: isn't stable html output only?
<Shinmera>
Yes
asarch has quit [Quit: Leaving]
<jasom>
so you'd need to do html -> PDF for PDF documents
<Shinmera>
Sure.
sjl has quit [Ping timeout: 260 seconds]
<jasom>
which is "not terrible" with an appropriate style sheet
<jasom>
(fwiw staple was the winner of the "API Generator" category of sabra's review
<Shinmera>
Staple is also being continuously improved.
<Shinmera>
There's been a couple of major improvements over the last half year or so thanks to prompts by Baggers.
<Shinmera>
So I'm quite happy to work on it if people come up with problems or ideas.
Kundry_Wag has joined #lisp
<jasom>
declit is my "least non-favorite" of the "make a full manual" family
<rpg>
What I would most like to see is a tool like declit that lets you add structure by putting in arbitrary text (the stuff that tells users the big picture), and lets you rearrange entries to suit a structure that's not the same as the codes'
<jasom>
rpg: documentation-template does this IIRC
<jeosol>
jasom: two negatives ... meaning you don't like?
<rpg>
is that the one that is used by SBCL?
<jasom>
jeosol: right, it's the least bad
<jasom>
rpg: it's the one used by all ediware
<jasom>
jeosol: I don't like it, but it's better than others I've tried
<jeosol>
so I took a quick look at the sabraonthehill link and there is a comment about adding tutorial type material in Staple
<Shinmera>
Also, Sabra's page on the generators is outdated / inaccurate for Staple
<jeosol>
Oh I see, I would love to take a look at documentation systems. Didier's post a while ago about some library tool discussed about Declit
Kundry_Wag has quit [Ping timeout: 260 seconds]
shwouchk_ has joined #lisp
<jasom>
I have not used Staple, so it may be my new least non-favorite once I get the chance to try it :)
<Shinmera>
I'm not sure why Sabra has lots of "no"s in his table for things like author, license, etc. as those have always been outputted by Staple since day one.
<Shinmera>
Staple can also be used as a full manual generation. Which symbols are outputted can be configured.
<Shinmera>
I'm rethinking how to make the symbol selection process more easily customisable right now, so hopefully that'll be more convenient soon.
fikka has joined #lisp
varjag has quit [Ping timeout: 264 seconds]
<Shinmera>
Chapters for the symbols?
fikka has quit [Ping timeout: 264 seconds]
trocado has joined #lisp
<rpg>
Shinmera: Something like ASDF -- you could have a chapter for the object model, a chapter for plan-building, etc. It would be conceptually organized.
Bike has joined #lisp
<rpg>
sorry -- I meant, imagine you were documenting a system like ASDF.
<rpg>
so you might have a chapter on using it, on configuring it, on extending it, etc.
<Shinmera>
Well, the cop-out answer is that you can do anything (rainbows) since you can write your own template. To answer your question otherwise, the main "documentation body" is parsed from another file -- typically the README.md, so whatever structure you put in there is output into the resulting HTML. If you want to chop up the symbol indexes and intermix them with your main documentation body then that's currently
<Shinmera>
It does some minor stuff like primitively analysing <code> segments in the resulting body to try and provide cross-references, but the main documentation text is largely left untouched.
<Shinmera>
It could do more, I suppose, if I had a good idea about what people want it to do for that.
<SAL9000>
Shinmera: In regards to staple's analysis of "See XYZ" -- any particular reason that you're ignoring cross-package See links? In other words, I'm extending/wrapping another package - I want to cross-reference it's docs (in staple-browser).
<Shinmera>
Staple-browser is just a small hack that invokes staple directly. For staple "usually", it has no way of knowing where the documentation for another project lives, so it can't make a link to it.
<SAL9000>
ah. I've been pretty much treating staple as a doc-browser more than an doc-generator. :)
<Shinmera>
Well, good to hear it's being used!
<Shinmera>
That behaviour could definitely be improved though. Providing a way to let staple know how to resolve cross references would be good.
* Shinmera
makes a note
<SAL9000>
FWIW, it *does* put an <a> element in, but foo:bar makes a bogus #link and foo::bar makes a link to a nonexistent file (iirc it'd make a link to ./bar)
<SAL9000>
this is all in staple-browser
<Shinmera>
Hrm.
<Shinmera>
Is this on latest?
<SAL9000>
whatever's in quicklisp
<SAL9000>
can re-test with latest though
<Shinmera>
Please do. I don't remember if I did fix something like that recently or not.