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

Class syntax brainstorming

by Luc Fabresse

Hi, Following Pharo Days, I brainstormed about some possible class definition syntaxes. What I have in mind: "basic mechanics, only THIS one in the image!" ClassDefinition new superclass: Object; "optional. If not specified, Object by default ;-)" name: #A; "optional and create an anonymous class if not specified" instVars: 'a b c'; traits: {TEquality}; package: 'Plop'; createClass. " this message sent might be hidden by the browser when accepting" "---------------" "Some IDEAS (but I did not find one that I really like) of scripting/shorter syntaxes that must ALWAYS end up calling the above basic mechanics at the end:" Class fromDefinition: [ :def | def name: #sub; instVars: 'w r g'; superclass: Object ]. Object subclass "<-- returns a subclass of Object but the problem is that the new class is muted each time and the class definition is not explicit" name: #A; ivs: 'a b c'; traits: { TEquality }. { #superclass -> Object. #name -> #sub. #instVars -> 'a b c' } asClass. { Object asSuperclass. #sub asClassName. 'a b c' asInstVars. 'c' asClassVar } asClass. "litteral approach" #( name A superclass Object instVars #(a b c) instVar d ) asClass #Luc

May 22, 2017

Re: [Pharo-dev] FileTree/Iceberg and SSDs, change the file format

by K K Subbu

On Sunday 21 May 2017 11:34 PM, Dale Henrichs wrote: > As part of his work on Cypress 2.0 Martin McClure is planning on > supporting a file per class disk format in addition to the file per > method format and possibly a file per package format. > > I'm not sure whether Martin is at the point where he is ready to share > his plans, but this is a problem that is being worked on and when Martin > is ready for feedback he'll publish his spec. Is it possible to build a file responder right into Pharo and expose packages through WebDAV or FUSE or sshfs service? Then the contents can go directly from RAM (pharo) to RAM (repo server or git) without going through slow disk filesystem. Regards .. Subbu

May 22, 2017

Re: [Pharo-dev] FileTree/Iceberg and SSDs, change the file format

by Ben Coman

On Sun, May 21, 2017 at 11:25 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > At the PharoDays I was painfully reminded that SSDs perform really badly > when using small files. The Bloc tutorial used a github filetree repo and > that has a lot of files. The whole folder is 116 MB in 16K files. Copying > that amount of data should not be noticable, taking about a third of a > second. With it being in so many files, it took more than half a minute, or > a hundred times as long. > > That is too much overhead. How can we improve the file format in a way > that keeps the cross-platform exchange advantages and a reasonable way to > view diffs and propose small changes using the github web tools? > > Cuis uses a different format with git. How does that compare? What is used > in Squeak? > > So this was copying files at the OS level? Which OS? For comparison, pulling whole of pharo-core across network and unpacking... $ time git clone --depth=1 https://github.com/pharo-project/pharo-core.git real 0m44.306s user 0m5.384s sys 0m5.908s Count and size of files $ find pharo-core/ | wc -l 152547 [files] $ du -sh pharo-core 639MB The smaller size of the archive without compression was a surprise. i.e. two-thirds empty space in filesystem blocks... $ time tar cf pharo-core.tar pharo-core/ real 0m8.216s user 0m2.284s sys 0m3.776s $ ls -lh pharo-core.tar 212MB File by file copy to a USB stick. Wow! Yes, thats over an hour. $ time cp -R pharo-core /media/ben/USBSTICK/pharo-core real 68m49.168s user 0m1.852s sys 0m39.768s Many forums indicated the following should be faster, but it was not... $ time ((tar cf - pharo-core) | (tar xf - -C /media/ben/USBSTICK/)) real 77m47.896s user 0m6.360s sys 0m38.900s Saving to an archive on USB stick is much quicker... $ time tar cf /media/ben/USBSTICK/pharo-core.tar pharo-core real 1m35.723s user 0m3.188s sys 0m5.972s Saving to a compressed archive on USB stick is muchmuch quicker... $ time tar zcf /media/ben/USBSTICK/pharo-core.tgz pharo-core real 0m11.778s user 0m7.908s sys 0m3.604s Saving to a compressed archive on USB stick, then unpacking that to local drive... $ time (tar zcf /media/ben/USBSTICK/pharo-core.tgz pharo-core \ && tar zxf /media/ben/USBSTICK/pharo-core.tgz -C restore/) real 0m49.934s user 0m10.552s sys 0m9.192s So 38 seconds to unpack, which is very similar to original git clone. But I guess your primary drive is SSD? So you don't get to bypass the issue using archvies? What result do you get cloning pharo-core like my first test case? cheers -ben

