I've applied the "block assignment" patch but still am having troubles getting webrick to boot. How would I go about troubleshooting this kind of thing?[21:36:37][~/Projects/rails/jrubyonrails]$ jruby script/server webrick
=> Booting WEBrick...org.jruby.parser.DefaultRubyParser.yyparse(DefaultRuby
Very, very cool. That was my understanding of sysread as well. I was confused, as you could imagine, why when I made the socket nonblocking there were no issues. Your explanation that Ruby wanted UP TO n bytes makes sense now; nonblocking allowed it to return just what it had available, and make it
Yep. I've tested this with net/http which was blocking forever before -- now it downloads as fast as it ought.
EvanOn 6/27/06, Evan Buswell <[EMAIL PROTECTED]> wrote:
Yeah, about 2 minutes after I sent that I realized that was your change and it had reason for being there. Sorry.
The problem is
Yeah, about 2 minutes after I sent that I realized that was your change and it had reason for being there. Sorry.
The problem isn't the blocking channel, its my sysread function.
Here's the deal: I was under the impression sysread(20) meant block
till you read 20, otherwise what distinguishes it
The CallNode error is because of the goofy block syntax. Apply docs/patches/rails/rails-whatever.patch to your gem-installed rails-1.1.2 dir and all will be right with the world.Maybe it would be worth asking on the rails mailing lists (perhaps on core) what would be the most "correct" way to distr
On Tue, 27 Jun 2006, Nick Sieger defenestrated me:
>
> config.frameworks -= [:active_record]
Cool idea.
> I just tried starting my now-modified app with jruby and got the following:
>
> [14:03:13][~/Projects/rails/jrubyonrails]$ ../../jruby/bin/jruby
> script/server webrick
> => Booting W
The Selectable nonblocking thing was my contribution to fix the fact that sockets were blocking by default. This caused a final read from the socket to block until Ruby's timeout.rb thread interrupted it, causing the gem exception that didn't seem to hurt anything. Setting the channel nonblocking f
I added some code into the "init.rb" file of my JDBC plugin to deal
with issues related to the fact that Rails wants to initialize the
database before the plugins. Additionally, the following line of code
will need to be added to config/environment.rb in your Rails
application (inside of the Rails
Patch is attached.
I noticed that code somehow crept in to set selectable channels
nonblocking by default (probably my fault). This may be part of
the problem with the exception being thrown at the end of the gem
download. This is also fixed in this patch.
The approach I took here is to have a
Sounds good on all points. We may or may not ship 0.9.0 with your updated patch (probably not) but we have seen no issues from my admittedly naive attempt. Get your patch over to us whenever you can, but don't worry about holding up the release.
On 6/27/06, Evan Buswell <[EMAIL PROTECTED]> wrote:
T
That's the problem. AFAIK, C select() on which Ruby's is based
makes no requirements about blocking/non-blocking, so this is only an
issue in Java, where if we are doing a select(), the socket must be
nonblocking, and if we set the socket blocking while in the middle of a
select, an exception is t
On 6/26/06, Charles O Nutter <[EMAIL PROTECTED]> wrote:
> As I understand it, the biggest issue with getting automatic JDBC database
> support in ActiveRecord is trying to figure out type mappings, yes?
Correct.
> - There ought to be a way to do a "best guess" mapping across the board
> based on
12 matches
Mail list logo
