1,097 karma · joined December 16, 2010
<p>
How will riot.js compile
this line?
</p>
would fail?[Don't mean to sound negative: I've been playing around with my own minimalist framework, so this is right up my alley. I'm reading the code to get a feel for how we've solved problems the same or differently, including the compile phase. Neat stuff and I'll write more when I have time to go over it in more depth.]
Side projects have mostly been stats/data based: using type providers to mash together different data sources, with visualization via FSharp.Charting.
Feels good :)
The PRU is the unrecognized gem of the BBB. As long as you're not scared of assembly :).
Edit to add citation. Also, I'm assuming you're talking about an S-Corp, since it would make not sense for a C-Corp. From http://www.irs.gov/Businesses/Small-Businesses-&-Self-Employ... :
"If most of the gross receipts and profits are associated with the shareholder's personal services [i.e. not from other employees or capital], then most of the profit distribution should be allocated as compensation."
If you're only paying yourself $15k of the %80k your company brings in, and that $80k comes from payment by clients for work that you personally did, then you are definitely on the wrong side of the tax code.
I and others noticed that the javascript solution posted was far from optimal. So for fun, I tried optimizing both it and the algorithm used. The end result runs almost 20,000 times faster and handily beats all implementations in the original post, including the carefully optimized C++11 one by almost 1000x.
As I say in the gist: it's still about the algorithm, not the language.
1) In any of the transformations [(-,-,+),(-,+,-),(+,-,-)], the delta b/w numbers (s-b, s-z, b-z) changes by 0 or 2. What this tells us is that if the delta is odd to start, it will always be odd, if even always even.
2) Since the final state will involve only one type left standing (or else the stronger could eat the weaker), we know that the final counts will be two at 0, one at something >0. Since our losers end with an even delta (0), they must always have had an even delta. In the scenario you proposed, that's s and z (2055 - 2017 = 38). So b, bigcorps, is going to be our winner.
3) Now that we know who will win, we need to find the maximum possible number of bs remaining. Since each move reduces the total population by one, the maximum bs will be produced by the shortest sequence of moves that gets rid of all zs and ss.
4) As long as z>0 and s>0, our best move is to have z eat s, as it drops the population of z and s by 2. So our first sequence is to have all zs eat ss, leaving us with s = 38, b = 4023, z = 0.
5) When z = 0, our only possible move is b eats s, creating a z, which can then be eaten by an s to produce a b, thereby restoring b to its original count and lowering s by 2. After repeating this sequence 19 times to get rid of the 38 ss, we'll have s = 0, b = 4023, z = 0.
Ergo, maximal final state is 4023 bigcorps.
V8 has seen a lot of really nice optimizations to closures over the last year. My favorite is that closures are no longer considered megamorphic.
Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. That's why you saw this behavior. The same would happen if you used a 'with' construct.
Just as a point of fact, javascript -- at least the v8 implementation I'm most knowledgeable of -- doesn't "keep the entire context alive forever." Only variables used in the closure are allocated into the closure (i.e. on the heap), the others are allocated on the stack and disappear as soon as the function returns.
I don't use iTunes so can't read their book, but I wanted to ask: you say that ARC is still their GC strategy, correct? So reference cycles are still an issue? I'm surprised at this. I can see reference counting being a strategy for moving a non-GC'd language to GC (like Objective-C), but to start a new language with that constraint is surprising.