October 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Esteban Lorenzano

> On 7 Oct 2017, at 10:10, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Yes it would be good that class description do not use category else > we will never be able to clean. but as I said to Denis, adapting tonel would be easy, but it would be a cosmetic change when what we actually need is to adapt the structure. Right now Ring2 supports this, but Monticello metadata still doesnât. And I prefer to do the real fix, not just the cosmetic oneâ¦ for me putting a line like this: TonelWriter >> methodDefinitionOf: aMethodDefinition ^ self toSTON: (OrderedDictionary new at: #protocol put: aMethodDefinition category; yourself) would be a smell, and pointless. but: methodDefinitionOf: aMethodDefinition ^ self toSTON: (OrderedDictionary new at: #protocol put: aMethodDefinition protocol; yourself) looks a lot better :) Esteban > > 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.self(a)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(a)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 <estebanlm(a)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 >>> >>> >

Oct. 7, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Esteban Lorenzano

> On 7 Oct 2017, at 08:14, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > How method history will be supported with Tonel? we will use git blame, probably. or we will use log from class then take definitions and trace method changes. what is easier to implement (right now, I think is the 2nd, what looks easierâ¦ ) Esteban ps: btw, 2nd way is how plain Monticello supports method history too. > > 2017-10-06 19:18 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > 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 <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/MUDClient> > https://github.com/estebanlm/pharo-tonel <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 <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 <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 >

Oct. 7, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Esteban Lorenzano

> On 7 Oct 2017, at 08:10, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Esteban > > 2017-10-06 19:18 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > 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 <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/MUDClient> > https://github.com/estebanlm/pharo-tonel <https://github.com/estebanlm/pharo-tonel> (this was just an example and it has some minimal errors already fixed) > > Did you accept format changes? > Because it still uses category for the class. Really, we are moving away from it. Class has package and tags. > Method also needs support for multiple tags. While you are not agree on using tags terminology Tonel still uses single category for this. > I think it is important for the new format to not use deprecated names and add support for upcoming features. Instead we will be forced to maintain old Tonel format at some point. > And what about slots and class extensions? Do you have example for them? We will support changes when the subjacent model changes. Just cosmetic changes are a no go for me, because thatâs always arguably. For example, is been months that Iâm telling you that protocols and tags are not the same, even if mechanically they behave the same :) So, tonel will support âprotocolâ (and âprotocolsâ) instead category (when MCMethodDefinition changes). But for sure it will not support âtagâ or âtagsâ :P It will support slots tooâ¦ just when MC metamodel supports it. Class extensions are there: Object.extension.class, for example. Now, Tonel format is thought to be flexible because we intend to use it to replace file tree and file tree *is* flexible. Using STON definitions allows us to quickly adapt at the only price of being backward compatible a reasonable amount of time. So, it will adaptâ¦ but as I said, it will adapt with real system changes. Esteban > > > 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 <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 <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 >

Oct. 7, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Esteban Lorenzano

> On 6 Oct 2017, at 23:44, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 06/10/2017 Ã 23:34, Tim Mackinnon a Ã©crit : >> 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 >> >> > Hi, > > I cannot say for class, but the {} for methods metadata (as protocols) > is because it is STON. yeah, thatâs the reasonâ¦ we use STON to store package/class/method metadata. And STON uses curly braces :S not a big fan either, but at a point I had to make the thing work :) Esteban > > -- > Cyril Ferlicot > https://ferlicot.fr <https://ferlicot.fr/> > > http://www.synectique.eu <http://www.synectique.eu/> > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France

Oct. 7, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Esteban Lorenzano

