This is the first complete build cycle since moving from BitBucket+Mercurial to GitHub+Git.
Actor Framework
Several improvements have been made to the concurrent APIs.
The Future API is now abstract to allow custom implementations. A static factory named makeCompletable will create a future which you can call complete on yourself. We are using Java's terminology of CompletableFuture but with only one public class. Java's CompletableFuture API roughly corresponds to JavaScript promises. The Java implementation of Future now implements java.util.concurrent.Future so it can be used interchangeably with Java native code. There is now another separate internal subclass of Future used for actor sends.
The cooperative multi-tasking scheduler used by Actors has been redesigned. Previously actors yielded their thread whenever a certain number of messages had been processed. Now actors yield their thread based on processing time and only when other actors are waiting for access to a thread. There is a nodoc option ActorPool.maxTimeBeforeYield which defaults to 5sec. This should provide more equitable and performant throughput for messages when actors are contending for a limited number of threads.
FilePack
We are introducing a new class web::FilePack to make it easier to deploy Fantom JS files to the browser. The heart of this new API is a suite of static utility methods to build up a list of CSS and JS files for deployment. Depending your deployment you can use these files however you want. To make it easy use web::FilePack.makeFiles to serve up one or more files as a single HTTP URI with built-in support for ETag/Last-Modified for 304 optimization.
Change Log
Build 1.0.75 (24 Aug 2020)
Move repo from BitBucket to GitHub
List addNotNull, mapNotNull, findNotNull
Map addNotNull, mapNotNull, findNotNull
Deprecated List.addIfNotNull, Map.addIfNotNull
domkit: Add DropTarget.onLeave callback
Updates to original documentation
Actors now yield based on time instead of msg count
Actor improved diagnostics
ActorPool.balance experimental method
Future is now abstract
Pod flattenDepends, orderByDepends
Remove JS fixed sourceMappingURL in favor of SourceMap header
as the current find() method returns a single item whereas findAll() returns a new list with multiple items.
It would also help those using autocomplete to find the new findAllNotNull() when they've typed findAll.
brianSun 31 Jan 2021
Maybe, although I certainly don't feel strong enough about it personally to deprecate those and rename them all. We've always had findType too - pretty much every findXXX is going to be a list result. But if everyone else thinks its worth trying to make more consistent, I'm open to changing them
andyMon 1 Feb 2021
Seems like they ought to be prefixed. But the naming convention ship might have already sailed for the List class...
SlimerDudeMon 1 Feb 2021
With the magic of @NoDoc, nobody need ever know!
@NoDoc @Deprecated { msg="Use findAllNotNull() instead" }
List findNotNull()
** Return a new list with all null items removed.
List findAllNotNull()
brianFri 7 May 2021
I did some more brainstorming with Matthew on the findNotNull vs findAllNotNull. Some pros and cons:
findAllNotNull: more technically correct
findAllNotNull: could potentially free up findNotNull for finding the first non-null single value (if we wanted both versions)
findNotNull: but is there ever a use case for finding just a first single non-null value?
findNotNull: slightly more terse and easier to read
findNotNull: consistent with findType which has been in the API forever
findNotNull: what is already there and working today
All said, we both lean slightly towards keeping it as findNotNull. More thoughts?
brian Mon 24 Aug 2020
We have posted a new Fantom build.
This is the first complete build cycle since moving from BitBucket+Mercurial to GitHub+Git.
Actor Framework
Several improvements have been made to the concurrent APIs.
The Future API is now abstract to allow custom implementations. A static factory named
makeCompletablewill create a future which you can callcompleteon yourself. We are using Java's terminology of CompletableFuture but with only one public class. Java's CompletableFuture API roughly corresponds to JavaScript promises. The Java implementation of Future now implementsjava.util.concurrent.Futureso it can be used interchangeably with Java native code. There is now another separate internal subclass of Future used for actor sends.The cooperative multi-tasking scheduler used by Actors has been redesigned. Previously actors yielded their thread whenever a certain number of messages had been processed. Now actors yield their thread based on processing time and only when other actors are waiting for access to a thread. There is a nodoc option ActorPool.maxTimeBeforeYield which defaults to 5sec. This should provide more equitable and performant throughput for messages when actors are contending for a limited number of threads.
FilePack
We are introducing a new class
web::FilePackto make it easier to deploy Fantom JS files to the browser. The heart of this new API is a suite of static utility methods to build up a list of CSS and JS files for deployment. Depending your deployment you can use these files however you want. To make it easy useweb::FilePack.makeFilesto serve up one or more files as a single HTTP URI with built-in support for ETag/Last-Modified for 304 optimization.Change Log
Build 1.0.75 (24 Aug 2020)
SlimerDude Sat 30 Jan 2021
Should the new methods:
List.findNotNull()Map.findNotNull()perhaps instead be called:
List.findAllNotNull()Map.findAllNotNull()as the current
find()method returns a single item whereasfindAll()returns a new list with multiple items.It would also help those using autocomplete to find the new
findAllNotNull()when they've typedfindAll.brian Sun 31 Jan 2021
Maybe, although I certainly don't feel strong enough about it personally to deprecate those and rename them all. We've always had findType too - pretty much every findXXX is going to be a list result. But if everyone else thinks its worth trying to make more consistent, I'm open to changing them
andy Mon 1 Feb 2021
Seems like they ought to be prefixed. But the naming convention ship might have already sailed for the
Listclass...SlimerDude Mon 1 Feb 2021
With the magic of
@NoDoc, nobody need ever know!@NoDoc @Deprecated { msg="Use findAllNotNull() instead" } List findNotNull() ** Return a new list with all null items removed. List findAllNotNull()brian Fri 7 May 2021
I did some more brainstorming with Matthew on the findNotNull vs findAllNotNull. Some pros and cons:
All said, we both lean slightly towards keeping it as findNotNull. More thoughts?
go4 Fri 7 May 2021
removeNull, filterOutNull