[squeak-dev] "Pretty Print" collections as abstract syntax trees using plain text output

Eliot Miranda eliot.miranda at gmail.com
Thu Oct 1 18:24:24 UTC 2020


Hi t,

On Thu, Oct 1, 2020 at 11:11 AM gettimothy <gettimothy at zoho.com> wrote:

> Hi Eliot
>
>
> ---- On Thu, 01 Oct 2020 11:07:08 -0400 *Eliot Miranda
> <eliot.miranda at gmail.com <eliot.miranda at gmail.com>>* wrote ----
>
> Hi Tty,
>
> On Oct 1, 2020, at 2:33 AM, gettimothy via Squeak-dev <
> squeak-dev at lists.squeakfoundation.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201001/fcd3e6cf/attachment.html>


More information about the Squeak-dev mailing list