You're sure to know more about it than I. The "one byte" thing makes sense also, since we do get a valid gem eventually...it's just that last read that ends up getting stuck.If there's a better way to do this, or an fcntl fix that needs to be made, I'm all for it. So far, however, this primitive fi
So we have something like:
class FlashHash < Hash
...
end
and if we do a Marshal.dump(FlashHash.new)
marshalStream ends up calling marshalTo on the object being
marshalled. In this case Hash has a marshalTo where the derived
class doesn't. So we dump it as a hash...
-Tom
On Fri, 16 Jun 2006,
Yeah, remember I emailed about this a while back. I had a marshalling fix that resolved this error, but there were others.The issue is that we don't properly marshal out the class if it's a simple extension of one of our core classes. We just marshall out that it's a Hash, rather than the actual ty
Well, look at that. I shall check later tonight.
/O
At 16:28 2006-06-16, you wrote:
> It appears that when we marshal the session it writes a FlashHash
>as a Hash, then on reread of session file it now thinks it is a Hash.
>A marshalling error? Perish the thought :)
>
>-Tom
>
>On Fri, 16 Jun 2
It appears that when we marshal the session it writes a FlashHash
as a Hash, then on reread of session file it now thinks it is a Hash.
A marshalling error? Perish the thought :)
-Tom
On Fri, 16 Jun 2006, Thomas E Enebo defenestrated me:
> It looks like somewhere @session['flash'] is gettin
It looks like somewhere @session['flash'] is getting set to a
regular hash. That is causing the error. FlashHash when explcitly set
then works...
-Tom
On Fri, 16 Jun 2006, Ola Bini defenestrated me:
> Wow, goodie!
>
> I checked that flash implementation, and it's really strange. I trried to
Wow, goodie!
I checked that flash implementation, and it's really strange. I trried to
extract it (just taking out FlashHash and FlashNow) and using it from irb
in regular C Ruby,
and both keep and sweep result in infinite recursion. I can't really
understand how it works in Rails..
/O
At 15:
HEH...Well that didn't take long. StringIO.sync= was expecting
the wrong type. Now the cool part. Cookbook is running using jdbc
and webrick! Well that is if I comment out flash.sweep in flash.rb
in actionpack. I will look at that next.
-Tom
On Fri, 16 Jun 2006, Thomas E Enebo defenestra
I added your two patches to the tree where I already have Ola's fixes.
I gave this a run against webrick running rails and we now get an
java exception versus a deadlock, so things look better. I am home sick
today so I will investigate. I will be applying Ola's patches today
and I can apply th
Ah, ouch. I'll take a look at it later. I saw it when I created the
original Zlib too. It's probably something small, though.
/O
At 09:36 2006-06-16, you wrote:
>Also FYI, with or without my NIO fix, I'm getting the following error
>while installing RubyGems:
>
> Successfully built RubyGem
>
Awesome! Really great!
This is starting to become _really_ fun! ... maybe it's time to do a hprof
on the RDoc stuff?
/O
At 09:29 2006-06-16, you wrote:
>So we all know our friend Ola has contributed some great pieces of work
>over the past several months. As another JRubyist put it, "Ola is a f
Also FYI, with or without my NIO fix, I'm getting the following error while installing RubyGems: Successfully built RubyGem Name: sources Version: 0.0.1 File: sources-0.0.1.gemhook /home/headius/rubygems-
0.8.11/./post-install.rb failed:java.io.EOFException: Unexpected end of ZLIB input streamP
FYI, I went ahead and committed the plaincharset.jar file, since the patch seems to have mangled it.On 6/16/06, Charles O Nutter <
[EMAIL PROTECTED]> wrote:So we all know our friend Ola has contributed some great pieces of work over the past several months. As another JRubyist put it, "Ola is a f'n
13 matches
Mail list logo
