Greetings to all,
This is my first post to this forum. I am a Nimrod user since roughly one year, and I am using it for developing a number of tools related to my domain of interest (cosmology).
I wanted to share some feelings I am having at the moment after having read the post "Problems installing 0.9.4 from master branch" (http://forum.nimrod-lang.org/t/541). Please take my comments positively, as my purpose is to be constructive here.
I find that some of the answers given to shiv reveal an approach to Nimrod's hacking that might be hurting the project in the mid- and long-term. First, let me state the opinion that it is not possible to have broken instructions for building Nimrod. Any user attempting to install Nimrod will surely feel upset and will likely turn his back on Nimrod (not before maybe writing rants in a blog post). This is really harmful!
As an example, some time ago I had the chance of showing one of my Nimrod projects to one of my colleagues, but I chose not to do so because a few days before I noticed that Nimrod's master branch did not compile anymore. (I cannot remember if the problem is the same as the one reported by shiv, as this happened at least one month ago: I remember that the problem was already signaled on GitHub, and the answer was to temporarily use the devel branch.)
Araq answer to brianrogoff in the same thread reveals another problem:
Well here in the "nobody pays for this" open source land, most work is done at the weekends and it will be fixed soon (or is already).
I completely understand the fact that Nimrod's mantainers are a few volunteers that steal their hours of hacking from their families and their hobbies. Nevertheless, if you want Nimrod to succeed, problems like these should get the highest priority. (The post dates September 2nd, yet today is 6 Sep and the code in the master branch still does not compile.) Better: you should build a safety net to make sure that problems like these do not happen at all. (E.g. automatically compile and run the full test suite on the master branch after every commit to it, adding a branching model to csources, …)
In the same post I discovered two other facts:
I, like brianrogoff, wasn't aware of these changes, despite checking this forum regularly. Araq explains:
Indeed the name change and changing the default to --cs:partial are big changes not to be found on the roadmap but both have been discussed for months now. Note that most action happens via IRC and not on the forum.
I think that discussions about such big changes should not be confined to IRC alone. The advantage of forums is that you can put a subject to a discussion, and this makes things easy to search. (I've tried to hunt for the discussions mentioned by Araq, but after a digging into a few days of IRC logs got bored and gave up.) In fact, Araq himself has started a few posts regarding the proposal of some not-so-big changes, e.g., http://forum.nimrod-lang.org/t/521 and http://forum.nimrod-lang.org/t/209 . In my opinion, at the very same moment one implements such changes in the master branch, he or somebody else must be ready to update any relevant documentation and advertise them in this forum. If these parallel activities are not possible, such commits should be postponed.
Please do not be upset by this post of mine. I realize that this is the first time I write here, and so far I have only written what I do not like. I am sharing my thoughts because I really want Nimrod to succeed. So far, every time I can avoid using C++ in my projects, I use Free Pascal or GNAT Ada, relegating Nimrod to those tiny scripts I am sure I will never need to share. With some more improvements (e.g., array slices, proper float32 support) and a stable version of the language, Nimrod would be the ideal tool for all my projects. (Although my blog will probably win the contest for "the lowest number of readers", I have written an article describing my experiences with Nimrod, http://ziotom78.blogspot.it/2014/01/experiments-with-nimrod.html , where I praised this project.)
I feel that, in order to attract more potential users and contributors, more effort should be put in the "PR" part. It might be more tiresome, but IMHO it is the price to pay for making Nimrod more popular. (And, please, consider converging to a stable 1.0 release in a reasonable time: the language is already nice enough as it is now, in my opinion.)
Thank you for your feedback. It's always nice to hear that people use and like the language.
That master doesn't build anymore is news to me, but then you don't tell us how you try to build it.
I repeated what shiv did (http://forum.nimrod-lang.org/t/541) and got the same error message ("Error: system module needs 'TNimType'").
IMO the biggest mistake is that we tell people to build from github instead of sticking to the official stable releases! A lot of effort goes into these.
Then it would be good to change ASAP the page http://nimrod-lang.org/download.html, because at the moment it says: "Starting with 0.9.4 we now advise people to build directly from the github master branch."
Release of 1.0 by the end of this year is still realistic.
That's very good to hear!
csources should be fixed by now - I've created/rewound branches in the csources repository to match the major branches in the Nimrod repository . Any branches in the Nimrod repository that don't have a directly corresponding branch in the csources repository should use the branch closest in source/history.
Pull requests to improve the readme in the csources repository are welcome!
Then it would be good to change ASAP the page http://nimrod-lang.org/download.html, because at the moment it says: > "Starting with 0.9.4 we now advise people to build directly from the github master branch."
This all works fine again, tested on Ubuntu 14.04, and I'll test with OS X 10.9.3 later. So, no need to change the page.
It's great that Nimrod compiles itself so fast, it makes checking this out easy.
Release of 1.0 by the end of this year is still realistic.
I hope that vision is realized.
This all works fine again, tested on Ubuntu 14.04, and I'll test with OS X 10.9.3 later. So, no need to change the page.
Are you sure? I suggested to reword the sentence because of Araq's comment:
IMO the biggest mistake is that we tell people to build from github instead of sticking to the official stable releases! A lot of effort goes into these.
As it is now, the page seems to contradict what Araq said, because at the top the page says:
You can download the latest version of the Nimrod compiler here. You can use the binaries provided or build from source.
This seems to imply that choosing the binaries or the sources should be equivalent. This is enforced by what is stated at the bottom:
Starting with 0.9.4 we now advise people to build directly from the github master branch. […] The master branch always contains the latest stable version of the compiler.
I would put a big warning somewhere in the page, saying that the recommended way of obtaining Nim is through the binaries, and that compiling it from source, even the ``master`` branch, might lead to problems. (The fact that today, September 8th 2014, master compiles fine does not contradict the statement.)
As it is now, the page seems to contradict what Araq said...
Yes, you are absolutely right. The question is: Can we ensure that master will never break again leading to frustrated users? I think we have to deny this question and so the website should be updated to reflect reality. master is more stable than the latest official release unless it is broken...
Maybe applying bors (*)or something similar to the workflow should be considered.*
No. This whole "workflow" does not work, even if master is technically guaranteed to never break.
So you install "Nim compiler version 0.9.5, commit 0a0ffee" (note how the version number is essentially meaningless at this point and the commit hash has become the real version number!) and write your module and submit it to Babel. But Babel doesn't work with commit hashes and so the dependency is something like "Nim >= 0.9.5" or perhaps "Nim = 0.9.5". But that is a lie. There is no version 0.9.5. Will it work with 0.9.6? Who knows.
What works is having official releases that people can write their code against. Whether the master branch on github builds or not should be irrelevant for our users.
Rust and Julia manage to keep the master working.
This is rather meaningless. Nobody should write Python/C#/Java/Ruby/C++/Rust/Julia code against "language implementation with commit hash 0a0ffee".
The current mess with building Aporia+Babel+PackageX is a direct result of the fact that we tell people to install everything from git master.
What works is having official releases that people can write their code against.
Yeah, I shot from the hip before. You're right that most people should be encouraged to build from a versioned release. And git hashtags are not versions at all.
Whether the master branch on github builds or not should be irrelevant for our users.
Which users? For a language like Nim (pre 1.0, rapidly changing, new features coming on frequently), some large subset of users will want to build the "latest development version" from source. Some will want to work on a specific branch for a while. I think that latest version should always build from source, at least on various Unixes, including OS X. So the 'build from source' instructions on the page should always work.
The current mess with building Aporia+Babel+PackageX is a direct result of the fact that we tell people to install everything from git master.
How so? From my POV it's a direct result of pushing obviously broken code which wasn't tested.
So the 'build from source' instructions on the page should always work.
Well the stable releases also include source based installations; part of the problem is that build instructions change and there are lots of ways to build Nim.
If you want bleeding edge, build from github, but don't complain when we (very rarely!) break things. Frankly I don't see the point in putting lots of effort into ensuring that master never ever breaks. It's outdated already and many people use devel which means it's tested more. We tried the master vs devel split for exactly the reason to always have a stable version on github but failed.
At some point you have to accept reality and document what works with the resources that we have. Both Rust and Julia have teams of full time paid developers and what works for them doesn't work for us.
How so? From my POV it's a direct result of pushing obviously broken code which wasn't tested.
Babel for instance is developed against devel using cutting edge features and frequently fails to compile with 0.9.4. In fact, Babel and Aporia should probably follow Nim's branching model.