kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
jdw4000 has quit [Quit: Leaving]
<no-defun-allowed>
finalisers?
<no-defun-allowed>
i guess that needs a full gc though
LdBeth has joined #lisp
<LdBeth>
good afternoon
eddof13 has quit [Quit: eddof13]
fikka has joined #lisp
<no-defun-allowed>
afternoon LdBeth
fikka has quit [Ping timeout: 260 seconds]
pillton has joined #lisp
pierpa has joined #lisp
benjamin-l has joined #lisp
Kaisyu has joined #lisp
astronavt has joined #lisp
astronavt has quit [Remote host closed the connection]
fikka has joined #lisp
smokeink has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 240 seconds]
smokeink has joined #lisp
elfmacs has joined #lisp
Kundry_Wag has joined #lisp
fikka has joined #lisp
broccolistem has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
k-hos has quit [Read error: Connection reset by peer]
k-hos has joined #lisp
fikka has joined #lisp
jcowan has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
<jcowan>
Zipf's Law (or one of them) tells us that high-frequency words tend to be short, so in a planned language like a programming language you should (all else being equal) assign short names to commonly used functions.
broccolistem has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
broccolistem has joined #lisp
broccolistem has quit [Client Quit]
fikka has joined #lisp
<LdBeth>
of course, + - / * car cdr eq cons cond are all no more than 4 char
fikka has quit [Ping timeout: 272 seconds]
frgo has quit [Read error: Connection reset by peer]
frgo has joined #lisp
asarch has quit [Quit: Leaving]
skeleton2 is now known as saturn2
robotoad has quit [Quit: robotoad]
epr0xe has joined #lisp
quazimodo has joined #lisp
Oladon has joined #lisp
shifty has quit [Ping timeout: 245 seconds]
robotoad has joined #lisp
on_ion has quit [Ping timeout: 252 seconds]
on_ion has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 246 seconds]
esrse has joined #lisp
Bike has quit [Quit: Lost terminal]
Roy_Fokker has quit [Read error: Connection reset by peer]
igemnace has quit [Quit: WeeChat 2.3]
cylb has joined #lisp
quazimodo has quit [Ping timeout: 244 seconds]
cylb has quit [Ping timeout: 268 seconds]
ryan_vw has joined #lisp
Kundry_Wag has joined #lisp
robotoad has quit [Quit: robotoad]
robotoad has joined #lisp
<no-defun-allowed>
let, defun, defvar, equal, and others are good and short without being incomprehensible
rumbler31 has joined #lisp
smasta has quit [Quit: WeeChat 2.2]
wanz has joined #lisp
<no-defun-allowed>
cgay (IRC): (get 'git 'gud)
elfmacs has quit [Ping timeout: 252 seconds]
robotoad has quit [Quit: robotoad]
robotoad has joined #lisp
Kundry_Wag has quit [Ping timeout: 244 seconds]
Xach has quit [Ping timeout: 252 seconds]
Xach has joined #lisp
Lycurgus has quit [Quit: Exeunt]
shifty has joined #lisp
Sauvin has joined #lisp
Xach has quit [Ping timeout: 252 seconds]
<White_Flame>
of course, there's also the legacy of short names to save precious memory back in the bad old days
Xach has joined #lisp
pierpa has quit [Quit: Page closed]
Xach has quit [Ping timeout: 268 seconds]
<beach>
Good morning everyone!
robotoad has quit [Quit: robotoad]
nanoz has joined #lisp
robotoad has joined #lisp
ryan_vw has quit [Ping timeout: 250 seconds]
travv0 has quit [Quit: Connection closed for inactivity]
Xach has joined #lisp
<emaczen>
good morning beach
azimut_ has joined #lisp
azimut has quit [Ping timeout: 246 seconds]
parjanya has quit [Remote host closed the connection]
fikka has joined #lisp
rumbler31 has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 246 seconds]
epr0xe has quit [Quit: epr0xe]
Kundry_Wag has joined #lisp
Oladon has quit [Quit: Leaving.]
nanozz has joined #lisp
MichaelRaskin has quit [Quit: MichaelRaskin]
nanoz has quit [Ping timeout: 268 seconds]
elderK has joined #lisp
igemnace has joined #lisp
<no-defun-allowed>
how should i handle the results of bordeaux-fft?
<no-defun-allowed>
so far it seems the values are #c(period/2 intensity) or something similar but i've never worked with just fft
<beach>
Yes, the result of an FFT is a vector of complex values.
<beach>
The absolute value is the amplitude, and the angle is the phase.
<no-defun-allowed>
i see
<beach>
So if you only want the amplitude of each frequency, take the absolute value.
<no-defun-allowed>
gotcha.
<no-defun-allowed>
how do i know which frequency each value is then?
<beach>
It is determined by the size of the window in the time domain and of the sampling frequency.
<no-defun-allowed>
right then
<aeth>
no-defun-allowed, LdBeth, jcowan: I don't know. Not all the names in the standard are good examples (ignoring obviously bad like rplaca). Even when short, I'd prefer hyphens, e.g. do-list is better than dolist. Obviously, that can't be fixed without breaking compatibility (which won't happen), but you shouldn't have hyphenless multi-word symbols in your API even if you're supposed to be using it literally every line imo.
<aeth>
You can easily learn the wrong lesson and even remove hyphens for common function/macro names. I think Clojure does this.
skeuomorf has joined #lisp
skeuomorf has left #lisp [#lisp]
<no-defun-allowed>
clojure's just being weird i suppose
<beach>
no-defun-allowed: Did you see the formula?
<no-defun-allowed>
yes i did
<beach>
OK, good.
<aeth>
no-defun-allowed: Clojure takes the whole "common things should be short" thing too far, just like Arc. Afaik, CL's common things being short is accidental, from its backwards compatibility. Lots of uncommon things are also short, e.g. GET and SET.
elfmacs has joined #lisp
<no-defun-allowed>
oh right, so frequency bins are evenly distributed from 0 to my sample rate. thanks beach
<beach>
Exactly.
<no-defun-allowed>
i don't mind my code being long if it has descriptive names in it.
<no-defun-allowed>
then again, CL isn't innocent, with stuff like fmakunbound which requires saying out loud to comprehend, but i never found shortening useful
<aeth>
I think the way names in APIs should be written is... keep them reasonable. Can they fit on a line in common usage? So if it's something that's supposed to go on its own like like define-foo it could be very long. If it's something that's supposed to be used for arithmetic like + you're probably very limited.
<aeth>
But between those two extremes you can still have names that are longer than you think.
<aeth>
(Just shorter than Java people think.)
<aeth>
Although, actually, not having dot syntax means longer names aren't as awkward as in Java. Also not using camelCase.
dieggsy has joined #lisp
<luis>
The other day I learned that this-is-called-kebab-case.
<aeth>
yes
<aeth>
and it makes long symbols okay to write if you're a touch-typist, for the most part.
<aeth>
Things I'd make short are things like foo-ref or foo-+ (arithmetic can look weird when you use kebab-case, especially foo-- for foo's version of subtraction)
<no-defun-allowed>
also i object to having these in my lisp: [][][][]
igemnace has quit [Quit: WeeChat 2.3]
Kundry_Wag has quit [Ping timeout: 268 seconds]
<luis>
I use this·naming·convention·at·work which was very weird at first and now I almost like it.
<no-defun-allowed>
i already swapped () and [] in emacs, please don't make me reach for shift-9 and shift-0
<aeth>
no-defun-allowed: The concept of [] could be interesting. Well, as some languages interpret []. It would basically be gethash + aref + elt and maybe a few others.
<no-defun-allowed>
would foo(nbsp)bar work, where (nbsp) is a non-breaking space?
jcowan has quit [Quit: Connection closed for inactivity]
<no-defun-allowed>
eeh, that's a lot to cover with one operator
<luis>
no-defun-allowed: out of curiosity, just checked that SBCL quotes those names when printing (symbolicate "FOO" #\NO-BREAK_SPACE "BAR") => |FOO BAR| but it's fine (FSVO of fine) to read them unquoted 'FOO BAR => |FOO BAR|
<no-defun-allowed>
nice
CrazyEddy has quit [Ping timeout: 245 seconds]
<luis>
Emacs actually renders #\NO-BREAK_SPACE as an underscore though, but there's plenty of sneaky spaces to choose from: http://jkorpela.fi/chars/spaces.html
skeuomorf has joined #lisp
skeuomorf has left #lisp [#lisp]
robotoad has quit [Quit: robotoad]
Kundry_Wag has joined #lisp
esrse has quit [Ping timeout: 272 seconds]
<emaczen>
I have a call stack backtrace and I have an address
<emaczen>
Is there any way to go from the address to a function name?
<emaczen>
It is probably implementation specific...
<beach>
Yes, there are no addresses in Common Lisp.
fikka has joined #lisp
angavrilov has joined #lisp
fikka has quit [Ping timeout: 246 seconds]
<beach>
... and of course, not all functions have names.
<jmercouris>
hi everyone, I know this isn't a strictly Lisp related statement, but Next will be finishing its fundraising round in 2 days, so if anyone is interested in helping support the project I would be grateful, thanks for your time (https://www.indiegogo.com/projects/next-browser-nix-support/)
<flip214>
luis: sjl: I've thought a bit more about how symbols might be encoded in JSON or msgpack.
<flip214>
The best I can come up is as readable strings - like ":KEYWORD" and "CL:CAR".
<flip214>
If there's a colon in a symbol, we'd get "PACKAGE:|SYMBOL:YEAH|", which we _could_ compare, but won't need to, as the swank protocol doesn't use such symbols.
<flip214>
how about that?
epr0xe has joined #lisp
Zaab1t has joined #lisp
astalla has joined #lisp
hhdave has quit [Ping timeout: 272 seconds]
Lycurgus has joined #lisp
DGASAU has quit [Ping timeout: 264 seconds]
Lycurgus has quit [Quit: Exeunt]
hhdave has joined #lisp
Lycurgus has joined #lisp
<luis>
flip214: yeah, that's what I was trying to convey, I think. Sounds good.
<flip214>
luis: ack.
doubledup has quit [Ping timeout: 268 seconds]
<luis>
flip214: Printing symbols readably is definitely a clear and precise way to put it. I don't think you have to use uppercase though.
<phoe>
luis: depends on the readtable-case of the reader
<phoe>
s/reader/reading party/
<luis>
phoe: no worries, we fully control the reader settings in this case.
<luis>
(pun unintended)
rumbler31 has joined #lisp
loli has quit [Ping timeout: 246 seconds]
Kundry_Wag has joined #lisp
beach has quit [Ping timeout: 252 seconds]
varjag has joined #lisp
rumbler31 has quit [Ping timeout: 240 seconds]
beach has joined #lisp
fikka has joined #lisp
jmercouris has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 264 seconds]
<phoe>
then one worry less for you
epr0xe has quit [Ping timeout: 246 seconds]
<flip214>
luis: well, using uppercase might be the least-surprising way
<phoe>
(except slime sends them lowercase, AFAIK)
<phoe>
hm, now that I think of it, slime sends input in whatever case the user typed it in
<phoe>
and sends output in whatever case Lisp printed it
anewuser has quit [Ping timeout: 272 seconds]
<luis>
phoe: we're discussing certain symbols that SWANK sends in its sexp-based message format not user input/output.
nanozz has quit [Ping timeout: 245 seconds]
<phoe>
luis: got it, thanks.
<luis>
flip214: I would argue the opposite. They show up as lower case in the *slime-events* buffer. Elisp's reader is case-sensitive so I'm guessing that SWANK is writing them in lower case.
Kundry_Wag has quit [Ping timeout: 252 seconds]
anewuser has joined #lisp
loli has joined #lisp
CrazyEddy has joined #lisp
Zaab1t has quit [Quit: bye bye friends]
skeuomorf has joined #lisp
rumbler31 has joined #lisp
Bike has joined #lisp
rumbler31 has quit [Ping timeout: 252 seconds]
wanz has joined #lisp
skeuomorf has quit [Ping timeout: 272 seconds]
ebzzry has joined #lisp
loli has quit [Ping timeout: 260 seconds]
nanoz has joined #lisp
foom2 has joined #lisp
foom has quit [Ping timeout: 250 seconds]
loli has joined #lisp
m00natic has joined #lisp
jcowan has joined #lisp
Spooktober has quit [Quit: Spooktober is over.]
grumble has joined #lisp
xrash has quit [Ping timeout: 260 seconds]
loli has quit [Ping timeout: 268 seconds]
<flip214>
luis: well, the CL- *internal* convention is uppercase. So stick a (with-standard-io-syntax) around the JSON printer, and we have some sane convention.
<flip214>
furthermore, having ":KEYWORD" would make them stand out in the vim script sources, which might be a good idea.
wanz has quit [Quit: wanz]
scymtym has quit [Ping timeout: 252 seconds]
DGASAU has joined #lisp
loli has joined #lisp
cylb has joined #lisp
Kundry_Wag has joined #lisp
Bike is now known as Bicyclidine
deng_cn has quit [Remote host closed the connection]
deng_cn has joined #lisp
loli has quit [Ping timeout: 252 seconds]
anewuser has quit [Ping timeout: 268 seconds]
nanoz has quit [Ping timeout: 272 seconds]
wanz has joined #lisp
nly has joined #lisp
loli has joined #lisp
steiner has joined #lisp
rumbler31 has joined #lisp
Kundry_Wag has quit [Ping timeout: 245 seconds]
rumbler31 has quit [Ping timeout: 268 seconds]
loli has quit [Ping timeout: 252 seconds]
loli has joined #lisp
steiner has quit [Quit: ERC (IRC client for Emacs 26.1)]
<luis>
flip214: 👌
DGASAU has quit [Ping timeout: 250 seconds]
loli has quit [Ping timeout: 244 seconds]
loli has joined #lisp
nicksmaddog has joined #lisp
<beach>
luis: Careful. That gesture does not have a universal interpretation.
<sjl>
flip214: it doesn't ever send strings either?
<jdz>
A hack is a hack, but probably better than the rectangles with hex codes...
<jdz>
Haha, and of course the hack does not work at good screen resolutions...
rumbler31 has joined #lisp
broccolistem has joined #lisp
frodef has quit [Ping timeout: 246 seconds]
rumbler31 has quit [Ping timeout: 244 seconds]
<flip214>
sjl: yes, it does. for example, the *package* an expression should be evaluated "in" is sent as string. but I don't follow you right now, what's the issue?
lnostdal has joined #lisp
<luis>
beach: splittist: heh. I meant to use the sign the same way divers use it! :-)
<jcowan>
To me, a "good" screen resolution is one which lets me see things, so I live in a world of 175% magnification
<flip214>
luis: that's how I would have understood it, anyway.
frodef has joined #lisp
<flip214>
jcowan: the new hi-res notebook screens are awful, yeah.
<beach>
flip214: In what way?
sjl has quit [Quit: WeeChat 2.2-dev]
<jcowan>
They make everything much too small until you magnify, and not all things support magnification.
<flip214>
beach: too many pixels. and the DPI setting can't easily be different between two screens at the same time (notebook, external monitor), and so on.
sjl has joined #lisp
<jcowan>
My wife still plays a lot of MS-DOS solitaire games. DOSBOX lets me support them on Windows, but I can do little about the fact that the cards are tiny.
<jdz>
flip214: it can be different, except when using Linux.
<flip214>
jdz: yeah, thanks. need some more salt? ;)
<sjl>
flip214: I assume you're translating strings to vimscript strings as well. So wouldn't the lisp symbol FOO and the lisp string "FOO" both end up as the vim string "FOO"?
<jdz>
I also totally love my 270DPI laptop screen.
<sjl>
ugh, brb, vpn. I really need to set up an IRC bouncer some day.
<hjudt>
as for support for other dev envs: it was easy to add support because the required slime/sly packages are in quicklisp. that way, one does not have to inject the files manually into the container.
<jdz>
I have two high-res displays, with wildly different DPI values (157 and 276), and different sub-pixel led structures (RGB and VBGR). I'm not expecting a seamless configuration from Linux any time soon.
DGASAU has quit [Read error: Connection reset by peer]
<hjudt>
also, the way to create slynk and swank servers is _very_ similar, as you can see in the install.lisp.
<hjudt>
that said, i guess it would not be hard to support other dev environments too.
DGASAU has joined #lisp
<hjudt>
till now, i didn't know about anything else except slime and sly, and i am mainly an emacs user where it is available.
jtecca has joined #lisp
dale has quit [Quit: dale]
elfmacs has quit [Ping timeout: 250 seconds]
dale has joined #lisp
<shka_>
what will happen when calling slot-definition-initarg on slot that lacks initarg?
<shka_>
error?
<Bike>
mop slot-definition-initarg
<specbot>
Couldn't find anything for slot-definition-initarg.
<Bike>
so it returns nil if there are no initargs.
<shka_>
oh
<shka_>
that makes sense
<shka_>
Bike: thanks!
<Bike>
no problem.
<shka_>
but, i have other question
<shka_>
how CLOS resolves situation when slot has two initargs and BOTH has been supplied?
<Bike>
it works like it does for any keyword
<Bike>
if you have (lambda (&key a) ...)
<Bike>
and pass it :a 7 :a 9
<Bike>
it takes the leftmost
<jdz>
That's why plists are cool.
<Bike>
if :a and :b are both keywords for the same slot, it will just take the leftmost
froggey has quit [Ping timeout: 252 seconds]
<shka_>
ok, that makes sense to me
<shka_>
thanks
<jdz>
Thus overriding an initarg (any keyward argument) is just a matter of consing it in front of &rest args.
<jdz>
And searching a value is just a matter of finding the first occurrence.
froggey has joined #lisp
Essadon has joined #lisp
beach has quit [Ping timeout: 252 seconds]
robotoad has joined #lisp
jtecca has quit [Remote host closed the connection]
beach has joined #lisp
<jcowan>
I'm surprised it's the first occurrence rather than the last
<dlowe>
it allows you to override plists with shared structure
<dlowe>
very easily
johnjay has joined #lisp
<Bike>
jcowan: so that you can (apply function :x y other-keywords)
<jcowan>
Yes, I see the logic of it, I'm just surprised that the original implementation didn't use straightforward last-man-standing-wins processing
<jcowan>
since all keywords have to be checked to make sure there are no bad ones (modulo &allow-other-keywords)
<jcowan>
s/checked/& at run time
<jdz>
Bad ones?
<jcowan>
Keywords not appearing in the lambda-list
wanz has quit [Quit: wanz]
<jdz>
Checking is orthogonal to using the value.
rippa has joined #lisp
<jdz>
Also, if you did not know, you can pass :allow-other-keys t any time :)
<jcowan>
I did not know that
<jdz>
A weird feature until you need it.
<jcowan>
So many Lisps, so little time
smokeink has quit [Remote host closed the connection]
<beach>
jcowan: Nah, this channels limits it to a single one.
robotoad has quit [Quit: robotoad]
wanz has joined #lisp
<jcowan>
And yet I seem to be a tolerated outsider these days
<jcowan>
even though I haven't written CL since 1995 or so
<Lucretia>
hi, going through "land of lisp," I've got to cons in the book. I don't understand why (cons 'chicken 'cat) gives "(CHICKEN . CAT)" and (cons 'beef (cons 'chicken nil)) doesn have the dots, is there a reason?
pflanze has joined #lisp
<phoe>
Lucretia: yep, there is a reason for that
<phoe>
basically, conses are printed either as conses, or as lists
<Lucretia>
ahh
<phoe>
(1 2 3) is a list, (1 . 2) is a cons
<phoe>
(1 2 3 4 . 5) is an improper list, where the last cons does not end with a NIL
<phoe>
therefore it is printed with a dot.
<phoe>
therefore a cons whose last element is not NIL is a special case of an improper list
<phoe>
so it's printed with a dot
<phoe>
(cons 1 2) ;=> (1 . 2)
<phoe>
(cons 1 (cons 2 (cons 3 nil))) ;=> (1 2 3)
<pflanze>
I'm a Schemer, not CL'er. How would you translate this Scheme code to CL?: (let ((* +)) (* 10 10))
<pflanze>
I can't get flet to work because of package locks, and am not even sure it's the right form.
<Lucretia>
phoe: so would sbcl return (1 2 3 4 . 5) at all?
<beach>
pflanze: You are not allowed to redefine Common Lisp standard function names in FLET.
<beach>
pflanze: This is to protect you from macros that might do that, with very strange consequences as a result.
<luis>
pflanze: you can define a package where * is not cl:*
<pflanze>
What if I want to write a macro that actually legitimately does want to shadow * ?
<pflanze>
(with-unlocked-packages (COMMON-LISP) (flet ((* (a b) (+ a b))) (* 10 10)))
<phoe>
that's undefined behavior
<pflanze>
That's not right, I don't get the &rest and &body specification in the standard.
<phoe>
unless * is shadowed
<phoe>
Lucretia: sure
<phoe>
(list* 1 2 3 4 5) ;=> (1 2 3 4 . 5)
<phoe>
that's one way to make an improper list
<sjl>
You use a * that's a different symbol than the one in the CL package, and users of the macro make sure to refer to your-package:* either by typing it out or by shadowing importing it.
<luis>
pflanze: the macro /could/ replace * with something else in its body, but it wouldn't be a great idea.
<Lucretia>
phoe: thanks
<pflanze>
That won't do, I guess I'll have to learn the package system: (flet ((my:* #'+)) (my:* 10 10))
<sjl>
But if you're a good human: you pick a different glyph that doesn't already have a definition in the language like * does, to avoid confusing users of the macro.
<phoe>
pflanze: learning the package system is a good investment
<sjl>
(flet ((% (a b) (+ a b))) (% a b))
<sjl>
er, (% 10 10) at the end.
<sjl>
or (flet ((*_ (a b) (+ a b))) (*_ 10 12)) if you're really attached to the asterisk
<sjl>
(unfortunately ' is used for quoting, so you can't use it as a mathematician would use "prime", like: (defun *' ...))
wanz has quit [Quit: wanz]
<beach>
Bah, just change the readtable.
<sjl>
I wonder how portable (defun *′ (a b) (+ a b)) is
<sjl>
sbcl and ccl both allow it
<varjag>
maybe there's unicode asterisk homonym out there
<varjag>
..or an emoji
<phoe>
*' ?
<varjag>
starfish?
<phoe>
sjl: that is not read that way
<phoe>
the reader treats this as (defun * '(a b) (+ a b))
<beach>
×
<phoe>
encountering a terminating macro character finishes reading of the current token
<phoe>
and SBCL errors on (defun *' (a b) (+ a b))
<beach>
That's the unicode multiplication sign.
<phoe>
(read-from-string "(defun *' (a b) (+ a b))") ;=> (DEFUN * (QUOTE (A B)) (+ A B))
<jcowan>
pflanze: Since rebinding names has only lexical scope (in CL as in Scheme), there is no reason to use + * except readability (or unreadability); you can use plus and times, or whatever.
<pflanze>
Sadly I never got around to really learning CL.
<pflanze>
I'd welcome comments on my comment
<anamorphic>
Is it possible to create a C callback from a Lisp function at runtime? I looked at CFFI, but they're macros. Hoping to do something like (make-trigger :callback #'(lambda (a b) ...)) where inside make-trigger, it would create the C level function address and call some cffi:defcfun'd C function with the callback address it just produced
astalla has joined #lisp
<jcowan>
pflanze: The term you are looking for in your last sentence is "parser".
<pflanze>
Well that's the term I originally used (if you follow up the parent chain), thus fine.
<pflanze>
Actually what I'm saying is that read doesn't parse all the way.
<jcowan>
BTW, Racket's parse does rewrite function applications like (+ 3 4) as (#%app + 3 4) to make further stages easier
<pflanze>
Yes that's the distinction between parsing and reading that I'm trying to make in my comments.
<beach>
shka_: It is considered the same slot in that case.
<sjl>
There are two separate issues with trying to differentiate (+ (flet ((* #'+)) (* x 2)) 12)
<sjl>
aside from the obvious broken syntax
<sjl>
1. Handling FLET
<sjl>
2. Handling a case where someone has rebound * to mean something else
<sjl>
case 2 can't happen in Common Lisp because of the rules about messing with symbols in the CL package
<pflanze>
Yes, I mention all of that (a bit messy since I re-edited the comment multiple times)
<sjl>
If you see the symbol CL:* you know it means multiplication, no matter what.
<jcowan>
It can't happen (or rather, doesn't matter) in Scheme anyway because the binding of flet (which is just let for us) is lexically scoped, so there is no confusion.
<sjl>
> except I'm told that you can define them in a new package then import them, but then I'm not sure you can rebind them lexically
<anamorphic>
phoe, OK I'll look at get-callback again
<pflanze>
jcowan, what do you mean? I'm coming from Scheme.
<White_Flame>
just consider a DSL or library function instead of a CL: symbol. the package locking of CL isn't a major point here, IMO
<jcowan>
I mean that which *assigning* a new definition to * would indeed be dangerous, binding it in a lexical scope really can't be
<pflanze>
sjl, what I was thinking of doing is (defpackage :foo ....) (in-package :foo) (defun * (a b) ..) then import foo:* and shadow that with flet.
<sjl>
If you define a symbol * in another package, and then import it, it's an entirely separate symbol. It just happens to have a confusingly similar name to one in CL, but otherwise it's just some other arbitrary symbol.
<jcowan>
(modulo non-hygienic macros, which IMO are the real reason for making CL: symbols immutable)
Ukari has joined #lisp
<jcowan>
s/immutable/& and unbindable
<pflanze>
jcowan, the point I'm trying to make in my original comment was that, if you want to allow general Lisp (well, Scheme, for me) then a code walker has to maintain a lexical context to know that * has been bound to +, before concluding what the derivative is.
<sjl>
When your differentiator looks at your-package:* and asks "is this thing I'm looking at the symbol cl:*?" it'll say "nope".
<White_Flame>
really, this particular issue is about code generation. If you're generating code, and the outer context reassigns things that the generator uses, that's an override that can/should function properly
<pflanze>
This is about the claimed simplicity in implementing derivation. What I want to point out is that, yes, it's simple, iff you ignore any context-sensitivity in the s-expressions.
<sjl>
* and + is orthogonal to handling flet.
<pflanze>
sjl, good point, fair enough.
<sjl>
If you want to differentiate (flet ((foo (a b) (+ a b)) (foo 1 2)) you need that support too
<pflanze>
Still, this only holds for those CL built-ins.
<pflanze>
I'm trying to make a comment that's true in general but doesn't for this special case, bummer.
<pflanze>
sjl, yes that's perhaps a better example.
<TMA>
jcowan: I think that another reason is that the immutability and unbindability allows the compiler know certain facts about code that would be really hard (halting-problem hard) to infer from the code alone
<White_Flame>
also, the deriv example is for mathematical Lisp expressions, not general computational ones
<sjl>
But all those '+ and '* cases in there are safe and wouldn't need to check for rebindings, because you KNOW they can never be rebound
<pflanze>
White_Flame, yes, note that I said you can get away with it *iff* you're happy to restrict it to that.
<jcowan>
TMA: Mutability I grant, bindability I deny. If you bind * to an unknown function, the compiler locally ignores what it knows about global *. If you bind it to the definition of +, the compiler can apply what it knows about + to the lexically apparent occurrences of *
astalla has quit [Ping timeout: 245 seconds]
<White_Flame>
pflanze: without that restriction, it's an unresolvable halting-problem-esque static analysis problem
<jcowan>
Yes, if you are working with only a subset of Lisp code that excludes flet, then fine.
<stylewarning>
jcowan: are you an avid Common Lisper now?
<jcowan>
I grant that Lisp code without limitations is a problem for such analyzers, but the mere appearance of flet/let doesn't actually make their lives much harder, certainly not halting-hard.
<pflanze>
White_Flame, no, you could allow bindings, local functions etc. and have the code walker deal with those, as long as all the primitives are mathematically derivable.
<White_Flame>
which still leaves you in a restricted, math-only (plus visible math functions) subset
<jcowan>
They could be removed in a single pass, assuming that all the operators are pure and function (certainly the case for a symbolic differentiator)
<White_Flame>
you're just moving the goalposts slightly
<pflanze>
White_Flame, which is an orthogonal issue.
<stylewarning>
this sounds like a symbolic math discussion]
<jcowan>
Our point is that rebinding known symbols is not a serious cost increase
<White_Flame>
this deriv operation requires full understanding of the code it's calculating the symbolic derivative of. So the full vocabulary is enumerated in the implementation, and bounds what it can do
<White_Flame>
regardless of if that includes flet or not
<jcowan>
Sure
<pflanze>
White_Flame, see my first comment, the point I'm making is that, the walker presented deals with a context insensitive language. *That* is why it's simple. It's not a property inherent to lisp.
<White_Flame>
jcowan: I'm mostly responding to pflanze's "you can get away with it *iff* you're happy to restrict it to that."
<pflanze>
And it's not even a property inherent to mathematical expressions, either.
<White_Flame>
there's always gonig to be a very hard restriction on the input vocabulary
<stylewarning>
Are we forgetting that derivatives require differentiable functions as input? (:
<pflanze>
So what I want to do is move the goal post to include lexical context dependence. That's the difference I want to talk about.
<White_Flame>
the property inherent to Lisp is the for-free expression representation and syntactically simple composability
<stylewarning>
How are we to compute whether a function is differentiable statically? (:
* jcowan
thinks local functions would have to be restricted to avoid recursion, though
<stylewarning>
You would need to solve the zero-equivalence problem, which is undecidable.
<White_Flame>
any language can do it if you implement all your custom AST nodes or whatever. Lisp can do it with no resistance
<pflanze>
Because that then shows something that people otherwise naively would think is an inherent property of all of lisp, which it isn't.
<pflanze>
*shows something that contests
<stylewarning>
pflanze: Being able to compute symbolic derivatives in Lisp, at any level of complexity, plays to Lisp's strengths, which are inherent to Lisp.
<jcowan>
stylewarning: It has to refer only to known functions and it can't involve recursive functions or macros
<White_Flame>
the complexity of implementing local functions is going to be the same regardless of language. Lisp allows the code syntax itself ot be data, which is the advantage
<stylewarning>
You can compute the derivative of a Python program represented as a string in Python, but it will be inane and cumbersome, because Python's strengths don't align well to the task.
<pflanze>
stylewarning, Except you have to deny half of lisp, which is the point I want to make.
<stylewarning>
pflanze: What does that mean, "deny half of Lisp"?
<stylewarning>
Half of Lisp are functions like DRIBBLE and TERPRI.
<stylewarning>
I'm OK to ignore those for computing derivatives.
<pflanze>
Function definitions, first class functions.
<stylewarning>
Why should I ignore those?
<pflanze>
If the walker can't deal with functions or local redefinitions, then it ignores those, that's what Im saying.
<White_Flame>
you could consider all programming constructs to be mathematically representable, therefore in the scope of this, therefore requiring full static understanding of any program in order to meet your requirements
<stylewarning>
pflanze: this is a flimsy argument and shows me you're not actually interested in computing derivatives, but language lawyering. DEFSTRUCT also doesn't allow redefinition, but I wouldn't consider it a broken feature of Lisp
<White_Flame>
(and I botched editing that...)
<pflanze>
I'm not saying anything is broken about lisp??
<pflanze>
Please read my commentws.
<stylewarning>
pflanze: "you have to ignore", etc.
<stylewarning>
I am reading them. Most people computing derivatives are computing derivatives of mathematical functions, not arbitrary expressions from the bowels of third-party libraries.
<White_Flame>
1) you need extra parsing to know exactly what a var means in a lexical context
<White_Flame>
2) symbolic mathematical derivation such as this will necessarily be restricted to a subset of operations that it understands
<White_Flame>
that subset may or may not get into the realm of 1)
<White_Flame>
and the complexity of implementation, once you have a representation to work with, is the same regardless of language
<White_Flame>
Lisp just gives you an easy, automatic representation
<White_Flame>
and that was the major point of the original blog post
<pflanze>
Which I'm not contesting. Iff restricting to the context free subset.
<White_Flame>
specifically, JS can do anything Lisp does here. It just needs to come from & go to strings at the endpoints
<White_Flame>
adding context-aware is not language specific
nly has quit [Ping timeout: 244 seconds]
<White_Flame>
it's AST analysis and transforms
hiroaki has joined #lisp
<White_Flame>
if there are location function foo() in JS, or (flet ((foo ..)) ..) in Lisp, it's the same problem
<pflanze>
So what am I conflating in the comment?
nly has joined #lisp
<pflanze>
I don't see that I'm conflating anything since I point out the differences, I thought.
<White_Flame>
I found your HN comments generally agreeable. But here you seem to be saying that implementing FLET is unique to Lisp.
<pflanze>
No, of course it's not. I should make the example in Scheme maybe.
<White_Flame>
most languages can shadow symbols at some level
<pflanze>
Yes
<White_Flame>
and increasing the scope of what deriv handles is not language specific
<pflanze>
Yes. (I didn't say anything else?)
<White_Flame>
"I try to explain a detail to people so that it is not missed." I believe people already understand the above points. If you're overexplaining those, they can bikeshed wrong
<xkapastel>
pflanze: fwiw i think your point is solid, symbolic expressions aren't actually ASTs
<xkapastel>
if you really want to do the example of derivatives well you need the whole AST
<pflanze>
Yes for Scheme, for CL it's incidentally working better since the math operators can't be shadowed.
<sjl>
The main points here seem to be 1. Differentiating can be nontrivial in Lisp if you want to support things beyond the basic mathematical operators, like FLET. 2. Differentiating in Lisp is still much easier than in most other languages.
<sjl>
That's basically it?
<pflanze>
Yup, that's what I wanted to say in my HN comments.
<pflanze>
Nontrivial just meaning that the code walker has to maintain a lexical context.
<pflanze>
(And, more support for the derivative logic, to support e.g. inlining functions)
<sjl>
Sure, and know how to walk/process arglists, etc etc. Some value of "nontrivial".
scymtym has joined #lisp
<pflanze>
Yes.
<pflanze>
Is there some standard infrastructure for walking Common Lisp code?
<xkapastel>
there's another way to do it without walking
<xkapastel>
the math operators would use e.g. delimited continuations to just compute the derivative themselves
<White_Flame>
if I were to implement such a hypothetical thing, I would seek to transform all the functions to inline, instead of caring about deriving them separately
<pflanze>
xkapastel, interesting, I have to look at that. There's also an approach that "mis-uses(?)" complex numbers and operator overloading, it's used in Julia.
<xkapastel>
using complex numbers as dual numbers?
<sjl>
There are a few code walkers out there, e.g. the hu.dwim one. But some libraries (e.g. iterate) just implement their own.
<xkapastel>
julia probably has all of these techniques implemented
<xkapastel>
i really like that language
<xkapastel>
shame it doesn't have enough parens :)
<jcowan>
Python in particular does have a standard AST representation, though obvs not as simple as Lisp's.
<stylewarning>
pflanze: I read your comment. I agree that people take the idea "Lisp is natively an AST" or "Lisp doesn't require parsing" too far, far enough to not be strictly true.
<White_Flame>
technically, it is a _syntax_ tree, not a _semantic_ tree
<sjl>
xkapastel: julia --lisp
<pflanze>
Sounds like good terms.
<sjl>
(+ 1 2)
<sjl>
3
<sjl>
There you go, bud.
<pflanze>
sjl, that's just an implementation detail there, it's got no interoperation with Julia.
epr0xe has joined #lisp
<sjl>
Yes, I know
<xkapastel>
is that the custom lisp they used for the parser?
<pflanze>
xkapastel, yes
<xkapastel>
that was such a strange decision
Kaisyu has quit [Quit: Connection closed for inactivity]
<pflanze>
The first version of Julia was fully written in Scheme. Then they started shedding the Scheme roots, so wrote a simple interpreter to keep the parser in Scheme.
<pflanze>
Not so strange?
<pflanze>
It probably helps bootstrapping.
<xkapastel>
i didn't know the first version was in scheme
<xkapastel>
now i wanna use that n-dimensional array from scheme
<White_Flame>
right, but "AST" technically is about syntax. Although many language implementations use that language to resolve all the source-level semantics
<White_Flame>
s/language/layer/
<pflanze>
Yeah, not sure what the proper definition is there.
<White_Flame>
so in that specific verbage, Lisp sexprs are an AST
<pflanze>
It's a dangerous conflation
<pflanze>
Because I think s-exprs are cool. But often misunderstood.
<White_Flame>
I think one of the stylistic issues is that sexprs tend to be more nestable than other languages' source forms
<White_Flame>
along with all sorts of local definitions/bindings/shadowing
<White_Flame>
and because of macros, Lisp passes around code snippets that depend on their context much more than other languages
hiroaki has quit [Remote host closed the connection]
<pflanze>
Yes, macros sit at the root of both the usefulness of sexprs (why lisps really have them), and also why sexprs are not the same kind of ASTs other languages are using.
<White_Flame>
so in practice, Lisp actively does things with its AST, whereas many often just have the AST in the compiler and static codegen tools
frgo has quit []
<White_Flame>
and I think the fact that at the sexpr level, the per-symbol semantics are NOT resolved, that makes it more powerful
<xkapastel>
symbols not having a fixed meaning is at the heart of lisp i think. so while sexp isn't a "real" ast, the fact that it's not is the whole feature lisp is providing imo
varjag has joined #lisp
frgo_ has joined #lisp
frgo has quit [Ping timeout: 246 seconds]
<White_Flame>
from wiki: "Once built, additional information is added to the AST by means of subsequent processing, e.g., contextual analysis. "
<White_Flame>
so certainly an AST without contextual semantics still is an AST
<xkapastel>
it's not clear that you could have an ast "without contextual semantics" in the usual style of PL definition i'm familiar with
<White_Flame>
things like "a=3". Does the AST have to know if that's global or local?
fikka has joined #lisp
<White_Flame>
obviously, that information will eventually be resolved, but that's a separate issue
<White_Flame>
(and that resolved information will likely be stored on the AST)
Sauvin has quit [Read error: Connection reset by peer]
<White_Flame>
heh, on the bottom of the AST page, "[Lisp], a family of languages written in trees, with macros to manipulate code trees", which specifically avoids calling those trees "AST" by name
<pflanze>
I've posted a follow-up comment on HN. I guess some ambiguity will remain. The right thing to realize is that there are various extents of information that an AST can contain.
fikka has quit [Ping timeout: 252 seconds]
frodef has joined #lisp
nly has quit [Read error: Connection reset by peer]
nlyy has joined #lisp
nlyy has quit [Client Quit]
<on_ion>
hm any tree could be casted as abstract syntax
hhdave has quit [Ping timeout: 252 seconds]
zxcvz has joined #lisp
<flip214>
phoe: the email address listed on github doesn't work; I got a bounce back: connect to mail.openmailbox.org[5.79.108.160]:25: Connection timed out
<flip214>
JFI.
fikka has joined #lisp
elderK has quit []
<phoe>
flip214: yes, that's why I finally changed it. openmailbox ground to a halt some months ago.
fikka has quit [Ping timeout: 246 seconds]
epr0xe has quit [Quit: epr0xe]
fikka has joined #lisp
ggole has quit [Quit: ggole]
<pjb>
Nice idea! Castrate your trees, and treat them of abstract syntax :-)
<phoe>
sjl: oh yes, that's exactly what was on my mind
<jasom>
Ukari: what do you want out of your promises? lparallel is a library for structured concurrency that includes promises
fikka has quit [Ping timeout: 272 seconds]
jeosol has joined #lisp
shifty has quit [Ping timeout: 272 seconds]
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
nowhere_man has joined #lisp
anamorphic has quit [Quit: anamorphic]
fikka has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
<jeosol>
morning guys
nowhere_man has quit [Ping timeout: 252 seconds]
astalla has joined #lisp
<jeosol>
I need some DSL help guys, for those DSL experts here. This is mostly in my head for now. I am trying to develop a system that where a user creates a file with plain instructions, e.g., run_simulation (objects) and I map that to (run-simulation objects)
<phoe>
why can't they input s-expressions for you to read?
<jeosol>
objects is a CLOS instance of a class. The file will contain a bunch of instructions that are performed in a procedural form, but each function in the plane file should map into a lisp file.
<phoe>
do you have a specification for that DSL?
<jeosol>
well, I don't expect uses to know how to use CL at all.
<jeosol>
not very savvy, most users use GUI software for the different steps, click here, click there.
<jeosol>
phoe: I don't have one yet, still working on it. I am trying to see if it is possible to that yet.
<jeosol>
All a user then has to do will be type a set of instructions once the "object" variable is ready, and I read that file and do the calculations
<jeosol>
phoe: I meant to do what I'm planning or may be just have type type the s-expressions by providing a manual
fikka has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
dueyfinster has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<jeosol>
The way I run the code is on a repl. I create list of the functions to call, and call them sequentially. I am looking for the best way for potential users to pick some standard workflow or run a user specific workflow.
robdog has joined #lisp
<jeosol>
Each action in the user-specific workflow will have a CL function and should normally take one argument (an instance of a class)
fikka has quit [Ping timeout: 240 seconds]
<on_ion>
sounds good..
<phoe>
jeosol: I have a silly idea
<phoe>
can't you expose a (possibly simplified) Lisp REPL to them, after putting them in a proper package?
<jeosol>
I'll like to hear it.
<phoe>
simplified in two ways:
dueyfinster has joined #lisp
<phoe>
1) create a package with predefined symbols that you want them to use and IN-PACKAGE into it
<phoe>
2) you might want to write a custom simple REPL that handles all errors on its own and therefore prevents debugger entry
<jeosol>
I see.
<phoe>
(to dumb the REPL down, in order not to overload the user with data)
<White_Flame>
yeah, I had an image-builder system with prop files to define how to load up a lisp environment, either for the repl or to build an executable image. I ended up doing exactly that in the 2nd revision, making defuns and having the prop file contents simply call them
<White_Flame>
instead of messing with reading the file as data
<jeosol>
I'll need to catch syntax errors, when the enter wrong symbols.
<jeosol>
white_flame: thanks for that info.
<phoe>
jeosol: catch *all* errors
<jeosol>
What am looking at is something that say includes some package (e.g., header c/c++, import in python) where the "object" instance becomes available
<phoe>
and then expose INCLUDE-HEADER for the user to call
<jeosol>
and then the user can write some statements that map to CL functions.
frodef has quit [Ping timeout: 245 seconds]
<jeosol>
phoe: thanks for that.
<robdog>
newbie quest: how do you print a new line? (format t "hello\n") ?
<jeosol>
(format t "~%")
<varjag>
"~%"
<robdog>
awesome
<varjag>
alternatively you can use freshline
<varjag>
~&
<robdog>
newline = \r\n and freshline is?
<varjag>
freshline is newline when there was no newline before
<robdog>
a conditional newline?
<varjag>
placed at the beginning of the string
<jeosol>
phoe: the CL include-header function are for he first option?
<robdog>
if (cursorXloc != 0) print "\n" ??
<varjag>
"~&foo" will always start on a new line, but wont' print extra newline if you did "bar~%" before it
fsmunoz has quit [Remote host closed the connection]
<phoe>
jeosol: sure thing
<phoe>
oh wait
<robdog>
i will have to force myself to use that, since ive never used it before
<phoe>
there is no CL:INCLUDE-HEADER function
<jeosol>
I know
<phoe>
build it yourself, based on USE-PACKAGE
frgo_ has quit []
<jeosol>
I was just asking if that function goes with option 1 or 2 above
<phoe>
um, what are the options?
<phoe>
this would go with the custom REPL
<jeosol>
since you mentioned two ways I could go about building the translation unit
<jeosol>
I see, the custom repl option.
<jeosol>
white_flame: anyway I can look at the image-builder system
fikka has joined #lisp
lnostdal has joined #lisp
<White_Flame>
robdog: there's #clschool which is probably more appropriate for learning questions
<White_Flame>
jeosol: that was an internal tool of ours, not something visible
<robdog>
White_Flame: oops..sorry..i thought i was sending it to #clnoobs
<White_Flame>
the noobs channel is unmoderated and abandoned now
<jeosol>
ok, white_flame: no worries, that's for the info anyway.
<phoe>
robdog: actually #clnoobs is abandoned due to it having a high volume of spam traffic
<phoe>
and no op being available
<dlowe>
learning questions are fine here
<phoe>
(which is also good because the new channel's name is less abrasive)
<dlowe>
but it's also nice to have a specialized channel
<phoe>
also what dlowe said - it's usually only good to direct learning stuff there when #lisp is busy with other traffic, so the different conversation flows don't collide with each other
nowhere_man has joined #lisp
<phoe>
(and now it isn't all that busy)
<jeosol>
phoe: thanks for the input. I'll give this some hacking.
<dlowe>
also, people are on #lisp for a variety of reasons, but you know that everyone in #clschool is there for learn-sharing
fikka has quit [Ping timeout: 244 seconds]
<White_Flame>
learning on #lisp can also tend to result in incredibly over-precise answers & in-depth discussions which aren't as useful for learning context
<robdog>
dlowe: cool..im on #clschool now..thanks guys! one day ill be back here actually answering questions!
rotty has joined #lisp
<phoe>
robdog: good luck!
<robdog>
thanks phoe!
eddof13 has quit [Quit: eddof13]
nowhere_man has quit [Ping timeout: 252 seconds]
fikka has joined #lisp
rozenglass has joined #lisp
anamorphic has joined #lisp
fikka has quit [Ping timeout: 244 seconds]
nowhere_man has joined #lisp
frgo has joined #lisp
rumbler31 has quit [Remote host closed the connection]
eddof13 has joined #lisp
anamorphic has quit [Quit: anamorphic]
dueyfinster has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
zxcvz has quit [Quit: Leaving]
nowhere_man has quit [Ping timeout: 252 seconds]
anamorphic has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
fikka has joined #lisp
fikka has quit [Ping timeout: 252 seconds]
eddof13 has quit [Quit: eddof13]
<aeth>
robdog: The two main ways to print a newline are (format t "~%") or (terpri). Obviously there are other ways, like (write-char #\Newline) or (write-line ""), of course.
<aeth>
If you're already using format, the best way to do it is to add ~% to the end of the string like "hello~%". If you're not already using format, terpri might be the clearer option even though it's poorly-named.
scymtym has quit [Ping timeout: 264 seconds]
fikka has joined #lisp
frgo has quit [Read error: Connection reset by peer]
frgo has joined #lisp
<aeth>
With the exception of format nil, which makes a string instead of writing to a stream, you can mix and match things when writing to a stream. That might make things clearer than putting everything in one big format. Everything that writes to a stream has an optional argument that defaults to *standard-output* except for format, where t is used to write to *standard-output* because it cannot have optional arguments at the end.
eddof13 has joined #lisp
<aeth>
So in terms of style, you probably want (format stream "whatever~%" ...) (format stream "another-line~%" ...) etc. where stream is either a stream or t for *standard-output* (this won't work with format nil, you'll have to create a with-output-to-string stream for that if you want to keep this style)
<pjb>
And you can always do (with-output-to-string (*standard-output*) (print 'hello) (print 'world))
<White_Flame>
..(terpri))
fikka has quit [Ping timeout: 268 seconds]
<White_Flame>
ah, print newlines. So you get HELLO~%WORLD~%
<aeth>
Get used to reading/writing code that either separates things with (terpri) or splits up formats (where you probably will end them in ~% instead of using terpri). And as pjb said you can just rebind *standard-output* instead of using non-t FORMAT and providing the stream explicitly for non-FORMAT writing.
<White_Flame>
erm, "~%HELLO ~%WORLD"
<White_Flame>
+" " :-P
* White_Flame
steps away from the keyboard
<aeth>
robdog: The final thing you should know about the basics of printing in CL is that there are basically three tiers of abstraction. The very high level FORMAT, the middle level PRINFOO (e.g. PRINT), and the low-level WRITE-FOO (when WRITE-FOO is writing characters/strings to a character stream, not bytes to a byte stream). TERPRI is the way to do newline for the bottom two levels, and "~%" for FORMAT.
<aeth>
There isn't a (portable) level lower than WRITE-CHAR
nowhere_man has joined #lisp
fikka has joined #lisp
<aeth>
(If you need to work with characters as bytes, perhaps to use a certain encoding, use a library like babel)
Roy_Fokker has joined #lisp
fikka has quit [Ping timeout: 252 seconds]
shka_ has quit [Ping timeout: 250 seconds]
fikka has joined #lisp
nowhere_man has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 252 seconds]
moei has quit [Quit: Leaving...]
<pjb>
aeth: (write-char #\newline)
<pjb>
#\newline is a "virtual" character. It can write CR, LF or CRLF, or something else, depending on the kind of file or device.
<aeth>
pjb: Yes, TERPRI is probably just (progn (write-char #\newline) nil) because WRITE-CHAR is the lowest level. In terms of style, though, I'd use TERPRI even in code that heavily uses WRITE-FOO. I guess you could argue TERPRI belongs at the PRINFOO level, though.
frgo_ has joined #lisp
<aeth>
(Interestingly, in SBCL this does *not* seem to be the case. I guess there's performance reasons to having a separate TERPRI.)
<aeth>
They marked recommended/standard libraries, and they sorted implementations to put SBCL, CCL, and ECL on top and in that order.
<aeth>
(And they removed GCL)
rumbler31 has quit [Ping timeout: 246 seconds]
<aeth>
(perhaps I should say "de facto standard libraries" instead of "standard libraries" since the latter means something else)
vlatkoB has quit [Remote host closed the connection]
jkordani_ has joined #lisp
fikka has joined #lisp
rumbler31 has joined #lisp
jkordani has quit [Ping timeout: 244 seconds]
mutenewt has quit [Quit: Leaving]
fikka has quit [Ping timeout: 245 seconds]
sjl has quit [Quit: WeeChat 2.3-dev]
fikka has joined #lisp
<jasom>
does/has anyone used ECL to write plugin(s) for apps that support C plugins? I'm considering doing so and am interested to hear advice
<rumbler31>
jasom: so you're going to end up with dlls to link with the final project?
<rumbler31>
or shared objects?
<pillton>
jasom: What happens if there are two plugins that use different versions of ECL?
fikka has quit [Ping timeout: 272 seconds]
<pillton>
jasom: I wonder if LispWorks solves this problem with the their COM and shared library support?
<pjb>
what happens if two libraries use different versions of libc?
<pjb>
You fucking recompile all of them to use the fucking same version of libc!
<rumbler31>
yea?
<rumbler31>
er... I suppose that depends on... which libraries are being linked in (in the case of ecl)
<rumbler31>
if it is the case that different versions of ecl present themselves as different names of the dynamic lib to be linked, then one plugin links version 1 and the other version 2...
fikka has joined #lisp
<rumbler31>
along the same vein, would two modules designed separately potentially clash if they use the same version of ecl?
<rumbler31>
or have access to each others objects functions, etc?
<pjb>
Yes, both.
<pjb>
If you link them in the same program.
<pjb>
Just like C libraries.
nirved is now known as Guest78180
Guest78180 has quit [Killed (niven.freenode.net (Nickname regained by services))]
<pillton>
I am pretty sure that is incorrect.
<pillton>
All dynamically loadable plugins export the same function name.
<pillton>
It is the interface to the dynamically loadable plugin.
<pjb>
In C, you deal with that by using the visibility of symbols in the linker. In CL you deal with that by using different packages.
<no-defun-allowed>
can i use initialize-instance on structs?
<rumbler31>
there's verbiage in microsofts documentation about making the distinction about statically linking their c runtime vs dynamic, about how different things become exposed or shared (or hidden) across your codebase
<rumbler31>
which I don't quite understand
<pjb>
Well, it depends on when you link the shared library. But in anycase, when you dlopen one, the unresolved symbols are linked.
meepdeew has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
<rumbler31>
honestly the documentation didn't really clear anything up, just said, "there is a difference"
<jasom>
rumbler31: yes; pillton good question, but it's unlikely to happen
<jasom>
sorry, I got a phone call like right after I asked.
<jasom>
I imagine I would have a single libecl plugin, and then have ecl load lisp file(s) that are needed; this is how e.g. python plugins typically work.
<pillton>
jasom: The question I asked generalises to any process specific state. e.g. asynchronous signals.
<aeth>
jasom: Yes. Sounds like the alternative would be very wasteful even if you did use the same version.
<pillton>
Can python, java and CL operate in the same process?
<jasom>
pillton: indeed, I don't know how much global process state ECL wishes to manage. The term "embeddable" makes me hopeful it's not too much.
<aeth>
pillton: Technically, yes. You'd have to use ABCL, though.
<aeth>
(And Jython)
<jasom>
clisp, for example, is very limited in how it can manage child processes since the runtime hooks into SIGCHLD
<no-defun-allowed>
can i set up an array or structure inside a struct using values from make-struct?
<pillton>
jasom: To be honest, you would better off making your plugin a controller for starting and stopping a CL process and using IPC.
<no-defun-allowed>
initialize-instance doesn't get called it seems
<aeth>
no-defun-allowed: Change the constructor's name to %make-foo and define and inline make-foo
<aeth>
At least, that's what I've been doing for years
<no-defun-allowed>
alright
<pillton>
jasom: would be*....
sjl has joined #lisp
LiamH has quit [Quit: Leaving.]
<aeth>
no-defun-allowed: and you rename the constructor by replacing the name foo with (foo (:constructor %make-foo))
<jasom>
pillton: I can imagine lots of problems, but empirical data trumps imagination.
<no-defun-allowed>
did that
<jasom>
pillton: I would like to avoid using an IPC if I can, but I have done exactly this in the past.
<pillton>
jasom: At least with IPC you get some invariance to time.
kajo has joined #lisp
<pjb>
pillton: of course. Run cl-python on abcl on the jvm.
<pjb>
jasom: don't avoid IPC. This is actually a very nice structuring tool.
<pjb>
jasom: some programs explicitely use it to split out their functionality into separate processes, for security reasons. For example, postfix (but others too).
<jasom>
pjb: I'm well aware of the advantages and disadvantages of multiprocessing.
fikka has joined #lisp
Essadon has quit [Quit: Qutting]
fikka has quit [Ping timeout: 245 seconds]
fikka has joined #lisp
quazimodo has joined #lisp
robotoad has quit [Quit: robotoad]
fikka has quit [Ping timeout: 252 seconds]
akovalenko has quit [Remote host closed the connection]
akovalenko has joined #lisp
troydm has quit [Ping timeout: 268 seconds]
vutral has quit [Ping timeout: 268 seconds]
<pillton>
jasom: I meant no offence. I have asked similar questions in the past and these are the problems I have thought of.
vutral has joined #lisp
troydm has joined #lisp
<jasom>
pillton: no offense taken, just clarifying why I'm asking :)
<jasom>
pillton: "If you want to use your own signal handlers then you should set the appropriate options before invoking cl_boot(), as explained in ecl_set_option. Note that in this case ECL will not always be able to detect floating point exceptions, specially if your compiler does not support C99 and the corresponding floating point flags."