<aeth>
jasom: single-float's used a lot in graphics. Plus, you can work with double-floats and have single-float as the end result.
<jasom>
you would need to vary your range by 2**39 to ever have more precision with single-float vs unsigned-byte 64
<jasom>
aeth: I'm talking about 64 bit machines, where unboxed single-floats are used.
on_ion has quit [Quit: WeeChat 1.9.1]
<aeth>
jasom: single-floats are faster when you don't really care about the end result that much (e.g. gaming), and even faster since you'd have to use a third party library for fixed-point arithmetic
<aeth>
jasom: afaik in practice single-floats are just double-floats whose end results are stored as single-floats in CL implementations
<aeth>
for e.g. sin
<jasom>
single-floats are faster than 64-bit integers? I'd bet that depends on the operation.
<aeth>
jasom: Assuming not +/- (and *?)
r1b has quit [Quit: r1b]
<aeth>
jasom: But even then in CL you'd have to wrap it in (mod ... (expt 2 64)) after every operation to get it to be fast
<aeth>
(assuming the implementation even optimizes that, like SBCL does)
tsandstr has quit [Remote host closed the connection]
<aeth>
okay, it's actually generally just run with sb-int:with-float-traps-masked and a slow path for every other implementation, but that's the author's fault for not using the library Shinmera wrote for that
<jasom>
ah. I really don't like floats so haven't explored such things in CL much.
<aeth>
jasom: it's actually really great
rumbler31 has quit [Remote host closed the connection]
<jasom>
I do very few calculations where the required precision is relative to the magnitude of the value, so *shrug*
<aeth>
jasom: mask float traps when you are running your application, but keep the defaults when you run your unit tests
Roy_Fokker has quit [Read error: Connection reset by peer]
<aeth>
So during your unit tests, you can see the overflows/etc.
<jasom>
My motto is "fixnums can represent the entire solar system to a precision of under 1mm"
<aeth>
jasom: usually there's some complicated algorithm that works around problems with floating point... and you can just implement the algorithm
<jasom>
aeth: at which point single-floats may no longer keep up with fixed-point
<aeth>
jasom: why not both?
<aeth>
jasom: If you do a solar system with single-floats (you could just go to doubles at that point) then you can divide it into zones
<aeth>
small integer zones
<aeth>
jasom: anyway, I think floating point is in general faster because CPUs build in hardware for floating point (but you might need special ASM to access it all)
<jasom>
At a minimum, my point is that integers are much larger than they were when floating-point won over fixed-point, so reevaluating ones choices might be good. Also, outside of certain scientific calculations the assumptions of floating-point may not fit your data
<jasom>
CPUs build in hardware for integers too...
<aeth>
eh, it depends on what speed you want
<jasom>
in any event, dinner, I'll look at your last points later :)
<aeth>
if you're doing real time use floats, if you're doing supercomputer simulations use floats.
<aeth>
Anything where you'd be using Fortran before SBCL became an acceptable Fortran, you probably want floats.
<aeth>
(Whether you want single-float or double-float or both depends on specifics)
<aeth>
I've written my share of efficient integer arithmetic, too. It's a bit more painful in CL because CL actually wants correct behavior, so you need to establish your bounds or use unsigned and wrap each arithmetic operation with mod of a power of 2
<aeth>
I'm sure a compiler that enforced float correctness would make floats equally or more painful, of course. With floats you just get runtime nonsense values or a runtime exception (depending on settings), rather than a compile time possible bignum allocation.
quazimodo has quit [Ping timeout: 272 seconds]
<aeth>
I have established bounds for certain float functions with random testing, but I think that those bounds are probably best left as just documented rather than enforced.
quazimodo has joined #lisp
oni-on-ion has joined #lisp
r1b has joined #lisp
oni-on-ion has quit [Quit: WeeChat 1.9.1]
pjb has quit [Ping timeout: 252 seconds]
oni-on-ion has joined #lisp
<aeth>
Anyway, that's just my 2¢. On the other hand, if there's anyone who'd waste months implementing efficient fixed point in CL to be used in a handful of functions, it'd probably be me. :-p
<oni-on-ion>
topic, sbcl 1.4.5 -> 1.4.12
robotoad has quit [Quit: robotoad]
<oni-on-ion>
"optimization: adding 1 to or subtracting 1 from a fixnum variable does not cons." =)
<oni-on-ion>
(1.4.10)
<oni-on-ion>
aeth: been following it? used SB-COVER?
ryan_vw has joined #lisp
<aeth>
oni-on-ion: code coverage, as in it tracks to see how much is tested?
<aeth>
Hmm, doesn't appear to give correct results for me. I guess I was reading the manual incorrectly.
<aeth>
I do know that the coverage is very low, though. :-)
pierpal has quit [Remote host closed the connection]
scymtym has quit [Remote host closed the connection]
<Xach>
arrrgh postmodern is busted
<no-defun-allowed>
):
scymtym has joined #lisp
tsandstr has joined #lisp
<no-defun-allowed>
Xach: what happened to it?
<Xach>
duplicate definition at the end of postmodern/utils.lisp
Balooga_ has joined #lisp
Denommus has quit [Remote host closed the connection]
<no-defun-allowed>
that's a shame
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
pjb has joined #lisp
sjl has quit [Ping timeout: 252 seconds]
s-geometry has joined #lisp
elfmacs has joined #lisp
<no-defun-allowed>
hi s-geometry
frgo has joined #lisp
s-geometry has quit [Read error: Connection reset by peer]
wanz has joined #lisp
frgo has quit [Ping timeout: 272 seconds]
Balooga_ has quit [Quit: Balooga_]
r1b has quit [Quit: r1b]
ACE_Recliner has quit [Remote host closed the connection]
meepdeew has quit [Remote host closed the connection]
<|3b|>
you need to pass the local environment to macro0expand to see macrolet
* |3b|
doesn't remember if there is a better way to get that local environment than with a macro or not
<beach>
I don't think so.
meepdeew has joined #lisp
<|3b|>
macro/macrolet accept &environment lambda-list keyword to let you get access to the environment while expanding the macro
<|3b|>
something like (defmacro x (form &environment e) `',(macroexpand form e))
meepdeew has quit [Ping timeout: 245 seconds]
<|3b|>
then inside your macrolet (x (slot my-slot)) will expand to '(my-slot ...)
frgo has joined #lisp
dented42 has joined #lisp
beaky has quit [Quit: WeebChat 2.0.1]
frgo has quit [Ping timeout: 244 seconds]
ealfonso has quit [Ping timeout: 252 seconds]
ealfonso has joined #lisp
<ealfonso>
beach |3b| thanks
shifty has quit [Ping timeout: 268 seconds]
7IZAAM9GH has quit [Quit: 7IZAAM9GH]
slyrus1 has joined #lisp
meepdeew has joined #lisp
drl has quit [Ping timeout: 252 seconds]
<ealfonso>
actually I'm still stuck... shouldn't the inner macro (defined via macrolet) be expanded before the defclass macro? https://pastebin.com/1U571DZC
<Bike>
no.
<Bike>
why would it be?
<Bike>
since that's not even in a normal evaluation context, the my-local-slot-macro form will never be evaluated, so it's just a syntax error.
<beach>
ealfonso: Macro calls are expanded only when they are in a position of evaluation.
<beach>
ealfonso: The slots of a DEFMACRO form are not in such a position.
<ealfonso>
I see
<beach>
I am saying the same thing as Bike, only with different words.
lavaflow has quit [Read error: Connection reset by peer]
moei has quit [Read error: Connection reset by peer]
moei has joined #lisp
dented42 has joined #lisp
dented42 has quit [Ping timeout: 268 seconds]
myrmidon has joined #lisp
cl-arthur has joined #lisp
dented42 has joined #lisp
jgoss has quit [Remote host closed the connection]
asymptotically has joined #lisp
ebzzry has joined #lisp
flamebeard has joined #lisp
zfree has joined #lisp
varjag has joined #lisp
dented42 has quit [Ping timeout: 246 seconds]
knicklux has quit [Quit: Leaving]
SaganMan has quit [Ping timeout: 252 seconds]
flamebeard has quit [Remote host closed the connection]
roshanavand has quit [Quit: leaving]
dented42 has joined #lisp
pjb has joined #lisp
siraben has joined #lisp
jack_rabbit has quit [Ping timeout: 260 seconds]
mingus has quit [Remote host closed the connection]
orivej has joined #lisp
mingus has joined #lisp
frgo has quit [Remote host closed the connection]
dented42 has quit [Ping timeout: 252 seconds]
frgo has joined #lisp
pjb has quit [Ping timeout: 264 seconds]
frgo has quit [Ping timeout: 252 seconds]
igemnace has quit [Quit: WeeChat 2.2]
moei has quit [Ping timeout: 252 seconds]
lemoinem has quit [Ping timeout: 244 seconds]
frgo has joined #lisp
orivej has quit [Ping timeout: 268 seconds]
SaganMan has joined #lisp
orivej has joined #lisp
dented42 has joined #lisp
charh has quit [Remote host closed the connection]
esrse has quit [Ping timeout: 264 seconds]
flamebeard has joined #lisp
flamebeard has quit [Remote host closed the connection]
Harag1 has joined #lisp
Harag has quit [Ping timeout: 245 seconds]
Harag1 is now known as Harag
dented42 has quit [Ping timeout: 252 seconds]
galdor has quit [Quit: WeeChat 2.2]
galdor has joined #lisp
Essadon has joined #lisp
roshanavand has joined #lisp
shifty has quit [Ping timeout: 246 seconds]
sunset_NOVA has joined #lisp
m00natic has joined #lisp
cl-arthur has quit [Quit: Lost terminal]
pjb has joined #lisp
kamog has quit [Quit: Leaving.]
flamebeard has joined #lisp
sunset_NOVA has quit [Ping timeout: 244 seconds]
eschatologist has quit [Ping timeout: 264 seconds]
moei has joined #lisp
dented42 has joined #lisp
sunset_NOVA has joined #lisp
asymptotically2 has joined #lisp
pjb has quit [Ping timeout: 252 seconds]
asymptotically has quit [Ping timeout: 256 seconds]
moei has quit [Quit: Leaving...]
LiamH has joined #lisp
flamebeard has quit [Remote host closed the connection]
steiner has quit [Remote host closed the connection]
warweasle has joined #lisp
<shka_>
heisig: hello
<shka_>
heisig: where should i start reading petalisp source code to understand how code generation works?
<shka_>
I am trying to figure out your technics
X-Scale has joined #lisp
<heisig>
shka_: Thank you for your interest! The recommended reading order is just the order that ASDF uses. Another way is to use (break) and M-. to dive into the code.
aindilis has quit [Ping timeout: 250 seconds]
<shka_>
ok, sounds fine
<shka_>
thanks!
asymptotically2 is now known as asymptotically
dented42 has quit [Ping timeout: 246 seconds]
Bike has joined #lisp
SumoSud0 has quit [Remote host closed the connection]
SumoSud0 has joined #lisp
lemoinem has joined #lisp
steiner has joined #lisp
ggole has joined #lisp
frgo has quit [Remote host closed the connection]
heisig has quit [Quit: Leaving]
moei has joined #lisp
nixfreak has joined #lisp
dented42 has joined #lisp
stacksmith has joined #lisp
stacksmith has left #lisp [#lisp]
stacksmith has joined #lisp
frgo has joined #lisp
shka_ has quit [Quit: WeeChat 1.9.1]
lieven has quit [Ping timeout: 250 seconds]
galdor has quit [Ping timeout: 250 seconds]
FreeBirdLjj has joined #lisp
myrmidon has quit [Quit: Leaving]
lieven has joined #lisp
dented42 has quit [Ping timeout: 245 seconds]
Harag has quit [Ping timeout: 264 seconds]
pjb has joined #lisp
<pfdietz>
aeth: oni-on-ion: Waters' old COVER package will be going into quicklisp soonish. I tidied it up a bit and wrote an asd file. https://github.com/pfdietz/cover
eMBee has joined #lisp
rippa has joined #lisp
vaporatorius has joined #lisp
pjb has quit [Ping timeout: 252 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
astronavt has quit [Remote host closed the connection]
quazimodo has quit [Ping timeout: 252 seconds]
astronavt has joined #lisp
FreeBirdLjj has joined #lisp
quazimodo has joined #lisp
robotoad has joined #lisp
nsrahmad has joined #lisp
FreeBirdLjj has quit [Ping timeout: 252 seconds]
chipolux has joined #lisp
quazimodo has quit [Ping timeout: 245 seconds]
astronavt has quit [Ping timeout: 252 seconds]
quazimodo has joined #lisp
<jasom>
pfdietz: interesting; I wonder if that could be used to write something like AFL (a tool for generating inputs to take each possible branch).
<pfdietz>
This is part of my plan!
<jasom>
pfdietz: thanks! it's people like you that allow me to sit on the couch eating bon-bons all day :)
didi has joined #lisp
<pfdietz>
The plan is to generalize the "point" data structure there to allow subclassing and custom behaviors. For that use case, it needs checkpointing and rollback, so tests can be tracked if they increase coverage, and then the test minimized to the smallest input(s) that still increase coverage.
<pfdietz>
Current issue I have with COVER is that it doesn't play well with certain macro packages, particularly ITERATE.
<didi>
Can I use function EQ to compare two instances of a class?
<pfdietz>
Yes
<didi>
Cool. Thank you.
<pfdietz>
It will determine if they are the same object, not do a slot-by-slot comparison.
<didi>
That's exactly what I want.
<pfdietz>
The only place you need to beware of EQ is with numbers and characters. Use EQL for those. Or, in general, use EQL instead of EQ unless you want to microoptimize.
<didi>
Thank you.
JohnMS_WORK has quit [Read error: Connection reset by peer]
rumbler31 has joined #lisp
cage_ has joined #lisp
rumbler31 has quit [Remote host closed the connection]
sjl has joined #lisp
zfree has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
ggole has quit [Quit: ggole]
FreeBirdLjj has quit [Ping timeout: 245 seconds]
shka_ has joined #lisp
slightlycyborg has joined #lisp
dented42 has joined #lisp
<slightlycyborg>
Hi. I am interested in the concept of dyanmically loaded lisp packages. I want to run a top level form that loads some code, uses that code, and then unloads that code so it doesn't consume ram. What is the best way to do this?
<Bike>
the unloading part is hard.
<Bike>
loading code can have arbitrary side effects, so there's no nonspecific way to undo a load.
<Bike>
you can undefine functions and stuff though.
<slightlycyborg>
Ok. I am just imagining having more code on my machines HD than I have space for in RAM. If I want to use all that code at different points in time while still keeping the same lisp process up and running, then I will have to load and unload.
<Shinmera>
why imagine. Worry about it once you confirm that this is actually a problem.
<beach>
slightlycyborg: Your virtual-memory system will likely take care of it.
asarch has joined #lisp
<slightlycyborg>
Ok. Those are both good points.
Harag has joined #lisp
<shka_>
good evening
<beach>
Hello shka_.
jcowan has joined #lisp
hhdave has quit [Ping timeout: 245 seconds]
pjb has joined #lisp
<LdBeth>
good morning
<jcowan>
Good afternoon!
<Bike>
good time
varjagg has joined #lisp
stereosphere has joined #lisp
dented42 has quit [Ping timeout: 245 seconds]
FreeBirdLjj has joined #lisp
sunset_NOVA has quit [Quit: Leaving]
<shka_>
Bike: :D
didi has left #lisp ["O bella ciao bella ciao bella ciao, ciao, ciao."]
FreeBirdLjj has quit [Ping timeout: 246 seconds]
<jasom>
beach: vm will take care of it, but then you need to swap to do a full heap GC :(
<shka_>
documentation for cl-progress-bar is not in the quickref
<shka_>
any idea why is that?
<jasom>
slightlycyborg: it's unlikely to be a real issue if you're only running a single lisp process because code has gotten larger much slower than RAM has gotten cheaper. If you do run into a problem you can enforce that a loadable "unit" of code use a single package and then delete the package, which may render most of the functions and global variables loaded unreachable
<Shinmera>
also typically the size of data far dwarfs the size of code
<slightlycyborg>
jasom. I was contemplating a lisp machine on top of linux where there is a single lisp process and all subsequent processes are sbcl threads.
<slightlycyborg>
Ok so if fn's are unreachable then they get gc'd I guess. I didn't know how fns work. I assumed data would get gc'd since that complies with my model of a java gc
<Shinmera>
The standard does not mandate GC of any kind. In practice every implementation so far has GC of some kind, though not all GC functions.
<Shinmera>
(Clasp for instance does not due to LLVM complications)
FreeBirdLjj has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
m00natic has quit [Remote host closed the connection]
frgo has quit [Ping timeout: 245 seconds]
quazimodo has quit [Ping timeout: 268 seconds]
quazimodo has joined #lisp
rixard has joined #lisp
sauvin has quit [Remote host closed the connection]
<pfdietz>
Code not being GCed is a problem for things I do, but there are workarounds.
jack_rabbit has joined #lisp
Kaisyu has quit [Quit: Connection closed for inactivity]
rixard has quit [Quit: rixard]
nsrahmad has quit [Remote host closed the connection]
frgo has joined #lisp
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
cage_ has quit [Remote host closed the connection]
Selwyn has joined #lisp
SenasOzys has joined #lisp
dented42 has joined #lisp
<jasom>
slightlycyborg: of course if you have any references to the names of the functions lying around (most obvious would be actual calls to the function, but any variables with the same name would do it as well), then the functions likely wont be GC'd, and it is very implementation dependent.
<beach>
jasom: Depends on the kind of GC you have. :)
<jasom>
but sbcl will GC code inasmuch as it GCs anything
orivej has quit [Ping timeout: 252 seconds]
<jasom>
beach: I suppose a reference counted GC wouldn't need to walk the tree, but most other GCs tend to at least occasionally walk the entire heap (even if just incrementally).
steiner has quit [Ping timeout: 245 seconds]
<beach>
jasom: True. I was (jokingly) referring to the fact that most GCs will in fact traverse the entire heap because they copy it.
<jasom>
beach: most lisp GCs will; mostly-copying GCs tend to be less popular in other runtimes, in favor of either compacting or even non-moving GCs.
<White_Flame>
and if course, if you go oldschool like picolisp, then every object on the heap is 2 words and fragmentation isn't an issue at all
<jasom>
IIRC you have a GC design that only moves when promoting from the nursery.
<beach>
jasom: I was also (jokingly) making an allusion to the planned SICL GC which I think would have less of a paging problem since the global collector does not move objects around.
<jasom>
I haven't measured it, but I imagine that non-moving GCs would be more VM friendly since they wouldn't dirty pages with only old objects.
<beach>
Yeah.
Copenhagen_Bram has quit [Read error: Connection reset by peer]
<jasom>
does sbcl at least not move very large objects? When I was playing around with a toy incremental copying GC, that was a fairly large win.
<beach>
White_Flame: Interestingly, I made an early decision with SICL that every heap allocated object is either a 2-word CONS cell, or it has a 2-word "header" which has one pointer to the class and another pointer to the "rack" (which contains all data), so I can have the advantages of a mark-and-sweep collector for the CONS cells and headers, and I use a malloc/free style allocator for the racks (Doug Lea's technique).
<beach>
Therefore object allocated in the global heap do not move.
<White_Flame>
would things like boxed double-floats need to have a header/rack as well?
<beach>
Yes.
<jasom>
is the rack for 2-word objects in malloc style heap too?
<jasom>
that was unclear from the paper.
<beach>
Good question.
<jasom>
though I only read it once, and 3 is a minimum for me actually understanding technical papers
<jcowan>
Java has pluggable GC, and has just introduced a GC that does not collect garbage. It can be used to induce memory pressure.
<beach>
Yes, I don't think a 2-word rack would exist.
Josh_2 has joined #lisp
<jcowan>
beach: Do you have any immediate representations in SICL?
<beach>
Sure, fixnums, characters, single floats.
<jasom>
CONS and fixnum at least I remember.
<jasom>
oh, are conses not immediates?
<beach>
I don't call that immediate, no.
<beach>
But they have no rack.
<beach>
Only a 2-word cell.
<jasom>
hmm if you ran in x32 mode they could be immediates (totally the opposite direction you are going, but gives me a fairly useless idea).
<beach>
jasom: A rack contains at the very least a stamp and a list of slots. So an object with 1 word information would have 3 words in it.
<jasom>
beach: that makes sense
* jcowan
nods
<beach>
jasom: I don't think I am going to try 32-bit stuff.
<jasom>
beach: that would make some of your persistance ideas non-workable
<jasom>
32-bit address space that is
<beach>
Yeah.
<jcowan>
So you distinguish between pairs and non-pairs using a low tag?
<beach>
One reason I am willing to drop it.
<beach>
Yes, CONS cells and "general instances" have different tags.
<jcowan>
In the pointer, or in the object?
<beach>
In the pointer.
astronavt has joined #lisp
<jcowan>
Gotcha, thanks
<beach>
Pleasure.
astronavt has quit [Max SendQ exceeded]
astronavt has joined #lisp
<beach>
I am off to spend time with my (admittedly small) family. I'll be back tomorrow morning (UTC+2).
<jcowan>
Bottom Scheme, a back-burner project of mine, uses all 8 pointer tags to encode fixnums, other immediates, and pointers to compnums, vectors, pairs, bytevectors, strings, and all other (procedure, symbol, or struct). Double floats are punboxed.
vaporatorius has quit [Quit: Leaving]
Kundry_Wag has joined #lisp
dented42 has quit [Ping timeout: 268 seconds]
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
asymptotically has quit [Quit: Leaving]
nirved has quit [Quit: Leaving]
Kundry_Wag has quit [Remote host closed the connection]
drewc has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in]
gilez has joined #lisp
Kundry_Wag has joined #lisp
makomo has joined #lisp
Bike_ has joined #lisp
Bike has quit [Disconnected by services]
Bike_ is now known as Bike
m3tti has joined #lisp
ealfonso has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
vlatkoB has quit [Remote host closed the connection]
m3tti has quit [Remote host closed the connection]
m3tti has joined #lisp
drewc has joined #lisp
roshanavand has quit [Ping timeout: 252 seconds]
roshanavand has joined #lisp
quazimodo has quit [Ping timeout: 252 seconds]
mkolenda has joined #lisp
quazimodo has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
dented42 has joined #lisp
roshanavand has quit [Ping timeout: 245 seconds]
roshanavand has joined #lisp
eschatologist has joined #lisp
roshanavand has quit [Ping timeout: 252 seconds]
shka_ has quit [Ping timeout: 245 seconds]
roshanavand has joined #lisp
roshanavand has quit [Remote host closed the connection]
roshanavand has joined #lisp
<jcowan>
I've been thinking about these conversions from bitvectors to integers. It seems in order to make them work, #*111000 has to be treated as the integer 7; that is, bitvector bits are numbered big-endianly (as in array displacements), integer bits are numbered little-endianly (as in byte specs). Does that seem wrong to anyone?
roshanavand has quit [Ping timeout: 245 seconds]
roshanavand has joined #lisp
<dlowe>
binary notation of a number is bigend
<dlowe>
endian is just the encoding of a number, like the text encoding of a character
anamorphic has joined #lisp
m3tti has quit [Remote host closed the connection]
m3tti has joined #lisp
DGASAU has quit [Read error: Connection reset by peer]
DGASAU has joined #lisp
angavrilov has quit [Remote host closed the connection]
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<jcowan>
Yes. But the LOGBITP and BYTE functions treat integers in a little-endian way, even if the internal representation is big-endian. That is, bit 0 is 2^0, bit 1 is 2^1, etc.
<Bike>
i guess i would just think of it as bit vectors being written left to right while numbers are written write to left
<jcowan>
Just so. (In actual Arabic writing (but not Persian, which uses the Arabic script), people actually do write numbers from right to left. In Persian and Hebrew, you jump forward (rightward) for the appropriate number of digits and then write them left to right, and then jump forward again.
<jcowan>
)
Nizumzen has joined #lisp
<Bike>
i thought in arabic you wrote everything from right to left
<ecraven>
jcowan: you mean arabic writes literal "61" for 16? that is incorrect, I think, 1 is left and 6 is right, in arabic writing
Roy_Fokker has joined #lisp
shifty has joined #lisp
<aeth>
ecraven: I think so, too. There are also two Arabic numerals. The first are the ones in the west (west of Egypt?) that Europe eventually got. The second are distinct
<ecraven>
I actually can't think of any number system that writes least-significant-digit-leftmost (unless you count things like ancient greek boustrophedon, which is not a positional numeral system anyway)
<aeth>
e.g. ١ instead of 1
<anamorphic>
Is there any kind of guide on what's good practice when designing an API for a CFFI'd library?
<ecraven>
aeth: ١٦, I think, is 16
<anamorphic>
e.g. should I make it really lispy, or make it very C-ish so that it is more easilly documented by the library's own C documentation
<ecraven>
anamorphic: I usually split it, one thin layer above C, and then a better abstraction on top of it
<ecraven>
so if anyone wants to, they can import the lower-level API, but for most use cases the higher-level API is better
<sjl>
that's the approach cl-charms takes. there's a charms/low-level package with the CFFI wrappers and charms/high-level with the Lispy abstractions. I've used that approach for some other things and it works pretty well.
<Shinmera>
I third this.
kushal has quit [Remote host closed the connection]
<no-defun-allowed>
Morning
<anamorphic>
would it matter if the low-level thing is defined at a asdf system level or is it enought as a system with low and high level packages?
<sjl>
You can even generate the low-level package with something like SWIG if that appeals to you (I know some people don't like it though).
<Shinmera>
Generally I make a *-cffi package for direct bindings, and a * package for a "no headaches" wrapper
kushal has joined #lisp
drl has quit [Quit: Ex-Chat]
<sjl>
I suppose you could make them separate systems if you really wanted to. I generally don't bother and just make them two packages in one system.
<Shinmera>
yeah, typically neither level is large enough to warrant a split
<anamorphic>
ok cool. I went the way of creating a foo-cffi pacakge and a foo pacakge with some niceties
scymtym has quit [Ping timeout: 276 seconds]
<aeth>
cl-opengl splits it, it has a %gl and a gl package
<Shinmera>
yes, I meant a split of the systems
<Shinmera>
naturally splitting the packages is a good idea
stereosphere has quit [Ping timeout: 252 seconds]
<anamorphic>
Hmm yeah I guess that saves extra code from being loaded
<Shinmera>
Ok to be clear: I don't think splitting systems is a good idea. I do think splitting packages is a good idea.
<anamorphic>
Oh OK
jmercouris has joined #lisp
* |3b|
usually intends the low-level to be used in addition to the high-level for specific bits that need higher performance or something, so both would generally be used together
<|3b|>
i probably wouldn't reject a pull request from someone that wanted to be able to load the low-level by itself, but wouldn't set it up that way to start with
m3tti has quit [Remote host closed the connection]
m3tti has joined #lisp
<|3b|>
like in the opengl case, i could see wanting to write a separate high-level layer for gles, which would usually run on resource constrained systems so skipping normal GL wrappers would be good
quazimodo has quit [Ping timeout: 252 seconds]
<|3b|>
(that case would probably skip some of the low-level code as well for that matter)
<anamorphic>
are you referring to cl-opengl specifically in this case?
<|3b|>
in general for the part about pull requests and intent, cl-opengl specifically for gles example
quazimodo has joined #lisp
* |3b|
probably wouldn't accept a pull request for gles specific systems of my non-gl libraries :)
m3tti has quit [Remote host closed the connection]
dyelar has quit [Remote host closed the connection]
dyelar has joined #lisp
<pjb>
jcowan: (let ((i (random 1024)) (bv (make-array 10 :element-type 'bit))) (loop for bit below (integer-length i) do (setf (aref bv bit) (if (logbitp bit i) 1 0))) (values (format nil "~B" i) bv)) #| --> "1110100101" ; #*1010010111 |#
<pjb>
jcowan: it's just a matter of convention in the binary representation of integers, and the lisp printed representation of bit-vectors.
<pjb>
jcowan: if the bit weren't in the same order, we'd have to write (setf (aref bv (- (integer-length i) bit)) …)
dented42 has quit [Ping timeout: 246 seconds]
charh has joined #lisp
scymtym has joined #lisp
asymptotically has joined #lisp
<jcowan>
ecraven: no, I mean that when writing "16" in Arabic text, the 6 is written before the 1, whereas in Persian/Hebrew/Latin writing, the 1 is written before the 6.
<jmercouris>
yep, I will use the uiop version though, so thanks for the tip
<|3b|>
if you are passing to OS, native is better. CL one might escape things oddly to maintain CL semantics
<jmercouris>
yeah, I figured
<jmercouris>
always use uiop when possible
<|3b|>
well, if you are staying in lisp, not escaping might confuse things too :)
Selwyn has quit [Read error: Connection reset by peer]
<jmercouris>
I'm running chown, hence why I need that string
<|3b|>
though CL pathname/namestring semantics aren't always non-confusing to start with
Harag has quit [Ping timeout: 252 seconds]
<jmercouris>
understatement of the year :D
<jmercouris>
I am now almost two years into CL, and I'm still not 100% on them
<jmercouris>
then again, there is so much to learn, I feel like I could spend at least a decade before really mastering CL
<jmercouris>
maybe I am just slow, not sure
anamorphic has quit [Quit: anamorphic]
jmercouris has quit [Remote host closed the connection]
<pjb>
A decade if you put in a dedicated effort learning it. I've been doing CL for 22 years, and I'm still very light on parts, such as the MOP.
anamorphic has joined #lisp
pjb has quit [Ping timeout: 252 seconds]
anamorphic has quit [Quit: anamorphic]
anewuser has joined #lisp
<Petit_Dejeuner>
Easy to learn, hard to master.
<Petit_Dejeuner>
...how many years until you become such expert who regularly uses eval and read.
<Petit_Dejeuner>
s/such/an/
Essadon has quit [Quit: Qutting]
r1b has joined #lisp
orivej has quit [Ping timeout: 244 seconds]
<jasom>
Petit_Dejeuner: directly calling eval is very rare outside of implementing a REPL.
quazimodo has quit [Ping timeout: 268 seconds]
aindilis has joined #lisp
quazimodo has joined #lisp
<Petit_Dejeuner>
So I've been told.
makomo has quit [Ping timeout: 244 seconds]
<White_Flame>
hot code loading uses it, too
<Petit_Dejeuner>
Is that what SLIME is doing underneath?
pjb has joined #lisp
<Petit_Dejeuner>
Since we're on the topic, is there anyway to control what dynamic environment #'eval sees to limit what functions it can call?
<Petit_Dejeuner>
Stick it in a package with limited bindings?
<White_Flame>
it can always use package::private in order to hit whatever dynamic variable it wants
shifty has quit [Ping timeout: 245 seconds]
<White_Flame>
after read and before eval, maybe you could sweep through all the symbols to try to ensure they're always white-listed. Then you also have to eliminate interning, and it might be a difficult cat-and-mouse game
Kaisyu has joined #lisp
RagnarDanneskjol has joined #lisp
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
roshanavand has quit [Ping timeout: 252 seconds]
<jasom>
Petit_Dejeuner: there is no way to control the environment of eval in general; if you want to have a sandbox, it's probably better to write a CL-like DSL
<Petit_Dejeuner>
This ALMOST seems right, but I need to make sure stuff like #. isn't creating leaks. https://pastebin.com/raw/gQYwVRkF
<Petit_Dejeuner>
Probably need to make a safe reader as well somehow.
<jasom>
Petit_Dejeuner: not at all; consider the input of "(uiop:run-program ...)"
Jesin has quit [Quit: Leaving]
SenasOzys has quit [Remote host closed the connection]
SenasOzys has joined #lisp
<Petit_Dejeuner>
Huh, yeah I guess it can still get at other packages.
<Petit_Dejeuner>
Maybe I can change the reader so qualified (or whatever they're called) symbols don't work?
dented42 has joined #lisp
<White_Flame>
*READ-EVAL* can turn off the #. read-time feature
<jasom>
Petit_Dejeuner: if you change the reader so it can't get at other packages and you don't import any symbols that could allow them to intern strings, then you might be almost right.