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

2010-03-14:

[4:50] <sh1mmer> anyone have any thoughts about good places to run node in the cloud?
[4:50] <sh1mmer> I heard a rumour about joyent and some kind of out of the box node support
[5:19] <Dantman> ^_^ Yay. the dns
[6:53] <Dantman> Anyone up right now?
[6:53] <kal> Dantman well.. kinda :P
[6:54] <Dantman> kal, Care to create a dummy http://wiki.commonjs.org/wiki/Website:Index/test for me?
[6:54] <Dantman> My edits are autoreviewed.
[6:55] <kal> donee
[6:55] <kal> I think :S
[6:56] <Dantman> ok. i'll have to fix the website's script
[6:57] <kal> it's supposed to not allow for direct changes or?
[6:57] <Dantman> See http://commonjs.org/test/
[6:58] <Dantman> Try making an edit to http://wiki.commonjs.org/wiki/Website:Index and seeing how nothing happens to http://commonjs.org/
[6:58] <Dantman> Right now changes to a page that was once reviewed will not show up till those changes have been reviewed.
[6:58] <Dantman> However if a page was never reviewed (you just created it) the latest revision will show up on the wiki.
[6:59] <Dantman> So you can't spam an existing page, but you can create any page you want and make it show up on the wiki without review.
[6:59] <kal> Ah I see :O
[6:59] <Dantman> unreviewed pages should probably be 404s until reviewed.
[7:00] <kal> seems logical
[7:02] <Dantman> ^_^ http://commonjs.org/test/ done
[7:03] <Dantman> And the draft works right as well http://draft.commonjs.org/test/
[7:03] <kal> Dantman: nice! :)
[7:05] <Dantman> I wonder if I should make a footer note that I manage the website and host it on a redwerks server.
[7:07] <kal> well it's quite a lot of text to put in a footer so maybe link in the footer to something like a "about the site" and there's a lot of space for info :)
[7:08] <Dantman> Meh, we already have "Copyright ? 2009 - Kevin Dangoor and many CommonJS contributors. MIT license."
[7:08] <Dantman> A little "Managed by Daniel Friesen, Hosted on servers paid for by Redwerks"
[7:08] <Dantman> is nothing
[7:09] <kal> well how'd you up it there then, on the same line or on another? :)
[7:09] <Dantman> Another
[7:09] <Dantman> Not that we're short horizontal space
[7:14] <Dantman> ^_^ Actually there's enough room to fit both lines on a single line without going past the content area width.
[7:15] <kal> okeey yea that kinda works, and I do get why'd you want it there
[7:21] <Dantman> When we create an auth system for Kommonwealth maybe I'll create a auth extension to MediaWiki.
[7:55] <Dantman> kal, Mind modifying http://wiki.commonjs.org/wiki/Website:Index too?
[8:09] <kal> Dantman: sorry was away, done now :)
[8:13] <Dantman> Heh
[8:19] <kriskowal> Dantman thanks for setting up the wiki/website. What's the new relationship between the commonjs github account and the new wiki-based CMS?
[8:19] <Dantman> github account?
[8:50] <Dantman> kriskowal,
[8:50] <Dantman> Agh, damn laptop
[8:50] <kriskowal> ,Dantman
[8:50] <Dantman> kriskowal, No relation anymore really... that's old content...
[8:51] <Dantman> The new commonjs.org site is nothing but a simple .htaccess that redirects everything to index.php, a all exclusive robots-draft.txt file, and a index.php
[8:52] <kriskowal> ok. what about the non-wiki stuff in the commonjs github. is it no longer hosted?
[8:52] <kriskowal> perhaps we need a subdomain to take advantage of gh-pages for that?
[8:52] <Dantman> http://gist.github.com/331871
[8:52] <Dantman> Non wiki?
[8:53] <kriskowal> unit tests
[8:53] <kriskowal> that kind of thing
[8:53] <kriskowal> it's probably fine just to reference the github page. thanks
[8:53] <Dantman> Well, the only thing I changed was the website... if there is non-website stuff inside the commonjs repo that's still relevant.
[8:54] <Dantman> If there was something somehow available to view on the old website that no longer works on the new one please point it out.
[8:57] <Dantman> I could also make unit tests viewable somewhere.
[9:21] <kriskowal> hannesw here's my preliminary cut of the Narwhal libraries decoupled from Narwhal proper and provided as a package http://github.com/kriskowal/narwhal-lib/
[9:22] <hannesw> kriskowal very cool! thanks!
[9:22] <kriskowal> ashb Wes-- ondras tlrobinson ^
[9:22] <kriskowal> i'm using git-subtree to keep it in sync without having to use submodules
[9:22] <kriskowal> i'm optimistic
[9:22] <hannesw> ah, didn't know about subtree
[9:22] <kriskowal> let me know if you want more or less in there
[9:23] <kriskowal> it does not presently include tusk
[9:23] <hannesw> now it may be we (ringo) won't need this after all
[9:23] <kriskowal> with subtree?
[9:23] <hannesw> because narwhal proper installs properly as a package
[9:23] <kriskowal> ah, yeah
[9:24] <hannesw> well i guess the default catalog entry for narwhal could be changed to narwhal-lib
[9:24] <hannesw> but we definitly want tusk :)
[9:24] <hannesw> http://ringojs.org/wiki/Tusk/
[9:24] <ondras> hmm
[9:24] <ondras> does not look bad
[9:24] <ondras> (narwhal modules separated)
[9:25] <ondras> the question is: what is the nature of its relation to narwhal now?
[9:25] <kriskowal> tom and i have made some headway on making tusk usable on other engines
[9:25] <kriskowal> ondras: flexible
[9:25] <ondras> hmmh
[9:25] <ondras> s/narwhal-lib/commonjs-lib/ ?
[9:25] <ondras> :)
[9:26] <kriskowal> to do so would require approval of everyone on commonjs, i think
[9:26] <ondras> my aim is not to bring in "commonjs", but rather remove "narwhal"
[9:27] <kriskowal> it would also put commonjs in the business of maintaining an implementation in addition to specifications. it might be good to keep them separate
[9:27] <ondras> because being impl-agnostic is the very nature of these modules
[9:27] <hannesw> kriskowal: i got tusk running just fine on my ringojs branch the other day
[9:27] <kriskowal> that's sweet, hannesw
[9:27] <hannesw> yep, it's great
[9:27] <kriskowal> tom got it running on narwhal-jsc the other day too
[9:28] <kriskowal> i'm a sync http module away from getting it to work on narwhal-node
[9:28] <hannesw> very cool
[9:28] <kriskowal> which naturally begs whether i ought to just make it work async
[9:28] <ondras> hm
[9:28] <ondras> exports.hash = function (s, _characterSize) {
[9:28] <ondras> pity we cannot use binary yet
[9:28] <kriskowal> it would be nice.
[9:29] <kriskowal> a lot of these modules have been simply ported from browser implementations
[9:29] <ondras> I have done the same in v8cgi :/
[9:29] <kriskowal> ondras, also, i have a branch of narwhal with your optparse. i'm not sure what to do about it.
[9:29] <ondras> never the less, it is indeed a very good idea to have at least one repository of purejs modules
[9:30] <kriskowal> args.js is pretty nice
[9:30] <ondras> kriskowal: if you think it is worty, move it to this library...
[9:30] <kriskowal> i'm not sure it is
[9:31] <ondras> args.js is not thoroughly documented, can I see some apidocs/usage somewhere?
[9:31] <ondras> it looks rather complex to me
[9:31] <kriskowal> it's jquery-like
[9:32] <kriskowal> http://github.com/280north/narwhal/blob/master/lib/narwhal/tusk.js
[9:32] * ondras is not a big fan of jquery syntax
[9:32] <kriskowal> http://github.com/280north/narwhal/blob/master/lib/narwhal.js
[9:32] <kriskowal> i tend to agree, but this is a nice fit
[9:33] <hannesw> is that narwhal's args.js?
[9:33] <kriskowal> yeah
[9:34] <hannesw> we have a simpler one: http://ringojs.org/api/ringo/args
[9:34] <ondras> hannesw: your api seems very close to v8cgi's one
[9:34] <hannesw> it's much more limited, but quite nice to use
[9:34] <kriskowal> if you s/addOption/option/, it's a strict subset, i think
[9:35] <hannesw> e.g. http://github.com/ringo/ringojs/blob/master/modules/ringo/webapp/daemon.js
[9:35] <kriskowal> almost
[9:36] * Dantman needs to come up with better names than flip and compact.
[9:37] <kriskowal> Dantman yeah, probably. what are the corresponding behaviors?
[9:37] <Dantman> For a ByteBuffer with inbuilt position and limit support.
[9:39] <Dantman> flip sets the limit to the current position, and the position to 0 preparing the buffer for get operations (ie: Writing data out from the buffer).
[9:39] <kriskowal> hannesw, it would be nice if we could align our args modules so that one can switch more easily between the two
[9:39] <Dantman> ie: You read data into a buffer, then call .flip() and it's ready for you to read that data out.
[9:39] <kriskowal> and i don't mind name-spacing our args module; we can move things into a narwhal subdir no-problem
[9:40] <kriskowal> we'll have to deprecate and migrate, of course
[9:40] <hannesw> kriskowal: not sure, I'd like to keep our args as simple as it is
[9:40] <kriskowal> i agree, just names
[9:40] <hannesw> Dantman: not entirely convinced about flip()/compact()
[9:41] <Dantman> compact copies any data in between position and limit to the start of the buffer, places the position at the end of the new location of the data, and sets the limit to the capacity of the buffer.
[9:41] <hannesw> basically you let the buffer manage two index variables which you otherwise manage yourself: position and end
[9:41] <Dantman> In other words preparing the buffer to read new data... without overwriting data that has not yet been read from the buffer.
[9:42] <ondras> kriskowal: how does args.js handle options with optional values, default values and numeric/repeatable options like "verbosity" ?
[9:42] <ondras> also, exports.Parser.prototype.Parser = exports.Parser; is somewhat confusing
[9:42] * ondras wants api docs to understand it :/
[9:43] <kriskowal> ondras, yeah, it's on the todo list
[9:43] <Dantman> hannesw, ^_^ So which code do you want to use? http://pastie.org/866053
[9:44] <kriskowal> ondras, we follow python's lead about optional values on options?they're not allowed because they introduce non-determinism. default values are provided by .def(). numeric-repeatables are managed by .inc() and .dec()
[9:45] <kriskowal> .inc() and .dec() are examples of methods that are trivially implemented on top of the basic .action() and .validate() methods.
[9:46] <ondras> I see
[9:46] <kriskowal> we also support all of the gnu conventions. -fbar --foo=bar --foo bar
[9:46] <ondras> from my point of view, args.js does about a million advanced things which I had no need for (so far)
[9:47] <ondras> it is pretty high level
[9:47] <ondras> including type validation
[9:47] <ondras> color output
[9:47] <ondras> etc
[9:47] <kriskowal> a strict subset of it is pretty simple.
[9:48] <kriskowal> i like hannes's approach.
[9:48] <kriskowal> i think it would be nice if someone can start with ringo/args and upgrade to narwhal/args if they want to buy in
[9:49] <kriskowal> i think it's pretty close
[9:49] <kriskowal> ringo/args's .addOption is essentially the same as narwhal's .option
[9:49] <ashb> Dantman: transclude means you can get content on the website without needing to approve it :)
[9:49] <ashb> http://commonjs.org/specs/modules/1.0/
[9:49] <ashb> right at the end :)
[9:50] <Dantman> I know...
[9:50] <ondras> kriskowal: ringo's addOption seems to be very close to my .add(), on the first sight
[9:50] <kriskowal> hannes's .help is different, i think
[9:50] <Dantman> Flagged revs can handle that, if I enabled it inside the other namespace.
[9:50] <ashb> speaking of arg validation, flusspferd;s is:
[9:50] <kriskowal> maybe we can hash out some common ground on commonjs
[9:51] <Dantman> But flagging everything doesn't feel too necessary.
[9:51] <ondras> kriskowal: also, I belive my impl also supports all gnu conventions, including -abcdef for -a -b -c -d -e -f
[9:51] <ashb> not loading for some reason...
[9:51] <kriskowal> ondras, yeah, we do too
[9:51] <ashb> wtf its just static html. whats going on here
[9:51] <kriskowal> -fbar is only equiv to -f bar if the f option takes an argument
[9:52] <ondras> kriskowal: however, -v is an example of optional argument
[9:52] <ondras> -vvv or -v -v -v or -v 3
[9:52] <ondras> how do you do this?
[9:52] <kriskowal> we only support one or the other
[9:52] <ondras> okay
[9:52] <kriskowal> .inc() does -vvv and -v -v -v, and .set() supports -v 3 and -v3
[9:52] * ondras thought this was also some kind of convention
[9:53] <ondras> but my unix experience is not large
[9:53] <ashb> http://flusspferd.org/docs/js/flusspferd%20core/getopt.html
[9:53] <ashb> there we go
[9:53] <ondras> :)))
[9:53] <ondras> more impls!
[9:54] <ondras> ashb: why don't you use the class approach?
[9:54] <ashb> 'class approach'
[9:54] <ashb> ?
[9:54] <ondras> bad naming, I now
[9:55] <ondras> var x = new X(); x.stuff()
[9:55] <kriskowal> python has modules for both approaches
[9:55] <ondras> x.showHelp(), x.parse(), ...
[9:55] <ashb> didn't see the need
[9:55] <kriskowal> people coming from shell expect ashb's style
[9:55] <ashb> there's not exactly a lot of internal state toe manage
[9:55] <ondras> instead of x_showHelp(data), x_parse(data), ...
[9:55] <ashb> its pretty much a direct mirror of gnu's getopt, yeah
[9:56] * ondras believes that internal state is not the only reason to use "new"
[9:56] <kriskowal> i named args.js to avoid confusion with getopt
[9:56] <kriskowal> if there's a getopt module, i think it should look like ashb's
[9:56] <ashb> ondras: sure, but also if you can do it all in one call most of the time///
[9:56] <Dantman> ashb, Try it again...
[9:57] <ondras> ashb: yeah
[9:57] <kriskowal> it make sense for args.js's Parser object to exist since it's possible to create subtypes that support specific styles of option decorators
[9:58] <kriskowal> but apart from that, it's just sugar
[9:58] <kriskowal> ashb, i'd adopt your getopt.js module wholesale if it conformed to crockford style
[9:58] <ondras> it is a pity that the ultimate goal of a standardization process is to throw away N-1 implementations, each being Y lines of nice debugged functional code...
[9:59] <ashb> kriskowal: yeah blame those C++ coders ;)
[9:59] <ashb> they wrote it
[9:59] <ashb> kriskowal: also its written in C++ since it what we use for parsing args for the main binary
[9:59] <ondras> "crockford style", what is that? no ==, no continue, no break, ... ?
[9:59] <ashb> camelCase
[10:00] <kriskowal> http://javascript.crockford.com/style1.html
[10:00] <ashb> kriskowal: you're fine with the v:[undefined,undefined] result style?
[10:00] <kriskowal> i'm not sure what you mean
[10:01] <ashb> -vv input produces output of v:[undefined,undefined]
[10:01] <ashb> which still feels a little odd to me
[10:01] <ashb> but its kinda correct
[10:01] <kriskowal> in what?
[10:01] <ashb> our getopt
[10:01] <kriskowal> oh, in getopt
[10:01] <kriskowal> seems fine to me.
[10:02] <kriskowal> when you look at the "v" option, you're looking for .length anyway
[10:02] <ashb> hmmm someone do me a favour: try sshing to 178.63.242.208
[10:02] <ashb> tell me if you get a login or a timeout
[10:02] <kriskowal> not it
[10:02] <ondras> login
[10:02] <kriskowal> http://wiki.commonjs.org/index.php?title=Coding_Standards&action=history
[10:03] <kriskowal> there was virtually no argument about following crock's lead
[10:03] <ashb> ondras: thanks
[10:03] <kriskowal> but that was back in february last year
[10:03] <ashb> kriskowal: yeah i mostly do camelCase for public and under_score for 'private'
[10:03] <kriskowal> maybe a quarter of our active discussion participants were not with us at the time
[10:04] <ashb> i.e. methods that you can call if you want, but dont complain when something changes
[10:04] * ondras has no problems here, but I am certain some people do not like "The { (left curly brace) should be at the end of the line that begins the compound statement."
[10:04] <ondras> etc etc
[10:04] <ondras> hm
[10:04] <ondras> Avoid use of the continue statement. It tends to obscure the control flow of the function.
[10:04] * ondras is not okay with this
[10:04] <ashb> yeah - tbh crockford is as wrong as he is right
[10:04] <kriskowal> avoid isn't the same as forbid
[10:04] <ondras> ok
[10:04] <kriskowal> a lot of this is non-normative
[10:05] <ashb> position of '{' doesn't matter so long as its consistent in a module/project
[10:05] <ondras> afk, going to cook lunch
[10:05] <kriskowal> afk, going to sleep :P
[10:05] <ondras> :))
[10:05] <ondras> gn
[10:09] <Dantman> ashb, going to re-vandalize the modules spec?
[10:10] <ashb> oh sure
[10:11] <ashb> edited
[10:11] <ashb> still shows up
[10:11] <Dantman> Oh well
[10:12] <ashb> you can't include a specific revision?
[10:12] <Dantman> If it ends up as a real issue I can enable flagged revs through the site...
[10:13] <Dantman> ashb, FlaggedRevs has built in handling so that included pages are stuck til reviewed, but I guess it only works when both pages use flagged revs... I only have flagged revs enabled in the Website namespace.
[10:13] <ashb> ah
[10:17] * Dantman still needs to come up with a replacement for flip and compact
[10:32] <Dantman> Hmm... does .mark() and .retrace() sound like a reasonable pair... ie: You .mark() your current location, do stuff that pushes the .position forward, then .retrace() to reset the .position to where it was when you called mark()?
[10:32] <ashb> i'm mainly not sure its a sane API
[10:38] <zumbrunn> Dantman: is the email confirmation for the wiki accounts supposed to work?
[10:38] <zumbrunn> I tried when you set up the wiki originally and I registered and I retried yesterday
[10:39] <zumbrunn> and I don't get an email I could confirm
[10:40] <ashb> Dantman: fwiw those do sound like better names. mark at least does anyway
[10:50] <Dantman> Different part of the api...
[10:50] <Dantman> That was a replacement for Java's mark/reset pair...
[10:51] <Dantman> reset sounds too heavy for something that merely returns the position index to a previous location.
[10:51] <Dantman> reset sounds like a better name for clear... resetting position, limit, and mark to their default locations.
[10:53] <ashb> but mainly - what's your thought on why those sohuld be members of the buffer?
[10:55] <Dantman> Heh, in that case I just don't feel like using a backend object that supports them, and discarding the functionality...
[11:01] <Dantman> ^_^ Heh, and if your impl doesn't have a backend with built in mark and you don't feel like coding it in C..... Buffer.prototype.mark = function() { this._mark = this.position; return this; }; Buffer.prototype.retrace = function() { if ( this._mark === undefined ) throw "Invalid mark"; this.position = this._mark; return this; }
[11:02] <Dantman> Actually, besides compact; the equivs of Java's clear, rewind, and flip can all be trivial prototypes that don't even need to be written outside of JS.
[11:03] <ashb> compact does?
[11:03] <ashb> I often find its better to think of APIs driven form the use case, not just existing APIs
[11:04] <ashb> existing APIs oftne come with baggage in terms of naming/expected behaviour that might not be right for us
[11:04] <Dantman> "compact copies any data in between position and limit to the start of the buffer, places the position at the end of the new location of the data, and sets the limit to the capacity of the buffer. In other words preparing the buffer to read new data... without overwriting data that has not yet been read from the buffer."
[11:04] <Dantman> mentioned it earlier
[11:04] <ashb> that seems like a really expensive operation
[11:05] <ashb> its a much 'smarter' buffer than most people are talking about
[11:05] <Dantman> Keep calling .write till you've written everything, or prepare your buffer for read to make use of the space that is left inside of your buffer; Pick your poison...
[11:08] <Dantman> The latter does need a little bit of data to be copied in local memory... But the former could have you trying to write the remaining 5 bytes from a 1024 byte buffer when you could instead read the 512 bytes that are remaining for you to read...
[11:09] <Dantman> Mhmm, the buffer is smarter...
[11:11] <Dantman> Right now I'm just developing it as "aio" rather than writing another time consuming spec that'll probably not get much attention... This kind of buffer plays well with other binary formats anyways... After all nio buffers co-exist with byte[] in Java.
[11:12] <ashb> its just a layer ontop of basically any buffer isn't it?
[11:13] <Dantman> Hmm... well if your engine has getters and setters, you could probably implement an aio bytebuffer on top of another buffer...
[11:13] <Dantman> But that doesn't do much for the rest of the api.
[11:18] <Dantman> nonblocking io operations that obey the semantics of the buffer (well, I suppose you could write an entire layer on top of your other io api), transferFrom/transferTo written in a way that attempts to avoid copying the data in the first place.
[11:21] <Dantman> Unless you're in rhino pipeTo probably can't be implemented at JS level.
[11:23] <ashb> so i dont really have a problem with the buffer knowing its read and write markers, but i know ryan will have a big problem with the compact type operation
[11:23] <ashb> so much that he just wont implement it: its a really slow op
[11:34] <Dantman> The only actual requirements of compact is that position becomes remainder, limit becomes capacity, and future get/put operations are made such that index 0 starts with the data that was previously in between position and limit.
[11:35] <Dantman> I'm sure there are some creative ways to eliminate, or at least defer the act of copying any data.
[11:38] <Dantman> COW, faking the location of the data so that the previous data stays in place but you use the other portions of the buffer as if they were located after it, allocating some sort of secondary buffer...
[11:39] <Dantman> Which is more expensive; Copying a small chunk of data, or calling nonblocking write twice? (Neither of these operations are even guaranteed to be necessary to do on every iteration)
[11:43] <Dantman> You, know if it's such a hateful act... In our version I could probably remove the requirement of setting limit to the capacity and make it so that it's possible for implementations to ignore the task of copying data, which would then instead cause the same algorithm to instead write all data from the buffer before reading new data without changing the algorithm at all.
[11:54] <Dantman> An impl could instead of copying data from position>-<limit to the start, set an internal offset to the position making it look like the data is at index 0, set position to the value remaining had, and set limit so that it sits at the real end of the buffer, not the capacity which becomes a virtual value temporarily.
[11:57] <Dantman> As a result the unused area in between limit and the real capacity (if any) would become the area ready to be read into.
[11:58] <Dantman> The algorithm would end up making use of any free area that any previous partial read didn't get to
[11:59] <Dantman> Writes would continue consuming the data until finally it had written all the data that had been read into the buffer.
[12:00] <Dantman> And at that point .compact would reset offset and position to 0, and limit to capacity thus freeing the buffer back up for a full stack of fresh data.
[12:01] <Dantman> No change in coding, pattern, but the impl gets to pick whether it wants to copy data or artificially shrink the capacity of the buffer.
[12:02] <Dantman> ^_^ Maybe I'll have to come up with some diagrams for these.
[14:19] <Wes-> kriskowal: Thanks - been thinking about trying to sort through Narwhal again lately
[14:20] <Wes-> kriskowal: Any kind of a test suite? I found your moved interoperablejs repo the other day
[19:02] <ashb> Wes-: such as http://github.com/ashb/juice/blob/master/lib/juice/application.js#L621
[19:02] <ashb> tho admittedly i do that via absolute requier
[19:14] <Wes-> ashb: yeah
[20:09] <MisterN> ashb: var err = "Unable to load module 'file://" + module.resource.resolve( id + ".js" ) + "':"; <- here you should use the variable instead :P
[20:11] <ashb> huh yes thanks :)
[22:10] <Dantman> :/ apache commons' charset lib doesn't play well with nio, there goes that plan...
[22:16] <Wes-> Dantman: If you take my Binary/F plan, you don't need the charset lib
[22:16] <Wes-> Of course, my plan is "only support Unicode character sets"
[22:16] <Wes-> but I don't think it's a bad plan when you start talking reality vs. fantasy
[22:17] <Dantman> Wes-, I'm just looking at commons' specific Base64 and Hex encoders.
[22:17] <Dantman> Java builtin ByteBuffer decoding by charset is fairly trivial.
[22:18] <Dantman> Grab your charset with Charset.forName, use charset.decode to turn your ByteBuffer (which might not even be a byte[] it could be directly from memory ;) ) into a CharBuffer, then call toString on that CharBuffer.
[22:20] <Dantman> But apache's lib only works with byte[] and Input/Output Streams.
[22:20] <Dantman> So you can't encode a ByteBuffer with it unless you turn it into a byte[]
[22:21] <Dantman> Easy if your ByteBuffer is already backed by a byte[]
[22:22] <Dantman> But if not, you end up copying data efficiently located outside of Java's normal GC into the area of mem it does the gc.
[22:23] <Wes-> sounds like java needs pointers and programmer-managed memory, if you ask me. ;)
[22:23] <Dantman> No, Apache needs to update their commons libs to support nio.
[22:24] <Dantman> There's no way pointers are going to show up in main java, one of java's strong points is the fact that you can't cut your foot into 5 pieces, and forget one in a programming error ;)
[22:25] <Dantman> nio is a good middle ground in between the completely java gc managed byte[] and the wild world of pointers.
[22:27] <Dantman> *cough* Perhaps I should have instead said "...can't cut your foot into 5 pieces, and forget you hid one inside your lunchbox when you reassemble your foot, not leaving you with enough room for your food..."
[22:29] <Dantman> ^_^ Wes- with MappedByteBuffers you can copy os managed mmap data from one MappedByteBuffer to another MappedByteBuffer, theoretically doing it without copying a single byte of the data into an intermediate java managed buffer.
[22:30] <Dantman> That close enough to the world of pointers?
[22:31] <Dantman> ;) And iirc, that task would roughly be mmapB.put(mmapA);
[22:43] <Dantman> O_O Java 7 supports symbolic and hard links!
[22:47] <Dantman> you know, theoretically someone could implement base64 and hex using a CharsetProvider, and a set of Charset, CharsetEncoder, and CharsetDecoder classes...
[22:48] <Dantman> Then any normal pattern for toStringing something would instantly support .toString("base64");
[23:46] * Dantman still has not come up with names to replace flip and compact

 

 

Logs by date :