Jruby, after a long nap, is starting up development again. This
release offers a number of changes:
Interpreter now thinks it is a ruby 1.8 interpreter (though it still
sometimes behaves like a 1.6 interpreter)
Simplified build environment (now eclipse friendly) (Thanks to Joey Gibson)
Added functions Float,Integer,String,Array to Kernel module
Various fixes to Kernel, Array, Dir, File, and String
IO expanded support for
Random Access of files (seek, rewind,…)
File descriptors
reopen, dup
sysread, syswrite
many other IO fixes
Added FileTest
Backout of inneffective callindexed optimization
Able to run rubicon without hacking rubicon itself
many other changes…
Thanks to Jan Arne Petersen, Anders Bengtsson, Thomas E Enebo,
Benoit Cerrina. Joey Gibson, Hunter Kelly and Pergiuliani Bossi for
submitting fixes since the last release.
This version also boasts improved results in rubicon passing nearly
100 more tests which translates into about 800 more assertions. Here is
a test summary:
···
========================================================================
All Tests Test Results V0.3.5
Did you checkout rubicon from its new home on rubyforge? It’s been
updated quite a bit since the last version from the Ruby CVS
repository. We’ve moved it here temporarily to try to bring it update
to date with Ruby 1.8.* and Test::Unit. It’s in pretty good shape but
needs the kinks worked out on a variety of different platforms.
Anyone who cares to check it out from CVS and give it a go, please do
and send in your results.
On Mar 12, 2004, at 12:33 PM, Thomas E Enebo wrote:
This version also boasts improved results in rubicon passing nearly
100 more tests which translates into about 800 more assertions. Here
is
a test summary:
On Sat, 13 Mar 2004, gabriele renzi defenestrated me:
great to hear this!
There is a chance of ever see something like jrubyc to create jvm
bytecode from ruby sources?
There is a chance…Someone (Anders) had worked on this some time ago.
I am not sure how far he got, but he currently is not working on it
(as far as I know). Still, some ground work has been done towards
supporting it.
This version also boasts improved results in rubicon passing nearly
100 more tests which translates into about 800 more assertions. Here
is
a test summary:
Did you checkout rubicon from its new home on rubyforge? It’s been
updated quite a bit since the last version from the Ruby CVS
repository. We’ve moved it here temporarily to try to bring it update
to date with Ruby 1.8.* and Test::Unit. It’s in pretty good shape but
needs the kinks worked out on a variety of different platforms.
Anyone who cares to check it out from CVS and give it a go, please do
and send in your results.
Where should I send my results? I have some errors using ruby-1.9 from cvs, i.e.
in rubicon.rb VERSION constant is used, but in 1.9 it doesn’t exists.
not defined?(VERSION) and VERSION = RUBY_VERSION
fixes that, but not too clean though. So about my initial question, where should I send
all other errors I got from running ‘make test’?
···
On Saturday 13 March 2004 10:20, Chad Fowler wrote:
On Mar 12, 2004, at 12:33 PM, Thomas E Enebo wrote:
Chad
–
sdmitry -=- Dmitry V. Sabanin
MuraveyLabs.
Spam Here → postmaster@sco.com
The big news, of course, is that it includes binary builds for MS
Windows and Mac OS X Panther. I may add one or more Linux binaries
later, or they may have to wait for 0.3.
This is still an early beta release, so it still has a number of known
problems. If you find a problem that is not mentioned in the README or
in one of the rubyforge trackers, please let me know.
Thanks to everyone for your help with this, and especially to Curt and
Nick for building the binary packages.
You can either send them using the post.rb that is included with
Rubicon:
ruby AllTests.rb -op xml|ruby post.rb
or you can email them.
Thanks,
Chad
···
On Mar 13, 2004, at 2:57 AM, Dmitry V. Sabanin wrote:
On Saturday 13 March 2004 10:20, Chad Fowler wrote:
On Mar 12, 2004, at 12:33 PM, Thomas E Enebo wrote:
This version also boasts improved results in rubicon passing nearly
100 more tests which translates into about 800 more assertions. Here
is
a test summary:
Did you checkout rubicon from its new home on rubyforge? It’s been
updated quite a bit since the last version from the Ruby CVS
repository. We’ve moved it here temporarily to try to bring it update
to date with Ruby 1.8.* and Test::Unit. It’s in pretty good shape but
needs the kinks worked out on a variety of different platforms.
Anyone who cares to check it out from CVS and give it a go, please do
and send in your results.
Where should I send my results? I have some errors using ruby-1.9 from
cvs, i.e.
in rubicon.rb VERSION constant is used, but in 1.9 it doesn’t exists.
not defined?(VERSION) and VERSION = RUBY_VERSION
fixes that, but not too clean though. So about my initial question,
where should I send
all other errors I got from running ‘make test’?
Hi Kevin (and Curt). I happened to be watching my RSS inbox right as
you posted this last night, so I downloaded it (Mac OS) and gave it a
try. As you say in the release notes, it’s obviously still beta
quality, but I was very excited about what’s to come! Great work.
I’m looking forward to using this library more and more in the future.
The big news, of course, is that it includes binary builds for MS
Windows and Mac OS X Panther. I may add one or more Linux binaries
later, or they may have to wait for 0.3.
This is still an early beta release, so it still has a number of known
problems. If you find a problem that is not mentioned in the README or
in one of the rubyforge trackers, please let me know.
Thanks to everyone for your help with this, and especially to Curt and
Nick for building the binary packages.
The big news, of course, is that it includes binary builds for MS
Windows and Mac OS X Panther. I may add one or more Linux binaries
later, or they may have to wait for 0.3.
This is still an early beta release, so it still has a number of known
problems. If you find a problem that is not mentioned in the README or
in one of the rubyforge trackers, please let me know.
Thanks to everyone for your help with this, and especially to Curt and
Nick for building the binary packages.
The big news, of course, is that it includes binary builds for MS
Windows and Mac OS X Panther. I may add one or more Linux binaries
later, or they may have to wait for 0.3.
This is still an early beta release, so it still has a number of known
problems. If you find a problem that is not mentioned in the README or
in one of the rubyforge trackers, please let me know.
Thanks to everyone for your help with this, and especially to Curt and
Nick for building the binary packages.
Woo-hoo!
How easy is it to build GUI apps in Ruby/wxRuby for cross-platform use
on Windows, MacOSX, and Linux?
The big news, of course, is that it includes binary builds for MS
Windows and Mac OS X Panther. I may add one or more Linux binaries
later, or they may have to wait for 0.3.
This is still an early beta release, so it still has a number of known
problems. If you find a problem that is not mentioned in the README or
in one of the rubyforge trackers, please let me know.
Thanks to everyone for your help with this, and especially to Curt and
Nick for building the binary packages.
Woo-hoo!
How easy is it to build GUI apps in Ruby/wxRuby for cross-platform use
on Windows, MacOSX, and Linux?
Is this it? Or will it be, post-beta?
You can do this now. The wxRuby distribution comes with a about 20 sample
apps that run on all platforms. Kevin has written an email client (although
that is not part of the wxRuby distribution).
Curt
···
On Sat, 13 Mar 2004 15:04:40 +0900, “Curt Hibbs” curt@hibbs.com
very cool.
thanks for your work. let’s hope that it will be as successful as wxPython.
I hate to say it but, as long as we’re still using Ruby 1.x, it probably
won’t be. Sometimes we just need real/OS threads, which won’t be present
until Ruby2.
very cool.
thanks for your work. let’s hope that it will be as successful as wxPython.
I hate to say it but, as long as we’re still using Ruby 1.x, it probably
won’t be. Sometimes we just need real/OS threads, which won’t be present
until Ruby2.
I don’t know much about gui programming, and nothing about wxWidgets.
Could you explain why native threads are so important?
Quoteing lists@zara.6.isreserved.com, on Sun, Mar 14, 2004 at 11:10:19AM +0900:
Markus Jais wrote:
>very cool.
>thanks for your work. let's hope that it will be as successful as wxPython.
I hate to say it but, as long as we're still using Ruby 1.x, it probably
won't be. Sometimes we just need real/OS threads, which won't be present
until Ruby2.
I don't know much about gui programming, and nothing about wxWidgets.
Could you explain why native threads are so important?
They are important for programming but you are right, they are not
very important for GUI programming. Most GUI Toolkits are not really
multithread safe, some offer a few hooks, but they do this because
they don't support fibers (cooperative threads like ruby).
In fact a good event loop implementation can have the same performance
as python at the moment. But this would require that for example
even file operations are also implemented as async operations.
I doubt that there are so many reasons for native threads, most of
them are only necessary for native C extensions.
TCL has a good implementation of threads and the only useful
for a script language. They separate the "threads" memory space
and only do event passing with marshal/unmarshal data. But most people
don't call this a 'thread implementation'.
Smalltalk dialects got around native threads in their GUIs for a very
long time. But Smalltalk GUIs are completely written in Smalltalk
which has it’s own lightweight process model. Ruby uses GUI toolkits
written in C/C++. Those toolkits nearly always use nativ
multithreading, don’t they?
I don’t know much about gui programming, and nothing about wxWidgets.
Could you explain why native threads are so important?
They are important for programming but you are right, they are not
very important for GUI programming. Most GUI Toolkits are not really
multithread safe, some offer a few hooks, but they do this because
they don’t support fibers (cooperative threads like ruby).
Wednesday, March 17, 2004, 10:14:38 AM, you wrote:
> I don't know much about gui programming, and nothing about wxWidgets.
> Could you explain why native threads are so important?
They are important for programming but you are right, they are not
very important for GUI programming. Most GUI Toolkits are not really
multithread safe, some offer a few hooks, but they do this because
they don't support fibers (cooperative threads like ruby).
Smalltalk dialects got around native threads in their GUIs for a very
long time.
But now they must support it. There are to many important blocking
libraries they must use. Oracles DB driver has a non blocking
interface but AFAIK there is nothing for MySQL or Interbase
and i'm 100% that there is nothing like this for Sqllite.
But Smalltalk GUIs are completely written in Smalltalk
which has it's own lightweight process model. Ruby uses GUI toolkits
written in C/C++. Those toolkits nearly always use nativ
multithreading, don't they?
No, for example FOX is not multithreading safe. FLTK or TK have a
simple mutex for calling into the GUI code which 95% of all use cases
works, but not for the 5% of sophisticated ones.
But now they must support it. There are to many important blocking
libraries they must use. Oracles DB driver has a non blocking
interface but AFAIK there is nothing for MySQL or Interbase
and i’m 100% that there is nothing like this for Sqllite.
Ok, I start to see. Most of the demand that I’ve seen for “real”/os
native threads seemed to be based around the assumption that they
were in some way “better” than ruby’s threads, based around io
multiplexing. It wasn’t very convincing.
The Sqllite API is a lot more convincing! So, in summary,
native threads are useful for writing C extensions to:
blocking APIs, like you mention above
APIs that use threads as part of their interface – doesn’t gnome/gtk
make extensive use of threading?
With a blocking API, couldn’t you write an extension module that did
its work in a thread, notifying the main thread when the work was done?
With a blocking API, couldn't you write an extension module that did
its work in a thread, notifying the main thread when the work was done?
Sure you can do that, but often the synchronize overhead will be very high
and more important then that (we are still a script language, so highest
performance is not so important) is that it requires much more work
and a skilled developer. Most API's like the SQLite can't be wrapped
in an easy way. Every fetch of a row may block and take a long time -
for example 5 disk seeks can cost around 150 ms, so you would have to
write a sync handling for this on each call. But maybe the next rows
are already cached, then the synchronisation can add an overhead of
a few 100%. Most accesses are cached, so you have 3 alternatives:
a) non blocking slow API
b) blocking API
c) non natural and non blocking API
(for example a function that delivers rows in chunks of 50 or so)
I use GNU Eiffel on work and we have the same problem with it because
it neither supports user level threads nor native threads.
It's no problem to solve the problems, but it is not so much fun.
But now they must support it. There are to many important blocking
libraries they must use. Oracles DB driver has a non blocking
interface but AFAIK there is nothing for MySQL or Interbase
and i’m 100% that there is nothing like this for Sqllite.
Ok, I start to see. Most of the demand that I’ve seen for “real”/os
native threads seemed to be based around the assumption that they
were in some way “better” than ruby’s threads, based around io
multiplexing. It wasn’t very convincing.
The Sqllite API is a lot more convincing! So, in summary,
native threads are useful for writing C extensions to:
blocking APIs, like you mention above
APIs that use threads as part of their interface – doesn’t gnome/gtk
make extensive use of threading?
Also, don’t forget another benefit of OS/kernel threads: SMP.
Basically, threads are used for paralellism and only OS/kernel threads
provide true paralellism.
