Phase 1 rubyinstaller.org final review
Jon
I just pushed a few changes out to http://rubyinstaller.org/proto/ this morning that need your review.
Specifically, I've condensed things to just 2 real pages, have updated the links appropriately, and have included Charles Roper's cleanup to the logo (thanks!).
In addition to some last minute polish, a few open issues remain:
* Update link to the real DevKit download from Add-on page
* Fix pixel shift issue when switching between homepage and Add-on pages
* Double-check the greens used on Add-on page; it's burns eyes on one of my monitors :(
* Finish the new http://wiki.github.com/oneclick/rubyinstaller/development-kit/ wiki page. I've started a rough outline but it needs someone to pick it up and finish it.
While Roger Pack has a great writeup that he linked in to the Tutorials wiki page, I want to make the DevKit info more visable as a top-level wiki page as well as add a bit more context for first-time users.
* Review with Pavel to see if any look-n-feel changes need to be made.
I'm offline this weekend and plan to make any final tweaks to content, colors, typography, functionality on Monday. If all goes well, the plan is to go live with Phase 1 on Tuesday morning.
Take a look at things see what needs a bit more work.
Jon
Bosko Ivanisevic
* Double-check the greens used on Add-on page; it's burns eyes on one of my monitors :(
Regards,
Bosko Ivanisevic
Luis Lavena
>
> Phase 1 of rubyinstaller.org is coming together nicely and I think we're about ready to go live.
>
Thank you Jon, snips to one point
> [...]
>
> * Double-check the greens used on Add-on page; it's burns eyes on one of my monitors :(
Mine too, definitely green is not a nice color :-P
Perhaps is due the white color of the font, but could work for now.
> * Finish the new http://wiki.github.com/oneclick/rubyinstaller/development-kit/ wiki page. I've started a rough outline but it needs someone to pick it up and finish it.
>
I was thinking on write a blog post explaining how to get MySQL 5.1
and the DevKit to work on this. Perhaps that can be used as
foundation?
> I'm offline this weekend and plan to make any final tweaks to content, colors, typography, functionality on Monday. If all goes well, the plan is to go live with Phase 1 on Tuesday morning.
>
Awesome man, thank you.
Cheers and have a nice weekend!
--
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
Jon
> >
>
> I was thinking on write a blog post explaining how to get MySQL 5.1
> and the DevKit to work on this. Perhaps that can be used as
> foundation?
Good idea, and please link it in on our Tutorials wiki page.
That said, I feel strongly that the DevKit should have a top-level wiki page as it is such a key enabler to a good MRI Ruby experience on Windows.
While one could claim it's "just a build environment" it really does enable one to easily use native gems that don't have a correct binary distribution. While it's great there are more binary gems that work well with the mingw builds (e.g. - sqlite3-rugy, amalgalite, nokogiri, etc) there are still some incredible gems such as ffi that need the DevKit...and build and install nicely once you've installed the DevKit.
Enough of this mini-rant.....if no one has the time to pick this one up, I'll do it after I push the placeholder site out tomorrow.
Gordon Thiesfeld
I had started on this before I saw you had created the wiki page. I
found my notes and dusted them off and took a stab at it. It probably
needs work/corrections, but it's a beginning.
Jon
> found my notes and dusted them off and took a stab at it. It probably
> needs work/corrections, but it's a beginning.
Thanks Gordon...looks like a great start!
...and I just got tired of futzing with things...
the placeholder site is now live at http://rubyinstaller.org/ so clear your caches, double check the links, and see if you've recovered from the green blindess caused by the add-ons page. i'll roll in updates as needed.
Gordon...does it make sense to change the link on http://www.ruby-lang.org/en/downloads/ for the "one-click installer" text in the first paragraph of "Ruby on Windows" to point to rubyinstaller.org rather than redirect to the old RubyForge wiki page?
Jon
Gordon Thiesfeld
Yes it does :-) And I just did.
>
> Jon
>
Bosko Ivanisevic
Thanks Gordon...looks like a great start!
> I had started on this before I saw you had created the wiki page. I
> found my notes and dusted them off and took a stab at it. It probably
> needs work/corrections, but it's a beginning.
...and I just got tired of futzing with things...
the placeholder site is now live at http://rubyinstaller.org/ so clear your caches, double check the links, and see if you've recovered from the green blindess caused by the add-ons page. i'll roll in updates as needed.
Matt Hulse
Yes it does :-) And I just did.> Gordon...does it make sense to change the link on http://www.ruby-lang.org/en/downloads/ for the "one-click installer" text in the first paragraph of "Ruby on Windows" to point to rubyinstaller.org rather than redirect to the old RubyForge wiki page?
Gordon Thiesfeld
Did you try it? The rubyforge page redirects to rubyinstaller.org now.
Let me know if there's a problem.
Matt Hulse
Did you try it? The rubyforge page redirects to rubyinstaller.org now.
Let me know if there's a problem.
Luis Lavena
>
> [...]
>
> While one could claim it's "just a build environment" it really does enable one to easily use native gems that don't have a correct binary distribution. While it's great there are more binary gems that work well with the mingw builds (e.g. - sqlite3-rugy, amalgalite, nokogiri, etc) there are still some incredible gems such as ffi that need the DevKit...and build and install nicely once you've installed the DevKit.
>
But FFI already ships native binaries for 0.4.0, and as more people
start using it, they would be able to contribute back checking out the
source code and running the specs.
> Enough of this mini-rant.....if no one has the time to pick this one up, I'll do it after I push the placeholder site out tomorrow.
Please do, and thank you for the lead on this.
Cheers.
Luis Lavena
>
>> I had started on this before I saw you had created the wiki page. I
>> found my notes and dusted them off and took a stab at it. It probably
>> needs work/corrections, but it's a beginning.
>
> Thanks Gordon...looks like a great start!
>
> ...and I just got tired of futzing with things...
>
> the placeholder site is now live at http://rubyinstaller.org/ so clear your caches, double check the links, and see if you've recovered from the green blindess caused by the add-ons page. i'll roll in updates as needed.
>
The Logo/ISO should link to "/", not index.html. that is going to
generate a duplicated element on search engines.
Jon
But FFI already ships native binaries for 0.4.0, and as more people
start using it, they would be able to contribute back checking out the
source code and running the specs.
At http://rubyforge.org/frs/?group_id=7208 FFI currently has ruby, java, and x86-mswin32 gems so folks still need to use the DevKit for RubyInstaller-based installs until a mingw32 binary gem is made available.
Luis Lavena
Can someone open a "issue" for ffi project and tell them to use this?
ext.cross_platform = ['i386-mingw32', 'i386-mswin32']
Next version (0.5.0?) will remove the need of the compiler.
Alexey Borzenkov
> Can someone open a "issue" for ffi project and tell them to use this?
>
> ext.cross_platform = ['i386-mingw32', 'i386-mswin32']
>
> Next version (0.5.0?) will remove the need of the compiler.
Btw, you can sometimes use --platform mswin32 to install gems that are
difficult to compile or that you don't want to compile. On the other
hand, I myself have --platform source in my .gemrc, simply because I
don't trust binary gems. :-/
Luis Lavena
>
> On Wed, Aug 19, 2009 at 9:44 PM, Luis Lavena<luisl...@gmail.com> wrote:
>> Can someone open a "issue" for ffi project and tell them to use this?
>>
>> ext.cross_platform = ['i386-mingw32', 'i386-mswin32']
>>
>> Next version (0.5.0?) will remove the need of the compiler.
>
> Btw, you can sometimes use --platform mswin32 to install gems that are
> difficult to compile or that you don't want to compile.
http://blog.mmediasys.com/2008/08/10/rubygems-with-power-comes-responsibility/
> On the other
> hand, I myself have --platform source in my .gemrc, simply because I
> don't trust binary gems. :-/
Oh, about to cry... what about my gems? :'(
;-)
Alexey Borzenkov
>> Btw, you can sometimes use --platform mswin32 to install gems that are
>> difficult to compile or that you don't want to compile.
> http://blog.mmediasys.com/2008/08/10/rubygems-with-power-comes-responsibility/
Hmm, I found your letter at
http://rubyforge.org/pipermail/rubyinstaller-devel/2008-August/000378.html
- what sort of alignment are you talking about? The only
incompatibility I currently know about is the size of long double (10
bytes on mingw, 8 bytes on msvc), which was recently mentioned on
python-devel, but ruby doesn't seem to use that. And on mysql, I've
been using mysql installed with --platform mswin32 (btw, didn't know
there's mingw32 variant, so accustomed to adding --platform mswin32)
almost half a year ago, before I knew about rubyinstaller and was
building ruby myself, and didn't have any problems. Very strange. :-/
But anyway, I mostly use mswin32 for win32-service only, because even
though I ported it to g++ (with constructor/destructor paradigm
instead of __try/__finally) it didn't have any meaning, gcc doesn't
support SEH, period. Anything else is pure laziness to tweak
CPATH/LIBRARY_PATH/etc. :)
> Oh, about to cry... what about my gems? :'(
Well, I'm sure you are building good gems, but what about others, do
they? How did they build them? What did they use? What are their
dependencies? It's not such a big problem with mingw32, as I don't
think there are many out there. Oddly, I started to dislike binary
gems back when I was desperately trying to build mswin32 with Visual
C++, although it was 2008 Express, not 6.0 (my worst ruby experience
ever). And rubygems not only has no clue about your ruby version, but
your C runtime as well. :-/ Now that's when I had plenty of "crap,
it's installing binary gems" moments...
Luis Lavena
>
> On Wed, Aug 19, 2009 at 10:10 PM, Luis Lavena<luisl...@gmail.com> wrote:
>>> Btw, you can sometimes use --platform mswin32 to install gems that are
>>> difficult to compile or that you don't want to compile.
>> http://blog.mmediasys.com/2008/08/10/rubygems-with-power-comes-responsibility/
>
> Hmm, I found your letter at
> http://rubyforge.org/pipermail/rubyinstaller-devel/2008-August/000378.html
> - what sort of alignment are you talking about? The only
> incompatibility I currently know about is the size of long double (10
> bytes on mingw, 8 bytes on msvc), which was recently mentioned on
> python-devel, but ruby doesn't seem to use that. And on mysql, I've
> been using mysql installed with --platform mswin32 (btw, didn't know
> there's mingw32 variant, so accustomed to adding --platform mswin32)
> almost half a year ago, before I knew about rubyinstaller and was
> building ruby myself, and didn't have any problems. Very strange. :-/
>
"There are other problems about platforms like RUBY_PLATFORM regexp
that can interfere with the actual code execution.
So sometimes issuing a --platform=mswin32 will not fix the issue, but
generate some random errors (like Mongrel 1.1.5 a few weeks ago, mea
culpa)."
Ruby code more than binary extension one.
MySQL gem will get updated soon, since is not 1.9 compatible, more on
that in my blog soon.
> But anyway, I mostly use mswin32 for win32-service only, because even
> though I ported it to g++ (with constructor/destructor paradigm
> instead of __try/__finally) it didn't have any meaning, gcc doesn't
> support SEH, period. Anything else is pure laziness to tweak
> CPATH/LIBRARY_PATH/etc. :)
>
> Well, I'm sure you are building good gems, but what about others, do
> they?
I believe the ones that are cross compiled using rake-compiler are
going to be good, crash tested the whole stuff a lot before making it
public
> How did they build them? What did they use? What are their
> dependencies? It's not such a big problem with mingw32, as I don't
> think there are many out there. Oddly, I started to dislike binary
> gems back when I was desperately trying to build mswin32 with Visual
> C++, although it was 2008 Express, not 6.0 (my worst ruby experience
> ever). And rubygems not only has no clue about your ruby version, but
> your C runtime as well. :-/ Now that's when I had plenty of "crap,
> it's installing binary gems" moments...
>
Oh la la, I've been there, done that, moved forward.
But you're still depending on mswin32 binaries... so that means you
trust win32utils guys ;-)