RubyInstaller in 2011?
Jon
While we know we'd all like to have infinite resources, time, money, etc to do a lot of different things, don't self-censor and get bogged down in practicalities just yet. Bring on the crazy, wild-eyed ideas! :)
How and where are you using the RubyInstaller? What new (or not-so-new) things do you think would make this project even more useful?
Jon
Boško Ivanišević
--
Regards,
Boško Ivanišević
Chuck Remes
1. Make RubyInstaller runtime-agnostic so that it can be used to install MRI, JRuby, Rubinius, IronRuby, etc. Obviously this would probably require participation from those projects.
2. 64-bit MRI
3. An improved set of Windows specs for exercising the WIN32OLE classes. This would probably require a COM app/dll that knew how to
a) return every argument type (VT_BSTRING, VT_DATE, etc),
b) provided stub facilities for registering for event callbacks,
c) could generate all of the COM errors and exceptions
These specs would ensure that every runtime fully implemented the WIN32OLE (and related) classes and that no regressions are introduced between releases.
4. Work on a set of successor classes to WIN32OLE
Microsoft has deprecated OLE (and COM) and provided a replacement API in the form of .NET. Ruby needs to start moving in that direction.
Those are my ideas.
cr
Nikolai Weibull
> Microsoft has deprecated OLE (and COM) and provided a replacement API in the form of .NET. Ruby needs to start moving in that direction.
Do you have any idea of how much work that would be? (Please read
that in a non-sarcastic tone. I really want to know. I need to start
accessing .Net APIs at work and I would like to continue using MRI,
not IronRuby.)
Luis Lavena
I believe the work done by the Ruby CLR project will need to be resurrected.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Gordon Thiesfeld
I wonder if the rubyclr gem could be updated to work for this?
http://rubyforge.org/projects/rubyclr/
--
Gordon Thiesfeld
http://vert.igino.us
Gordon Thiesfeld
> I'd like to kick off an open-ended discussion on what capabilities you think make sense to implement in the RubyInstaller and/or DevKit this year. Nothing formal or official yet like a polldaddy.com survey, but a bit of unrestrained brainstorming.
>
> While we know we'd all like to have infinite resources, time, money, etc to do a lot of different things, don't self-censor and get bogged down in practicalities just yet. Bring on the crazy, wild-eyed ideas! :)
In no particular order:
1. RubiniusInstaller
2. Major, major performance improvements to MRI 1.9.2. The kind that
will have people switching off of their macs ;-)
3. Improvements to documentation and tools to get more Windows folks
contributing to their favorite projects. Luis, Jon, et. al are doing
a great job, but it would be nice to get more people feeling empowered
to help out. Maybe something like Dr. Nic's 8 steps for fixing other
people's code, but tailored to the Windows environment. Stuff like
that.
>
> How and where are you using the RubyInstaller? What new (or not-so-new) things do you think would make this project even more useful?
>
> Jon
>
> ---
> http://jonforums.github.com/
>
> --
> You received this message because you are subscribed to the Google Groups "RubyInstaller" group.
> To post to this group, send email to rubyin...@googlegroups.com.
> To unsubscribe from this group, send email to rubyinstalle...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rubyinstaller?hl=en.
Chuck Remes
I'm glad you put that note in there about how to read your question because my first time through I definitely read it as, "Are you crazy?" :)
I don't know how much work it would take. I assume it is non-trivial and would require weeks/months of effort. Hopefully it could be accomplished in such a way that it would be usable by multiple runtimes (via FFI for MRI & Rubinius and JNI for JRuby).
Other than than, Luis' comment is probably spot on.
cr
Vít Ondruch
SWIG should be one possible way. But it is out of scope or RubyInstaller
IMO.
Vit
Jon
In addition to feature ideas...
Any refinements or changes in how the project is run and/or ways to make it easier to contribute?
Any of the current open issues https://github.com/oneclick/rubyinstaller/issues roadblocking you from doing what you want?
Dušan Majkić
> The kind that will have people switching off of their macs ;-)
It looks like major startup problem is that Windows isn't caching
rb files, so every ruby init call starts major disk plowing.
I wonder if it would be possible to put all rb files in dll as resorces,
with modifided require, wich would just fetch rb file from dll.
since dlls are cached, and shared between processes.
And instaler suplied dll-s could be signed and secure.
Same thing could be done for gems, via gem install with DevKit
If (in gem dir) exists dirname-something.dll, try to require file from
dll, else get it from disk as usual.
I have no idea how to do it, or is it possible at all - just sharing
unrestrained wishes, as Jon pointed out.
Dušan Majkić
I would love to see DevKit renamed to WinKit, and made
essential single point where can be developed and deployed to.
I think of something like Homebrew for windows on top of
DevKit, so known software could be added to it with ease
via simple script. Like Tcl, zlib, pcre, openssl, mysql,
ssh, ... Like "brew mysql" or "brew my_app"
You are already doing it with rubyinstaller, but it would
be nice to be able to add my own app with all dependencies
via simple ruby script.
Or we could just steel Hombrew. It is pure ruby just OSX
specific. It would be also right use for windows Ruby.
Ruby is a pain to embedd. I would love to have minified 7z
rubyinstaller that I could just ship as component in my own
instaler and un7zip it via instalation process in jailed dir, with
some gems, somewhere in AppData so that user doesn't even
know he is on Ruby.
And I wish we have Console2 with embedded AnsiCon,
and all rightclick menus in one line without nesting.
Charles Roper
>
> Bring on the crazy, wild-eyed ideas! :)
>
Improved performance. I'd like to be able to strike-through the first
bullet-point here:
http://stackoverflow.com/questions/164896/limitations-in-running-ruby-rails-on-windows/166548#166548
(I know performance isn't RubyInstaller or DevKit's raison d'etre, but
we're being wild-eyed here, right?)
Happy 2011 to you all, btw.
Charles
Nikolai Weibull
>> 2. Major, major performance improvements to MRI 1.9.2.
>> The kind that will have people switching off of their macs ;-)
>
> It looks like major startup problem is that Windows isn't caching
> rb files, so every ruby init call starts major disk plowing.
I’m adding ruby-core.
The major problem is that Kernel#require is incredibly slow in 1.9.2:
a.rb:
require 'unprof'
(or any gem)
% time PATH=/Ruby19/bin:$PATH ruby a.rb
Thread ID: 13871796
Total: 0.010000
%self total self wait child calls name
0.00 0.00 0.00 0.00 0.00 1 Global#[No method]
/Ruby19/bin/ruby g.rb
real: 1.724 user: 0.031 system: 0.015 (2%)
% time PATH=/Ruby18/bin:$PATH ruby a.rb
Thread ID: 26060688
Total: 0.010000
%self total self wait child calls name
0.00 0.00 0.00 0.00 0.00 1 Global#[No method]
ruby g.rb
real: 0.476 user: 0.000 system: 0.031 (6%)
For some reason require does an insane amount of I/O. I’ve attached
logs that I generated from Process Monitor. (dtruss/strace will
generate similar, less verbose, results.) Not only does require stat
every directory component leading to the found file, once found, it,
if I understand things correctly, makes sure that specification.rb
actually exists 148 times!
It seems, from some slight debugging, that something funky is going on
in rb_get_expanded_load_path/rb_file_expand_path. These results have
to be cached to minimize I/O.
Octagon
starters, there are no pointers to ,NET objects and no ability to lock
an object in memory. So, all you can hope for is to "access .Net APIs"
in some way that may or may not be sufficient.
The most powerful way is to host a .NET runtime in a native gem and it
will take weeks to write such a gem. There are lots of questions
starting with "which runtime?" As mentioned above, there still will be
problems.
As for "normal" limited interoperability, I guess we already have it.
The COM support takes care of .NET assemblies wrapped in COM and FFI
handles .NET code wrapped in mixed mode C++ assemblies.
It may be useful to have a mixed mode C++ assembly that loads other
assemblies and provides introspection and the like to unmanaged code,
but this is not Ruby specific. It should be easy to write it, but it
may take months before the interface settles down to something
convenient to everybody.
A gem that wraps the interface to that assembly, possibly a pure Ruby
one using FFI, should be very easy to write.
As for "Microsoft has deprecated OLE (and COM)", I have doubts. More
likely, it tried and failed. It looks like COM is here to stay since
deprecating it means much work leading to diminished status for many
MS folks. I bet the way how Muglia left MS supports this theory.
On Jan 11, 5:35 pm, Nikolai Weibull <n...@bitwi.se> wrote:
Luis Lavena
>> 2. Major, major performance improvements to MRI 1.9.2.
>> The kind that will have people switching off of their macs ;-)
>
> It looks like major startup problem is that Windows isn't caching
> rb files, so every ruby init call starts major disk plowing.
>
Ruby does an insane amount of IO when looking for files.
I've some article that is going out this weekend that cover those and
invite people to start digging into it.
I would like we move the Ruby IO conversation to another thread once
that goes out, will love your input Dusan.
Luis Lavena
>> I'd like to kick off an open-ended discussion
>
> I would love to see DevKit renamed to WinKit, and made
> essential single point where can be developed and deployed to.
>
I didn't wanted to advertise DevKit as essential part beyond Ruby,
because is simple a repackage of MinGW or TDM releases, nothing fancy.
> I think of something like Homebrew for windows on top of
> DevKit, so known software could be added to it with ease
> via simple script. Like Tcl, zlib, pcre, openssl, mysql,
> ssh, ... Like "brew mysql" or "brew my_app"
>
> You are already doing it with rubyinstaller, but it would
> be nice to be able to add my own app with all dependencies
> via simple ruby script.
>
I've some initial system working for that, actually :-)
But until I figure out some free time to finish it, remains a prototype.
> Ruby is a pain to embedd. I would love to have minified 7z
> rubyinstaller that I could just ship as component in my own
> instaler and un7zip it via instalation process in jailed dir, with
> some gems, somewhere in AppData so that user doesn't even
> know he is on Ruby.
>
Better documentation on how Ruby start could be generated taking the
lead of exerb and what Shoes is doing.
Jon
My prioritized wish list:
1) Performance roadblocks identified, fixed and patched in the ruby-core ruby_1_9_2 and trunk branches by the end of March.
2) Stand up a donation system (paypal, pledgie, ??) for this project with the primary goals of (a) offsetting infrastructure costs, and (b) enabling us to efficiently offer bounties for "notable" updates (e.g. - WIN32OLE) and development.
3) A thin_service gem based upon a "service framework" C extension gem that wrangles WMI scripting objects via IDispatch.
4) A distinctive main graphic for the RubyInstaller rather than the stock Inno graphic we currently use. If you have talented graphically-minded friends, put them in contact with me before I go over to http://www.deviantart.com/ :)
Jon
---
blog: http://jonforums.github.com/
Luis Lavena
>> How and where are you using the RubyInstaller? What new (or not-so-new) things do you think would make this project even more useful?
>
> My prioritized wish list:
>
> 1) Performance roadblocks identified, fixed and patched in the ruby-core ruby_1_9_2 and trunk branches by the end of March.
>
Why by the end of march?
> 2) Stand up a donation system (paypal, pledgie, ??) for this project with the primary goals of (a) offsetting infrastructure costs, and (b) enabling us to efficiently offer bounties for "notable" updates (e.g. - WIN32OLE) and development.
>
Ruby Masters Conference in Brazil is going to contribute money to the project:
http://rubymastersconf.com/opensource
There is no number yet so can't comment further.
> 3) A thin_service gem based upon a "service framework" C extension gem that wrangles WMI scripting objects via IDispatch.
>
What? Why such complicated beast? There is already a service API that
doesn't need going over WMI...
Jon
> >
>
> Why by the end of march?
Specific targets do wonders for forward momentum. And who wouldn't want 9 months of a better Ruby on Windows experience ;)
Seriously, once this roadblock is removed I believe we'll see an "umbrella" effect in which more developers begin viewing MRI Ruby on Windows as a more viable production platform, at least for internal intranet style apps. A March target gives more time for that to happen.
> > 2) Stand up a donation system (paypal, pledgie, ??) for this project with the primary goals of (a) offsetting infrastructure costs, and (b) enabling us to efficiently offer bounties for "notable" updates (e.g. - WIN32OLE) and development.
> >
>
> Ruby Masters Conference in Brazil is going to contribute money to the project:
>
> http://rubymastersconf.com/opensource
>
> There is no number yet so can't comment further.
Very nice.
I'm also looking for something we can use on a regular, ongoing basis to help fund "notable" ideas and promote them on http://rubyinstaller.org/ in place of the chasm-o-space we currently have.
> > 3) A thin_service gem based upon a "service framework" C extension gem that wrangles WMI scripting objects via IDispatch.
> >
>
> What? Why such complicated beast? There is already a service API that
> doesn't need going over WMI...
An wild-eyed experiment of mine partially motivated by Gordon's ruby-wmi :)
I know about the service API, win32-service and have briefly looked over your mongrel_service, but I also like WMI's capabilities to do things easily like the following VBScript:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Service",,48)
For Each objItem in colItems
Wscript.Echo "Service Name: " & objItem.Name & VBNewLine _
& " State: " & objItem.State
Next
Boško Ivanišević
On Wed, Jan 12, 2011 at 12:37 PM, Jon <jon.f...@gmail.com> wrote:Why by the end of march?
>> How and where are you using the RubyInstaller? What new (or not-so-new) things do you think would make this project even more useful?
>
> My prioritized wish list:
>
> 1) Performance roadblocks identified, fixed and patched in the ruby-core ruby_1_9_2 and trunk branches by the end of March.
>
What? Why such complicated beast? There is already a service API that
> 3) A thin_service gem based upon a "service framework" C extension gem that wrangles WMI scripting objects via IDispatch.
>
doesn't need going over WMI...
--
Regards,
Boško Ivanišević
Jon
> essential single point where can be developed and deployed to.
What specific concerns do you have on how the DevKit recipe/config is currently integrated into the main rubyinstaller repo?
I'm particularly interested in fixing problems that (a) complicate ongoing development and maintenance of the DevKit, and (b) make it overly difficult for someone to build their own DevKit.
Dušan Majkić
> is currently integrated into the main rubyinstaller repo?
Let me say that I have absolutely no concerns for DevKit, for which I
think is a great, game changing product, and excellent piece of work.
I am just making wishes, that we were asked to do.
Every native gem that depends on some 3p library has linux
instructions like this:
$ apt-get install somethig
$ gem install ruby-something
(replace apt-get with yum, pacman, port, or whatever package manager)
Gem works for windows, but there's no apt-get. Nothing beside what
comes with DevKit. And it would be impossible, or even stupid, to put
every single lib and app in DevKit.
All this because Windows users are spoiled by lasting binary compatibility.
Find somewhere prebuilt exe or dll for windows, and you are ready to go.
This is a good thing. For end user. But not for developer.
I have a hunch that DevKit somehow fits there. It would be great if I could
just, instead of system-wide packager (like apt-get) have directory-wide
one or DevKit-wide packager (like homebrew for OSX) where I could install
basic DevKit, and then add some libs, headers via simple commands.
Like for example:
C:\> brew sqlite3
C:\> gem install sqlite3-ruby
Brew command above should download tgz, unpack it in DevKit, build it,
and copy sqlite3.dll to <registered rubies>/bin.
I wouldn't go beyond sqlite, mysqlcli, pgclient, and other basic rails gems.
But, if done right, someone will.
Regards.
Luis Lavena
>> What specific concerns do you have on how the DevKit recipe/config
>> is currently integrated into the main rubyinstaller repo?
>
> Let me say that I have absolutely no concerns for DevKit, for which I
> think is a great, game changing product, and excellent piece of work.
> I am just making wishes, that we were asked to do.
>
> Every native gem that depends on some 3p library has linux
> instructions like this:
>
> $ apt-get install somethig
> $ gem install ruby-something
>
> (replace apt-get with yum, pacman, port, or whatever package manager)
>
> Gem works for windows, but there's no apt-get. Nothing beside what
> comes with DevKit. And it would be impossible, or even stupid, to put
> every single lib and app in DevKit.
>
> All this because Windows users are spoiled by lasting binary compatibility.
> Find somewhere prebuilt exe or dll for windows, and you are ready to go.
> This is a good thing. For end user. But not for developer.
>
As I mentioned before, I've been working on a recipe system, like
homebrew, but not tied to an architecture.
Been experimenting with it for certain packages, but not all packages
are equal, so cannot apply autoconf rules to all.
And create cross-platform compatible recipes is not easy.
I've been testing this internally to replace rake-compiler cross
platform build needs, and still remains lot of pieces for all Ruby
dependencies.
Different that brew and macports the tool I was working with keep
packages in isolation and place with environment variables.
On platforms that support symlink, it "activates" different components
into a common directory and use that with environment variables.
> I wouldn't go beyond sqlite, mysqlcli, pgclient, and other basic rails gems.
> But, if done right, someone will.
>
Compiling things like postgres or mysql are complicated and do not
possible with MinGW (AFAIK, not officially)
If I find the time to work on this to the point is usable will share
with you guys.
Jon
> > is currently integrated into the main rubyinstaller repo?
>
> Let me say that I have absolutely no concerns for DevKit, for which I
> think is a great, game changing product, and excellent piece of work.
> I am just making wishes, that we were asked to do.
Thank you very much for taking the time to provide the feedback/wishes. I hope my questions didn't come across as anything other than me wanting to better understand your comments.
I think it's very important for a people and projects to be able to ask for and accept very direct feedback (without getting defensive) on areas that could be improved. Unless this is regularly done, projects atrophy :(
I like your DevKit + HomeBrew idea especially for those cases in which a "gem install blah --platform=ruby" isn't good enough because of other dependencies are unmet. I go back and forth as to the most efficient way to solve this. Do we need better and more accessible troubleshooting documentation? Or do we need to automate it with code similar to a package manager? How much does it take to maintain either of the two and keep them up-to-date?
I don't know the right answer, especially with limited resources and time. That said, I suspect many of these installation problems could be minimized if we (RubyInstaller community) regularly maintained developer wiki pages at our github repo. This may be the quicker, lower cost way to solve 80% of the issues without spinning up new code.
Regardless, I think your idea is clever and I've always liked things similar to gentoo and the arch build system :)
Vít Ondruch
It reminds me Emerge from Gentoo more than Apt, Yum, whatever (even
Cygwin). The difference is source vs binary distribution.
Vit
Dušan Majkić
> homebrew, but not tied to an architecture.
I heard it the first time. Just didn't wanted to push things, since
I realize that work you are doing here is huge in every possible
sense of the word. And I have no intention to bring more.
> Compiling things like postgres or mysql are complicated
I think that it should start just small, supporting only software that
have a web site with wgetable source, and compiles with ease.
If it refuses to comply with that - skip it.
> If I find the time to work on this to the point is usable will share
> with you guys.
Take your time.
Nikolai Weibull
> Compiling things like postgres or mysql are complicated and do not
> possible with MinGW (AFAIK, not officially)
Why not port emerge, apt-get, or similar system instead so that you at
least don’t have to rewrite the actual recipes?
Dušan Majkić
> least don’t have to rewrite the actual recipes?
They all relay on Unix: locations, presmisions, etc.
There is Cygwin and Unix Services for Windows for that.
DevKit provides build enviroment. Resulting build can be native apps
that can be used without DevKit (native gems, etc)
DevKit brings build power to Ruby On Windows.
My sugestion is to bring Windows Ruby power back to DevKit.
Dušan Majkić
> "gem install blah --platform=ruby" isn't good enough because of other
> dependencies are unmet. I go back and forth as to the most efficient
> way to solve this.
If something can be manualy added to DevKit with ease, script it in Ruby
and give it a nice name.
When someone asks how, reply with install Ruby and DevKit, type
'<command> <recepie>'.
Dont't go to wide, only basic stuff is needed.
I also have nothing against direct binaries fetching, as long as they
play fair and simple.
Nikolai Weibull
>> Why not port emerge, apt-get, or similar system instead so that you at
>> least don’t have to rewrite the actual recipes?
> They all relay on Unix: locations, presmisions, etc.
> There is Cygwin and Unix Services for Windows for that.
Well, MingW/MSYS provides much of this as well, so there’s nothing
that prevents you from porting emerge/apt-get/ports to run on top of
DevKit.
> DevKit provides build enviroment. Resulting build can be native apps
> that can be used without DevKit (native gems, etc)
> DevKit brings build power to Ruby On Windows.
How does that relate to my question?
> My sugestion is to bring Windows Ruby power back to DevKit.
What does this mean?
Luis Lavena
> 2011/1/13 Dušan Majkić <dma...@gmail.com>:
>>> Why not port emerge, apt-get, or similar system instead so that you at
>>> least don’t have to rewrite the actual recipes?
>
>> They all relay on Unix: locations, presmisions, etc.
>> There is Cygwin and Unix Services for Windows for that.
>
> Well, MingW/MSYS provides much of this as well, so there’s nothing
> that prevents you from porting emerge/apt-get/ports to run on top of
> DevKit.
>
Actually no, apt-get, emerge and other can't be ported to Windows to
run on top of MinGW/MSYS due several configuration options,
assumptions like chroot and others.
emerge has been ported to Windows, but it depends on Microsoft UNIX services:
http://www.gentooexperimental.org/nt/
So it will not work with MinGW.
Last, but no least, emerge is Python... enough said.
Dušan Majkić
> that prevents you from porting emerge/apt-get/ports to run on top of
> DevKit.
>
>> DevKit provides build enviroment. Resulting build can be native apps
>> that can be used without DevKit (native gems, etc)
>> DevKit brings build power to Ruby On Windows.
>
> How does that relate to my question?
You are right. I see nothing that should stop you port them to Windows.
Regards.
Nikolai Weibull
Nikolai Weibull
> Actually no, apt-get, emerge and other can't be ported to Windows to
> run on top of MinGW/MSYS due several configuration options,
> assumptions like chroot and others.
I would assume that fixing such issues, that no doubt exist, would be
a lot less work than setting up new infrastructure and recipes.
> Last, but no least, emerge is Python... enough said.
That is definitely least. I don’t like writing code in assembler, but
it’s not preventing me from using software written in it.
I don’t want to take anything away from you. If you’re working on a
new package management system, fine, and good luck to you. I will use
it. I just wanted to know why you’re not adapting something that
already exists.
And now a rant follows that is only slightly related, but puts my
questioning demeanor in context.
My concern of late is that being Ruby developers have taken on the
mantra “we don’t use things not invented here”. Take the whole
RubyGems debacle, for example. Instead of actually solving the issue
of library versioning, we now have a crappy package management system
that doesn’t play nice with any other package management system or the
FHS and you have to use separate software, for example, Bundler, to
actually load the correct version of a library.
Dušan Majkić
>
> Sorry, but are you being snide?
No!
I would really love to see something like apt-get on Windows.
The fact that I think that the work is too hard, beyond my free time,
or even impossible, should in no way stop someone from trying it.
It is I who hate when someone insists that something can't be done,
so I always try to avoid doing that to others.
BTW This is way off topic.
Regards.
Luis Lavena
>
> I don’t want to take anything away from you. If you’re working on a
> new package management system, fine, and good luck to you. I will use
> it. I just wanted to know why you’re not adapting something that
> already exists.
>
The problem is simple, emerge, pacman and lot of package manager have
been conceived for POSIX OS.
None of these packages consider the needed tweaks required for certain
projects to compile on Windows.
Take for example OpenSSL, which it's own compile process differs a lot
from autoconf/automake based ones (depends on Perl) and it doesn't
generate DLLs (shared objects) properly, something we need to
generate.
These package manager love to symlink stuff, which breaks the purpose
of doing binary packaging in isolation for us to deliver and use (and
not compile every single time).
I had investigated these options as I have been a user of many Linux
OS for long time, and none of these recipes or package management
solutions can play nice with what we have.
And for nice I'm talking major surgery to make them work.
So, why force something that wasn't conceived in that tool in the first place?
The tool I've been working on is not aim at end-users, but instead
provide a facility to scratch my own itch: build stuff on Windows *as
developer*
So the tool is aimed as developers and to make it easy for other
developers to recreate the environment.
Please take a look to rake-compiler and search to know how it helped
others developers provide support for Windows.
What I'm trying to do with this tool is extend that for developers,
not compete with Windows Installer or emerge, apt or pacman.
I'm not reinventing the wheel on this, I believe there has been sooo
many package managers ideas and goals just to add another one.
I'm building a tool that fits my needs, the need of building Ruby and
it's support libraries consistently. If a side effect someone can use
it to create recipes for other tools, so be it.
I don't want to turn this nice brainstorming thread into something
else, so I'm cutting your rant and leave it there.
If you want to explore the idea of porting emerge/apt/pacman or other
packaging system to work on top of MinGW+MSYS I would love to provide
feedback on my findings, but not going to invest more time already in
that path.
Nikolai Weibull
>>> You are right. I see nothing that should stop you port them to Windows.
>>
>> Sorry, but are you being snide?
>
> No!
OK, good.
> BTW This is way off topic.
Agreed. I’ll shut up now ;-).
Nikolai Weibull
> On Thu, Jan 13, 2011 at 10:40 AM, Nikolai Weibull <n...@bitwi.se> wrote:
>> I don’t want to take anything away from you. If you’re working on a
>> new package management system, fine, and good luck to you. I will use
>> it. I just wanted to know why you’re not adapting something that
>> already exists.
[Long and excellent description]
Thank you, Luis, for this information! It would make an excellent
mission statement on a future website for the project.
Jon
??
> That is definitely least. I don’t like writing code in assembler, but
> it’s not preventing me from using software written in it.
>
> ...SNIP...
>
> And now a rant follows that is only slightly related, but puts my
> questioning demeanor in context.
>
> My concern of late is that being Ruby developers have taken on the
> mantra “we don’t use things not invented here”. Take the whole
> RubyGems debacle, for example.
Anyone who thinks hackers aren't passionate must be asleep. That said, foul on you both for getting tempted away by other siren songs ;)
original_point => brainstorming ideas on how to make *RubyInstaller/DevKit* more useful in 2011.
Jon
Nikolai Weibull
I wrote:
>> My concern of late is that being Ruby developers have taken on the
>> mantra “we don’t use things not invented here”. Take the whole
>> RubyGems debacle, for example.
> Anyone who thinks hackers aren't passionate must be asleep. That said, foul on you both for getting tempted away by other siren songs ;)
I would say that the current attitude that many people have to, for
example, apt-get versus RubyGems is steeped in arrogance, not passion.
I won’t push this further here, I just wanted to make my off-topic point clear.
Vít Ondruch
I have few ideas:
1) We should have special RubyInstaller testing gem, which should
replace "gem install rdiscount --platform=ruby". This gem could be
tweaked in the way, that it will check correct, supported compiler
tools, either during installation or after installation.
2) There should be some debugging option, or script to ease solving of
user issues. Sorry but filling of some excel sheet (while better than
nothing) could be replaced by some script which would report ruby
version, gem version, environment variables or possible check for some
known cases which were already solved.
3) This is may be far beyond scope of Ruby installer, but for someone
who is using Visual Studio for his daily work is first touch with MinGW,
MSys, Bash and other tools completely different experience (worser at
least for first time). But what I am really missing is actually some
easy Windows environment where we would be able to target Windows
specific Ruby issues. For example in Visual Studio there is pretty easy
to switch between release and debug versions. In Ruby, there is probably
some flag how to enable debugging informations, but anyway, how to use
GDB than? On command line? So may be some tutorial would be good
starting point, however, something like Visual Studio solution (but you
can substitute your favourite IDE instead) would help in my opinion.
4) I would like to see DevKit in some other form than SFX archive. For
me, it is neither archive nor installation, just something "I can't
mentally handle" :) Installer is not priority for me personally, so I
would love to see plain old 7z archive, same as Ruby itself is provided.
Btw, ideal state of RubyInstaller on Windows would be "Pik on steroids".
I imagine it at least as Pik which smoothly works without any Ruby
present on your computer, allowing you to selectively install which
version of Ruby you want, which Devkit, etc. So at the end only Pik
would be installed and the rest would be just some archives managed by
Pik. Pik could stay command line only, or would be extended by fancy GUI.
This is already possible with Pik 0.2.8, there are unfortunately some
outstanding bugs which harm user experience :(
Vit
Dne 10.1.2011 23:25, Jon napsal(a):
> I'd like to kick off an open-ended discussion on what capabilities you think make sense to implement in the RubyInstaller and/or DevKit this year. Nothing formal or official yet like a polldaddy.com survey, but a bit of unrestrained brainstorming.
>
> While we know we'd all like to have infinite resources, time, money, etc to do a lot of different things, don't self-censor and get bogged down in practicalities just yet. Bring on the crazy, wild-eyed ideas! :)
>
> How and where are you using the RubyInstaller? What new (or not-so-new) things do you think would make this project even more useful?
>
> Jon
>
> ---
> http://jonforums.github.com/
>
Nikolai Weibull
> 4) I would like to see DevKit in some other form than SFX archive. For me,
> it is neither archive nor installation, just something "I can't mentally
> handle" :) Installer is not priority for me personally, so I would love to
> see plain old 7z archive, same as Ruby itself is provided.
Yes. SFX is just confusing. Every time I run it I’m thinking, well,
why should I unpack it to THAT folder? (The folder being the one
suggested by the installer.) I just want to unpack it under /Ruby18.
Providing an installer is also pointless. Why would anyone who can’t
figure out where to install DevKit want to install it? If you can’t
figure that out, you’re probably not ready to begin using it.
Luis Lavena
Been thinking add an extra checkbox (uncheck as default) to
alternatively download the DevKit.
It will download a 7z archive as part of the installation process and
place it along the installation of Ruby (devkit folder inside of it).
The word of recommendation will be not use it that way if you plan on
install multiple versions of Ruby.
Just an idea.
André Caron
> On Thu, Jan 20, 2011 at 6:14 PM, Nikolai Weibull <n...@bitwi.se> wrote:
>> On Thu, Jan 20, 2011 at 21:59, Vít Ondruch <v.on...@gmail.com> wrote:
>>
>> Yes. SFX is just confusing. Every time I run it I’m thinking, well,
>> why should I unpack it to THAT folder? (The folder being the one
>> suggested by the installer.) I just want to unpack it under /Ruby18.
>> Providing an installer is also pointless. Why would anyone who can’t
>> figure out where to install DevKit want to install it? If you can’t
>> figure that out, you’re probably not ready to begin using it.
>>
>
> Been thinking add an extra checkbox (uncheck as default) to
> alternatively download the DevKit.
>
> It will download a 7z archive as part of the installation process and
> place it along the installation of Ruby (devkit folder inside of it).
>
> The word of recommendation will be not use it that way if you plan on
> install multiple versions of Ruby.
>
> Just an idea.
> --
> Luis Lavena
Why is it not installed by default, as part of the ruby installer? As
a new Ruby user, I was confused that 'gem install X' is part of the
default install, but running 'gem install X' might require some
infrastructure that's not part of the setup.
Is it a technical or political reason?
Regards,
André Caron
Vít Ondruch
> On Thu, Jan 20, 2011 at 4:28 PM, Luis Lavena<luisl...@gmail.com> wrote:
>> On Thu, Jan 20, 2011 at 6:14 PM, Nikolai Weibull<n...@bitwi.se> wrote:
>>>
>>> Yes. SFX is just confusing. Every time I run it I�m thinking, well,
>>> why should I unpack it to THAT folder? (The folder being the one
>>> suggested by the installer.) I just want to unpack it under /Ruby18.
>>> figure out where to install DevKit want to install it? If you can�t
>>> figure that out, you�re probably not ready to begin using it.
>>>
>> Been thinking add an extra checkbox (uncheck as default) to
>> alternatively download the DevKit.
>>
>> It will download a 7z archive as part of the installation process and
>> place it along the installation of Ruby (devkit folder inside of it).
>>
>> The word of recommendation will be not use it that way if you plan on
>> install multiple versions of Ruby.
>>
>> Just an idea.
>> --
>> Luis Lavena
> Why is it not installed by default, as part of the ruby installer? As
> a new Ruby user, I was confused that 'gem install X' is part of the
> default install, but running 'gem install X' might require some
> infrastructure that's not part of the setup.
>
> Is it a technical or political reason?
>
> Regards,
>
Binary gems are preferred solution. So you don't need DevKit in ideal
world. And also it is historical reason of course, since nobody did
anything better yet :)
Vit
Luis Lavena
>
> Why is it not installed by default, as part of the ruby installer? As
> a new Ruby user, I was confused that 'gem install X' is part of the
> default install, but running 'gem install X' might require some
> infrastructure that's not part of the setup.
>
> Is it a technical or political reason?
>
Both. Not everybody needs to compile gems and even with a compiler,
not all gem will compile due missing dependencies, so is the same you
have a compiler or not. mkmf will generate you a cryptic error.
"gem install" is part of RubyGems, that shouldn't be root of confusion.
At least now, when you don't have a compiler, you get a friendlier message.
The bundling of DevKit has been discussed several times on the list to
which I have responded. I've blogged about it too:
http://blog.mmediasys.com/2010/09/23/rubyinstaller-what-where-when-1/
Quote: "(in relation to bundling DevKit with the installer) I
personally don’t believe that will fix the education and lack of
documentation problem, it will just make the installers 12MB bigger."
On other platforms you still need to install a compiler (Xcode,
build-essentials) that is not out of the box. Also, on these
platforms, you need to install development packages to be able to
install certain gems, that is the same here.
So, since all platforms suffer the same, what is the problem? IMO
education and documentation.
André Caron
>>
>> I'd like to kick off an open-ended discussion on what capabilities you
>> think make sense to implement in the RubyInstaller and/or DevKit this year.
>> Nothing formal or official yet like a polldaddy.com survey, but a bit of
>> unrestrained brainstorming.
>>
>> While we know we'd all like to have infinite resources, time, money, etc
>> to do a lot of different things, don't self-censor and get bogged down in
>> practicalities just yet. Bring on the crazy, wild-eyed ideas! :)
>>
>> How and where are you using the RubyInstaller? What new (or not-so-new)
>> things do you think would make this project even more useful?
>>
>> Jon
In the spirit of throwing in the first crazy, wild-eyed idea, and also
because it is the current (and first) use I have of Ruby!
How about a procedure for shipping a Ruby script as a standalone
install? The only tools in that spirit I've seen so far are
RubyScript2Exe (http://www.erikveen.dds.nl/rubyscript2exe/) and
AllInOneRuby (http://www.erikveen.dds.nl/allinoneruby/) which are both
outdated. Further, I don't believe any compilation of ruby to native
code is necessary.
A simple bundle with the Ruby interpreter, a configurable set of Gems
and an application script would be perfect. I think this would really
encourage developers to develop Ruby desktop applications for
non-techie users.
(If you already have a process for doing this, I'm sorry, but I
haven't found it.)
Regards,
André Caron
Vít Ondruch
Note that DevKit itself cannot solve issues like building native
extensions for database adapters for example. It can help but still, you
need to have available also the database SDK, etc. Therefore it is
better if author of the gem, who has all the dependencies already setup
on his computer provides the binary gem and it renders DevKit useless
for you.
As an example, you can use Postgres, Mysqul, Sqlite3, Nokogiri gems
without DevKit, because they already contains the binary extension compiled.
So really, DevKit is advanced feautre, targeted more on Gem developers
than regular users (Rails programmers for example).
Vit
Vit
Luis Lavena
>
> How about a procedure for shipping a Ruby script as a standalone
> install? The only tools in that spirit I've seen so far are
> RubyScript2Exe (http://www.erikveen.dds.nl/rubyscript2exe/) and
> AllInOneRuby (http://www.erikveen.dds.nl/allinoneruby/) which are both
> outdated. Further, I don't believe any compilation of ruby to native
> code is necessary.
>
These are not the only tools:
Ocra:
exerb:
http://vert.igino.us/2011/01/05/exerb-101-building-windows-executables-with-ruby/
> A simple bundle with the Ruby interpreter, a configurable set of Gems
> and an application script would be perfect. I think this would really
> encourage developers to develop Ruby desktop applications for
> non-techie users.
>
QtBindings is 49MB, it will not be easy to package that as monolithic executble.
Shoes fits better the bill.
Gordon Thiesfeld
> Hi everybody,
>
> I have few ideas:
>
> 1) We should have special RubyInstaller testing gem, which should replace
> "gem install rdiscount --platform=ruby". This gem could be tweaked in the
> way, that it will check correct, supported compiler tools, either during
> installation or after installation.
This sounds like a good idea to me. I'll give this some thought. As
it stands, a casual reader might be getting the wrong idea about
rdiscount ;-)
>
> 2) There should be some debugging option, or script to ease solving of user
> issues. Sorry but filling of some excel sheet (while better than nothing)
> could be replaced by some script which would report ruby version, gem
> version, environment variables or possible check for some known cases which
> were already solved.
Possibly combined with option 1? I think that would be ideal. If it
works, awesome. If it fails, extconf.rb could dump as much info as we
can gather into gem_make.out? Have the user send us that file or
pastie it for inspection.
Thoughts?
--
Gordon Thiesfeld
http://vert.igino.us
Jon
> >> it is neither archive nor installation, just something "I can't mentally
> >> handle" :) Installer is not priority for me personally, so I would love to
> >> see plain old 7z archive, same as Ruby itself is provided.
> >
> > Yes. SFX is just confusing. Every time I run it I’m thinking, well,
> > why should I unpack it to THAT folder? (The folder being the one
> > suggested by the installer.) I just want to unpack it under /Ruby18.
> > Providing an installer is also pointless. Why would anyone who can’t
> > figure out where to install DevKit want to install it? If you can’t
> > figure that out, you’re probably not ready to begin using it.
> >
Since we can already easily build a 7z DevKit (rather than SFX) with
rake devkit 7z=1
should we move the current 4.5.1 SFX to the Archive page and replace it with a 4.5.1 7z archive? Or simply just add a 4.5.1 7z to the download page? Or do nothing?
> Been thinking add an extra checkbox (uncheck as default) to
> alternatively download the DevKit.
>
> It will download a 7z archive as part of the installation process and
> place it along the installation of Ruby (devkit folder inside of it).
>
> The word of recommendation will be not use it that way if you plan on
> install multiple versions of Ruby.
Good idea I think for those who use the installer not the 7z archives.
We'll need to add download code to the current installer, but I'm assuming you've already started looking into some of the existing Inno download codes? ;)
Luis Lavena
Awesome ideas!
So, a few things that extconf.rb needs to do before generating the
makefile (from the top of my head)
* Ruby information:
RUBY_VERSION
RUBY_PATCHLEVEL
RUBY_PLATFORM
Installation directory of "ruby.exe":
ruby -rrbconfig -ve "puts RbConfig::TOPDIR"
* Values of:
PATH
COMSPEC
* Information in registry (reg query) of:
reg query "HKCU\Environment" /v PATH
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager\Environment" /v PATH
reg query "HKCU\Software\Microsoft\Command Processor" /v AutoRun
reg query "HKLM\Software\Microsoft\Command Processor" /v AutoRun
* If gcc.exe, make.exe, sh.exe are available
The extension itself could be something simple as this:
https://github.com/luislavena/test-ruby-c-extension
Then, as post_install message, we congrats the user ;-)
Volunteers? :-D
Luis Lavena
>
> Since we can already easily build a 7z DevKit (rather than SFX) with
>
> rake devkit 7z=1
>
> should we move the current 4.5.1 SFX to the Archive page and replace it with a 4.5.1 7z archive? Or simply just add a 4.5.1 7z to the download page? Or do nothing?
>
The main problem we had on this is that 7z packages should have been
made available along the SFX. Had problems uploading the devkit to
GitHub (slow internet).
I think we need to start putting these things into a more reliable CDN
than RubyForge on next upload.
>
> We'll need to add download code to the current installer, but I'm assuming you've already started looking into some of the existing Inno download codes? ;)
>
Yes, but two concerns:
A) Use a stable DevKit at the time we build the installer
or
B) Use a generic 302 redirect for the download URL to download
possible updated DevKit.
The problem with that could be if we decide to move to a different
compiler (mingw-w64), these links could fail (or stagnate)
Let's see how it goes ;-)
Jon
Great idea. Any useful bits from https://github.com/oneclick/rubyinstaller/blob/master/resources/tools/fakeruby.c to put into the extension?
Jon
Gordon Thiesfeld
:-)
Here's what I have so far.
https://gist.github.com/788841
Not top priority, but I'll get it up on github in the next few days.
Vít Ondruch
> On Thu, Jan 20, 2011 at 4:28 PM, Luis Lavena<luisl...@gmail.com> wrote:
>> On Thu, Jan 20, 2011 at 7:15 PM, Gordon Thiesfeld<gthie...@gmail.com> wrote:
Nice!
* Can we detect somehow DevKit version?
* Is it possible to know if the Ruby are official release or some
unofficial build?
* Can we get somehow the executed command, e.g. "gem install rdiscount
--platform=ruby", or is there somewhere visible the "platform" parameter?
Cosmetics:
* Could you split the PATH?
More ideas:
* Not sure if the gist is meant as output of gem install or log, but for
end user, it would be nice to see some checkboxes, e.g. "gcc ver 4.5.0
.... [ OK ] \n registry entries ..... [ Failed ]", and the details store
in log. But I am pretty sure that this is not feasible ;)
Vit
Luis Lavena
>>
>> Here's what I have so far.
>>
>> https://gist.github.com/788841
>>
>> Not top priority, but I'll get it up on github in the next few days.
>>
>
> Nice!
>
> * Can we detect somehow DevKit version?
You get it from gcc.exe --version
> * Is it possible to know if the Ruby are official release or some unofficial
> build?
I don't think so.
> * Can we get somehow the executed command, e.g. "gem install rdiscount
> --platform=ruby", or is there somewhere visible the "platform" parameter?
>
Well, we can get ARGV, but after all, the idea with this output is
that if the gem fails, the user copy the entire output in the group
for us to help solve the issue
> * Not sure if the gist is meant as output of gem install or log, but for end
> user, it would be nice to see some checkboxes, e.g. "gcc ver 4.5.0 .... [ OK
> ] \n registry entries ..... [ Failed ]", and the details store in log. But I
> am pretty sure that this is not feasible ;)
>
Well, the idea is for us to have enough debugging information, so I
think OK/FAIL will not help that.
The theory:
gem install rubyinstaller-test
If it fails, it will output "gem_make.out" to the end user.
This output will be what Gordon has worked. Some lines that says
"please include this to RubyInstaller list when you report your
installation problem"
With all that information, I think we covered pretty much the issues
already shown in the group.
Jon
> >
> > rake devkit 7z=1
> >
> > should we move the current 4.5.1 SFX to the Archive page and replace it with a 4.5.1 7z archive? Or simply just add a 4.5.1 7z to the download page? Or do nothing?
> >
>
> The main problem we had on this is that 7z packages should have been
> made available along the SFX. Had problems uploading the devkit to
> GitHub (slow internet).
I've not had upload problems when uploading the DevKit to GitHub. My issue is that I want to be able to automate uploads via upload.rb but haven't looked into it enough to make it part of a new "deploy" recipe.
> I think we need to start putting these things into a more reliable CDN
> than RubyForge on next upload.
Have you (or any one else) had problems downloading the DevKit from our http://rubyinstaller.org/downloads/ page and is currently hosted on GitHub?
> > We'll need to add download code to the current installer, but I'm assuming you've already started looking into some of the existing Inno download codes? ;)
> >
> Yes, but two concerns:
>
> A) Use a stable DevKit at the time we build the installer
>
> or
>
> B) Use a generic 302 redirect for the download URL to download
> possible updated DevKit.
>
> The problem with that could be if we decide to move to a different
> compiler (mingw-w64), these links could fail (or stagnate)
>
> Let's see how it goes ;-)
Let's try the simplest thing that could work and see how it goes. I'll update the installer code to put a "DevKit Download" link on the "Finished" page that goes to http://rubyinstaller.org/downloads/
Jon
---
blog: http://jonforums.github.com/
twitter: @jonforums
Luis Lavena
>
> I've not had upload problems when uploading the DevKit to GitHub. My issue is that I want to be able to automate uploads via upload.rb but haven't looked into it enough to make it part of a new "deploy" recipe.
>
Neither GitHub or RubyForge support resuming uploads. I'm in
Argentina, so for me to upload newer releases need to find a really
stable and good internet connection.
Not that we don't have it, but sometimes things just reboot themselves :-P
I had problems with GitHub form uploader using Chrome and needed to
use Firefox instead.
>
>> I think we need to start putting these things into a more reliable CDN
>> than RubyForge on next upload.
>
> Have you (or any one else) had problems downloading the DevKit from our http://rubyinstaller.org/downloads/ page and is currently hosted on GitHub?
>
Pik doesn't find the download :-P
Also people looking at RubyForge download page don't see it.
>
> Let's try the simplest thing that could work and see how it goes. I'll update the installer code to put a "DevKit Download" link on the "Finished" page that goes to http://rubyinstaller.org/downloads/
>
Cool.
Jon
> >
> Neither GitHub or RubyForge support resuming uploads. I'm in
> Argentina, so for me to upload newer releases need to find a really
> stable and good internet connection.
>
> Not that we don't have it, but sometimes things just reboot themselves :-P
>
> I had problems with GitHub form uploader using Chrome and needed to
> use Firefox instead.
Ugh, no fun.
I'm OK with moving the DevKit's to CloudFront if you're OK with the increase in traffic. Let me know and I'll make the changes. That said, I do like seeing the DevKit download counts on GitHub.
> > Let's try the simplest thing that could work and see how it goes. I'll update the installer code to put a "DevKit Download" link on the "Finished" page that goes to http://rubyinstaller.org/downloads/
> >
>
> Cool.
Here's what it could look like.
Everyone who's got an opinion please test it out to see if how it works via a FakeRubyInstaller at http://db.tt/kxML9CH and weigh in with feedback before I commit to master.
Vít Ondruch
Hm, it points people back to the place where they have probably obtained
the installer, without any further note. Its like going in circles. May
be better destination would be some page, which would explain what
DevKit is, who and why would like to install it.
Vít Ondruch
> On Thu, Jan 20, 2011 at 8:34 PM, V�t Ondruch<v.on...@gmail.com> wrote:
>>> Here's what I have so far.
>>>
>>> https://gist.github.com/788841
>>>
>>> Not top priority, but I'll get it up on github in the next few days.
>>>
>> Nice!
>>
>> * Can we detect somehow DevKit version?
> You get it from gcc.exe --version
This is not precise and might provide unreliable results. If I will
install gcc with the same version, but other tools with different
version ....
>> * Is it possible to know if the Ruby are official release or some unofficial
>> build?
> I don't think so.
>
>> * Can we get somehow the executed command, e.g. "gem install rdiscount
>> --platform=ruby", or is there somewhere visible the "platform" parameter?
>>
> Well, we can get ARGV, but after all, the idea with this output is
> that if the gem fails, the user copy the entire output in the group
> for us to help solve the issue
>
>> * Not sure if the gist is meant as output of gem install or log, but for end
>> user, it would be nice to see some checkboxes, e.g. "gcc ver 4.5.0 .... [ OK
>> ] \n registry entries ..... [ Failed ]", and the details store in log. But I
>> am pretty sure that this is not feasible ;)
>>
> Well, the idea is for us to have enough debugging information, so I
> think OK/FAIL will not help that.
Please don't underestimate user experience. It will not be very helpful
if users will start to send us logs after successful installation with
questions "what does it mens? Is it working now or not?". I see all the
times software done by developer, which functionality might be
wonderful, but the user experience is awful.
This step should tell everybody that he is doing well and he should fell
in charge and secure. I am not saying that it is must, I just saying
that it would be nice and we should not throw the idea even though it
will not be done immediately.
> The theory:
>
> gem install rubyinstaller-test
>
> If it fails, it will output "gem_make.out" to the end user.
>
> This output will be what Gordon has worked. Some lines that says
> "please include this to RubyInstaller list when you report your
> installation problem"
>
> With all that information, I think we covered pretty much the issues
> already shown in the group.
>
Also, we should try to obtain "config.yml" if possible.
Vit
Boško Ivanišević
--
Regards,
Boško Ivanišević
Luis Lavena
>
> Please don't underestimate user experience. It will not be very helpful if
> users will start to send us logs after successful installation with
> questions "what does it mens? Is it working now or not?". I see all the
> times software done by developer, which functionality might be wonderful,
> but the user experience is awful.
>
I don't underestimate UX, I do that every day at my work.
The only way all this information will be presented to the user is
*if* the gem fails to compile, and that information is what we need to
help the user solve the issue.
> Also, we should try to obtain "config.yml" if possible.
>
I think is possible as long config.yml is generated in the DevKit
folder (which is relative to bin and mingw/bin by "..")
Luis Lavena
>
> Hm, it points people back to the place where they have probably obtained the
> installer, without any further note. Its like going in circles. May be
> better destination would be some page, which would explain what DevKit is,
> who and why would like to install it.
>
Please suggest a "copy" of the text that needs to live in that page
(let's say downloads/devkit)
Then we can put that live and point the link there.
Jon
> > the installer, without any further note. Its like going in circles. May be
> > better destination would be some page, which would explain what DevKit is,
> > who and why would like to install it.
>
> I agree. Users will probably be confused because they've already downloaded
> installer from the same page. Pointing to new page just for DevKit would be
> better.
Good point. Which of these links do you prefer over using the downloads page?
1) http://rubyinstaller.org/add-ons/devkit/
2) https://github.com/oneclick/rubyinstaller/wiki/Development-Kit
(1) could use some editing to clean it up while (2) would need at least a download link near the top of the text.
Jon
> >> user, it would be nice to see some checkboxes, e.g. "gcc ver 4.5.0 .... [ OK
> >> ] \n registry entries ..... [ Failed ]", and the details store in log. But I
> >> am pretty sure that this is not feasible ;)
> >>
> > Well, the idea is for us to have enough debugging information, so I
> > think OK/FAIL will not help that.
>
> Please don't underestimate user experience. It will not be very helpful
> if users will start to send us logs after successful installation with
> questions "what does it mens? Is it working now or not?". I see all the
> times software done by developer, which functionality might be
> wonderful, but the user experience is awful.
>
> This step should tell everybody that he is doing well and he should fell
> in charge and secure. I am not saying that it is must, I just saying
> that it would be nice and we should not throw the idea even though it
> will not be done immediately.
Are you suggesting two levels of output, a "summary" for end-users and "details" in a log to help with debugging if needed?
For example, the end user might see after running "gem install rubyinstaller-test":
checking for gcc... gcc (tdm-1) 4.5.1
checking for make... GNU Make 3.81
...
while a generated gem_make.out would look more like Gordon's gist.
> Also, we should try to obtain "config.yml" if possible.
Agreed.
Remember that with the current dk.rb install script I've added the RI_DEVKIT environment variable to each of the three key usage scenarios:
* gem install your_gem [--platform=ruby]
* ruby -rdevkit extconf.rb
* C:\DevKit\devkitvars.bat
This env var contains the DevKit's root install dir and could be used to grab config.yml *assuming* the user has run "ruby dk.rb install" from the DevKit install dir. All bets are off on config.yml being in the DevKit root dir if someone did something similar to:
C:\tools>ruby \DevKit\dk.rb init
...as config.yml is now in the current dir as C:\tools\config.yml
André Caron
> On Thu, Jan 20, 2011 at 6:50 PM, André Caron <andre....@gmail.com> wrote:
>>
>> Is it a technical or political reason?
>>
>
> Both. Not everybody needs to compile gems and even with a compiler,
> not all gem will compile due missing dependencies, so is the same you
> have a compiler or not. mkmf will generate you a cryptic error.
>
> "gem install" is part of RubyGems, that shouldn't be root of confusion.
>
> At least now, when you don't have a compiler, you get a friendlier message.
Agreed, I've noticed and this IS cool :-)
> The bundling of DevKit has been discussed several times on the list to
> which I have responded. I've blogged about it too:
>
> http://blog.mmediasys.com/2010/09/23/rubyinstaller-what-where-when-1/
>
> Quote: "(in relation to bundling DevKit with the installer) I
> personally don’t believe that will fix the education and lack of
> documentation problem, it will just make the installers 12MB bigger."
No, it wouldn't fix lack of documentation or education. However, gem
developers currently have the option of distributing extensions as
source because it makes their lives easier (don't need access to
machines of all platforms). Ironically, the very existence of the
DevKit encourages gem developers to distribute from source. I see
increasing dependency on the DevKit as it matures. It's a vicious
circle. More and more gems with C extensions will be made available
because it is becoming convenient for everyone. The better this
project gets, the more it will be used.
> On other platforms you still need to install a compiler (Xcode,
> build-essentials) that is not out of the box. Also, on these
> platforms, you need to install development packages to be able to
> install certain gems, that is the same here.
>
> So, since all platforms suffer the same, what is the problem? IMO
> education and documentation.
>
> --
> Luis Lavena
> AREA 17
Just because other suppliers don't do it well, doesn't mean you should
do as bad as they do. Also, I'm under the impression that it is more
convenient for Linux (and possibly Mac, I'm not familiar) users to
install a development environment using their usual package manager.
If there was a standard package manager for Windows in quasi-universal
use and MinGW was available through it, I don't believe there would be
a need for the DevKit in the first place because the RubyInstaller
"package" could simply require "package MinGW version X".
Regards,
André Caron
Luis Lavena
>
> No, it wouldn't fix lack of documentation or education. However, gem
> developers currently have the option of distributing extensions as
> source because it makes their lives easier (don't need access to
> machines of all platforms). Ironically, the very existence of the
> DevKit encourages gem developers to distribute from source. I see
> increasing dependency on the DevKit as it matures. It's a vicious
> circle. More and more gems with C extensions will be made available
> because it is becoming convenient for everyone. The better this
> project gets, the more it will be used.
>
The DevKit is made available as convenience to work around certain
gems, but not all are granted to work.
Specially the ones that depends on 3rd parties (headers and libs).
That is why I took the time to build rake-compiler. so gem authors can
see what others will see when installing their gems on Windows.
Binary gems are the solution there.
> Just because other suppliers don't do it well, doesn't mean you should
> do as bad as they do. Also, I'm under the impression that it is more
> convenient for Linux (and possibly Mac, I'm not familiar) users to
> install a development environment using their usual package manager.
Until you need a library that your distribution/supplier don't have,
and you need to compile it by hand and figure out other dependencies
it needs.
--
Luis Lavena
AREA 17
Jon
> some flag how to enable debugging informations, but anyway, how to use
> GDB than? On command line? So may be some tutorial would be good
> starting point, however, something like Visual Studio solution (but you
> can substitute your favourite IDE instead) would help in my opinion.
While there are good GDB tutorials out there, we could certainly use a RubyInstaller specific version. I've been meaning to write one up showing how to use the GDB included with the DevKit to track down a NULL/uninitialized pointer induced segfault from a native C RubyGem.
If that's useful, I'll bump it up on my TODO list.
If anyone beats me to it, please post a link on https://github.com/oneclick/rubyinstaller/wiki/Tutorials tweet it and do an ANN here.
IIRC, our current build recipes use the "-g" debugging flag for at least Ruby. It may make sense to change that to "-ggdb3", but I'd like to hear Luis' feedback.
> I would love to see plain old 7z archive, same as Ruby itself is provided.
I will build a 7z DevKit archive and make available from our download page. Anyone can do the same via "rake devkit 7z=1"
> Btw, ideal state of RubyInstaller on Windows would be "Pik on steroids".
> I imagine it at least as Pik which smoothly works without any Ruby
> present on your computer, allowing you to selectively install which
> version of Ruby you want, which Devkit, etc. So at the end only Pik
> would be installed and the rest would be just some archives managed by
> Pik. Pik could stay command line only, or would be extended by fancy GUI.
Ah, so that's Pik's world domination plan. Cool. So Gordon, you're planning to embed FxRuby in Pik? ;)
Gordon Thiesfeld
>> I would love to see plain old 7z archive, same as Ruby itself is provided.
>
> I will build a 7z DevKit archive and make available from our download page. Anyone can do the same via "rake devkit 7z=1"
>
FWIW, 7zip can open the sfx file just fine. ;-)
>
>> Btw, ideal state of RubyInstaller on Windows would be "Pik on steroids".
>> I imagine it at least as Pik which smoothly works without any Ruby
>> present on your computer, allowing you to selectively install which
>> version of Ruby you want, which Devkit, etc. So at the end only Pik
>> would be installed and the rest would be just some archives managed by
>> Pik. Pik could stay command line only, or would be extended by fancy GUI.
>
> Ah, so that's Pik's world domination plan. Cool. So Gordon, you're planning to embed FxRuby in Pik? ;)
>
I have no such plans. I'm quite content with my command line. If
someone else would like to, more power to them ;-)
Vít Ondruch
>>> Hm, it points people back to the place where they have probably obtained
>>> the installer, without any further note. Its like going in circles. May be
>>> better destination would be some page, which would explain what DevKit is,
>>> who and why would like to install it.
>>
>> I agree. Users will probably be confused because they've already downloaded
>> installer from the same page. Pointing to new page just for DevKit would be
>> better.
> Good point. Which of these links do you prefer over using the downloads page?
>
> 1) http://rubyinstaller.org/add-ons/devkit/
The rubyinstaller.org looks better for me. While wiki is nice, because
everybody could help, rubyinstaller page looks more professional. From
there, there could be link to Github wiki.
However, the description should stress something in this sense: "Please
note that while you can smoothly install and compile gems with simple
native extensions, such as rdiscount, DevKit doesn't automatically
ensure, that you will be able to install every gem with binary
extension. This is because gems such as nokogiri requires additional
development dependencies, such libXml header files and libraries." Take
the nokogiri just as an example. I have never tried to built it, so may
be some other example should be chosen.
Vít Ondruch
>>>> * Not sure if the gist is meant as output of gem install or log, but for end
>>>> user, it would be nice to see some checkboxes, e.g. "gcc ver 4.5.0 .... [ OK
>>>> ] \n registry entries ..... [ Failed ]", and the details store in log. But I
>>>> am pretty sure that this is not feasible ;)
>>>>
>>> Well, the idea is for us to have enough debugging information, so I
>>> think OK/FAIL will not help that.
>> Please don't underestimate user experience. It will not be very helpful
>> if users will start to send us logs after successful installation with
>> questions "what does it mens? Is it working now or not?". I see all the
>> times software done by developer, which functionality might be
>> wonderful, but the user experience is awful.
>>
>> This step should tell everybody that he is doing well and he should fell
>> in charge and secure. I am not saying that it is must, I just saying
>> that it would be nice and we should not throw the idea even though it
>> will not be done immediately.
> Are you suggesting two levels of output, a "summary" for end-users and "details" in a log to help with debugging if needed?
>
> For example, the end user might see after running "gem install rubyinstaller-test":
>
> checking for gcc... gcc (tdm-1) 4.5.1
> checking for make... GNU Make 3.81
> ...
>
> while a generated gem_make.out would look more like Gordon's gist.
>
>
Yes! Yes please! :) That would be wonderful.
>> Also, we should try to obtain "config.yml" if possible.
> Agreed.
>
> Remember that with the current dk.rb install script I've added the RI_DEVKIT environment variable to each of the three key usage scenarios:
>
> * gem install your_gem [--platform=ruby]
> * ruby -rdevkit extconf.rb
> * C:\DevKit\devkitvars.bat
>
> This env var contains the DevKit's root install dir and could be used to grab config.yml *assuming* the user has run "ruby dk.rb install" from the DevKit install dir. All bets are off on config.yml being in the DevKit root dir if someone did something similar to:
>
> C:\tools>ruby \DevKit\dk.rb init
>
> ...as config.yml is now in the current dir as C:\tools\config.yml
Yes, there might be some cavities, however this is advanced scenario
which should not come into play if user follows our installation step.
And if this fails, it is also good sign that we know that the user was
doing something non-standard (I am not saying wrong :)).
Luis Lavena
>
> The rubyinstaller.org looks better for me. While wiki is nice, because
> everybody could help, rubyinstaller page looks more professional. From
> there, there could be link to Github wiki.
>
> However, the description should stress something in this sense: "Please note
> that while you can smoothly install and compile gems with simple native
> extensions, such as rdiscount, DevKit doesn't automatically ensure, that you
> will be able to install every gem with binary extension. This is because
> gems such as nokogiri requires additional development dependencies, such
> libXml header files and libraries." Take the nokogiri just as an example. I
> have never tried to built it, so may be some other example should be chosen.
>
What about:
"Please not that certain gems might require external dependencies
(headers and libraries) required for successful installation. If these
aren't present, the installation will fail. For those cases, please
refer to the gem documentation to know which dependencies are
missing."
As for nokogiri, it uses:
zlib
iconv
libxml2
libxslt
Which Aaron Patterson managed to cross compile when creating the gem:
https://github.com/tenderlove/nokogiri/blob/master/tasks/cross_compile.rb
Is not for the faint of heart :(
Vít Ondruch
> On Sat, Jan 22, 2011 at 12:05 PM, V�t Ondruch<v.on...@gmail.com> wrote:
>> The rubyinstaller.org looks better for me. While wiki is nice, because
>> everybody could help, rubyinstaller page looks more professional. From
>> there, there could be link to Github wiki.
>>
>> However, the description should stress something in this sense: "Please note
>> that while you can smoothly install and compile gems with simple native
>> extensions, such as rdiscount, DevKit doesn't automatically ensure, that you
>> will be able to install every gem with binary extension. This is because
>> gems such as nokogiri requires additional development dependencies, such
>> libXml header files and libraries." Take the nokogiri just as an example. I
>> have never tried to built it, so may be some other example should be chosen.
>>
> What about:
>
> "Please not that certain gems might require external dependencies
> (headers and libraries) required for successful installation. If these
> aren't present, the installation will fail. For those cases, please
> refer to the gem documentation to know which dependencies are
> missing."
That is also good, but I would like to see there some examples. Because
then the user can experiment:
gem install rdiscount ..... hmm, works, nice
gem install nokogiri .... FAILURE! ahhh, so that is what they are
speaking about
> As for nokogiri, it uses:
>
> zlib
> iconv
> libxml2
> libxslt
>
> Which Aaron Patterson managed to cross compile when creating the gem:
> https://github.com/tenderlove/nokogiri/blob/master/tasks/cross_compile.rb
>
> Is not for the faint of heart :(
>
Well, nokogiri is probably bad example, because it "just works" on
Windows, but I could't come with any better :) So please substitute
nokogiri with something more appropriate ..
Vit
Luis Lavena
>>
>> For example, the end user might see after running "gem install
>> rubyinstaller-test":
>>
>> checking for gcc... gcc (tdm-1) 4.5.1
>> checking for make... GNU Make 3.81
>> ...
>>
>> while a generated gem_make.out would look more like Gordon's gist.
>>
>>
>
> Yes! Yes please! :) That would be wonderful.
>
Don't want to kill your unicorns, but that is not possible.
RubyGems runs the extension configure and make process in silence, so
no output is shown unless there is an error, which will output what
gem_make.out contains to the end user.
Sorry for not making myself clear when I responded to your OK/FAIL
email, but I refer to this limitation when answered you.
Since after all the end user will see the gem_make.out contents, why
bother doing a short and a verbose options?
Vít Ondruch
> On Sat, Jan 22, 2011 at 12:11 PM, V�t Ondruch<v.on...@gmail.com> wrote:
>>> For example, the end user might see after running "gem install
>>> rubyinstaller-test":
>>>
>>> checking for gcc... gcc (tdm-1) 4.5.1
>>> checking for make... GNU Make 3.81
>>> ...
>>>
>>> while a generated gem_make.out would look more like Gordon's gist.
>>>
>>>
>> Yes! Yes please! :) That would be wonderful.
>>
> Don't want to kill your unicorns, but that is not possible.
>
> RubyGems runs the extension configure and make process in silence, so
> no output is shown unless there is an error, which will output what
> gem_make.out contains to the end user.
>
Hm, thats sad :( I don't know how I will survive that ;) Sorry, just
joking ... it was just brainstorming
> Sorry for not making myself clear when I responded to your OK/FAIL
> email, but I refer to this limitation when answered you.
>
> Since after all the end user will see the gem_make.out contents, why
> bother doing a short and a verbose options?
>
Well, what could be nice about this short output on the screen is that
the user would not need to check the gem_make.out contents. Why bother
with the file if you can clearly see on the screen that something was ok
or not. The log will contain probably more informations then necessary
for quick overview.
But of course we can start somewhere and then improve if possible. If we
have log, super, if we have concise screen output, better ...
Vit
Boško Ivanišević
Jon
> >> rubyinstaller-test":
> >>
> >> checking for gcc... gcc (tdm-1) 4.5.1
> >> checking for make... GNU Make 3.81
> >> ...
> >>
> >> while a generated gem_make.out would look more like Gordon's gist.
> >>
> >
> > Yes! Yes please! :) That would be wonderful.
> >
>
> Don't want to kill your unicorns, but that is not possible.
I was thinking of a pre_install Ruby-only hook that would scroll out some key info to the end-user before the actual extension configure process was run. This assumes a few key things, but I'll try the idea out with a native gem I've just built for showing how to debug segfaults with GDB.
Jon
> >> everybody could help, rubyinstaller page looks more professional. From
> >> there, there could be link to Github wiki.
Thanks and http://rubyinstaller.org/add-ons/devkit/ it is.
I'll update the page and the installer recipes as appropriate.
Luis Lavena
>
> I was thinking of a pre_install Ruby-only hook that would scroll out some key info to the end-user before the actual extension configure process was run. This assumes a few key things, but I'll try the idea out with a native gem I've just built for showing how to debug segfaults with GDB.
>
The first thing it assumes is that pre_install hooks will need to be
*before* the gem installs :-P
I see the following UX:
1. Installed RubyInstaller
2. gem install rdiscount
(or any gem that doesn't have binaries)
3. User get instructions to download the DevKit and install it
4. User install DevKit and follows instructions, last step is:
5. gem install rubyinstaller-test
A) If gem succeed on installation, post_install message will be displayed:
"Awesome, your environment is ready to roll!, please remember blah blah blah"
B) If gem installation fails, RubyGems outputs automatically the
contents of gem_make.out to the terminal.
gem_make.out will contain all the things extconf.rb of the gem did,
even puts that showed certain information.
The first lines (or last ones) fo gem_make.out should contain a notice
about "We encountered a problem, please copy all this information and
report it back to RubyInstaller group for us to assist you."
In that information, we can have PATH split in multiple lines for
readability, version of GCC, version of make. If mingw32-make is in
the path, version of Ruby, etc.
The extension itself doesn't need to be more complicated than this:
https://github.com/luislavena/test-ruby-c-extension
And we can even "fake" the error doing:
gem install rubyinstaller-test -- --enable-failure
(Or similar option, something that mkmf supports)
James Cowlishaw
James.
On 22 Jan 2011, at 22:18, Luis Lavena <luisl...@gmail.com> wrote:
> B) If gem installation fails, RubyGems outputs automatically the
> contents of gem_make.out to the terminal.
>
> gem_make.out will contain all the things extconf.rb of the gem did,
> even puts that showed certain information.
>
> The first lines (or last ones) fo gem_make.out should contain a notice
> about "We encountered a problem, please copy all this information and
> report it back to RubyInstaller group for us to assist you."
>
I know we're talking about a command line utility & environment. But why not output this to HTML with a mailto: link with the to, subject and body of the message populated with the failure report? Then launch a browser to display it?
Just a thought, might reduce partial copy and paste errors from consoles with short scrollback etc.
James.
Luis Lavena
>
> I know we're talking about a command line utility & environment. But why not output this to HTML with a mailto: link with the to, subject and body of the message populated with the failure report? Then launch a browser to display it?
>
> Just a thought, might reduce partial copy and paste errors from consoles with short scrollback etc.
>
extconf.rb is the only place we can execute Ruby code, and extconf.rb
happens before make and gcc are invoked and executed.
Past issues related with gem installation indicates that the
installation issues or conflicts happen *before* extconf.rb is
executed (Julie smoke test fail a few days ago) or *after* extconf.rb
during make or GCC having issues to find headers or fire cc1.exe
So, there is no way to produce what you're suggesting without
modifying RubyGems (who is controlling the whole process)
James Cowlishaw
On Sat, Jan 22, 2011 at 7:35 PM, James Cowlishaw <cowl...@gmail.com> wrote:extconf.rb is the only place we can execute Ruby code, and extconf.rb
>
> I know we're talking about a command line utility & environment. But why not output this to HTML with a mailto: link with the to, subject and body of the message populated with the failure report? Then launch a browser to display it?
>
> Just a thought, might reduce partial copy and paste errors from consoles with short scrollback etc.
>
happens before make and gcc are invoked and executed.
Past issues related with gem installation indicates that the
installation issues or conflicts happen *before* extconf.rb is
executed (Julie smoke test fail a few days ago) or *after* extconf.rb
during make or GCC having issues to find headers or fire cc1.exe
So, there is no way to produce what you're suggesting without
modifying RubyGems (who is controlling the whole process)
André Caron
> On Thu, Jan 20, 2011 at 6:59 PM, André Caron <andre....@gmail.com> wrote:
>>
>> How about a procedure for shipping a Ruby script as a standalone
>> install? The only tools in that spirit I've seen so far are
>> RubyScript2Exe (http://www.erikveen.dds.nl/rubyscript2exe/) and
>> AllInOneRuby (http://www.erikveen.dds.nl/allinoneruby/) which are both
>> outdated. Further, I don't believe any compilation of ruby to native
>> code is necessary.
>>
>
> These are not the only tools:
>
> Ocra:
>
> http://ocra.rubyforge.org/
>
> exerb:
>
> http://vert.igino.us/2011/01/05/exerb-101-building-windows-executables-with-ruby/
>
> --
> Luis Lavena
> AREA 17
Thanks Luis!
I tried both of these and Ocra seems to fit the bill, it is *exactly*
what I was looking for. 'exerb' happens to have trouble with bundling
RedCloth because of resource files that can't be bundled easily with
their technique. I hope it eventually overcomes this limitation, I
like it's implementation a lot!
Anyhow, thanks for the help!
Regards,
André Caron
Jon
> >
>
> The first thing it assumes is that pre_install hooks will need to be
> *before* the gem installs :-P
Yes, and that may be possible by having rubyinstaller-test gem dependent upon a rubyinstaller-canary gem which has a pre_install hook as part of lib/rubygems_plugin.rb. The pre-install hook should be smart enough to run only if certain gems (rubyinstaller-test) are being installed rather than run on every install.
I'm playing with a couple of ideas to see if it *actually* works because I want (a) some summary output, and (b) an install that's as easy as doing "gem install rubyinstaller-test" that installs the "rubyinstaller-canary" dependent gem which installs a pre_install hook available to run *before* the rubyinstaller-test install. The dependent gem idea may be needed because I can't get pre_install hooks defined in a plugin *of the gem being installed* to work. It makes sense that they wouldn't but it also may be my mistakes.
One things for certain, I can't do what I want in extconf.rb because of lines like the following in Gem::Ext::Builder
result << `#{command} #{redirector}`
It's definitely a unicorn, but I'm chasing it through the woods at the moment. ;)
> I see the following UX:
>
> 1. Installed RubyInstaller
> 2. gem install rdiscount
> (or any gem that doesn't have binaries)
> 3. User get instructions to download the DevKit and install it
> 4. User install DevKit and follows instructions, last step is:
> 5. gem install rubyinstaller-test
Agreed, and if the my idea works I would like to see a summary of config-like messages (3-5) scroll past like
checking for DevKit... C:\DevKit
checking for gcc... gcc (tdm-1) 4.5.1
along with the post_install message upon success or gem_make.out upon failure.
> The extension itself doesn't need to be more complicated than this:
>
> https://github.com/luislavena/test-ruby-c-extension
>
> And we can even "fake" the error doing:
>
> gem install rubyinstaller-test -- --enable-failure
Will check it out...
Luis Lavena
>> > I was thinking of a pre_install Ruby-only hook that would scroll out some key info to the end-user before the actual extension configure process was run. This assumes a few key things, but I'll try the idea out with a native gem I've just built for showing how to debug segfaults with GDB.
>> >
>>
>> The first thing it assumes is that pre_install hooks will need to be
>> *before* the gem installs :-P
>
> Yes, and that may be possible by having rubyinstaller-test gem dependent upon a rubyinstaller-canary gem which has a pre_install hook as part of lib/rubygems_plugin.rb. The pre-install hook should be smart enough to run only if certain gems (rubyinstaller-test) are being installed rather than run on every install.
>
gem plugins are loaded once when gem runner is loaded, so a double
dependency cannot be executed.
I think we are overly complicating the whole thing. Showcase a summary
information "as it goes" provides no value for the end user. Is a
lovely idea, but I don't see it's purpose and taking in consideration
the technical facts around RubyGems, I think is a waste of effort.
Again, personal opinion.