"Pretty Print" collections as abstract syntax trees using plain text output

Hi Tty,

On Oct 1, 2020, at 2:33 AM, gettimothy via Squeak-dev <[hidden email]> wrote:



Hi folks.

Has anybody coded a way , using plain text, to output a 

https://en.wikipedia.org/wiki/Abstract_syntax_tree

to a workspace?

It would be a handy debug tool if so.

An infinitely better way would be to port the Rossal visualisation system.  I’ve talked with Alexandre and he says Rossal is designed with portability in mind (it currently runs on Pharo and BisyalWorks and predates Pharo’s current imaging model).  This would give you a graphical representation of the entire tree, with the ability to attach behaviour to elements of the representation.

thx

Hi t,

On Thu, Oct 1, 2020 at 11:11 AM gettimothy <[hidden email]> wrote:

Hi Eliot

---- On Thu, 01 Oct 2020 11:07:08 -0400 Eliot Miranda <[hidden email]> wrote ----

Hi Tty,

I don't see any mention of Rossal in the below.  What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it?

On Oct 1, 2020, at 2:33 AM, gettimothy via Squeak-dev <[hidden email]> wrote:



Hi folks.

Has anybody coded a way , using plain text, to output a 

https://en.wikipedia.org/wiki/Abstract_syntax_tree

to a workspace?

It would be a handy debug tool if so.

An infinitely better way would be to port the Rossal visualisation system.  I’ve talked with Alexandre and he says Rossal is designed with portability in mind (it currently runs on Pharo and BisyalWorks and predates Pharo’s current imaging model).  This would give you a graphical representation of the entire tree, with the ability to attach behaviour to elements of the representation.

thx

I would love too, Rossal is intriguing.

IIRC , "Mr. Feenk" and the board had a thread recently about "what it would take to make Rossal work on  Squeak" and the discussion decided on waiting on everybody having a block of time to make that happen.

I don't see any mention of Rossal in the below.  What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it?

Here is a cut-n-paste of that email, I saved it for future reference:

Hi,

Currently, at feenk we have feenkcom/opensmalltalk-vm:

https://github.com/feenkcom/opensmalltalk-vm

This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit.

For Glamorous Toolkit we aimed for the following functionality:

    • Open the GUI natively and have native display quality (GUI opened through FFI calls)

    • Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS

    • Create end-user applications that are fully customisable (executable name, menus, etc)

    • Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI.

    • Have Iceberg running in native windows (which requires nested FFI callbacks)

There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible.

Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm.

To have native GUIs we relied on Ronie Salgado’s work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch:

https://github.com/pharo-project/opensmalltalk-vm/tree/headless

That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback.

On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour.

To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package).

Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56).

The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/). When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin). Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17).

While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62.

To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI.

We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper.

Please let us know you would prefer to coordinate.

Cheers,

Tudor, on behalf of the feenk team

--

feenk.com

"The coherence of a trip is given by the clearness of the goal."

If these things have already happened, I can push (most) other projects down the stack and take this up part-time.  Let me know.

Wow, that's quite an offer.  I wish I could devote time to this, and probably won't be able to stay away once it starts, but for the moment I have other commitments precluding joining in this effort. 

If not, I briefly looked into piping output to graphviz via OSProcess .

Regardless, the tool would be invaluable in groking / debugging the PEG grammars.

cheers,

t

_,,,^..^,,,_

best, Eliot

Hi!

The email seems to discuss more about the VM extension. Roassal is a pure software solution.

I would love to see Roassal running on Squeak and other Smalltalks.

Cheers,

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 01-10-2020, at 15:24, Eliot Miranda <[hidden email]> wrote:

Hi t,

On Thu, Oct 1, 2020 at 11:11 AM gettimothy <[hidden email]> wrote:

Hi Eliot

---- On Thu, 01 Oct 2020 11:07:08 -0400 Eliot Miranda <[hidden email]> wrote ----

Hi Tty,

On Oct 1, 2020, at 2:33 AM, gettimothy via Squeak-dev <[hidden email]> wrote:



Hi folks.

Has anybody coded a way , using plain text, to output a 

https://en.wikipedia.org/wiki/Abstract_syntax_tree

to a workspace?

It would be a handy debug tool if so.

An infinitely better way would be to port the Rossal visualisation system.  I’ve talked with Alexandre and he says Rossal is designed with portability in mind (it currently runs on Pharo and BisyalWorks and predates Pharo’s current imaging model).  This would give you a graphical representation of the entire tree, with the ability to attach behaviour to elements of the representation.

http://agilevisualization.com/

thx

I would love too, Rossal is intriguing.

IIRC , "Mr. Feenk" and the board had a thread recently about "what it would take to make Rossal work on  Squeak" and the discussion decided on waiting on everybody having a block of time to make that happen.

I don't see any mention of Rossal in the below.  What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it?

Here is a cut-n-paste of that email, I saved it for future reference:

Hi,

Currently, at feenk we have feenkcom/opensmalltalk-vm:

https://github.com/feenkcom/opensmalltalk-vm

