| |
| |
| |
|
Page: 1 2 3 4 5 6
Comments:
<0> michaelw: Then I don't think it's possible. You need to either use a non-simple array, which makes for another level of indirection and more expensive access, copy, or do manual book-keeping.
<1> gimbal`: if you want to be true FOSS, look at RedHat instead
<2> projections about income on sales & support seem unlikely to be reliable
<3> foom: I suppose one could reasonably expect such optimization to not happen with (debug 3)
<2> SuSE makes it work, too
<4> google's stock price may be providing some gumption
<5> Maybe they have a high-tech gumption generation and storage facility?
<1> yeah, in oregon
<2> SuSE seems to get some appeal in europe
<2> Redhat is the token Linux company
<6> rydis: ****s slightly :(
<6> also, character io in sbcl is rather slow due to the unicode tax
<1> michaelw: well, what do you expect from UCS-4?
<0> michaelw: Something like the "pools" on the LispM is probably what you want. I don't see how it is possible to get what you want.
<7> target an embedded system and charge for your lispOS, 95% of all CPUs fall into that category, and most of them need an OS
<7> not sure, though, whether a lispOS is best for those
<0> (Possible with CL arrays, that is.)
<8> robotics applications would love it.
<1> nominolo: it's all in how you implement it
<7> sure
<7> but make sure you get security and real time
<1> embedded boards for robots, CL is an easy win
<7> oh, and small of course
<7> but that goes along with security
<7> however, i don't see how lisp has special advantage there. at least Common Lisp
<7> BitC looks nicer for such stuff
<4> heh. common lisp on embedded boards is an easy win?
<2> is there not a potential for that a lisp machine's hardware might be designed as to be more effective for the execution of a lisp os than are defined the set of components (e.g. CPU & bus) to a typical intel archiecture?
<7> i think there was a thread on c.l.l about this
<9> jsnell: it's not only that simple case
<2> & I dunno the electronics that I guess VHDL diagrams might serve to describe
<7> something about features modern lispM h/w should provide
<9> jsnell: it happens a lot in complicated functions, where stuff is used more than once
<9> jsnell: I'm sure there's some optimization going on still, but it's quite hard to predict when it'll show you a variable.
<2> once guessed that you might be able to define a specific type of memory chip for supporting e.g. cmucl-style bignum encoding
<2> er .. encoding in memory, I guess; fuzzy here, no doubt
<7> don't you alread have this?
<7> it's called carry-flag?
<7> and jump-on-carry
<7> furthermore, does an OS need bignum?
<4> depends on the size of a fixnum.
<7> yup, but even 24 bit should suffice
<6> rydis: yeah, ****s. i can work around it, but it ain't pretty
<3> foom: quite possible, I haven't really used the debugger much. I doubt anyone has :-)
<7> most important features i can think of: some gc-support (fine-grained paging) and some tag-features (e.g. "ignore n least-significant bits")
<3> michaelw: I don't think that's true in general (character io slow due to unicode)
<3> e.g. reading a 18MB file in using read-line takes 0.35s with sbcl (unicode), 0.85s with cmucl, 1.3s with clisp and 0.2s with perl
<3> read-sequence on character streams is admittedly pretty slow. I have a too-ugly-to-commit patch around somewhere for that
<6> jsnell: do you have your benchmark code around?
<0> michaelw: There might exist some "pool" library for CL in the CMU archives or somewhere. ;)
<3> michaelw: nothing fancy, just (time (with-open-file (stream "big-file") (loop for line = (read-line stream nil nil) for count from 0 while line finally (return count))))
<6> jsnell: around 1sec for 24MB here with read-line
<3> ok... is that with a utf-8 locale? mine was in a latin1 one
<6> yes, utf-8 local
<6> and it conses x4, of course
<3> decoding utf-8 is of course going to be more expensive than decoding latin-1
<6> jsnell: i have a read-sequence version on (unsigned-byte 8) streams which reads, processes and writes those 24MB back in 0.7--1sec (the C version does it in 0.5sec), and conses only slightly more than 25MB
<3> who cares about consing?
<3> oops, I was actually using an old version of sbcl. with 0.9.14.8 I get 0.26s for latin1, 0.48 for utf-8
<6> 0.9.13 here
<3> anyway, I don't really see what the problem is if you get ~1s for a unicode version (while doing utf-8 -> ucs-4 transliteration) and slightly under 1s for (unsigned-byte 8) streams
<6> slightly under 1s while doing a lot more work. i will try to re***emble a read-line version which does the same, so that i can compare directly
<3> oops, I missed the part about processing and writing back :-)
<6> yeah, i did a number of versions with different io strategies, but didn't finish all of them. i stopped when it became clear that I wouldn't get far, and switched to the next idea
<5> ... It's Tuesday? How'd it get to be Tuesday? I thought it was Thursday or something...
<3> no, it's wednesday
<5> Yeah, on that side of the pond maybe.
<6> jsnell: fwiw, the :latin-1 read-line version takes 2.7--3.4 secs, factor 4
<3> hmm...
<6> minion: memo for jsnell: ***uming the 4x overhead is due to large (unicode) characters, how feasible would it be to add a "byte-string" string type and an 8-bit character subtype? i believe the spec allows this.
<10> Remembered. I'll tell jsnell when he/she/it next speaks.
<11> hi all, what is the proper way to suppress all of SBCL's output when I call (compile-file) ?
<12> clhs *compile-print*
<13> http://www.lispworks.com/reference/HyperSpec/Body/v_cmp_pr.htm
<11> rtoym: that's what I thought, but it doesn't appear to work on SBCL 0.9.10.37
<0> bradbev: It's sort of a FAQ. It's probably googlable.
<11> ok, but does SBCL not muffle output when (eq *compile-print* nil) ?
<0> I don't know. You say it doesn't, and I have no reason to doubt you.
<0> It's a rather ancient version of SBCL, so I guess it might have bugs.
<11> hmm, CLHS says the dreaded "implementation-dependant" words about *complie-print*, so I guess its all up for grabs
<11> yeah, maybe an upgrade is a good idea
<0> (But I think it's in the SBCL FAQ. Something using MUFFLE-WARNING, probably.)
<14> (handler-bind ((warning #'muffle-warning)) (compile-file ...))
<0> <URL: http://sbcl.sourceforge.net/manual/Controlling-Verbosity.html > seems relevant.
<14> (Probably STYLE-WARNING instead of WARNING there would be better.)
<11> thanks for the links, I'll try that
<11> though, I it looks like Slime thinks that *compile-file* ought to do something - maybe my version is just too old
<15> Is BIG-REQUEST in the latest telent-clx?
<15> Has anyone updated http://mcclim.cliki.net/Building%20using%20ASDF recently?
<12> starseeker: Hello! I think I used those directions the last time I built mcclim some time ago.
<15> Hey rtoy!
<15> long time no chat
<15> It looks like :clim is now :mcclim
<15> Oh well, I guess if I can figure that out anyone can ;-)
<12> Oh, really? I haven't built mcclim in a while. Probably not since the last time I played with climaxima.
<15> rtoym: Did that scrolling bug ever get identified?
<16> if the clhs in lisp.org is out-of-date, why does it come up in google ahead of the one in lispworks.com -- does this mean the obsolete one is getting more traffic
<15> rr--: Not sure. Might be getting selected more in the google search results
<15> rtoym: I'm looking more at Axiom these days, but I still hope McCLIM will ultimately be the GUI lib of choice
<12> starseeker: No. But I also stopped working on it. I want to try again, with a more recent mcclim. Someday. But in some ways, the window of opportunity for climaxima is closed. I think wxmaxima (?) is pretty good.
<15> rtoym: Probably true.
<12> But if I could get subexpression selection working, that would open the window again. :-)
<15> rtoym: Heh :-). McCLIM is frustrating - it seems like it should rule the roost of GUI libs, but it never quite comes together - there's not been an "aha" experience for me yet.
<12> I don't use it enough or long enough for any kind of "aha", unfortunately.
<15> rtoym: I think my favorite idea with McCLIM is to start creating CLIM3, and fix the ambiguity and lack of clarity that seems to plague the current spec.
<15> and at the same time, try to understand it ;-)
<17>
<15> rtoym: Actually, I think the best folks to do such things are the ones figuring it out - they know what is needed to explain the ****er because they're going through it themselves ;-)
<15> rtoym: Conceptually, it seems like there should be "layered" backend options - use QT if you want a QT look, GTK if you want a GTK look, and clx if you want a custom look. But darned if I have ever figured out how that's organized. I should look at the new gtk backend
<15> I'm really hoping cffi will allow for a cl-gdi package on Windows.
<12> I don't care to much for the backend, as long as it runs on X. I just want to make it do what I want. I just don't know how to do it.
<15> Amen.
<15> Dan Stanger did some gdi work for Garnet, but I haven't yet been smart enough to understand it. (sigh)
<15> I wish I could upgrade my brain
<12> What is gdi?
<15> That's the Windows version of xlib, roughly
<15> So cl-gdi would be the moral equalivent of clx
<12> But done using ffi, right, since there's no network protocol?
<15> Presumably. I think it's clisp specific
<15> I remember in the early days of cffi some runs were taken at windows.h, but I don't know what became of that.
<15> You know, it's funny - presumably virtually all languages need "FFI" bindings to the operating system's graphical libraries, yet only lisp seems to go in for FFIs in a big way
<18> unlike ... python, perl, php, etc?
<15> It's just that I never see much talk about python's FFI system, or perls.
<15> What are they doing right that we're doing wrong?
<19> FFI in Perl? Bahahaha!
<19> I don't know about Python, but Ruby also falls a bit short.
<15> How do they handle graphical bindings, then? Python has wxPython, which is a tad quirky but seems to do OK
<15> Isn't there a GTK-Perl module of some sort?
<15> Cool - that was the most painless Gsharp run I've ever had!
<19> starseeker: here's Perl's FFI: http://perldoc.perl.org/perlxs.html
<15> Hmm. So is the special FFI issue in lisp that we have six different varieties depending on which implementation you use?
<19> starseeker: Just use CFFI.
<15> Oh, I agree.
<15> Darn it, scigraph isn't working
<20> starseeker pasted "scigraph build problem" at http://paste.lisp.org/display/22835
<15> What just happened there?
<12> You need to look elsewhere for the cause. The error is from asdf.
<15> Uh. Weird. I did (compile-file "") on that one file, and now it worked.
<15> why would it fail when asdf was building, but not on a compile-file command?
<15> Runs, too (or at least the demo works)
<15> Nifty.
<12> Because the return values from compile-file said there was a warning and asdf doesn't want to load a file that warned.
<15> Ah.
<15> SBCL is the most finicky about correct lisp code, correct?
<12> Probably.
<15> OK, that makes sense then.
Return to
#lisp
or
Go to some related
logs:
cedega dependences
arpwatch for winxp
gentoo netsetup part of
#math
gd5480 cirrus logic fedora
#debian
yum fc5 djvu
ubuntu c0d0p1 not exist
No Match for argument: kmod-ntfs
acer 3613 freezes
|
|