May 22, 2017

Re: [Pharo-dev] Chrome DevTools Protocol and Pharo

by Alistair Grant

Hi Torsten, On Fri, May 19, 2017 at 09:20:48PM +0000, Alistair Grant wrote: > > On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote: > > Hi Alistair, > > > > cant look right now but two things: > > > > - there are also events in the protocol - if we could hook Pharo into them > > this would solve the problem without abusing delay (because then you will > > get informed when the page loading is finished) > > That would be great. It will be a while before I get a chance to look > at this (I want to finish some proposed changes to the FileSystem > packages first), but I'll try and include it then. I've got basic event listening working. It requires that all messages are read asynchronously, so I'll need to change the interface to handle that. Knowing when a page has finished loading isn't quite as simple as looking for an event - a page can consist of multiple frames, and notifications are delivered for each frame. The page I'm interested in has around 25 frames. If anyone has a good design pattern for writing an asynchronous WebSocket client please let me know, I don't have anything concrete in mind. Thanks, Alistair

May 21, 2017

Re: [Pharo-dev] FileTree/Iceberg and SSDs, change the file format

by Thierry Goubier

Le 21/05/2017 Ã 17:25, Stephan Eggermont a Ã©crit : > At the PharoDays I was painfully reminded that SSDs perform really badly when using small files. The Bloc tutorial used a github filetree repo and that has a lot of files. The whole folder is 116 MB in 16K files. Copying that amount of data should not be noticable, taking about a third of a second. With it being in so many files, it took more than half a minute, or a hundred times as long. > > That is too much overhead. How can we improve the file format in a way that keeps the cross-platform exchange advantages and a reasonable way to view diffs and propose small changes using the github web tools? Write longer methods ;) As soon as you start packing together multiple methods in a file, then the diff context view of all the tools except the smalltalk ones become problematic because it does not respect anymore the "method" context around the changes, forcing you to mentally rebuild the context of the diff. I've done that when tracking down changes in git between two .st packages, and it really becomes a problem, like a method change + addition of a new method messes up completely the diff in terms of understanding what has really changed. And since the diff does not carry enough context for you to know in which method you are... > Cuis uses a different format with git. How does that compare? What is used in Squeak? Cuis: it is just the old .st package format. Cuis does not handle anything vcs related, you work in a git client. You can set dependencies between packages. I don't know for Squeak. Thierry > Stephan > >

May 21, 2017

Re: [Pharo-dev] FileTree/Iceberg and SSDs, change the file format

by Dale Henrichs

Cuis uses a standard chunk file format[1] with a file per package. Given the fact that no two Smalltalk dialects share a common class creation protocol makes simply using chunk file format a non-starter. Squeak uses FileTree. As part of his work on Cypress 2.0 Martin McClure is planning on supporting a file per class disk format in addition to the file per method format and possibly a file per package format. I'm not sure whether Martin is at the point where he is ready to share his plans, but this is a problem that is being worked on and when Martin is ready for feedback he'll publish his spec. Dale [1] https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/A… On 5/21/17 8:25 AM, Stephan Eggermont wrote: > At the PharoDays I was painfully reminded that SSDs perform really badly when using small files. The Bloc tutorial used a github filetree repo and that has a lot of files. The whole folder is 116 MB in 16K files. Copying that amount of data should not be noticable, taking about a third of a second. With it being in so many files, it took more than half a minute, or a hundred times as long. > > That is too much overhead. How can we improve the file format in a way that keeps the cross-platform exchange advantages and a reasonable way to view diffs and propose small changes using the github web tools? > > Cuis uses a different format with git. How does that compare? What is used in Squeak? > > Stephan >

May 21, 2017

Re: [Pharo-dev] Git, FileTree/Cypress, missing Traits comments

by Dale Henrichs

