Roassal3 "action plan"

Hi Tom,

After thinking on it, it makes sense to port all the pharo Athens calls to methods in "some appropriate class" in the Balloon or Graphics area and modifying the pharo call to those methods to use the Balloon/Graphics methods.

AND

when doing that, duplicate the Tests for those calls.

All the while asking for pointers on specific instances.

The approach gives me a needed structure, instead of doing "stupid stuff" like cloning in the GraphicsPaint class from Athen's directly into squeak, just to make things work.

Sound like a plan?

Hi timothy,

what I could gleam from the Roassal codebase, my assumption is that their design initially started out with an arbitrary graphics backend in mind but, gradually, some lower-level aspects leaked into the domain-specific high-level code. You can see that the codebase contains two or three classes specifically with "Athens" in their name, which typically aim to abstract and collect the interface needed by Roassal to produce graphics. So, our goal would be to extend these abstractions to serve the use cases where Athens-specific code currently exists in the Roassal domain layer. Then, we can "simply" go in, provide a second interface that uses Balloon as its backend and we're done! Since an incremental process is obviously beneficial here and will yield the fastest sense of progress, starting out by creating this Balloon interface and making it just about serviceable is what we currently have in our repo. I believe Balloon as an engine should be able to express just about all the requirements that Roassal puts on Athens, even though I'm rather sure we'll have to employ some trickery for e.g. text.

To make it more concrete: I think your approach of going test by test or example by example should work well. Ideally, you would compare the output of each example with what you find in Pharo and see where things are currently entirely broken or missing. If you then encounter a test/example that uses Athens-specific code, try to isolate the code in one of the abstraction classes, such as the RSAthensMorph or RSAthensRenderer and try to provide an equivalent implementation for our own RSBalloonMorph and RSBalloonRenderer classes. Eventually, we can then simply not load the RSAthensMorph and RSAthensRenderer were all Athens-specific code is isolated and should thus no longer encounter code that cannot load in Squeak.

Additionally, it may be worthwhile to keep a separate document in case we encounter larger architectural issues where Roassal and Athens code are intertwined, such that the Roassal team can review the document rather than having to sift through a pull request of thousands of lines.

Best,

Tom

Hi Tom

thanks for the reply.

cheers.

p.s. I am saving to a local monticello repo as I go. Its easier than me having to relearn Metacello and the Git is just a reference at this point.

it's great that you are working on this! Once it's (somewhat) running, I can write some wrappers for the vizualizations to make them work in Vivide (http://github.com/hpi-swa/vivide).

Best,

Marcel

Am 25.10.2020 16:43:37 schrieb gettimothy via Squeak-dev <[hidden email]>:

Hi Tom

thanks for the reply.

what I could gleam from the Roassal codebase, my assumption is that their design initially started out with an arbitrary graphics backend in mind but, gradually, some lower-level aspects leaked into the domain-specific high-level code. You can see that the codebase contains two or three classes specifically with "Athens" in their name, which typically aim to abstract and collect the interface needed by Roassal to produce graphics. So, our goal would be to extend these abstractions to serve the use cases where Athens-specific code currently exists in the Roassal domain layer. Then, we can "simply" go in, provide a second interface that uses Balloon as its backend and we're done! Since an incremental process is obviously beneficial here and will yield the fastest sense of progress, starting out by creating this Balloon interface and making it just about serviceable is what we currently have in our repo. I believe Balloon as an engine should be able to express just about all the requirements that Roassal puts on Athens, even though I'm rather sure we'll have to employ some trickery for e.g. text.

Athens becomes Balloon....

To make it more concrete: I think your approach of going test by test or example by example should work well. Ideally, you would compare the output of each example with what you find in Pharo and see where things are currently entirely broken or missing. If you then encounter a test/example that uses Athens-specific code, try to isolate the code in one of the abstraction classes, such as the RSAthensMorph or RSAthensRenderer and try to provide an equivalent implementation for our own RSBalloonMorph and RSBalloonRenderer classes. Eventually, we can then simply not load the RSAthensMorph and RSAthensRenderer were all Athens-specific code is isolated and should thus no longer encounter code that cannot load in Squeak.

cool!  That's what I am doing now. The emphatic "NO" on Cairo is what I needed to hear to proceed down this path.

btw, I got two more of those tests working by adding a method to BallonPathBuilder...steps to get all but the four last ones are:

===modify messages for pharo-isms===

need stdev  from pharo   in Collection 

stdev

| avg sample sum |

"In statistics, the standard deviation is a measure that is used to quantify the amount of variation or dispersion of a set of data values.

For details about implementation see comment in self sum."

avg := self average.

sample := self anyOne.

sum := self inject: sample into: [ :accum :each | accum + (each - avg) squared ].

sum := sum - sample.

^ (sum / (self size - 1)) sqrt

flatCollect: becomes 'gather:'.

Browse Collection, add bogus method, flatCollect: aBlock. find senders...

RPackageOrganizer becomes PackageOrganizer

(repeat until all changed)

ClassDescription, add method category *Roassal-Squeak

add method 'numberOfMethods' >> ^self  localSelectors size.

BalloonPathBuilder add method cateogry *Roassal3-Squeak ad method

>>close

self closePath.

===run examples ===

RSChartExample new example01Markers open.

RSChartExample new example02ScatterPlot open.

RSChartExample new example03Plot open.

RSChartExample new example04WithTick open.

RSChartExample new example05WithTick open.

RSChartExample new example06CustomNumberOfTicks open.

RSChartExample new example07AdjustingFontSize open.

RSChartExample new example08TwoCharts open.

RSChartExample new example09LinearSqrtSymlog open.

RSChartExample new example10BarPlot open.

RSChartExample new example11BarplotCombinedWithLine open.

RSChartExample new example12ScatterPlotAndNormalizer open.

RSChartExample new example13AreaPlot open.

RSChartExample new example14AreaPlotWithError open.

xRSChartExample new example15AreaBox open.

xRSChartExample new example16Series open.

xRSChartExample new example17CLPvsUSD open.

xRSChartExample new example18Animation open.

Additionally, it may be worthwhile to keep a separate document in case we encounter larger architectural issues where Roassal and Athens code are intertwined, such that the Roassal team can review the document rather than having to sift through a pull request of thousands of lines.

I will leave that to you, but I will contribute when I encounter that stuff.

Best,

Tom

cheers.

p.s. I am saving to a local monticello repo as I go. Its easier than me having to relearn Metacello and the Git is just a reference at this point.

Tom's working off of a git repo...and, it is Tom's project, so I will let him decide.

cheers.

Hi timothy,

thank you for asking for my opinion here :)

I would say please move to whichever stack you are most comfortable with. I can adapt accordingly for when I find time to contribute again. Eventually, we will have to move back to git to propose upstream changes but until then I see no reason not to use Monticello. I agree with Elliot that it would be very useful to always have your most up-to-date changes somewhere publicly accessible. So please feel free to create a project on squeaksource.com and maybe you could even add me (tobe) and also Eliot (?) as contributors right away.

Best,

Tom

I will do that now,

cheers!

Hi folks,

A Roassal project already exists on Squeaksource.

Not my project. Found this when I went to create the project.

How to proceed?

Create  Roassal3 project?

cheers.