Yes it would be good that class description do not use category else
we will never be able to clean.
Denis multiple tags for methods. when we will stop to add new features
and stabilise what we have?
Yes I'm not in a good mood because I see that I will have to migrate
all calypso in the future to brick.
Stef
On Sat, Oct 7, 2017 at 10:08 AM, Stephane Ducasse
<stepharo.s...@gmail.com> wrote:
> Tim
>
> we talk about this format of methods year ago and we will like it and
> we will not discuss it anymore.
> For the record a method is a named block so it fits and we do not have
> to have {} for method delimiters.
>
> Stef
>
> On Fri, Oct 6, 2017 at 11:34 PM, Tim Mackinnon <tim@testit.works> wrote:
>> Gosh - It actually work quite well to be able to easily browse code online
>> in a more traditional format of seeing an entire class. Hopefully this leads
>> to us being able to share solutions to common language agnostic problems.
>>
>> One small observation - I quickly grok’d the use of class { …. } (with the
>> curly braces) - but given that smalltalk methods often have lots of [ ]
>> (square braces in them), I was a bit surprised to see that method
>> declarations in tonal don’t use { … } (curly braces) to denote them, but
>> instead use [ ] - which feels slightly strange given the class declaration
>> above has. {}.
>>
>> Was it easier to parse this way, or is there some subtlety I missed? I would
>> have been tempted to use {} for classes and methods and [] for the
>> protocols as this more closely matches what other languages do - and it
>> might actually make it more easily readable for other programmers. Given we
>> have to learn this new format anyway - I’d be prepared to give a nod to what
>> others do…
>>
>> Possibly this observation comes to late - and maybe there is compelling
>> reason to go the route we have gone - but maybe its worth a quick double
>> check as its an exciting development.
>>
>> Tim
>>
>> On 6 Oct 2017, at 18:18, Esteban Lorenzano <esteba...@gmail.com> wrote:
>>
>> Hi all,
>>
>> I released Iceberg version 0.6. It includes a lot of small tweaks and fixes,
>> but the most important inclusion is tonel file format which aims to replace
>> file tree.
>>
>> What is Tonel? (https://github.com/pharo-vcs/tonel)
>> Tonel is a file-per-class file format for monticello repositories. It’s
>> purpose is to reduce the amount of files touched each operation, make the IO
>> faster an compact the repositories database.
>> It has also as an objective to offer an “easy-to-read” format, so people
>> wanting to understand a chunk of code will recognise it easily.
>> For testing, I migrated several of my projects to Tonel and I’ve been using
>> it, you can see some as examples:
>>
>> https://github.com/estebanlm/MUDClient
>> https://github.com/estebanlm/pharo-tonel (this was just an example and it
>> has some minimal errors already fixed)
>>
>> We plan to migrate Pharo development to tonel to address some problems we
>> have:
>>
>> - since it has to read/write a lot of files, IO operations are slow
>> - and even much more slow in Windows
>> - Windows also has a problem with longpaths.
>>
>> Iceberg 0.6 will be integrated to Pharo7 soon :)
>> To update Pharo 6.1, there are instructions in the readme:
>> https://github.com/pharo-vcs/iceberg/blob/master/README.md
>> now, if you wan to migrate your projects to Tonel (from FileTree), here is a
>> script you can use:
>> https://github.com/pharo-vcs/tonel/blob/master/MigrateFromFileTree.md
>>
>> btw, tonel is independent of Iceberg and can be used with plain Monticello
>> (but it is a metadaless format, history will reside on git, not on
>> monticello).
>>
>> cheers,
>> Esteban
>>
>>