This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit.

For Glamorous Toolkit we aimed for the following functionality:

    • Open the GUI natively and have native display quality (GUI opened through FFI calls)

    • Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS

    • Create end-user applications that are fully customisable (executable name, menus, etc)

    • Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI.

    • Have Iceberg running in native windows (which requires nested FFI callbacks)

There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible.

Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm.

To have native GUIs we relied on Ronie Salgado’s work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch:

https://github.com/pharo-project/opensmalltalk-vm/tree/headless

That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback.

On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour.

To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package).

Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56).

The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/). When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin). Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17).

While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62.

To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI.

We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper.

Please let us know you would prefer to coordinate.

Cheers,

Tudor, on behalf of the feenk team

--

feenk.com

"The coherence of a trip is given by the clearness of the goal."

If these things have already happened, I can push (most) other projects down the stack and take this up part-time.  Let me know.

Wow, that's quite an offer.  I wish I could devote time to this, and probably won't be able to stay away once it starts, but for the moment I have other commitments precluding joining in this effort. 

If not, I briefly looked into piping output to graphviz via OSProcess .

Regardless, the tool would be invaluable in groking / debugging the PEG grammars.

cheers,

t

_,,,^..^,,,_

best, Eliot

The GitHub of Roassal3 is https://github.com/ObjectProfile/Roassal3

I am not sure what are the difference between Pharo and Squeak. Long time I have not looked in detail.

Roassal3 comes with plenty of unit tests. I guess than the starting point is to make the test pass. 

Does Squeak has Athens / Cairo? 

Cheers,

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 01-10-2020, at 16:36, Eliot Miranda <[hidden email]> wrote:

Hi Alexandre,

  where are the Rossal repositories?  If we wanted to begin a port, what would be the best starting point?

On Thu, Oct 1, 2020 at 12:28 PM Alexandre Bergel <[hidden email]> wrote:

I think that Glamorous toolkit has its own visualization engine, unrelated to Roassal

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 01-10-2020, at 15:47, gettimothy <[hidden email]> wrote:

Hi Eiliot,

re: 

I don't see any mention of Rossal in the below.  What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it?

IIRC Glamorous Toolkit  and Rossal are related; perhaps I have conflated the two.

at  https://feenk.com/gt/ you can see the tree graphs I have in mind.

---- On Thu, 01 Oct 2020 14:24:24 -0400 Eliot Miranda <[hidden email]> wrote ----

Hi t,

On Thu, Oct 1, 2020 at 11:11 AM gettimothy <[hidden email]> wrote:

Hi Eliot

---- On Thu, 01 Oct 2020 11:07:08 -0400 Eliot Miranda <[hidden email]> wrote ----

Hi Tty,

I don't see any mention of Rossal in the below.  What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it?

On Oct 1, 2020, at 2:33 AM, gettimothy via Squeak-dev <[hidden email]> wrote:



Hi folks.

Has anybody coded a way , using plain text, to output a 

https://en.wikipedia.org/wiki/Abstract_syntax_tree

to a workspace?

It would be a handy debug tool if so.

An infinitely better way would be to port the Rossal visualisation system.  I’ve talked with Alexandre and he says Rossal is designed with portability in mind (it currently runs on Pharo and BisyalWorks and predates Pharo’s current imaging model).  This would give you a graphical representation of the entire tree, with the ability to attach behaviour to elements of the representation.

thx

I would love too, Rossal is intriguing.

IIRC , "Mr. Feenk" and the board had a thread recently about "what it would take to make Rossal work on  Squeak" and the discussion decided on waiting on everybody having a block of time to make that happen.

I don't see any mention of Rossal in the below.  What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it?

Here is a cut-n-paste of that email, I saved it for future reference:

Hi,

Currently, at feenk we have feenkcom/opensmalltalk-vm:

https://github.com/feenkcom/opensmalltalk-vm

This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit.

For Glamorous Toolkit we aimed for the following functionality:

    • Open the GUI natively and have native display quality (GUI opened through FFI calls)

    • Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS

    • Create end-user applications that are fully customisable (executable name, menus, etc)

    • Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI.

    • Have Iceberg running in native windows (which requires nested FFI callbacks)

There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible.

Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm.

To have native GUIs we relied on Ronie Salgado’s work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch:

https://github.com/pharo-project/opensmalltalk-vm/tree/headless

That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback.

On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour.

To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package).

Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56).

The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/). When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin). Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17).

While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62.

To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI.

We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper.

Please let us know you would prefer to coordinate.

Cheers,

Tudor, on behalf of the feenk team

--

feenk.com

"The coherence of a trip is given by the clearness of the goal."

If these things have already happened, I can push (most) other projects down the stack and take this up part-time.  Let me know.

Wow, that's quite an offer.  I wish I could devote time to this, and probably won't be able to stay away once it starts, but for the moment I have other commitments precluding joining in this effort. 

If not, I briefly looked into piping output to graphviz via OSProcess .

Regardless, the tool would be invaluable in groking / debugging the PEG grammars.

cheers,

t

