<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Good question. Why a thing like Tonel,
instead of just Smalltalk?<br>
The short answer is that Smalltalk doesn't have syntax for
anything larger than a method. <br>
<br>
Filetree creates one file per method, so each file can be just
Smalltalk. Filetree doesn't work well for large bodies of code --
operating systems tend to allocate a minimum of 4K to each file.
Since most methods are *much* shorter than 4K, most of the space
is unused. If you have a million methods (and some of my customers
*do* have a million methods) the space requirements are
prohibitive. The answer is to put more than one method into most
files.<br>
<br>
When you start to pack more than one method into the same file,
you need some kind of syntax beyond Smalltalk to tell you where
each method begins and ends, and other meta-information like class
definitions and whether a method is a class method or an instance
method and what category it belongs in is also needed. Smalltalk
doesn't have syntax for that.<br>
<br>
Tonel tries to keep the methods themselves as much pure Smalltalk
and as readable as possible. The extra syntax is needed for the
things outside the methods.<br>
<br>
Note that Tonel is *not* chunk format. Chunk format dates back to
Smalltalk-80, and is not part of Tonel. No '!!' in Tonel files.
:-) <br>
Chunk format did exist for a similar reason, though, that some
kind of syntax beyond Smalltalk is needed if you want to put more
than one method in a file. Chunk format was imperative for the
things outside of methods (things like class definitions are
essentially do-its). This has led to serious awkwardness over the
years, so Tonel is entirely declarative.<br>
<br>
Hope that helps,<br>
-Martin<br>
<br>
On 8/26/20 5:04 PM, Kjell Godo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAM+JcOhQ146FP3jxpdmBXuoYrS+MPRvrH3PH04FiV8E6Y4Rm2w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>
<div dir="auto">i realize that you want to keep the ball rolling
and all</div>
</div>
<div dir="auto">and not waste the previous efforts</div>
<div dir="auto">but why make a special Tonel syntax ?</div>
<div dir="auto">why not just use Smalltalk and String literals
Number literals etc</div>
<div dir="auto">then it will be easy to change</div>
<div dir="auto">and isn’t this whole chunk format </div>
<div dir="auto">that shows up in Package Files</div>
<div dir="auto">an artifact of the limited hardware of yor</div>
<div dir="auto">or i can’t tell why they used it instead of just
using Smalltalk</div>
<div dir="auto">i can’t see why you wouldn’t just use Smalltalk
instead of these ! ! bang things</div>
<div dir="auto">and all are there some C style hard limits
that can run you afoul ?</div>
<div dir="auto">no there are not</div>
<div dir="auto">but this is not helping to keep the ball rolling
no</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Aug 26, 2020 at
13:37 Martin McClure <<a
href="mailto:martin@hand2mouse.com" moz-do-not-send="true">martin@hand2mouse.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jakob,<br>
<br>
Thanks for your interest. I'll send you the draft under
separate cover. <br>
Putting it on GitHub is probably the best option -- I'll try
to get that <br>
set up within the next couple of days, and announce it on
the list when <br>
I do.<br>
<br>
Regards,<br>
-Martin<br>
<br>
On 8/26/20 1:04 PM, Jakob Reschke wrote:<br>
> Hello Martin,<br>
><br>
> While I probably won't be able to provide comprehensive
feedback or<br>
> even read the whole text in the near future, I would
certainly be<br>
> interested to have a look.<br>
><br>
> What is the licensing status of the draft and future
proposed<br>
> standard? If it is in some plain text/markup format, is
it possible to<br>
> upload the draft to a public GitHub repository? Or
something similar<br>
> that allows for commenting on changes. On GitHub one
can only comment<br>
> on diffs, but the initial commit will add all the
lines, so one could<br>
> still comment on all of the text. Also people could
provide suggested<br>
> changes via pull requests.<br>
><br>
> Kind regards,<br>
> Jakob<br>
><br>
> Am Mi., 26. Aug. 2020 um 21:20 Uhr schrieb Martin
McClure<br>
> <<a href="mailto:martin@hand2mouse.com"
target="_blank" moz-do-not-send="true">martin@hand2mouse.com</a>>:<br>
>> Hi all,<br>
>><br>
>> Dale let me know this morning that Tonel was being
discussed on<br>
>> Squeak-dev. I beg your pardon for arriving late.<br>
>><br>
>> As Dale said, I'm the minder of the Tonel 1.0
standard, which is<br>
>> currently in draft, with initial feedback from some
of the folks who<br>
>> have implemented or are interested in implementing
Tonel for their<br>
>> Smalltalk dialect.<br>
>><br>
>> I'm interested in getting feedback from *all*
dialects who are<br>
>> interested in using Tonel. I hope that the Squeak
community will<br>
>> participate.<br>
>><br>
>> Tonel started as a collaboration between Pharo
(primarily Esteban<br>
>> Lorenzano) and GemTalk (primarily me), but the
intent has always been to<br>
>> have a format that can be used in common between
*all* dialects of<br>
>> Smalltalk. The fundamental shape of Tonel is
probably not going to<br>
>> change at this point, but feedback so far is likely
to result in some<br>
>> changes to the draft standard.<br>
>><br>
>> Note that Tonel as currently implemented by Pharo
is a bit different<br>
>> from standard Tonel. Pharo has agreed to make
several changes to the<br>
>> format to standardize it. I'm not sure what the
status of those changes<br>
>> within the Pharo project. The GemStone
implementation is closer to the<br>
>> standard, though not fully there yet.<br>
>><br>
>> I encourage the Squeak community to consider
whether coding to the<br>
>> standard early on might be a desirable direction.
As Dale explained, the<br>
>> standard does allow for dialect-specific
properties, so adding<br>
>> timestamps probably doesn't require any changes to
the spec.<br>
>><br>
>> I'd like it If a few folks from the community would
volunteer to give<br>
>> the spec a careful read-through and comment. It's a
bit of a read (and<br>
>> was quite a bit of effort to write!) so I won't
post the draft on the<br>
>> list, but it's available by request, and I need to
figure out a place to<br>
>> make it readily available.<br>
>><br>
>> Regards,<br>
>> -Martin<br>
>><br>
>><br>
>> On 8/26/20 9:41 AM, Dale Henrichs wrote:<br>
>>> Eliot,<br>
>>><br>
>>> When you repost, could you make sure that you
include a description of<br>
>>> where the time stamps are stashed ... I'm
assuming that you are adding<br>
>>> it to the method properties (where the category
is stashed) as I think<br>
>>> that this is the right place, but it's always
best not to guess:)<br>
>>><br>
>>> The current crop of Tonel readers/writers do
not necessarily do a good<br>
>>> job of preserving, foreign data (IIRC, the
convention is to add a<br>
>>> platform prefix to the property name, which is
the same convention<br>
>>> used for class properties ... at GemStone we
add a leading `gs_` to<br>
>>> our property names), so until we can get all of
the different Tonel<br>
>>> readers/writers to preserve foreign properties
(package, class and<br>
>>> method) it will continue to be dicey business
for preserving foreign<br>
>>> properties in cross platform projects ...<br>
>>><br>
>>> Monticello does not explicitly preserve foreign
properties as the<br>
>>> definitions get created from the native
objects, so it takes some<br>
>>> additional work to arrange to preserve foreign
properties for<br>
>>> packages, classes, and methods in the objects
themselves. So it is<br>
>>> worth considering what you will do with
preserving foreign properties<br>
>>> from other platforms.<br>
>>><br>
>>> FWIW, I intend to support the preservation of
foreign properties in<br>
>>> Rowan (read that as "I haven't done that yet":)<br>
>>><br>
>>> Finally, Martin McClure has started working on
a spec for the next<br>
>>> generation Tonel format ... to add a few
missing pieces and tweak the<br>
>>> format to make it possible to continue to
evolve the Tonel format into<br>
>>> the future in a somewhat sane way. If there are
folks here in the<br>
>>> Squeak community who would like to review,
comment and participate in<br>
>>> the creation of the next generation format,
send me (or Martin) mail<br>
>>> and we'll get you added to the mailing list.<br>
>>><br>
>>> Dale<br>
>>><br>
>>> On 8/26/20 7:15 AM, Eliot Miranda wrote:<br>
>>>> Jakob,<br>
>>>><br>
>>>>> On Aug 26, 2020, at 2:45 AM, Jakob
Reschke <<a href="mailto:forums.jakob@resfarm.de"
target="_blank" moz-do-not-send="true">forums.jakob@resfarm.de</a>><br>
>>>>> wrote:<br>
>>>>><br>
>>>>> Hi Eliot,<br>
>>>>><br>
>>>>>> Am Mi., 26. Aug. 2020 um 11:20 Uhr
schrieb Eliot Miranda<br>
>>>>>> <<a
href="mailto:eliot.miranda@gmail.com" target="_blank"
moz-do-not-send="true">eliot.miranda@gmail.com</a>>:<br>
>>>>>><br>
>>>>>> If we go with Tonel then we must
change it to support method<br>
>>>>>> timestamps. I have a change set
that does this (it is a trivial<br>
>>>>>> change). And my changes are
controlled by a class variable so that<br>
>>>>>> the same code can produce Pharo
format or a slightly modified<br>
>>>>>> format that includes method
timestamps.<br>
>>>>>><br>
>>>>>> What I don’t understand is why
Esteban Lorenzano refuses to accept<br>
>>>>>> my changes and allow Tonel to be
used either with or without method<br>
>>>>>> timestamps.<br>
>>>>>><br>
>>>>> Method timestamps produce merge
conflicts inevitably.<br>
>>>> a) only when they change, and they change
only when methods change<br>
>>>> b) inadvertent method timestamp changes can
be undone automatically<br>
>>>> c) Squeak uses method timestamps; we have
lots of tools that use<br>
>>>> them. Dropping them just so that we can use
Tonel is an example of<br>
>>>> the tail wagging the dog. The Tonel
interface must instead be made to<br>
>>>> function with method timestamps<br>
>>>><br>
>>>> If there is a decision not to support
method timestamps then I will<br>
>>>> not support the work. This is a make or
break issue for me.<br>
>>>><br>
>>>>> Can you re-post<br>
>>>>> your changeset here?<br>
>>>> I’ll post it later today (reading email in
bed right now).<br>
>>>><br>
>>>>> <a
href="https://github.com/squeak-smalltalk/squeak-tonel/issues"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/squeak-smalltalk/squeak-tonel/issues</a><br>
>>>> OK<br>
>>>><br>
>>>>> Then we could<br>
>>>>> discuss whether to include it at least
in the Squeak version. As we<br>
>>>>> have heard from Mariano some time ago,
VA Smalltalk also puts its<br>
>>>>> dialect-specific metadata in the Tonel
format, so Squeak would not be<br>
>>>>> the first to do so.<br>
>>>> Good.<br>
>>>><br>
>>>>> Kind regards,<br>
>>>>> Jakob<br>
>><br>
<br>
<br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<br>
</body>
</html>