One-Click Installer: MinGW? or VC2005?

Ruby
141

Lothar S. [email protected] writes:

Smalltalk with it’s extreme syntax simplicity is also not a good
argument here.

There are very fast and efficient implementations of both, I don’t see
why they shouldn’t be able to parse Ruby as fast as Bison. In the
end, it’s just shuffling a few strings around and doing quick method
calls.

142

Christian N. wrote:

There are very fast and efficient implementations of both, I don’t see
why they shouldn’t be able to parse Ruby as fast as Bison. In the
end, it’s just shuffling a few strings around and doing quick method
calls.

I think there are large chunks of this available in various packages,
but there doesn’t seem to be a “project” with the specific goal of
creating an efficient Ruby compiler/interpreter in Ruby. It’s clearly
possible, but whether it’s worthy of scarce (volunteer) developer time
relative to all of the other Ruby projects is another question. Lisp was
around quite a while before it had a usable “compile to real machine
code” tool set.

143

On 7/22/06, Srinivas JONNALAGADDA [email protected] wrote:

I do not yet know how extconf.rb really works, but could an underlying
CMake make the job of extconf.rb easier?

Probably not. We don’t want to require a P-language to compile Ruby
extensions.

-austin

144

gregarican wrote:

Ruby will definitely run on the Zaurus. Last year I wrote a mobile CRM
app that used Ruby and Qt/Embedded bindings. It was a nice result.
Buying up a handful of refurb SL-5500’s on eBay I could deploy a
relatively sophisticated app on the cheap. But other handheld platforms
aren’t as easy. Newer Windows Mobile versions for example.

The Zaurus is nice, but in the Western world Sharp has abandoned it and
its essentially kaput.
Sharp hasn’t abandoned the Zaurus in the western world. They’ve simply
made a business decision to focus on what’s profitable. If someone
developed, say, a CRM application for the Zaurus 6000, got an attorney
and an accountant and made Sharp a credible business proposal, they
would probably at least listen to it. I’ve forgotten the web link, but
they do have a way of “adopting” projects like this.

If the majority of handheld devices in active
use are running Microsoft, Palm, and Symbian then not having Ruby
available for them is a downside for me. And I’m not advanced enough to
be able to port Ruby to these platforms myself :frowning:

I went poking around in the Ruby 1.8.5 pre something source last night
looking for something else and discovered that there are at least some
hooks for Windows CE. You need the SDK, of course, but it looks like at
least it’s possible to get Ruby up and running on a Microsoft handheld.
I’m not by any stretch of the imagination an embedded/handheld
developer; I’m more focused on the other end of the spectrum.

145

Curt H. wrote:

I agree that that this has been a very productive discussion thread,
and I’m
really looking forward to working with the Microsoft team to see what
can be
done. We can’t make a fully informed decision on this until we have
all the
facts in.
Is there a “MinGW team?”

146

M. Edward (Ed) Borasky wrote:

I went poking around in the Ruby 1.8.5 pre something source last night
looking for something else and discovered that there are at least some
hooks for Windows CE. You need the SDK, of course, but it looks like at
least it’s possible to get Ruby up and running on a Microsoft handheld.
I’m not by any stretch of the imagination an embedded/handheld
developer; I’m more focused on the other end of the spectrum.

True. There is a wince subdirectory in the Ruby source going back
awhile. There are even references to a pocketruby implementation
intended for such mobile platforms. But I think it went by the wayside
years ago. As far as I know versions of Microsoft mobile OS’es more
recent than Windows CE 3.0 are dicey at best for supporting Ruby. I
spent days trying to compile various Ruby versions from source to get
them running on Windows Mobile 5.0. Finally I gave up and went with
Python to get my mobile CRM app working on Windows Mobile PDA’s.

147

On 7/22/06, M. Edward (Ed) Borasky [email protected] wrote:

Curt H. wrote:

I agree that that this has been a very productive discussion thread,
and I’m
really looking forward to working with the Microsoft team to see what
can be
done. We can’t make a fully informed decision on this until we have
all the
facts in.
Is there a “MinGW team?”

I think the majority of the people on this thread are the MinGW team.

Curt

148

Hi,

At Sat, 22 Jul 2006 00:35:17 +0900,
[email protected] wrote in [ruby-core:08337]:

here’s an example showing the abis of the c libs are not compatible:

Ara@windozer C:/msys/1.0/home/Ara/build/narray-0.5.8
$ /c/ruby/bin/ruby -r ./narray.so -e’ p NArray ’
./narray.so: 127: The specified procedure (isacii) could not be found. - ./narray.so (LoadError)

Ara@windozer C:/msys/1.0/home/Ara/build/narray-0.5.8
$ /c/usr/local/bin/ruby -r ./narray.so -e’ p NArray ’
NArray

When did you try it? It should be fixed while ago.

| Tue Jun 27 16:04:05 2006 WATANABE Hirofumi
|
| * win32/win32.h: define isascii on MinGW for msvcrt compatibility.
|
| * configure.in: set ac_cv_header_sys_time_h=no on MinGW
| for msvcrt compatibility.

149

On Sun, 23 Jul 2006 [email protected] wrote:

| * configure.in: set ac_cv_header_sys_time_h=no on MinGW
| for msvcrt compatibility.

–
Nobu Nakada

this was a month or two ago. yeah, i know how to fix it, i fixed it
myself,
my concern is that it’s up to extension writers to shoehorn these fixes
into
there packages - this should be the responsibility of the c compiler/c
lib and
it’s subtle incompatibilities like these which make mixing vc++ and msys
binaries worrisome.

cheers.

-a

150

I would like to thank everyone who posted to this thread. You have
really
helped get all the issues laid out.

No decision is going to be made on this for at least a month, and
possibly
longer, as I really need to see what Microsoft is willing to do to help
mitigate the the issues that would otherwise push the decision towards
MinGW.

Curt

151

I also think that fixing the toolchain might help out more in the long
run
then changing the compiler. Most of the problems
mentioned seems to be that Windows doesn’t have the ./configure, make,
make
install tool chain.

Would it make sense to port the autotool tasks to ruby and get rid of
that
requirement.

If mkmf would be changed to generate a rakefile instead of a makefile
then
the requirement for make goes away.
(see http://rubyforge.org/projects/mkrf) which is a google SOC project

If we had a configure file parser that would generate a platform
dependent
rakefile or a extconf.rb file we could use ruby tools to compile the C
libraries also. (Sounds like a good Ruby Q. candidate)

152

Hi,

At Sat, 22 Jul 2006 03:52:17 +0900,
Lothar S. wrote in [ruby-talk:203182]:

Ruby still suffers in plattform independence because to much is done
on unix boxes and ignorance about windows issues among the developers
is high. The “win32.c” already has to much code that shows that people
don’t have any understanding about the windows plattform
(take “Kernel::system” for example).

Patches are always welcome. :slight_smile: