<mfiano>
I had to do a double take when something didn't make sense.
<beach>
I am confused. That file should no longer exist.
<phoe>
beach: I'm linking to an old commit, maybe that is the case
<phoe>
oh shit, I should not be making an issue then!
<mfiano>
:D
<phoe>
beach: what's the current proper part of Cleavir then?
<beach>
There is a CANONICALIZE-DESTRUCTURING-LAMBDA-LIST in Cleavir/Code-utilities/lambda-list.lisp
<phoe>
thanks
<mfiano>
Oh that might not be what I want. I'm not looking to put it into any canonical form. I don't know if what I'll be receiving is even a valid D-L-L, or even if it's a list.
<phoe>
I assume you can stuff if in IGNORE-ERRORS and use this as a boolean function
<phoe>
(after handling the null list case)
<mfiano>
I'm not sure what sort of checks have to be made for a D-L-L to be used, and more importantly, used as intended in a generated D-B form.
<phoe>
the logic still seems to be there IIUC, it's just named differently
<beach>
I would rather encourage the use of scymtym's s-expression-syntax library.
jolby has joined #commonlisp
<beach>
In fact, it is entirely possible that this code will be removed from SICL in the future, in favor of that library.
<mfiano>
Gotcha ok, thanks. I'll add them to my notes with the preference of scymtym's library. That is all I need for now :)
<beach>
Well, it is being worked on, so I am counting on it to be usable, if not now, then very soon.
<phoe>
yes, I see
<beach>
And that library has the potential of centralizing a lot of processing that is now done separately in many places.
<beach>
But the ambition level is high, so it might not be entirely "finished" even when it is usable.
<mfiano>
But can it be recommended for casual use now, without constant fixing, which may result in major refactoring of dependent code? I imagine that it will be very useful, but I am unsure of it's current status. Such a library could have very deep/wide dependents
<mfiano>
its*
mingus has joined #commonlisp
ec has quit [Ping timeout: 255 seconds]
frgo has quit [Ping timeout: 256 seconds]
ec has joined #commonlisp
sunarch has quit [Read error: Software caused connection abort]
sunarch has joined #commonlisp
<beach>
You need to ask scymtym about that.
<mfiano>
Ok, thank you. It is nothing urgent. I'm just taking notes for a design document, and I'm sure they will respond or it will be ready before it is ever going to be a problem, at the rate I am going, anyway.
<beach>
That's a package name, and it is important to make those unique, perhaps even globally if you want other to use the code.
<euouae>
I'm trying to recall what this naming scheme is called. I know I've seen it before in a different context
<beach>
I don't recall a particular name for it.
<euouae>
Maybe it's called a "Distinguished Name"
<euouae>
Is the user then to use these names? Or does the library somehow remedy the verbosity problem?
<beach>
Many people use package-local nicknames these days.
<euouae>
I agree
<beach>
Then you can use whatever name you like to replace the longer one.
Dynom_ has joined #commonlisp
Dynom_ is now known as Guest1376
<euouae>
Another question, in unit tests, what is the right way to use other libraries? :use or :import-from, etc?
<phoe>
:local-nicknames
<euouae>
I've done a bit of reading about symbols, packages, and asdf systems and I can't think of any problem with either, but I do find discussion online about it
<phoe>
:USE means that your tests may accidentally overwrite stuff from the external package, :IMPORT-FROM has the same risk except on a smaller scale
<phoe>
I find it much better to always explicitly qualify the package under test, and local nicknames are perfect for this
<euouae>
Wouldn't it trigger a symbol clash phoe?
<euouae>
or e.g. a duplicate DEFVAR?
<phoe>
a symbol clash where?
<euouae>
I'm not sure how the accidental overwrite happens with :use
<phoe>
(defpackage #:foo (:export :bar)) (in-package #:foo) (defun bar ...) (defpackage #:foo-test (:use #:cl :foo)) (in-package #:foo-test) (defun bar ...)
<euouae>
ah, and then :foo uses foo-test::bar instead of its own
<euouae>
or is it just that foo:bar is not available to :foo-test?
<phoe>
not really, then the second (defun bar ...) is actually (defun foo:bar ...)
<phoe>
which will clobber the original fdefinition from FOO
<euouae>
does this affect FOO or FOO-TEST only?
shka has joined #commonlisp
<euouae>
it affects everyone right? the value of the symbol changed
<phoe>
everyone
azimut has quit [Remote host closed the connection]
<phoe>
accidental clobbering is a possible problem
<euouae>
Thanks for that example
<phoe>
:USE is dangerous like that
<phoe>
whereas local nicknames don't have that sort of risk because you immediately see that f:foo is a symbol from a (most likely) different package
<euouae>
now I'm trying to think why :use is more dangerous than :import e.g.
<phoe>
because with :import you only import a predefined set of keywords
<euouae>
ah right
<phoe>
so you can try to remember that e.g. BAR is imported and try not to touch it
<phoe>
whereas :USE imports everything and the kitchen sink, everything that the other package exports
<phoe>
so if the other package starts exporting e.g. BAZ
<phoe>
and you have (DEFUN BAZ ...) in your code
<phoe>
then a change in definition of package FOO can cause your code in package BAR to break package FOO
Cymew has joined #commonlisp
azimut has joined #commonlisp
<beach>
Well, :USE technically doesn't import anything, but makes all the exported symbols available.
<phoe>
and everything that depends on it
<phoe>
beach: thanks for the correction
<euouae>
Yeah I understand, it makes them accessible
<euouae>
isn't there :import and :import-from?
<phoe>
nope, just :IMPORT-FROM
<euouae>
ah alright, thanks
<phoe>
but there's also the function CL:IMPORT
<euouae>
yes
<euouae>
is 'clobber' a common word in lisp?
<euouae>
I'd say overwrite, but I wonder if that's a common term
<phoe>
yeah, sort of
<euouae>
thanks for the help
<phoe>
AFAIK it's used as a term for redefining stuff you shouldn't really be redefining, either because you aren't allowed to do it (such as definitions from packages you don't own) or because it might cause trouble (e.g. type proclamations for already typed functions)
<mfiano>
euouae: I think your original question got lost in a discussion about package-local nicknames. That notation is usually called "reverse domain name notation".
<euouae>
mfiano: ah thanks. I'm trying to recall where I've encountered it. It might've been when reading on X.509 or vendor names in hardware products. I'm not really sure
<euouae>
I specifically remember the bit about the US gov having one, but I just can't recall what it was
<euouae>
phoe, in your original code, #:foo needs to use :CL otherwise I can't DEFUN right?
<mfiano>
It's ubiquitous in Java, and some other languages. Not so much in CL, but it is a good way to ensure your package name is unique, which is required for a Lisp image to be able to load with all the other software it might depend on.
<mfiano>
THat particular notation or whatever doesn't matter. If it's unique, then good. PLNs can do the rest.
<beach>
euouae: You almost always want to :USE the COMMON-LISP package.
<phoe>
euouae: not having any :USE leads to unspecified behavior
<phoe>
the implementation can provide anything at that point - it can be equivalent to (:USE), (:USE :CL), (:USE :CL :CCL) and what else
<euouae>
I was just asking about your defpackage foo above
<phoe>
so, I guess, you want to explicitly specify :USE every time
<euouae>
it was (defpackage #:foo (:export :bar))
<phoe>
oh wait, yes
<phoe>
I should have (:use :cl) there
<euouae>
alright, just checking
<euouae>
because I was going to share that example with someone to also help them
<thuna`>
:ccl?
<beach>
euouae: Perhaps you should tell that someone to join #clschool.
<euouae>
beach, perhaps but it might come off the wrong way
<euouae>
It's a delicate situation when you're in a group setting, how you talk
<euouae>
Ultimately the goal is to get the job done
<phoe>
this is what happens on Clozure Common Lisp
<phoe>
so, yes
<phoe>
even packages you aren't aware of can get pulled in this way
<thuna`>
Huh
<euouae>
another thing:
<euouae>
I've been writing a random-package library. Any suggestions welcome. So far I have a function that creates N packages with (I, E) internal and external symbols, and associations between them on how many symbols are imported and how many inherited
<euouae>
It would be used for unit testing. It would be similar to random filesystems that people use in unit testing libraries
<phoe>
okay, I can understand everything so far
<euouae>
That's good :) Well, any suggestions welcome really
<phoe>
what is the question though?
<euouae>
In question form it would be "What features would be useful in this library?"
<phoe>
I'd ask the people who actually have use cases for that sort of testing
<euouae>
not sure if there's any
<euouae>
It's just an open source project I'm working on
<euouae>
but I might try to use it for another open source project. So you make a good point, I could cater to those needs
<phoe>
then it sounds like mental gymnastics :D
<phoe>
which isn't bad tbh, especially if it's fun and if you learn things along the way
<euouae>
yeah...
<phoe>
and maybe someone will need such a lib in the future, especially if they end up writing some sort of package management library or some sort of "overlay" above the package system
<phoe>
which isn't entirely implausible, I've seen things like that such as tfeb's conduit-packages
<euouae>
I'd like my randomized package library to be able to express all possible situations, or bare mininum the usual situations
<phoe>
being able to get a random set of packages with predefined behavior wrt their symbols and relationships would be a time-saver for testing such libraries
thuna` has quit [Ping timeout: 260 seconds]
<phoe>
s/behavior/contents/
<phoe>
so, mental gymnastics is one thing, I can see how that could be useful
<euouae>
yeah! good point. now I'm only working on the symbols themselves but their values should be randomized too
<euouae>
thanks! awesome
<phoe>
values? oh boy, that's getting complicated
<phoe>
the package system is one thing, namespaces is another
<euouae>
I'll do what I can and then leave it up to whoever wants to add/complete the features
<phoe>
because "values" can relate to variables, functions, classes and what not
<phoe>
and it's kind of an orthogonal issue
<euouae>
well I'm not trying to come up with (random-lisp-image)
<phoe>
:D
thuna` has joined #commonlisp
thuna` has quit [Remote host closed the connection]
thuna` has joined #commonlisp
jolby has quit [Quit: Client closed]
rainthree has joined #commonlisp
sedzcat has joined #commonlisp
scymtym has joined #commonlisp
<euouae>
can I collect values into a list? other than multiple-value-bind?
<euouae>
or is it (multiple-value-bind (&rest rest) (my-function) (apply #'list rest))?
<beach>
euouae: The way you do this is you go to the permuted index, and look for (say) "multiple".
<euouae>
I tried to look up 'values'
<scymtym>
phoe: s-expression-syntax aims to be the eclector of, well, s-expression syntax (as opposed to character syntax). https://techfak.de/~jmoringe/semantic-highlighting.ogv shows a testbed thing that uses eclector and the s-expression-syntax library (and some additional stuff)
jello_pudding has quit [Ping timeout: 260 seconds]
jello_pudding has joined #commonlisp
pve has joined #commonlisp
mingus1 has joined #commonlisp
mingus has quit [Ping timeout: 260 seconds]
mingus1 is now known as mingus
Bung has joined #commonlisp
jmdaemon has quit [Ping timeout: 260 seconds]
euouae has quit [Ping timeout: 268 seconds]
Bunggg has joined #commonlisp
Bung has quit [Ping timeout: 255 seconds]
euouae has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 252 seconds]
MajorBiscuit has joined #commonlisp
morganw has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 260 seconds]
Bunggg has quit [Remote host closed the connection]
Bunggg has joined #commonlisp
MajorBiscuit has joined #commonlisp
Bunggg has quit [Remote host closed the connection]
Bunggg has joined #commonlisp
ec has quit [Ping timeout: 255 seconds]
random-nick has joined #commonlisp
ec has joined #commonlisp
jeosol has quit [Quit: Client closed]
Bunggg has quit [Remote host closed the connection]
azimut has quit [Remote host closed the connection]
tevo has quit [Ping timeout: 256 seconds]
Bunggg has joined #commonlisp
azimut has joined #commonlisp
glaucon has joined #commonlisp
rendar_ has quit [Quit: Leaving]
rendar has joined #commonlisp
rendar has joined #commonlisp
<thuna`>
Why is generic-cl not the default? As in, why does the standard not have the common functions as generic?
<phoe>
your question number 1 is answered by question number 2
<thuna`>
My question 1 was a rephrased version of question 2
<phoe>
and the question number 2 is answered by "for speed, but then again, nothing prevents the standard from implementing standard functions via GFs"
<phoe>
AFAIK that's what SICL does under the hood
<thuna`>
So... basically for no reason?
<phoe>
it would be much more complicated implementation-wise and slower to keep everything generic
<thuna`>
Wouldn't the common optimization strategies work just fine with generic functions?
<phoe>
no
<phoe>
GFs can have new functionality plugged into them at runtime
<thuna`>
Oh, :before, :after, and so on?
<_death>
it's silly to blindly make a function generic.. for some functions you want the behavior to be fixed.. also a generic function is supposed to satisfy two different audiences (callers and extenders) and often you wish to separate these concerns
<phoe>
and also even if you implemented CL=+ via (defgeneric binary-+ (a b)) then you'd need to do method dispatch on every call
<phoe>
because, by definition, you can (defmethod generic-+ ((a my-number) (b my-number)) ...) at runtime and all existing invocations of + will need to take this new method into account
<thuna`>
Isn't this also true for normal functions?
<phoe>
no?
<phoe>
normal CL:+ will never need to care about MY-NUMBER
<phoe>
it'll just signal an error and let you deal with the fallout
<thuna`>
What's stopping me from doing (defun + (a b)...) at runtime (besides the lock)
<phoe>
of course, you can shadow CL:+ and define your own MY-PACKAGE:+
<thuna`>
Ok but that's just a matter of rewriting the standard.
<phoe>
but that's a completely different function that the rest of the world won't care about
<phoe>
no
<phoe>
it's a matter of changing the specification AND getting it adopted
<phoe>
the former is trivial, it's just a text document
<eta>
thuna`: like, why would you want to make this change?
<eta>
this destroys the optimizing compiler's ability to optimize calls to CL:+
<phoe>
the latter is convincing eight implementations to support it
<phoe>
and what eta just mentioned, you've just destroyed a good chunk of CL numerical performance
<thuna`>
My point is, if I (against all common sense), redefine +, the new definition will be called whenever + is called
<phoe>
no
Bunggg has quit [Quit: Leaving]
<phoe>
you are in undefined behavior zone and anything can happen
<eta>
thuna`: no, since functions could already have been optimised to a machine instruction for adding or something
<phoe>
and each implementation will do something else
<phoe>
especially since CL:+ is allowed to be open-coded, so the actual function #'+ may not even be called
<phoe>
(as with all CL functions)
<thuna`>
Alright, forget about CL: for a second
<phoe>
okay
<thuna`>
If I have the normal function FOO:BAR, every call for that should (to reflect my runtime changes) check the current definition
<thuna`>
How is this in any way different from redefining the method?
<phoe>
yes, unless the call was requested to be inlined via DECLARE INLINE and the compiler actually inlined it, or if there was a compiler macro that the compiler used
<thuna`>
Alright, sure, but we can do the same for generic functions if we optimized for specific types
<phoe>
thuna`: you are omitting the cost of generic dispatch
<jackdaniel>
actually unless it is declared notinline it may be always inlined
<thuna`>
Can we not already determine what type an object is supposed to be at any point in the code (even if it's T)?
pranavats has left #commonlisp [Error from remote client]
<phoe>
thuna`: an object can be of infinitely many types, that's one problem
pranavats has joined #commonlisp
<phoe>
second, as you mentioned, the value of evaluating (cl:read) must be T
<thuna`>
Ah, damn. I gotta go for a while, even though I want to keep this going. Sorry
<phoe>
continue later then!
<phoe>
see you
<jackdaniel>
yeah, that's how it is. unless you say notinline, the compiler may do just that
thuna` has quit [Quit: oops]
<AadVersteden[m]>
Anyone here use Dexador with a connection pool with success? Any other comparatively fast http clients known? I'm executing many HTTP 1.1 POST requests to the same host.
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
<AadVersteden[m]>
When I enable the connection pool, requests are substantially slower. It's not clear to me how I could debug.
<Bike>
extensible design takes more thought than just making everything generic. for example, standard + is commutative, and compilers can leverage this to reorder arguments. e.g. (+ 4 x y 8.8) can be constant folded to (+ 12.8 x y). if + was simply made generic, with no further organization, the compiler would have to drop this assumption and leave the code as-is. at best it could reorder when it could
<Bike>
determine x and y are reals, which it could not always do.
<Bike>
this isn't to say making the language more generic is impossible. just that doing so is more involved than slapping defgeneric on everything
euouae has quit [Ping timeout: 268 seconds]
<scymtym>
one could demand that methods on BINARY-+ can only be specialized to classes that are disjoint from NUMBER. that way, the compiler could apply its usual optimizations and only call the generic variant on non-numbers (where it would currently signal a type error). however, even with that restriction, the assumption that BINARY-+ /returns/ a NUMBER would no longer be true and that would also inhibit optimizations
<Nilby>
So is it really true that if I want to publish stuff I have to rename all of my hundreds of .asd files like org.long-ass-bullshit.fuxored-garbage.asd, or arrogantly take the name garbage.asd forever?
<phoe>
the former is nicer, but the latter is the status quo
<phoe>
I don't think either of my systems on quicklisp uses FQDNs
<scymtym>
alternatively, new numeric types could be required to be subclasses of NUMBER, but that would destroy the compiler's ability to reason based on the fact that the numeric types form a partition of NUMBER
<phoe>
scymtym: STANDARD-NUMBER would need to become a thing
<phoe>
or, using SBCL terminology, HAIRY-NUMBER
<phoe>
where NUMBER would then be (OR STANDARD-NUMBER HAIRY-NUMBER)
<phoe>
but even that would destroy optimizations, as you mentioned
pranavats has left #commonlisp [Error from remote client]
<yitzi>
Nilby: I despise FQDN in lisp system or package names. I try to pick a semi-unique and not too long name for my projects.
<Nilby>
yitzi: I despise them too, but I'm thinking of publishing something with 100's of systems, which already have numerous clashes with quicklisp.
<yitzi>
100's of systems? Whoa. Is that needed? .... but aside from your own design choices I usually keep to main-sys, main-sys/test, main-sys/other, bla.
<Nilby>
Unless I ditch using asdf altogether and come up with my own quirky loader, hwhich I really don't want to do.
<Nilby>
On the other hand, somehow emacs has survived all these years without FQDN package names.
<Nilby>
and 5k packages in my (list-packages)
tyson2 has joined #commonlisp
attila_lendvai has joined #commonlisp
dipper has joined #commonlisp
Guest268987 has joined #commonlisp
<pjb>
yitzi: yeah, semi-unique like the half-dozen clon systems, or cl-josn systems…
<yitzi>
pjb: Not sure I understand your point beyond "naming is hard?"
<Nilby>
I guess there's not really much risk of me publishing anyway. and why uselessly clutter quicklisp.
<Nilby>
I guess there's always rename-package…
<Nilby>
but it's the system/filename namespace that really bugs me
<_death>
nilby-foo
<Nilby>
_death: yes, I think that's what I'll do. if emacs can do it with a zillion helm-* packages
Bung has joined #commonlisp
Bung has quit [Remote host closed the connection]
Bung has joined #commonlisp
<AadVersteden[m]>
Nilby: Emacs code makes me question all the design rules I've learned.
<AadVersteden[m]>
It would be nice if there were some sort of project-local-nicknames. I have no clue how such a thing should work, but it would be nice to have project-wide nicknames for packages and symbols.
Posterdati has joined #commonlisp
<_death>
needing more and more context when you see a reference doesn't strike me as ideal
attila_lendvai has quit [Ping timeout: 252 seconds]
<phoe>
project-wide? you mean spanning multiple packages?
Bung has quit [Remote host closed the connection]
ec has quit [Ping timeout: 255 seconds]
Bung has joined #commonlisp
ec has joined #commonlisp
euouae has joined #commonlisp
attila_lendvai has joined #commonlisp
azimut has quit [Ping timeout: 255 seconds]
<AadVersteden[m]>
phoe: Yes. They're different solutions but if we want to use FQDNs then you probably want shorter names within a project.
azimut has joined #commonlisp
causal has joined #commonlisp
<Bike>
i think really hierarchical package local nicknames might be nice - so you could do like foo:bar:baz to mean the symbol named BAZ in the package locally nicknamed BAR in the package named FOO. but despite working on pretty large systems i don't think i've ever really needed anything like them so far.
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
Guest268987 has quit [Ping timeout: 268 seconds]
cage has joined #commonlisp
random-nick has quit [Ping timeout: 260 seconds]
dipper has quit [Remote host closed the connection]
attila_lendvai has quit [Ping timeout: 268 seconds]
eddof13 has joined #commonlisp
<mariari>
AadVersteden[m]: I was thinking about making a system that could withstand such a thing, basically each project has a view of the package space, and extends some default package space with each import. When the project is exported, only the functions it defines are brought over, and you could simply just qualify everything added by this system
attila_lendvai has joined #commonlisp
NotThatRPG has joined #commonlisp
eddof13 has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
attila_lendvai has quit [Ping timeout: 240 seconds]
<Josh_2>
AadVersteden[m]: The connection pool is enabled by default
<AadVersteden[m]>
Josh_2: Yup! But disabling it yields substantially better performance.
<Josh_2>
Perhaps you could make an issue
waleee has joined #commonlisp
<AadVersteden[m]>
Josh_2: I'm not sure how to debug, but yes. Was hoping on some pointers here.
<pdietz>
euouae: `(apply #'list rest)` ==> just `rest`
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
<pdietz>
thuna`, phoe: I do wish the standard would allow users to define new methods for functions like + (and that + was generic). If this was prohibited from changing the behavior on standard classes, it need not affect performance at all.
<beach>
pdietz: You can't really make + itself generic, because of the variable number of arguments.
<phoe>
beach: you could work around it by making binary-+ generic I guess, or by doing something even more clever
<phoe>
and have + call binary-+ in the most generic case
<beach>
phoe: That's why I explicitly said "itself".
<pjb>
yitzi: my point is that to advance is a state changing verb, so a function named advance-state must mutate a state. If you only compute a new state without mutating the previous state, then call it next-state.
<pjb>
yitzi: if you want, naming is not hard if you stay logical.
<phoe>
beach: OK, I see now
<beach>
As I recall, Dylan explicitly requires some binary-+ to exist, and it is defined to be generic.
<pjb>
pdietz: unless, of course, you want to reject lists greater than call-argument-limit elements, while making a copy of the smaller lists.
<pjb>
euouae: ^
<ecraven>
It's been a long time, but I found Dylan to be very interesting regarding the design of its generic functions and collection library
<_death>
once upon a time there was a language called GOO
<pjb>
euouae: it uses the test argument as a key in a map to the actual hash function.
<beach>
euouae: It does it by allowing only a few choices.
<euouae>
Isn't every object possible to have as key beach?
<euouae>
pbj, I don't understand
<beach>
Sure. It derives a hash function from the equality function.
<euouae>
but how?
<pjb>
euouae: (cond ((or (eql test 'eql) (eql test #'eql)) (function eql-hash))
<pjb>
(t (error "Bad :test argument")))
<pjb>
((or (eql test 'equal) (eql test #'equal)) (function equal-hash))
<pjb>
((or (eql test 'equalp) (eql test #'equalp)) (function equalp-hash))
<beach>
euouae: It basically follows the definition of the equality predicate. Like, if it is EQUAL, it uses the hash value of things like symbols and characters, but not of CONS cells.
<pjb>
then it uses this to compute the hash: (funcall … key)
<euouae>
Ah now I get it. I didn't know :test isn't allowed to be arbitrary
<beach>
pjb: euouae is asking how it is done.
<beach>
euouae: That's why I told you to read that line.
<beach>
And you said you did.
<AadVersteden[m]>
euouae: that also tripped me up at some point :-)
<pjb>
what's a little puzzling, is that it allows the actual functions #'eql, #'equal and #'equalp, when it's only a discrete choice (member eql equal equalp) would have been a better type for this argument.
<euouae>
beach, I did not realize
<_death>
for this reason my style is to never use :test #'foo but :test 'foo
<pjb>
exactly.
pdietz has joined #commonlisp
<pdietz>
Yes you can
<beach>
_death: I don't understand the reason. Can you elaborate?
<pdietz>
The four allowed :test arguments are eq, eql, equal, and equalp (and their actual functions).
<pjb>
Oh, right eq is also allowed. Sorry.
<pjb>
I tend to forget EQ.
<pdietz>
That
<pdietz>
's usually the right thing to do
<pjb>
beach: if you think you're allowed to pass a function, you can easily think you're allowed to pass ANY function.
<euouae>
beach my bad
<beach>
pjb: Oh, I see.
<_death>
beach: generally I'd expect that if you can pass a function, you can pass any function that satisfies a signature, and not one that needs to be a member of a fixed set
<beach>
Yes, I see.
chrcav has joined #commonlisp
<mariari>
pdietz: is this true in general for most CL functions, or only for MAKE-HASH-TABLE
<pjb>
IIRC, make-hash-table is the only function that has a :test like that.
<beach>
mariari: "this"?
<pdietz>
make-hash-table is special, since it needs to infer some things from the test function.
<pjb>
For all other function you can pass any function you want (with limitations) to :test (and :key).
<jackdaniel>
different hashing functions are used for different tests
<mariari>
beach: the 'eql versus #'eql, I've always used #'eql
<pdietz>
Really, you want to pass a hash function, and a test, and maybe a canonicalizer for keys. Some sort of combination of those things. Smells categorical.
<jackdaniel>
that said at least ccl, ecl and sbcl allow adding new tests for make-hash-table (when paired with an appropriate hashing one)
<beach>
mariari: Most functions take a "function designator", so both a symbol and a function is allowed.
jolby has joined #commonlisp
<beach>
mariari: Be careful though. The symbol always refers to the global function, so if you want to use a local function (introduced by FLET or LABELS), you need to use the #' version.
<mariari>
ahh yes that was the edge case I ran into years ago, and why I always defaulted to using #'
<_death>
I was talking about make-hash-table in particular
<mariari>
_death: yes that was why I was curious, as in that case you are correct ' is better than #' due to the implication
<mariari>
however I was unaware if this rule existed for any function other than make-hash-table
sunset_NOVA has joined #commonlisp
<beach>
I use the symbol only when I want to refer to one of my own functions that may later be redefined.
<pjb>
beach: yes, but arguably, hash-table doesn't need to call the test function (designator). It would always use it thru a CASE or COND to select the right code.
<pjb>
I guess it's just a remain of the standardization process, where some old lisp used #'equal while others used 'equal.
<beach>
That sounds plausible.
<pdietz>
There are also extended function designators but I don't think most standard functions that take function arguments accept those.
<euouae>
how does with-hash-table-iterator have a declaration* in its argument?
<euouae>
how can I do that to my own macros? or is it a macro thing that all macros have?
<beach>
You make the macro expand to a form that takes a declaration.
<euouae>
do I need additinal arguments?
<euouae>
(defmacro with-edge-iterator (name graph &body body) `(with-hash-table-iterator ,name (edges ,graph) ,@body)) would do it?
<beach>
No, the macro handles it just like any other expression.
Bung has quit [Remote host closed the connection]
<euouae>
I see
<pdietz>
In that sort of macro you typically have a body that is like the body of a LET. It should start with declarations. The macro expansion you define would then stick that body into a place where declarations are allowed.
<_death>
Josh_2: it's useful if you want to iterate through multiple hash tables in parallel
Oladon has joined #commonlisp
<_death>
though you can't rely on any order so still rather limited
rainthree has quit [Read error: Connection reset by peer]
rainthree has joined #commonlisp
<pjb>
It's too bad that the iterator (generator-fn) is limited to the scope (I would have prefered a make-hash-table-iterator), since hash-table are opaque and implementation dependent. You can easily implement make-{list,a-list,p-list,vector,array,etc}-iterator.
rainthree has quit [Remote host closed the connection]
<_death>
pjb: yeah.. also w-h-t-i introduces a local macro, that you may need to wrap a call to in order to pass a function around (within the dynamic extent constraint)
rainthree has joined #commonlisp
<euouae>
What do you mean? That you want the iterator outside the macro body?
<euouae>
@pjb
<pjb>
euouae: yes. So you may advance at your leisure. Like with C++ iterators.
<euouae>
Yeah indeed. Leisure time only within macro body I suppose
<pjb>
You can pass iterators to other algorithms.
<pjb>
or even store them in data structures.
<euouae>
right
<euouae>
oh well it'll have to do for now
jolby has quit [Quit: Client closed]
pdietz has quit [Ping timeout: 260 seconds]
<_death>
pjb: then again storing them could also expose one to iterator invalidation trouble.. so maybe encouragement of limited extent is not so bad
<pjb>
Indeed.
NotThatRPG has quit [Ping timeout: 268 seconds]
<euouae>
is the pattern (setf place (f place)) common?
<jcowan>
A classic application of arenas is a compiler, where you create a tree representing the source code allocated in an arena, and then you create a second tree allocated in another arena, after which you can discard the first arena, and so on until you are done
<jcowan>
s/\(representing the source code\)\(allocated in an arena)/\2\1
<euouae>
beach, nice thanks
<beach>
Sure.
Bung has quit [Remote host closed the connection]
tevo has joined #commonlisp
terrorjack has quit [Ping timeout: 260 seconds]
NotThatRPG has joined #commonlisp
waleee has quit [Ping timeout: 256 seconds]
terrorjack has joined #commonlisp
ttree has joined #commonlisp
Bung has joined #commonlisp
waleee has joined #commonlisp
Guest268987 has quit [Ping timeout: 256 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.6]
gxt has quit [Remote host closed the connection]
pranavats has left #commonlisp [Disconnected: Hibernating too long]
Krystof has quit [Ping timeout: 260 seconds]
gxt has joined #commonlisp
Bung has quit [Remote host closed the connection]
Bung has joined #commonlisp
tormenatur has quit [Quit: Connection closed for inactivity]
rgherdt has joined #commonlisp
jolby has joined #commonlisp
jmdaemon has joined #commonlisp
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
NotThatRPG has joined #commonlisp
euandreh2 has joined #commonlisp
euandreh has quit [Ping timeout: 260 seconds]
euandreh2 is now known as euandreh
euandreh has quit [Client Quit]
notzmv has quit [Ping timeout: 256 seconds]
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
NotThatRPG has joined #commonlisp
Oladon has quit [Quit: Leaving.]
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ecraven has quit [Ping timeout: 246 seconds]
pranavats has joined #commonlisp
NotThatRPG has joined #commonlisp
random-nick has joined #commonlisp
euandreh has joined #commonlisp
lottaquestions_ has joined #commonlisp
lottaquestions_ has quit [Client Quit]
lottaquestions_ has joined #commonlisp
lottaquestions has quit [Ping timeout: 256 seconds]
pdietz has joined #commonlisp
akoana has joined #commonlisp
antoszka has quit [Ping timeout: 252 seconds]
igemnace has quit [Remote host closed the connection]
alanz has quit [Ping timeout: 268 seconds]
antoszka has joined #commonlisp
Bung has quit [Remote host closed the connection]
Bung has joined #commonlisp
alanz has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
pranavats has left #commonlisp [Error from remote client]
azimut has quit [Ping timeout: 255 seconds]
Bung has quit [Quit: Leaving]
azimut has joined #commonlisp
sedzcat has quit [Quit: sedzcat]
rogersm has joined #commonlisp
rogersm has quit [Quit: Leaving...]
tyson2 has joined #commonlisp
rainthree has quit [Ping timeout: 260 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
lisp1234 has joined #commonlisp
<Josh_2>
Has anyone performed remote lisp editing on 2.2.9?
pdietz has quit [Ping timeout: 260 seconds]
<Josh_2>
I will quickly try latest sly from github, see if that fixes
<Bike>
2.2.9 of what?
<Josh_2>
sbcl sorry
<Bike>
Ah
<euouae>
note 2.2.10 is lataest now
<Josh_2>
My package manager just installed 2.2.9 which is good enough for me
<Josh_2>
But when I get an sbcl version update I have to update my VPS binaries as well, but seems that I'm having a problem with 2.2.9 compiling the quicklisp version of Slynk (when I connect with sly-connect)
<Josh_2>
It is a problem I've never had before
nij- has joined #commonlisp
pranavats has joined #commonlisp
jeosol has joined #commonlisp
<Josh_2>
Okay :)
<Josh_2>
Version from github sorted it out
Madsy has joined #commonlisp
nij- has left #commonlisp [#commonlisp]
azimut has quit [Remote host closed the connection]
notzmv has joined #commonlisp
<euouae>
nice
markb1 has joined #commonlisp
Catie has quit [Ping timeout: 255 seconds]
markb1 has left #commonlisp [#commonlisp]
tyson2 has quit [Remote host closed the connection]
azimut has joined #commonlisp
lisp1234 has quit [Remote host closed the connection]
lisp1234 has joined #commonlisp
ecraven has joined #commonlisp
lisp1234 has quit [Read error: Connection reset by peer]
<Josh_2>
Lucky me that I documented how to solve this issue last time I had it :sunglasses:
glaucon has quit [Read error: Connection reset by peer]
epony has quit [K-Lined]
<phoe>
euouae: the macros in question are have a FOOF naming convention
<phoe>
standard CL has INCF, DECF; alexandria has things like APPENDF, NCONCF
tyson2 has joined #commonlisp
<euouae>
ah
<euouae>
foof or barf
<phoe>
something like that, yes
<euouae>
I will use it
Guest1376 has quit [Quit: WeeChat 3.7.1]
chipxxx has quit [Ping timeout: 256 seconds]
pve has quit [Quit: leaving]
euouae has quit []
shka has quit [Ping timeout: 260 seconds]
<Josh_2>
Okay take 2 of telling myself how to fix it.
<Josh_2>
When I have a slynk connection problem (failing to find files etc .fasls, perms denied etc) then I have to copy the .cache/common-lisp/..../sly/* to my remote servers .cache/common-lisp/.../sly/* that will let me connect to images built on my local machine and uploaded to my VPS :P
<Josh_2>
Now when I update SBCL in 6 months I wont be 100% lost :joy:
Oladon has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
jolby has quit [Quit: Client closed]
morganw has quit [Remote host closed the connection]
<NotThatRPG>
On my M1 Mac I get an error building static-vectors: Unknown CFFI type :SIZE -- anyone have any idea what might cause this?
<Shinmera>
why does that do it like that instead of checking constantp and emitting a load-time-value
<NotThatRPG>
phoe: That's right. Unless Xach's labeling is wrong, #343 wouldn't have broken this
<phoe>
NotThatRPG: can you check if your quicklisp dist's CFFI contains this change?
<NotThatRPG>
phoe: It does not
<phoe>
huh
<phoe>
what else has changed then?...
<phoe>
I can't see any cffi commits that might have caused this
<NotThatRPG>
I looked for `define-compiler-macro` and did not find anything for `foreign-type-size`
<phoe>
I can't say CFFI is to blame then
<NotThatRPG>
Well, note that this is the first time I have tried to compile static-vectors on the M1 chip so maybe this isn't a new CFFI bug, but instead a problem with ARM64?
<phoe>
unlikely, it would have been caught by now I think
<phoe>
and also the ctype :SIZE is likely to be defined on all architectures
<NotThatRPG>
Honestly, even as ASDF maintainer I have trouble understanding how ASDF and QL are going to interact. I have simply no idea why it is loading this.
<Shinmera>
phew.
<phoe>
yes, I got double stressed over here
<Shinmera>
the ASDF registry remains a spooky beast to me and I just rely on ql's projects system instead.
<NotThatRPG>
Yes, I stopped understanding it once ASDF:*central-registry* was deprecated. The new multi-scheme is quite confusing.
akoana has quit [Quit: leaving]
jolby has joined #commonlisp
random-nick has quit [Ping timeout: 256 seconds]
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dipper has joined #commonlisp
sbenitezb has joined #commonlisp
<pjb>
You still can use asdf:*central-registry*, or quicklisp-client:*local-project-directories*