Hi Tom (and others), From an earlier email, you remarked that you where able to get an example up and running quickly by ignoring Athens (?) and rolling your own. Is this approach "optimal" ? Here is an example of things we cannot do until dependencies are resolved...heck, at the bottom of this email* is the entire Roassal install "log" that I saved when I installed the package:
I can either port the AthensCairoPathBuilder or I can move the functionality to your BalloonPathBuilder. Since I know nothing about either, it will be equally painful to implement either, so the question becomes, which path yeilds the best results going forward? Consider too, that "grok FFI" is on my skillset todo-list and Athens-Cairo looks like it would put a checkmark on that todo-list item. I do not know enough to make an informed decision (I intuitively prefer to get the base right, but as we discovered with the pharo kernel bytes fiasco, that is not always possible) Your thoughts? cheers, tty. *Install log follows:
|
Hi timothy, my personal opinion is that, for Squeak, it would be more interesting to get a working implementation in Balloon going, rather than porting Athens. Having Athens-Cairo would bring higher quality graphics (as of right now), but it's also a rather large dependency that may introduce portability issues, while we know for sure that Balloon "just works". Staying with Balloon could also make running the Roassal port in some of the Squeak derivatives such as SqueakJS, GraalSqueak or RSqueak simpler than depending on FFI. Note, however, that I have not dug deep into Athens' code, so I may be over- or underestimating the complexity it would introduce. I do know that the Balloon backend for Athens (porting which would also be an option) was very incomplete when I last looked at it. Best, Tom On Sun, Oct 25, 2020 at 2:24 PM gettimothy via Squeak-dev <[hidden email]> wrote:
|
In reply to this post by Squeak - Dev mailing list
Hi Timothy,
On Oct 25, 2020, at 6:24 AM, gettimothy via Squeak-dev <[hidden email]> wrote:
So for the moment you should roll you own or host above BitBLT until we can move to Morphic3. This is essential. Under no circumstances should you release something using Athens/Cairo. If will do lasting damage to this community and its strategic direction and viability.
_,,,^..^,,,_ (phone) |
In reply to this post by Tom Beckmann
On Oct 25, 2020, at 6:39 AM, Tom Beckmann <[hidden email]> wrote:
|
In reply to this post by Squeak - Dev mailing list
Hi Tom, Eliot has chimed in with a resounding, "Oh! The Humanity!!!" Hindenburg level Disaster alert, so port to Balloon(?) is the way to go and Cairo is a no go. So then, should we mirror the Athen's heirarchy with Balloon stuff? What I am saying, is that, rather than hacking a hodge-podge, I would feel better with a structure to adhere to. In my Browser, I see "Balloon-Collections, Engine, Fills, Geometry, Simulations and then I see Graphics-Display, Primitives....etc. I also see the RSAthensMorph.... For that "install log " list of messages/classes that must be implemented, I am more than happy to create the methods in appropriate places and go from there. I just do not know the appropriate places. Some mapping strategy...I guess I could try to intuit it, but others who know this stuff may have better ideas. cheers,
On Sun, Oct 25, 2020 at 2:24 PM gettimothy via Squeak-dev <[hidden email]> wrote:
|
In reply to this post by Eliot Miranda-2
My understanding is that Athens in itself has nothing to do with FFI. The Cario FFI calls are encapsulated in the Athen-Cario backend. Indeed,
with an Athens-HTML backend Matthius seems to have got Athens running on Amber, which I'm sure doesn't have FFI... https://www.youtube.com/watch?v=9nAkiwbZZEQ An Athens-Balloon seems to have been planned, slide 7... https://rmod.inria.fr/archives/talks/2012-PharoConf-Athens.pdf I don't know the status. cheers -ben On Sun, 25 Oct 2020 at 21:44, Eliot Miranda <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |