| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13
Comments:
<0> maybe so
<0> Krystof: I saw Aymeric briefly today, and he said he started looking into Lisp over the holidays, and for the first time in a long time he is now again finding great pleasure in programming.
<1> you mean porting sbcl to $strange_platform was his first exposure to it?
<2> beach: I read that as Asymmetric Vincent
<0> slyrus_: I won't tell him that.
<0> Krystof: he must have had some exposure to something like Scheme in the past, I would think.
<0> anyway, nice talking to you guys, but I have been up for 16 hours, and I have had 3 hours of (lisp-related) lecture and one Gsharp talk today, so I am off to bed.
<1> sleep well
<2> night beach
<0> thanks
<3> Xach: neat
<4> i'm reminded a little bit of the theory that a convenient and helpful and useful interface might be ugly and hackish and that's ok
<4> err, implemented in an ugly and hackish way
<4> it's nice to be able to say (checkout module) (rtag module "foo") (export module "bar") (make-tarball module release)
<4> i tend to forget to do that, so i provide the version number and sanity check the system file & documentation
<4> lemonodor: i rasterized some futura bold condensed but the spacing just didn't work out quite right
<5> futura bold almost looks like a completey different font to me
<4> maybe it was black
<6> xristos: you're using an old version of SBCL
<7> adeht pasted "slime/sbcl bugs" at http://paste.lisp.org/display/34535
<8> cods: i just want to run example programs from the book you adviced
<7> _deepfire pasted "NIL or not NIL?" at http://paste.lisp.org/display/34536
<9> _deepfire: the problem is quite likely the declared type of your function
<9> NIL as a type specifier is not "only the value NIL", it is "nothing at all"
<9> so (or nil box) is equivalent to box
<10> o/` and when I watch the lighting... o/`
<9> so the compiler figures that the WHEN can never be false
<11> ohh -- it has to be (or null box)?
<9> yes
<9> since you told the compiler something false, it is allowed to misbehave
<11> indeed indeed... thanks
<11> thanks a lot!
<9> are you using sbcl?
<12> kpreid: The return-value of a function being of type (or nil box) would, I think, mean that it either returns a box, or doesn't return at all.
<9> rydis: no
<11> kpreid, yes
<9> rydis just 'box' means that, too
<9> nil doesn't mean 'doesn't return', it is precisely the type with no values
<13> So the real question is: why didn't the ftype get checked.
<12> kpreid: OK. Then CMUCL uses it for another purpose.
<9> rydis: return type of nil means this function cannot return, because there are no values it could return
<9> return type of box means that if it returns, the value is of type box
<12> kpreid: CMUCL/Python, I'm fairly certain, considers a inferred or declared return type of NIL to mean that it doesn't return. Things such as ERROR.
<9> rydis: and it is correct to do so
<9> but it would also be correct to do so for (or)
<9> or (integer 0 (0))
<12> It's actually one of the problems with bordeaux-threads; the method used there with non-specialized methods in some functions that error leaks inferred method return values (which is a CMUCL bug) causing breakage.
<14> Hi all.
<9> well, the problem there is the type inference, not what is concluded from empty types
<12> kpreid: Yes.
<14> I need to do some text processing using lisp. Open a file, detect a start word, put all the lines after that into a list, stop doing that when I get to an end word.
<14> Can someone give me some terms to google to get examples of that sort of thing in lisp?
<12> I still think that to declare a return type of (or nil box) is a more explicit way of saying that it might deliberately not return than just box, though.
<12> I might be wrong in my thinking, of course.
<9> rydis: that seems plausible. I was just disputing that it had any semantic difference to CL.
<12> kpreid: Ah. Well, then we agree.
<13> so I guess sbcl never checks ftype declarations, even in safety 3.
<13> that seems somewhat bad. ;)
<11> i have safety 3 debug 3 speed 0 size 0 compilation-speed 0
<13> oh...it does if you do the declaim ftype before the defun.
<13> hm.
<12> Yes, you need to do that.
<11> wow, did not realise it made a difference
<12> Just like you need to declaim stuff inline before defun, and so on.
<13> i'd ***ert that it oughtn't to affect the inferencer if you do it afterwards, either, then.
<15> kpreid - Hey man, have you worked any more on integrating Serve Event with the Carbon / Cocoa event loop?
<15> Now that xmas is over it looks like something I'm going to have to start looking at
<12> foom: To affect the compilation of something, you need to say what it is before the actual compilation, no? The cl***ic (declaim (inline foo)) (defun foo (...) ...) (declaim (notinline foo)) is kind of an example...
<9> Dr^Nick: oh, hi
<9> Dr^Nick: I'd completely forgotten about that project
<12> (To generate code that is inlinable; ext:maybe-inline in CMUCL, for convenience.)
<15> ah haha
<13> rydis: I don't disagree with that first statement.
<13> rydis: what I disagree with is the final behavior of doing something clearly unsafe in safety 3
<9> Dr^Nick: it's still where I left it; I have a working-for-simple-cases but incorrect version and one which tries but fails to behave as serve-event should
<15> any chance i could steal it from you and take a look through it?
<12> foom: OK.
<15> or alternatively prompt you to continue it? :)
<13> ideally it would check it either way, but the current behavior of not checking it, *and* using it in type inference for call sites is seriously unsafe.
<9> Dr^Nick: do you want it in buildable form or just to look at how it works?
<15> either or
<15> Whatever is easiest for you
<12> foom: Hmm. Does it matter, if you /don't/ lie to the compiler? Is safe code with faulty declarations required to work or be flagged as faulty?
<9> okay, I'll throw the files into a paste. the first is harder because cvs doesn't give diffs with locally added files...
<15> sure :D thanks
<6> rydis: it's not a matter of what the spec requires, but of what the right thing to do is
<6> checking things on safety 3 would be the right thing, even if you're lying to the compiler, since finding out where you're doing that is a major reason for using safety 3
<7> kpreid pasted "sbcl/darwin CFRunLoop serve-event (nonworking version)" at http://paste.lisp.org/display/34539
<15> perfect, thanks
<7> kpreid annotated #34539 with "sort-of-works-but-not-properly-reentrant-and-inefficient version" at http://paste.lisp.org/display/34539#1
<2> kpreid: interesting. I would have tried to do that down in the C runtime.
<12> jsnell: I'm not entirely certain it's clear that there is a single right thing, but that's probably the best default policy.
<7> kpreid annotated #34539 with "(in-package "SB!CF") -- support code" at http://paste.lisp.org/display/34539#2
<9> Dr^Nick: that's it
<9> slyrus_: why would I want to write C? :)
<15> thanks man
<9> slyrus_: and the first version involves changing the representation of handlers, and so on
<9> because it registers a CFRunLoop source when you do add-fd-handler. so doing that from C would have been gratuitously painful
<9> and besides, I learned how to use sbcl's ffi :)
<13> rydis: yes, that is the point of safety 3.
<13> rydis: to find places where you inadvertantly lie to the compiler
<9> Dr^Nick: I just cvs updated and it shows there have been (automergeable) changes to serve-event.lisp since I wrote this, so don't just drop my file on top
<15> ok
<9> the relevant bits are all #!+darwin, of course
<9> (and I also made some things #!-darwin
<15> I've only been doing lisp for a relatively short amount of time, so this is going to take me a bit to get through anyway
<15> about a year(?)
Return to
#lisp
or
Go to some related
logs:
whats the difference with madwifi and madwifi-ng?
#math
_SERVER[SCRIPT_URL] missing
turn off beagled-helper
#math
ubuntu mv4
NTFS errord
#math
debian dvb-utils apt
sender_dependent_relayhost_maps example
|
|