ts not too many libraries and the fix looks easy, it might be worth
filing bugs with Ruby. Finding an include through manual file lookup
stuff seems like its pretty bad programming practice anyway.
Evan
Charles O Nutter wrote:
> Actually it's worth mentioning that if you don't need
pollThreadEvents could be cut down a little: it is currently being
called both by EvaluationState.executeNext() and
NewlineNodeVisitor.execute() -- meaning it is being called twice when
there is a newline.
Evan
Charles O Nutter wrote:
> I'm starting to run some profiles to find real
em. Rails checks the platform and opens the right file
accordingly, but we give it the "wrong" platform.
Couldn't this also make steps towards fixing the LF vs CRLF problem?
Evan
On 6/30/06, Thomas E Enebo <[EMAIL PROTECTED]> wrote:
On Fri, 30 Jun 2006, Thomas E Enebo defen
Oops, I think I entirely forgot -u in the last patch. I see you got it to work anyway, so I won't reattach.
If you're having trouble with other patches, I probably forgot to
remove excess garbage from "cvs diff -u" which seems to confuse patch
sometimes.
Apologies,
Evan
O
ECTED]> wrote:
http://jruby.codehaus.org/There's
a confluence out there for it, and I think Tom is looking into getting
JIRA up. We're mostly focused on the release at the moment, but we're
on Codehaus immediately after the release.
On 6/28/06, Nick Sieger <
[EMAIL PROTECTED
I've noticed my patch for getting Base64 decoding working right hasn't
made it into cvs. Obviously there's other priorities for
0.9, but I can't go back to using the head until Base64 decoding is
fixed.
Patch is attached again just in case.
Sorry to be a squeaky wheel ;-)
E
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.
. I think we're pretty well set for 0.9.0, but if this
is not too complicated and accomplishes what my nonblocking hack did,
we may include it.
Thanks for the quick turnaround.On 6/27/06, Evan Buswell <
[EMAIL PROTECTED]> wrote:
Patch is attached.
I noticed that code somehow crept in
ck when I know
something could theoretically blow up...
Evan
On 6/27/06, Charles O Nutter <[EMAIL PROTECTED]> wrote:
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 ov
just spin (this could maybe account for
the 99% CPU that someone was mentioning?).
I'm going to try and write a patch that will configure non-blocking and
avoid these issues. Hopefully I'll have it later today.
Evan
On 6/16/06, Charles O Nutter <[EMAIL PROTECTED]> wrote:
Do whate
gain there might.
Evan
Ola Bini wrote:
> Hi
>
> I've managed to fix a working fcntl implementation that sets
> nonblocking io when asked to. Patch is attached.
> This makes a simple daytime server work flawlessly.
>
> When I scale this up and try something like this:
>
>
If the call is read() (gets(), etc) rather than sysread() or recv(),
then we are reading in up to 4k bytes at a time and buffering it.
Evan
Thomas E Enebo wrote:
> On Tue, 06 Jun 2006, Thomas E Enebo defenestrated me:
>
>> On Tue, 06 Jun 2006, Ola Bini defenestrated me:
>>
would avoid.
Evan
Charles O Nutter wrote:
> Blast, forgot the patch.
>
> On 6/4/06, *Charles O Nutter* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> ObjectSpace is slow.
>
> I'm optimizing RubyString and seeing again and again how
blip?
Evan
Ola Bini wrote:
> Hi again.
>
> It seems that the remote fetching of RubyGems should be a good test case
> for the new IO handlers. With the old stuff I actually managed to
> download the Gem source index, but no luck so far with the new things:
>
> After trying T
I think this patch should fix the buffering problem. Turns out C Ruby
doesn't tag an io stream as buffered until a *read* buffering operation
happens; I was tagging it for *write* as well.
Let me know if it works.
Evan
Thomas E Enebo wrote:
> A simple hack which may or may not wo
hatever IO operation happens
immediately before the syswrite().
Evan
Thomas E Enebo wrote:
> A simple hack which may or may not work is to remove the
> checkBuffered() call from sysread in IOHandlerNio.java. If things
> work with that commented out then we can work from that.
>
>
ning this w/o serialize gives:
Thread 1: 1
Thread 2: 1
Thread 1: 2
Thread 2: 2
As expected, but when this is serialized, I get:
Thread 1: 1
Thread 2: 1
[sleeping]
Thread 2: 2
It looks as if serialized code implies single-threading, is this by
de
Array#unpack w/ "m" had a bug where only multiples of three characters
would be decoded. Try:
puts ["123"].pack("m").unpack("m").inspect
and it works, but
puts ["12"].pack("m").unpack("m").inspect
throws an error.
The attached patch fixes this.
unpack.patch
Description: Binary data
e the possibility of further
collision. This makes the Java object act less like a Ruby object, but
there's nothing all that unexpected about that.
Evan
Charles O Nutter wrote:
> This is definitely a tricky one. In the java world we don't have to
> worry about constructors colliding wit
Thanks!
Well, I imlemented select() first and read this second. But it feels good
to not find anything contradictory there, anyhow. JRuby doesn't have to
do poll() (right?) so the approach is slighty different anyway.
Evan
Adam Ritter wrote:
> Hi!
> I just found this site and tho
d / recv code I wrote, as well as providing trivial support for
UDPSocket and SSLSocket (based on java.net.ssl...)
Evan
Thomas E Enebo wrote:
> I will take a look this weekend. Anything which gets us closer is
> a great thing. When I examined sockets last, it seemed there would need
>
ct different behaviour. I don't know of any major ruby program or
library which uses them.
Socket.new
Socket.open
Socket#connect
Socket#bind
Socket#listen
Socket#accept
Socket#sysaccept
Socket#recvfrom
And then of course, there's the stickiest: Kernel#select
Anyway, have fun!
Evan
socket.patch
Description: Binary data
d a way to keep the semantics of Ruby threads while going totally
native, this seems like it would provide a better upgrade path.
///End random brain dump
Any update on getting my patch included?
Evan
Charles O Nutter wrote:
> The granularity of thread events is still up for debate. Every newline
make
hrown only once, we just need it not to be thrown
at every instruction. I think...
Evan
P.S. I noticed pollThreadEvents happens *both* at every execute *and* at
every newline. Shouldn't it be at one or the other? (My votes go to
every execute).
Charles O Nutter wrote:
> Perhaps it
e.
I'll be gone for a week so I won't be getting a chance to try this out for
awhile. If anyone else takes it on, great, otherwise this is my top
priority come Monday.
Evan
Evan wrote:
> Am I crazy, or does JRuby's implementation kill a thread w/o running any
> ensure blocks
lready had thoughts about how this
*should* happen?
Evan
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime devel
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 th
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
it and I won't send another patch in 5 minutes...
Evan
jruby-0.8.2-send-recv-0.1.patch
Description: Binary data
y for me.
I tested this by building a simple smtp server which works in jruby and
ruby unaltered. I didn't run any of the unit tests you guys have as
funcSocket.rb (or whatever it's called) bailed on vanilla JRuby 0.8.2. Of
course it didn't work on my modified jruby either ;-)
ar its not something more fundamental in the JRuby interpreter.
Hopefully I can knock this out pretty quickly.
Evan
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobil
s. Its technically a Ruby Extension, I know, but its something most
users will expect will work unless you specify otherwise.
Thanks a lot,
Evan
P.S. I'm new to this list and the sourceforge mailing list interface
sucks, so forgive me if this has already been discussed.
--
32 matches
Mail list logo
