...
[13:18:24 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' ' set by jessm on 07:30:00 CST(-0600)
[13:37:00 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' ' set by jessm on 07:30:00 CST(-0600)
...
[21:34:58 CDT(-0500)] <colinclark> in your Current_Faust_Compilation demo, you've got a file:// url, which means I couldn't try it out
...
[22:26:38 CDT(-0500)] <colinclark> http://en.wikipedia.org/wiki/Integer_overflow
[22:26:40 CDT(-0500)] <thealphanerd> did you manage to get integer arithmatic working with asm?
[22:28:20 CDT(-0500)] <colinclark> Presumably one has to trust the VM
[22:28:46 CDT(-0500)] <colinclark> but I have no idea what kind of overflow behaviour you get--again, presumably whatever the underlying architecture does
[22:30:20 CDT(-0500)] <colinclark> I was curious about this statement, "Unfortunately some of the semantics of C++ do not translate perfectly to JavaScript, the unfortunate side effect of moving from an Object Oriented language to a Functional Language."
[22:31:18 CDT(-0500)] <thealphanerd> colinclark: is asm a vm though by itself???
[22:31:29 CDT(-0500)] <thealphanerd> colinclark: emscripten by default doesn't automate wrappers
[22:31:38 CDT(-0500)] <thealphanerd> it is easy to break out a function
[22:31:46 CDT(-0500)] <thealphanerd> but a class or a struct is a bit more difficult
[22:31:53 CDT(-0500)] <colinclark> well, yes
[22:32:00 CDT(-0500)] <colinclark> it's pretty well just C
[22:32:25 CDT(-0500)] <colinclark> One likely wouldn't refer to C as a "Functional Language" either
[22:32:47 CDT(-0500)] <colinclark> It seems to me less an issue of semantics not translating...
[22:32:51 CDT(-0500)] <thealphanerd> definitely not
[22:33:13 CDT(-0500)] <colinclark> though there are plenty of C++ semantics that wouldn't have equivalents in JavaScript, but that's sort of a separate issue
[22:33:35 CDT(-0500)] <colinclark> and more a question of what kind of "bridge" or language bindings are available between C++ and JavaScript in Emscripten
[22:33:46 CDT(-0500)] <colinclark> and your experience and sample code makes it clear that the answer is currently "none"
[22:34:00 CDT(-0500)] <thealphanerd> there are some projects
[22:34:12 CDT(-0500)] <thealphanerd> in forks of emscripten
[22:34:43 CDT(-0500)] <colinclark> Yeah, I saw reference to something coming
[22:34:54 CDT(-0500)] <thealphanerd> brb
[22:35:06 CDT(-0500)] <colinclark> I guess Emscripten is still very raw
[22:42:57 CDT(-0500)] <thealphanerd> and back
[22:43:13 CDT(-0500)] <thealphanerd> colinclark: I think that I need to go through and look at the way in which some of the larger projects using emscripten is done
[22:43:26 CDT(-0500)] <colinclark> yeah, it'll be interesting to see what they do
[22:44:05 CDT(-0500)] <colinclark> The other thing I wondered about is why you didn't mention the question of how much of a speed benefit we can expect with asm.js, based on the architecture of Web Audio, etc.
[22:44:17 CDT(-0500)] <colinclark> I guess we haven't had much of a chance to talk about it, what with our travel schedules
[22:44:38 CDT(-0500)] <colinclark> but I'm increasingly doubtful that asm.js offers terribly much benefit
[22:44:52 CDT(-0500)] <colinclark> but I suppose we should suffer through trying to port a few more examples to see
[22:45:21 CDT(-0500)] <colinclark> I mean, garbage is probably our first enemy
[22:45:33 CDT(-0500)] <colinclark> and I've written all of Flocking's unit generators to essentially be garbage-free
[22:45:56 CDT(-0500)] <colinclark> at least until you go swapping one unit generator for another or other much more esoteric things
[22:46:07 CDT(-0500)] <colinclark> my impression is that the VMs are really good at optimizing hot loops
[22:46:13 CDT(-0500)] <colinclark> which is what most unit generators tend to be
[22:46:28 CDT(-0500)] <colinclark> Types are totally stable
[22:46:36 CDT(-0500)] <thealphanerd> oh yeah
[22:46:53 CDT(-0500)] <colinclark> so an engine like V8 is likely going to compile a UGen to the point where it's pretty fast to begin with
[22:46:54 CDT(-0500)] <thealphanerd> Hongchan is maybe interested in using flocking to link together his waax modules
[22:47:03 CDT(-0500)] <colinclark> ah, nice
[22:47:05 CDT(-0500)] <colinclark> why is that?
[22:47:11 CDT(-0500)] <thealphanerd> becuase I was talking about it
[22:47:28 CDT(-0500)] <thealphanerd> have may have just been polite about it
[22:47:34 CDT(-0500)] <colinclark>
[22:47:51 CDT(-0500)] <thealphanerd> brb again
[22:47:53 CDT(-0500)] <thealphanerd> sorry
[22:47:58 CDT(-0500)] <thealphanerd> so much to tlak about though
[22:52:32 CDT(-0500)] <colinclark>
[22:52:35 CDT(-0500)] <colinclark> totally