<heisig>
loke: I'm asking because I am working on a portable type inference and function specialization library.
<heisig>
And I'm thinking about things like GPU offloading for some programs, so it is important for me to figure out which Lisp types correspond to which C/OpenCL/CUDA types.
<heisig>
If I can reasonably assume that single-float is a 32bit IEEE float, that simplifies a lot.
<heisig>
loke: By the way, I just read the CLISP documentation and it seems that single-float and double-float are IEEE 754 floats.
<loke>
You can't. You can assume it'll be close to it though.
nullman has quit [Ping timeout: 244 seconds]
<heisig>
loke: Can you elaborate? So far, the only problems I see is the behavior with respect to over- and underflow and infinities.
libertyprime has quit [Read error: Connection reset by peer]
iovec has quit [Quit: Connection closed for inactivity]
<jackdaniel>
heisig: one catch: cl standard guarantees that there is a system class float
<jackdaniel>
*-float may be defined just as types (without class)
<jackdaniel>
also it is worth noting, that long-float in ecl defaults to long double C type while in sbcl long-float is the same thing as double-float
<jackdaniel>
and that no implementation I'm aware of implements short-float as 16bit IEEE float :)
<loke>
I could imagine a 30-bit short-float though, which woudln't require boxing
<jackdaniel>
32bit float could be an immediate type as well on 64-bit systems
<jackdaniel>
I think it is in fact on cmucl, sbcl and ccl
<loke>
Yes, but they would require more storage
cosimone has joined #lisp
<beach>
loke: Why do you think that?
<jackdaniel>
pointer has the same amount of memory disregarding how many bits has the underlying object
<jackdaniel>
s/pointer/memory address/
<loke>
If you crate an array of N short-floats, I'd want that array to occupy 4*N bytes o fmemory
<beach>
loke: There would very likely be a specialized array type that would store them unboxed.
<loke>
beach: You'd want ot be able to store nil etc as well in it
<jackdaniel>
yes, arrays may be specialized and it is orthogonal to immediate types
<loke>
There are definitely benefits to an unboxed floating point type.
<jackdaniel>
that would be a wasteful optimization (to have such bivalent specialized arrays)
<loke>
jackdaniel: Exactly.
<loke>
so you create a 30-bit type so you don' thave to specialise.
<jackdaniel>
who said that array alement storage is 32bit?
<jackdaniel>
if memory addresses have 64bit, then there you go
<loke>
Efficiency. Lots of bit-fiddling otherwise, or you'll be wasting space.
<heisig>
Let me point out that I don't care about short-floats and long-floats. Or rather, I acknowledge that there is no consensus in CL on how they ought to be represented.
<beach>
loke: I still don't understand. If you have an unspecialized array, your 30-bit floats would still take up a full pointer.
<jackdaniel>
exactly
<loke>
beach: I'm thinking something along the lines of what the JVM does.
<jackdaniel>
there won't be bit-fiddling if you may have arbitrary object there
<beach>
loke: You would have to tell me what it does.
<loke>
beach: It uses 64-bit pointers/values, but if the top 32 bits are zeroes, they only occupy 4 bytes of storage.
<loke>
beach: As long as your heap is >4GB, all points only needs 32 bits.
<jackdaniel>
loke: how do you find 123432th element address then?
<jackdaniel>
you look for elements and count how many occupy reduced space?
<loke>
jackdaniel: No. The packed format only works when the heap is less than 4 GB in size.
<beach>
loke: You mean < rather than >?
<loke>
Then it switches to full 64-bit pointers.
<beach>
I see.
<loke>
beach: Yes, of course :-)
<loke>
The heap doesn't have to be located at address zero. Pointers are an offet from heap start.
<loke>
offset
<jackdaniel>
why then such float would need to have 30bits (and not 32bits)?
<loke>
Because if a Lisp implementation wanted to implement this, they'd need tagging, which I presume would occupy at least two bits.
<shka__>
wow, java does that?
<shka__>
crazy
<loke>
shka__: Yes, it does.
<shka__>
interesting, not sure if worth it
<jackdaniel>
loke: I don't think that any CL implementation does change memory address size at runtime
<jackdaniel>
and I can imagine how tedious that would be (especially with regard to immediate types)
<loke>
shka__: There are flags to control whether or not it's used. By defaul tit uses it if the heap can fit within the low 4 GB of address space (i.e. it doesn't normally use the offset trick unless requested, since it can slow things down)
<jackdaniel>
but now I get what you say, thank you for the explanation
<shka__>
well, there is a burden on the code base regardless
<loke>
shka__: I didn't know about it either until our application at work started failing weirdly. Turns out aht because we embed a JVM, an dby default packing is enabled, it hard-located its heap just below the 4 GB limit, so when the C++ code wanted to allocated more memort, BOOM. The break pointer crashed into the Java heap.
<jackdaniel>
sounds like "fun" to debug ,)
<loke>
jackdaniel: I've worked so much with the JVM recently, that I kind of instinctively think about this stuf fin JVM terms. :-) Soryr about that.
<loke>
jackdaniel: Yeah. And it wasn't obvious at first. It was kind of easy to note that the Java heap was blocking the C++ malloc() function, since there was a JVM-sized [anon] block in the heap map.
<jackdaniel>
imo specialized arrays are good enough for saving space, and if you want to be generic all the way down then you need to deal with addresses which won't surprise you at random time ,)
<loke>
Figuring out why the JVM wnated to be below 4 GB was the tricky part. There wasn't anything obvious to good for. I can't remember how I found the documentation on it.
<shka__>
beach: quick question regarding sbcl immobile spaces: it is an issue with just generic functions, and not just with any funcallable object?
<heisig>
loke: You still haven't told me why I shouldn't assume that single-float and double-float are IEEE 754 floats.
<beach>
It used to be all funcallable standard objects, but stassats kindly changed that for me, so that now it is only generic functions.
<beach>
shka__: ^
kajo has joined #lisp
<loke>
heisig: Because the standard allows it to be different, and you shouldn't assume things that the standard explicitly states are unspecified. SBCL in particular tend to take advatage of these (non)-guarantees.
<shka__>
beach: great, thanks
<jackdaniel>
heisig: it would be a good idea to add a new feature to trivial-features :ieee-floats
<jackdaniel>
on sbcl and ecl it is :IEEE-FLOATING-POINT
<heisig>
jackdaniel: Hmm, yes, I should at least check for the presence of these features.
<jackdaniel>
ccl doesn't have anything interesting relevant to this in features
<jackdaniel>
I've reported the issue in this library repository
nullman has joined #lisp
<scymtym>
jackdaniel: if i'm not mistaken, a new feature is not needed. clhs *FEATURES* says ":ieee-floating-point If present, indicates that the implementation purports to conform to the requirements of IEEE Standard for Binary Floating-Point Arithmetic."
<jackdaniel>
scymtym: you are right
refpga has joined #lisp
ggole has joined #lisp
grms has joined #lisp
libertyprime has joined #lisp
refpga has quit [Ping timeout: 246 seconds]
<aeth>
but CCL doesn't have it in its *FEATURES*?
anewuser has joined #lisp
<jackdaniel>
I think that this is a question for #ccl developers whenever their implementation has some lackings or it was simply an omission (or functionality was implemented over time and nobody thought about adding the feature)
<jackdaniel>
so many possibilities
xkapastel has joined #lisp
<Xach>
so many
donotturnoff has joined #lisp
esrse has quit [Ping timeout: 248 seconds]
cosimone has quit [Quit: WeeChat 2.4]
aautcsh has joined #lisp
refpga has joined #lisp
ludston has joined #lisp
lavaflow has quit [Ping timeout: 248 seconds]
crystalball has joined #lisp
theBlackDragon has joined #lisp
<phoe>
is there any kind of test suite for testing ieee-floats conformance in CL?
<jackdaniel>
there is a limited number of tests for ieee in ansi-tests
<jackdaniel>
that should be put in ansi-beyond test suite
<jackdaniel>
(atan nan /anything/) -> nan ,)
jkordani_ has joined #lisp
<jackdaniel>
(atan -inf -inf) -> -3pi/4
abarbosa has quit [Ping timeout: 258 seconds]
<phoe>
jackdaniel: wait a second, where does this last result come from
<phoe>
this is maybe offtopic but I seriously have no idea
blandest has joined #lisp
rumbler31__ has joined #lisp
<jackdaniel>
don't ask me, I was working on that almost 3y ago
<jackdaniel>
signed 0 examples from the spec afair
<jackdaniel>
or maybe not, either way I took it from /somewhere/ what was concerned about ieee conformance and atan
jkordani has quit [Ping timeout: 268 seconds]
jkordani has joined #lisp
jkordani_ has quit [Ping timeout: 245 seconds]
Lycurgus has quit [Quit: Exeunt]
jkordani_ has joined #lisp
<jackdaniel>
but it looks spectacular, doesn't it? :)
GoldRin has joined #lisp
rumbler31__ has quit [Ping timeout: 248 seconds]
jkordani has quit [Ping timeout: 268 seconds]
anewuser has quit [Ping timeout: 258 seconds]
rumbler31__ has joined #lisp
orivej has quit [Ping timeout: 248 seconds]
jkordani_ has quit [Ping timeout: 248 seconds]
crystalball has quit []
Josh_2 has quit [Remote host closed the connection]
cosimone has joined #lisp
Bike has joined #lisp
dale_ has joined #lisp
dale_ is now known as dale
LiamH has joined #lisp
<phoe>
...yes it does
v88m has quit [Read error: Connection reset by peer]
v88m has joined #lisp
amerlyq has joined #lisp
dale has quit [Quit: dale]
orivej has joined #lisp
blandest has quit [Ping timeout: 252 seconds]
dale has joined #lisp
sz0 has quit [Quit: Connection closed for inactivity]
aautcsh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aautcsh has joined #lisp
Inline has joined #lisp
hhdave_ has joined #lisp
saravia has joined #lisp
hhdave has quit [Ping timeout: 248 seconds]
hhdave_ is now known as hhdave
saravia has quit [Client Quit]
Inline has quit [Client Quit]
Inline has joined #lisp
Lord_of_Life_ has joined #lisp
sjl_ has joined #lisp
rippa has joined #lisp
Lord_of_Life has quit [Ping timeout: 272 seconds]
Lord_of_Life_ is now known as Lord_of_Life
froggey has quit [Remote host closed the connection]
moldybits has quit [Ping timeout: 248 seconds]
Jesin has quit [Quit: Leaving]
froggey has joined #lisp
aautcsh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
scymtym has quit [Ping timeout: 252 seconds]
orivej has quit [Ping timeout: 248 seconds]
jprajzne has quit [Remote host closed the connection]
Jesin has joined #lisp
flamebeard has quit []
<LdBeth>
Does CFFI able to access variables defined as C preprocessor macros?
travv0 has left #lisp [#lisp]
v88m has quit [Ping timeout: 245 seconds]
hhdave_ has joined #lisp
<jackdaniel>
"C preprocessor macros" are not available in the resulting binary after compiling with C compiler
hhdave__ has joined #lisp
hhdave has quit [Ping timeout: 258 seconds]
<jackdaniel>
(so no, it can't)
<Bike>
you have to grovel for those.
manualcrank has joined #lisp
<LdBeth>
So are there any tools can help generating wrappers if the header files are provided?
hhdave has joined #lisp
hhdave_ has quit [Ping timeout: 268 seconds]
hhdave_ has joined #lisp
<jackdaniel>
as Bike said, groveller is used to look into header files to infere some things
hhdave__ has quit [Ping timeout: 268 seconds]
<jackdaniel>
to what extent it could be used as means to "record" preprocessor macros is not known to me
<jackdaniel>
is there a reason you want to have these preprocessor macros definitions?
hhdave__ has joined #lisp
<pjb>
LdBeth: the main problem with the preprocessor, is that it depends on the preprocessing. Which can be different on each compilation,
<pjb>
LdBeth: there's no guarantee that the preprocessing done by lisp tools will give the same macro values as when the actual C library was compiled.
hhdave has quit [Ping timeout: 248 seconds]
<pjb>
LdBeth: therefore, don't do that. Instead, design your C API to not use preprocessing macros.
<pjb>
LdBeth: eg. instead of #define FOO 42 use const int FOO=42;
hhdave has joined #lisp
<pjb>
LdBeth: eg. instead of #define FOO(x) (x-1) use inline int FOO(int x){ return x-1; }
<pjb>
LdBeth: but really, just don't use fucking FFI.
actuallybatman has joined #lisp
<pjb>
Write it in Common Lisp!
ym555 has joined #lisp
orivej has joined #lisp
hhdave___ has joined #lisp
hhdave_ has quit [Ping timeout: 272 seconds]
v88m has joined #lisp
<LdBeth>
I’m planning port GNU lighting
hhdave_ has joined #lisp
hhdave__ has quit [Ping timeout: 245 seconds]
hhdave__ has joined #lisp
hhdave has quit [Ping timeout: 246 seconds]
hhdave has joined #lisp
<LdBeth>
There’s not much info about calling assembly code generated at runtime in CL
<jackdaniel>
clisp uses this jit library
hhdave___ has quit [Ping timeout: 245 seconds]
<jackdaniel>
you may take inspirate in its source code
<Bike>
it's probably used in the c part of clisp, though...
hhdave_ has quit [Ping timeout: 246 seconds]
<LdBeth>
It uses a lot macrology
<LdBeth>
And not designed for being called from ABI
hhdave__ has quit [Ping timeout: 248 seconds]
<LdBeth>
But it is a lightweight replacement for LLVM
aautcsh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sauvin has quit [Ping timeout: 244 seconds]
beach has quit [Ping timeout: 258 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
iovec has joined #lisp
cosimone has quit [Quit: WeeChat 2.4]
donotturnoff has quit [Ping timeout: 272 seconds]
refpga has quit [Remote host closed the connection]
refpga has joined #lisp
Lycurgus has joined #lisp
actuallybatman has quit [Ping timeout: 245 seconds]
gravicappa has quit [Ping timeout: 246 seconds]
scymtym has joined #lisp
slac-in-the-box has joined #lisp
donotturnoff has joined #lisp
edgar-rft has joined #lisp
donotturnoff has quit [Ping timeout: 248 seconds]
shka_ has quit [Ping timeout: 245 seconds]
vlatkoB has quit [Remote host closed the connection]
cosimone has joined #lisp
ricekrispie has quit [Quit: YEET]
aautcsh has joined #lisp
aautcsh has quit [Client Quit]
refpga has quit [Ping timeout: 272 seconds]
APic has joined #lisp
ricekrispie has joined #lisp
xkapastel has joined #lisp
wigust- has joined #lisp
bexx has quit [Remote host closed the connection]
wigust has quit [Ping timeout: 258 seconds]
ebrasca has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 245 seconds]
<markasoftware>
what's the logic behind :symbol for package names instead of 'symbol ?
<markasoftware>
package names don't logically seem like keywords to me, since they're user-defined
<markasoftware>
package names logically refer to something, not just to themselves -- they represent a package
<White_Flame>
if they were always keywords, it would save a bit of space, compared to all packages which reference it by name interning their own 'SYMBOL
<White_Flame>
#:symbol is also common
<dmiles>
it is mainly sanitation
<White_Flame>
although that doesn't pollute your own package, it does take up that bit more of space :)
hiroaki has quit [Ping timeout: 252 seconds]
<grewal>
I prefer how my editor highlights 'symbol over :symbol
<pjb>
markasoftware: you're perfectly right. package operators take string designators. You can as well pass strings.
<pjb>
dmiles: package names are very officially case sensitive.
<White_Flame>
dmiles: yeah, I wish symbols were truly case-insensitive
<markasoftware>
ah, but i need to capitalize if i use a string?
<White_Flame>
that's how we've typically done it in our languages
<pjb>
White_Flame: which would be a bad move, since you couldn't use "MyPackage" as package name.
<White_Flame>
why not?
<dmiles>
if you use a "MyPackage" you need to do a #:|MyPackage| maybe
<pjb>
(defpackage "MyPackage" (:use :cl) (:export :foo)) (list MyPackage:foo ) #| ERROR: There is no package named "MYPACKAGE" . |#
<pjb>
dmiles: indeed.
<White_Flame>
sure, because CL is case-sensitive for its symbols
<White_Flame>
I said I wished it was case-INsensitive
<White_Flame>
and our languages have case-insensitive symbols
Bike has quit [Ping timeout: 256 seconds]
sebboh has quit [Ping timeout: 252 seconds]
<pjb>
Nope. Most languages are case sensitive. The only language that is not AFAIK, is Chinese.
cosimone has quit [Quit: WeeChat 2.4]
<markasoftware>
well, thanks! Packages are one of my few remaining major confusion points.
<dmiles>
I wish Prolog use Lisp packages
<White_Flame>
yeah, packages are a bit confusing at first, usually because the same name "package" means different things in other languages. Here in CL, a package is literally a namespace, only affecting symbols
Fare has joined #lisp
<White_Flame>
pjb: "our languages" = internal programming languages we use
Bike has joined #lisp
shifty has joined #lisp
hiroaki has joined #lisp
nowhere_man has quit [Ping timeout: 258 seconds]
actuallybatman has joined #lisp
polezaivsani has quit [Quit: ERC (IRC client for Emacs 26.2)]
<remexre>
is it possible to dispatch a method based on a (satisfies _) type?
<pjb>
remexre: of course.
<pjb>
remexre: read the /topic !
<Bike>
remexre: not really.
<pjb>
remexre: the question is not whether it's possible, but whether it's wise to do it.
<Bike>
the type system isn't restricted enough to allow the way normal method dispatch works.
<pjb>
Bike: well, the not really comes from the fact that testing for satisfies doesn't necessarily call the satisfying function.
<pjb>
remexre: but you can do something similar just giving the predicate.
<pjb>
remexre: it takes less time to implement it than this discussion so far, by the way.
<remexre>
how, then? I'm currently doing (defmethod foo (bar (baz (satisfies quux))) ...), but CCL throws an error at this
<remexre>
Illegal arg (SATISFIES QUUX)
<Bike>
that's because it's not allowed.
Fare has quit [Ping timeout: 245 seconds]
<Bike>
methods dispatch on EQL specializers (eqling a particular object) or classes, and satisfies types aren't classes.
<aeth>
some libraries dispatch on types
<Bike>
you could extend the system to dispatch more generally, but then you lose a lot of properties of clos.
dagg has joined #lisp
<remexre>
hm
<Bike>
and of course you could just have a body like (if (quux baz) thingone thingtwo).
zulu-inuoe has quit [Read error: Connection reset by peer]
<remexre>
I'm using (eql) in other places and need to be able to keep adding more (eql) variants
zhlyg has quit [Ping timeout: 272 seconds]
<Bike>
sure? eql is built in.
<remexre>
I guess the satisfies ones are finite so I could put them in a default one?
<Bike>
i don't know what you mean by "finite".
<remexre>
er, don't need to be extended
<White_Flame>
that sounds appropriate
<remexre>
I'll give this more thinking; thanks all!
<semz>
Bike: what properties would be lost by a more general dispatch?
<Bike>
ordering, mainly.
LiamH has quit [Quit: Leaving.]
<Bike>
a lot of clos's rules are about being able to translate a network of subtype relationships into a line, the class precedence list.
<Bike>
once you have that you can have a defined order for methods running.
<Bike>
satisfies types are completely arbitrary, which means they can overlap in disorganized ways. worse, figuring out the subtype relationship at all is impossible.
<semz>
i see
<dagg>
Hello. Can I pass a default arg to function? I. e.:
<dagg>
(defun test (&optional (a 0) (b 0)) (list a b))
<dagg>
→ (0 1)
<dagg>
(test :unprovided 1)
<Bike>
you have to specify the default.
<Bike>
like, write (test 0 1)
<Bike>
you can't leave one argument unprovided but provide the next.
<dagg>
Hmm... Pity.
<Bike>
if you want to do that, use &key instead.
<dagg>
The function #'test is given.
<dagg>
Why this feature is so commonly used, if it makes code so unflexible, I wonder.
<dagg>
Instead of the approach normal for Scheme (or Emacs Lisp): (setf a (or a 0)), I mean.
<Bike>
i think there is actually a bias against &optional in new code. maybe only a little, though.
<Bike>
functions sometimes do that too.
<Bike>
like a lot of the standard printing functions.
<remexre>
pjb: huh, okay, I'll give those a look in a bit; thanks!
<pjb>
remexre: now of course, if you have a lot of methods, you may want to be more efficient in find-predicate-dispatch-method. eg. you can use a tree instead of a list. or a tree of hash-tables, etc.
Fare has joined #lisp
Bike has quit []
Fare has quit [Ping timeout: 246 seconds]
dagg has quit [Quit: ERC (IRC client for Emacs 27.0.50)]
Fare has joined #lisp
sjl_ has quit [Quit: WeeChat 2.3-dev]
iovec has quit [Quit: Connection closed for inactivity]
didi has joined #lisp
abarbosa has quit [Ping timeout: 258 seconds]
<didi>
Curious limitation: the size of a byte is unchangeable after the stream has been created.
<didi>
Not that I ever had to use a byte size different than 8.
dacoda has joined #lisp
abarbosa has joined #lisp
nowhere_man has joined #lisp
orivej has joined #lisp
Fare has quit [Ping timeout: 244 seconds]
<didi>
Also, no `unread-byte'.
moei has quit [Quit: Leaving...]
makomo has quit [Ping timeout: 245 seconds]
ludston has joined #lisp
Bike has joined #lisp
edgar-rft has quit [Ping timeout: 248 seconds]
amerlyq has quit [Quit: amerlyq]
actuallybatman has quit [Ping timeout: 248 seconds]
ltriant has joined #lisp
aautcsh has joined #lisp
v88m has quit [Ping timeout: 272 seconds]
v0|d has quit [Ping timeout: 248 seconds]
Oladon has joined #lisp
actuallybatman has joined #lisp
Lycurgus has quit [Quit: Exeunt]
moldybits has quit [Read error: Connection reset by peer]