Help (ruby-talk ML)


(Benjamin Peterson) #1

<… bits about i18n and text processing snipped …>

I will take your word for it that these are
significant roadblocks for
you and others. I typically deal with English (ASCII)
text exclusively
and so it hasn’t been an issue for me – yet.

I accept that Ruby’s linguistic limitations are not a
problem for a majority of users. But then, people who
might get text from any old country can’t be
users…

Just curious, what would be the significance
(benefit) of having an
ActiveState Windows distribution versus some other
Windows distribution?

There is no particular magic virtue in the name
’ActiveState’, but there were two things needed that
ActiveState could have provided:

Resources: The boost ActiveState gave to Perl was
considerable – a serious amount of resources were
added to the Perl project, leaving Perl’s core people
free to work on the language secure in the knowledge
that the Windows hordes would be able to use it all
right out of the box. The Pragmatic Programmers have
done a great job, but they have nothing like the
resources to spend on this that ActiveState gave to
Perl.

Enough clout to make their distro the standard: Most
people search for ‘ruby windows binary’ and come up
with all sorts of horrible things. The PragProg
distro may be the best Windows distro, (though
ActiveScriptRuby is important), but it is only one of
four links to win32 Ruby distros on the
ruby-lang.org download page. It feels futile to try
and add windows-specific functions when there are so
many competing distros many of which will never
incorporate any new functionality. With ActiveState
Perl, though, it was possible to add lots of goodies,
because you could pretty well assume the users would
have them in their distro.

The most recent Ruby installer for Windows (from Andy
Hunt) included
Ruby/DBI, DBD/ODBC, DBD/Postgres, DBD/MySQL and
DBD/Oracle.

So it does. A thank you to Andy Hunt and a slap on
the wrist to myself.

But for things that do depend on
modifications to the core it would be nice to have
some more concrete
plans to work with.

You accidentally pasted the words ‘more concrete’ into
your mail :slight_smile:

You are right when you say that many of the features I
mentioned are not critical for the majority of users
(we’ll never have threads and I can live with that).
However, the problem I hoped to draw attention to was
not the absence/desirability/necessity of particular
features, so much as the need, if Ruby is to grow and
spread any further, to move to a more open model of
software development.

x


(Dave Thomas) #2

Benjamin Peterson bjsp123@yahoo.com writes:

Enough clout to make their distro the standard: Most people search
for ‘ruby windows binary’ and come up with all sorts of horrible
things. The PragProg distro may be the best Windows distro,
(though ActiveScriptRuby is important), but it is only one of four
links to win32 Ruby distros on the ruby-lang.org download page. It
feels futile to try and add windows-specific functions when there
are so many competing distros many of which will never incorporate
any new functionality. With ActiveState Perl, though, it was
possible to add lots of goodies, because you could pretty well
assume the users would have them in their distro.

Which raises a question.

How can we open up the process so that the community can get involved
in the generation of the windows distribution? If we moved it to
(say) SourceForge would other folks be interested in helping out?

Cheers

Dave


(Bob Calco) #3

Yes, I would gladly volunteer considerable effort to this end. I have
considerable Windows System level programming that I’d like to contribute
to, particularly, the multithreading issues noted elsewhere as a weakness in
the distribution.

– Bob Calco

···

-----Original Message-----
From: dave@thomases.com [mailto:dave@thomases.com]On Behalf Of Dave
Thomas
Sent: Thursday, June 27, 2002 12:22 PM
To: ruby-talk ML
Cc: Andy Hunt
Subject: Re: help (ruby-talk ML)

Benjamin Peterson bjsp123@yahoo.com writes:

Enough clout to make their distro the standard: Most people search
for ‘ruby windows binary’ and come up with all sorts of horrible
things. The PragProg distro may be the best Windows distro,
(though ActiveScriptRuby is important), but it is only one of four
links to win32 Ruby distros on the ruby-lang.org download page. It
feels futile to try and add windows-specific functions when there
are so many competing distros many of which will never incorporate
any new functionality. With ActiveState Perl, though, it was
possible to add lots of goodies, because you could pretty well
assume the users would have them in their distro.

Which raises a question.

How can we open up the process so that the community can get involved
in the generation of the windows distribution? If we moved it to
(say) SourceForge would other folks be interested in helping out?

Cheers

Dave


(Dave Thomas) #4

Bob Calco robert.calco@verizon.net writes:

Yes, I would gladly volunteer considerable effort to this end. I
have considerable Windows System level programming that I’d like to
contribute to, particularly, the multithreading issues noted
elsewhere as a weakness in the distribution.

That’s great. In fact, changes to the basic Ruby interpreter and
runtime don’t need a project on SF: all you have to do is check out
the source code from ruby-lang and set to it. I’m sure that Matz will
be happy to accept patches, and will likely make folks who produce
good work committers in the tree.

If you do do work n this area, I’d encourage you to update the rubicon
tests accordingly: Chad Fowler (among others) spent some time getting
the tests more stable under Windows, so we can now start using
them. If there’s a feature that’s broken that isn’t in the tests,
write a test that fails, then fix the interpreter and watch the test
pass. If there are tests that are currently not run on Windows because
of compatibility problems, let’s make them run.

I’d love to see a couple of Window’s efforts get started in earnest:
one to beef up Windows support in the interpreter and its libraries,
and the other to have the community work towards building a standard
Windows distribution that we can all agree on. Pragmatic Programmers
may not have the resources of ActiveState, but as a community we have
considerably more. It just needs coordinating.

Cheers (and thanks)

Dave


(Lyle Johnson) #5

“Dave Thomas” Dave@pragmaticprogrammer.com wrote in message
news:m21yas3bdf.fsf@zip.local.thomases.com

That’s great. In fact, changes to the basic Ruby interpreter and
runtime don’t need a project on SF: all you have to do is check out
the source code from ruby-lang and set to it. I’m sure that Matz will
be happy to accept patches, and will likely make folks who produce
good work committers in the tree.

At last year’s RubyConf, in the sort-of “round-table” discussion at the end,
someone asked a question along the lines: if Matz himself isn’t especially
interested in improving the Ruby core support for Windows, would he at least
allow interested members of the Ruby community to make improvements to the
core? The question was met with what was, at best, a “lukewarm” response,
which I took at the time to mean he really didn’t want anyone soiling Ruby
with Windows-related code. But over the past year I’ve come to realize that
it was probably just Matz being quiet and mysterious :wink:

I guess the question (which has come up before) is what really needs to be
"fixed" in the Ruby core for Windows. I’m all for new and improved extension
modules that make Ruby-on-Windows more powerful, but by definition those
don’t require modifications to the core. The only problem that immediately
comes to mind is the “quirky” behavior of Ruby threads on Windows, and I’m
not sure that anyone’s nailed that one down conclusively.

I’d love to see a couple of Windows efforts get started in earnest:
one to beef up Windows support in the interpreter and its libraries,
and the other to have the community work towards building a standard
Windows distribution that we can all agree on. Pragmatic Programmers
may not have the resources of ActiveState, but as a community we have
considerably more. It just needs coordinating.

See previous question about what “beefing up” Windows support in the
interpreter and its libraries entails. Or maybe we both have the same
question :wink: And I definitely agree about farming out more of the work on
building a Windows distribution. I for one will be glad to “adopt” some of
the popular extensions and make sure that Windows binaries are available.
Seems like we just need a central repository for such things.


(Dave Thomas) #6

“Lyle Johnson” jlj@cfdrc.com writes:

I guess the question (which has come up before) is what really needs to be
"fixed" in the Ruby core for Windows. I’m all for new and improved extension
modules that make Ruby-on-Windows more powerful, but by definition those
don’t require modifications to the core. The only problem that immediately
comes to mind is the “quirky” behavior of Ruby threads on Windows, and I’m
not sure that anyone’s nailed that one down conclusively.

