zenspider

I have a TODO in omnifocus to fold those in. It's a shame I didn't do that earlier.

and freedom: http://www.macupdate.com/app/mac/27958/freedom

I would like to like riot, but not creating a new test instance per test is a Bad Thing™. I just can't abide by it despite the speed boost.

You forgot the most important part... They're MUCH MUCH faster so you get a wonderful productivity boost, esp when you run your tests with autotest.

SHIFT-JIS is important because ruby is a japanese language with a huge foothold in Japan. A lot of SHIFT-JIS gets processed by ruby.

you _do_ know you can customize emacs with ruby, right?

http://www.emacswiki.org/emacs/EmacsLispForRuby

I dunno what you consider reliable, but I don't trust git in the slightest. 3rd link down on a quick google search shows an august 2009 date (1st 2 links are both from 2006 on the git mailing list):

http://pastebin.ca/1549372

I've had git fuck with my code/data one too many times to fully trust it.

Doesn't build for me either right now (NativeRect array problem in nsterm.m), but I'm guessing it doesn't for him either since there hasn't been a build for 2 days.

I've always build mine with:

    ./configure --with-ns
    make -j 4 bootstrap

(I only rebuild every few months or so, so a bootstrap is safer)

Not a stub, a bridge. As you can see in the readme, there IS a php runtime embedded in ruby. So that covers your redundant requests for interpreter and runtime.

Compiler? Why?

Embedded and dynamic linking? Does that even make sense in the PHP world? Sounds nonsensical to me, but I've avoided PHP until now.

HOLY SHIT! YAY!

I knew if I just waited long enough someone would finish this off for me! Wonderful!

What do you think about folding this into sexp_processor?

I should prolly actually ask this on github. I only read ycombinator for the enterprise post. :)

that is CERTAINLY some of it... wtf were they thinking when they decided to take the regular find-file TAB key and replace it with RET???

to answer the question above: it is VERY intrusive. I've finally set it up to only ever take 1 line only, but even then it is a huge departure from the norm. The key incompatibility is a huge issue. The fact that all my muscle memory (17 years) is dead using it.

I have this peculiar belief that C-x C-f RET should _always_ open the parent dir of the current buffer's file. ido threw that out the window. Now that will load the alphabetically first file in the dir. Lame.

There are others, but I don't remember them currently.

I'm thinking more like cpan than mozilla...

Dave Winer has been bitching about apple for years and years and years... it is his favorite hobby.

Someone is always going to bitch about apple. period.

Hypothetical example: What if apple is already working on a better podcasting app that works on the iphone, yet they _don't_ reject any apps?

Then, when their podcasting app comes out and kills off the competitors (usually because it is free--but also because they write damn good apps), then some author is going to bitch about how apple targeted them and killed their app. Sounding like that whiny sandvox guy doesn't do anyone any good.

Maybe... just maybe... this is the better alternative.

Personally, I'm going to write the quickest/smallest app I can that gets the 1.0 beta 1 idea into form. I'll apply with that. If I get accepted, great. I'll pump out a lot of releases getting it to 1.0 final. If not? I didn't lose that much time/effort.

"He doesn't really mention in his post the fun fact that you've got to pay a fee so Apple can review/reject your app. Definitely not feeling warm and fuzzy about the investment so far."

You'd rather they get flooded with an absolute ton of crap? The fee isn't _that_ much and it separates the boys from the men, so to speak.

I'm still not sold on ido... I'm trying it out again, but thus far there are enough annoyances that I don't think I can activate it full-time. I may, however, use their completing read function standalone tho for other things I do.

So far, I've found that autotest.el + file-cache + ffap + some advice for ffap (see my emacswiki page) does 80-90% of what I need on a daily basis.

I was in the 80% case when I wrote vlad. cap does NOT work fine. It is a steaming pile of intertwined crap... imhfo.

We got the 80% usage case of vlad covered in about a 3rd() of the code that cap required.

) actually π. In the release notes for vlad 1.1: "The flog ratio between capistrano+deps / vlad+deps is pi (or, damn close)!". Line numbers correlated fairly close iirc.

yes... and they're great. Esp for situations like the OP was describing. Fire off a ton of incredibly lightweight threads and they'll quietly sit waiting for IO... perfect.

