<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>FWIW, I am working on a project called Rowan that is a
replacement for Metacello ... Right now I am working on
integrating Rowan into the GemStone build process and the plan is
that Rowan will be included in the next major release of GemStone
... Like Metacello, Rowan is aimed at multiple dialects of
Smalltalk. <br>
</p>
<p>All of the project/package metadata is stored external to the
packages directory. Here is a very simple example project[1] that
has 2 packages[2] RowanSample9-Core and RowanSample9-Tests. The
RowanSample-Tests package is conditionally loaded. if you poke
around in the rowan directory[1], you will see that the project
meta data is being stored on disk in STON format.</p>
<p>Rowan supports both Filetree and Tonel package formats.</p>
<p>There are nearly 60 different sample projects in the RowanSample9
repository[3] each on it's own branch and all of the projects were
created and updated using the Rowan API. The Rowan API encompasses
not only creating and managing project meta data, but the creation
and management of projects/packages/classes/methods. <br>
</p>
<p>The "Rowan API" is segregated into two major pieces: disk format
and in-image api. <br>
</p>
<p>The most important piece of the API is the disk format as that is
the key to sharing projects between smalltalk dialects. At a
minimum all dialects must be able to share the disk format. <br>
</p>
<p>The second component is the in-image api. The in-image api is in
roughly three pieces: Rowan definitions (similar to Monticello
definitions ... extended to include projects and the in-image
representation of the meta data; a loader api which manages the
work of installing definitions into the image; and the loaded
representation of projects, packages, classes and methods.</p>
<p>I'm imagining that different dialects will choose to support
Rowan at different levels. Sharing disk format only; sharing the
definition implementation (which would include reading and writing
definitions to/from disk); sharing the loader implementation; and
sharing the loaded implementation.<br>
</p>
<p>Esteban, Mariano and I talked in December/January about
incorporating sub applications, etc. into Rowan, but we were all
under time constraints at the time and it seems that incorporating
the Envy meta data was going to take a little bit of work. Rowan
has the notion of `components` which are very similar to
subapplications, but subapplications are more restrictive than
components[4] and there was no opportunity for directly mapping
between the two --- without spending a bit of time that we didn't
have ... with that said I am optimistic that Envy metadata can be
incorporated. <br>
</p>
<p>The fact that Rowan serializes objects to disk in STON format,
means that we can have quite a bit of latitude in what how we
shape the metadata that is stored on disk --- which means that if
push comes to shove, Envy style projects may use a different set
of classes than the "standard Rowan project (akin to
Metacello/Monticello projects)". Of course, the Envy style
projects should be loadable and writable on all supported
platforms ...</p>
<p>I am still a couple months away from being done with V2.0 of
Rowan (Rowan V1.0 went into production at one of our customer's
sites 1.5 years ago) and I will have other tasks related to the
next release of GemStone, so I can't forecast when I will start
porting Rowan to other platforms, but that is my intention.<br>
</p>
<p>In the mean time, if there are folks interested in helping with
the port to other platforms, please drop me a line and we can
arrange a chat :)</p>
<p>Dale<br>
</p>
[1] <a class="moz-txt-link-freetext" href="https://github.com/dalehenrich/RowanSample9/tree/spec_0001/rowan">https://github.com/dalehenrich/RowanSample9/tree/spec_0001/rowan</a><br>
[2]
<a class="moz-txt-link-freetext" href="https://github.com/dalehenrich/RowanSample9/tree/spec_0001/rowan/src">https://github.com/dalehenrich/RowanSample9/tree/spec_0001/rowan/src</a><br>
[3] <a class="moz-txt-link-freetext" href="https://github.com/dalehenrich/RowanSample9">https://github.com/dalehenrich/RowanSample9</a><br>
[4] <a class="moz-txt-link-freetext" href="https://github.com/GemTalk/Rowan/issues/553">https://github.com/GemTalk/Rowan/issues/553</a><br>
<div class="moz-cite-prefix">On 5/29/20 12:50 PM, Mariano Martinez
Peck wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAA+-=mX8kGzXDB=unPWZUp-Ts1RugAUJ_1w87TCDJZLzFKiHcQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, May 29, 2020 at 4:34
PM Jakob Reschke <<a
href="mailto:forums.jakob@resfarm.de"
moz-do-not-send="true">forums.jakob@resfarm.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Mariano,<br>
<br>
That is interesting to hear, thank you!<br>
<br>
What is VA Smalltalk's stance about Tonel interoperability
between the<br>
Smalltalks _in the same project_? For example, if the main
developers<br>
use VA Smalltalk, there will be the additional ENVY
properties for<br>
SubApplications and such in the meta files. But when someone
loads the<br>
project in Squeak or Pharo and writes another version, this
will not<br>
include these additional properties. So if this person
created a pull<br>
request, merging it without manual polishing will "destroy"
the<br>
additional setup for VA Smalltalk.<br>
<br>
I am asking because we are facing similar problems between
Squeak and<br>
Pharo, although they are still much closer to one another
than VA<br>
Smalltalk is to any of them.<br>
<br>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Yes, that would be the current situation. Although, if
you can live with certain constrains (like not having
subapps, loosing whether a method is public or private, etc
etc), then its much closer to be interoperable. You can read
more here: <a
href="https://github.com/instantiations/tonel-vast#compatibility-recommendations"
moz-do-not-send="true">https://github.com/instantiations/tonel-vast#compatibility-recommendations</a></div>
<div><br>
</div>
<div>Also, we have an open issue to address the possibility
of storing the VA specific metadata in a separate place: <a
href="https://github.com/instantiations/tonel-vast/issues/49"
moz-do-not-send="true">https://github.com/instantiations/tonel-vast/issues/49</a></div>
<div>But we have a bunch of other higher priority things
first. </div>
<div><br>
</div>
<div>Hope this helps. </div>
<div><br>
</div>
</div>
-- <br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div><font color="#666666">Mariano Martinez Peck</font></div>
<div>
<div dir="ltr">
<div dir="ltr"><font color="#666666">Email: <a
href="mailto:marianopeck@gmail.com"
target="_blank" moz-do-not-send="true">marianopeck@gmail.com</a></font></div>
<div dir="ltr"><font color="#666666">Twitter:
@MartinezPeck</font></div>
<div dir="ltr"><font color="#666666">LinkedIn: <a
href="https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/"
target="_blank" moz-do-not-send="true">www.linkedin.com/in/mariano-martinez-peck</a></font></div>
<div dir="ltr">
<div dir="ltr"><font color="#666666">Blog: <a
href="https://marianopeck.wordpress.com/" target="_blank"
moz-do-not-send="true">https://marianopeck.wordpress.com/</a></font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>