IRC channel logs

2013-11-27.log

back to list of logs

***alexei___ is now known as amgarchIn9
<dsmith-work>sneek: later tell wingo Awesome graph!
<sneek>Got it.
<dsmith-work>sneek: botsnack
<sneek>:)
<unknown_lamer>sneek: later tell wingo is there any reason to care about GLUT implementations other than freeglut in figl? (I added a module with basic freeglut extensions, not sure if I should just export schemey variants from the glut module or ...). I think the only non-freeglut in use is on OS X? And you can still use freeglut there.
<sneek>Got it.
<nalaginrut>morning guilers~
<lloda>DeeEff: if you have your data in an m*n 2D array, you can reshape its ravel to p*q with (reshape A p q). (reshape) is in guile-ploy, but it's mostly independent of the rest of the library. You can also do (reshape A p #f) or (reshape A #f q) and the other dimension will be deduced from m*n. When possible, (reshape) resolves to make-shared-array which it's O(1). Although it's much easier to use than make-shared-array.
<lloda>Guile also has (transpose-array A ...) if that's what you meant instead.
<ArneBab_>wingo: great article!
<unknown_lamer>oh sweet
<unknown_lamer>just in time for an atrociously slow news day at slashdot, an article on something about five people will care about but dangit they'll have low uids and its better than zomg blackberry is taking on le twitter
<wingo>tx :)
<sneek>wingo, you have 2 messages.
<sneek>wingo, dsmith-work says: Awesome graph!
<sneek>wingo, unknown_lamer says: is there any reason to care about GLUT implementations other than freeglut in figl? (I added a module with basic freeglut extensions, not sure if I should just export schemey variants from the glut module or ...). I think the only non-freeglut in use is on OS X? And you can still use freeglut there.
<wingo>unknown_lamer: i have no idea
<unknown_lamer>the extensions are worthwhile and pretty useful. Things like being able to exit full screen mode and a bunch of additional callbacks
<unknown_lamer>my opinion is that targetting the Free version that is still maintained instead of the deprecated non-free version is a reasonable idea for a free software opengl binding, so if you don't mind either way I'll just integrate the new callbacks etc. into the main module and submit it along with everything else a few weeks from now
<wingo>cool, as long as they resolve symbols only when they are first used
<unknown_lamer>yep, thanks to (define-glut-function ...)
<unknown_lamer>I'm thinking I'm going to bind openal and alure soonish... and they have similarly *fun* runtime symbol resolution. Good thing someone already wrote it for me ;)
<dsmith-work>Happy (virtual) Friday Guilers!! (for those in the US)
<wingo>does anyone know how guilemacs is going?
<TaylanUB>wingo: Haven't seen activity in the repo since the end of GSoC; latest status was that the wip-guile-sym branch unifies Elisp and Guile symbols, and bipt had said something along the lines of "now I can replace the Elisp engine"
<TaylanUB>It's fine to paste logs of this channel, right ? (#emacs has rules against it IIRC) http://sprunge.us/ZTXJ
<unknown_lamer>wingo: it can boot without the emacs interpreter, but you have to bootstrap it with elc files from a copy of guile-emacs with the interpreter enabled
<unknown_lamer>and now you can use the guile-elisp compiler and it Just Works (tm)
<TaylanUB>unknown_lamer: Do you have a version I'm not aware of ?
<unknown_lamer>bipt has one on eir computer, which has not been pushed upstream since the end of gsoc
<unknown_lamer>and bipt lives across the hallway so!
<TaylanUB>Oh haha!
<unknown_lamer>I keep prodding about pushing things to the public repo so other people can fix everything
<unknown_lamer>it's really, really close. Kind of awesome.
<TaylanUB>Well there aren't many people working on it .. I managed to make some tiny contributions, who else was working on it ?
<unknown_lamer>I don't think anyone
<unknown_lamer>but it needs to be made emacs master
<unknown_lamer>or I guess it's at the point where that discussion should start
<unknown_lamer>the future is HERE
<unknown_lamer>Scheme as a first class citizen on GNU comes with Emacs using Guile I think
<dsmith-work>There couldn't be a firmer statement of support.
<wingo>unknown_lamer: ask permission to fetch it and at least push it somewhere, in case the house burns down :)
<wingo>unknown_lamer: also getting it going with master would be swell
<wingo>startup times won't be perfect but they will be much better
<wingo>guile itself does half the work starting up, compared to before
<wingo>half of the work it used to do i mean
<unknown_lamer>bah, gcc-xml and swig both hate the SDL2 headers
<unknown_lamer>somehow clang's tool can parse them
<davexunit>unknown_lamer: trying to make sdl2 bindings for guile? :)
<unknown_lamer>not at this rate
<unknown_lamer>guile-sdl is entirely written in C, and sdl2 is enough different that it doesn't look like it makes too much sense to try and update it
<unknown_lamer>except for extracting sdl_mixer and sdl_gfx support, since afaict those extensions weren't changed much
<unknown_lamer>I pretty much have the array extensions I needed + matrix and vector ops for doing a few opengl things that were removed in 3.x implemented, so next it's see if it works well enough to rewrite the particle demo and then...
<unknown_lamer>I think I'm going to bind two or three functions from imlib to slurp images into bytevectors, and probably OpenAL+ALURE since they are smaller than SDL_mixer with fancier features
<unknown_lamer>despite its poor acoustic model, openal position audio is pretty cool on my 5.1 rig in the livingroom...
<unknown_lamer>too bad the guy that wrote vspace (ambisonic sound file generator) ended up writing a proprietary ambisonics based openal implementation for windows only :(
<davexunit>I could help you in writing an SDL2 binding by hand.
<davexunit>since I would like to move guile-2d to SDL2
<davexunit>and dropping guile-sdl would be nice.
<davexunit>using the FFI would be much nicer.
<davexunit>and focusing on only guile 2.x
<davexunit>guile-sdl does a lot of work for compatibility, iirc
<unknown_lamer>well, it's been around since the 1.4 days
<unknown_lamer>possibly even 1.2, but my memory is *very* fuzzy from then, since I was like ... 13
<davexunit>yeah, I understand why it has that stuff.
<davexunit>but that along with being written in C makes it all the more difficult to port to SDL2
<unknown_lamer>I'm amazed that ttn finally reappeared after fighting with mvo in the 1.7.x era
<davexunit>I'm not aware of that drama
<davexunit>I became a part of this community well after 2.0 was released.
<unknown_lamer>wasn't much in the way of drama, just a short commit war and revocation of commit rights...
<unknown_lamer>followed by ttn maintaining guile 1.4.x until the 2.0.x days
<unknown_lamer>irreconcilable differences in opinion about the gh_ api IIRC
<davexunit>ah, I see.
<davexunit>what is the gh_ API?
<unknown_lamer>"Guile High-level"
<unknown_lamer>it was an attempt at making a C api that was in theory portable. mzscheme supported it for a bit.
<unknown_lamer>but it was kind of ... bad
<unknown_lamer>it was never feature complete so you had to violate abstraction and use the scm api anyway, and then mzscheme stopped supporting it, ... followed by the scm api being greatly improved in 1.8
<davexunit>thanks for the explanation.
<unknown_lamer>next week on tales from guile's ancient history...
<davexunit>sounds like guile is on much better footing now.
<unknown_lamer>it wasn't too bad back then, gh at worst ended up being the prototype for a good extension api
<DeeEff>lloda: I got your comment about (reshape) in guile-ploy in my hilights this morning, this actually helps a lot. Thanks so much!
<unknown_lamer>'tho I hear that scheme48 would have assigned copyright to gnu, if only they had asked. Whoops.
<dsmith-work>Yes, the scm_{from,to}_* stuff is an incredibly sane improvement over the old gh_*
<lloda>DeeEff: glad to hear it
<jemarch>hi
<wingo>ohai :)
<wingo>how goes?
<unknown_lamer> http://git.hcoop.net/?p=clinton/guile-figl.git;a=tree;f=figl/contrib/math;h=f53133a7c747ef61aacdf0320401ec6be90435e9;hb=fca9c65f2070f2df9190708d48c6eca4fa64d97a progress!
<unknown_lamer>I'm even managing to rewrap my head around syntax-case after years in defmacro land (modified cut to add <<>> and <<...>> which are arrays and then mapped over, with possible constant and scalar <>)
<unknown_lamer>I hope vcut isn't some kind of sin secretly, because it makes doing math over uniform vectors much easier
<jemarch>wingo: hi andy. Congrats on the new vm.
<wingo>tx!
***sneek_ is now known as sneek
<jemarch>how can I set the name of a goops class created with (make <class> ...)?
<jemarch>Trying to instantiate a nameless class leads to a "no appplicable method for #<<generic> initialize ...>" errors, understandably
<jemarch>ah, with #:name
<civodul>wingo: wonderful post!
<civodul>especially the graphs ;-)
<civodul>hey jemarch
<jemarch>hm, I better use make-class
<wingo>:)
<wingo>jemarch: #:name 'foo perhaps?
<wingo>i don't recall
<jemarch>ah bummer
<jemarch>the manual is wrong
<jemarch>the initialization keyword for the dsupers slot #:dsupers, not #:supers
<jemarch>I would change the keyword to #:supers, to be consistent with #:slots
<mark_weaver>jemarch: I think we need to fix the manual instead, because there could be code out there that uses #:dsupers
<unknown_lamer>I am resisting urges to dig into goops
<jemarch>mark_weaver: hm, yes
<unknown_lamer>I peeked at the current goops.c and a good chunk of it could be rewritten in scheme
<unknown_lamer>and the built in type hierarchy is kind of wonky... e.g. <list> is the superclass of <pair>, despite all lists being pairs but not all pairs being lists
<ijp>we could rewrite it using rm
<unknown_lamer>and array? returns true for <vector> <array> <bytevector> and <uvec> despite none of them having a meaningful hierarchical relationship (uvec is a subclass of bytevector, everything else is a child of <top>)
<mark_weaver>unknown_lamer: I think the idea behind 'array?' returning true for those things is that the array accessors work on them (don't they?)
<unknown_lamer>yes, but I think in goops land that means there should be a class that can be specialized on that also operates on all of them
<wingo>goops should reflect that hierarchy imo
<unknown_lamer>it'd be a bad idea to change the position of <array> in the hierarchy, hence <basic-array>
<wingo>or if it's not a strict hierarchy, at least all arrays should be <generic-array>s or something
<unknown_lamer><number> is already using a deep hierarchy that corresponds to the numeric tower
<unknown_lamer>afaict, changing it is trivial (couple of make_std_class changes)
<unknown_lamer>'tho if I get around to that (trying to stick to opengl, not using goops yet, but I think I'm going to end up there) ... I don't see any reason not to move the initialization of stuff like that into scheme
<unknown_lamer>wingo: is calling C from the rtl vm still expensive?
<wingo>unknown_lamer: it's similar to the stack vm
<unknown_lamer>so, not a great idea when your C function is something like (eq? blah *goops-unbound*)
<unknown_lamer>gah, almost the entirety of goops.c could be done in scheme now, probably without too much of a hit either (and nil when AOT exists, eh)
<wingo>could be; but that code is very tricky and we need to move slowly there
<unknown_lamer>naturally
<unknown_lamer>I keep meaning to take a stab at adding method combinations (shouldn't be *too* hard since next-method already exists). The hardest part I think would be how to do the automagic generic merging for two generics with different method combinations
<wingo>things we appear to have documented: http://www.gnu.org/software/guile/manual/html_node/Sloppy-Alist-Functions.html
<wingo>wtf
<ijp>the fuck
*ijp runs git blame
<DerGuteMoritz>that's some sloppy-ass stuff!
<ijp>and it's really old
<DerGuteMoritz>I miss sloppy-alist-cons
<DerGuteMoritz>it would sometimes turn the alist into a sloppy alist?
<mark_weaver>ouch. I say deprecate and undocument immediately.
<wingo>fwiw currently about 10% of guile's startup time is spend in lazy dynamic symbol resolution, in ld.so
<wingo>seems quite silly for internal references, dunno
<mark_weaver>hmm. there seems to be a problem with guile's old vcs history
<mark_weaver>if I git checkout 07d83abe7b8b617e4bb70a08efc0c0f6999fa0cc^, just before several *.texi files were renamed, the files that were renamed are empty.
<mark_weaver>(I was trying to determine the origin of the sloppy-alist procedures)
<jemarch>does guile really need bdw-gc >= 7.2?
<dsmith-work>Works best. 7.2d
<dsmith-work>sneek: libgc?
<sneek>Someone once said libgc is http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.2d.tar.gz
<mark_weaver>jemarch: it's highly recommended. we can work with the much older 7.1 that's in debian stable, but at least one test in our test suite occasionally fails with that version of libgc, and things like finalizers work a little differently because of missing functionality in 7.1.
<dsmith-work>mark_weaver: Did wingo recently remove those workarounds in master?
<mark_weaver>he did remove some libgc workarounds recently, but I don't know the details.