Threading is the big one. Then there’s also the strange subprocess
handling: last time I tried it, accessing $? after calling system()
threw an exception, for example. Handling of built-in commands also
used to be problematic.

I also see problems with the networking code: webrick keeps crashing
for me under windows.

In general, Ruby under Windows is not as stable or as reliable as
under Unix. If someone were to take charge, they could work on
building the bug list.

I’d love to see a couple of Windows efforts get started in earnest:
one to beef up Windows support in the interpreter and its libraries,
and the other to have the community work towards building a standard
Windows distribution that we can all agree on. Pragmatic Programmers
may not have the resources of ActiveState, but as a community we have
considerably more. It just needs coordinating.

See previous question about what “beefing up” Windows support in the
interpreter and its libraries entails. Or maybe we both have the same
question :wink: And I definitely agree about farming out more of the work on
building a Windows distribution. I for one will be glad to “adopt” some of
the popular extensions and make sure that Windows binaries are available.
Seems like we just need a central repository for such things.

Andy’s building a metadata system which lets him build new releases
declaratively. He’s currently plagued by incompatibilities between all
the different installation mechanisms and requirements that folks
use. If we could get the windows distribution train rolling, perhaps
we could also use it as a bully pulpit to bring some standardization
here too.

My ideal would be to have a community project to get Ruby support
under Windows as solid as Perl’s. That means fixing stuff in the
interpreter and libraries (and, as importantly) showing a commitment
to fixing stuff in the Windows environment. Second, I’d like to see
the community come to consensus on a Windows distribution (possibly
via a SF project to set up the distribution builder). Once that’s
there, it would be nice to have a system that could generate these
distributions (say daily), so we no longer had to wait for Andy to get
a spare evening to do it. Perhaps SF could do this for us too: I
haven’t investigated their build system.

Cheers

Dave


(Yukihiro Matsumoto) #7

Hi,

···

In message “Re: help (ruby-talk ML)” on 02/06/28, “Lyle Johnson” jlj@cfdrc.com writes:

At last year’s RubyConf, in the sort-of “round-table” discussion at the end,
someone asked a question along the lines: if Matz himself isn’t especially
interested in improving the Ruby core support for Windows, would he at least
allow interested members of the Ruby community to make improvements to the
core? The question was met with what was, at best, a “lukewarm” response,
which I took at the time to mean he really didn’t want anyone soiling Ruby
with Windows-related code. But over the past year I’ve come to realize that
it was probably just Matz being quiet and mysterious :wink:

Was I? :wink:

As you know, I myself is not interested in the Windows support, but
I’ve already allowed Windows improvement, and even assigned a few guys
for Windows support. All we need are bug reports, proposals, ideas,
and especially patches.

						matz.

(Curt Hibbs) #8

Dave Thomas wrote:

Threading is the big one. Then there’s also the strange subprocess
handling: last time I tried it, accessing $? after calling system()
threw an exception, for example. Handling of built-in commands also
used to be problematic.

I am going to try to figure out the threading problem, out of necessity –
as it is holding up the development of FreeRIDE.

If anyone has already spent any time investigating this, I would appreciate
any information that you could pass on to speed up my efforts.

Curt


(Serg Koren) #9

Hi

Is there an accepted way of handling timed interval events? I’d like to
process some code every 30 seconds. I can’t seem to find any timer or
interval classes in Ruby’s library.

Thanks for any hints or code snippets.
S


(HAL 9000) #10

“Lyle Johnson” jlj@cfdrc.com writes:

I guess the question (which has come up before) is what really needs to
be

“fixed” in the Ruby core for Windows. I’m all for new and improved
extension

modules that make Ruby-on-Windows more powerful, but by definition those
don’t require modifications to the core. The only problem that
immediately

comes to mind is the “quirky” behavior of Ruby threads on Windows, and
I’m

not sure that anyone’s nailed that one down conclusively.