> On 6 Oct 2017, at 21:56, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Fri, Oct 6, 2017 at 4:46 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: > Le 06/10/2017 Ã 21:38, Cyril Ferlicot D. a Ã©crit : > > Le 06/10/2017 Ã 21:34, Mariano Martinez Peck a Ã©crit : > >> I followed the instructions to update Iceberg from in a 6.1 image. When > >> I tried to clone the repository, I have the attached error (DNU on > >> #dangerTextColor). I workedaround that by doing: > >> > >> IceAbstractModel >> colorError > >> ^ Color red > >> > >> After I manage to make some progress and I finally was able to clone the > >> repository, I get a #free DNU (see attached too). > >> > > > > Hi, > > > > I introduced #dangerTextColor in Pharo 7 and used it on Iceberg. But I > > though I added it to #Iceberg-Pharo6 package. > > > > I'll check and do a hotfix when I'll have the time. > > > > Humâ¦ This is weird because I see those methods in the Iceberg-Pharo6 > package and I see this package in the baseline. > > Can you check if you have this package? > > > Weird.... that package is not being loaded... sure I can explicitly load it ... but I think we must fix the baseline... but the baseline looks correct doesnt it ? I don't understand. I will release 0.6.1 with that fix and all problems that arise this week end ;) Esteban > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Oct. 7, 2017

Re: [Pharo-dev] Reproducible VM Crash using UFFI

by Esteban Lorenzano

> On 7 Oct 2017, at 00:11, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > 2017-10-06 2:39 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: >> >> >>> On 6 Oct 2017, at 05:34, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>> >>> Hi Nicolas >>> >>> 2017-10-05 16:04 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>> >>>> 2017-10-05 15:42 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >>>>> >>>>> I tried, now I get an exception "Use ExternalAddress instead!" >>>>> >>>>> I guess the message means Use ExternalAddres in the "out" parameter. >>>>> But replacing byte with ExternalAddress also crashes the VM (crash.dmp >>>>> attached). >>>>> >>>>> >>>>> >>>>> 2017-10-05 10:03 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>> >>>>>>> On 5 Oct 2017, at 14:55, HernÃ¡n Morales Durand >>>>>>> <hernan.morales(a)gmail.com> wrote: >>>>>>> >>>>>>> Forgot to comment that Nacl worked in Pharo 5. >>>>>> >>>>>> yes but that was with NB and there are some minimum differences. >>>>>> I do not have the library and I lack the time to try more, but seems to >>>>>> me that here: >>>>>> >>>>>> apiCryptoHashSha512Output: outByteArray input: inByteArray inputLength: >>>>>> inByteArrayLength >>>>>> >>>>>> ^ self >>>>>> ffiCall: #(long crypto_hash_sha512_ref (byte * >>>>>> outByteArray, byte * inByteArray, ulonglong * inByteArrayLength)) >>>>>> module: 'libsodiumâ. >>>>>> >>>>>> >>>>>> instead "byte * outByteArrayâ, you want "byte **outByteArrayâ >>>>>> >>>>>> can you try? >>>>>> >>>>>> Esteban >>>>>> >>>> >>>> >>>> Hmm no, internet reference says: >>>> >>>> extern int crypto_hash_sha512_ref(unsigned char *,const unsigned char >>>> *,unsigned long long); >>>> >>>> The error is rather that you pass the address of length rather than the >>>> length... >>>> So you pass an erroneous length that may lead to a segfault... >>>> >>> >>> Yes, that extra * was the error indeed. >>> Thank you Nicolas. >>> >>> I do not know the VM internals, however I wonder if it is >>> understandable to expect a VM crash for a typo like this? >>> Maybe it is too difficult to catch in the VM side? >>> >>> Just asking, not criticizing anyone's work. >> >> Of course that is normal. This is C code, any error has the potential to crash your program. In C there are no runtime safe guards. >> >> There is a reason why we like/use Pharo. >> > > However there are a couple of lightweight libraries which claim to > provide exceptions for C: > https://github.com/guillermocalvo/exceptions4c <https://github.com/guillermocalvo/exceptions4c> or this one > https://github.com/psevon/exceptions-and-raii-in-c <https://github.com/psevon/exceptions-and-raii-in-c> > > I wonder if something like that could be used in UFFI Nothing in C *ever* will save you from accessing bad memory blocks. And yes, it will always crash your program. those links you point are exception mechanisms, a set of tools to easy the catch of programming exceptions. But, if you try to read a chunk of memory in, say 0x8000 and the data/function that should be there is now garbage, youâre screw. as Sven pointed, thatâs why we use higher level languages, with GC and all that. Esteban > > >>> HernÃ¡n >>> >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> HernÃ¡n >>>>>>> >>>>>>> 2017-10-05 3:23 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>>>> H Hernani, >>>>>>>> >>>>>>>> Most probably is a problem in the library and not UFFI, but I could >>>>>>>> not know without a crash report. >>>>>>>> >>>>>>>> Esteban >>>>>>>> >>>>>>>>> On 5 Oct 2017, at 06:00, HernÃ¡n Morales Durand >>>>>>>>> <hernan.morales(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I ported Nacl (a libsodium wrapper) from the old FFI apicall: format >>>>>>>>> to use the UFFI ffiCall:, but there should be something terribly >>>>>>>>> wrong >>>>>>>>> because is crashing the VM, in both Windows 8.1 and Linux. >>>>>>>>> >>>>>>>>> How to reproduce in Pharo 6.1 >>>>>>>>> >>>>>>>>> Metacello new >>>>>>>>> smalltalkhubUser: 'tonyg' project: 'Crypto-Nacl'; >>>>>>>>> configuration: 'Nacl'; >>>>>>>>> version: #development; >>>>>>>>> load. >>>>>>>>> >>>>>>>>> (Nacl hashString: 'The quick brown fox jumps over the lazy dog') hex >>>>>>>>> >>>>>>>>> This one does deserve a bug entry? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> HernÃ¡n

Oct. 7, 2017

Re: [Pharo-dev] Swimming with the fish imagery

by Stephane Ducasse

Did you watch the What is Pharo videos of the mooc :) On Sat, Oct 7, 2017 at 3:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > > "Swimming with the fish" is a catchy phrase that I like which seems to > encompass the strength of Pharo's tight development feedback loop that comes > from operating in a world of live objects. I had some imagery floating > through my head on this I thought worth sharing. Only time for a quick dump, > but I hope you can piece it together... > > > In the style of one of those fast paced cartoon product videos... > > Scene 1: > "The development process we all know..." > A neutral background with directed arcs in circle > "Debug-->Edit-->Compile-->Execute-->" > > > Scene 2: > "In most languages... debugging..." > Zoom in on Aquarium 1 to show a developer standing outside aquarium > window... > https://tinyurl.com/PharoSwimWithTheFish-Outside > > reaching in through quarantine-box-like-gloxes to use telescopic tools to > pick up and examine fish at a distance... > https://tinyurl.com/PharoSwimWithTheFish-OtherTool > > until the lightbulb moment... > https://tinyurl.com/PharoSwimWithTheFish-Lightbulb > > > Scene 3: > "In most languages... editing...." > Developer zooms out away from aquarium. It folds up into a tiny box and > drops in a bin. > Developer zooms in on an architectural drafting table with many drawings > with many different but simple flow diagrams on each. Quickly make required > edit to flow diagrams. > https://tinyurl.com/PharoSwimWithTheFish-OtherEdit > > > Scene 4: > "In most languages... compiling..." > Drawings pass through a photocopier into a box that is transferred to site > supervisor. > At an empty flat construction site, supervisor opens box pulling out > drawings to review them. > Trucks and machines arrive and start building the aquarium at his > direction... > Two buildings clash when they overlap the same space (compile error). Return > to Scene 3 to fix design then rerun Scene 4 through to completion. > > > Scene 5: > " In most languages... execution..." > Water trucks arrive and pour water into the pool, then more trucks arrive > adding the fish. > (i.e. initialization and getting to the point of the program you want check > again) > > > Scene 6: > "In most languages... debugging..." > Complete the loop by starting scene 3 again. > > > Scene 7: > "In Pharo.... debugging..." > Zoom out, over and into Aquarium 2 where a developer is swimming inside the > pool... > https://tinyurl.com/PharoSwimWithTheFish-Inside > http://blog.atlantisthepalm.com/wp-content/uploads/2017/05/different-in-wat… > > Developer grabs a fish, shifts it aside, lets it go to swim some more, grabs > it again, holds it up close to look a small detail. Out of nothing creates > a new fish to interact with the first fish. > Out of nothing creates some clay and then moulds a new scope-like tool from > it to look at the fish differently. > > Lightbulb moment... > https://tinyurl.com/PharoSwimWithTheFish-Lightbulb > > "In Pharo.... editing..." > Developer peers into brain of fish seeing many neurons, picks one out which > shows as simple flow diagram, makes a change to it. > > "In Pharo.... compiling..." > Laser beam quickly scans the simple flow diagram and packs neuron back into > the fish. > > "In Pharo.... execution..." > Fish swims off. > > "In Pharo.... debugging..." > Developer grabs another fish... > > > Scene 8: > Zoom out to show both aquariums. > In Aquarium 1, repetitively run through Scenes 2 through 6 > In Aquarium 2, repetitively run through Scene 7. > Play at 10x original speed. > > Fade in a "Debug-->Edit-->Compile-->Run-->" over each aquarium, showing > synced state transitions. > > Fade in "Come swim with the fish with Pharo" > Fade in "It will change the way you think about programming" > > > cheers -ben

Oct. 7, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Stephane Ducasse

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.self(a)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(a)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 <estebanlm(a)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 >> >>

Oct. 7, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Stephane Ducasse

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(a)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 <estebanlm(a)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 > >

Oct. 7, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Denis Kudriashov

How method history will be supported with Tonel? 2017-10-06 19:18 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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 >

Oct. 7, 2017