I've made some more progress on getting ActiveRecord working with JDBC. I've got a script which successfully performs a create table migration followed by CRUD operations on an AR model sitting on top of that table. See attached
testConfidenceBuilder.rb for details of what's working.If anyone wa
Commited.
-Tom
On Sun, 02 Apr 2006, Ola Bini defenestrated me:
>
> The attached patch contains working implementations of Time._dump and
> Time._load, and a (very) small test case for this. It also contains
> updates to MarshalStream and UnmarshalStream so we can handle
> marshal_dump and mars
On Friday 07 April 2006 10:59 am, Ola Bini wrote:
> Hi
>
> Yes, that's actually a pretty good idea, to use it as a test case.
> Just try to scramble up a few K's or M's of data and run through it and see
> what happens.
>
> As for creating it all the time... Are we using Java regexps for this, btw?
On Friday 07 April 2006 10:55 am, Thomas E Enebo wrote:
> On Fri, 07 Apr 2006, Ola Bini defenestrated me:
> > Hi.
> >
> > Well, as you can see, this part has nothing to do with Syck either. It is
> > not the speed of YAML-parsing that's the issue (at least not yet... =),
> > but the speed of this p
This is good to hear. I applied a variant of your patch along with
some changes I made PLUS some changes Ola made right after the release
of 0.8.3. The result of those changes was enough to get open-uri and
net/http working. Well the simple examples given in the docs of those
modules.
The
The code consistently produces the said error for me provided I use
jruby-0.8.3 (compiled and run with sun-jdk-1.4.2_10), run just like "java
-jar jruby.jar -e ''".
I upgraded to the latest cvs and the problem seems to be already fixed, so
I guess we'll leave it at that.
Evan
Ola Bini wrote:
> .
... and again, at least when running your code in jirb, the call blocks
at read, as expected. I also made a script of this, and run it with
jruby, and it seems to block. which means I cannot reproduce this behaviour.
Regards
Ola Bini
- Original Message -
From: Evan <[EMAIL PROTECTED]>
Da
Hi.
I'm not really sure how to get your test case to work. I try it in
vanilla Ruby, and it hangs on the s.read(10)-line. (which it should,
since we have not sent something to google http to elicit an answer)
I guess the real question is: how do you get to the "Still haven't
crashed"-line at all?
I'm porting my socket+send/recv patch to work with jruby 0.8.3 but there
seems to be a bug in the vanilla jruby 0.8.3 socket implementation.
"read" (I haven't tried write...) returns something (instead of blocking)
which when accessed crashes the interpreter. Since the IO code seems to
have chang
Hi
Yes, that's actually a pretty good idea, to use it as a test case.
Just try to scramble up a few K's or M's of data and run through it and see
what happens.
As for creating it all the time... Are we using Java regexps for this, btw?
If we are, then it would make sense to compile a regexp t
On Fri, 07 Apr 2006, Ola Bini defenestrated me:
> Hi.
>
> Well, as you can see, this part has nothing to do with Syck either. It is
> not the speed of YAML-parsing that's the issue (at least not yet... =), but
> the speed of this particular
> code fragment.
Bummer, I was hoping the each in y
Hi.
Well, as you can see, this part has nothing to do with Syck either. It is
not the speed of YAML-parsing that's the issue (at least not yet... =), but
the speed of this particular
code fragment. And yes, I had the patience to let it work in about 25k
lines before it started to make my other
On Fri, 07 Apr 2006, Ola Bini defenestrated me:
> Hi.
>
> Here comes a patch and two new Java-classes which speeds up Zlib deflate
> and inflate to more or less C-Ruby-standards. Very nice.
>
> Status for RubyGems right now is that YAML.load(spec) seems to have
> problems with loading a spec i
I was going to ask if it was working on a zlib thing, but I can see it
is already inflated. Something tells me this could have been the motivation
for moving to Syck.
Have you put in prints or the like to make sure this thing is
not just looping over the same stuff endlessly? I am hoping
Hi.
The stopgap for RubyGems now seems to be this method, where it has spent
more cycles and hours than I care to count:
def reduce_spec(yaml_spec)
result = ""
state = :copy
x=0
yaml_spec.each do |line|
if state == :copy && line =~ /^\s+files:\s*$/
Hi.
Here comes a patch and two new Java-classes which speeds up Zlib deflate
and inflate to more or less C-Ruby-standards. Very nice.
Status for RubyGems right now is that YAML.load(spec) seems to have
problems with loading a spec in the size of 3megs. It fizzles for a few
hours and then goe
16 matches
Mail list logo
