ahungry has quit [Remote host closed the connection]
ahungry has joined #lisp
Nilby has quit [Read error: Connection reset by peer]
ahungry has quit [Remote host closed the connection]
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 268 seconds]
Lord_of_Life_ is now known as Lord_of_Life
<pjb>
HiRE: that's about what happens, everyone writes his own documentation parser.
<pjb>
White_Flame: dynamic binding is not in any scope. It's in some TIME!
<pjb>
"global" is a lexical notion. So wrong.
* White_Flame
sighs
<pjb>
"eternal" would be a dynamic (time) notion, but it implies some level of immutability, so it would do only for defconstant…
<White_Flame>
The length of time is a scope with a definite beginning and usually definite ending
<pjb>
Some "initial" binding of special variable can be specified with defparameter/defvar.
<White_Flame>
"global" means many things, and the binding in question is the shared one that everybody sees without a local private override
<no-defun-allowed>
SBCL has a macro named DEFGLOBAL, so there is some precedent to calling it a global value.
<pjb>
White_Flame: In the expression "global variable", "global" designates a lexical scope.
<White_Flame>
no-defun-allowed: yes, as do older lisps when dynamic binding was new
<no-defun-allowed>
Dynamic binding was new once?
<White_Flame>
but this isn't "global variable", it's a "global value" or "global binding"
<pjb>
White_Flame: defining a variable with defparameter or defvar doesn't propagate its definition in the past. Therefore it cannot be a "global temporal" scope.
<White_Flame>
no-defun-allowed: ah, no, more an optimization thing
shifty has quit [Ping timeout: 240 seconds]
igemnace has joined #lisp
<White_Flame>
pjb: the "shared" notion is the one most related to "global"
<White_Flame>
the scope is the distinction between this one and private bindings that other threads of execution create
<Bike>
defglobal doesn't define a special variable, so that's more of a point against, really
saravia has joined #lisp
<White_Flame>
other terms might be "default" or "shared" or "public" or something
Necktwi has joined #lisp
<HiRE>
tbh dynamic and lexical scope still kind of confuse me with lisp
<White_Flame>
but I did default to "global" as well, just couldn't find any specific basis for it
<pjb>
dynamic binding is a fucking TIME notion!
<White_Flame>
pjb: and time has scopes, too
<pjb>
default, shared or public is not on the time axis!
<White_Flame>
and scopes control visibility
<White_Flame>
it is the proper term
<pjb>
There are time intervals, yes.
<HiRE>
I think its just the names of the scope. The process is intuitive but "dynamic" goofs me up for some reason.
<Bike>
the clhs entry for defvar/defparameter calls it the "value cell" but that's kinda bad for other reasons
<pjb>
If you use the same word for the two orthogonal notion, you are bound to be confused, and to confuse everybody.
<White_Flame>
right
<White_Flame>
(Bike
<no-defun-allowed>
)
<White_Flame>
and does the "value cell" point to a private location when another dynamic binding is in effect?
<HiRE>
thank you for fixing my ocd no-defun-allowed
saravia has quit [Client Quit]
<White_Flame>
as opposed to always meaning the (usually) symbol struct slot?
slyrus_ has joined #lisp
slyrus has quit [Ping timeout: 265 seconds]
<White_Flame>
" A dynamic variable can be referenced outside the dynamic extent of a form that binds it. Such a variable is sometimes called a ``global variable'' but is still in all respects just a dynamic variable whose binding happens to exist in the global environment rather than in some dynamic environment. "
<White_Flame>
so I think "global binding" still is the best one
Codaraxis has quit [Read error: Connection reset by peer]
<White_Flame>
harkening to the term "global environment"
<White_Flame>
(which again has zero to do with lexical notions)
<White_Flame>
well, specific to the comment I'm writing, "global value" would imply the value held in symbol's said "global binding", even if there are other dynamic bindings flying around
smokeink has joined #lisp
slyrus__ has joined #lisp
slyrus_ has quit [Ping timeout: 272 seconds]
<White_Flame>
oh, and "global variable" is in the glossary as well: "global variable n. a dynamic variable or a constant variable."
<White_Flame>
(lol "constant variable")
<no-defun-allowed>
Perhaps it's varying at a constant rate.
<White_Flame>
as they say, "constants aren't, and variables don't."
<White_Flame>
(at least when it comes to math & physics)
davr0s__ has joined #lisp
karswell has quit [Remote host closed the connection]
karswell_ has joined #lisp
davr0s_ has quit [Ping timeout: 260 seconds]
davr0s has quit [Ping timeout: 260 seconds]
davr0s has joined #lisp
karlosz has left #lisp [#lisp]
_whitelogger has joined #lisp
Lord_of_Life has quit [Ping timeout: 272 seconds]
karswell_ is now known as karswell
Lord_of_Life has joined #lisp
gnufr33d0m has quit [Quit: gnufr33d0m]
gnufr33d0m has joined #lisp
remexre has quit [Quit: WeeChat 2.6]
Bike has quit [Quit: Lost terminal]
gravicappa has joined #lisp
stepnem_ has quit [Ping timeout: 258 seconds]
stepnem has joined #lisp
milanj has quit [Quit: This computer has gone to sleep]
davisr_ has joined #lisp
davisr has quit [Ping timeout: 265 seconds]
oxum has joined #lisp
<beach>
Good morning everyone!
<LdBeth>
Hello beach
patrixl has joined #lisp
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
ahungry has joined #lisp
ahungry has quit [Remote host closed the connection]
slyrus_ has joined #lisp
vlatkoB has joined #lisp
slyrus__ has quit [Ping timeout: 268 seconds]
slyrus__ has joined #lisp
slyrus_ has quit [Ping timeout: 268 seconds]
torbo has quit [Remote host closed the connection]
brown121407 has quit [Ping timeout: 265 seconds]
brown121407 has joined #lisp
karswell has quit [Remote host closed the connection]
karswell has joined #lisp
gnufr33d0m has quit [Quit: gnufr33d0m]
anewuser has quit [Quit: anewuser]
koenig has quit [Ping timeout: 246 seconds]
koenig has joined #lisp
<smokeink>
how to muffle such notes? note: doing unsigned word to integer coercion (cost 20) to "<return value>"
varjag has joined #lisp
narimiran has joined #lisp
space_otter has joined #lisp
sauvin has joined #lisp
rtra has joined #lisp
space_otter has quit [Remote host closed the connection]
space_otter has joined #lisp
jello_pudding has joined #lisp
rtra has quit [Ping timeout: 260 seconds]
Codaraxis has joined #lisp
rtra has joined #lisp
seok has joined #lisp
varjag has quit [Ping timeout: 258 seconds]
karswell has quit [Read error: Connection reset by peer]
rtra has quit [Ping timeout: 245 seconds]
ebzzry has quit [Ping timeout: 258 seconds]
jprajzne has joined #lisp
ebzzry has joined #lisp
dale has quit [Quit: My computer has gone to sleep]
vivit has quit [Ping timeout: 272 seconds]
scymtym has quit [Ping timeout: 272 seconds]
<White_Flame>
smokeink: (declare (sb-ext:muffle-conditions optimization-note)) in the scope
<White_Flame>
I have a macro that generates `(locally (declare ....) ,@body) so I can easily wrap it around small operations
<White_Flame>
(declare (sb-ext:unmuffle-conditions optimization-note)) around the parameters of the subform also allows its whinings to not be muffled, just the singular form in question
ebzzry has quit [Ping timeout: 265 seconds]
koenig has quit [Ping timeout: 272 seconds]
koenig has joined #lisp
<seok>
Is there a library to resize jpg images?
space_otter has quit [Remote host closed the connection]
space_otter has joined #lisp
jonatack has quit [Ping timeout: 272 seconds]
adolby has quit [Remote host closed the connection]
<slyrus__>
seok: you can do that with opticl pretty easily
<seok>
slyrus__: cool, thanks
<smokeink>
White_Flame: thanks
adolby has joined #lisp
jonatack has joined #lisp
Buggys has quit [Ping timeout: 248 seconds]
frgo has quit [Remote host closed the connection]
slyrus_ has joined #lisp
scymtym has joined #lisp
Buggys has joined #lisp
slyrus__ has quit [Ping timeout: 258 seconds]
<Shinmera>
HiRE: If you have questions about Staple, let me know.
grabarz has joined #lisp
flamebeard has joined #lisp
gxt has quit [Ping timeout: 240 seconds]
jonatack has quit [Ping timeout: 260 seconds]
JohnMS_WORK has joined #lisp
shifty has joined #lisp
grabarz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
william1_ has joined #lisp
frgo has joined #lisp
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
varjag has joined #lisp
william1_ has quit [Ping timeout: 240 seconds]
JohnMS has joined #lisp
slyrus__ has joined #lisp
grabarz has joined #lisp
slyrus_ has quit [Ping timeout: 258 seconds]
JohnMS_WORK has quit [Ping timeout: 265 seconds]
rtra has joined #lisp
picantest has quit [Ping timeout: 260 seconds]
Codaraxis_ has joined #lisp
Codaraxis has quit [Ping timeout: 272 seconds]
mangul has joined #lisp
jfb4 has joined #lisp
jfb4_ has quit [Ping timeout: 268 seconds]
rtra has quit [Ping timeout: 258 seconds]
rtra has joined #lisp
<trittweiler>
White_Flame, "global binding" versus "thread-local binding" (non-standard, of course) versus "local binding" is decent terminology I would reckon
<jackdaniel>
isn't the terminology: deep binding and shallow binding (and a symbol value which is not a binding)?
milanj has joined #lisp
<jackdaniel>
and a consequence of deep binding implementation technique are thread-local bindings, and shallow gives you bindigns which are shared across threads (n.b probably harder to synchronize )
_fe_ has joined #lisp
<smokeink>
White_Flame: unknown type specifier: OPTIMIZATION-NOTE
ralt has joined #lisp
<beach>
jackdaniel: That doesn't sound right.
<beach>
jackdaniel: The distinction between deep and shallow binding is just an implementation issue.
<beach>
jackdaniel: Correct implementation of shallow binding in a multi-thread context is that there must be a per-thread "value cell".
<jackdaniel>
beach: isn't this issue directly influencing how binding behaves in threads?
<beach>
I should hope not.
<beach>
From memory, SBCL assigns a number to a symbol as soon as it is used as a variable. This number is used as an index into a table in the reified thread.
<jackdaniel>
hm, thanks for correcting me. I'll re-read the relevant parts of LiSP then to improve my understanding
<beach>
That table contains the per-thread "value cells".
mingus`` has quit [Remote host closed the connection]
<jackdaniel>
I see
rtra has quit [Ping timeout: 268 seconds]
<beach>
Does ECL use deep binding then?
hhdave has joined #lisp
<jackdaniel>
yes, it has a per-thread bindings array
<jackdaniel>
(and stack)
<beach>
Then that is shallow binding.
<beach>
No?
<beach>
How does it access the current value of a variable?
<beach>
Does it traverse the stack or does it consult the array?
<jackdaniel>
sorry, I can't tell from top of my head (and I'm focused on McCLIM issue atm so I'm not eager to look up ECL's internals code)
<beach>
No worries. Just interested.
hhdave has quit [Ping timeout: 265 seconds]
<jackdaniel>
I think that the location is on the stack and the array element is updated to point at that location
Achylles has joined #lisp
<beach>
OK.
<beach>
But I wasn't asking what happens when a binding is done or undone. Just what SYMBOL-VALUE does. Again, if you are busy, you don't have to answer.
<jackdaniel>
it looks up value in said array
<beach>
Then you have shallow binding.
<jackdaniel>
OK, thanks for explaining; I think I won't cnofuse these things anymore
jonatack has joined #lisp
<beach>
Glad to be of help.
quazimodo has quit [Ping timeout: 268 seconds]
hhdave has joined #lisp
<beach>
For what it's worth, my current hypothesis is to use deep binding for SICL. I.e., the dynamic environment stack contains binding entries, and there is no per-thread table. SYMBOL-VALUE then has to search the stack to find the most recent binding.
redeemed has joined #lisp
<beach>
So searching for the current value or setting that value is more expensive than with shallow binding, at least if the stack is somewhat deep. Though finding the table in the thread is not free either.
<beach>
On the other hand, binding/unbinding is cheaper in deep binding than in shallow binding.
<beach>
If it turns out that 1. Access to special variables is frequent, and 2. Those accesses are often to deeply nested bindings, then I may have to reconsider.
phlim has quit [Quit: WeeChat 2.4]
william1 has joined #lisp
davepdotorg has joined #lisp
chimneys has joined #lisp
<chimneys>
is closure the same ething as currying in lambda calculus
<LdBeth>
no
<White_Flame>
beach: in SBCL, the TLS is always in a register, so "finding the table in the thread" actually is free
<White_Flame>
*tls pointer
<beach>
White_Flame: Yes, I understand.
<beach>
chimneys: A closure can be the result of currying. But closures exist independently.
<LdBeth>
currying is just a function (defun currying (fn) (lambda (x) (lambda (y) (funcall fn x y))))
<beach>
chimneys: (let ((x 10)) (lambda (y) (+ x y))) creates a closure with one parameter
<beach>
chimneys: When called, the closure returns the parameter + 10.
<beach>
It is *so* inspiring to answer questions from someone who 1. does not acknowledge this fact, and 2. leaves instead.
<LdBeth>
GG
Achylles has quit [Ping timeout: 272 seconds]
<phoe>
beach: the channel is logged, so if they ever come again and/or ask again, you can point them towards the logs in the channel topic.
ghard has joined #lisp
<jackdaniel>
"- hey, I remember your nick from 5months ago, you did not thank me - do you remember that? - no (leaves the channel)", pretty burdensome strategy
<jackdaniel>
and I doubt that would change the culture of a person who is reminded that they did not follow proper netiquette
<phoe>
jackdaniel: right
<phoe>
I thought of something like more like "oh I happen to recognize that nickname, they asked a question that was answered but they left, the answer is in the channel logs"
<phoe>
but that approach has its obvious downsides
<phoe>
oh well, let me try to wake up instead
<shka_>
good day everyone!
tiwEllien has joined #lisp
<LdBeth>
hi shka_
Achylles has joined #lisp
jprajzne has quit [Quit: jprajzne]
william1_ has joined #lisp
<phoe>
heyy
<beach>
I totally agree with jackdaniel.
<beach>
Hello shka_.
<no-defun-allowed>
Hello shka_ and phoe
mingus has joined #lisp
montaropdf has joined #lisp
rtra has joined #lisp
okflo has joined #lisp
okflo has left #lisp [#lisp]
atgreen has joined #lisp
<ghard>
Morning
Achylles has quit [Remote host closed the connection]
<beach>
Hello ghard.
<ghard>
Have asked this before, methinks, but anyone tried to use ZS3 with DigitalOcean with success (claims to be S3-API-compatible) ?
<ghard>
(maybe this is not a discussion for a lang-focused group)
jprajzne has joined #lisp
sz0 has joined #lisp
m00natic has joined #lisp
shifty has quit [Ping timeout: 265 seconds]
imherentlybad has joined #lisp
<seok>
good evening
<seok>
is there a shortcut to convert array to list?
<seok>
thought alexandria might have it but nope
jonatack has quit [Ping timeout: 260 seconds]
<seok>
Guess everyone just writes the loop?
<no-defun-allowed>
(coerce <vector> 'list)
<selwyn>
(coerce #(1 2 3) 'list) ; => (1 2 3)
<seok>
ah thank you
<no-defun-allowed>
Note that it won't work for arrays of arbitrary dimensions, but only for one-dimensional vectors.
space_otter has quit [Remote host closed the connection]
<seok>
yup
smokeink has quit [Remote host closed the connection]
smokeink has joined #lisp
smokeink has quit [Remote host closed the connection]
decent-username has joined #lisp
Achylles has joined #lisp
EvW has joined #lisp
gnufr33d0m has joined #lisp
oxum has quit [Remote host closed the connection]
jfb4 has quit [Ping timeout: 272 seconds]
jfb4 has joined #lisp
oxum has joined #lisp
ggole has joined #lisp
nullman has quit [Remote host closed the connection]
nullman has joined #lisp
EvW has quit [Ping timeout: 245 seconds]
dddddd has joined #lisp
jonatack has joined #lisp
Achylles has quit [Ping timeout: 272 seconds]
Necktwi has quit [Read error: Connection reset by peer]
Necktwi has joined #lisp
rwcom6 has joined #lisp
rwcom has quit [Ping timeout: 268 seconds]
rwcom6 is now known as rwcom
imherentlybad has quit [Ping timeout: 268 seconds]
Achylles has joined #lisp
rwcom5 has joined #lisp
kajo has quit [Ping timeout: 272 seconds]
kajo has joined #lisp
rwcom has quit [Ping timeout: 268 seconds]
rwcom5 is now known as rwcom
atgreen has quit [Ping timeout: 272 seconds]
william1_ has quit [Ping timeout: 240 seconds]
EvW has joined #lisp
ljavorsk has joined #lisp
brown121407 has quit [Read error: Connection reset by peer]
<_death>
pjb: just the other day I wrote this kind of flatten-array operator.. useful if you're representing bayesian network conditional probability as multi-dimensional arrays
<_death>
*conditional probability tables
Nilby has joined #lisp
smokeink has joined #lisp
ggole has quit [Remote host closed the connection]
ggole has joined #lisp
Lycurgus has quit [Remote host closed the connection]
milanj has joined #lisp
raghavgururajan has quit [Read error: Connection reset by peer]
<reepca>
is there a way to print arrays that preserves the fill pointer?
<_death>
you need to write your own printer
decent-username has quit [Ping timeout: 272 seconds]
<reepca>
for example: (defparameter test-array (make-array 10 :adjustable t :fill-pointer 0 :element-type '(unsigned-byte 8)))
<reepca>
just realized, s/*print-readbly*/*print-readably*
<reepca>
need to touch up the soldering on my 'a' key again...
<reepca>
but anyway, behavior is the same
<pjb>
reepca: but you cannot use print, because it is not specified whether print uses print-object or not, and you cannot define print-object methods on standard classes such as array.
smokeink has quit [Quit: Leaving]
<pjb>
reepca: you may be able to do something with *print-pretty*, I'm not sure.
<_death>
pjb: sure
<bitmapper>
this may be the most annoying bug ive ever encountered
<pjb>
reepca: you should also define a new #A dispatching reader macro.
EvW has quit [Ping timeout: 260 seconds]
<pjb>
bitmapper: just define your own functions. (defgeneric serialize (…))
<bitmapper>
nonono, not this
<bitmapper>
debugger invoked on a COMMON-LISP:UNDEFINED-FUNCTION in thread #<THREAD "main thread" RUNNING {10005084C3}>: The function SB-C::%MORE-ARG-CONTEXT is undefined.
<bitmapper>
this
<bitmapper>
how does that even occur
<boeg>
I am trying to build a piece of software (the next browser) but it seems a common lisp error happens and it errors out. I get the error message thats put into the Makefile to make sure i have the xclip binary installed as well as developer files for sqlite and fixposix which I have in /usr/bin and in /usr/lib and /lib. I'm not sure if it's not able to find one or all of them or if something else goes wrong. Would anyone mind
<boeg>
taking a
<boeg>
look at the output from make and see if they can figure out what is wrong? It's here: http://ix.io/27sw
<galdor>
the error is The value "The root of all modes." is not of type LIST also called "do not use crappy stuff such as cl-annot which is dead, repo archived and unmaintained (and useless to start with)" or "test your code"
<galdor>
(and by "your" I mean "next developers")
<boeg>
right
<boeg>
so its not actually a dependency that is missing?
<phoe>
nope, that's a type error
<boeg>
ah
<boeg>
crossed my mind
<phoe>
I'd mention jmercouris if he was around here, but he isn't
<boeg>
thank you for confirming it
<phoe>
so just file an issue on the next repository
<galdor>
oh they use puri for a web browser
<boeg>
yeah i'm just gonna talk with him about it
<galdor>
it's not going to end well
ebzzry has joined #lisp
frgo has quit []
frgo has joined #lisp
william1 has quit [Ping timeout: 265 seconds]
Bike has joined #lisp
frgo_ has joined #lisp
seok has joined #lisp
<seok>
if the complexity of gethash is O(1), isn't it better than arrays or lists in all cases for large dataset?
<Bike>
arrays are also O(1), provided the key is a nonnegative integer
<Shinmera>
hash tables aren't magic.
<seok>
Right, but you can setf to hash with O(1) too right?
<Bike>
more or less, sure
<phoe>
seok: they're amortized O(1)
<Bike>
you might also want to do things other than retrieve an element
<phoe>
nonetheless, array access usually has a smaller constant factor than hashing
<seok>
phoe: so would that mean arrays are better in smaller sizes but hash better in larger ones?
<phoe>
plus there's very fast iteration if you want to access elements sequentially
frgo has quit [Ping timeout: 260 seconds]
<Bike>
you're not always using them for the same things, so comparing them may not be sensible
<phoe>
seok: not really, I'd say it depends on your use case
<seok>
Shinmera: wow, nice seeing you around, love your work
<oni-on-ion>
=)
<Shinmera>
Thanks!
<seok>
works*
amerlyq has joined #lisp
hhdave_ has joined #lisp
hhdave has quit [Ping timeout: 268 seconds]
hhdave_ is now known as hhdave
<d4ryus>
seok: Depending on use case rehashing might slow things down
EvW has joined #lisp
<seok>
oh ok
zmv has joined #lisp
<Shinmera>
there's also memory adjacency, the fact that you need to hash at all, etc.
<Shinmera>
Then there's a ton of different ways of writing a hash table
<Shinmera>
And it's just not a black and white answer in any way.
<Nilby>
Amortized O(1) + C is slower than exact O(1) + 0, especially when C is related to (length key).
rtra has joined #lisp
<zmv>
Morning, folks.
gnufr33d0m has quit [Quit: gnufr33d0m]
billstclair has quit []
billstclair has joined #lisp
<seok>
hello
rwcom has quit [Read error: Connection reset by peer]
<pfdietz>
Had a case recently where using string-case was much faster than intern, on a set of common symbol names.
<pjb>
seok: and here, you have integers as keys… Any other object would take a lot more time to hash.
<seok>
That is solid evidence, nice job
<pjb>
pfdietz: you can usually exclude a case on 1 char=, and there are a finite number of cases, so you can select the right branch in basically O(1).
<pjb>
finite and fixed, ie. constant number of cases.
LiamH has joined #lisp
<pfdietz>
And you can play games with multiple character comparisons using (logior (logxor ...) (logxor ...) ...), which string-case does.
clothespin has joined #lisp
gjnoonan has quit []
gjnoonan has joined #lisp
decent-username has joined #lisp
<_death>
if the strings are fixed, you could use a perfect hash table
hlavaty has quit [Ping timeout: 260 seconds]
<Nilby>
Thinking about readably printing arrays made me try this experiement. Is there anything I missed? https://termbin.com/82c2
<_death>
if you go that way, you can use #.(make-array ...)
<Nilby>
oh, right, of course
<_death>
also unclear what you get by printing displacement
<_death>
the result of type-of is implementation defined
<Bike>
if you have two arrays displaced to the same array and you have print-circle you can reconstruct their sharing
<Bike>
i guess
<_death>
you don't need total size if you print the dimensions
<Nilby>
I imagine potentially reconstructing the sharing
<_death>
Bike: but then you want an actual displacement reference, rather than printing the data again
<Bike>
also if it is displaced you don't need the data. course you might have to recursively total-array-whatever-print the underlying array
<_death>
also note that multiple displacements
<_death>
*you can have
<Nilby>
Thank you. Now I see how redundant it is. Also I'm considering race conditions.
<_death>
also unclear how useful this is in general
<Nilby>
Yeah. It would be wierd to reconstruct a possibly huge chain of displacements.
<Nilby>
I agree. My feeling is that if it was generally useful, it would be in the standard.
milanj has quit [Read error: Connection reset by peer]
<_death>
in reepca case it was also strange because he has an octet vector.. which usually don't have fill pointers, and usually are printed/read as octets..
milanj has joined #lisp
<reepca>
fill pointer + adjustable was because there isn't a non-blocking way to read more than one byte at a time in usocket
<_death>
maybe try iolib or basic-binary-ipc
<_death>
for adjustable, usually you know (or arrange to know) the size before-hand... for fill pointer, it makes sense, but for octet vectors I would consider having it separate so that you have a simple-array
<boeg>
How does it work when you have function with an argument list like `(defun aname (a (&rest argv) &body body) ()`? Doesn't &rest and &body kinda do the same?
<_death>
boeg: you can't have such a function in CL
<boeg>
(i just saw a piece of code like that in the wild)
<boeg>
oh
<boeg>
weird
<boeg>
_death: it's a macro definition - does that make a difference?
<_death>
boeg: macros can take a destructuring lambda list
<selwyn>
it makes a difference
<boeg>
ah
<boeg>
so how does it work in that case?
clothespin has quit [Ping timeout: 260 seconds]
<Bike>
it means it takes at least two arguments. the second argument is a list and fills argv, while any further arguments fill body.
<Bike>
you can't just ignore the parentheses of (&rest argv).
<boeg>
ah alright
decent-username has quit [Ping timeout: 265 seconds]
<boeg>
makes sense, thank you
<p_l>
I think it would look in use somewhat like (aname first-arg (argv list goes here) body...) ?
<pjb>
Nilby: note that if there's a displacement, you will want to have *print-circle* set to t, and deal with references.
<pjb>
Also, it looks like adjusting a displaced array to another displaced array so that there is a circle leads to an infinite loop.
<Nilby>
pjb: I now see the whole subject is fraught with peril in many ways.
<pjb>
Nilby: The problem is if you want to read back the printed-readably structure. If you just want to describe the structure, you can give all the information (a copy of it). But if you want to load back, you'd have to identify existing objects that are referenced. You get the ORM or OORM problem, with caching, identification of objects, etc…
<pjb>
Nilby: note there's (inspect your-array)
jfb4_ has joined #lisp
jfb4 has quit [Ping timeout: 272 seconds]
<Nilby>
Right. *print-readably* is a bit deceptive and actually a very deep subject.
<Nilby>
My pet peeve with *print-readably* is package prefixes.
flamebeard has quit [Remote host closed the connection]
flamebeard has joined #lisp
vivit has joined #lisp
lavaflow has quit [Ping timeout: 268 seconds]
flamebeard has quit [Remote host closed the connection]
flamebeard has joined #lisp
flamebeard has quit [Remote host closed the connection]
<Xach>
Nilby: how so?
<pjb>
Well, I'm not sure if it's completely specified. But basically, it assumes the current readtable. So if you print a symbol, you might not be able to read it in a different readtable, because it's not printed fully qualified and cased |FOO|:|BAR| would be the most readably. However, since again it depends on the readtable, it depends on the reader macro that could exist on #\|.
<pjb>
So something printed readably is not really stand alone. You must specify along the readtable.
<pjb>
Also, one problem is that most people assume the default readtable.
<Nilby>
Xach: Like the package might not be there or internal vs external may have changed.
<Nilby>
Xach: But if you don't have a package prefix, it might be wrong too.
<Xach>
Nilby: do you know the trick for always printing package prefixes?
random-nick has joined #lisp
dale_ has joined #lisp
dale_ is now known as dale
<_death>
with-standard-io-syntax binds *package* and *readtable* .. though that wouldn't solve all issues of course
<Nilby>
Xach: I'm not sure.
<Nilby>
Is there a trick that (write 'foo :readably t) doesn't do?
<pfdietz>
_death: string-case turns out to be faster than a perfect hash table.
<_death>
pfdietz: could be.. memory access is expensive
ebrasca has joined #lisp
<pfdietz>
I would like to see similar tricks used for intern itself, at least for standardized packages or packages that import from them. Perhaps even dynamic code generation there.
<Xach>
Nilby: bind *package* to the keyword package to always print prefixes
<Nilby>
Nice. I didn't know that. Thanks!
<Xach>
it is a special case in the spec!
<pfdietz>
The special case being keywords are printed with : even if the current package is the keyword package.
<Xach>
pfdietz: that is not the special case I had in mind
<Xach>
Hmm, I can't find the text of the special case I had in mind, so maybe I dreamed it.
picantest has joined #lisp
Achylles has quit [Ping timeout: 272 seconds]
<Nilby>
My dream is to go back to 1994 and add *read-intern* and solve the problem.
<Nilby>
phoe: That's cool. I like the protection from intern bombing.
bumble-bot has joined #lisp
<pfdietz>
Does importing a symbol into a package count as "interning" it? From glossary: intern v.t. 1. (a string in a package) to look up the string in the package, returning either a symbol with that name which was already accessible in the package or a newly created internal symbol of the package with that name.
<pfdietz>
But this does not happen in SBCL when a symbol belonging to another package is imported into the keyword package
<pjb>
pfdietz: yes, in one case: "If any symbol to be imported has no home package (i.e., (symbol-package symbol) => nil), import sets the home package of the symbol to package."
<pjb>
This is why the homeless symbol imported into keyword becomes a symbol. (symbol-value (find-symbol "FOO21312" "KEYWORD")) #| --> :foo21312 |#
<pjb>
<pfdietz>
The standard makes a distinction between being interned in a package, and having a package as the symbol's home package.
<pfdietz>
So I think this is an SBCL bug.
<pjb>
Only for homeless symbols. No bug here.
Achylles has joined #lisp
<pfdietz>
No. Simply importing a symbol into a package counts as interning it in that package.
<Xach>
pfdietz: ???
<pfdietz>
And when a symbol is interned in KEYWORD, certain things have to happen.
<pfdietz>
And they don't.
<pjb>
If the symbol is not homeless then it is NOT interned. It is just present.
<pjb>
But it's a "foreign" symbol, with a different home package.
<pjb>
Only homeless symbols are interned when they are imported.
<Xach>
pfdietz: i want to know more! what should happen?
<pjb>
And when those homeless symbols are imported into keyword, they must become symbols (bound to themselve, become constant variables, exported from keyword). If the implementation doesn't do that in this case, it's a conformity bug.
heisig has quit [Quit: Leaving]
atgreen has joined #lisp
<pfdietz>
What should happen is that the symbol becomes a keyword. For example, it should become a constant that evaluates to itself.
vms14 has joined #lisp
<Xach>
pfdietz: what section is that in? my aimless clicking has failed
hhdave has quit [Read error: Connection reset by peer]
brettgilio has joined #lisp
montaropdf has quit [Quit: WeeChat 2.4]
hhdave has joined #lisp
<Xach>
pfdietz: intern is approximately (or (find-symbol name package) (let ((sym (make-symbol name))) (import sym package) sym))))) - you're arguing that the find-symbol step should also include the work of making the symbol constant, self-valued, and external, if it isn't already?
<pfdietz>
I'd argue import already has to do that.
<Xach>
importing isn't interning - it's part of interning
rwcom has quit [Ping timeout: 268 seconds]
<Xach>
make-symbol is also part of interning
<Xach>
and find-symbol
<pfdietz>
Regardless, SBCL fails to do the special keyword processing even if one subsequently calls intern to get that symbol.
rwcom has joined #lisp
<Xach>
it's kind of regardful, because to get that behavior you'd need to do a lot more work in the find-symbol branch
<Xach>
not that sbcl has shied away from extra work to follow the letter of the standard
bumble-bot has quit [Read error: Connection reset by peer]
Achylles has joined #lisp
<pfdietz>
"unintern removes symbol from package. If symbol is present in package, it is removed from package and also from package's shadowing symbols list if it is present there."
narimiran has quit [Ping timeout: 240 seconds]
<pfdietz>
This implies being present in a package means the symbol is interned in the package.
<Xach>
present means imported
<pfdietz>
Yes
<pfdietz>
As opposed to being accessible merely by means of inheritance from another package via use-package.
<Xach>
you can import without interning, but you can't intern without importing
<Xach>
i wrote a package system so i am familiar with these bits to some degree
<Xach>
or rather, you can intern without importing, if it's accessible already.
<pfdietz>
So there's an inconsistency here between intern and unintern. A symbol could continue be returned by intern even if unintern had been called.
<Xach>
sure - this is one of the examples RG uses ot disparage the package system as a whole
smazga has joined #lisp
<pfdietz>
In any event, even if we take the more restricted defn of interning, that it doesn't include accessible but not present, there's a bug here.
kajo has quit [Ping timeout: 260 seconds]
Bike has quit [Remote host closed the connection]
sjl_ has joined #lisp
pfdietz has quit [Remote host closed the connection]
<Nilby>
I'm thankful they could agree on the flawed package system so at least we're not stuck with problems like Elisp.
pfdietz has joined #lisp
Achylles has quit [Quit: Leaving]
narimiran has joined #lisp
<beach>
Nilby: Why do you consider the package system flawed?
<Nilby>
Well, the most recent example is package local nicknames.
<Nilby>
Another example you've probably considered is implementing something like Emacs's buffer local variables in the CL package system.
<Nilby>
But I still think it's okay, and certainly better than nothing.
atgreen has quit [Ping timeout: 258 seconds]
ggole has quit [Quit: Leaving]
EvW has quit [Ping timeout: 245 seconds]
<Nilby>
Another example is my wish for *read-intern* I linked above.
<_death>
The Package Wars ended, but the CLHS uses humour to commemorate
slyrus has joined #lisp
<beach>
It appears to be a widespread sport to find flaws in the standard, and to wish for the standard to be updated. However, most of the suggestions are made by people (not targeting you Nilby) who know nothing about language design, so they do not know the consequences that their suggestions might have. And they certainly don't know the constraints in the form of historical decisions and time pressure the committee had to deal with.
slyrus__ has quit [Ping timeout: 260 seconds]
<Nilby>
I lost my meta-ctrl-pinky in the package wars.
<aeth>
As far as finding flaws in the package system (or anywhere), I'd look at hacks that people do to work around the lack of features which they wish they had. For packages, I think what's missing is hierarchical packages because the foo/bar naming idiom is so common. This would not be easy to design and add, though.
grabarz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Nilby>
beach: I agree. Every *read-X*, *print-x* variable has consequeces, problems, and trade offs that are difficult to understand.
Odin- has joined #lisp
kajo has joined #lisp
<pjb>
Nilby: HOWEVER, those variables, the printer and the reader, must be understood as development tools, to help debugging (and basically implement the REPL, the debugger, and inspect). They are not industry streight tools to use in your applications. For your application, it is understood that you will have to implement your own I/O and validation functions!
Bike has joined #lisp
vivit has quit [Ping timeout: 272 seconds]
<beach>
aeth: So for example, the existence of all those people who wish that SYMBOL-VALUE, EVAL, etc. had access to lexical variables would indicate a flaw in the standard. And we should fix it, thereby making compilation of Common Lisp essentially impossible.
vivit has joined #lisp
<Bike>
i think the package system problems people usually identify aren't quite like that.
hydan has quit []
hydan has joined #lisp
<beach>
All I am saying is that there is often more to it than just lamenting the lack of a particular feature.
<beach>
ralt: Such code is very likely to create conflicts.
<_death>
code like this is why PLN should exist :)
<beach>
Package-local nicknames solve a real problem. But that does not imply that the standard is flawed.
<ralt>
PLN?
vms14 has quit [Remote host closed the connection]
<ralt>
ah, package-local nicknames
<ralt>
the standard doesn't have to mean an exhaustive standard library to me
Oddity has quit [Read error: Connection reset by peer]
<beach>
ralt: Exactly. And that is particularly clear when you notice that people use languages on a daily basis that don't even HAVE a standard.
<_death>
wrt to packages, there are much easier targets to criticize..
<beach>
_death: Sure, but it gets boring, is what I am saying.
<ralt>
something that _is_ a bit odd with Lisp, is that as opposed to many languages, anything can be outside of the standard. In many languages, if it's not supported by the language, you're SOL, so there is often a strong argument to put that in the main place. Not so for Lisp.
<ralt>
almost anything*
oni-on-ion has quit [Remote host closed the connection]
<Xach>
pfdietz: if you define an "interned symbol" as one that was created through the intern process I think you can rationalize the current behavior.
oni-on-ion has joined #lisp
<Xach>
that is, "interned in X" meaning "created by (intern name X)"
<_death>
beach: I wonder whether the Chapter 11 joke was an anachronism
<ralt>
my personal pet peeve is related to pathnames/folders/trailing slash...
<beach>
_death: I must be tired (after a long day), but I don't know what joke you are referring to.
<Nilby>
Thankfully packages aren't likely to be completely bankrupt any time soon.
<beach>
Ah, I think I understand.
<_death>
beach: it's US-centric joke.. in the US "chapter 11" means bankcruptcy.. the CLHS Packages chapter is chapter 11.. during the package flamewars associations were made
<beach>
I see, I see. Thanks.
Oddity has joined #lisp
<beach>
So anyway, there are very few things in the standard that prevent me from doing my work, and those that do are easy to get around. At the same time, there is a lot of work to be done with what the standard provides.
moldybits has joined #lisp
jtecca has quit [Ping timeout: 268 seconds]
Khisanth has quit [Ping timeout: 240 seconds]
davepdotorg has quit [Remote host closed the connection]
Khisanth has joined #lisp
hhdave has quit [Quit: hhdave]
<pfdietz>
There are problems with the standard, but you have to have some experience to find the real ones.
<beach>
Well put.
<pfdietz>
Example of a non-problem: "it's not a Lisp-1".
<pfdietz>
Another large class of problems are things that are problems, but not significant ones. Edge cases that language lawyers enjoy but that have little practical importance.
<Bike>
i'm good at those.
atgreen has joined #lisp
<pfdietz>
If I had to choose between "fixing/expanding the standard" and "fixing/expanding available libraries", I go with the latter in a heartbeat. Admittedly, the boundary is a bit blurry.
atgreen` has joined #lisp
oni-on-ion has quit [Read error: Connection reset by peer]
oni-on-ion has joined #lisp
bumble-bot has joined #lisp
atgreen has quit [Ping timeout: 260 seconds]
atgreen`` has joined #lisp
rtra has quit [Ping timeout: 258 seconds]
atgreen`` has quit [Remote host closed the connection]
atgreen` has quit [Remote host closed the connection]
rtra has joined #lisp
<galdor>
do you consider introducing packages that all implementations implement the same way "expanding the standard" ?
oni-on-ion has quit [Ping timeout: 265 seconds]
<beach>
No, that's just "widely agreed-upon libraries". There are plenty of those, and they are good.
<galdor>
if you take bordeaux threads, I find it curious to end up with a library instead of having implementations follow the bordeaux thread pseudo standard, which would allow every one to use, e.g. threads:make-thread without having to import a library
lukego has quit []
<beach>
galdor: It is much easier to use a library than to convince all the maintainers of all the implementations to add the same thing.
lukego has joined #lisp
<Shinmera>
not to mention convincing them to possibly change an interface if they already have users for it.
<pfdietz>
That's the blurry part. Are de facto standard libraries part of the standard? I'll go with whatever answer makes things easier.
<galdor>
easier sure, but then you end up with a local maximum which will not move
<pfdietz>
Having a better social process for creating standard libraries, now that's interesting and useful.
<Shinmera>
galdor: I'm sure people would prefer it if all implementations offered all of the possible features.
<galdor>
and these libraries are external, generally maintained by zero to one person
<Shinmera>
I feel like you're vastly underestimating the effort involved in that.
<pfdietz>
Having better use of standard libraries (for example, encourage explicit import rather than :use) would be valuable.
<galdor>
oh I get the idea
<Nilby>
And overestimating the resources available to do so.
<galdor>
in practice, the thing is that the vast majority of implementations won't change anything because they are in low maintainance mode and won't ever evolve
pent has quit []
<galdor>
so you're stuck with the situation
pent has joined #lisp
<Xach>
galdor: i don't think that's the case
<galdor>
but at some point, who cares if only 2 or 3 implementations do the work, others are dead anyway
<Xach>
the conditions for change vary but I don't think it's the case that they won't change anything.
<pfdietz>
They keep extending C and C++ even though each of those has large numbers of effectively dead compilers.
<Shinmera>
For example, I think by now only Allegro is lacking PLNs (and hasn't announced adding them)
<Shinmera>
Hmm, and Clisp, I think.
<galdor>
technically it's not yet in CCL, there are no stable releases with PLN ^^
<Shinmera>
Sure, same with LW
<galdor>
as for Allegro and LW, I'd honestly love to know at which point they actually have a tech roadmap on their implementations or if they just rack up license fees with old clients (not that there is anything wrong with that)
bumble-bot has quit [Read error: Connection reset by peer]
kmeow has quit [Quit: Leaving]
jfb4 has joined #lisp
jfb4_ has quit [Ping timeout: 265 seconds]
william1_ has joined #lisp
mingus has quit [Read error: Connection reset by peer]
<p_l>
galdor: Franz is actively doing a second-hand lisp business in the form of selling stuff built on top of AllegroGraph
picantest has left #lisp ["Leaving"]
william1_ has quit [Ping timeout: 272 seconds]
picantest has joined #lisp
m00natic has quit [Read error: Connection reset by peer]
<pfdietz>
the interesting question is to what extent Franz depends on external libraries that may stop working for them because of PLNs
rtra has quit [Ping timeout: 258 seconds]
nowhere_man has joined #lisp
<galdor>
is it me but do they both (Franz and LW) stay way out of the open source world ?