Will you use or update your fork from mongo source like you did for 2.6.7 at https://github.com/meteor/mongo
I ask to prepare the new parts for Meteor universal fork on ARM devices.
This time I had to add ARM support for v8 into that extended fork at https://github.com/4commerce-technologies-AG/mongo
Would be nice to get an info so that we can start the port to mongo 3.2
Thanks
Tom
Today I had a short conversation with Sing-Li from Rocket.Chat about using ARMv8 (64bit) boards. I am curious if we can make it there too with node v4 and mongo 3.2. That would enable those new sets of ARMv8 servers.
Awesome news MDG! Way to go team - super excited for Mongo 3.2.
Hi
I started with porting of the meteor branch release-1.4 to the ARM architecture at https://github.com/4commerce-technologies-AG/meteor/tree/release-1.4-universal-beta
You may follow the track at https://github.com/4commerce-technologies-AG/meteor/issues/42
I also add the new ARM64 (armv8l, aarch64, arm64) support and that is what currently blocks: see my issue at the babel tracker: https://phabricator.babeljs.io/T7457
Maybe someone has an idea on that.
Cheers
Tom
At the end of this weekend, we had success and meteor-1.4-beta is already running on ARM and the brand new ARM64 architecture. Looking forward to this new server hardware …
@benjamn: Please be aware of these two bugfixes for nodejs and node-fibers. It would be great, if meteor-1.4 will beget upgraded to their latest stable releases when our PRs are merged.
Cheers
Tom
Meteor-1.4 beta is now ready for running on ARM v7 and v8 (aarch64) architectures.
I finally have also built and included in the dev_bundle.tgz the node v.4.4.6-patched (will be replaced with next node v4 stable), the node-fibers v1.0.13-patched (will be replaced when patch comes to stable) and finally also a mongo r3.2.6 from their github.
As a test I run the simple-meteor-react example, with no issues
Question might be if we should invest additional effort into ARMv6 architecture (Raspi 1/A) - I will check via vote on Twitter.
Latest Meteor 1.4 (beta.6 tag) is ready to run on ARMv7 and ARMv8. Performance on linaro ARM cluster is very well. Looking forward to some hosters like skaleway but with ARMv8 boards.
For someone interested on tests, I will leave a dev_bundle for aarch64 (ARMv8) on bintray. The build scripts are currently not 100% finished. Testing for the right compiler directives.
Cheers
Tom
UPDATE: If you like to try that version please use
git clone --depth 1 --branch release-1.4-universal-beta https://github.com/4commerce-technologies-AG/meteor.git
for checkout
See GitHub - bevry-archive/esnextguardian: Superseded by the editions package: https://editions.bevry.me and its successor GitHub - bevry/editions: 📦 The best way to produce and consume the JavaScript packages you care about.
Any idea when 1.4 will be officially released?
Also, will 1.4 solve the issue with super-long build times? This is the one thing that absolutely drives me up the wall the most and just kills my productivity.
No official release date has been mentioned by MDG, but since the beta is now at 1.4-beta.14, I’m guessing we’ll see a release candidate very soon.
The main focus of 1.4 is:
Tackling rebuild times hasn’t been discussed by MDG yet, but the issue is being tracked here (add your +1’s accordingly):
I think this is an actual BUG and not an issue of 1.3, let me explain…
Upon the first time I upgraded to 1.3, after upgrade I had ridiculously long build times. I found this weird as build times were supposed to have DROPPED. But mine were higher than ever before…
I had to revert. Upon reverting everything was back to normal.
Then I decided to give the upgrade a try again - on my second attempt, everything ran GREAT. Reload time was no longer an issue.
Then one of the incremental patches came out, 1.3.2 i think? Upon doing that upgrade, the SAME ISSUE happened. I reverted again, did the upgrade again, problem fixed.
I gave somoene else this advice once before and it worked for them as well.
It seems the updater (at least the windows one) has some errors that are completely screwing the build time.
Hi, have you ever tried to check what happens if doing a complete fresh meteor 1.3.x installation? Would be interesting if this run as quick or if the magic is in the “update - revert - update” process
huh? as far as I could tell by earlier threads, I thought people were working hard on this. Well guess not 
Just adding my 0,02, having 30s rebuilds in event the smallest possible app (ssd even) is kind of unworkable. Especially since it’s on every single small html tweak you do.
Well, there has been a lot of discussion about it, but I just meant there hasn’t been any official statements (or schedule) from MDG about how they’re planning on addressing this issue. Each new release adds incremental performance improvements, but the larger issue definitely still needs to be addressed.
Given that issue 4284 has 155 comments and growing, you’re not alone!
That should not be the case unless you have the bug I mentioned above. if 1.3 is working as intended it should be pretty fast (mine is a very large project and takes only a couple seconds)
What page number? I’ll go look when back at the office.
Got it… pg 164.
sorry in advance for the snide remark: as an ex-windows user, I can attest that windows is what hurts windows developers’ productivity the most. =P
(I did love C# though…)
Hello ,
I am currently using Meteor 1.3 with Blaze Engine
First of all , Why in the official page no more tutorial For Blaze ?
I wanna know if Blaze is gonna vanish one day or not ?
Am I safe with Blaze ? Does MDG planning to take out one day ?
I am worried a little bit about this issues because I have a huge app based on Blaze
and migration or change in code will be disaster
I hope one of the expert guys here could answer me clearly
Thanks