IRC channel logs
2016-12-13.log
back to list of logs
<ArneBab>with just 5% of the work which goes into the Linux kernel, the Hurd could provide USB and sound quite quickly, given that low-level is much easier when you can simply attach gdb to a filesystem and restart it without affecting your running system to iron out a bug you found.. <paroneayea>GOOPS (next-method) feels like it leaves something to be desired <paroneayea>another GOOPS thing: I'd like to be able to have "class values", the way that Python has class values <paroneayea>which is to say, *without* instantiating a GOOPS object, get something attached to that object <paroneayea>though maybe I need to look into how the metaclass sttuff works. <paroneayea>(class-slot-ref) seems to be doing the right thing ;) <davexunit>is it possible to just copy the prebuilt/ directory from the 2.1.5 tarball and build guile from git quickly? <davexunit>wingo: rendering and animating sprites with only the occasional gc run right now. :) <davexunit>ran simulation for 2 minutes, statprof reports that less than 1 second was spent in GC. <davexunit>(besides needing a GNU Changelog style commit log) <wingo>davexunit: patch looks generally good :) one thing tho, you need all five comparisons (< <= = >= >) because floating point arithmetic isn't commutative <wingo>davexunit: also you can specialize a f64 comparison if *either* argument is a flonum, afaiu <lloda>I think there's probably something wrong in specialize-numbers.scm, see bug #24908 <davexunit>ArneBab_: because I was trying to make the most minimal patch I could as a first pass. I will change it to cond when I take another pass to fix things up. <davexunit>wingo: wow I had no idea floating point arithmetic isn't commutative. thanks for that lesson! <davexunit>wingo: I'd love a bit of explanation about specializing if either arg is a flonum. I saw that done for u64s but I couldn't make sense of why it works. <davexunit>wingo: also, despite this being mostly a monkey-type exercise based on your u64 work, I find the vm/compiler code to be very hackable. <ArneBab_>davexunit: if you add an f8 to an f64 the result will be much different from adding the f64 to the f8. When we’re only working on f64 I’m not sure. Adding a small number to a large number might discard the small number entirely while adding the large number to the small number might cause an overflow. <ArneBab_>davexunit: what I find crazy is that I could review your patch without knowing much about the surrounding code. @wingo: kudos to that code from me, too! <davexunit>ArneBab_: I'm not sure if such a situation applies here. <davexunit>because they're all f64s as far as guile is concerned. <davexunit>but again, still quite ignorant so very likely wrong :) <ArneBab_>davexunit: for floating point math it’s always a question how many bit are reserved for the value and how many for the "magnitude" <ArneBab_>floating point number: 0.xxxxx*2^{yyyyy} <ArneBab_>how many x bits and how many y bits do we have? <ArneBab_>are they the same for all our floating point numbers? <davexunit>in the VM itself I believe everything is a double <ArneBab_>(in Fortran you can explicitly set this for every variable) <ArneBab_>and even worse: mathematical functions might throw away part of the precision depending on the operation) <ArneBab_>davexunit: here’s something fun: (= (+ 1.e20 1.e100) (+ 1.e80 1.e100)) <ArneBab_>compare to (= (+ 1.e20 1.e100) (+ 1.e84 1.e100)) <davexunit>ArneBab_: that first one returns #t, but mathemetically speaking it is false, correct? <ArneBab_>and here’s commutativity violated: (= (+ 1e84 1e100 1e100) (+ 1e100 1e84 1.e100)) <ArneBab_>(I had to experiment for a while to find that :)) <paroneayea>I guess it's not surprising, but am I right in reading that dispatching on a generic method, even when reading from the cache, is still O(n) the number of method definitions for that generic? <ArneBab_>associativity is what’s violated: (= (+ 1e100 1e100 1e84) (+ 1e100 1e84 1.e100)) <ArneBab_>first adding 1e100 and 1e100 and then adding 1e84 causes adding 1e101 to 1e84 so the 1e84 is ignored (below precision) <ArneBab_>first adding 1e100 and 1e84 gives 1.0000000000000002e100, when adding 1e100 it gives… <davexunit>turned out to be easy because wingo had already done the hard work for u64s. <dsmith>ArneBab_: Best to start with the smallest numbers first when summing a bunch. <ArneBab_>dsmith: yes — I just wanted to show the problem :) <daviid>wingo: although guile-gnome compiles and make check pass for 2.2, it actually still needs tuning, either g-wrap or guile-gnome or both (I beleive the C part of their respective C goops code needs to be patched). here is a very easy way to reproduce (you'd need to checkout devel, compile... then try this code): http://paste.lisp.org/+75P2 <daviid>wingo: ok, if you could later look at it later ... tx! <paroneayea>daviid: do you think you could figure out how to reproduce it and file a bug? <paroneayea>well, you clearly figured out how to reproduce it <paroneayea>but maybe reduce it to something useful for a clear bug report <daviid>paroneayea: I left all in this paste so wingo could see that 'test' used 2.1.4, compiling guile-gnome scheme modules for 2.2 ... <daviid>but all it takes is> (use-modules (gnome-2) (gnome gnome)) <daviid>gnome-program-init "name" "version") <daviid>this is a g-wrap or guile-gnome bug paroneayea , not a guile bug <daviid>paroneayea: you need to checkout the devel branch of guile-gnome to be able to compile install it sing 2.2 (and recompile/install g-wrap guile-cairo first of course, which I all do in /opt2 ...) <paroneayea>ok, I assumed it was a bug in the goops rewrite because it hit the vtable bug in the middle of goops.scm, but I guess maybe guile-gnome does something with the vtable outside of goops itself? <daviid>paroneayea: actually I don't :) this g-wrap and guile-gnome C part (which is important), I don't know <davexunit>wingo: I read more into specializing if either operand A or B is a flonum, but the way it is done for u64s requires additional VM ops for scm comparisons. <wingo>davexunit: you can unbox both arguments <davexunit>so even if it is, say, an integer, it doesn't matter? <daviid>and if I comment this gnome-program-init (which is optional, not mandatory), than if fails tring o instanciate a gtk-window from a glade file here, for info (this would need to be reduced to a snipset, but ...) http://paste.lisp.org/+75P2/1 <davexunit>wingo: okay, I see that it works. I changed 'and' to 'or' and experimented with various expressions. <paroneayea>davexunit: I'm excited to see you hacking the guile compiler, both because the work is cool, and because it's nice to see a higher count of people hacking the compiler :) <davexunit>even my ill-fated struct field unboxing felt very doable <davexunit>the code is clear enough that you can read what wingo has already done and figure out what the next step for yourself is. <daviid>davexunit: this sounds very good! does this also applies for f32? (I'm using f32 for guile-cv) <davexunit>yeah, definitely, actually. just realized I did my tests with f32 bytevectors <davexunit>since we don't have struct field unboxing, I've been defining certain record types as simple wrappers around bytevectors <davexunit>with a bunch of inlinable procedures to ref/set values within them <davexunit>with the operations inlined, the compiler can optimize all of my 2D vector math I'm doing. <daviid>davexunit: fantastic! image processing, 'pro' image processing can lead to full machine power and mem consumption... (tomography stack can be 3000 images of a couple of MB each ... and I use f32 vectors <davexunit>daviid: perhaps this new optimization will help. not sure though. try viewing the disassembly and see if there's any f64->scm instructions followed by branch instructions like br-if-< <daviid>ACTION is a bit confused wrt boxed, unboxed terminology, because in CL (a while ago he used CL), we'd do (declare (f float) ...) and the manual said 'f is then boxed' and the compiler can assume it fits in register (or something like that) <daviid>and now it appears you use unboxed for what used to be called boxed... unless I ssunderstood <daviid>davexunit: tx, I won't be able to do that now, but I hope any work done in this domain you are 'touching' now applies to f32 floats as well <daviid>davexunit: I'll try to dissamble im-=? later today and see (that is a terribly conssuming op) <daviid>davexunit: I did ask because you are in this perf check 'step' wrt sly, but wrt guile-cv, I'm still in the very beginning... <davexunit>daviid: well when you get to that phase, the ",x" REPL metacommand will be your friend. <davexunit>I've somewhat abandoned sly, but have taken a good deal of its code and am building a new game programming library. <davexunit>I will probably continue to use the sly name for it. <daviid>davexunit: thanks! abandoned sly? hum, you mean you are changing its API and implementation up to the point it is not sly anymore? just curious <davexunit>daviid: it will be almost entirely different when I'm done, yeah. <daviid>ok I just know nothing in this field, but I know it is somehow, with computer vision algo, the 'best' perfomance tests that guile has to deal with :) <daviid>or shall I say will have to deal with ... anyway, we are facing very good days now! guile is a must, geiser rocks ... we just need g-golf and ore lib ... then the world becomes guile :):) <davexunit>these floating point optimizations enable more programs to be written in guile and also perform decently. <daviid>davexunit: exactly! I hope for this, and with it, I should be able to write algo using guile-cv as fast as vigra itself <daviid>actually, it could even become fatser (procedure call is faster and guile-cv uses threading to parallelize most of its computation <daviid>though this said, my first objective is to bind what vigra_c has (which is a subset of vigra), rewritting things in scheme is not a priority, there are so much to do... <wingo>ACTION does not remember how to use the ffi <wingo>i want luajit's ffi and also ljsyscall <wingo>ffs the procedure->pointer errno stuff was never ported to 2.2 <paroneayea>I did ask them, as an aside, about the possibility of Guile integration <paroneayea>it sounds like if someone took it on, they could work with them and make it happen, since it's theoretically extendable with other languages