<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">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">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">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">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">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>