Hi Zeno,
I'd like to better understand what you are requesting.
1) Are you asking for a custom RubyInstaller .exe (not .7z archive) in which the only difference from the 1.8.6 version we currently provide is the Onigurma patch applied?
2) Are you asking that this project continue to support (1) as we do with the other RubyInstallers? Or is this a custom build that you'd maintain and support?
3) Why 1.8.6 rather than 1.8.7? Does the patch apply successfully to 1.8.7 when building from Linux?
4) Have you tried cloning our git://github.com/oneclick/rubyinstaller.git repo, applying the patch, and building a 1.8.6 installer on your system? Any issues?
Jon
Have you looked at the Oniguruma gem[1]? I'm using it with 1.8.7, and
I could write up the steps needed to install the Oniguruma gem, if
that sounds like a good alternative.
Gordon
Understood and it makes a lot of sense especially for those who still want to use 1.8.6.
The key issue I have is that you'd not use the "RubyInstaller" or "OneClick" names for the custom installer you'd support as this could lead to a lot of confusion in that users might come to this project and want support that we wouldn't be able to provide. I think that would be very frustrating to all involved.
That said, Luis is the project manager of the RubyInstaller and his perspective on the naming issue is the one that's final :)
> > 4) Have you tried cloning our git://github.com/oneclick/rubyinstaller.git repo, applying the patch, and building a 1.8.6 installer on your system? Any issues?
>
> No have not done that yet. I am looking into the README now. We
> successfully applied the patch today on Cygwin. But what I want is a
> clean Ruby-1.8.6-Oniguruma.exe Installer. One click and Ruby 1.8.6
> with the Patch should be installed.
I think you'll find that we've structured the build recipes in such a way that they're fairly easy to use and customize. They should provide the quickest way to build your custom installer. Hopefully :)
After you've tried the recipes and see how they work for you, let us know if you have any problems or further questions.
Jon
Please ensure that autocrlf is set to false in your checkout of
rubyinstaller, patches are very sensitive about line endings and an
incorrect checkout will produce this.
>
> Thanks so far. Question: In which directory would I have to put the
> patch? Can you provide me with a short howto for going about? I am
> willing to pay for that as well.
>
Take a look to how other packages like libffi or openssl contains the
patches, these are basically diffs applied to the extracted source
code that needs to be compatible with "git apply" command.
--
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
Yikes, looks like you have git on PATH so the easy fix is out. I never use or build 1.8.6 anymore, but let me try it on my machine this afternoon.
BTW, the above will try to build 1.8.6-p398 because of https://github.com/oneclick/rubyinstaller/blob/master/config/ruby_installer.rb#L46 This can be overridden in a few ways, but lets see if I can replicate your failure on my Win7 box.
Don't wait on me to get back with you...try putting a .rb file into <RUBYINSTALLER_DIR>\override and do something similar to the following in which you override the relevant parts of https://github.com/oneclick/rubyinstaller/blob/master/config/ruby_installer.rb#L18-51 and bypass the COMPAT command line flag. Force the 1.8 build recipe to download and use the right 1.8.6 patch level you need.
# file: override\rbreadline_updates.rb
if ENV['RBREADLINE'] then
puts '[INFO] Overriding to use updated rbreadline...'
RubyInstaller::PureReadline.url = 'https://github.com/downloads/luislavena/rb-readline'
RubyInstaller::PureReadline.files = [ 'rb-readline-0.3.0.zip' ]
end
> > After you've tried the recipes and see how they work for you, let us know if you have any problems or further questions.
>
> I will try some more asap.
>
> Thanks so far. Question: In which directory would I have to put the
> patch? Can you provide me with a short howto for going about? I am
> willing to pay for that as well.
We put the actual patches in https://github.com/oneclick/rubyinstaller/tree/master/resources/patches and then have specific build recipes apply the patch.
For example, here's the openssl patch part of the recipe https://github.com/oneclick/rubyinstaller/blob/master/recipes/dependencies/openssl.rake#L34-40
We normally do not patch up the Ruby source, but recently Luis needed to patch 1.9 for a serious issue regarding registry access. He added https://github.com/oneclick/rubyinstaller/blob/master/recipes/interpreter/ruby19.rake#L72-76 to the 1.9 build recipe and you'd likely need to do something similiar to the 1.8 recipe, but I've not looked at the 1.8 recipe at https://github.com/oneclick/rubyinstaller/blob/master/recipes/interpreter/ruby18.rake
Jon
something like:
C:\Users\Jon\Documents\RubyDev>git config --global --list
core.editor=c:/vim/vim73/gvim.exe
core.autocrlf=false
color.ui=auto
user.name=Jon
...
I'm all for keeping git on PATH :) I use the latest msysgit (1.7.3.1) and put C:\git\cmd on PATH and it Just Works using Command Prompt and Console2 shells. My earlier feedback was simply showing you git's autocrlf setting that Luis suggested.
Jon
You can select the medium option (which is checkout as is, commit as
LF) or the 3rd option which equals to setting autocrlf to false.
An easy way to set it is to edit your %USERPROFILE%\.gitconfig to include something like:
[core]
editor = c:/vim/vim73/gvim.exe
autocrlf = false
[color]
ui = auto
[push]
default = current
...
Jon
rd sandbox /s/q
rake devkit DKVER=mingw-32-3.4.5
rake ruby18 COMPAT=1
See my previous comment on this thread: Ruby 1.8.6 is not compatible
with our GCC 4.5.1, you need GCC 3.4.5.
Permission issues happen when you have antivirus software running or a
Windows explorer monitoring that folder (or any open editor or program
that might be locking the tree)
Please see in the group, this was mentioned before.
Also, disable Windows indexing for the build folders as it often causes frustrating random build failures.
> Now to the Oniguruma patch. Can I just wrap a recipe around the Linux-
> Oniguruma-Patch or will that not work? As I understand that will not
> work as simple as it worked with Cygwin.
Try the following first before you spend time building a recipe. If it works, it's your quickest solution I think.
WARNING...I haven't tried this as I don't use 1.8.x, but it's similar enough to how I do regular 1.9 and trunk builds from a local ruby git repo:
* download ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p369.tar.bz2 and extract it to somewhere, say c:\build\ruby
* apply your patches
* cd to <RUBYINSTALLER_BASE_DIR> and type the following...this _should_ cause the recipes to build from your patched 1.8.6-p369 version in c:\build\ruby rather than trying to download ruby
rake ruby18 dkver=mingw-32-3.4.5 local="C:\build\ruby"
Jon
Hello,
Don't want to be a jerk, but a patch for a specific patchlevel will
not apply to latest.
At minimum I recommend you read RubyInstaller's README for
instructions, better yet, read the code to understand what is doing.
Also, all this trouble and seems you're very anxious, why not try oniguruma gem?
https://rubygems.org/gems/oniguruma
Gordon already mentioned that before and you ignored and insisted on
the patch-path.
At least provide an answer of "tried that didn't work"...
Can I ask why? Doesn't install, doesn't contain what are you
requiring? Can you be more specific?
>> https://rubygems.org/gems/oniguruma
>>
>> Gordon already mentioned that before and you ignored and insisted on
>> the patch-path.
>
> We need Regexp-lookbehind.
>
I believe that is what the gem provides.
> The simple reason is: Our software runs on Linux with Ruby-1.8.6 with
> the Oniguruma-Patch. We are not using the gem because it does not work
> in Linux for us.
>
Did you install oniguruma library dependency? Asking all this because
if is not clear for you how the patching works, we are going to be in
a thread of 200 messages without any real progress...
> I want some consistency in our Apps, cross-plattform.
>
Consistency can be achieved differently, the patched version of Ruby
seems too brittle from my point of view.
I don't trust myself, asked politely because most of the times the
complicated path can be solved more simpler.
>> Did you install oniguruma library dependency? Asking all this because
>> if is not clear for you how the patching works, we are going to be in
>> a thread of 200 messages without any real progress...
>
> No, because the patch works fine on Linux.
>
I just looked in the massive patch file you provided, and is not clear
how to get that working.
Your request for help is not very convincing for me as is not clear
(sounds convoluted).
If you can provide, in a logical fashion the steps you (or one of your
developers/co-workers) did for this special Ruby compilation, I could
take a look to it.
But, just to clarify:
* You can extract Ruby into any folder (any version of Ruby)
* You can apply the patch yourself to it (however that is done)
* Then you can compile ruby with "rake ruby18
LOCAL=C:\Path\To\Your\Patched\Ruby"
These patches are svn patches, we no longer bundle with patch utiltiy
and instead we use git apply to avoid UAC warnings.
If you transform these patches to git diff format, git apply should work.
>
> http://dev.ywesee.com/wiki.php/Masa/20100907-install-ruby#oniguruma
>
Following these instructions can work too, you just need a few steps before:
the make 186 will need to be modified to do "git apply" instead of
patch, as patch is not integrated OR download patch for windows:
http://gnuwin32.sourceforge.net/packages/patch.htm
Then:
rake ruby18:dependencies devkit:sh
That should give you a bash shell where you can apply the patches, etc.
This onigumura patch/hack is tricky, worked on Linux because you have
installed all your dependencies before, but on Windows, there is no
dependency (zlib or any other is not bundled with the OS), so
RubyInstaller have recipes for that.
I can't help you further as this tricky thing is time consuming and
time is something I lack right now.
To generate the installers and compile you're pretty close, you just
need read the code and time and patience (which for the flood of
emails looks like you're running out).
Hope above helps you.
Ensure you've got Inno http://www.innosetup.com/isdl.php installed, both isetup and ispack (only need the pre-processor installed from ispack) if you want to build the .exe installer. Looks like you may be close :)
Jon
Have you tested that the ruby actually contains the patch and is working?
Asking this because the "make 186" from the onigumura download copies
a lot of files, not just the patch files.
Once you test that you can create the executable with "rake
ruby18:package RELEASE=onigumura"
Again, as mentioned before, I don't recommend creating the installer
or even distribute them. I would recommend you take
sandbox/ruby18_mingw (where Ruby was compiled) and compress it with
7zip or WinZip and distribute internally in your company.
Building installers that could be distributed in the wild and
installed by others will bring lot of folks with questions since
menus, shortcuts and instructions of the installer points to
RubyInstaller (since you haven't mention you modified them).
ruby18_build is where the configure and make process of Ruby is held.
ruby_1_8 contains the extracted source code of the ruby package you
donwloaded and where patches should have been applied.
ruby18_mingw is the target of "make install" and is a standalone
portable version of the Ruby as distributed in the official
installers.
Everything that is in that folder should work on any other computer as
long 'bin' directory is in the PATH.
>
> But what I need to do now is start up my application that is a gem and
> it is in
>
> C:\Ruby186\lib\ruby\gems\1.8\gems\de.oddb-2.0.0\bin\oddbd
>
> and I have a lot of other gems that are in
>
> C:\Ruby186\lib\ruby\gems\1.8\gems
>
> that I need for oddbd start up to work.
>
You need to consider ruby18_mingw a *new* Ruby installation and
install the gems into it, do not copy things from your existing
installation as things are different and will not prove that this
version of Ruby works as expected.
>
> but my new Ruby-Oniguruma-Version that is now installed in
>
> C:\Program Files\Ruby_1.8.6-p369-oniguruma\ruby.exe
>
I have no idea why you installed inside Program Files. RubyInstaller
installer script do not select program files, and dunno why you
selected it.
>
>> Again, as mentioned before, I don't recommend creating the installer
>> or even distribute them. I would recommend you take
>> sandbox/ruby18_mingw (where Ruby was compiled) and compress it with
>> 7zip or WinZip and distribute internally in your company.
>
> Yes, sounds very reasonable. But first I need to know that it works.
>
So copy ruby18_mingw into a different folder (C:\Ruby186-Mine) and add
C:\Ruby186-Mine\bin to the PATH and install gems and your application
into it.
The patch is not the issue, checking the steps from the linux link you
provided, you're missing "make 186" from the onigumura extracted
folder.
Opening the makefile I saw it also copes several onigumura files to
replace the Ruby ones. Also check that before rebuild.
Yes, task "186" depends on cpruby task and the patch command.
So first it copies the files from onigumura (which you can manually
copy) and then it applies the patch.
I don't think a script is needed now, just getting it working first
and then you can automate or document it later.
configure is a bash script, and for that you need to execute inside a
bash/sh shell, that is why I told you about devkit:sh rake task.
Pseudo steps to get this done:
* Extract ruby .tar package into a clean directory (called it C:\Source-Ruby)
* Extract onigumura somehere (call it C:\onigumura)
* Download patch.exe and place it somewhere in the PATH
* Inside RubyInstaller, invoke rake devkit:sh
* cd to /c/onigumura
* ./configure and point to /c/Source-Ruby
* make 186
* exit
* Now proceed with "rake ruby18 LOCAL=C:\Source-Ruby
From there, you will end with sandbox\ruby18_mingw, that is a working
Ruby installation, use that for testing (as explained before)
Something along these lines should do the trick. The key point is
onigumura configure and make do the right thing, I can't confirm how
that will work, up to you now.
Is the Ruby-1.8.6-onigumura your installation directory? Then I will
say yes, remove it to avoid any possible leftover interfere.
We don't want any of these things produce a fluke of results than then
make you loose hair when installing in X number of machines and things
not working.
You need to always scratch and start from zero to reproduce as close
as possible the end-user scenario.
Good to know.
>
> So now Luis we have to discuss how we want to distribute this. I
> believe there is a big demand out there for a Windows-Ruby-
> Installer-1.8.6 with the Oniguruma Patch applied for _Windows_.
>
Where are your sources about that? (links, requests)
The patch itself is a big change from Ruby mainline, which goes
against RubyInstaller rules (less deviation from source).
I personally not going to consider such level of deviation (and the
manual steps required) just to get this patch in.
From what I see on onigumura gem, it is suppose to do the same thing
(depends on a fully working onigumura) and not patching Ruby. The only
difference is that you don't refer things as Regexp but instead use
Onigumura regexp.
Please note that that specific patchlevel might not contain needed
fixes for Windows, which was required for Ruby to work properly (see
the ChangeLog file for differences between p398 and p369)
You need to compile and install onigumura first. That is a dependency
of the gem:
For example, in Mac OSX, it didn't install either, so needed to
install it first:
https://gist.github.com/769679
Same applies to Windows.
>> Please note that that specific patchlevel might not contain needed
>> fixes for Windows, which was required for Ruby to work properly (see
>> the ChangeLog file for differences between p398 and p369)
>
> Can you paste me the link to the changelog please? I may be able to
> apply the patch to a later version of Ruby as well.
>
Inside each ruby source package is the ChangeLog file.
>
> PS: http://just.do/2011/01/10/a-vote-for-ruby-1-8-8/
>
1.8.x is a burden to maintain. New features added to 1.8.x beyond
expectations of 1.8.6 just break things. I'm not a Rails user either,
and 1.8.7 initially broke lot of stuff for us (RubyInstaller). Look at
my blog from my thoughts about 1.8.7
Continue bring features from 1.9.x branch into 1.8.x seems wrong.
One big example is the inability of 1.8.x to support filenames and
directories with unicode characters... that is not going to happen and
that is an excellent reason not to support 1.8.x anymore.
Latin and non-roman characters should be supported properly. 1.8.x can
only handle english at the filesystem.
It also split our focus on improving Ruby.
For example, the method of fixing bugs is first on trunk and then
those changes are backported to the specific branches.
Sometimes my patches to improve Ruby on windows never reach Ruby 1.8.x
branch... not because of my, but the structure of Ruby development.
So, that is a burden of development and I'll need to continuously poke
branch maintainers to backport my changes.
I honestly prefer do something else.
It not about adventure, I'm talking about improve Ruby on Windows and
splitting efforts to support so many 1.8.x with new features or
performance improvements with Ruby trunk split our time and effort.
>> For example, the method of fixing bugs is first on trunk and then
>> those changes are backported to the specific branches.
>>
>> Sometimes my patches to improve Ruby on windows never reach Ruby 1.8.x
>> branch... not because of my, but the structure of Ruby development.
>
> Can you make a specific example?
>
>> So, that is a burden of development and I'll need to continuously poke
>> branch maintainers to backport my changes.
>
> Can you make a specific example?
>
For both, see all my discussions on Ruby core, see all the tickets
open from me on Redmine. See my blog for comments on the issues of
Ruby 1.8.7 not been able to cross-compile itself.
It will take me time to summarize all that, which I don't have right
now, but if you search the group, ruby-core and redmine will find
them.
As for the installer and the onigumura dependency, my position
remains, either these changes need to be part of Ruby or you depend on
a gem/extension to do the job.
And that is again what 1.8.7 broke from 1.8.6, and you want 1.8.8 make
that even more broken.
You're changing expectations from 1.8.x features with these changes,
same as 1.8.7.
I realize I'm late here, but I wanted to step back for a second. I
don't think we've ever gotten to the bottom of why the Oniguruma gem
won't work for you. If the gem is definitely not an option for you,
I'm sorry for pressing again.
I've had good success with the gem, although my needs may be much
simpler than yours. If we can determine whether it is workable for
you, I think it would be much easier for you to build and distribute a
binary gem to your users than a modified installer. It's just a
suggestion, but I hope you'll give it consideration.
Here are the steps for building the gem on Windows, if you're insterested.
https://gist.github.com/772895
>
>> Please note that that specific patchlevel might not contain needed
>> fixes for Windows, which was required for Ruby to work properly (see
>> the ChangeLog file for differences between p398 and p369)
>
> Can you paste me the link to the changelog please? I may be able to
> apply the patch to a later version of Ruby as well.
>
> On Linux I patched Ruby-1.8.6-p388 with the same patch. So that should
> basically work on Windows as well.
>
> Best
> Zeno
>
> PS: http://just.do/2011/01/10/a-vote-for-ruby-1-8-8/
>
> --
> 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.
>
>
--
Gordon Thiesfeld
http://vert.igino.us
However, this post http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/34286 is too enticing not to pass along. It captures my current views on 1.8.x and is relevant as I question whether your efforts on 1.8.6 are maintainable.
Specifically, as your "flavor" gets further and further away from the mainstream, I think the cost (money and developer resources) for you to maintain may quickly become too much. You likely believe moving to 1.9.2 isn't feasible, but given how much time you and Luis have spent so far, is transitioning your clients forward in fact the less costly and more sustainable option?
A rhetorical question (no need for a reply) as it appears you're already well aware of the issue.
> > As for the installer and the onigumura dependency, my position
> > remains, either these changes need to be part of Ruby or you depend on
> > a gem/extension to do the job.
I think this is really wise feedback. For you to maintain a patch queue (and the expertise needed to keep it working) for Ruby (and other gems?) may defocus your resources. Focus on where you add value and leverage as much as you can :)
> That is exactly why I want them in 1.8.8. The goal of 1.8.8 should be
> to make the transition to 1.9.2 smoother, for any application for any
> developer using Ruby 1.8.6.
I believe that day (1.8.x smoothing the transition to 1.9.x) has long since passed and the goal is no longer relevant. FWIW, this is one of the reasons I've focused my team exclusively on 1.9.x.
Jon
I can also build this alternative Oniguruma gem[1], with similar
steps. It supports the 2.x version of Oniguruma as well. That might
be an option.
[1] https://github.com/geoffgarside/oniguruma
The funny thing is, that usually the more you wait, the more you are
afraid and the bigger the gap is. Working with legacy code it is usually
hard to even adopt and enforce constructs which would eventually shrink
the gap.
Also, there is this strange myth of R1.9 not supporting some gems. But
if you would spent the amount of time you spent with the backporting on
conversion to R1.9, you could be already done. In my previous company,
we switched from R1.8 to R1.9 one and half year ago and it never made
any problems worth of mentioning. Of course that was success story
because of wonderful RubyInstaller :)
Vit
Actually, you're forking Ruby and adding a patch and aiming to
distribute that version without "proof" that there is a real need for
it. So far, you've been the first and only requesting this.
You haven't look at the alternatives that we mention and the
requirements of those. AFAIK these were more simpler to implement and
follow than what you have done.
Yet still, you mention "enhancing our gems", which is not what you
have accomplish here.
> Think consistency for Entreprise(TM). Think about the environment.
>
I know this line is not targeted at me. When I think about
consistency, I think on what you're doing with the fork and you're
going the opposite direction.
You mention your application is used in dunno how many places. So if
the IT department of that place wanted to check what you have done, or
a possible problem they could solve, the will find references to Ruby
for Windows and RubyInstaller in your fork, and direct all the issue,
grief or whatever to us (first google result).
Then we will need to deal with the burden of a fork that might differ
in dunno how many ways (because is not packaged by us or signed by us)
You talk about enterprise and consistency, yet still this single point
defeat your statement.
I'll sound like a broken record, but over the past 15 years I worked
in the video broadcast industry and let me tell you, every second you
loose there, thousands of dollars are lost.
I learnt there think of all the possible scenarios things will fail.
And most of the time, when I look to an OSS library, apply one single
scenario, it breaks.
Some people consider me a magnet to bugs.
I try to apply the same principles I learnt doing that to my OSS
development, and so far they worked up to my expectations.
Some people will disagree with my point of view in relation to
RubyInstaller, but I believe, while slow and steady, we accomplish a
lot.
Now, I might not have specific experience in dotNET or Java corporate
environments, but what I do know, still applies to all of them.
This is not a mine is bigger than yours response, but I want to put a
end to this thread as is not been productive at all for any of us. No
point that you can possible reiterate that wasn't discussed before
needs to be presented or discussed further.
Cheers,
Sorry, it was irony ... It was not about throwing out the code but about
keeping with upstream. Two completely different cases. I could
demonstrate on more examples and wrong decision which were unfortunately
taken during the years I spent in previous company. But that is long
story and off-topic.
>> Also, there is this strange myth of R1.9 not supporting some gems. But
>> if you would spent the amount of time you spent with the backporting on
>> conversion to R1.9, you could be already done. In my previous company,
>> we switched from R1.8 to R1.9 one and half year ago and it never made
>> any problems worth of mentioning. Of course that was success story
>> because of wonderful RubyInstaller :)
> Well so you already switched your job twice! That I do not call
> consistent. That is a lot of noise, if you ask me. We are working on
> the same code since 10 years and the code base has just grown. Very
> simple. I think you do not understand my problem.
>
> Yes, RubyInstaller is wonderful for Windows. I agree. But we are just
> enhancing our gems to windows. An easy task. But other gems like gd2
> are not yet working on Windows. They work perfectly well on Linux. So
> that is where I want to help, in the Windows environment.
That is wonderful, but are you going to make gd2 functioning for 1.8.6,
1.8.7 or for 1.9.2.
> Do your apps run on Linux? I mean are they live an Linux?
This is the same example as keeping you code with upstream. We used QT
for our UI and there were some people who thought that we use QT, we are
on the safe side. But the longer we had worked with QT, the more we have
to workaround QT inabilities. We never contributed anything upstream and
it led just to diversion from compatibility with upstream. At the end,
although the application was QT based, I would never tried it to compile
it on Linux nor run it.
Seems that my attempt to put an end to this thread didn't succeed, but.
There is a fallacy on consider that Linux == Windows and things that
works on Linux should work on Windows, or vice-versa
Most the gems, considering what they do *should* work on Windows, but
gem and library authors didn't pay attention to the cross-platform
nature of the language they are using, turning their library into the
common "works on my machine" kind of thing.
Neither authors mention what dependencies their libraries require and
so many other conditions not been considered when releasing code in
the wild.
And other authors simple don't care.
So, if you aim your application works on all the platforms, learn the
platforms. Learn the Windows API if is required (which is for your GD2
issue) and fix it, or create a new library that correct the GD2 issue
and release it as replacement, so your Linux and Windows version both
use the same codebase.
If you want to accomplish that for your application, it is time you
and your team get your hands dirty.