Threading is the big one. Then there’s also the strange subprocess
handling: last time I tried it, accessing $? after calling system()
threw an exception, for example. Handling of built-in commands also
used to be problematic.

I also see problems with the networking code: webrick keeps crashing
for me under windows.

In general, Ruby under Windows is not as stable or as reliable as
under Unix. If someone were to take charge, they could work on
building the bug list.

FWIW, I’ve seen these problems also:

  1. Tried to run something and got a NotImplemented exception saying
    that fork() was not implemented on this platform. (!) This was
    probably the first time I’d tried to do a fork on Windows using the
    non-Cygwin Ruby. We’ve also lost popen, haven’t we?

  2. No matter the version of Ruby (on Windows) I see it hang from
    time to time (on exit). This is chiefly (only?) when doing GUI work
    – Tk or FXRuby, doesn’t matter (GTK? Can’t recall). My workaround is:
    a. kill the DOS window;
    b. hit YES, I really want to kill it;
    c. Ctl-alt-del, scroll down to Winoldap; hit End Task
    d. Wait a few seconds, get a dialog saying the task is unwell
    e. Hit End Task
    f. Open a new DOS window

Not to [re]open a can of worms, but exactly why did we move away
from the Cygwin version? I realize we have reduced dependence on
an outside entity, but have we broken more than we fixed? Did the
threading problem happen on the Cygwin Ruby?

On a related note: Are there instructions for building Ruby on
Windows? I never got it to work with djgpp. I’d be willing to
try it with VC++, but I’d like to see at least minimal docs
first. Maybe they’re there and I just haven’t noticed them.

And another thought: How well does Rubicon work on Windows? The
last time I tried it, there were some (fixable) problems. This
tool is IMO too important to be just the plaything of its creator
(Dave?) – I think the community should get behind it, on every
platform.

Enough rambling from me.

Cheers,
Hal Fulton

···

----- Original Message -----
From: “Dave Thomas” Dave@PragmaticProgrammer.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, June 27, 2002 1:14 PM
Subject: Re: help (ruby-talk ML)


(Tobi Reif) #11

Dave Thomas wrote:

Threading is the big one. Then there’s also the strange subprocess
handling: last time I tried it, accessing $? after calling system()
threw an exception, for example. Handling of built-in commands also
used to be problematic.

I also see problems with the networking code: webrick keeps crashing
for me under windows.

In general, Ruby under Windows is not as stable or as reliable as
under Unix. If someone were to take charge, they could work on
building the bug list.

All this brainstorming and coordinating of efforts feels like a breeze
of fresh air. Although I’m currently moving away from Windows, I’m happy
to see people starting to make Ruby go more places, in a better way.

My ideal would be to have a community project to get Ruby support
under Windows as solid as Perl’s.

I think you all can do it :slight_smile:

Tobi

···


http://www.pinkjuice.com/


(Tobi Reif) #12

Yukihiro Matsumoto wrote:

I’ve already allowed Windows improvement, and even assigned a few guys
for Windows support.

Awesome :slight_smile:

All we need are bug reports, proposals, ideas,
and especially patches.

There’s a lot of these (except patches) in the ruby-talk archive.

In addition, perhaps some tiny bugtracking system might help (eg sf).

Tobi

···


http://www.pinkjuice.com/


(Lyle Johnson) #13

“Serg Koren” Serg@VisualNewt.com wrote in message
news:B9413D30.62E9%Serg@VisualNewt.com…

Hi

Is there an accepted way of handling timed interval events? I’d like to
process some code every 30 seconds. I can’t seem to find any timer or
interval classes in Ruby’s library.

I’ll bet there’s a better way, but what about creating a thread that sleeps
thirty seconds in between doing its thing?

th = Thread.new do
  loop do
    puts "I just did something, going back to sleep now!"
    sleep(5)
  end
end

HTH,

Lyle


(Lyle Johnson) #14

“Serg Koren” Serg@VisualNewt.com wrote in message
news:B9413D30.62E9%Serg@VisualNewt.com…

