dinomug has quit [Remote host closed the connection]
contrapunctus has left #commonlisp [#commonlisp]
X-Scale has quit [Quit: Client closed]
Oladon has quit [Quit: Leaving.]
random-jellyfish has joined #commonlisp
random-jellyfish has joined #commonlisp
contrapunctus has joined #commonlisp
zephyr has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
_whitelogger_ has joined #commonlisp
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 255 seconds]
zephyr has quit [Remote host closed the connection]
zephyr has joined #commonlisp
Lord_of_Life_ is now known as Lord_of_Life
zephyr has quit [Ping timeout: 255 seconds]
X-Scale has joined #commonlisp
igemnace has quit [Quit: WeeChat 4.1.0]
Lycurgus has joined #commonlisp
Lycurgus has quit [Client Quit]
Lycurgus has joined #commonlisp
<smlckz>
''Symbols that print the same _usually_ are eq to each other because of the use of the intern function.'' Can I safely use eq to check symbol equality?
alexsotodev has quit [Quit: Leaving.]
zephyr has joined #commonlisp
<bike>
yes, that's talking more about import than eq.
<moon-child>
or e.g. #:a and #:a will print the same but are not eq
<moon-child>
but eq is almost certainly what you want when comparing symbols
<aeth>
if EQ didn't always work for symbols, that'd be huge
<moon-child>
it 'works'; the question is whether it's what you want
<moon-child>
it might not be. Loop uses string=, for instance, very intentionally
<aeth>
yes, that is the main exception because it's rare that you don't want the package namespace
Lycurgus has quit [Quit: leaving]
<aeth>
usually if you don't want a package you'll use '#:foo or :foo with the latter technically being part of the KEYWORD package
Lycurgus has joined #commonlisp
<smlckz>
(string= 'abc :abc) => T hmm
<bike>
string= compares the symbol names but ignores their packages.
<ldb>
use eq won't make your lisp explode anyway
Lycurgus has quit [Client Quit]
<ldb>
or cause segfaul
<ldb>
t
<aeth>
well, some people just use EQL for everything instead of special casing EQ which is afaik really only special cased specifically on symbols and maybe one or two other things
<aeth>
as far as style goes
<aeth>
EQL being EQ that doesn't work unexpectedly on numbers/characters
<ldb>
if EQ cannot compare symbols what is the point of including it in the language lol
<aeth>
right
<moon-child>
originally, eq could _only_ compare symbols
<aeth>
ldb: but that doesn't mean that the answer to smlckz's question is "yes" because there are some pointless things in the language (though EQ is a fairly common thing, so it would be surprising and probably break some code assumptions)
<aeth>
e.g. RPLACA/RPLACD are basically pointless in the era of SETF (which is compile time, so there's no difference!) and have very ugly names, too. Of course, (setf car) and (setf cdr) are probably implemented in terms of those functions (but only because they exist) and there are some really, really niche cases of niche higher order functions where RPLACA/RPLACD being functions is a useful thing.
tyson2 has quit [Remote host closed the connection]
<jcowan>
My view is that EQL is Lisp's identity function and EQ is a speed hack.
<moon-child>
I understand why people feel so.
<moon-child>
But I usually use eq preferentially to eql
<jcowan>
If you are using it as SYMBOL= then it is understandable
<ldb>
EQ is the unique object check
<moon-child>
mutable data structures more generally. But rarely numbers or characters
<moon-child>
the main issue imo is that eql is half-baked and numbers and characters are special-cased. Compare with baker egal in a world where there were immutable data structures more generally
<aeth>
ldb: yes, but how often do you need to know if the bignum/rational or big character (is that even a thing anymore? unicode fits in 64 bits for now) is unique or not?
<ldb>
and for some reason, ACL2 says (thm (implies (eql a b) (eq a b))) is true
<moon-child>
huh
<moon-child>
i guess probably it treats eq and eql as the same
<moon-child>
instead of modeling the nondeterminism?
<ldb>
I think one reason is it does hashconsing, that is every objects are interned.
<jcowan>
DSSSL has only EQUAL, because it has no mutable data structures
<moon-child>
does it have more than one type of number?
<ldb>
of cause the standard version of ACL2 disables float but there is a compile flag that ebables float reasoning
dinomug has joined #commonlisp
<moon-child>
why does it do that?
<ldb>
because cannot assume float computation commute, lol
<jcowan>
Because of the bad behavior of inexact numbers: = is not transitive
<moon-child>
????
<ldb>
(a + b) + c != a + (b + c)
<jcowan>
sorry, yes, that's what I meant
<moon-child>
ldb: if we ignore the fact that standard + is nondeterministic (because nondeterminism is bad), floating-point addition is commutative; it is not associative, but so what?
<moon-child>
there are no inexact numbers; scheme terminology is bad
<jcowan>
It messes up proofs
<aeth>
ldb: you mean (/= (+ (+ a b) c) (+ a (+ b c))) right? :-p
<aeth>
although I think the former is the same as (+ a b c) because I think CL specifies an order, unlike Scheme?
<moon-child>
jcowan: however do you mean?
<moon-child>
if you want to prove something holds for rationals but not floats, that's perfectly fine
<moon-child>
aeth: no, it does not. That's the nondeterminism I alluded to
<jcowan>
It would be better to speak of exact and inexact operations
<moon-child>
yes
<Alfr>
aeth, of evaluation (of subforms) but not the order those will be added together.
<aeth>
uh oh :-p
<moon-child>
Alfr: oh, does scheme leave the former unspecified?
<moon-child>
for function arguments in general?
<moon-child>
that seems bad...
<Alfr>
aeth, 12.1.1.1.1
<Alfr>
moon-child, if you need an ordering in scheme, better use lets and friends.
<jcowan>
In general, function arguments are evaluated in arbitrary order, but that's not the same thing as lack of associativity. + applied to exact numbers is associative.
<ldb>
if a large float number is added to a small one, the small number would be rounded, and that's why precision float computation needs an accumulator for the rounding errors.
<Alfr>
moon-child, but this #cl. ;)
<moon-child>
booo spurious nondeterminism :(
davidt has joined #commonlisp
<ldb>
and I bet one cannot get very consistent float behavior across different common lisps
<Alfr>
moon-child, depends on what your source code is intended to convey; without this limitation a compiler might (for better or worse) reorder evaluation of subforms.
<moon-child>
if the compiler wants to reorder things than it had damn well better proven that it doesn't make a semantic difference
<ldb>
notably, Clozure CL has/had many float related issues and not consistent with SBCL
<smlckz>
so [for the peace of my mind] is using string= better than eq for symbol equality checking?
<moon-child>
ldb: 'sort of'--modulo clisp, they are mostly stupid and use the hardware ieee754
<Alfr>
moon-child, it doesn't as the language doesn't make the l-t-r guarantee.
<moon-child>
ldb: i've had more problems with sbcl...
<aeth>
smlckz: no, string= is an alternate, entirely different way to do things that is usually not what you want, and is almost exclusively restricted to LOOP
<jcowan>
moon-child: booo spurious determinism
<moon-child>
e.g. sbcl's scale-float is completely broken
<aeth>
smlckz: perhaps you could use it if you were using s-expressions as data to, for instance, configure and you don't care about namespaces... but might as well just use keywords like everyone else in that case
<moon-child>
and sb-c::float-accuracy is lol
<jcowan>
well, string= is suitable for comparing symbols without regard to packages, if that''s what you want.
<smlckz>
yes i'm dealing with s-exps
<ldb>
string= for compare symbols is a very niche use case anyway
<jcowan>
Yes
<jcowan>
I would never write code to depend on the evaluation order of arguments
<moon-child>
jcowan: gonna make a language that evaluates function arguments concurrently on different threads😎
<ldb>
In the Multics MacLisp they never had real strings data type so string is just symbol with special plist
<moon-child>
jcowan: maybe you wouldn't like to write such code, but surely if such code were written it were better that it had a single unambiguous interpretation under the language semantics, no?
<Pixel_Outlaw>
I have this dark thought to bring back symbol names with explode and implode if I make a Lisp.
<Pixel_Outlaw>
:>
<ldb>
but we do have string as array of characters now and memory isn't a much issue so if you want to using string= just don't use symbols
<ldb>
Pixel_Outlaw: I bet SML/OCaml is still doing that?
<Pixel_Outlaw>
Oh I don't know. I just saw it in MicroLisp for Commodore 64 and thought it was a fun novelty.
<ldb>
As a relic of ML compiler built on lisp
<aeth>
smlckz: basically, EQ matches on FOO:BAR while STRING= on a symbol matches on BAR in FOO:BAR (so BAR:BAR would also match, as would :BAR)
<Pixel_Outlaw>
OCaml has that static typing bondage stuff doesn't it? That kind of keeps me away.
<moon-child>
ldb: haskell uses linked lists of characters for strings
X-Scale has quit [Quit: Client closed]
<ldb>
Pixel_Outlaw: they have opened a hole called Magic that let you override the type stuff, lol
<ldb>
moon-child: yes a bad decision huh
<jcowan>
moon-child: Per contra, I would rather have a compiler free to reorder the evaluation order of arguments for efficiency
<ixelp>
funny prototype 48-bit umac with floating point I got bored with before finishing · GitHub
<moon-child>
only useful for one intel uarch before they added vpmadd52[lh]uq but still
<bjorkintosh>
moon-child, reason I asked is, cl seems absolutely great already! what would fp add that it lisp doesn't already do in a lispy way?
<aeth>
I'd have to say the most annoying thing about floats is their nondeterminism in various ways, whether inherent or just due to the mess of support
<aeth>
because everything is networked these days
<moon-child>
bjorkintosh: cl 'has' floating point numbers, but it specifies basically nothing about them (and implementation support is quite spotty); and it lacks a lot of useful operations (like fma, rounding control, exceptions access)
<ixelp>
C-XSC - A C++ Class Library for Extended Scientific Computing: Simple programming examples
<aeth>
bike: afaik most of the things that moon-child is complaining about could be added to float-features (or another library) if the implementations added/exposed support
<aeth>
maybe not all
<moon-child>
aeth: no, the most important thing is guarantees on behaviour
<ldb>
At least I hope libraries like XSC can be theoretically feasible in CL
<bike>
sure, but a language extension means a reasonably precise definition of what that support would be.
<moon-child>
functionality is secondary
<aeth>
moon-child: the most important guarantee on behavior that implementations should support isn't in floating point imo... it's a guarantee on tail call optimization. Otherwise, code can work perfectly fine except when (debug 3)
<moon-child>
I wouldn't compare the two
<bike>
i mean i've only tried writing an extension with the threads stuff, and that's not done and it's already a pain in the ass for reasons mostly unrelated to deciding what functions are defined
<moon-child>
certainly tco would be great
<ldb>
I think CL should forbid recursion, so novice programmer won't write 3 mutual recursive functions that would explode stack when the input is nil
<ldb>
which caused me brain pain to figure out that that s***t is doing
<moon-child>
well, _I_ think cl should prohibit consing, so novice programmers won't write a loop that exhausts the heap
<bike>
i'm failing to figure out what curse word this is.
<jcowan>
tail recursion + hash consing!
<aeth>
ldb: I think CL should forbid compilation so the novice programmer cannot make a faulty program. Instead, you can download precompiled libraries/programs from a package manager.
<ldb>
in the end I think we invented Rust
<moon-child>
jcowan: you want a single big hash cons for everything?
<jcowan>
Sure, why not.
<jcowan>
But really, total functional Lisp would be a Good Thing
<moon-child>
is it still lisp then?
<moon-child>
I think hayley talked about transparent hash consing for immutable objects
<jcowan>
I think so, yes
<moon-child>
but it seems to me kinda high overhead and difficult to know when worth it
<jcowan>
an uncommon lisp at any rate
<ldb>
remember hashconsing is a synonym to memory leak
* ldb
memory leak in a useful way
<moon-child>
not if done properly
<bike>
weak pointers would be another good language extension, come think.
<jcowan>
Yes
<jcowan>
And ephemerons
<moon-child>
weak pointers idk
<jcowan>
there is no need for weak pointres if you have ephemerons
<moon-child>
I just want the gc to tell me when it's about to trace me
<moon-child>
and maybe also let me move myself
<bike>
srfi 124 will probably seem fine once i understand what reference-barrier does.
<jcowan>
ask mnieper
<moon-child>
oh I also wanna data dependencies
<jcowan>
FWIU there is no actual need for it
<moon-child>
and I figured out how to implement them which c++ totally flubbed
<aeth>
What I'd want as a language extension is a way to have "arrays-of-structs" like a lot of low-level C/C++ does (the other being structs-of-arrays, which is trivial in CL, as long as the array element-types work)
<bike>
moon-child: you sure? consume is scary.
<aeth>
You can't just make an AREFable array :element-type for something that's not immutable like some numeric type, so you'd need a data structure that's array-like but distinct
<aeth>
(or characters, characters also being immutable)
<moon-child>
bike: yeah that's why my thing is better
<bike>
i mean, sure that you got it right
<moon-child>
pretty sure
<bike>
i've read a few of the papers on C++ atomics semantics being broken and i'm still at "scary"
<moon-child>
load (or any loading operation--cas xchg whatever) also returns a token, which has its own type and is completely opaque
<moon-child>
and you can supply a set of tokens to any subsequent memory operation to order it after all the loads associated with the tokens
<jcowan>
hmm, are literals allowed to be immutable?
<bike>
in CL, mutating a literal is UB. so they're immutable in an unenforced sense.
<moon-child>
I think this might even be easier to reason about in some respects than acquire, because it makes the ordering explicit in the dataflow, rather than implicit (logically a state transition from 'haven't acquired' to 'acquired')
<aeth>
another thing that would be nice is element-type for hash-tables; another thing that would be nice is a list/cons of single element-type, too, but that is a bit more complicated because that would only refer the CAR, so it wouldn't apply to trees, so you'd really need two possibilities (CAR-of-elt-type and CDR-of-cons-type; vs CAR-and-CDR-of-elt-type-or-cons-type)
<bike>
moon-child: definitely seems like an interesting idea.
<moon-child>
the problem with dependency ordering wasn't defining it; it was implementing it and reasoning about it. I think my approach solves both of those
<aeth>
(oh sorry, I also left out NIL)
<ldb>
'(1 2 3) is a literal
<moon-child>
bike: one thing I'm not sure about is control dependencies. I wanted to leave them out entirely (and force the optimiser to take advantage of them if possible), but now I think maybe it makes more sense to say you can also provide tokens to a branch
<moon-child>
but maybe that's getting too far back towards hard-to-reason-about
<bike>
definitely getting... involved. maybe in practice you'd also have higher level operators whose underlying semantics use the tokens but don't otherwise expose them?
<jcowan>
I think the right way to type binary trees is that both the car and the cdr are either a T or a tree of type T.
<moon-child>
that's kinda what I was thinking is that you'd have a user function that doesn't know about tokens and then a higher level thing that expresses the control dependency and then calls the user function
<moon-child>
vs the alternative of making it pass the token into the user function and now you have to thread it through all your accesses
<aeth>
jcowan: or NIL. And this is distinct from linked lists despite being CONS-like, because a typed linked list has typed-cons-or-nil for the CDR, and the type for the CAR
<moon-child>
but you still have potentially rather tenuous semantics in the user function so maybe it doesn't matter
<jcowan>
yes, or NIL
<jcowan>
now n-ary trees are yet another story
<aeth>
Both typed trees/lists can be implemented on top of defstruct, though, so it's less of a big deal (though it probably does have performance loss even using defstruct instead of defclass) than coming up with an array-of-struct implementation for CL to directly translate some C/C++/etc. idioms
<aeth>
though the most trivial thing would be adding array-style element-type to hash-tables
<aeth>
of the three things that need types
<bike>
is that something people really want? someone put it in my ctype library but i don't think i've ever particularly wanted it...
<jcowan>
hash-tables need two types, unless they are being used as sets and then they need only one type
<moon-child>
aeth: I just wanna fast implementation support for (logior (aref a i) (ash (aref a (+ 1 i)) 8) (ash (aref a (+ 2 i)) 16) (ash (aref a (+ 3 i)) 24)) where a is ub8
<moon-child>
oh another cool thing would be in-line :read-only arrays in structs
<jcowan>
Why read-only rather than both read-only and read-write?
anticrisis has joined #commonlisp
<moon-child>
the idea is to store it in the same allocation
<moon-child>
how would you do that if it's read-write?
<moon-child>
(like a trailing array member in c)
<Pixel_Outlaw>
Has anyone tried that newfangled Common Lisp IDE? I've mostly been an emacs guy but maybe it'll provide a nice environment for the guys at work to try CL.
<ldb>
especially I didn't see any email/IRC related feature on it
masinter has quit [Ping timeout: 255 seconds]
masinter has joined #commonlisp
contrapunctus has quit [Ping timeout: 248 seconds]
davidt has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
contrapunctus has joined #commonlisp
ldb has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
<aeth>
jcowan: I'm assuming that the reference is what's read-only and the contents can be mutable
<aeth>
but read-only arrays in structs isn't that big of a deal because when you care about arrays in structs they're usually quite large
<aeth>
what's much more of a big deal is that you can't put structs in arrays tightly, and never can with language semantics (but you could have an array-like sequence)
<moon-child>
yes :read-only the array elements can be changed. You just can't switch to a different array
<White_Flame>
of course there's always the old-school solution of having arrays of individual "struct slots" and a fixed pool
<moon-child>
what do I look like, a c programmer?
<White_Flame>
no, because you could actually resize the arrays easier than C ;)
waleee has quit [Ping timeout: 260 seconds]
dinomug has quit [Remote host closed the connection]
triffid has quit [Ping timeout: 256 seconds]
triffid has joined #commonlisp
<aeth>
adjustable and bounds checking don't go well together
<aeth>
C decides to not bounds check and maybe you're no longer in the array anymore and maybe you'll find out eventually
<aeth>
but it's frustrating to "know" the bounds of the adjustable array, but not statically, so you're doing a bounds check each access
<jcowan>
Actually, C permiss bounds checking, it's just that most implementations don't.
<moon-child>
c standard and implementations have a symbiotic relationship that mostly revolves around flagellating their users for lulz and 'historical reasons'
<aeth>
The worst part about C is probably that every major platform has its own, different C compiler (which probably also does C++). So you do have to worry about standard behavior, de facto standard behavior, implementation quirks, etc.
<aeth>
Although in theory you can also try using the same C compiler everywhere I guess.
anticomputer has quit [Remote host closed the connection]
moon-child is now known as childlikempress
anticomputer has joined #commonlisp
dcb has quit [Quit: MSN Messenger 4.1.0]
X-Scale68 has joined #commonlisp
X-Scale has quit [Ping timeout: 248 seconds]
random-jellyfish has quit [Ping timeout: 264 seconds]
<jcowan>
aeth: That overstates the case. gcc is dominant on Unix (by which I mean "everything but Apple and Windows") but is available everywhere; clang is dominant on Apple, is available on Unix, and is also available on Windows but requires either MSVC or gcc libraries; MSVC is available only on Windows.
<childlikempress>
clang is fairly dominant on non-apple unices, because a lot of the big corps are behind it
<aeth>
I guess at this point the various commercial Unix C compilers are dead (but I guess the various commercial Unixes/Unices/Unixen are basically dead, too)
<childlikempress>
but clang goes to some lengths to be gcc-compatible
<childlikempress>
aeth: the intel c compiler died recently, alas
msavoritias has joined #commonlisp
<childlikempress>
but I am reliably informed there is still considerable use of other c compilers outside of the client-desktop-bubble
<aeth>
I wouldn't be surprised if the various obscure platforms have some outdated, extended fork of GCC, though. I don't know if that's better or worse than having their own C compiler because now you have to use an old version
notzmv has quit [Ping timeout: 240 seconds]
<aeth>
Although in theory (and only in theory) you could bring that up to date because of the GPL.
<childlikempress>
gcc but also others
<childlikempress>
edg (which I believe is an ancestor of msvc and icc too)
<childlikempress>
is one at least
<Pixel_Outlaw>
Common Lisp is kind of a "thinking putty" that moves in the direction you push it. If anyone works on a multi member Common Lisp team, I'd be kind of interested to know how you stop each person from implimenting their own DSL and fragmenting the project.
<aeth>
I think the most natural way to do a Common Lisp team collaboration would be to divide things up... Conway's law it from the start. Give each person responsibility over what is effectively its own ASDF system and at least one package.
<aeth>
But, I have no experience here.
<childlikempress>
Pixel_Outlaw: you simply do not do that
<childlikempress>
agree upon style and interfaces
<Pixel_Outlaw>
Well, we have some possible Common Lisp tools on the horizon I tend to use a bit more CLOS but the other guys are Clojure guys so they'll try and turn it all into maps and arrow macros. :P
<Pixel_Outlaw>
The ideal program 1 lambda function 1000 arrow macros and an environmental map. :P
<aeth>
some people do weird things with CLOS
<childlikempress>
if you're not in agreement about what you're building and how you're building it you're going to have a bad time regardless
<aeth>
yeah, you kind of have to agree on the basic architecture
<aeth>
which is why I don't really collaborate; everyone on IRC is firmly in the CLOSify everything camp
<aeth>
while I don't believe in using DEFMETHOD until I actually need polymorphism
<Pixel_Outlaw>
But you get all those sweet :before :after and :around keywords! ;)
<childlikempress>
closify everything would be great if the implementations were competent and could optimise them :(
<Pixel_Outlaw>
I don't know it seems like the SBCL guys put a lot of work in to making things faster each release.
<aeth>
> COMEFROM is the inverse of GOTO in that it can take the execution state from any arbitrary point in code to a COMEFROM statement.
<childlikempress>
sbcl hasn't given any attention to this. Actually doing a good job would involve very large structural changes
<aeth>
DEFMETHOD :before :after :around is the ultimate COMEFROM
<Pixel_Outlaw>
An oppertunity for your PR! :)
<childlikempress>
fuck no
<childlikempress>
I'd rather start from scratch
<aeth>
^ the Lisp philosophy
<childlikempress>
sbcl is painful to work with'
Cymew has joined #commonlisp
donleo has joined #commonlisp
igemnace has joined #commonlisp
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
Pirx has quit [Ping timeout: 255 seconds]
Pixel_Outlaw has quit [Quit: Leaving]
bendersteed has joined #commonlisp
shka has joined #commonlisp
Inline has quit [Quit: Leaving]
Inline has joined #commonlisp
mrh57` has joined #commonlisp
mrh57` has left #commonlisp [#commonlisp]
mrh57 has joined #commonlisp
chomwitt has joined #commonlisp
MajorBiscuit has joined #commonlisp
rtypo has joined #commonlisp
random-jellyfish has joined #commonlisp
random-jellyfish has joined #commonlisp
rgherdt has joined #commonlisp
cage has joined #commonlisp
thollief has joined #commonlisp
son0p has quit [Ping timeout: 258 seconds]
habamax has joined #commonlisp
<beach>
Do you mean to work on the SBCL implementation, or to just use it?
anticrisis has quit [Read error: Connection reset by peer]
<childlikempress>
beach: the former
mgl has joined #commonlisp
<beach>
Got it.
kenran has joined #commonlisp
mrh57 has quit [Ping timeout: 260 seconds]
attila_lendvai has joined #commonlisp
vats has joined #commonlisp
dino_tutter has joined #commonlisp
varjag has joined #commonlisp
danse-nr3 has joined #commonlisp
vats has quit [Ping timeout: 240 seconds]
kenran has quit [Remote host closed the connection]
Inline has quit [Quit: Leaving]
danse-nr3 has quit [Remote host closed the connection]
danse-nr3 has joined #commonlisp
cognemo has quit [Ping timeout: 246 seconds]
yitzi has joined #commonlisp
wonko-the-sane has joined #commonlisp
karlosz has joined #commonlisp
tok has joined #commonlisp
rgherdt has quit [Ping timeout: 258 seconds]
danse-nr3 has quit [Ping timeout: 255 seconds]
danse-nr3 has joined #commonlisp
danse-nr3 has quit [Ping timeout: 260 seconds]
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.90)]
yitzi has quit [Remote host closed the connection]
karlosz has quit [Quit: karlosz]
danse-nr3 has joined #commonlisp
shka has quit [Read error: Connection reset by peer]
shka has joined #commonlisp
Lycurgus has joined #commonlisp
Lycurgus has quit [Changing host]
Lycurgus has joined #commonlisp
phantomics_ has joined #commonlisp
phantomics has quit [Ping timeout: 240 seconds]
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
karlosz has joined #commonlisp
karlosz_ has joined #commonlisp
karlosz_ has quit [Remote host closed the connection]
danse-nr3 has quit [Remote host closed the connection]
Lycurgus has quit [Quit: leaving]
karlosz has quit [Ping timeout: 258 seconds]
danse-nr3 has joined #commonlisp
random-nick has joined #commonlisp
karlosz has joined #commonlisp
Inline has joined #commonlisp
karlosz has quit [Client Quit]
karlosz has joined #commonlisp
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
ebrasca has joined #commonlisp
karlosz has quit [Read error: Connection reset by peer]
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
karlosz has joined #commonlisp
bendersteed has quit [Quit: bendersteed]
bendersteed has joined #commonlisp
vats has joined #commonlisp
igemnace has quit [Read error: Connection reset by peer]
eritamenm has joined #commonlisp
tyson2 has joined #commonlisp
karlosz has quit [Quit: karlosz]
vats has quit [Ping timeout: 240 seconds]
igemnace has joined #commonlisp
eritamenm has quit [Remote host closed the connection]
wonko-the-sane has quit [Remote host closed the connection]
Lycurgus has joined #commonlisp
Lycurgus has quit [Changing host]
Lycurgus has joined #commonlisp
edr has joined #commonlisp
Lycurgus has quit [Quit: leaving]
danse-nr3 has quit [Ping timeout: 272 seconds]
yitzi has joined #commonlisp
dino_tutter has quit [Ping timeout: 240 seconds]
danse-nr3 has joined #commonlisp
karlosz has joined #commonlisp
cage has quit [Remote host closed the connection]
danse-nr3 has quit [Remote host closed the connection]
danse-nr3 has joined #commonlisp
X-Scale has joined #commonlisp
cage has joined #commonlisp
Inline has quit [Ping timeout: 272 seconds]
bendersteed has quit [Quit: bendersteed]
eddof13 has joined #commonlisp
Gleefre has joined #commonlisp
danse-nr3 has quit [Ping timeout: 252 seconds]
varjag has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
karlosz has quit [Quit: karlosz]
Lycurgus has joined #commonlisp
trillp has joined #commonlisp
jonatack has quit [Ping timeout: 258 seconds]
yitzi has quit [Remote host closed the connection]
dcb has joined #commonlisp
MajorBiscuit has quit [Quit: WeeChat 4.1.0]
Lycurgus has quit [Quit: leaving]
notzmv has joined #commonlisp
karlosz has joined #commonlisp
karlosz has quit [Remote host closed the connection]
karlosz has joined #commonlisp
Cymew has quit [Quit: Konversation terminated!]
tok has quit [Remote host closed the connection]
merita has joined #commonlisp
dino_tutter has joined #commonlisp
karlosz has quit [Quit: karlosz]
grawlinson has quit [Quit: SIGTERM]
santiagopim has joined #commonlisp
merita has quit [Remote host closed the connection]
jonatack has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
grawlinson has joined #commonlisp
zephyr has quit [Quit: Leaving]
luis1 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
X-Scale has quit [Ping timeout: 248 seconds]
Gleefre has joined #commonlisp
kli6891 has joined #commonlisp
kli6891 has left #commonlisp [ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
X-Scale has joined #commonlisp
eddof13 has quit [Quit: eddof13]
eddof13 has joined #commonlisp
CO2 has quit [Quit: WeeChat 4.1.0]
tyson2 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
X-Scale has quit [Quit: Client closed]
yitzi has joined #commonlisp
random-jellyfish has quit [Ping timeout: 258 seconds]
luis1 is now known as luis
eddof13 has quit [Quit: eddof13]
waleee has joined #commonlisp
eddof13 has joined #commonlisp
pranavats has joined #commonlisp
CO2 has joined #commonlisp
NotThatRPG has joined #commonlisp
tyson2 has quit [Ping timeout: 264 seconds]
trillp has left #commonlisp [Leaving]
Guest63 has joined #commonlisp
Guest63 has quit [Client Quit]
triffid has quit [Ping timeout: 256 seconds]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
karlosz has joined #commonlisp
triffid has joined #commonlisp
zxcvz has joined #commonlisp
zxcvz has quit [Client Quit]
X-Scale has joined #commonlisp
Gleefre has quit [Ping timeout: 248 seconds]
eddof13 has quit [Quit: eddof13]
tyson2 has joined #commonlisp
X-Scale has quit [Ping timeout: 248 seconds]
eddof13 has joined #commonlisp
X-Scale has joined #commonlisp
CO2 has quit [Quit: WeeChat 4.1.0]
karlosz has quit [Quit: karlosz]
X-Scale has quit [Ping timeout: 248 seconds]
Gleefre has joined #commonlisp
zxcvz has joined #commonlisp
anticrisis has joined #commonlisp
CO2 has joined #commonlisp
msavoritias has quit [Remote host closed the connection]
eddof13 has quit [Quit: eddof13]
attila_lendvai has quit [Remote host closed the connection]
karlosz has joined #commonlisp
attila_lendvai has joined #commonlisp
igemnace has quit [Remote host closed the connection]
eddof13 has joined #commonlisp
rcharles has joined #commonlisp
rcharles has quit [Remote host closed the connection]
rcharles has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
Lycurgus has joined #commonlisp
Just_in has quit [Quit: Leaving]
yitzi has quit [Remote host closed the connection]
zxcvz has quit [Quit: zxcvz]
Oladon has joined #commonlisp
gooba has quit [Remote host closed the connection]
X-Scale has joined #commonlisp
eddof13 has quit [Quit: eddof13]
tyson2 has quit [Remote host closed the connection]
Lycurgus has quit [Quit: leaving]
thollief has quit [Quit: Leaving]
attila_lendvai has quit [Ping timeout: 240 seconds]
eddof13 has joined #commonlisp
attila_lendvai has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 29.1]
eddof13 has quit [Quit: eddof13]
eddof13 has joined #commonlisp
eddof13 has quit [Client Quit]
eddof13 has joined #commonlisp
mgl has quit [Ping timeout: 255 seconds]
Gleefre has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 255 seconds]
waleee has joined #commonlisp
eddof13 has quit [Quit: eddof13]
rcharles has quit [Remote host closed the connection]
rgherdt has joined #commonlisp
<lispmacs[work]>
I was a little confused by what exactly the processor cycles count means in the SBCL time implementation. I looked at the DESCRIBE string and now I am even less certain. Is it documented somewhere what it means exactly for x86-64?
Inline has joined #commonlisp
<lispmacs[work]>
the function doesn't seem to be even mentioned in the SBCL manual, I suppose I'll need to dive into the compiler source
<bike>
lispmacs[work]: i think it's pretty raw RDTSC output.
CO2 has quit [Quit: WeeChat 4.1.0]
<lispmacs[work]>
bike: so just the number of clock cycles that have passed between start and stop?
<childlikempress>
I think it's rdtsc too
<childlikempress>
rdtsc measures real time, not actual clock cycles, on recent x86 cpus
<bike>
lispmacs[work]: yep.
<lispmacs[work]>
hmm, so a pretty much meaningless statistic
<lispmacs[work]>
unless your computer happens to be doing absolutely nothing else
<childlikempress>
(time (sleep 1))
<childlikempress>
...
<childlikempress>
3,000,217,812 processor cycles
<bike>
i wouldn't use it for much of anything but comparisons between runs
<childlikempress>
there is some pmc stuff for measuring actual clock cycles but pmc is ... an adventure
X-Scale has quit [Ping timeout: 248 seconds]
<lispmacs[work]>
pmc?
<lispmacs[work]>
profiler
<lispmacs[work]>
?
<childlikempress>
performance monitoring counters
<childlikempress>
rdpmc
<lispmacs[work]>
okay
Oladon has quit [Quit: Leaving.]
waleee has quit [Ping timeout: 255 seconds]
X-Scale has joined #commonlisp
pve has quit [Quit: leaving]
<lispmacs[work]>
(typep 3 'number)
<lispmacs[work]>
oops, sorry
attila_lendvai has quit [Ping timeout: 255 seconds]
karlosz has quit [Ping timeout: 240 seconds]
X-Scale has quit [Ping timeout: 248 seconds]
X-Scale48 has joined #commonlisp
<lispmacs[work]>
how do I create a vector with a specified length and initialized value?
<lispmacs[work]>
i.e, without having to type out (vector val1 val2 val3...) where valn are all the same
<childlikempress>
make-array n :initial-element x
CO2 has joined #commonlisp
<aeth>
It's make-array, not make-vector, because it's generalized to arrays (n-dimensional), of which vectors are the 1-dimensional subtype.
<aeth>
so you can (make-array n) and you can (make-array '(m n))
<aeth>
or rather, you'd have to do something like (make-array '(4 3)) or (make-array `(,m ,n))
rgherdt has quit [Remote host closed the connection]
rgherdt_ has joined #commonlisp
waleee has joined #commonlisp
X-Scale has joined #commonlisp
X-Scale48 has quit [Ping timeout: 248 seconds]
random-nick has quit [Ping timeout: 258 seconds]
shka has quit [Ping timeout: 255 seconds]
<lispmacs[work]>
aeth: okay, thanks. I see there is an initial-element parameter
X-Scale75 has joined #commonlisp
Pirx has joined #commonlisp
rgherdt_ has quit [Quit: Leaving]
X-Scale has quit [Ping timeout: 248 seconds]
notzmv has quit [Ping timeout: 258 seconds]
anticrisis has quit [Read error: Connection reset by peer]
<aeth>
iirc, you always should use initial-element because otherwise the implementation will probably guess a 0 (or #\Nul if string) by the element-type but it's undefined behavior (and NIL would be a reasonable default for when the element-type is the default, T, but SBCL seems to use 0, so already there's a place for Lisp implementations to diverge in behavior)
<aeth>
except when you use initial-contents, then you can't use initial-element
<lispmacs[work]>
aeth: so, I'm trying to use aref on the array made with make-array
<lispmacs[work]>
oh, the indices are not also specified as a list
<lispmacs[work]>
I assumed '(2 1)
<aeth>
they have to be a list in make-array because they're not in the final position (and the final position is keywords, so it's basically a plist tail, so it would be impossible to tell the difference between keys and values)
<aeth>
but lists are kinda inefficient unless literal, so in AREF it makes sense not to use them
<aeth>
also note that you can use initial-contents instead of initial-elment, which may be more efficient if you have a literal list to initialize from (but probably isn't more efficient if you have to build the list up)
<aeth>
almost everything should have either initial-contents or initial-element (you can only get away with not including it if you're going to set every value before anyone views it and so have no undefined/unspecified values remaining)
<aeth>
They also often have an element-type (but this is only for character or numeric types that are simple enough, so e.g. almost every implementation supports single-float (only CLISP doesn't, iirc?) while no implementation supports float, which would be all 2-4 supported float types). You can thus use this to create a string (with 'character as the element-type) or an (unsigned-byte 8) array or whatever.
<aeth>
They can be adjustable, but only when 1D.
<bike>
huh? you can have adjustable multidimensional arrays. you just can't vector-push-extend them.
Pixel_Outlaw has joined #commonlisp
<aeth>
you can? weird
<aeth>
I have never seen them
<aeth>
I guess you manually adjust using the lower level functionality?
<bike>
you use adjust-array.
Inline has quit [Quit: Leaving]
dino_tutter has quit [Ping timeout: 248 seconds]
Inline has joined #commonlisp
<lispmacs[work]>
with structures, are the field names stored outside of each structure instance? i.e., is the structure instance memory-efficient?
waleee has quit [Quit: WeeChat 4.0.2]
<lispmacs[work]>
am using SBCL
<childlikempress>
yes, it is fairly efficient
<jcowan>
lispmacs[work]: They are not stored in the struct at all, because structs are accessed only through accessors, not by slot names
<ixelp>
(defstruct foo x) => FOO, and then (slot-value (make-foo :x 5) 'x) => 5
Gnuxie has joined #commonlisp
<childlikempress>
in sbcl, a struct is represented as a header word, sometimes another header word, and then one word per slot (or two words, in the case of a complex double float)