| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9
Comments:
<0> I've been working on some Carbon stuff from SBCL, but I'm wondering if I am taking the wrong approach. I have code using the windowing toolkit in MCL, but I need to be able to run it on intel based macs.
<1> Riastrad1: your irc connection ****s
<2> Xach, Verizon ****s, specifically.
<2> Last night they decided it would be entertaining to start randomly disconnecting me, apparently.
<3> I'm going to give up if this happens once more.
<4> Hmm. So, what am I supposed to use to get gzip/gunzip? There seems to be quite a few possible ways to combine all that stuff together. Salza+inflate? zlib? ZIP?
<5> zlib would be the cannonical way
<1> rydis: salza has an example gzipper. lichtblau combined salza and inflate to get both, iirc.
<1> i'd like to get salza to do both, but that future plan won't help you much today.
<4> Xach: Yes. The only drawback is that neither salza nor inflate are in CVS. :-/
<1> rydis: i guess i don't see how that makes much of a difference.
<1> why would CVS help?
<4> Xach: Mostly so that I can update all dependencies in one go; using asdf-install re-installs stuff, even if I have the same version.
<4> I've been bitten by ancient asdf-install'd stuff a few times, and it's often not clear that that is the reason, to me.
<4> Xach: Do you know if there are big differences in performance between salza and zlib?
<1> rydis: do you mean a FFI binding to zlib?
<4> Xach: No, I mean <URL: http://common-lisp.net/project/zlib/ >.
<1> i haven't compared in a long time
<1> rydis: salza seems to be over 100 times faster
<4> Xach: There's a reason to go with salza+inflate, then.
<1> i tested by loading /etc/p***wd as an octet buffer and comparing (zlib:compress buffer :fixed) to (salza:compress-sequence buffer)
<6> Xach: are you sure you compiled your competitor's code? :-)
<1> i think so
<1> salza does not compress as well, though
<1> there are many improvements i would make to salza if i had the time and it was at the top of my todo list...
<7> Xach: do you know what makes zlib compression better?
<1> I'm not actually sure it's better. I'm trying to test right now, but zlib has been compressing for 5 minutes and it's not done yet.
<1> oh, there we go.
<8> Xach pasted "salza vs zlib on /etc/termcap" at http://paste.lisp.org/display/34834
<9> Wow! Alternatively, do you know why salza is soooo much faster than zlib?
<10> hmm, zlib also appears to compress worser
<1> a lot of declarations and ugly code, most likely.
<10> ow, is that zlib implemented in lisp?
<1> _deepfire: yes. so is salza.
<9> Oh, zlib is in lisp. Not enough optimization, I guess.
<1> right...not the canonical C zlib.
<11> At least they didn't pick a name that is likely to be confused for any other compression library out there.
<4> Hmm. The difference here is much smaller.
<4> 1.77 seconds for salza, 9.3 for zlib.
<4> (CMUCL, and I added (declaim (ext:start-block compress uncompress)) in zlib.)
<1> yeah, that's another thing. i heavily tuned for sbcl.
<12> is eugene zaikonnikov here?
<1> slyrus: i don't think so.
<1> rydis: what size input?
<12> Xach: in an email he implied that he might be around soon. I don't even know his handle.
<4> Xach: /etc/termcap, on a debian system. 631716 bytes.
<12> nor, I ***ume, does he know mine
<4> Salza compresses slightly better. 307797 vs 318899.
<0> slyrus - Can we talk a little more about Carbon and lisp? You were talking about adding support to the C runtime. I'm unfamiliar with SBCL's source ... could we talk about it for a bit?
<13> can i capture multiple return values in a loop form (in 3 separate variables) ?
<12> Dr^Nick: sure, what's up?
<0> Well, to be honest, its somthing I'd like to look at doing but I'm not entirely sure where to start.
<12> Dr^Nick: I see three missing things for sbcl 1) stable threads, 2) objc support and 3) runtime support for calling RunApplicationEventLoop or whatever other carbon API stuff applications need to call.
<4> xristos: If nothing else, (loop for (a b c) = (multiple-value-list (function-returning-3-values)) ...).
<12> threads are nowhere in sight for ppc. For x86, the story is a bit better, but progress has somewhat stalled with threads in "mostly-working" state, but not fully working.
<12> oh, and 4) is mach exception handlers, which basically work, but they seem to exacerbate the threads problems.
<0> sly - Why do we need threads specficially?
<0> or objc support for that matter, in order to support carbon?
<12> I'm hoping that someone who actually understands multithreaded programming models (mega1, hopefully) will give the code a look at some point.
<0> Carbon's appkit is thread-unsafe for the most part
<12> If we had threads, we could do the app kit stuff in one thread and the lisp stuff in another.
<0> Imagine we're running the event pump in one thread, and lisp stuff in a second. Most calls to carbon wouldn't be able to execute in the lisp thread and would have to be p***ed (MPRemoteCall?) to the main thread to execute
<12> yeah, you can probably work out models where we don't need threads. Personally, I'd like to have them and think that would be a good place to start.
<12> Isn't MPRemoteCall some sort of OS 9 thing?
<0> okay
<0> Maybe
<0> but its valid on os x, with a semantic change.
<11> slyrus: I think the point is that using carbon doesn't involve all of the objc cocoa junk.
<12> yes, but if you're going to go through the effort, you probably want the objc/cocoa junk at some point
<11> There comes a point where one just wants eye candy as soon as possible, and actual state-of-the-artness later.
<0> slyrus: Here's the hackjob I have at present: http://www.andrewbutcher.net/G.tar.gz
<0> I'm trying to clean this up
<0> Basically with it i can create windows and have some level of control over them...
<0> but as you'll immediately see its a terrible hack-job
<0> (load "g") (defvar w (make-instance 'g-window)) (g-clear w g-black) (g-make-visible w) ; example usage
<0> Anyway, this is what I've been trying to make work for some time now... and its becoming clear to me that my approach of doing everything in C and loading it in is gross :D
<14> hey guys
<12> huh. sbcl doesn't seem to like that (nor do I :) ) that use-package :cffi
<14> this site runs on CLISP after Paul graham's guidance http://www.morecute.com
<0> ah, you'd need to install CFFI
<0> asdf...
<12> no, it's installed. it chokes on some sort of name conflict with something in sb-int
<0> really? odd.
<0> I don't have any issues.
<15> dont shoot me for asking this, but how bad COBOL really is? coz i might be getting a COBOL job...
<11> body: COBOL, last time I looked at it, had some redeeming merit.
<11> But then, I didn't look at it from the perspective of possibly having to actually -use- it.
<13> i have a network socket reader that calls socket-receive and uses a fixed vector (not allocated every time) for the results
<13> with 1mb/sec traffic, sbcl uses 16% just for reading the data
<13> anything i can do to make it consume less
<13> 16% cpu sorrt
<16> body: cobol is like a LOOP syntax for iterating over hash table keys.
<12> Dr^Nick: ok, I prefixed all the cffi symbols with cffi:. g.lisp loads. nothing happens.
<15> didnt really look at it so far..i'm kinda scared actually. ha! maybe if i discover how bad it really is after i'm in on the job, i might not get so frustrated
<12> then what?
<0> (defvar w (make-instance 'g-window)) (g-clear w g-black) (g-make-visible w)
<0> you now have a window you can draw to and control "intertactively"
<0> the reference manual for the MCL version is : http://rlai.cs.ualberta.ca/RLAI/glispmanual.html
<0> its fairly similar if you're just doing basic drawing
<12> cute. but of course no event handling. this is where threads come in. how do you run the mac event loop and the repl at the same time?
<0> Threads
<12> perhaps
<0> Event handling is there actually
<12> it is?
<12> I can't, for instance click in the menu bar
<0> yeah, my impl isn't very complete yet though
<12> and have something useful happen
<0> right, that's due to not calling RAEL
<12> how do you run the event loop while sitting at the repl?
<0> which installs the standard event handler
<0> Ive got the C backend
<0> it spawns a thread that starts an event pump
<12> doesn't that need to be the main thread?
<0> then I do a bit of work to convince OS X that the event pump in the second thread is actually in the main thread
<17> and then if you call any functions on the main thread, you crash your app
<0> foom - things do work...
<0> the problem is that it's a total hack
<17> it may seem to work, but calling thread-unsafe functions from two threads doesn't *actually* work.
<18> I was trying to figure out if I could hack serve-event to register the fds and sockets it's listening on with the CFEventLoop
<18> but I never figured out how to actually do that registration
<0> foom I'm well aware of the implications
<18> I should probably look at the CF source
<12> Dr^Nick: have you looked at how openmcl does this?
<12> hey chandler
<0> thats why you have to use MPRemoteCall...
<18> Yo slyrus.
<12> did you ever look at ppc mach exception handling?
<0> slyrus - No, I have no idea how OpenMCL does it :(
<12> Dr^Nick: openmcl makes you appreciate how complex simple things end up becoming :)
<18> slyrus: no, sorry. I got a bunch of work handed to me that week on something else :-)
<0> And I've never looked at mach exception handling
<17> chandler: twisted (python) has semi-working support for that
<12> Dr^Nick: that was for chandler. I ***ume your working on x86?
<18> foom: Oh. that may be something to look at.
<0> Intel and PPC macs
<12> chandler: ok. should be pretty straightforward, just need a little ppc asm
<12> Dr^Nick: then you will have some work to do to port threads to PPC :)
<17> chandler: but it never really worked *properly*; the recommended way now is to run a separate thread for the twisted reactor and the CF event loop.
<0> my regular dev machine is a G4 powerbook
<18> foom: Shoot.
<17> chandler: but it did work somewhat. (see cfreactor.py).
<18> More than just some work, FWIW.
<12> chandler: shh!
<0> slyrus - Do you know much about OpenMCL?
<12> how so?
<0> How is it for speed compared to SBCL?
<0> ... Are you familiar with how they implemented their gui stuff?
<12> it _compiles_ much faster, but, for what I need, the code is much slower as it doesn't do unboxed arithmetic (or not as well or as much or something like that)
<12> I've looked at the gui code a little bit. I 've looked at the threads and mach exception handling bits in some detail.
<0> If you have any interest in working on getting these things working in SBCL, let me know how I can help out
Return to
#lisp
or
Go to some related
logs:
#ubuntu
coitus inflagrante
zerodni
rc_status debian
aaxine gentoo
LBreakout2 server address
DHCPNAK with no active lease
definition of _EVP_BytesToKey php
glxgear ubuntu
gentoo bootsplash_patch Sorry, this kernel version is not supported.
|
|