Hi

Is there an accepted way of handling timed interval events? I’d like to
process some code every 30 seconds. I can’t seem to find any timer or
interval classes in Ruby’s library.

I’ll bet there’s a better way, but what about creating a thread that sleeps
thirty seconds in between doing its thing?

th = Thread.new do
  loop do
    puts "I just did something, going back to sleep now!"
    sleep(30)
  end
end

HTH,

Lyle


(Dave Thomas) #15

“Hal E. Fulton” hal9000@hypermetrics.com writes:

On a related note: Are there instructions for building Ruby on
Windows? I never got it to work with djgpp. I’d be willing to
try it with VC++, but I’d like to see at least minimal docs
first. Maybe they’re there and I just haven’t noticed them.

In the win32 subdirectory.

And another thought: How well does Rubicon work on Windows? The
last time I tried it, there were some (fixable) problems. This
tool is IMO too important to be just the plaything of its creator
(Dave?) – I think the community should get behind it, on every
platform.

Pretty well. Chad and I spent a long time on it a couple of months
ago, and it’s getting there. The real problem we bumped in to was
deciding was something not working a bug, or something that wasn’t
supposed to work. If you check out a recent Rubicon from ruby-lang
you’ll see all sorts of conditional stuff to make the tests run better
under Windows.

My ideal would be to have 90% of that conditional logic REMOVED by the
year’s end.

Enough rambling from me.

And me

Dave


(Albert) #16
> Not to [re]open a can of worms, but exactly why did we move away > from the Cygwin version? I realize we have reduced dependence on > an outside entity, but have we broken more than we fixed?

There is more in the can than worms :slight_smile: Windows users voted on it.

···

On Thursday 27 June 2002 10:39 pm, Hal E. Fulton wrote:

Cheers,
Hal Fulton


(Austin Ziegler) #17

I’ll gladly volunteer the use of HaloStatue.ca as a bug tracking for
Ruby/Windows if that’s desired. I’m the maintainer of an
(IM-not-at-all-H-O) very nice bug tracking system
(http://www.halostatue.ca/Corporate/products/bugtraction.html). As
soon as I feel more comfortable with Ruby, I’ll be translating it
from Perl to Ruby, so it’ll be a very nice Ruby-based bug tracking
system.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.06.28 at 17.02.25

···

On Sat, 29 Jun 2002 05:05:19 +0900, Tobias Reif wrote:

In addition, perhaps some tiny bugtracking system might help (eg
sf).


(Yukihiro Matsumoto) #18

Hi,

There’s a lot of these (except patches) in the ruby-talk archive.

Remaining

In addition, perhaps some tiny bugtracking system might help (eg sf).

Why not http://wwww.ruby-lang.org/cgi-bin/ruby-bugs ?

						matz.
···

In message “Re: help (ruby-talk ML)” on 02/06/29, Tobias Reif tobiasreif@pinkjuice.com writes:


(Yukihiro Matsumoto) #19

Hi,

···

In message “Re: help (ruby-talk ML)” on 02/06/29, Austin Ziegler austin@halostatue.ca writes:

I’ll gladly volunteer the use of HaloStatue.ca as a bug tracking for
Ruby/Windows if that’s desired. I’m the maintainer of an
(IM-not-at-all-H-O) very nice bug tracking system
(http://www.halostatue.ca/Corporate/products/bugtraction.html). As
soon as I feel more comfortable with Ruby, I’ll be translating it
from Perl to Ruby, so it’ll be a very nice Ruby-based bug tracking
system.

If there’s a better bugtracking than jitterbug, I’d be glad to move.

						matz.

(James) #20

Why not http://wwww.ruby-lang.org/cgi-bin/ruby-bugs ?

Um, because it gives this?

Error 500: Internal Server Error

Works better with one less ‘w’

http://www.ruby-lang.org/cgi-bin/ruby-bugs ?

:wink:

James

···
  					matz.