<nytpu>
i've gotten very confused about the clhs entry for ARRAY-DISPLACEMENT, can anyone clarify?
<nytpu>
in the description's first paragraph, it says "If the array is not a displaced array, nil and 0 are returned." but then in the second paragraph it directly contradicts that by saying "It is implementation-dependent whether array-displacement returns a non-nil primary value for [an array that is not displaced]."
<White_Flame>
the implementation-dependent return includes for displaced arrays with a NIL :displaced-to value
<mfiano>
Hmm?
<White_Flame>
at least, literally
<mfiano>
"If displaced-to is nil, the array is not a displaced array."
<mfiano>
As per MAKE-ARRAY
<White_Flame>
but yeah, needs a venn diagram ;)
<mfiano>
It's odd that they chose that wording for the second paragraph
<mfiano>
A verbose way to reinstate the previous paragraph, but with a conflicting constraint
<mfiano>
I'll leave a language lawyer to it
<nytpu>
yeah, that part of of MAKE-ARRAY (and ADJUST-ARRAY) is why i clarified the quote as "an array that is not displaced" rather than "an array with a NIL value given to :DISPLACED-TO", since the latter by definition means the former
<White_Flame>
"if not A, then return nil and 0". "if A, return X, undefined for anything else", basically?
<nytpu>
it almost reads like they had two different versions of the description and accidentally included both in the spec
<nytpu>
"Some implementations implicitly displace some arrays. (For example, adjustable arrays might be represented as displaced arrays.) Permitting ARRAY-DISPLACEMENT to return non-NIL for those arrays allows those implementations not to have to record some additional information in the array about whether an explicit :DISPLACED-TO was provided."
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nytpu>
the wording in the spec could still be a bit more clear though
notzmv has joined #commonlisp
yisef has quit [Ping timeout: 246 seconds]
habamax has quit [Remote host closed the connection]
habamax has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
Spawns_Carpeting has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
habamax has joined #commonlisp
Spawns_Carpeting has joined #commonlisp
xmachina has joined #commonlisp
fosskers has joined #commonlisp
<fengshaun>
how does one start dealing with binary data and endianness in cl?
<aeth>
this just helps you see what's going on with the bits
<aeth>
So you can write a function to convert endianness this way, by first using LDB to get the individual bytes and then by swapping the order in the function that puts them together with something like ASH and LOGAND
fosskers has quit [Ping timeout: 246 seconds]
<fengshaun>
it's easier than I thought!
<fengshaun>
thanks a ton!
<aeth>
you're welcome
eddof13 has joined #commonlisp
Lycurgus has quit [Quit: Tschüss]
jobhdez has joined #commonlisp
<jobhdez>
hello beach - hope all is well. not sure if this is good question to ask but im curious as to how you design compilers? whats your take on this? thanks
yisef has quit [Remote host closed the connection]
<beach>
jobhdez: There is a lot of literature available, and it is hard to summarize all that material here. The main work of a compiler nowadays is to apply a bunch of optimizations. For that, I use the book by Muchnick.
<beach>
"Advanced Compiler Design and Implementation"
<jobhdez>
thanks! some say that we have come to the end of moores law. you think compilers will increase in importance?
<beach>
Compiler technology (especially optimization) has been very important for quite some time. What is interesting to me is that most research has been done for C-like languages. And I guess LLVM is the current manifestation of that. But for dynamic languages like Common Lisp, there seems to be a lot to do still. We have done some, but I am sure there is more.
<hayley>
Moore's law isn't dead, it just smells funny. The relevant law for compiler optimisations is more pessimistic though.
<beach>
And, yes, Moore's law is not about speed, but about the number of transistors on a chip.
<hayley>
"Proebsting's law" states the performance of generated code doubles every 18 years; https://zeux.io/2022/01/08/on-proebstings-law/ does a little test with different versions of LLVM and finds the law to be too optimistic.
<ixelp>
zeux.io - On Proebsting's Law
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<beach>
Heh!
<jobhdez>
thats interesting that it would take that long. based on my linear algebra compiler papers i have read i get the impression that its really hard to generate efficient code thats as good as hand written kernels. also from ACM CC it seems like deep learning will improve optimization but im no expert so im not sure if this is true. so is building an
<jobhdez>
optimizer for a compiler really hard?
<jobhdez>
based n my reading of linear algebra papers***
<jobhdez>
on*
<beach>
jobhdez: It is not "hard" if you read the literature. You "just" have to implement the techniques that are documented. But, like I said, this is mainly true for static languages like C.
<jobhdez>
what are the open problems for compilers for dynamic languages eg common lisp?
<beach>
For some reason, relatively little research has been conducted to take advantage of the fact that, at any point in time, the Common Lisp image has access to the full code that is being used.
<beach>
jobhdez: I don't know. If I did, I would work on some of them. But you can study the SICL-related papers to see what things we invented for the past 10 or so years: http://metamodular.com/SICL/
<ixelp>
SICL documents
<jobhdez>
oh interesting. thanks a lot
<beach>
jobhdez: Also, it is not just about the compiler. It is about the full system, like generic dispatch, call-site optimization, etc. Those are not directly part of the compiler.
<hayley>
Dealing with dynamic dispatch, divining types and overcoming the darn Von Neumann bottleneck strike me as important.
<jobhdez>
beach: This is why you are separating these into their own repos right? I remember you saying something like this a while back. You were working on that I think.
<beach>
I don't remember exactly what I said. We extract code to separate repositories when we estimate that the code can be written in an implementation-independent way without sacrificing performance.
<beach>
Some parts of the compiler must collaborate with some parts of the garbage collector and the way the system represents objects.
<jobhdez>
thanks hayley - any other good compiler papers you recommend?
<hayley>
What I've read by Stefan Marr and Chris Seaton (RIP) on implementing Ruby tends to be really good.
<jobhdez>
thanks
drewjose8 has joined #commonlisp
<hayley>
With regards to "divining types" - this is all about concrete types, not so much types at the language level. Java and C++ might do similar with dynamic dispatch, the ML family might specialise higher-order functions. Okay, Craig Chambers's thesis (also on Self) is also excellent <http://www.wolczko.com/tmp/ChambersThesis.pdf>
<jobhdez>
hayley: thanks. hey, im curious. how did you go about building the garbage collector for sbcl? is such an enormous task. you did great work there
easye has quit [Ping timeout: 255 seconds]
easye has joined #commonlisp
dcb has quit [Quit: MSN Messenger 4.0.4]
<hayley>
I did it roughly in this order: 1. fail to reimplement luis's parallel copying collector patch 2. write the allocator 3. write a non-generational mark-region collector 4. add generations 5. add parallelism (which was pretty easy; I designed with it in mind) 6. procrastinate on implementing compaction 7. procrastinate on it some more 8. implement compaction
<beach>
jobhdez: Again, there is a vast amount of literature on garbage collection, for instance "The Garbage Collection Handbook" by Jones.
<beach>
jobhdez: The main difficulty is the very interaction I mentioned between the compiler and how objects are represented. And different techniques optimize different aspects, so there are tons of trade-offs.
<hayley>
Much of what I borrowed was not in the Garbage Collection Handbook at the time. I have the new edition, which covers the last decade of garbage collector design.
<hayley>
The parallel tracing algorithm by Ossia et al, Immix and the non-moving generational collector design by Boehm are in the first edition of the Handbook, but "Fast conservative garbage collection" and "Taking Off the Gloves with Reference Counting Immix" are not (as the Handbook predates those papers).
<beach>
Right, books are good starting points, but to do real work, one often has to consult research papers that are more recent.
<hayley>
beach: The difficulty mostly came from retrofitting a mostly non-moving collector onto SBCL, which is rather tightly coupled to a moving design.
<beach>
Yes, having to deal with existing design decisions complicates things.
<jobhdez>
good to know you all!
<hayley>
Were that not the case, I might have used MMTk and called it a day. Instead the developers "just" gave me some good ideas for my own collector.
<beach>
That's a big reason why I decided to create SICL rather than attempting to improve an existing implementation.
<hayley>
beach: I should mention, your sliding GC is cited in the Handbook now.
<ixelp>
The Garbage Collection Handbook: The Art of Automatic Memory Managemen
<aeth>
You could probably double the performance of programs compiled by SBCL twice, in less than 18 years. It would be much harder to double the performance of LLVM because that's closer to the cutting edge.
<beach>
aeth: In my opinion, that's not the main reason. Like I said, most research has been done for C-like languages.
<hayley>
aeth: I got a 70% speedup for one-more-re-nightmare in a few days. Extrapolate from that.
tibfulv has quit [Remote host closed the connection]
<aeth>
The first +100% (doubling) should be relatively easy if there was a large enough effort applied. The next +100% would be much harder.
<aeth>
Or I guess it would be +200% to double again... bah.
tibfulv has joined #commonlisp
<jobhdez>
hayley how did you get a 70% speedup?
<hayley>
The compiler would put code which exits a loop "fall through" a conditional jump, when the code in the loop should fall through. I'm still not exactly sure why it mattered so much, honestly.
<hayley>
Note that it was 70% for a very specific workload, though I heard of some 20% speedup in clintm's parsing code. Otherwise everything else was roughly unaffected.
triffid has joined #commonlisp
azimut has joined #commonlisp
mingus has joined #commonlisp
<jobhdez>
interesting. so did you read the whole garbage collector handbook or just the parts that you needed?
<jobhdez>
just curious
<hayley>
Mostly just the parts I needed. Sometimes I'd idly read a random part, but it's a very broad book.
<jobhdez>
im reading the intro right now and im thinking: why the hell do people program in C or C++, garbage collection is better
<jobhdez>
its pretty impressive that llvm work as it does considering it was built with c++
<jobhdez>
things like dangling pointers
pve has joined #commonlisp
<hayley>
One amusing reason, which doesn't cover all the cases, but covers an interesting amount is as follows:
<hayley>
"A lot of developers, particularly young developers, imagine that languages like C++ represent "leveling up" in the game of development. These developers spend their days toiling in cesspools of Python and Javascript, converting XML to JSON to SQL to TOML to XML to SQL to protobuf to JSON, while simultaneously wrestling with Kubernetes Amazon Docker React Chef, and imagine that "real programmers" are
<hayley>
having non-stop sex parties while slinging around manual memory management code and probably some cool inline assembly that's so fast that the CPU clocks actually run backwards."
<hayley>
There are legit reasons, but a fair amount seems to be not very legit.
<beach>
Nice quote! Where is it from?
<beach>
For LLVM, I suspect they wanted to interface to be C++ so that more clients could be considered. Otherwise, if it were just a compiler, C++ would be a bad choice indeed.
<jobhdez>
If youre writing a kernel then c/c++ is probably fine but as beach says, it seems a bad choice for a compiler. For me the best languages are probably common lisp, standard ml/ocaml, and haskell. but im not familiar with how lazyness affects compiler development but based on conversations with robert smith you kind of do need static guarantees when
<jobhdez>
building a compiler but the interactivity of common lisp makes it a good candidate as well. so i think coalton is a good thing
<jobhdez>
that was a good quote
<hayley>
Another issue is that tracing garbage collection tends to be poor at reusing a small address space quickly, which does not work well with cache.
<jobhdez>
ah ok. so that the more legit reason for choosing c++
<hayley>
I'd prefer not to write a kernel in C - empirically I can't not say that it's possible, but it's quite easy to make errors, and the cost of an error could be quite high.
<hayley>
(I turned down a job working on web browsers in C++ for that reason.)
NicknameJohn has joined #commonlisp
<jobhdez>
yeah writing in c++ just seems painful. dangling pointers and memory leaks just sounds awful. instead of thinking about the problem itself youre debugging memory errors. as someone said in a blog- when you write in c++ youre the programmer and the janitor.
<aeth>
I think the thing about C++ is that there's a lot of libraries out there in C++
<aeth>
the ones in C can be used from almost any language, but not all of the ones in C++ can easily be used in other languages
jonatack2 has quit [Read error: Connection reset by peer]
jonatack3 has joined #commonlisp
<aeth>
this creates a network effect
mingus1 has joined #commonlisp
mingus has quit [Ping timeout: 245 seconds]
mingus1 is now known as mingus
yisef has joined #commonlisp
jobhdez has quit [Quit: Client closed]
kenran has joined #commonlisp
rgherdt has joined #commonlisp
Inline has joined #commonlisp
LW has joined #commonlisp
LW has quit [Client Quit]
bendersteed has joined #commonlisp
igemnace has joined #commonlisp
shka has joined #commonlisp
<jcowan>
hayley: in addition to the langs you mention, Scheme and Smalltalk have been the subjects of a good deal of compiler research over time
msavoritias has joined #commonlisp
<jcowan>
I think another reason for favoring C/C++ is that if you want a job at FAANG you need the extra 1% or 0.1% performance gain. When I was working at GOogle it was said that a job running on a thousand servers was a small job
drewjose8 is now known as drewjose
Cymew has joined #commonlisp
rgherdt_ has joined #commonlisp
dnhester26 has joined #commonlisp
rgherdt has quit [Ping timeout: 255 seconds]
dino_tutter has joined #commonlisp
varjag has joined #commonlisp
mgl has joined #commonlisp
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
Inline has quit [Ping timeout: 240 seconds]
ecraven has quit [Quit: quit]
herjazz has joined #commonlisp
<beach>
I can't figure out from the documentation of Parachute how to compare the result of evaluating two forms so that the number of values and each of the values are equal.
attila_lendvai_ has joined #commonlisp
<beach>
I mean, I can always call multiple-value-list on both forms, but I would think this kind of comparison is common.
<beach>
I see that there are classes MULTIPLE-VALUE-RESULT and MULTIPLE-VALUE-COMPARISON-RESULT, but I don't see how these classes can be put to work.
ecraven has joined #commonlisp
habamax has joined #commonlisp
Inline has joined #commonlisp
random-nick has joined #commonlisp
yisef has quit [Quit: Client closed]
dimlibera is now known as dim
igemnace has quit [Read error: Connection reset by peer]
kenran has quit [Remote host closed the connection]
<fitzsim>
borodust: thanks for taking a look; yeah, I had org.borodust.org installed; replied in detail on the github issue; feel free to close "wontfix" if you're not interested in ppc64 support ever (or see alternative suggestion in the issue)
Josh_2 has quit [Quit: Gotta go fast!]
xmachina has quit [Quit: WeeChat 4.0.4]
thuna` has joined #commonlisp
prxq has joined #commonlisp
xmachina has joined #commonlisp
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.50)]
herjazz has quit [Quit: leaving]
zxcvz has joined #commonlisp
xmachina has quit [Quit: WeeChat 4.0.4]
mgl has joined #commonlisp
dnhester26 has joined #commonlisp
zxcvz has quit [Quit: zxcvz]
bendersteed has quit [Quit: bye]
tyson2 has quit [Remote host closed the connection]
Cymew has quit [Ping timeout: 245 seconds]
luna-is-here has quit [Ping timeout: 244 seconds]
luna-is-here has joined #commonlisp
overclucker has quit [Ping timeout: 246 seconds]
dnhester26 has quit [Remote host closed the connection]
overclucker has joined #commonlisp
<mfiano>
Is it portable and conforming to #'compile a new function object, in the environment of the same-named function of the global environment (as a memoization technique)?
<bike>
compile doesn't accept an environment anyway, so i'm not sure what you mean
<beach>
I don't understand what "in the environment of the same-named function of the global environment" means.
<mfiano>
I just mean to compile a new function into the toplevel environment (so no environment is fine), inside a function of the same name that also exists in the toplevel environment
<Inline>
for making an image ?
<mfiano>
So that the next time it is called, it is 'optimized' in some regard
<beach>
mfiano: You don't compile into an environment. The name is associated with the function as a result of (SETF FDEFINITION), not COMPILE.
<bike>
compile does essentially do setf fdefinition, but as an afterthought
<mfiano>
Right, I just mean (defun foo (..) ... (compile 'foo `(lambda (...) ...)) ...)
<bike>
that's sort of okay, but keep in mind that the semantic restrictions in compile-file mean you can't technically redefine individual functions
<mfiano>
Hmm
<beach>
Of course, we do that all the time in SLIME.
<mfiano>
Ok, thanks!
AetherWind has joined #commonlisp
notzmv has quit [Ping timeout: 255 seconds]
tyson2 has joined #commonlisp
xmachina has joined #commonlisp
jmdaemon has quit [Ping timeout: 246 seconds]
ronald has quit [Read error: Connection reset by peer]
kenran has joined #commonlisp
dino_tutter has quit [Ping timeout: 240 seconds]
ronald has joined #commonlisp
mgl has quit [Quit: Client closed]
Lycurgus has joined #commonlisp
rtypo has quit [Ping timeout: 255 seconds]
dinomug has joined #commonlisp
waleee has joined #commonlisp
ronald has quit [Read error: Connection reset by peer]
ronald has joined #commonlisp
igemnace has quit [Remote host closed the connection]
cage has joined #commonlisp
Oladon has joined #commonlisp
ronald has quit [Read error: Connection reset by peer]
dinomug has quit [Remote host closed the connection]
ronald has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
kenran has quit [Ping timeout: 246 seconds]
ronald has quit [Read error: Connection reset by peer]
attila_lendvai_ has quit [Ping timeout: 255 seconds]
ronald has joined #commonlisp
Lycurgus has quit [Quit: Tschüss]
waleee has quit [Ping timeout: 246 seconds]
dino_tutter has joined #commonlisp
dcb has joined #commonlisp
dinomug has joined #commonlisp
yottabyte has quit [Quit: Connection closed for inactivity]
dnhester26 has joined #commonlisp
Pixel_Outlaw has joined #commonlisp
dnhester26 has quit [Ping timeout: 240 seconds]
tyson2 has joined #commonlisp
Oladon has quit [Quit: Leaving.]
iska` has quit [Remote host closed the connection]
waleee has joined #commonlisp
notzmv has joined #commonlisp
overclucker has quit [Ping timeout: 240 seconds]
kurfen has quit [Ping timeout: 250 seconds]
kurfen has joined #commonlisp
overclucker has joined #commonlisp
attila_lendvai_ has joined #commonlisp
ronald_ has joined #commonlisp
NicknameJohn has quit [Ping timeout: 250 seconds]
dinomug has quit [Remote host closed the connection]
eddof13 has joined #commonlisp
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
anticomputer has quit [Quit: quit]
anticomputer has joined #commonlisp
NicknameJohn has joined #commonlisp
nij- has joined #commonlisp
msavoritias has quit [Remote host closed the connection]
Oddity has joined #commonlisp
dcb has quit [Quit: MSN Messenger 4.0.4]
azimut has quit [Ping timeout: 246 seconds]
azimut has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 28.2]
kurfen has quit [Ping timeout: 246 seconds]
tyson2 has quit [Remote host closed the connection]
pve has quit [Quit: leaving]
nij- has quit [Ping timeout: 240 seconds]
bollu7 has joined #commonlisp
shunter_ has joined #commonlisp
artyn_ has joined #commonlisp
nytpu_ has joined #commonlisp
pkal_ has joined #commonlisp
jonlevin_ has joined #commonlisp
mcoll_ has joined #commonlisp
skin_ has joined #commonlisp
ggb_ has joined #commonlisp
whereiseveryone_ has joined #commonlisp
sherbert_ has joined #commonlisp
srhm_ has joined #commonlisp
randm_ has joined #commonlisp
tertek_ has joined #commonlisp
equwal has quit [Ping timeout: 246 seconds]
tertek has quit [Ping timeout: 246 seconds]
artyn has quit [Ping timeout: 246 seconds]
whereiseveryone has quit [Ping timeout: 246 seconds]
mcoll has quit [Ping timeout: 246 seconds]
deadmarshal_ has quit [Ping timeout: 246 seconds]
xaltsc_ has quit [Ping timeout: 246 seconds]
rdrg109 has quit [Ping timeout: 246 seconds]
nytpu has quit [Ping timeout: 246 seconds]
jonlevin has quit [Ping timeout: 246 seconds]
ggb has quit [Ping timeout: 246 seconds]
sherbert has quit [Write error: Connection reset by peer]
pkal has quit [Ping timeout: 246 seconds]
bollu has quit [Ping timeout: 246 seconds]
xantoz has quit [Ping timeout: 246 seconds]
randm has quit [Ping timeout: 246 seconds]
Fade has quit [Ping timeout: 246 seconds]
shunter has quit [Ping timeout: 246 seconds]
pkal_ is now known as pkal
randm_ is now known as randm
bollu7 is now known as bollu
shunter_ is now known as shunter
mcoll_ is now known as mcoll
jonlevin_ is now known as jonlevin
ggb_ is now known as ggb
artyn_ is now known as artyn
nytpu_ is now known as nytpu
sherbert_ is now known as sherbert
Oddity has quit [Ping timeout: 246 seconds]
dustinm` has quit [Ping timeout: 246 seconds]
dirtcastle has quit [Ping timeout: 246 seconds]
buffet has quit [Ping timeout: 246 seconds]
mht-wtf has quit [Ping timeout: 246 seconds]
skin has quit [Ping timeout: 246 seconds]
srhm has quit [Ping timeout: 246 seconds]
xantoz has joined #commonlisp
sherbert has quit [Read error: Connection reset by peer]
paulapatience has quit [Read error: Connection reset by peer]
mhcat has quit [Write error: Connection reset by peer]
srhm_ has quit [Read error: Connection reset by peer]
theothornhill has quit [Read error: Connection reset by peer]
mcoll has quit [Read error: Connection reset by peer]
ggb has quit [Read error: Connection reset by peer]
rselim has quit [Write error: Connection reset by peer]
nytpu has quit [Read error: Connection reset by peer]
pvac has quit [Write error: Connection reset by peer]
jmbr has quit [Write error: Connection reset by peer]
sirufer has quit [Write error: Connection reset by peer]
jonlevin has quit [Read error: Connection reset by peer]
whereiseveryone_ has quit [Read error: Connection reset by peer]
artyn has quit [Read error: Connection reset by peer]
skin_ has quit [Read error: Connection reset by peer]
shunter has quit [Read error: Connection reset by peer]
sm2n has quit [Write error: Connection reset by peer]
Schnouki has quit [Write error: Connection reset by peer]
cpli has quit [Write error: Connection reset by peer]
\f has quit [Write error: Connection reset by peer]
zyd has quit [Write error: Connection reset by peer]
theesm has quit [Write error: Connection reset by peer]
jasom has quit [Write error: Connection reset by peer]
alethkit has quit [Write error: Connection reset by peer]
zoglesby has quit [Write error: Connection reset by peer]
chiheisen has quit [Read error: Connection reset by peer]
payphone has quit [Read error: Connection reset by peer]
sirufer has joined #commonlisp
zoglesby has joined #commonlisp
mhcat has joined #commonlisp
ggb has joined #commonlisp
shunter has joined #commonlisp
pvac has joined #commonlisp
paulapatience has joined #commonlisp
Schnouki has joined #commonlisp
equwal has joined #commonlisp
jonlevin has joined #commonlisp
srhm has joined #commonlisp
theesm has joined #commonlisp
sherbert has joined #commonlisp
sm2n has joined #commonlisp
whereiseveryone has joined #commonlisp
artyn has joined #commonlisp
nytpu has joined #commonlisp
zyd has joined #commonlisp
payphone has joined #commonlisp
mcoll has joined #commonlisp
dustinm` has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Fade has joined #commonlisp
cpli has joined #commonlisp
rdrg109 has joined #commonlisp
\f has joined #commonlisp
xaltsc has joined #commonlisp
skin has joined #commonlisp
rselim has joined #commonlisp
jasom has joined #commonlisp
theothornhill has joined #commonlisp
alethkit has joined #commonlisp
jmbr has joined #commonlisp
chiheisen has joined #commonlisp
tyson2 has joined #commonlisp
buffet has joined #commonlisp
mht-wtf has joined #commonlisp
Oddity has joined #commonlisp
dirtcastle has joined #commonlisp
<Shinmera>
aeth: wrong, on clisp array-total-size-limit is > most-positive-fixnum
deadmarshal_ has joined #commonlisp
<Shinmera>
it's weird that that's the case, but c'mon man, don't just post a straight falsehood after I post proof of that being a falsehood.
<jcowan>
Shinmera: a-t,-s-l is said to be a fixnum
<jcowan>
Ergo<
<jcowan>
< max pod
<jcowan>
Pod fixnum
<Shinmera>
oh wait, did I misread my own output
<Shinmera>
I did indeed
<Shinmera>
many apologies, I am indeed very stupid
<jcowan>
Nash
<jcowan>
Moral:format with commas
<Shinmera>
Anyway, I often do something like (deftype array-index () `(integer 0 ,(1- ARRAY-TOTAL-SIZE-LIMIT))) so I can easily bound values
<Shinmera>
without having to rely on FIXNUM as a kludge
<aeth>
> A positive fixnum, the exact magnitude of which is implementation-dependent, but which is not less than 1024.
<aeth>
If an implementation did violate it, it would be violating it, for whatever that's worth.
<Shinmera>
yea see I did know that, but thought "well, that's another weird clisp-ism to add to the list"
<aeth>
Alexandria has an array-index type
<aeth>
it uses (1- array-dimension-limit) as the default value
<aeth>
i.e. the max size each dimension can go, which may or may not be the same as array-total-size-limit.
attila_lendvai_ has quit [Ping timeout: 260 seconds]
<aeth>
should in theory be (<= array-dimension-limit array-total-size-limit most-positive-fixnum) but there is no restriction there.
amb007 has joined #commonlisp
<aeth>
something which holds in SBCL, ECL, and CLISP, which are the only three I have installed (I'm pretty sure I tested my earlier line in CLISP, too, but I can't guarantee that I did)
<aeth>
For completeness, what's really all over the place is array-rank-limit. Way too low standard minimum of 8. And implementations are much lower than you think (64 ECL, 4096 CLISP, 129 recent SBCLs) because you quickly run out of memory.
<Shinmera>
I don't remember when I last used even a 2D array, so I'm not particularly bothered by that :v
eddof13 has joined #commonlisp
<aeth>
2D seem to be very useful as matrices (at least ones that aren't sparse), except that most people who use matrices are doing graphics and so probably use 1D arrays and might use something like the static-vectors library for OpenGL.
<aeth>
3D might have uses, too. I think an image library uses it for x position, y position, and (r,g,b,a) iirc. Beyond that, it quickly loses practicality. 0D can be used as a "box", but that's rare.
<aeth>
I think I use 2D to make an "array" of (x, y, z) vecs, not too unlike what the image library does with (r,g,b,a) in 3 dimensions. You do sacrifice the ability to use the sequence functions when you do this, though.
<aeth>
(You probably don't care and this might all be old information to you, but someone reading the logs might want to know where 2D/3D arrays are used.)
<Pixel_Outlaw>
aeth, are you cataloging your findings between dialects? This'd be handy for somebody wanting to write portable code.
<Pixel_Outlaw>
Sorry between implementations.
thuna` has quit [Remote host closed the connection]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aeth>
It would have to be more systematic because versions differ and architectures differ (especially when the architectures are 32-bit vs 64-bit). (I assume that) the whole reason the standard minimums are too low in the first place is because they allow for 16-bit CL implementations.
<Pixel_Outlaw>
Probably "big enough" for 1993 :P
<aeth>
if you wanted 16-bit support, yes
<Pixel_Outlaw>
Or whenever the second standard was released.
rtypo has joined #commonlisp
dcb has quit [Quit: MSN Messenger 4.0.4]
<aeth>
The only thing that would be very hard and very useful in this project would be finding out all of the upgraded-array-element-type types.
<aeth>
It's easy to go through the types you think of and see if they're T or the type.
<aeth>
But you probably wouldn't think of (upgraded-array-element-type '(complex double-float))
dcb has joined #commonlisp
<aeth>
Also, [un]signed-byte is a bit more complicated because they're not just T or the type and they could round to an unusual size, such as a fixnum (or positive fixnum!) size. e.g. (upgraded-array-element-type '(unsigned-byte 48)) => (UNSIGNED-BYTE 62) ; but probably only on my current 64-bit SBCL install and not outside of SBCL
<aeth>
To further complicate things, there's a chance that such things might round to the size that the implementation uses for their 32-bit fixnum (or positive fixnum), despite that not existing inside of the 64-bit implementation in any other detectable sense.
tyson2 has quit [Remote host closed the connection]
cmack` has joined #commonlisp
rgherdt_ has quit [Quit: Leaving]
ElKowar3 has joined #commonlisp
macdavid313 has joined #commonlisp
dustinm` has quit [Ping timeout: 246 seconds]
gty has quit [Ping timeout: 246 seconds]
cmack has quit [Ping timeout: 246 seconds]
Brucio-61 has quit [Ping timeout: 246 seconds]
ixelp has quit [Ping timeout: 246 seconds]
macdavid313 is now known as gty
Brucio-61 has joined #commonlisp
light has quit [Ping timeout: 246 seconds]
borodust has quit [Ping timeout: 246 seconds]
ElKowar has quit [Ping timeout: 246 seconds]
ElKowar3 is now known as ElKowar
pok has quit [Ping timeout: 246 seconds]
overclucker has quit [Ping timeout: 240 seconds]
light has joined #commonlisp
borodust has joined #commonlisp
pok has joined #commonlisp
pok has joined #commonlisp
pok has quit [Changing host]
dustinm` has joined #commonlisp
ixelp has joined #commonlisp
overclucker has joined #commonlisp
shka has quit [Ping timeout: 255 seconds]
tyson2 has joined #commonlisp
chrcav has joined #commonlisp
<jcowan>
Higher-order tensors are the obvious application of n-dimensional arrays