_,,,^..^,,,_

best, Eliot

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_,,,^..^,,,_

best, Eliot

OpenGL is not directly supported in Pharo I believe, and if it is, it will be more for aiming at 3D graphics than fast 2D. Cairo is offered using a native library which is accessed from Pharo using Athens. 

All the rendering of Roassal3 is made by Athens, which are ultimately translated into native calls to the libcairo using uFFI.

Cheers,

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 03-10-2020, at 07:56, gettimothy <[hidden email]> wrote:

I am currently familiarizing myself with the new-fangled git tools and after that  will

be checking to see if Squeak can run the Cairo and Athens.

Also, since the diagram shows that Cairo sits on top of OpenGL, I will check the OpenGL on the pharo-9 bleeding edge and if it works, correlate with openGL on squeak6.0 alpha.

funny quirk is that Roassal3 is installed on the pristine image of pharo9, and there is Athens installed, but I do not see Cairo or OpenGL installed. Perhaps they are in the Athens Baseline, or I don't know where to look.

cheers.

---- On Thu, 01 Oct 2020 15:58:00 -0400 Alexandre Bergel <[hidden email]> wrote ----

The GitHub of Roassal3 is https://github.com/ObjectProfile/Roassal3

I am not sure what are the difference between Pharo and Squeak. Long time I have not looked in detail.

Roassal3 comes with plenty of unit tests. I guess than the starting point is to make the test pass. 

Does Squeak has Athens / Cairo? 

Cheers,

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 01-10-2020, at 16:36, Eliot Miranda <[hidden email]> wrote:

Hi Alexandre,

  where are the Rossal repositories?  If we wanted to begin a port, what would be the best starting point?

On Thu, Oct 1, 2020 at 12:28 PM Alexandre Bergel <[hidden email]> wrote:

I think that Glamorous toolkit has its own visualization engine, unrelated to Roassal

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 01-10-2020, at 15:47, gettimothy <[hidden email]> wrote:

Hi Eiliot,

re: 

I don't see any mention of Rossal in the below.  What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it?

IIRC Glamorous Toolkit  and Rossal are related; perhaps I have conflated the two.

at  https://feenk.com/gt/ you can see the tree graphs I have in mind.

---- On Thu, 01 Oct 2020 14:24:24 -0400 Eliot Miranda <[hidden email]> wrote ----

Hi t,

On Thu, Oct 1, 2020 at 11:11 AM gettimothy <[hidden email]> wrote:

Hi Eliot

---- On Thu, 01 Oct 2020 11:07:08 -0400 Eliot Miranda <[hidden email]> wrote ----

Hi Tty,

I don't see any mention of Rossal in the below.  What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it?

On Oct 1, 2020, at 2:33 AM, gettimothy via Squeak-dev <[hidden email]> wrote:



Hi folks.

Has anybody coded a way , using plain text, to output a 

https://en.wikipedia.org/wiki/Abstract_syntax_tree

to a workspace?

It would be a handy debug tool if so.

An infinitely better way would be to port the Rossal visualisation system.  I’ve talked with Alexandre and he says Rossal is designed with portability in mind (it currently runs on Pharo and BisyalWorks and predates Pharo’s current imaging model).  This would give you a graphical representation of the entire tree, with the ability to attach behaviour to elements of the representation.

thx

I would love too, Rossal is intriguing.

IIRC , "Mr. Feenk" and the board had a thread recently about "what it would take to make Rossal work on  Squeak" and the discussion decided on waiting on everybody having a block of time to make that happen.

I don't see any mention of Rossal in the below.  What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it?

Here is a cut-n-paste of that email, I saved it for future reference:

Hi,

Currently, at feenk we have feenkcom/opensmalltalk-vm:

https://github.com/feenkcom/opensmalltalk-vm

This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit.

For Glamorous Toolkit we aimed for the following functionality:

    • Open the GUI natively and have native display quality (GUI opened through FFI calls)

    • Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS

    • Create end-user applications that are fully customisable (executable name, menus, etc)

    • Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI.

    • Have Iceberg running in native windows (which requires nested FFI callbacks)

There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible.

Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm.

To have native GUIs we relied on Ronie Salgado’s work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch:

https://github.com/pharo-project/opensmalltalk-vm/tree/headless

That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback.

On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour.

To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package).

Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56).

The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/). When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin). Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17).

While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62.

To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI.

We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper.

Please let us know you would prefer to coordinate.

Cheers,

Tudor, on behalf of the feenk team

--

feenk.com

"The coherence of a trip is given by the clearness of the goal."

If these things have already happened, I can push (most) other projects down the stack and take this up part-time.  Let me know.

Wow, that's quite an offer.  I wish I could devote time to this, and probably won't be able to stay away once it starts, but for the moment I have other commitments precluding joining in this effort. 

If not, I briefly looked into piping output to graphviz via OSProcess .

Regardless, the tool would be invaluable in groking / debugging the PEG grammars.

cheers,

t

_,,,^..^,,,_

best, Eliot

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_,,,^..^,,,_

best, Eliot