MagLev tries to be compatible with ruby 1.8.7
So it seems to me that Jekyll should be able to run on it...
And based on this previous question, seems that even some rails applications can run on it...
But has anyone actually tried it?
What were the problems you had?
If you haven't tried it, do you anticipate any major problems?
TIA
I just tried Jekyll on Maglev's 1.9 branch, and it doesn't work. Maglev falls down when using anything with C extensions; in this case, it's Jekyll's dependency on posix-spawn.
You might wanna check out the docs regarding the state of C extensions on Maglev.
AFAIK, Jekyll doesn't really have persistence (besides static files), so I'm not sure what you'd gain from using Maglev. You can definitely have a lot of fun with Maglev and Sinatra, give them a shot.
Related
I am using a quite recent version of ruby (2.5.1) but some old gems. I am having some issues. I was wondering, is it correct that some gems work only with certain versions of ruby?
If a gem worked with ruby 2.3.0, is it true that it will definitely work with 2.5.1 (i.e. because 2.5.1 > 2.3.0)? Or is that not always the case?
I guess what I'm asking is are newer ruby versions always backwards compatible with older gems?
If a gem worked with ruby 2.3.0, is it true that it will definitely
work with 2.5.1
This is not correct. Programming languages are evolving while growing. This means language maintainers are doing lots of improvements or refactorings that they are new features or removing old components from the language. When the language community announces for new features or removing old feature such as Fixnum in ruby, the developers should follow the instructions and refactor their codebase accordingly. In other words, developers should have a good test coverage to detect any fail and fix it instantly.
In your scenario, as well as I understand you do not have a test coverage. The only but the simple thing should do is just upgrade your gems' versions to latest.
Gem is simply a plug-in library written in Ruby.
Of course, Ruby is developing, new features are appearing, old ones are disappearing.
It's best practice to specify Ruby version in .gemspec file. For example, like this one.
But if not, then you have to manually check the performance. So you can read gem source code or try to use your gem and check it.
For automation, of course, it is best to use tests.
Starting at Ruby 2.1.0 the version policy has been that a change in the MINOR version may introduce API breaking changes.
Should any gem happen to use an API that changes, an incompatibility will arise.
The MINOR version number has changed twice between 2.3.* and 2.5.* so even if a gem happens to have been written in accordance with the documented API, there's no guarantee that it will continue to work unless the gem's maintainer takes the effort to test the gem (and upgrade it if necessary). Automated test suites help a lot.
A standard way to document version compatiblity that is actually tested against is by providing required_ruby_version in .gemspec files.
Interestingly, if a particular gem is really badly written, I imagine it might break even between compatible versions of Ruby. That's not something I've encountered in the Ruby ecosystem but I've made a similar mistake writing Java code (and Java is famous for its backward compatibility) where my own code accidentally used a class that wasn't part of the API. There are many gems. Who knows what's out there? :)
I have a project with many Ruby files, loaded by external program with embedded Ruby interpreter (and some other libraries). I'm trying to use RubyMine and Rubocop to help with development, but the problem is that the said embedded interpreter is of version 1.9.2 and can't be upgraded in any way. Is it possible to still use the Rubocop or other linter inside RubyMine and at the same time to make sure the code is compatible with old interpreter?
Yes you can, Check this out and then let RuboCop know the oldest version of Ruby which your project supports with updating .rubocop.yml file:
AllCops:
TargetRubyVersion: 1.9
The short answer is that yes, it is possible to change the linter used in RubyMine, there are complete walk-throughs on JetBrains site explaining how. I don't know off the top of my head any linters that specifically work for pre-2.0 versions of Ruby, not to say they don't exist.
The longer answer is that it really won't make much difference if the interpreter is running through another program, and not using a real Ruby installation, and any linter is not going to reliably work for you. There will be plenty of code that a linter will still think is perfectly acceptable, but fail when running in an embedded VM.
# Linter thinks this perfectly fine, part of 1.9.2 standard library
require 'base64'
# Still thinks this perfectly fine. This all fails miserably though
Base64.encode64('My string')
The most obvious examples would be the entire standard library, gems, rake, and anything that is not part of the "core" library. Basic rule of thumb, if you have to require a script (excluding your project's local scripts), it is not going to work.
Another reason it could never be reliable is that you do not know if the embedded Ruby interpreter has been altered, or removed features from Ruby for their purposes, and a linter would have even less way of knowing that. Years ago I dabbled with the RPG Maker series, and discovered the hard way that their were certain built in features of Ruby that were removed (or at least hidden) from their custom build.
If you are familiar with Ruby, then you can obviously steer clear of the major and most common 2.0+ changes that Ruby implemented to the core library, but the only reliable way to know (even with a linter), is testing, which you will need to do anyway ( or at least you should). RubyMine has good support for automating this with Minitest and RSpec.
My question is about the ruby-doc.org documentation, but also relates to the ri documentation lookup inside ruby.
I've already read dozens of similar questions/answers about the ri not working and giving "nothing known" messages and I've tried to follow some of that old advice. It just seems that those old answers aren't applicable to me.
One was to install the rdoc --all --ri from the ruby root directory. I tried that and it failed (unable to convert to UTF8 or something like that).
Another suggested that the rubyinstaller for windows installer just doesn't contain that info anymore and I should use the online documentation, which, when I goto http://ruby-doc.org/downloads/ I discover that the version I am using (2.4.4) does not exist.
This is odd, because the rubyinstaller site specifically says that if I'm new to Ruby(which I am), I should install 2.4.4. You'd think that if any version had good documentation, it would be that one. Instead, it seems to be missing entirely.
This all started because I am trying to learn Ruby and am watching the Lynda.com course on Ruby by Kevin Skoglund, which was recorded many versions ago and in that course he refers to the ri command from the shell, which in my version doesn't work. see below:
ruby --version
ruby 2.4.4p296 (2018-03-28 revision 63013) [x64-mingw32]
ri --version
ri.cmd 5.0.0
ri String
Nothing known about String
Now, if it's not available within ruby using ri, and I have to use online documentation, AND it's missing for my version, which happens to be the version recommended for new users, … you see my frustration.
Here's what I really want...
1. I want to use ri and have it work.
2. If that's just not possible, I'd like to know where the documentation for my version is online, because it's not where it's supposed to be.
Any help is appreciated. If it involves installing anything, letting me know HOW to do that is also appreciated. As I mentioned, I'm new.
Since you are using the RubyInstaller, I will assume that you are on Windows.
I will open this by saying that I am not 100% on this, but I am pretty condfident in this answer.
The "Use 2.4, not 2.5" was due to errors with Ruby Gem when Ruby 2.5
was first released, as I happen to be on a Windows machine installing
Ruby at that exact time, and that was the reasoning at that point not
to use the newest 2.5 version.
The above mentioned reason has since been corrected.
Realistically, if you are beginner, as long as you using documentation that is close to your version (2.0+ - 2.4-ish), it will be fine. Now obviously, and I shouldn't have to provide this disclaimer, though I will so to avoid the inevitable down-votes if I don't, this is not 100% perfect solution and there will be very small differences. As a beginner, the likelihood of you encountering any of these differences are extremely low, low enough not to even worry about. There are missing and poorly documented sections of every language, and Ruby is no exception. Typically these are less used classes (though Ruby Fiddle is an exception that I hate how poorly documented it is), and will have no effect on your learning process as you learn the fundamentals and core of the language.
To my recollection, the "core" is rather well documented, and so long as you use documentation from 2.0+ (the closer to 2.4 the better), you should be completely fine, and it is exactly the same. The "standard library" may be slightly more hit or miss, and your mileage may vary a little more, yet still nothing too extreme.
So, to address the second part of your question, do not worry too hard about finding the EXACT version of documentation you are using. It may not even exist online, though the installer should have provided a CHM help file (there will be shortcut for it with the shortcuts for Ruby, IRB, etc.
As for "why" ri is not working, I am not 100% sure yet again. I am on ArchLinux, and RDoc doesn't even built. Honestly, RDoc is being left by the wayside for newer (and IMO better) document engine, namely YARD. A possible solution that I do, and prefer, is to install the YARD gem right after I install Ruby:
gem install yard
And then set YARD to generate my documentation with this in CMD:
yard config --gem-install-yri
If you decide to take this route, much more can be learned about it here.
The benefit with it is that it also supports RDoc and is backwards compatible.
I have done a bit of digging through the rubygems code and it doesn't look like there is a built-in way to get it to not throw a Gem::ConflictError even if there is one. During development I might be wanting to test something that I know is not going to touch the code from which the conflict is coming or I know that the whatever version of the erstwhile conflicting gem isn't going to cause a problem. I just want to get on with testing what I want to test and I'll worry about version conflicts later.
I know I can hack rubygems to do this. I can think or multiple ways to get it done. I'm just kind of curious if anyone has already done this, how they did it, and maybe if that code has been shared somewhere. I'm also a bit curious as to why this isn't built in to rubygems as a development tool.
You need to worry about version conflicts now before you can get anything done. As Ruby has a singular root namespace and every dependency gets loaded there it's generally not possible to load multiple versions of the same gem. Other systems like NPM for Node.js are significantly more flexible, it's possible to load any number of versions at the same time, so if you're used to that you'll need to adjust your expectations.
If you're trying to do testing and you want to avoid resolving a conflict, just remove that gem requirement from the Gemfile temporarily.
Ultimately you'll have to fix things, there's no way around it, but you can always be selective about what you require.
If you really know what you are doing, try this:
export NOEXEC_DISABLE=1
ruby you-program.rb
This environment variable will disable search and check for Gemfiles and gem versions.
i'm interested in updating code which is written in ruby v1.8.6 to 1.9.2. Are there any useful links to read about (probably with some warnings and recommendations)?
Just to be clear, so, i'm not expecting any problems right now, but i would like to avoid them.
P.S.
Links like this one are mostly not helpful.
A slideshow showing the differences: http://slideshow.rubyforge.org/ruby19.html#11
I migrated an app from ruby 1.8.7 to 1.9.3 a few days ago, and no problems happened.
Bu i advise you to test all of your code for little bugs.
Verify that all the gems you depend on are 1.9.2 compatible. isitruby19.com is a good resource to check this.
Other than that, the best strategy is to try migrating and do some testing. If your application has comprehensive unit test coverage, this shouldn't be too painful.