| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11
Comments:
<0> kamo: Lies. There are at least three left!
<1> adeht: also if a file i loaded with the load form then "v" can't show the source but displaces a "source form"
<1> Xach: i really hope so
<0> Besides, CMUCL can't die before CSS finishes his windows port.
<1> nyef: that can't be Cascade Style Sheets - what is it then?
<2> kamo: carl s. shapiro
<3> kamo: carl s... shapiro
<1> thank you
<4> kamo: Maybe that's a feature. Try M-. on the function name then?
<5> is there a way to know the maximum allowable (function call) stack depth in cmucl/sbcl
<1> adeht: interesting - works likewise
<1> adeht: it turns out that "v" in sldb works depending on how the form is executed - if the containing file is loaded with the "load" form it shows "source form", if it is loaded with C-c C-c it works
<1> adeht: also - i was wrong about the package dependancy
<4> How can the file be loaded with C-c C-c? That's supposed to dump the toplevel form to some temporary file and compile that, as far as I know.
<1> adeht: not the file, but the form
<4> Ah.
<4> So it somehow tells CMUCL the actual location of the form?
<1> adeht: somehow
<4> kamo: So you were wrong about the package dependency, so now what's the condition for v to work as desired?
<1> adeht: so now the question is how to load all the files in a multifile project - if I do (load "file.lisp") it looses this info
<1> adeht: the condition is to load the form with C-c C-c
<1> perhaps there are other ways as well
<4> kamo: Hmm.. some hours ago I told you to compile the file, and you said it didn't work for your particular project.
<1> adeht: indeed it didn't - let me double check
<6> I'm happy to see that you've finally discovered that the cause for "v" not working was what I suggested two hours ago
<7> rr--: For non-x86, the size of the control stack tells you how deep the call stack can be. I don't know how big the minimum control stack frame is, though. For x86, the C stack is the control stack, so I guess it's the size of the C stack. BICBW.
<1> adeht: I confirm what I've told. When I compile with C-c C-k nothing changes ("v" in sldb shows source form and not the source)
<7> slime works for me with cmucl. But I have a pretty old version of slime.
<1> adeht: the only way I found to make it work is to compile the form with C-c C-c
<4> That's pretty weird.
<0> Hrm... That's a thought. It'd be nasty around the edges, but adding non-linear stack extension to some SBCL ports might not be impossible... or even very difficult. I'll have to think about that a bit.
<6> kamo: what exactly are you loading with C-c C-k? the file that contains the function, or some other file which contains more load forms?
<6> since a recent comment of yours seems to be implying the latter
<1> jsnell: hmm which one? With C-c C-k I'm compiling the file that contains the form that I want to "v"
<4> Ah, I think I know what happens.
<1> adeht: spit it pls ;)
<4> I looked at SLIME sources now. C-c C-c for CMUCL saves the Emacs buffer/position for the form.
<1> adeht: damn, that sux
<4> When you C-c C-k, CMUCL probably saves the forms themselves, or if it also saves file/position, SLIME chooses to disregard that.
<6> it doesn't
<4> jsnell: "it" being SLIME disregarding, or CMUCL saving file/position, or CMUCL saving forms themselves, or what? :)
<6> about slime disregarding it for the cmucl backend
<6> finding the source location for functions in a file compiled with C-c C-k should (and based on a quick test does) work
<1> jsnell: with which backend
<6> but until kamo can give an actual example that someone else can run, I guess there's not much point in this
<6> in the cmucl backend, as I just wrote
<4> jsnell: Yeah, and I can see the code for doing that...
<4> But there's also some "source-form" location thingy.
<4> I mean, there are 3 kinds of location, as far as I can see: file, stream, and lisp. Apparently, kamo gets lisp when he wants file.
<8> hmm... I though t this "no transport function for object 0x0b62f00f (widetag 0x0)" thing was threads related, but it's happened unithread (linux/x86-64)
<8> anyone else seeing gc problems on x86-64?
<6> don't remember having any in normal use. how are you triggering them?
<8> a fairly-long-running job doing some image processing stuff. want a backtrace?
<6> not really, a backtrace doesn't sound like it'd be of much use in tracking down the problem
<1> guys, I think I got when it doesn't work
<6> now, I might be interested in a self-contained example that can be used to trigger the problems :-)
<8> heh.
<9> slyrus: I've seen that too, but I so far ***umed it was a bug in the app.
<8> I'll try again and see if I can reproduce, if not contain the problem.
<6> I don't mind it being a really large self-contained example, as long as I can run it and expect a crash to happen at some point
<8> you don't really want the 10G of images I'm processing I imagine...
<6> that might go out of the "really large" territory
<6> foom: have you been seing that for a long time, or is this something new?
<9> jsnell: I don't really know; it happened on 0.9.18.75.
<6> and is it always widetag 0x0?
<9> no
<9> but it happens rarely, and only on one program.
<9> (out of 2)
<6> that's not good, we aim for at least 51% workage
<9> so I had ***umed it was probably a bug in that program, and suggested gcing a lot to try to track down where it happens.
<6> which one of the two is crashing?
<9> qres, the clos-using one.
<6> ok, thanks for the information
<6> it might be worthwhile to enable the gc verification to catch the problem sooner
<6> but I don't remember whether we left those in a working state the last time around
<8> jsnell: i've had trouble trying to get the various gc verifying bits working properly.
<8> I think we need a gc-verifier-verifier
<6> :-)
<6> slyrus: do you use the ffi in the program?
<8> yes
<6> alien or cffi?
<8> hell, probably both :) but definitely sb-alien (to libtiff)
<6> do you p*** any strings to the ffi routines?
<8> i'd imagine there's some filename p***ing
<8> yeah, I call TIFFOpen with a filename
<6> ok. then there's a small chance that the patch that I sent to sbcl-devel last week would help
<8> oh, neat
<8> (in some ways I'm glad this doesn't seem to be a threads problem :) )
<6> hmm... or is there a chance? I'm not quite sure :-)
<8> well, it last happened unithreaded with basically the same symptoms
<8> my first thought was, of course, threads
<8> deport-alloc.diff?
<6> yeah
<8> ok, I'll let this run, see if I can reproduce, patch, rebuild and see if I can re-reproduce.
<8> thanks!
<6> don't thank me yet :-)
<1> adeht: when I compile the file I have 10 warnings and a note - as a result the function that i'm studying is not defined :-O
<7> Hahaha!
<1> i thought only errors can prevent the compile operation from succeeding
<10> kamo: did you load the file as well?
<11> what is the difference between setf and decf?
<10> setf sets somehting to a value
<10> decf decrements something by a value (default 1)
<11> oh, but it sets it to the new value
<11> so i could say that decf something = setf something (something -1)?
<10> decf can be incorrectly implemented as (defmacro decf (place &optional (amount 1)) `(setf ,place (- ,place ,amount)))
<11> incorrectly?
<10> that is incorrect because it evaluates place twice
<10> and does not take into account that place itself could be a subplace in another data structure
<11> hm, i see! why should these things be so complicated? :(
<1> rahul: C-c C-k compiles and loads generally
<12> you won't think them complicated after you grasp the notion of a 'place'. You might even think them less complicated than what some languages have, after that.
<10> kamo: ok
<11> ayrnieu: well i dont know well other languages, probably a bit C (which is more complicated) and no other object oriented language
<11> but that other languages are worse, doesnt make lisp less complicated
<11> :S
<13> plutonas: write simple programs and you can get away with simple tools.
<13> It's your decision.
<10> plutonas: they're complicated so that your code doesn't need to be complicated.
<11> Athas: welll i think i can write simple programms well enough, did some for practice, but i cant stay to simple programms all my life long...
<11> rahul: i like the way you set it, and from what i have seen til now, i suppose you're right :D
<10> abstraction is about keeping the complexity contained in specific places
<11> well then, using lisp, is difficult only at the beggining, is that right?
<13> If it was difficult all along, we wouldn't keep using it.
<11> well it could be better than everything else, but still difficult
<10> I found lisp easier in the beginning
<11> and harder now?
<13> With setf you can just imagine that it will always work (until you need to write your own setf expander).
<10> no, easier than what I was using before
<13> I don't think I have ever had a bug that I could attribute to me misunderstanding some setf concept.
<10> and it's constantly getting easier... or maybe it's getting harder because I'm doing more interesting stuff :P
<11> i see, my first lisp programm was a text editor, that works on the command line
<11> but now that i tried to bind that to cl-ncurses
<11> things are getting very bad
<13> Isn't cl-ncurses a rather thin wrapper around the C API?
<11> so i leave this and continue reading pcl :D
<10> heh
<13> Talking to the world of the barbarians (ie. outside the Lisp image/Unix) is hard in most language. I/O is always more complicated than the comfy world of the language abstractions.
<10> oh no, my scsi drive went up 2 degrees
<10> (I was upgrading java :\)
<11> i/o was really easy for me, i have to say that i did the same editor in C a year ago, and it took me 5 days and it still has some minor bugs (it was a project for the data-structures lesson)
<11> now in cl, it took me 3 hours and it works perfect
<10> heh
<11> but cl-ncurses biah
<10> it's not like C ncurses is easier :)
<11> i am fighting 2 days with it, and now i give up, maybe i come back later...
<11> yes, probably if i knew C ncurses, i wouldnt have problems, i think the functions etc, are almost the same
<10> if only we knew the solution to the problem before we had the problem
<13> We obviously need trivial-ncurses with a more Lispy API.
Return to
#lisp
or
Go to some related
logs:
#lisp
Naraha Server
msinhore
#perl
#web
#ldap
maximizing window
#ubuntu
ubuntu failsafe gnome
#math
|
|