Looks like Thierry has a nifty solution for Traits in FileTree that doesn't involve methods ... Bob's already your uncle:) Dale On 5/21/17 10:36 AM, Dale Henrichs wrote: > I'm not familiar with Traits and how they have been integrated into > Monticello, but reading comments from the snapshot is pretty wild --- > but I I suppose it works:) > > For FileTree Traits should be added as first class objects ... I > assume that Traits are just regular classes and that the trickery > comes with associating a method in a class with a method from a Trait. > > In Filetree (Cypress 1.0), the first line of an st file is interpreted > as the method protocol and monkeying with the method protocol would be > possible but not transparently portable. The "most recent" Cypress > format (Cypress 1.5) switched from a single line to a 4 line > structured comment[1]. > > Martin McClure is currently working on Cypress2.0 and I believe that > he is proposing that methods also have an attribute dictionary (like > classes [2]), so for Cypress 2.0 Traits methods could be first class > objects ... > > Cypress 2.0 is still a work in process. Cypress 1.0 is widely used, > while Cypress 1.5 is not... > > Sooo, I would suggest that the Cypress 1.5 format could be modified to > accommodate Traits methods ... FileTree already supports 3 or 4 > different disk formats, so FileTree could be updated to support > Cypress 1.5 format and then Bob's your uncle ... > > Dale > > [1]https://github.com/CampSmalltalk/Cypress/wiki#method-file-format > > [2] https://github.com/CampSmalltalk/Cypress/wiki#class-properties > > On 5/20/17 8:12 PM, Ben Coman wrote: >> Is this of concern for Pharo...? "Pull requests on GitHub where the >> Trait comments get removed (because they were not loaded with the >> package in the first place)." >> >> http://forum.world.st/Re-The-Inbox-System-jr-919-mcz-td4941798.html#none >> >> http://forum.world.st/The-Inbox-System-jr-919-mcz-td4933985.html >> >> cheers -ben >> >

May 21, 2017

Re: [Pharo-dev] Git, FileTree/Cypress, missing Traits comments

by Dale Henrichs

I'm not familiar with Traits and how they have been integrated into Monticello, but reading comments from the snapshot is pretty wild --- but I I suppose it works:) For FileTree Traits should be added as first class objects ... I assume that Traits are just regular classes and that the trickery comes with associating a method in a class with a method from a Trait. In Filetree (Cypress 1.0), the first line of an st file is interpreted as the method protocol and monkeying with the method protocol would be possible but not transparently portable. The "most recent" Cypress format (Cypress 1.5) switched from a single line to a 4 line structured comment[1]. Martin McClure is currently working on Cypress2.0 and I believe that he is proposing that methods also have an attribute dictionary (like classes [2]), so for Cypress 2.0 Traits methods could be first class objects ... Cypress 2.0 is still a work in process. Cypress 1.0 is widely used, while Cypress 1.5 is not... Sooo, I would suggest that the Cypress 1.5 format could be modified to accommodate Traits methods ... FileTree already supports 3 or 4 different disk formats, so FileTree could be updated to support Cypress 1.5 format and then Bob's your uncle ... Dale [1]https://github.com/CampSmalltalk/Cypress/wiki#method-file-format [2] https://github.com/CampSmalltalk/Cypress/wiki#class-properties On 5/20/17 8:12 PM, Ben Coman wrote: > Is this of concern for Pharo...? "Pull requests on GitHub where the > Trait comments get removed (because they were not loaded with the > package in the first place)." > > http://forum.world.st/Re-The-Inbox-System-jr-919-mcz-td4941798.html#none > > http://forum.world.st/The-Inbox-System-jr-919-mcz-td4933985.html > > cheers -ben >

May 21, 2017

Re: [Pharo-dev] FileTree/Iceberg and SSDs, change the file format

by philippe.back＠highoctane.be

There is the same kind of issues with Hadoop but the block size is 128MB. So, lots of small files give the same issue. This is solved by having HAR files (Hadoop Archive) that contain the files. The haddop filesystem is usually able to access the har contents somewhat transparently from userland. But I guess that libgit will not be too cooperative. We can also look into how to mount such an archive as a filesystem. Phil Le 21 mai 2017 17:27, "Stephan Eggermont" <stephan(a)stack.nl> a Ã©crit : At the PharoDays I was painfully reminded that SSDs perform really badly when using small files. The Bloc tutorial used a github filetree repo and that has a lot of files. The whole folder is 116 MB in 16K files. Copying that amount of data should not be noticable, taking about a third of a second. With it being in so many files, it took more than half a minute, or a hundred times as long. That is too much overhead. How can we improve the file format in a way that keeps the cross-platform exchange advantages and a reasonable way to view diffs and propose small changes using the github web tools? Cuis uses a different format with git. How does that compare? What is used in Squeak? Stephan

May 21, 2017

60494 Red-pane-of-death when sources file missing

by Ben Coman

We must be getting close to Pharo 6 Release. Due to missing PharoV60.soruces file, image 60494 get a red-pane-of-death in class pane. Even though the release would bypass this by including the file, we should be more robust to the missing sources file. Hopefully this fix can make it last minute into the release... https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death-when-sources-file… cheers -ben

May 21, 2017