<emaczen>
jasom: can you get the type? or just the offset
<jasom>
emaczen: offset I think. Does the groveller do types as well? I don't recall
<jasom>
cl-autowrap actually parses and extracts types and things but I didn't think the groveller did.
<jasom>
emaczen: C11 lets you do it, but most programs don't target that version yet so may not work in C11 mode.
<jasom>
though system headers should work, so at least for system calls you should be fine.
<emaczen>
Do cffi:defcstructs need the types of the members?
robotoad has quit [Quit: robotoad]
<emaczen>
wait
mange has joined #lisp
<jasom>
emaczen: yes, but you specify which slots you care about for the groveller
<emaczen>
jasom: I guess that is fine, the offsets are probably the most confusing
<jasom>
emaczen: especially since many APIs define what fields there are and their types, but not their order.
<emaczen>
I had to dig through a bunch of macroexpanded types...
pjb has quit [Ping timeout: 252 seconds]
<emaczen>
nvm I guess I could have relied on the API then like you are saying
Guest13389 has joined #lisp
r1b has joined #lisp
<emaczen>
what about when types are different across machines?
<oni-on-ion>
ub
<Bike>
i thought the groveler used sizeof and offsetof to get type information to lisp
anewuser has joined #lisp
razzy has quit [Ping timeout: 250 seconds]
sjl has quit [Ping timeout: 252 seconds]
pjb has joined #lisp
r1b has quit [Ping timeout: 268 seconds]
r1b has joined #lisp
elfmacs has joined #lisp
<emaczen>
Bike: I don't see how sizeof and offsetof could distinguish between types with the same sizes
<emaczen>
I dont think C really cares either?
<emaczen>
well signed vs unsigned should be interpreted differently
<|3b|>
mostly just care about size
<|3b|>
at least i hope people wouldn't make APIs where something is a float sometimes or an int other times
<emaczen>
|3b|: with a pointer?
<emaczen>
How do you specify "sometimes" in C
<|3b|>
on different platforms i mean
<emaczen>
|3b| digging through sockaddr between my mac and raspberrypi
<|3b|>
i'd expect most actual changes in struct definition per platform to be things like using different sized ints, assuming just taking native int size wasn't good enough
<emaczen>
the sa-family was uint8 on my mac and a short on my raspberrypi
<|3b|>
ah, system APIs are some of the messy cases for FFI
<|3b|>
especially unix inherited APIs
pjb has quit [Ping timeout: 252 seconds]
actuallybatman has joined #lisp
<|3b|>
but still both int types there, so just need to detect size
* |3b|
isn't sure groveller will handle that for you though
<Bike>
for the groveler you can specify the types in a struct. dunno if that's required, it's a &key
<russellw>
acons, perfect, just what I wanted. thanks!
<no-defun-allowed>
(push (cons key value) alist) and (setf alist (acons key value alist)) are common
<beach>
LIST* is for plists rather than alists.
dale has quit [Quit: dale]
wanz has joined #lisp
ryan_vw has joined #lisp
orivej has quit [Ping timeout: 252 seconds]
gector has quit [Read error: Connection reset by peer]
gector has joined #lisp
pjb has joined #lisp
pjb has quit [Ping timeout: 252 seconds]
elfmacs has quit [Quit: WeeChat 2.2]
sauvin has joined #lisp
ku has joined #lisp
robotoad_ has joined #lisp
borodust has quit [Ping timeout: 244 seconds]
ravndal has quit [Ping timeout: 244 seconds]
ebzzry has quit [Ping timeout: 244 seconds]
moei has quit [Ping timeout: 244 seconds]
msb has quit [Ping timeout: 244 seconds]
ryan_vw has quit [Ping timeout: 250 seconds]
robotoad has quit [Ping timeout: 244 seconds]
joast has quit [Ping timeout: 244 seconds]
Oddity has quit [Ping timeout: 244 seconds]
pacon has quit [Ping timeout: 244 seconds]
pacon has joined #lisp
potatonomicon has quit [Ping timeout: 244 seconds]
ravndal has joined #lisp
msb has joined #lisp
sigjuice has quit [Ping timeout: 252 seconds]
Bike has quit [Quit: Lost terminal]
sigjuice has joined #lisp
Oddity has joined #lisp
oni-on-ion has quit [Quit: WeeChat 1.9.1]
pjb has joined #lisp
oni-on-ion has joined #lisp
ecraven has quit [Ping timeout: 244 seconds]
drewc has quit [Ping timeout: 244 seconds]
ecraven has joined #lisp
SilverSteeples has quit [Ping timeout: 244 seconds]
Ekho has quit [Ping timeout: 244 seconds]
charh has quit [Ping timeout: 244 seconds]
theBlackDragon has quit [Ping timeout: 244 seconds]
plathrop has quit [Ping timeout: 244 seconds]
charh has joined #lisp
plathrop has joined #lisp
Ekho has joined #lisp
ku is now known as k-hos
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
anamorphic has joined #lisp
<anamorphic>
Is it possible to pass multiple values for a (setf foo) form? Something like this (defun (setf foo) (new-value) (multiple-value-bind (x y) new-value (list x y)))?
ggole has joined #lisp
<emaczen>
psetf?
<anamorphic>
When I do (setf (foo) (values 1 2)), I just get the result '(1 nil)
<emaczen>
anamorphic: I wrote a macro (defmacro msetf ((&rest vars) form) ....)
<emaczen>
you can ue it like (msetf (a b c) 1 2 3)
<|3b|>
(setf (foo) (values ...)) is fine, just can't be a setf function
emaczen has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
emaczen has joined #lisp
astronavt has quit [Ping timeout: 252 seconds]
pjb has quit [Ping timeout: 252 seconds]
dented42 has joined #lisp
<|3b|>
(defsetf foo () (a b c) `(progn (print (list ,a ,b ,c)) (values ,a ,b ,c)))
<|3b|>
prints (1 2 3), and returns values 1,2,3 as required by setf spec
<aeth>
(setf (foo) (values 1 2 3)) is very useful. it composes well with (setf (foo) (foo)) where (foo) is a function that returns multiple values
<aeth>
You can also do (setf (values x y z) (values 1 2 3)) which makes me wonder why you can't do that in let, which would make multiple-value-bind unnecessary
astronavt_ has quit [Quit: Leaving]
<|3b|>
evolution instead of design by looking into the future :)
<|3b|>
you could add (function x) to that and get rid of flet, add (special x) and get rid of special declarations too :)
vlatkoB has joined #lisp
mange has quit [Ping timeout: 268 seconds]
<aeth>
Too bad the community is far too conservative to accept that.
<aeth>
at least in the core language
<aeth>
The prefix is an interesting idea
<aeth>
(type foo fixnum) could get rid of type declarations, too.
<anamorphic>
Yeah I'm aiming for that (setf (foo) (foo))
<ggole>
Destructuring in all binding forms is a pretty well-known idea
<ggole>
Landin suggested it in the late 60s
<aeth>
Well, destructuring, too! (destructuring (foo bar baz &body body))
<anamorphic>
I did some reading... apparently there's a setf* in CLIM that does this for output record x/y position
orivej has joined #lisp
<Petit_Dejeuner>
setf* ?
<Petit_Dejeuner>
as in |setf*| ?
<aeth>
Actually, I might get rid of define-destructuring-function, actually. It's just like define-function except the first argument is destructured, so (define-destructuring-function foo ((foobar baz) quux) ...) instead of (define-function foo (list quux) (destructuring-bind (foobar baz) list) ...)
<aeth>
But the whole prefix thing is an interesting idea, and I could just say (destructuring (foobar baz)) or something
<aeth>
anamorphic: Oh, and when you mix the multiple-value accessors like (setf (foo quux) (bar baz)) with symbol-macrolet/with-accessors you get (setf foo bar)
<aeth>
So a multiple-value defsetf composes very well with a multiple-return-value function
<fiddlerwoaroof>
The nice thing about a lisp is that the community generally doesn't have to accept your preferred syntax
<anamorphic>
Hmm not sure what you mean about symbol-macrolet. Will check it out tho
dmiles has quit [Ping timeout: 268 seconds]
<aeth>
anamorphic: symbol-macrolet is how with-accessors is (probably) implemented and is necessary if you want to use fancier accessors (such as aref)
<aeth>
it's there at the bottom as the definition of with-accessors
<beach>
One major advantage of Common Lisp is that a serious project can choose the language for a long-term project, knowing that the standard will remain as it is, that the language won't evolve according to the whim of some benevolent dictator who is ignorant both when it comes to programming language design and compiler technology.
<beach>
... and that there are several implementations, free or commercial according to the needs of the project, that implement that standard.
<fiddlerwoaroof>
Yeah, I really wish more "modern" languages were implemented as compilers to CL
<fiddlerwoaroof>
ACL2, Shen, etc. show that this is possible and CL is a much nicer target than C or lower-level stuff, if you don't need performance
wglb has joined #lisp
Harag has joined #lisp
<fiddlerwoaroof>
(that is, if you're not in a domain where you need real-time guarantees, etc.
<Jachy>
That still wouldn't help much though when the younger languages update and make breaking or incompatible changes...
<beach>
fiddlerwoaroof: There are very few modern "languages", if by "language" you mean an independently published specification of the syntax and semantics of valid phrases, and the consequences of submitting invalid phrases to the compiler.
<fiddlerwoaroof>
Yeah, I'm using "modern" in a purely temporal sense
frodef has joined #lisp
<beach>
fiddlerwoaroof: Me too. But I have restrictions on what I call a "language".
<fiddlerwoaroof>
ah
<jackdaniel>
Jachy: if your target language of compilation is CL nothing prevents you from putting different language versions in separate packages of the same image
<jackdaniel>
in that case you'd be able to have (say) python2 and python3 funcitons interoperate
<beach>
There are, however, plenty of "programming systems" without any attempt at a detailed specification, and certainly no specification of what will remain unchanged in the future and what might change at arbitrary times in arbitrary ways.
<Jachy>
(Just ran into that last weekend, some code in hip new lang I wrote from 3 years ago didn't run. The language designers put random() into a module.)
<Jachy>
jackdaniel: by the same logic I can always run an old VM with the old language version, CL as a target not needed.
orivej has quit [Ping timeout: 252 seconds]
<fiddlerwoaroof>
If CL is a target, your language compiles to conforming common lisp
<jackdaniel>
Jachy: that's not the same logic, because you don't have two runtimes in the same image
<fiddlerwoaroof>
So, once I've compiled it, it will run as long as I have a CL lying around
<aeth>
CL isn't a suitable compilation target for everything that you'd want to have in a language.
<fiddlerwoaroof>
It is for languages in the python/ruby/clojure/etc. category
<jackdaniel>
I don't think CL would make a good compilation target, just commenting on Jachy remark
dmiles has joined #lisp
<beach>
It would probably be a better idea to generate Cleavir ASTs directly from the source language.
<beach>
A few new ASTs could be introduced where needed, but the bulk of the translation chain would remain the same.
<jackdaniel>
aren't Cleavir ASTs a subject of the same "beneloved dictator" syndrome you've mentioned before?
<beach>
That way, you would automatically get source tracking in the source language, and you would not have to debug your code in terms of Common Lisp target code.
<jackdaniel>
(not saying it is a good thing, that enables projects to move forward)
<jackdaniel>
not saying it is a bad thing*
<beach>
jackdaniel: It is not a language, and I don't pretend it is. It is a compiler framework.
ealfonso has quit [Disconnected by services]
ealfonso has joined #lisp
<jackdaniel>
uhm, then why is it better to compile to AST of a single compiler which is designed for another language than to compile to CL which has numerous implementations?
<beach>
You are right. Forget what I said. I was wrong. It would be worse.
<aeth>
You could compile to CL by having a series of extensions that the major implementations accepted. beach is right that debugging would be painful, though.
<aeth>
Afaik there probably aren't *that* many things that couldn't be added as extensions, it's just that it's a niche no one has really catered to.
<jcowan>
aeth is doing a Scheme->CL compiler targeting R7RS and SBCL
<jackdaniel>
I can't be right because I didn't make any statement, just asked a question out of curiosity
dmiles has quit [Ping timeout: 252 seconds]
<fiddlerwoaroof>
Racket has done a lot of work to figure out tracking errors in macro expansion to the source the programmer wrote
<jackdaniel>
compiling to *some* compiler IR is a common thing (LLVM is a common target for instance)
<flip214>
jackdaniel: you're right even if you don't intend to, or even try? well done! ;)
<jackdaniel>
I'm afraid it was not a praise, but I may be wrong on that ;-)
shrdlu68 has quit [Ping timeout: 245 seconds]
makomo has joined #lisp
<fiddlerwoaroof>
Maybe I'm wrong, but what I'm most interested in is higher-level interop
<fiddlerwoaroof>
I've been writing a lot of Clojure/Scala/Java for $work and not having to explicitly decode/encode values in ffi is the best part of the JVM
<aeth>
fiddlerwoaroof: notice that JVM languages with the best interop are written specifically for the JVM, though
<jackdaniel>
I think there is a vaporware entry on cliki named CLVM
<aeth>
fiddlerwoaroof: even Scheme-written-on-CL has some issues with CL interop
<fiddlerwoaroof>
aeth: there's no reason why clojure couldn't be a library + readtable for ABCL
<aeth>
symbol case sensitivity and a separate nil from false tend to be noticable interoperability issues with other languages and CL
<fiddlerwoaroof>
maybe, the readtable has control over the case quite nicely
<aeth>
CL macros would be pretty hard or impossible to interface with from a CLFFI, especially ones like symbol-macrolet
sunset_NOVA has joined #lisp
<fiddlerwoaroof>
I've been doing a lot of work embedding Apple's Objective-C runtime in CL and a couple well-chosen reader macros make dealing with a case-sensitive language pretty painless
<fiddlerwoaroof>
_using_ macros from other languages would be tricky, but this is true of most of the "advanced" features of JVM languages.
Balooga_ has joined #lisp
<fiddlerwoaroof>
My general rule is to do as much as possible in the more expressive language
nowhereman_ has joined #lisp
<aeth>
I've been thinking about Scheme<->CL and I think the best way to handle CL things defined in Scheme is to assume CL is being written case-insensitively with automatic upcasing and downcase it. So if you define a Scheme CONS from CL, turn it into |cons| because it was probably written as cons and then upcased into CONS.
<aeth>
oh, so basically just implement jcowan's SRFIs
<aeth>
oh, no there are other things
<Jachy>
fiddlerwoaroof: If it's so simple for objectitve-c I'm curious why ABCL and then later JSS lib still use strings to identify java method names...
<zigpaw>
nicely looking and there are great suggestions in the hackernews thread, lots of links I have tried on the projects sub-page doesn't work unfortunately.
<shka_>
List the undying
smokeink has joined #lisp
xlt has joined #lisp
angavrilov has joined #lisp
jmercouris has joined #lisp
<jmercouris>
beach: he did say functions, not methods, or maybe I am also not understanding
orivej has joined #lisp
<beach>
Who? I don't remember the stuff you are referring to. Sorry!
<jmercouris>
Ok, I just checked the irclog link instead of the CCL one, seems the CCL one is not up- to date
<jmercouris>
There was some user who said something along the lines of using generic functions in scheme or something
<beach>
jmercouris: Because you may want to allow for the client to override the methods, or to provide auxiliary methods.
Kaisyu has quit [Quit: Connection closed for inactivity]
<beach>
jmercouris: In the example, the client is T. Typically, client code will define its own CLIENT object, and then override the default method.
<beach>
Or, if they are happy with the default action, they just don't define an auxiliary method.
<beach>
jmercouris: This is the very basis of programming with generic functions, allowing client code to adapt the way the module works.
<beach>
jmercouris: I guess your experience with object-oriented programming is from a language that does not use generic functions.
<jmercouris>
Well, from many languages, yes
<jmercouris>
I've only started touching the surface of CLOS
<beach>
But they are probably all based on the same principles, which are different from those of CLOS.
<jmercouris>
Yes, I understand some of the basic ideas of CLOS
<jmercouris>
I just did not consider another user overriding your method
<jmercouris>
mostly because I made too many assumptions about that snippet of code, I assumed it was internal
<beach>
In all the other languages you know, client code would make a subclass and override that way.
<jmercouris>
In this case they would just specialize on the appropriate set of classes, right?
<beach>
No, that was the very client interface of Eclector, allowing client code to customize its behavior.
<jmercouris>
so they just need to write some new defmethods with the appropriate lambda lists, and they can change the behavior
<beach>
Yes, typically their own CLIENT class, as I said.
<beach>
Yes.
<jmercouris>
Well, yes, but my question came before you clarified that :D
<jmercouris>
Anyways, I understand now, at least I believe I do
<beach>
Good.
<beach>
This is the very essence why CLOS is so great.
<jmercouris>
That's what I've gathered as well, and on some intellectual level, I understand some of the details, and how it works, but I haven't really internalized it, and my thinking is still shaped for a traditional model
<beach>
I see, yes.
<jmercouris>
many years of java training has done me in, but I'm slowly changing my ideas about programming, I understand the process of "de-doctrination" takes time
<beach>
For Java, much less so than for C++.
<jmercouris>
I know for sure other parts of my mind have changed with regards to how I think about programming as a result of lisp, but I just haven't gotten deep enough into CLOS yet, to get that same effect
<beach>
As I understand it, you are still young, so there is still plenty of time.
<jmercouris>
yes, luckily my mind hasn't fully crystalized :D
<Jach[m]>
jmercouris: I've only recently cracked open "Object Oriented Programming: The CLOS Perspective" and finding it helpful (plus the hardcover has nice cover art...)
<jmercouris>
Jach[m]: I'm in the middle of gentle introduction to common lisp, maybe when I'm through with that I can take a look, thanks for the suggestion
<no-defun-allowed>
AGITSC doesn't cover the CLOS much, if at all.
<beach>
I fear that's true.
<beach>
PCL does though, right?
<no-defun-allowed>
It's mostly symbols and conses.
<no-defun-allowed>
PCL does cover the CLOS pretty well.
<no-defun-allowed>
Off memory, there's at least one or two chapters dedicated to it
<no-defun-allowed>
Yep, 7 and 6 cover the CLOS's classes and generic functions.
eminhi has joined #lisp
<jmercouris>
I've already read PCL, but perhaps I read it too soon
rotty has quit [Ping timeout: 252 seconds]
<jmercouris>
that's why I start with a gentle introduction to common lisp, now that I've been doing lisp for a while, it sticks a little easier
<jmercouris>
when I give PCL a revisit, it may help
<jmercouris>
PCL is indeed practical and succinct, and as a consequence, not really memorable, at least for me
* beach
needs to remind his favorite coauthor about the many book projects we need to work on.
<heisig>
In my experience, the best way to learn and understand CLOS is to read other people's code. Some code that comes to mind is cl-dot, cl-graph, Eclector (and pretty much all of SICL), ASDF and maybe LIL.
<heisig>
But yes, the world would benefit a lot from a book on CLOS that is more practically oriented than AMOP.
<beach>
... and with better and more examples than "Object-Oriented Programming in Common Lisp" by Sonja Keene.
<heisig>
Absolutely.
orivej has quit [Ping timeout: 246 seconds]
<shka_>
keene's book is not bad imho
orivej has joined #lisp
kajo has joined #lisp
<shka_>
but i agree that better book about object oriented lisp would be nice
roscoe_tw has joined #lisp
dddddd has joined #lisp
cl-arthur has joined #lisp
<beach>
I didn't like the examples. One example was about software distribution for different platforms, which doesn't speak to someone who is that new with object-oriented programming. Another example was about threads, which are not in the standard. The entire thing gave me the impression that there are few examples where object-oriented programming is useful, since it must be hard to come up with more mundane examples.
rotty has joined #lisp
<no-defun-allowed>
One random idea I had was a LET* variant that is evaluated in parallel.
eminhi has quit [Remote host closed the connection]
<no-defun-allowed>
But yes, PCL's examples are a little dull.
kooga has quit [Ping timeout: 260 seconds]
<beach>
I meant Keene's book. I don't remember the examples from PCL.
<beach>
I was answering shka_.
<no-defun-allowed>
Oh. There was a pathname library in PCL, I was thinking of that.
<beach>
That sounds dull as well. :)
<shka_>
well, ok
<shka_>
this is fair criticism
<no-defun-allowed>
Indeed it is. The rest of the book is nice but the examples (except the spam filter, that's a masterpiece) were fairly underwhelming.
<shka_>
beach: i started a blog, i will describe my last discussion with phoe regarding message/answer representation next
<no-defun-allowed>
If it were, I imagine the plet* system would do some tree generation and figure out which bindings to evaluate next while they were being evaluated.
<no-defun-allowed>
That's very nice. That's the second half of the magic PLET* too.
<no-defun-allowed>
I'd just want to make the second "required" list automagically generated, which seems fairly trivial.
m00natic has joined #lisp
<no-defun-allowed>
It'd just be the variables in the value form that are in the previous bindings.
flamebeard has joined #lisp
<scymtym>
finding free variable occurrences in a form generally requires code walking. if the names of the variables in questions are known (like in this case) a hack like (catch 'occurs (sb-cltl2:macroexpand-all '(macrolet ((occurs () (throw 'occurs t))) (symbol-macrolet ((VAR (occurs))) FORM))) nil) can work
patrixl has joined #lisp
esrse has quit [Ping timeout: 250 seconds]
asymptotically has quit [Quit: Leaving]
lnostdal has quit [Ping timeout: 268 seconds]
lnostdal has joined #lisp
<no-defun-allowed>
Code walking is very simple though. I also have a set of variables I'm only interested in too.
shelvick has quit [Ping timeout: 252 seconds]
vlatkoB_ has joined #lisp
DGASAU has quit [Remote host closed the connection]
ogamita has joined #lisp
vlatkoB has quit [Ping timeout: 246 seconds]
<scymtym>
i'm not aware of very simple solutions for code walking. what do you have in mind?
<jcowan>
let* is inherently going to be sequential
<jcowan>
as for predicate-based generic functions, since I am a spec writer and not (with this hat on) an implementer, I don't have to provide an efficient implementation. Lots of things in JavaScript, e.g., weren't known to be efficiently implementable when they were first specified, but nowadays fast JavaScript is a thing.
<no-defun-allowed>
scymtym: I guess it isn't as simple with macros and the like. I'd assume that the plet* forms would not cause side effects and would be "functional" to some extent.
<ggole>
Expecting something to be fast just because it would be convenient if it were fast is a good way to get a slow thing
<ggole>
(Of course, sometimes that is quite acceptable.)
<scymtym>
no-defun-allowed: even without macros, the analysis has to be aware of all special operators and has to keep track of lexical variables
<no-defun-allowed>
Yes, which is why I'd expect certain things from the forms provided.
<no-defun-allowed>
Without enforced evaluation order, side effects would be horrible.
nowhereman_ has quit [Ping timeout: 252 seconds]
igemnace has quit [Quit: WeeChat 2.2]
JohnMS has joined #lisp
rumbler31 has quit [Remote host closed the connection]
<pfdietz>
The specified evaluation order of CL forms is a wonderful thing, compared to (say) C.
JohnMS_WORK has quit [Ping timeout: 252 seconds]
asymptotically has joined #lisp
<shka_>
pfdietz: i always wondered why neither C or C++ standardized it
<shka_>
i mean, why no?!
<pfdietz>
A poor choice very early, and then there was too much incompatibility.
<pfdietz>
Different C compilers had done different things.
<cl-arthur>
Where can I read about the evaluation order of CL forms?
<ggole>
Lots of languages do that, not just C
<ggole>
Even scheme :/
<pfdietz>
I think the poor choice was driven by how restricted C compilers were on 16 bit platforms. Tiny, tiny things they were.
<jackdaniel>
unspecified evaluation order may also allow some optimizations
<jackdaniel>
other language which does not specify it is scheme
<pfdietz>
That's the good intention that paves the road to this particular hell, yes.
<jackdaniel>
yes, most commonly it is a source of error
<heisig>
A consequence of the unspecified evaluation order is that I consider every C and Scheme program broken unless proven otherwise.
<ggole>
There's no particularly important optimisations that it enables that I know of
<cl-arthur>
Thanks for the links :)
Selwyn has joined #lisp
<heisig>
I also consider every program broken that uses fixed size integers without proving rigorous upper bounds :)
<ggole>
It may have been beneficial for early compilers with weaker approaches to optimisation
<jackdaniel>
heisig: what about programs using bignums without infinite memory? ;-)
<pfdietz>
jackdaniel: I can show you a perfectly correct seven line CL program that causes the SBCL compiler to blow out memory due to bignum sizes (and would not overflow if just run naively). The problem does come up!
<heisig>
jackdaniel: In this case, stopping because of heap exhaustion is the only sane option. Would you prefer your program to continue despite being broken?
<_death>
a language where the absolute function may return negative numbers...
<jackdaniel>
heisig: my point is that if you don't control upper bounds your program may not return correct results (because it won't return results at all!), having fixed size integers and crash on overflow is equally good/bad
<ggole>
SML raises on overflow, that's a fairly principled approach
<jackdaniel>
I'm of course half joking (like you did with demanding proofs of program correctness :)
<pfdietz>
In this case, it would have been possible for the program (the compiler) to succeed, just by giving up and widening the inferred types to (INTEGER * *).
<jackdaniel>
pfdietz: heh
wanz has quit [Quit: wanz]
<heisig>
jackdaniel: Oh, sure, if your languages crashes on overflow that is still sane (and might be preferable for real-time systems).
<jackdaniel>
I find solution mentioned by ggole most sane
<heisig>
... for real-time applications. For a computer algebra system, I would be quite bothered by that.
<pfdietz>
Speaking as a compiler tester, I really like that in CL integers behave like integers. It makes it easier to write test generators. Doing the same on C was hard enough that Regehr's team got several papers out of it.
<ggole>
For that you'd use a bignum library (in a language with fixed-size built-in ints)
<pfdietz>
Avoiding the 100+ (?) undefined behaviors of C while generating and simplifying tests is difficult.
<ggole>
Generating meaningful programs is a lot easier without undefined behaviour
<ggole>
If you wrap, but you are defined to wrap, then you are mostly fine
<ggole>
The C way is nonsense on stilts, no argument there
<jackdaniel>
heisig: I mean signalling a condition of overflow or heap exhaustion
<jackdaniel>
I think that heap exhaustion is undefined in Common Lisp
<jackdaniel>
s/of/on/
wanz has joined #lisp
<jackdaniel>
nb: c11 defines, that unsigned integers modulo wrapping is a defined behavior
<beach>
shka_: OK. Am I involved in this blog discussion?
<shka_>
beach: i think not
<shka_>
don't mind me, i am simply bragging :P
<shka_>
because finally i really started
<beach>
Heh, OK.
razzy has quit [Ping timeout: 252 seconds]
jmercouris has quit [Remote host closed the connection]
wanz has quit [Quit: wanz]
jmercouris has joined #lisp
nowhereman_ has joined #lisp
shka_ has quit [Quit: WeeChat 1.9.1]
DGASAU has joined #lisp
random-nick has joined #lisp
DGASAU has quit [Remote host closed the connection]
DGASAU has joined #lisp
orivej has quit [Ping timeout: 268 seconds]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #lisp
sunset_NOVA has joined #lisp
eminhi has joined #lisp
LiamH has joined #lisp
shifty has quit [Ping timeout: 245 seconds]
joast has joined #lisp
orivej has quit [Ping timeout: 252 seconds]
Bike has joined #lisp
dented42 has joined #lisp
<Petit_Dejeuner>
jackdaniel: I take it that unsigned is not defined then?
frodef has quit [Ping timeout: 245 seconds]
kajo has quit [Ping timeout: 252 seconds]
smokeink has quit [Remote host closed the connection]
<jackdaniel>
yes, signed integer may overflow and consequences are not defined
flamebeard has quit []
<pfdietz>
Presumably due to continued existence of 1s complement platforms?
* jackdaniel
doesn't know why
foom2 is now known as foom
<pfdietz>
I vaguely recall the original C standard was influenced by the existence of the Symbolics C compiler, which if I recall correctly translated C to Common Lisp.
<pfdietz>
Or to Symbolics' version of lisp.
<foom>
no, everyone agrees that no 1s complement platforms exist anymore. The undefined-behavior is there, now, for 2 reasons:
<semz>
if it's undefined behavior, the compiler may assume it doesn't occur, which allows a few optimizations. regehr had some posts about this
<foom>
1) the compiler/runtime may detect and abort upon seeing it, instead of being required to wrap. But wrapping is almost never what users _really_ wanted.
<semz>
though imo modern compilers are way too aggressive with that
<foom>
2) It allows for some optimization opportunities.
<pfdietz>
I'm not sure detecting and aborting when going out of bounds is wanted either. Look at the first Ariane 5 (failed) launch (Ada there, not C though).
<semz>
what would have been improved if the program silently did the wrong thing there?
<ggole>
Aborting is what it didn't do
<pfdietz>
The problem was in pre-launch calibration code. It did not matter what it was computing at that point.
<pfdietz>
The code was left over from Ariane 4. But Ariane 5 leaps off the bad much faster, so a number overflowed.
scymtym has quit [Ping timeout: 276 seconds]
<jackdaniel>
in ideal world of fixed integers (without possibility to upgrade to bignums) would be: a) signalling a condition; b) having condition handlers like in CL; c) compiler giving warnings (or errors) if there is no proper handler for the operation which may overflow - that's at least my not well thought-through opinion for this moment :)
astronavt has joined #lisp
<semz>
considering how arithmetic without error handling is impossible this seems like The Right Thing (tm), but the question is how to do it a) efficiently and b) with clean code
groovy2shoes has quit [Ping timeout: 264 seconds]
<semz>
(a) might be easier because the handlers will probably do some cleanup nearby, so the compiler could recognize it
<jackdaniel>
I find Common Lisp condition system one of its most amazing features (and it is fairly clean and efficient)
scymtym has joined #lisp
<ggole>
Seems the ariane 5 thing was a conversion from a double to uint16, rather than a uint16 operation overflowing
<ggole>
Good old truncating conversion
dale_ has joined #lisp
<ggole>
For when you didn't know you wanted those bits.
dale_ is now known as dale
<semz>
for a high level language CL's conditions seem like a perfect fit, yeah
sunset_NOVA has quit [Quit: Leaving]
<semz>
but i'd like something like it for a "C replacement" of sorts
<semz>
since it's borderline impossible to write C which handles all overflow conditions and not end up with a hairball
<jackdaniel>
eulisp's level-0 has a similar condition system and is fairly low level
varjag has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
<jackdaniel>
(low level as in doesn't have much constraints for other parts)
groovy2shoes has joined #lisp
<heisig>
semz: Common Lisp is a good C replacement, or am I missing something?
Cymew has joined #lisp
<semz>
depends on what you use C for I suppose
<semz>
for application development, sure
<ogamita>
ggole: this is why you don't want to put type declaration in your code.
<semz>
but I was thinking more along the lines of system programming with that remark
<semz>
fwiw, i'd love to be proven wrong there
<jackdaniel>
heisig: not so much for embedded boards like arduino, but these lose in importance every day - it becomes cheaper to standarize on arm than on atmega even for home electronics
<jackdaniel>
so CL is perfectly fine for embedded work too
<ogamita>
ggole: (defun speed (a dt s) (+ (* a dt) s)) (speed (the (unsigned-byte 16) 42) 3 0) #| --> 126 |# (speed (the double-float 42.0d0) 3 0) #| --> 126.0D0 |#
groovy2shoes has quit [Client Quit]
gilez has quit [Ping timeout: 272 seconds]
Cymew has quit [Ping timeout: 252 seconds]
<heisig>
For modern systems, Common Lisp is almost always a good choice. Even for system programming. I recently played a game of Quake on an operating system written in Common Lisp :-)
<beach>
semz: I am convinced that if you just add a few primitives to your Common Lisp implementation, then it becomes a perfect fit for system programming.
knicklux has joined #lisp
<pfdietz>
shelvick: nibbles uses internal SBCL things that change frequently, so don't expect recent versions to work with old SBCLs.
<beach>
semz: What kind of "system programming" did you have in mind?
Cymew has quit [Ping timeout: 272 seconds]
<semz>
embedded and kernel stuff, primarily. though admittedly the main motivation was more of a vague "let me get rid of C and its nonsense already"
<jmercouris>
what about μlisp?
Cymew has joined #lisp
<beach>
semz: I see.
<beach>
semz: Well, clearly full Common Lisp is probably too big for many embedded applications.
<beach>
semz: I am guessing you mean applications that must manipulate arbitrary addresses in arbitrary ways. In those cases, I think system programs written in C probably rely a lot on undefined behavior.
<beach>
semz: On the other hand, if we abandoned the silly (and very old) idea that an application program should have access to the full address space (including the stack) as if it had access to a raw computer, then we could write a very safe operating system using Common Lisp. But it would not have a "kernel" in the Unix sense of the term.
Cymew has quit [Ping timeout: 252 seconds]
SaganMan has joined #lisp
ogamita has quit [Ping timeout: 244 seconds]
jack_rabbit has joined #lisp
asymptotically2 has joined #lisp
asymptotically has quit [Remote host closed the connection]
q-u-a-n has quit [Ping timeout: 272 seconds]
Cymew has joined #lisp
shka_ has joined #lisp
Cymew has quit [Ping timeout: 246 seconds]
SaganMan has quit [Read error: Connection reset by peer]
Cymew has joined #lisp
actuallybatman has quit [Read error: Connection reset by peer]
robotoad has joined #lisp
actuallybatman has joined #lisp
Cymew has quit [Ping timeout: 245 seconds]
shrdlu68 has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
igemnace has joined #lisp
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Cymew has quit [Ping timeout: 245 seconds]
nowhereman_ has quit [Ping timeout: 252 seconds]
Cymew has joined #lisp
nowhereman_ has joined #lisp
asymptotically2 is now known as asymptotically
Cymew has quit [Ping timeout: 276 seconds]
<oni-on-ion>
that like asymptote
Cymew has joined #lisp
Cymew has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
Cymew has quit [Ping timeout: 244 seconds]
sjl has joined #lisp
zfree has quit [Quit: zfree]
orivej has quit [Ping timeout: 252 seconds]
Harag has quit [Ping timeout: 268 seconds]
varjag has joined #lisp
jmercouris has quit [Remote host closed the connection]
ogamita has joined #lisp
hhdave has quit [Ping timeout: 268 seconds]
eminhi has quit [Ping timeout: 260 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
maarhart has joined #lisp
maarhart has quit [Client Quit]
ogamita has quit [Read error: Connection reset by peer]
FreeBirdLjj has joined #lisp
ogamita has joined #lisp
FreeBirdLjj has quit [Ping timeout: 250 seconds]
dyelar has quit [Ping timeout: 252 seconds]
uint has quit [Ping timeout: 252 seconds]
uint has joined #lisp
m00natic has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
asymptotically has quit [Remote host closed the connection]
shrdlu68 has joined #lisp
asymptotically has joined #lisp
anamorphic has quit [Quit: anamorphic]
anamorphic has joined #lisp
nowhereman_ has quit [Ping timeout: 252 seconds]
anamorphic has quit [Client Quit]
sauvin has quit [Read error: Connection reset by peer]
nixfreak has joined #lisp
cage_ has quit [Quit: Leaving]
ogamita has quit [Read error: Connection reset by peer]
MichaelRaskin has joined #lisp
stereosphere has joined #lisp
meepdeew has joined #lisp
dented42 has joined #lisp
asymptotically has quit [Quit: Leaving]
whartung has quit [Quit: whartung]
aindilis has quit [Ping timeout: 268 seconds]
slac-in-the-box has joined #lisp
ealfonso has quit [Quit: ERC (IRC client for Emacs 26.1)]
anamorphic has joined #lisp
dddddd has quit [Remote host closed the connection]
whartung has joined #lisp
makomo has joined #lisp
edgar-rft has quit [Quit: Leaving]
eminhi has joined #lisp
anamorphic has quit [Quit: anamorphic]
anamorphic has joined #lisp
maarhart has joined #lisp
maarhart has quit [Ping timeout: 252 seconds]
ealfonso has joined #lisp
warweasle has joined #lisp
Jesin has joined #lisp
random-nick has quit [Ping timeout: 250 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
orivej has joined #lisp
meepdeew has quit [Remote host closed the connection]
knicklux has quit [Remote host closed the connection]
random-nick has joined #lisp
shifty has joined #lisp
anamorphic has quit [Quit: anamorphic]
anamorphic has joined #lisp
vtomole has quit [Quit: Page closed]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nika has quit [Quit: Leaving...]
<anamorphic>
Hi, Is this the most effective way to convert a sequence of any kind of numbers to a one-dimensional array of double-floats? (let ((x-array (make-array length-x :element-type 'double-float))) (map-into x-array #'(lambda (value) (coerce value 'double-float)) x-sequence) ...)?
<anamorphic>
Hmm that seems better given that I don't have to explicitly create an array
razzy has joined #lisp
<shka_>
anamorphic: other then that, your code does same thing
vlatkoB_ has quit [Remote host closed the connection]
<aeth>
anamorphic: you might want to use the type (simple-array double-float (*)) instead of (vector double-float) in case the latter doesn't make it a simple-array
<aeth>
(it is a simple-array in SBCL, though)
<aeth>
if it's simple, that means there's no fill-pointer and it's not adjustable (and maybe a few other things) so it's faster.
<anamorphic>
Cool thanks
<aeth>
* just means it'll take the length from the length of the input
<pfdietz>
Be aware: a simple vector is not the same thing as a simple array that's a vector.
<aeth>
A vector is a 1D array. A simple-vector is a simple T vector. A simple-array is a simple array. There is no specialized simple-vector. There are specialized vectors, apparently, since pfdietz just defined one. This is a flaw in the standard imo
<aeth>
9 times out of 10 your simple-array is going to be a 1D array (i.e. a vector) but you have to use the more verbose multi-dimensional array syntax to talk about it
<aeth>
Usually you get around this by defining your own easier-to-type type if your code is filled with it.
Bike_ has joined #lisp
Bike has quit [Disconnected by services]
Bike_ is now known as Bike
<aeth>
(If simple-vector worked like everything else you could just say (simple-vector double-float) instead of (simple-array double-float (*)) since the size would be an optional argument at the end. But you can't.)
azimut has joined #lisp
azimut_ has quit [Ping timeout: 246 seconds]
frodef has joined #lisp
kajo has joined #lisp
<anamorphic>
Yeah had noticed that about simple-vector. Is it a historical thing that it doesn't have a type specializer?
<pfdietz>
I think?
anamorphic has quit [Quit: anamorphic]
anamorphic has joined #lisp
<White_Flame>
it could be to simplify the class inheritance model
stereosphere has quit [Ping timeout: 252 seconds]
<White_Flame>
what would its immediate parent be? would simple-array be in its ancestry?
gilez has joined #lisp
<White_Flame>
but yeah, I've been bitten by that as well in utf-8 and byte buffer conversions. One library uses simple-vector, the other uses simple-array, and they are not interchangeable; you need to copy the data to an object of the other type in order to bridge them
<Bike>
simple-vector does have a specialization- it's T. this is confusing, of course
<White_Flame>
specifically simple-vector takes no specialization
easye has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
easye has joined #lisp
<oni-on-ion>
shka_: cool article! just read it now.
easye has quit [Remote host closed the connection]
<shka_>
oni-on-ion: refresh, i just improved page look
robotoad has quit [Read error: Connection reset by peer]
<oni-on-ion>
im using eww. =_
<oni-on-ion>
=)
<shka_>
ok
eminhi has quit [Ping timeout: 250 seconds]
<oni-on-ion>
i see that they are speaking about something similar here in channel. =)
<shka_>
i don't think so, but yeah
robotoad has joined #lisp
sjl has quit [Ping timeout: 246 seconds]
warweasle is now known as warweasle_afk
<oni-on-ion>
dont think so but, yeah..?
<White_Flame>
which article? didn't see any shka_ link in the recent scrollback
<oni-on-ion>
aeth saying 'one part of cl..' and iterators
<shelvick>
weird! maybe I typo'd my qlfile. ok thanks.
pfdietz has quit [Quit: pfdietz]
<aeth>
White_Flame: The library that uses simple-vector for bytes is Objectively Wrong™
<Shinmera>
simple-vectors have element-type T, unlike simple-arrays :/
<aeth>
If you use a simple-vector for octets then everything's 4x larger in memory (if 64 bit) and the compiler loses any chance at knowing what type it is when AREFing
Cymew has quit [Ping timeout: 252 seconds]
Cymew has joined #lisp
pfdietz has joined #lisp
Cymew has quit [Ping timeout: 250 seconds]
warweasle_afk is now known as warweasle
Cymew has joined #lisp
<aeth>
(Oh, and the GC has to iterate through the T vector to see if anything's a pointer, doesn't it?)
<shka_>
aeth: yes
Cymew has quit [Ping timeout: 244 seconds]
<Shinmera>
Anyway, it's not wrong, just not a good idea.
Cymew has joined #lisp
Cymew has quit [Ping timeout: 245 seconds]
shka_ has quit [Ping timeout: 245 seconds]
gilez has quit [Remote host closed the connection]
scymtym has joined #lisp
Cymew has joined #lisp
Roy_Fokker has joined #lisp
ggole has quit [Quit: ggole]
Jesin has quit [Quit: Leaving]
Cymew has quit [Ping timeout: 252 seconds]
rumbler31 has quit [Remote host closed the connection]
dddddd has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
Cymew has joined #lisp
jkordani_ has quit [Read error: Connection reset by peer]
Cymew has quit [Ping timeout: 252 seconds]
anamorphic has quit [Quit: anamorphic]
anamorphic has joined #lisp
anamorphic has quit [Client Quit]
anamorphic has joined #lisp
Bike has quit [Ping timeout: 256 seconds]
asymptotically has quit [Quit: Leaving]
nowhereman_ has joined #lisp
dented42 has joined #lisp
nixfreak has quit [Ping timeout: 256 seconds]
angavrilov has quit [Remote host closed the connection]
anamorphic has quit [Quit: anamorphic]
Essadon has joined #lisp
hhdave has joined #lisp
nullniverse has joined #lisp
LiamH has quit [Quit: Leaving.]
anewuser has joined #lisp
shifty has quit [Ping timeout: 252 seconds]
voidlily has quit [Remote host closed the connection]