| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8
Comments:
<0> Yes, makes sense.
<1> sure I can type it in from the repl. #.(gethash ...)
<2> kpreid: cheater.
<3> kpreid: if the gensym is the hash key... (:
<0> Just got troubled by object identity... :)
<3> ...you could just be using a scratch package and use the package system instead of a hash table
<1> antifuchs: #.(some-hash-key ...)
<1> or possibly symbol-plists
<4> rtoy: Hmm. I'm seeing some trouble with the build, now.
<4> rtoy: "GC lossage. No scavenge function for object 0x0000aefa", drops to ldb.
<5> rydis: Aargh! More GC problems. Are you using weak pointers/tables?
<4> rtoy: I was trying to build McCLIM and its listener.
<4> rtoy: I'll try peeking around a bit.
<5> Ok. I'll try that myself sometime. I haven't done that in a few months.
<5> I would guess McCCLIM doesn't use weak objects. I probably broke something in adding the GC stuff for weak objects.
<6> anyone know anything about forcing a stream to be unbuffered in sbcl?
<4> ruhl: It might be easiest to do that when you OPEN it.
<7> tritchey pasted "is it complaining about the length?" at http://paste.lisp.org/display/23954
<4> rtoy: It /could/ be some stale fasls. I'm not sure.
<8> tritchey: what's the type of your array ? (Check with type-of)
<6> rydis: what if it's a stream opened by sbcl? no way to change it? i've been looking in the docs, but no joy thus far
<4> ruhl: I don't know.
<7> tritchey annotated #23954 with "this is the code in ?" at http://paste.lisp.org/display/23954#1
<4> I imagine you could use some sb-posix calls on the fd of the stream, but that's probably not best.
<3> rydis: there's probably some fd stream bufferage going on
<4> ruhl: If you are still doing run-program thingies, you could open the files manually, with buffering explicit, and give them as args to run-program.
<8> tritchey: you need '(unsigned-byte 8) rather than 'unsigned-byte in your make-array
<4> tritchey: unsigned-byte is, indeed, not (unsigned-byte 8). (unsigned byte is "any positive integer", which is rather different.)
<8> or rather "any non-negative integer"
<1> ruhl: fd-streams are always buffered; you must use posix read/write
<4> rtoy: To be precise, I can (asdf:oos 'asdf:load-op :mcclim) just fine, but when I, after that, do (asdf:oos 'asdf:load-op :climacs-listener), it crashes, seemingly when trying to compile util.lisp.
<9> clim-listener?
<4> rtoy: Hmm. A cmucl running Hemlock and being idle seems to have dropped to ldb, too. "NOT BOXED: 58cb1000 58d19000 58d17000" a number of times.
<5> rydis: Ok. I'll have to try that myself sometime. I take it none of the earlier snapshots will run on your system?
<4> splittist: Yes, of course. Sorry.
<4> rtoy: Unfortunately not. :-/
<5> I guess I'll have to try it myself on x86 and maybe some other platform in case it's an x86 problem.
<4> I'd need to build a new kernel, which I might just as well do, anyway.
<5> rydis: Thanks for your help!
<4> rtoy: I'm sorry I can't help more; I just don't know enough about this sort of stuff.
<10> has anyone ever done a dylan-like iteration protocol for common lisp?
<5> rydis: Only one way to know more! :-)
<4> rtoy: Yeah. I don't really know where to start, though.
<3> foom: I take it you don't mean something like iterate?
<4> Probably by learning C, I guess.
<10> antifuchs: right. not something like iterate. iterate would require a new macro and syntax for every kind of thing you want to iterate.
<10> something like (iterate (for x in y)) where the behavior depends on the type of y.
<5> rydis: "NOT BOXED" is unusual. That happens when the current region end is not the boxed region end in get_bytes_allocated_lower. I wonder how I could have messed that up?
<4> rtoy: I suspect a stale fasl that gets loaded by my .hemlock-init.lisp.
<5> rydis: I hope so. :-)
<11> foom: maybe FOR in http://www.tfeb.org/lisp/toys.html ?
<4> rtoy: Yeah, seems like it. Sorry about the scare.
<5> rydis: Yay!
<5> rydis: These kinds of issue make me wonder if the snapshots should bump the fasl version everytime. But it's a pain to have to do that every time and do the cross-compile.
<10> jsnell: yeah, something like that.
<4> rtoy: This is probably one time when it's motivated, since you need to cross-compile, anyway, right?
<10> jsnell: the *real* trick is to have that capability and also make it compile to efficient code for the normal cases. ;)
<10> I suppose that's why dylan has a more complex protocol. http://www.opendylan.org/books/dpg/db_256.html
<10> although I don't actually know that one couldn't efficiently implement the simpler thing too
<12> iteration protocols are one of the great things about Dylan
<13> jsnell: I take it you didn't get a full understanding of the pv-table optimization when you did your symbol-macrolet pv-env thing?
<11> no, I just achieved enough understanding to apply stupid mechanical transformations on it
<5> rydis: Good point. I should have.
<3> good night
<13> shame
<14> how to access a slot value of c structs in an array using cffi? (foreign-slot-value (inc-pointer p (* n (foreign-type-size 'c-struct-type))) 'c-struct-type 'slot-name)?
<13> My current plan, fwiw, is to define a %method-function funcallable structure
<13> then if PCL thinks it can do the fast-function optimization, it can stick all the relevant information in a slot in that %method-function structure
<13> this then gets p***ed on as the :function initarg to make-instance 'standard-method
<15> thomas001: look at cffi:mem-ref as a way to get to the correct arraw element first
<15> s/arraw/array
<13> so if a user does (in an :around method or something) (apply #'call-next-method :function (lambda (args nm) ... (funcall function args nm)))
<14> junrue67, but foreign-slot-value operates on pointers not on elements?
<13> the system method for initializing methods will notice that it doesn't have one of these special method-functions
<13> and hey presto
<11> sounds cool. what problem will this solve?
<15> thomas001: you'll get a foreign pointer back from mem-ref
<7> junrue67 pasted "mem-ref into array of structs" at http://paste.lisp.org/display/23955
<13> jsnell: a MOP "compliance" issue
<13> at the moment, a user p***ing :function as a method initarg or attempting to capture the method function from an initialization method will various fail or confuse the system
<13> the failure occurs because the system doesn't p*** :function <function>, but :fast-function <fast-function> instead
<13> and confusion can ensue if the method-function and the method-fast-function don't in fact do the same thing
<13> anyway. All this is in the future. (But it's significant in that it is the last fully-fledged failure detected by Pascal Costanza's mop-feature-tests)
<16> re
<17> Xach: around?
<18> ... Do linux core dumps (not lisp cores) of sbcl help in debugging, or are they a waste of disk space? (or are they never ever created?)
<19> I've had core dumps of cmucl. Mostly a waste of space because they were caused by stale fasls. But I think I've used them when debugging the port of gencgc to sparc.
<18> I ask because the Linux headers say that the stack segment is bounded by a pointer in the USER area on the one end, and by ESP on the other, but SBCL does stack switching on non-Win32.
<19> Anyone having name resolutions issues with common-lisp.net? I seem to be getting temp failures in resolution.
<4> rtoym: After I removed a couple of fasls, it seems to be working OK-ish. Some weirdness with McCLIM, but I think that's PCL stuff.
<18> rtoym: cl.net works for me right off.
<19> rydis: But no GC crashes, so I feel better about that. I don't like touching GC. Too much magic for me.
<19> nyef: Ok. I've had 2 temp failures just now checking in stuff. Maybe my ISPs DNS is flaky.
<4> Hmm. Is there a CMUCL commit mailing list? If so, is it on gmane? (I can't find one.)
<19> kire: I think you should be a note on common-lisp.net about ftp going away.
<19> rydis: Yes, but I've been too lazy to get on gmane.
<19> Er, maybe kire should not be a note, but you might want to put a note there. :-)
<4> OK. I was mostly just curious. I might be interested in browsing it occasionally, but not in getting it in my inbox.
<19> I'll have to look at how the commit list is done now, since it's on c-l.net.
<19> Ok. The commit log is at cons.org. I'll (finally) get it logged on gmane.
<4> rtoym: Oh, then there might be an archive there, so I can just browse that, perhaps.
<4> Hmm. No.
<20> Hey Lispers, there's a programming flame war at #flame. You know all languages are basically LISP!
<21> The lisper's sleeping.
<20> (wakey (wakey (eggs and (bacey))))
<22> don't you mean (and eggs (bacey)?
<23> let the lesser languages perish in the flames.
<24> hi all, a slime question: when I type (defun and hit space I see on the bottom line "(defun name args &body body)" with "name" in inverse video. trouble is, it's not really inverse so much as the foreground color on a green background. this is problematic when the foreground text is green as well. can anyone tell me how to change the colors here ?
<21> jlf: I'd M-x apropos RET slime.*face RET
<25> _3b lol yeah that must be what he meant
<22> well, it was either that or (eggs #'and (bacey)), or maybe (eggs :and (bacey))
<20> (eggs and (lambda bacey (print bacey)))
<24> pjb: thx, i haven't found it yet but that looks like the right neighborhood
<26> hello.. anyone heard of L#? i'm just starting on lisp.. wondering if it (http://lsharp.sourceforge.net) is worth learning :/
<27> I don't recall anyone ever referring to it here.
<27> this channel focuses on CL. You can learn about it here:
<27> minion: pcl-book
<28> pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
<21> As a newbie, I don't think lsharp would be worth it. I'd rather stick to the standard Common Lisp (or possibly Scheme). Once you know lisp, if you need to run on .NET and there's no Common Lisp on .NET, then you can consider Lsharp.
<26> nope i don't need .NET; i just thought it might be a good, practical way to start :)
<29> learn one lisp, and you can do them all.
<29> although not all lisps are created equal
<21> Alpha_Binary: no. The practical way to start, if you already know some programming, is Practical Common Lisp, see above link.
<26> probably it's just me, but i've almost finished reading that, and still don't know where to start from..
<26> also i am a vi guy, so emacs seems.. well... strange, to me :/
<21> Bad, bad, bad! You don't just _read_ a computer programming book!
<27> well, ask a question.
<22> there are functions for dealing with plists somewhere right?
<30> pjb, hi
<29> the editor isn't that important
<21> You program a computer while reading the computer programming book!
<26> is that so?
<21> erider: hi!
<26> i used to think it's all about interactive programming and stuffs
<21> Alpha_Binary: of course, computer programming is not a theorical activity you learn reading books.
<26> _3b: same here, that was how i started as well
<21> _3b: yes, there are functions to deal with plist.
<27> there's very little you can learn from reading, honestly.
<21> _3b: check chapter 14 of CLHS
<27> ("You /dissect corpses/ while reading a human anatomy book!")
<29> reading can give you a landscape
<26> well, that makes sense.. guess it's why i'm barely learning anything
<22> pjb: thanks, had found the definition of em, but not how to use :)
<21> Alpha_Binary: when you read about a programming language, each time you learn a new construct, you must make a program using it.
<27> alpha - write programs. Ask questions.
<26> would anyone like to recommend a platform (, ide, anything) i can get started from, easily?
<22> my first project after reading PCL was dissecting one of the lisp implementations i wanted to try :p
<26> i will.
<27> alpha - for your suspected platform? Try bare Corman Lisp.
<26> ask questions, that is.
Return to
#lisp
or
Go to some related
logs:
kagami redwire
my_pthread_fastmutex_init
etch gpdf evince xpdf acroread
#math
#css
#lisp
mt882 commands
perllinux kernel in perl
ubuntu authentication required domain
#css
|
|