On the topic of F4, I bring good news! I've spent the past week working through various build issues, and can now present some download links for a release candidate of F4 1.1.4:
f4-1.1.4-linux-gtk-x86.zip
f4-1.1.4-linux-gtk-x86_64.zip
f4-1.1.4-macosx-cocoa-x86_64.zip
f4-1.1.4-win32-win32-x86.zip
f4-1.1.4-win32-win32-x86_64.zip
F4 1.1.4 is now released - see GitHub releases for download links
I'll be testing it out myself over the next few days and, if all seems good, I'll make the release official on GitHub.
Main F4 1.1.4 Features:
Eclipse platform updated to Eclipse 4.9 2018-09 (from 4.6)
DLTK updated to 5.10 (from 5.6)
Fantom compiler updated to Fantom 1.0.74 (from 1.0.71)
Embedded Fantom runtime updated to Fantom 1.0.74 (from 1.0.71)
This means F4 now runs on any current version of Java!
And for those (unfortunate!) Macintosh users, I found an old, clean and unused, Apple Macintosh running OS X 10.11.6 / Darwin 15.6.0. With it I installed Oracle JDK 14, F4 1.1.4, successfully started F4, created a new project, and ran and debugged a simple "Hello World!" application. So I'm hoping F4 is now good for Macintosh users also.
Simply put, I've been unable to compile or assemble F4 with anything later. Here's a summary of incompatibilities:
Eclipse 4.10 (2018-12) and DLTK 5.11
Eclipse 4.11 (2019-03) and DLTK 5.11
Eclipse 4.12 (2019-06) and DLTK 5.11
Eclipse 4.13 (2019-09) and DLTK 5.11
Eclipse 4.14 (2019-12) and DLTK 5.11
There were no compilation issues with these later eclipse platforms, but the maven build to assemble the binaries would FAIL after a warning about a missing tool in the build chain.
Eclipse 4.15 (2020-03) and DLTK 6.1
As you may imagine, the majour update in the DLTK version brings about many compilation issues.
Therefore F4 will have to stay at Eclipse 4.9 until further investigation can be performed. But with 4.9 working with at least JDK 14, I hope this won't be an issue for most people.
Have fun,
Steve.
brianTue 21 Apr 2020
Thank you very much for all your hard work for the community Steve!
andyTue 21 Apr 2020
Sweet!
Jay HerronWed 22 Apr 2020
Thanks Steve!
SlimerDudeWed 29 Apr 2020
Hi,
While the last release candidate worked, I noticed it was slow sometimes. Also attempting to build F4 itself with it was excruciatingly slow (verging on impossible) with heavy amounts of build churn.
As this issue has been going on since before I took over, I decided enough is enough, put some big re-factoring boots on, and stomped all over the core code...
The result is a 2nd Release Candidate which, as far as having multiple projects is concerned, should be huge improvement on build speed.
RC2 download links:
f4-1.1.4-linux-gtk-x86.zip
f4-1.1.4-linux-gtk-x86_64.zip
f4-1.1.4-macosx-cocoa-x86_64.zip
f4-1.1.4-win32-win32-x86.zip
f4-1.1.4-win32-win32-x86_64.zip
f4-1.1.4-repository.zip
F4 1.1.4 is now released - see GitHub releases for download links
If, when opening and closing dependent projects, you get dependency errors - just touch the build.fan of the project in question (add a space, click save) to force a re-resolve of dependent pods / projects.
I'll be testing it out myself over the coming week and, if all seems good, I'll make the release official on GitHub.
While F4 still works on Apple Macintosh OS X 10.11 / Darwin 15.6, Andy says later Macintosh's still have issues - shrug :(
Anyway, Window users, have fun!
Steve.
Jay HerronThu 30 Apr 2020
I noticed the same thing Steve, but some of the slowness went away when I increased the F4 max heap allocation (how to here for eclipse). That might just be related to the size of the pods I'm building, though.
I'll give this new one a whirl and let you know how it goes! Thanks again Steve!
SlimerDudeThu 30 Apr 2020
Cheers Jay,
I did update the latest readme on GitHub to mention it's wise to do this when developing F4 itself; I didn't think about normal users though. I should have, because I always update mine! Here's what I use:
-vmargs
-Xms512m
-Xmx16384m
-XX:MaxPermSize=4096m
Although it never seems to consume much over 2 GB.
I'm sure I can change the default f4.ini for the next release - if anyone has any suggestions for some sensible defaults?
Or I can follow Ross's suggestion for Fantom, delete all the vmargs, and leave Java to set the defaults?
SlimerDude Tue 21 Apr 2020
Hi,
On the topic of F4, I bring good news! I've spent the past week working through various build issues, and can now present some download links for a release candidate of F4 1.1.4:
f4-1.1.4-linux-gtk-x86.zipf4-1.1.4-linux-gtk-x86_64.zipf4-1.1.4-macosx-cocoa-x86_64.zipf4-1.1.4-win32-win32-x86.zipf4-1.1.4-win32-win32-x86_64.zipI'll be testing it out myself over the next few days and, if all seems good, I'll make the release official on GitHub.
Main F4 1.1.4 Features:
This means F4 now runs on any current version of Java!
And for those (unfortunate!) Macintosh users, I found an old, clean and unused, Apple Macintosh running OS X 10.11.6 / Darwin 15.6.0. With it I installed Oracle JDK 14, F4 1.1.4, successfully started F4, created a new project, and ran and debugged a simple "Hello World!" application. So I'm hoping F4 is now good for Macintosh users also.
Some Essential Plugins
Well, they're essential to me at least!
Why Eclipse 4.9 (2018-09) ??
Simply put, I've been unable to compile or assemble F4 with anything later. Here's a summary of incompatibilities:
There were no compilation issues with these later eclipse platforms, but the maven build to assemble the binaries would FAIL after a warning about a missing tool in the build chain.
As you may imagine, the majour update in the DLTK version brings about many compilation issues.
Therefore F4 will have to stay at Eclipse 4.9 until further investigation can be performed. But with 4.9 working with at least JDK 14, I hope this won't be an issue for most people.
Have fun,
Steve.
brian Tue 21 Apr 2020
Thank you very much for all your hard work for the community Steve!
andy Tue 21 Apr 2020
Sweet!
Jay Herron Wed 22 Apr 2020
Thanks Steve!
SlimerDude Wed 29 Apr 2020
Hi,
While the last release candidate worked, I noticed it was slow sometimes. Also attempting to build F4 itself with it was excruciatingly slow (verging on impossible) with heavy amounts of build churn.
As this issue has been going on since before I took over, I decided enough is enough, put some big re-factoring boots on, and stomped all over the core code...
The result is a 2nd Release Candidate which, as far as having multiple projects is concerned, should be huge improvement on build speed.
RC2 download links:
f4-1.1.4-linux-gtk-x86.zipf4-1.1.4-linux-gtk-x86_64.zipf4-1.1.4-macosx-cocoa-x86_64.zipf4-1.1.4-win32-win32-x86.zipf4-1.1.4-win32-win32-x86_64.zipf4-1.1.4-repository.zipIf, when opening and closing dependent projects, you get dependency errors - just touch the
build.fanof the project in question (add a space, click save) to force a re-resolve of dependent pods / projects.I'll be testing it out myself over the coming week and, if all seems good, I'll make the release official on GitHub.
While F4 still works on Apple Macintosh OS X 10.11 / Darwin 15.6, Andy says later Macintosh's still have issues - shrug :(
Anyway, Window users, have fun!
Steve.
Jay Herron Thu 30 Apr 2020
I noticed the same thing Steve, but some of the slowness went away when I increased the F4 max heap allocation (how to here for eclipse). That might just be related to the size of the pods I'm building, though.
I'll give this new one a whirl and let you know how it goes! Thanks again Steve!
SlimerDude Thu 30 Apr 2020
Cheers Jay,
I did update the latest readme on GitHub to mention it's wise to do this when developing F4 itself; I didn't think about normal users though. I should have, because I always update mine! Here's what I use:
Although it never seems to consume much over 2 GB.
I'm sure I can change the default
f4.inifor the next release - if anyone has any suggestions for some sensible defaults?Or I can follow Ross's suggestion for Fantom, delete all the
vmargs, and leave Java to set the defaults?