Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2009-11-19:

[2:45] <Dantman> Wes-, MisterN; I found the answer to my issue earlier about fonts
[2:48] <Dantman> GraphicsConfiguration doesn't give you the dpi for a reason... What GraphicsConfiguration has is a transformation matrix... That matrix is used to transform px so that 72 of them fit in 1 inch of the device (Undoubtedly Java uses the real dpi behind the scenes to calculate that transformation)...
[2:49] <Dantman> ;) In other words, according to Java, everything is 72dpi as far as graphics contexts are concerned
[2:49] <Dantman> And a Font pt is defined as 1/72 of an inch instead of the normal definition...
[2:49] <Dantman> Thus, in Java graphics rendering 1pt === 1px
[2:50] <Dantman> I suppose it is the "Java" way to do things...
[3:04] <inimino> isn't 1/72 of an inch precisely the normal definition of a point?
[3:16] <Dantman> Heh, gotta love the confusing Java docs: FontRenderContext (A point is defined to be exactly 1/72 of an inch, which is slightly different than the traditional mechanical measurement of a point.)
[7:41] <ondras> ashb: yes, no
[7:42] <ondras> MisterN: yes, it is huge .. perhaps automatically generated
[11:32] <ondras> narwhal guys:
[11:32] <ondras> http://www.explosm.net/db/files/Comics/Dave/comicallpeoplehavedoneiscomplain1.png
[14:30] <kriszyp> hannesw_: are you there?
[14:31] <hannesw_> hi kriszyp, yes i'm here
[14:31] <kriszyp> the latest trunk in rhino fails on parsing json with trailing whitespace
[14:31] <hannesw_> oh ok, that issue again.
[14:32] <kriszyp> I added a json.trim() in my local code to fix it
[14:32] <hannesw_> it seems like that is required by ES5, weird as it seems
[14:32] <kriszyp> not sure if that was right though
[14:32] <kriszyp> the browsers allow for trailing whitespace
[14:32] <kriszyp> browsers tend to speak louder than specs ;)
[14:32] <hannesw_> yes, and it seems weird to break on trailing whitespace
[14:33] <kriszyp> yes, indeed
[14:34] <hannesw_> we should talk about this with raphael
[14:34] <hannesw_> bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=513549
[14:35] <kriszyp> ok, good to know it is reported...
[14:36] <kriszyp> hannesw_: also, do you know if anyone has played around with integrating rhino's debugging into any IDE? I was playing around with adding editing and saving in the debugger, was pretty easy to do, seems it would really be nice to use the debugger integrated with some editor
[14:37] <hannesw_> yeah, there's been some debugger activity, but I haven't seen anything come out of it yet.
[14:38] <hannesw_> Attila Szegedi has been working on something, and I think there's a Eclipse project that works on a Rhino based debugger
[14:38] <hannesw_> There's this google group about debugging protocols: http://groups.google.com/group/webdebugprotocol
[14:41] <kriszyp> any pointers to the rhino based debugger for eclipse?
[14:44] <hannesw_> sorry, no idea, i'd have to google, too
[14:44] <ashb> wow not allowing trailing whitespace is a stupid thing
[14:45] <kriszyp> google seems to lead to amateras, but that doesn't look promising, will try anyway
[14:45] <ashb> rhino is still on CVS?
[14:46] <hannesw_> ashb: yes. there's also a git mirror on github
[14:46] <ashb> mmmmm CVS
[14:46] <ashb> the VCS of... 1992
[14:46] <kriszyp> hmm, a git mirror? I should start using that...
[14:47] <kriszyp> rapha's?
[14:47] <hannesw_> http://github.com/earl/rhino-mirror
[14:47] <kriszyp> ah, ok
[14:47] <kriszyp> thank you!
[14:47] <hannesw_> rapha worked from this also
[14:48] <kriszyp> cool, I think I will use that...
[14:59] <Wes-> ashb: CVS was a god-send when it came out. You clearly are not familiar with SCM using e.g. RCS, SCCS
[14:59] <ashb> i've used RCS too
[15:00] <Wes-> "please enter a message explaining why you stole so-and-so's lock"
[15:00] <Wes-> ugly ugly ugly
[15:01] <ashb> yeah. was wonderful
[15:01] <ashb> the first open source(ish) project i worked on was a 4/5 person team using RCS on a single remote server
[15:02] <Wes-> I used to use it for my daily work
[15:02] <Wes-> we were always breaking each other
[15:08] <MisterN> Wes-: have you used PVCS, too?
[15:09] <Wes-> MisterN: no, iirc it wasn't sufficiently cross-platform
[15:09] <MisterN> Wes-: good for you.
[15:10] <Wes-> we were doing BSDI, Solaris and Linux on Alpha back then
[15:13] <ashb> BSDI?
[15:15] <MisterN> Wes-: back then? PVCS is still used :(
[15:15] <Wes-> ashb: BSDI was a commercial release of BSD UNIX for x86
[15:15] <MisterN> well, "used". normally nobody makes commits, and rather copies directories
[15:15] <ashb> Wes-: ah
[15:16] <Wes-> MisterN: So are horses, but I prefer gasoline engines
[15:17] <Wes-> ashb: http://en.wikipedia.org/wiki/Berkeley_Software_Design
[15:17] <Wes-> I still have hard-copy manuals around here somewhere...
[16:51] <ashb> kriszyp: so what sort of features (native) does pintura need?
[16:53] <kriszyp> a db :P
[16:53] <ashb> beyond sqlite? ;)
[16:54] <kriszyp> no, sqlite is great
[16:54] <kriszyp> actually one of our devs is using sqlite with pintura
[16:54] <ashb> cool, flusspferd has sqlite
[16:54] <ashb> i.e. whats would (theoretically) be need to get it running on hippo
[16:55] <kriszyp> in your case, I just need to write an adapter for sqlite
[16:55] <kriszyp> I think the sqlite part would be super easy
[16:55] <kriszyp> I am just calling executeSql (like web database)
[16:56] <kriszyp> fwiw, pintura is really packaged up to work without some effort yet, so it is still probably difficult to play with
[16:56] <kriszyp> but I am thinking that flusspferd won't be a difficult target
[16:56] <ashb> thats okay - i wasn't planning on playing with it just yet
[16:56] <ashb> just wondering if there are features that would be needed in the env to get it working
[16:57] <ashb> my current 2 top projects are 1) 'finish' off the mongodb; and 2) DOM
[16:57] <kriszyp> you already have file access, right?
[16:57] <ashb> yeah
[16:58] <kriszyp> I have a store impl that just writes data as json files (real simple, not scalable)
[16:58] <ashb> doesn't quite match narwhal cos it was left over from our original and there's no proper spec for it yet
[16:58] <kriszyp> (but nice for proto-ing)
[16:58] <kriszyp> yeah, but I bet it wouldn't be hard to adapt to
[16:59] <ashb> we dont yet have a proper text stream. By proper i mean seek/read in X chars
[16:59] <kriszyp> once I get the comet stuff written, that would require async support and workers, but I don't even have that started much yet
[16:59] <ashb> it just does 'x bytes' and probably requires text files to be utf8
[16:59] <ashb> but you can get Strings out
[16:59] <kriszyp> thats fine, I am just reading in entire files as a string in this store
[17:00] <kriszyp> very simple/primitive
[17:00] <ashb> cool
[17:00] <kriszyp> which is the point, actually (kind of useful for demo-ing how to write a store)
[17:03] <kriszyp> it will require narwhal and jack (at least for now), but just their modules in the path, they don't actually need to be "running" (they don't need to be the module loader or JSGI server)
[17:29] <ashb> Wes-: you sure about generators aren't possible?
[17:29] <ashb> not even if you make the generator slighlty smarter?
[18:28] <Wes-> ashb: I think so, lemme write a quick sample code piece
[18:33] <Wes-> ashb: http://pastebin.mozilla.org/684889
[18:33] <ashb> will look tonight - off to a meeting with a potential client
[18:33] <Wes-> That's where I got stuck, what to write for "XXX" which means "pull from the expression above"
[18:33] <Wes-> roger that
[18:34] * Wes- wonders, upon reflection, if naming the generator output would work
[22:29] <ashb> Wes-: so looking at your paste
[22:30] <ashb> you just can't iterator directly over the the return of OpenStream
[22:30] <ashb> var s = openStream(filename); for (line in s) { ... }

 

 

Logs by date :