they certainly didn't work fine when I tried to use them... after they'd gone into production releases of perl, the canonical demo/example scripts that were out there all crashed the perl runtime in a fiery horrible death.

I can only hope that it has improved since then, but I've moved on to greener pastures.

Just to add to the blog post a bit:

those flog scores interpretation are ONLY valid if you use them on a per-method basis... on a per-file or per-project level they're completely invalid.

For example:

    % pwd; flog -n -m lib | head
    /Users/ryan/Work/p4/zss/src/ruby_parser/dev/

    Total Flog = 5284.4 (12.2 +/- 2852.7 flog / method)
    
    RubyLexer#yylex: (1076.9)
    RubyLexer#tokadd_string: (146.8)
    RubyLexer#read_escape: (130.5)
    RubyLexer#heredoc: (118.3)
    RubyLexer#heredoc_identifier: (89.6)
    RubyParser#literal_concat: (81.2)
    RubyParser#assignable: (65.2)
    RubyLexer#parse_quote: (63.4)

There is little I can do at this time to clean up the monstrous yylex, but tokadd_string, read_escape, and heredoc are all too big and need some attention to clean them up. Everything else is, relative to those scores, reasonable and can be ignored at this time.

I am still chuckling that he recommends capistrano right after pushing tools to fight complexity...

I'm much more familiar with threads in ruby. It would actually be a real boon to this project imo.

I don't have as much experience with python threads as I do ruby. I've toyed with the internals of python and perl as well and know perl to be a wasteland and python to be rather elegantly clean. So I would expect python's threads to be better implemented. Poking at it, it does appear to be so.

perl threading was (and I'm sure still is) absolutely horrid.

I'd be interested in seeing the results of a rewrite not to C, but to python or ruby where the threading support is much much better. Then you could rewrite functions at a time in C as needed, but not have the extra burden of rewriting the whole thing.

I totally agree with the rest of the approach. Going low tech and using unix tools is a very good way to reduce overhead, increase parallelism, and delay calculations. One of the nice things about this approach is you can cobble up another $50 unix box to do some of the bulk processing via nfs or other means.

Congrats... It sounds like a very interesting project.

I was going to say roughly the same thing as swombat... you need to distinguish more. In particular, you seem focused on the fact that your app stays in the background. OmniFocus does the same thing. I hit

It'd be nice if the graphs did more than just master. In particular, rubinius has a lot of activity going on in the 'cpp' branch and none of it is visualized anywhere that I can find.

gimmie! I'd love to see what you use...

both of these points make me sad.

assignment evaluation to RHS catches everyone once in a while. I'd have gone with the plain `squid` at the end. Maybe even with a `return` if I was feeling chatty. (It took me a long while to get over my anti-return-for-speed-reasons bias... I'm still working on it sometimes.)

Besides, I'm not that much younger than you. :P

I think it is mostly that you went the lispy route while I took the smalltalk route.

ETA:

actually... I'll go one step further...

`returning` violates "Do the Simplest Thing That Could Possibly Work" flat out without giving you anything in return.

  foo = returning(Object.new) do |f|
    def f.bar
      ...
    end
    def f.bash
      ...
    end
  end

  # vs

  foo = Object.new
  def foo.bar
    ...
  end
  def foo.bash
    ...
  end

1 line shorter, less indentation, more clear. What does returning get you besides another message send and block activation? I have yet to see a good use for it. (yes, I'm biased. calibrate accordingly)

Well, that's partially false. #to_proc is in 1.9.

I also completely and totally disagree that they're not clever. There is nothing _not_ clever about #returning. It is second only to using inject because you're too lazy to assign to a variable first. Nevermind that every railz0r that does that ignores the fact that they've now assigned N times instead of once.

Clever code, in my mind, is a form of hidden cost. It seems to be what I get paid to deal with (read: remove) the most.

"The most obvious example that comes to mind is an xterm window. Even on OSX any programmer will spend 2/3 of their time looking at text."

Isn't that an example of _good_ UI? Much like Pages does a good job of giving you a blank sheet of paper and not much else (initially), Terminal.app does a good job of giving you a command line and not much else (ever).