On Sat, 2006-07-22 at 00:39 +0900, Austin Z. wrote:
To put
it another way, I don’t want to add MinGW or any other compiler to the
already heavy RubyForge download stream.
2 TB a month and rising…
Tom
On Sat, Jul 22, 2006 at 12:09:53AM +0900, Austin Z. wrote:
On 7/18/06, [email protected] [email protected] wrote:
the caveat, however, is whether mingw can cut the mustard. i’ve not heard
any
reason why it couldn’t - but i am simply not experience enough on windoze
to
know for sure.It can’t. It uses an older Win32 API and still doesn’t use the most
recent GCC and appears to be very slow on updating. MinGW appears to
compile significantly slower code than VC++ does, as well.
Not beeing on the bleeding edge of gcc development is a boon rather
than a detriment. Red Hat had to learn this painfully once. What
version is mingw based upon now?
I can’t comment much on the Win32 API and speed issues, but many of
the current problems seem to be derived from having many incompatible
and instable solutions. A small constant factor in speed may be
acceptable over the current mess.
If I’d use Win32 enough to care for it, I’d vote MinGW just because I
know the community will (and can) solve any outstanding problems once
a decision is made for it. On the other hand, it’ll be much harder to
influence VC development.
-Jürgen
On Sat, 2006-07-22 at 08:11 +0900, Austin Z. wrote:
check and I’ll verify.
Great! I’ll do that… and thanks for hosting a mirror!
Yours,
Tom
On 7/21/06, Tom C. [email protected] wrote:
On Sat, 2006-07-22 at 00:39 +0900, Austin Z. wrote:
To put
it another way, I don’t want to add MinGW or any other compiler to the
already heavy RubyForge download stream.
2 TB a month and rising…
Yeah. BTW, Tom, I need to check with my hosting provider, but it looks
like my share of the load may be able to increase a bit, although my
mechanism is still (unfortunately) ass-backwards. Ping me in August to
check and I’ll verify.
-austin
I have written a fair number of C extensions and for me it comes down
to the following:
MinGW Pro:
Much easier to build Linux/Unix libraries due to the complete tool
chain (autoconf, etc)
MinGW Con:
Uses an older buggy CRT
Questionable licensing issues
VC 2005 Pro:
Should be better optimized and tuned for the windows environment (not
saying it is, but generally vendor tool chains perform better than
gcc).
Better exposure to OS API’s
VC 2005 Con:
Much harder to build many Linux/Unix libraries
I love Ruby and will use it under Linux and Win32 regardless of the
final decision that is made. I would say that if Microsoft was willing
to provide some tools or bounties on a tool chain that would allow
people using their OS to make better use of more Open Source libraries
(autoconf, bash, etc) - with their compiler at the core that would
probably be best - and while I am dreaming how do they feel about
providing a Unix like fork API .
Without that tool chain I think both sides of the debate have more or
less equal arguments and it really comes down the developers needs
(Unix tools vs tighter OS integration).
My opinion for what it is worth (not much 
pth
Lothar S. wrote:
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).
I agree with this assertion. In my world I prefer to use Ruby for most
tasks that I take up. But the handful of times I specifically abandon
Ruby for Python is solely due to the fact that my ActiveState Python
install under Windows doesn’t hold me back from installing add-on
libraries. So if I can’t get something to work under Ruby in Windows
then I just grab the equivalent Python libraries and use Python
instead.
It’s usually as simple as running ‘python setup.py’ from the command
line or even executing an prepacked installation that does the job. No
tooling around with editing makefiles, tweaking the mkmf.rb, setup.rb,
install.rb, etc. as in the case with certain Ruby libraries. As a
language I don’t prefer Python but I am familiar enough with it to do
what needs to be done. But while I’m doing it I lament the fact that
I’d rather be doing it in Ruby.
While there is a long thread debating Ruby interpreter performance, to
me the main things I see that perhaps are major drawbacks to Ruby truly
hitting the “big time” are:
-
Obvious lean toward Unix platforms and lack to true cross platform
compatibility in the Windows world. -
Lack of well documented add-on libraries in certain cases. If you
comment your code well enough and syntactically correct enough just run
RDoc and include this in your package download. -
Need for targeting embedded devices. From cell phones to PDA’s to
smartphones there are lots of cutting edge projects which Ruby could
help expose how truly easy and fun programming them could be. But it
doesn’t seem as if there’s an overwhelming acknowledgement of this in
the Ruby community as a whole.
A little OT from the subject of mingw versus msvc, but my $0.02
nonetheless.
gregarican wrote:
- Need for targeting embedded devices. From cell phones to PDA’s to
smartphones there are lots of cutting edge projects which Ruby could
help expose how truly easy and fun programming them could be. But it
doesn’t seem as if there’s an overwhelming acknowledgement of this in
the Ruby community as a whole.
I don’t really like this idea. I find “live handheld programming” a
frustrating experience. Without a readable screen and a usable keyboard,
no matter how much RAM or flash memory a handheld has, it’s basically
just a PIM/PDA/expensive calculator.
The last handheld I owned that I considered programmable was the
HP-100LX. This had DOS 5.0, a small but readable 80x25 screen and a
small but usable keyboard. It would run Forth, DOS Perl 4, Derive and
just about anything that would run under DOS. And it had a great PIM/PDA
built in as well as Lotus 1-2-3 2.4.
I’ve got a Sharp Zaurus 6000, BTW. Supposedly it runs Maxima and it has
a nice screen, but the keyboard is tiny. It’s a tad big for a pocket,
but it’s the closest thing I’ve found to the HP-100LX.
There’s a reason people use SDKs to program small devices. I don’t see
the point of a Ruby interpreter in anything without a real keyboard.
gregarican wrote:
I agree with this assertion. In my world I prefer to use Ruby for most
tasks that I take up. But the handful of times I specifically abandon
Ruby for Python is solely due to the fact that my ActiveState Python
install under Windows doesn’t hold me back from installing add-on
libraries. So if I can’t get something to work under Ruby in Windows
then I just grab the equivalent Python libraries and use Python
instead.
Hmmm … now it’s starting to make sense. There’s ActiveState Python,
Perl and Tcl, CygWin Python, Perl and Tcl, and IIRC there are “native
Windows builds” from the appropriate open source community for these
three scripting languages.
There’s a “native Windows build” of Ruby – the one-click installer. And
there’s CygWin Ruby. But so far, ActiveState hasn’t built a Ruby. They
support Ruby in their Komodo IDE. Anyone here have a clue why there
isn’t an ActiveState Ruby?
M. Edward (Ed) Borasky wrote:
frustrating experience. Without a readable screen and a usable keyboard,
a nice screen, but the keyboard is tiny. It’s a tad big for a pocket,
but it’s the closest thing I’ve found to the HP-100LX.There’s a reason people use SDKs to program small devices. I don’t see
the point of a Ruby interpreter in anything without a real keyboard.
I see your point. (I had the 200LX, by the way. What a sweet machine.)
But to me, the point is being able to run programs on the handheld –
something I’d love to do. I don’t mind doing the development on the
desktop as long as I can run the result in the palm of my hand.
Ruby runs on the Zaurus, right? I grant you might not like coding and
debugging on it, but wouldn’t you like to run your own custom apps on it
written in Ruby? I would.
Hal
Hal F. wrote:
I see your point. (I had the 200LX, by the way. What a sweet machine.)
But to me, the point is being able to run programs on the handheld –
something I’d love to do. I don’t mind doing the development on the
desktop as long as I can run the result in the palm of my hand.Ruby runs on the Zaurus, right? I grant you might not like coding and
debugging on it, but wouldn’t you like to run your own custom apps on it
written in Ruby? I would.
I have to assume Ruby will run on the Zaurus, since gcc can build for
it. Incidentally, the “native” Zaurus GUI is QT. Now if QTRuby runs on
the Zaurus, that’s interesting. Still, these days I’m more a
collector of handhelds than a user.
Mat S. wrote:
On Jul 21, 2006, at 10:32 PM, M. Edward (Ed) Borasky wrote:
There’s a reason people use SDKs to program small devices. I don’t
see the point of a Ruby interpreter in anything without a real keyboard.Geek factor
young geek factor. Us elderly geeks need large print PDAs and
keyboards the same size as our fingers.
On Jul 21, 2006, at 10:32 PM, M. Edward (Ed) Borasky wrote:
There’s a reason people use SDKs to program small devices. I
don’t see the point of a Ruby interpreter in anything without a
real keyboard.
Geek factor
-Mat
On 7/21/06, M. Edward (Ed) Borasky [email protected] wrote:
There’s a “native Windows build” of Ruby – the one-click installer. And
there’s CygWin Ruby. But so far, ActiveState hasn’t built a Ruby. They
support Ruby in their Komodo IDE. Anyone here have a clue why there
isn’t an ActiveState Ruby?
Not enough market as of yet. You’d also be surprised what ActiveState
builds on. I have another, separate thread of discussion with Eric
Promislow of ActiveState – but I have had no time to pick up on that
as it was started just before I left on vacation.
-austin
On 7/21/06, Patrick H. [email protected] wrote:
I love Ruby and will use it under Linux and Win32 regardless of the
final decision that is made. I would say that if Microsoft was willing
to provide some tools or bounties on a tool chain that would allow
people using their OS to make better use of more Open Source libraries
(autoconf, bash, etc) - with their compiler at the core that would
probably be best - and while I am dreaming how do they feel about
providing a Unix like fork API .
They may. I don’t know. What I can say is that before I went on
vacation, I was on a conference call with several VC++ development
team members and they seemed interested in figuring out what can be
done to make it easier/better to build Ruby and extensions with the
latest Visual Studio.
So … let me make a very public call: let this issue rest for a few
weeks. I am still about two weeks from finishing my vacation and I
cannot meaningfully talk to Microsoft about these and other issues
until then. I will be getting Curt and a couple of other people who
have posted exceptionally insightful posts involved with the larger
discussion. It may be that we could convince Microsoft to have a gcc
command-line compatibility mode tool or something like that. It may be
that there are other options.
The issue is most visible on Windows right now because of the
proliferation of compilers available (gcc has strangled most others on
other platforms), but the reality is that the Ruby toolchain needs to
be built better and more cross-platform. No one so far has stepped up
to do that, and I will freely state that I’m not qualified to do it.
Someone needs to make extconf.rb and other tools much more
platform-neutral so that we aren’t bitten by people putting
compiler/platform-specific CFLAGS in their extconf.rb.
Talking about that would be far more productive than trying to force
the decision on MinGW or VS at this point. I have been very
insistent with Microsoft that whatever happens, we need to have a way
that we can end up trusting the results of someone who compiles with
MinGW (because the library that they’re working on doesn’t build well
with VC++) or with VS8.
That’s why I’ve been asking for much more information than I’ve been
getting until this thread. Without this sort of information, I can’t
show Microsoft how frustrating the situation is for Ruby developers on
Windows. Mainly because my goal is a better, faster, more up to
date, and more stable Ruby on Windows. I don’t actually do any
extension compiling on Windows (well, not usually).
-austin
On 7/22/06, Mat S. [email protected] wrote:
On Jul 21, 2006, at 10:32 PM, M. Edward (Ed) Borasky wrote:
There’s a reason people use SDKs to program small devices. I
don’t see the point of a Ruby interpreter in anything without a
real keyboard.Geek factor
Fine. Then use something like Lua instead. Am doing that exactly now.
Using lua as the client to talk to a ruby on rails server, with json
as the intermediate object format. Ruby isn’t doable on this machine.
Use the right tool for the job. In this case, it’s not Ruby.
– G.
On Sat, 2006-07-22 at 15:18 +0900, Austin Z. wrote:
The issue is most visible on Windows right now because of the
proliferation of compilers available (gcc has strangled most others on
other platforms), but the reality is that the Ruby toolchain needs to
be built better and more cross-platform. No one so far has stepped up
to do that, and I will freely state that I’m not qualified to do it.
Someone needs to make extconf.rb and other tools much more
platform-neutral so that we aren’t bitten by people putting
compiler/platform-specific CFLAGS in their extconf.rb.
I have recently started looking at the possibility of converting one of
my cross-platform projects (MSVC >= 6 on Win2K, WinXP, and g++ >= 3.4 on
Red Hat/SuSE Linux) from its current build system to CMake
(http://www.cmake.org).
The current build system is (mostly) automated using a set of Python
scripts. However, it is becoming increasingly difficult to maintain it.
My initial attempts at migrating a couple of sub-projects have been
successful. Indeed, the resulting CMakeLists.txt files are far simpler!
KDE project has switched recently to CMake from the auto-tools chain
(Why the KDE project switched to CMake -- and how (continued) [LWN.net]).
I do not yet know how extconf.rb really works, but could an underlying
CMake make the job of extconf.rb easier?
JS
Lothar S. [email protected] writes:
in ruby.
If they can do it in Smalltalk and Lisp, it’s possible in Ruby too.
Bootstrapping will be a boring and tiresome process, of course. But
once the JIT it running, it hardly doesn’t matter.
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. 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 
On 7/22/06, Austin Z. [email protected] wrote:
Talking about that would be far more productive than trying to force
the decision on MinGW or VS at this point. I have been very
insistent with Microsoft that whatever happens, we need to have a way
that we can end up trusting the results of someone who compiles with
MinGW (because the library that they’re working on doesn’t build well
with VC++) or with VS8.
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.
Curt
Hello Christian,
I’m really scared about seeing the performance of a ruby parser written
in ruby.
CN> If they can do it in Smalltalk and Lisp, it’s possible in Ruby too.
Lisp doesn’t count because “data = program syntax” and the builtin
basics for this are always written native.
Smalltalk with it’s extreme syntax simplicity is also not a good
argument here.