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

Re: [Pharo-dev] [ANN] New release of iceberg

by Aliaksei Syrel

Hi I use Iceberg to load project in non-interactive mode and this is what I get with latest stable: RETRY->BaselineOfIceberg An attempt to use interactive tools detected, while in non-interactive mode Is there any reason that prevents Iceberg to be used in non-interactive mode, from command line for example? Cheers, Alex On 15 October 2016 at 13:59, stepharo <stepharo(a)free.fr> wrote: > + 1 > > This is on my todo :) > > > Le 13/10/16 Ã 20:37, Tudor Girba a Ã©crit : > > Hi Nicolas, >> >> Great work! >> >> I will test it again. I kindly ask everyone else to follow the call and >> test this release. Ideally, create a repository on GitHub and play with it. >> >> It is important to get this piece as stable as possible to make Git part >> of the default Pharo experience. >> >> Cheers, >> Doru >> >> >> On Oct 13, 2016, at 2:25 PM, Nicolas Passerini <npasserini(a)gmail.com> >>> wrote: >>> >>> Hi, we are releasing a new version of Iceberg, with several new features >>> and bugfixes. I would't yet say that is 100% production ready, but it is >>> close, so I want to invite you to test it and provide feedback. >>> >>> You can install it by doing: >>> >>> Metacello new >>> baseline: 'Iceberg'; >>> repository: 'github://npasserini/iceberg'; >>> load. >>> >>> More installation instructions and documentation can be found at >>> https://github.com/npasserini/iceberg. >>> >>> Some of the new features in this version are: >>> - Allow to commit several packages together in the same commit. >>> - Show diffs for incoming and outgoing commits (i.e. before push/pull >>> you can browse the difference between the remote and the local versions). >>> - New History view allows to see any commit in any branch and compare it >>> to the current loaded version. >>> - Better support for interacting code loaded outside Iceberg >>> (smaltalkhub, filetree, gitfiletree, etc). >>> - From the diff view, revert changes or browse them (i.e. open a >>> Nautilus on the changed class/method). >>> - Automatically update presentations on code / repository changes. >>> - Integration with Metacello, i.e. after installing Iceberg you do >>> something like >>> >>> Metacello new >>> >>> baseline: 'TaskIt' >>> ; >>> repository: 'github://sbragagnolo/taskit' >>> ; >>> load. >>> >>> >>> (By default) it will be loaded using iceberg (there is a setting to >>> avoid it if you prefer traditional behavior. >>> >>> - Improved handling of git errors. >>> - Improved performance for several operations. >>> - Improved documentation. >>> - ... and several bug fixes and other minor improvements (please look at >>> https://github.com/npasserini/iceberg/milestone/7?closed=1 for more >>> details). >>> >>> >>> Please do not hesitate to contact me if you have any doubts. >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Reasonable is what we are accustomed with." >> >> >> >> > >

Oct. 16, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > AFAIU, Fuel is not capable working across versions, let alone over the > non-spur/spur divide. It's a let down, but it is by design (to optimise > for absolute speed). Lack of portability between Fuel versions is an annoyance, but is easy to overcome by updating Fuel on the source image to the same version as the target image before porting. But I don't see an obvious workaround for the non-spur -> spur breakdown. How can we leave users in a situation where it seems impossible to migrate data between Pharo versions?! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4918943.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 15, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Tudor Girba

Hi, > On Oct 15, 2016, at 6:21 PM, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Thu, Oct 13, 2016 at 4:12 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Stef, > > entitled: doesn't carries the right meaning. > > entitle > ÉªnËtÊÉªt(É)l,Én-/ > verb > past tense: entitled; past participle: entitled > > 1. > give (someone) a legal right or a just claim to receive or do something. > "employees are normally entitled to redundancy pay" > synonyms:qualify, make eligible, authorize, sanction, allow, permit, grant, grant/give the right,give permission; More > 2. > give (something) a particular title. > "a satire entitled âThe Rise of the Meritocracyâ" > > archaic > give (someone) a specified title expressing their rank, office, or character. > "they entitled him Sultan" > synonyms:title, name, call, give the title of, label, term, designate, dub; More > > Also, why act: as a shortcut? > action:icon:label: seems nicer to me. > I am not giving any rank to my menus for sure. > > I wonder what Ben would say about this. > > > I hesitated a while to consider this. I've come down on the side of thinking its fine, per point 2 above, you are giving it a title. Also, please consider that this selector is part of a fluent API: browser show: [ :composite | composite list display: â¦ ; act: â¦ entitled: â¦ ] Cheers, Doru > cheers -ben > > > > > On Wed, Oct 12, 2016 at 10:33 PM, stepharo <stepharo(a)free.fr> wrote: > > > > I'm adding > > > > act: aBlock iconName: aSymbol entitled: aString > > self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString > > > > and > > > > act: aBlock iconName: aSymbol on: aCharacter entitled: aString > > self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter entitled: aString > > > > and others .... > > > -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

Oct. 15, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Ben Coman

On Thu, Oct 13, 2016 at 4:12 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Stef, > > entitled: doesn't carries the right meaning. > > entitle > ÉªnËtÊÉªt(É)l,Én-/ > verb > past tense: entitled; past participle: entitled > > 1. > give (someone) a legal right or a just claim to receive or do something. > "employees are normally entitled to redundancy pay" > synonyms:qualify, make eligible, authorize, sanction, allow, permit, > grant, grant/give the right,give permission; More > 2. > give (something) a particular title. > "a satire entitled âThe Rise of the Meritocracyâ" > > archaic > give (someone) a specified title expressing their rank, office, or > character. > "they entitled him Sultan" > synonyms:title, name, call, give the title of, label, term, designate, > dub; More > > Also, why act: as a shortcut? > action:icon:label: seems nicer to me. > I am not giving any rank to my menus for sure. > > I wonder what Ben would say about this. > > I hesitated a while to consider this. I've come down on the side of thinking its fine, per point 2 above, you are giving it a title. cheers -ben > > > > On Wed, Oct 12, 2016 at 10:33 PM, stepharo <stepharo(a)free.fr> wrote: > > > > I'm adding > > > > act: aBlock iconName: aSymbol entitled: aString > > self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString > > > > and > > > > act: aBlock iconName: aSymbol on: aCharacter entitled: aString > > self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter > entitled: aString > > > > and others .... > > >

Oct. 15, 2016

Re: [Pharo-dev] [squeak-dev] Re: large images

by David T. Lewis

Ah, right - sorry for my misunderstanding. Certainly it would make sense to eliminate the GC if we are going to quit the image anyway. Processing the shutdown list and finalization queue probably makes sense as a matter of policy, even if in practice these actions are rarely needed. For cases in which, for example, database sessions are active, it might be very important to ensure clean shutdown when quitting the image. Dave On Fri, Oct 14, 2016 at 11:08:56PM -0500, John Brant wrote: > The time I was talking about was the time to quit the image without > saving. This time seems to be dependent on the size of the image. For > example, a 100MB image quits almost immediately, but a couple GB one > takes 5 or so seconds and my 7GB one was taking ~15 seconds. > > > John Brant > > > On 10/14/2016 05:34 PM, David T. Lewis wrote: > >Hi, > > > >Let's measure where the time is going before we fix it. I have saved V3 > >images > >of that size and more, and it takes a very long time to write the image > >file > >independent of any GC or finalization actions that need to happen. We > >should > >measure this on a large Spur image save, but I suspect that the dominant > >factor > >will turn out to be the time that it takes to flush all those gigabytes out > >to storage. Garbage collection and finalization actions might be just > >round-off > >error. > > > >Dave > > > > > >On Fri, Oct 14, 2016 at 08:29:13AM -0700, Eliot Miranda wrote: > >>Hi Both, > >> > >> let me try again :-/ > >> > >>>On Oct 8, 2016, at 10:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>> > >>>Nice! > >>> > >>>I put Eliot in CC :). > >>> > >>>@Eliot: John was playing with some large images and I asked him if he > >>>could save/load to see what happens. The report is below. Nice job :). > >>> > >>>Doru > >>> > >>> > >>>>On Oct 8, 2016, at 7:48 PM, John Brant <brant(a)refactoryworkers.com> > >>>>wrote: > >>>> > >>>>I loaded my model (6.8GiB on linux), saved the image (7.2GB), and > >>>>started the image. It all worked. It took a few minutes to load the > >>>>image, but it worked. It takes ~15 seconds to quit an image that large. > >>>>I'm not sure what quit is doing, but it appears to be dependent on the > >>>>image size. > >> > >>Regrettably the squeak vm does a full gc on snapshot, and then, > >>unavoidably, it does a scan of all contexts in the heap, changing any > >>with machine code pcs to have bytecode pcs so that the image can be > >>restarted on a different version/platform. It then writes the heap > >>segments to the file. > >> > >>I guess the scan could be folded into the gc. This is a long time to > >>wait! > >> > >>The gc makes sense only as a way of voiding new space; image loading is > >>simplified only having to load old space segments. It does /not/ make > >>sense semantically because and finalization actions it triggers cannot be > >>responded to until after the snapshot. > >> > >>Instead, it makes much more sense for the image to invoke a full gc > >>immediately prior to snapshot, and drain the finalization queue > >>(something I guess will happen implicitly due to finalization process > >>priority). This means that expected finalization activities such as > >>flushing and closing output files will actually take place. The existing > >>architecture effectively throws these actions away. > >> > >>Both squeak and pharo communities could do well to discuss this and agree > >>on an approach. > >> > >> > >>>> > >>>> > >>>>John Brant > >>> > >>>-- > >>>www.tudorgirba.com > >>>www.feenk.com > >>> > >>>"Every thing has its own flow." > >>> > >>> > >>> > >>> > >>> > >

Oct. 15, 2016

Re: [Pharo-dev] Path >> fullName should not be the same as printString

by stepharo

so how can we make progress? Stef Le 14/10/16 Ã 14:57, Damien Pollet a Ã©crit : > While we're at it, canonicalizing paths at creation time seems wrong > also: > > First because those two expressions do not return the same thing: > Path from: 'a/b/c/../d' > Path * / 'a' / 'b' / 'c' / '..' / 'd' > > Second because if c happens to be a symlink, then the operating system > will not find the same thing as Pharo. The semantics is that you > follow the symlink first, and follow .. in the directory you end up > in. So that goes to the parent of the actual directory pointed to by > the symlink, not back one level in the path. > > On 14 October 2016 at 13:59, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > All this already works (although maybe not perfectly in edge > cases). Consider: > > 'file:///C:/Users/tempfile.txt' asUrl. > > 'file:///C:/Users/tempfile.txt' asUrl asFileReference. > > FileLocator C / 'Users' / 'tmpfile.txt'. > > Where the last two are identical. > > Note that relative file URLs do not exist. > > > On 14 Oct 2016, at 13:28, Gabriel Cotelli <g.cotelli(a)gmail.com > <mailto:g.cotelli@gmail.com>> wrote: > > > > At least Chrome uses this: > > > > file:///C:/Users/tempfile.txt > > > > On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure > <martin(a)hand2mouse.com <mailto:martin@hand2mouse.com>> wrote: > > On 10/13/2016 10:35 AM, Damien Pollet wrote: > > Could you give an example what the file:// URLs look like when > they contain a drive letter? > > > > I'm afraid I don't have any Windows machines handy to see what > Internet Explorer does, but as far as I can tell an absolute URL > compliant with RFC 3986 might look something like > > > > file:/c:/foo/bar > > > > A relative URL that fits the URL syntax would be > > > > file:c:/foo/bar > > > > But I'm finding it difficult to tell precisely how RFCs 1738 and > 3986 currently interact. > > > > The discussion in this proposed RFC is somewhat interesting: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02 > <https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02>, > as it directly addresses Windows file naming. In appendix B.2, it says > > > > "When mapping a DOS- or Windows-like file path to a URI, use the > drive > > letter (e.g. "c:") as the first path segment. Some > implementations leave the leading slash off before the drive > letter. " > > > > and appendix C.1 deals with DOS file paths. > > > > > > I hope this is more helpful than it is confusing. > > > > Regards, > > > > -Martin > > > > > > > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 15, 2016

Re: [Pharo-dev] [ANN] New release of iceberg

by stepharo

+ 1 This is on my todo :) Le 13/10/16 Ã 20:37, Tudor Girba a Ã©crit : > Hi Nicolas, > > Great work! > > I will test it again. I kindly ask everyone else to follow the call and test this release. Ideally, create a repository on GitHub and play with it. > > It is important to get this piece as stable as possible to make Git part of the default Pharo experience. > > Cheers, > Doru > > >> On Oct 13, 2016, at 2:25 PM, Nicolas Passerini <npasserini(a)gmail.com> wrote: >> >> Hi, we are releasing a new version of Iceberg, with several new features and bugfixes. I would't yet say that is 100% production ready, but it is close, so I want to invite you to test it and provide feedback. >> >> You can install it by doing: >> >> Metacello new >> baseline: 'Iceberg'; >> repository: 'github://npasserini/iceberg'; >> load. >> >> More installation instructions and documentation can be found at https://github.com/npasserini/iceberg. >> >> Some of the new features in this version are: >> - Allow to commit several packages together in the same commit. >> - Show diffs for incoming and outgoing commits (i.e. before push/pull you can browse the difference between the remote and the local versions). >> - New History view allows to see any commit in any branch and compare it to the current loaded version. >> - Better support for interacting code loaded outside Iceberg (smaltalkhub, filetree, gitfiletree, etc). >> - From the diff view, revert changes or browse them (i.e. open a Nautilus on the changed class/method). >> - Automatically update presentations on code / repository changes. >> - Integration with Metacello, i.e. after installing Iceberg you do something like >> >> Metacello new >> >> >> baseline: 'TaskIt' >> ; >> >> repository: 'github://sbragagnolo/taskit' >> ; >> load. >> >> >> (By default) it will be loaded using iceberg (there is a setting to avoid it if you prefer traditional behavior. >> >> - Improved handling of git errors. >> - Improved performance for several operations. >> - Improved documentation. >> - ... and several bug fixes and other minor improvements (please look at https://github.com/npasserini/iceberg/milestone/7?closed=1 for more details). >> >> >> Please do not hesitate to contact me if you have any doubts. > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > >

Oct. 15, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sven Van Caekenberghe

AFAIU, Fuel is not capable working across versions, let alone over the non-spur/spur divide. It's a let down, but it is by design (to optimise for absolute speed). > On 15 Oct 2016, at 05:46, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Eliot Miranda-2 wrote >> Is that character code legal unicode? > > No, but that turned out to be a red herring! > > This simple experiment seems to show a fundamental problem when serializing > in 4.0 (non-spur) and materializing in 5.0 (spur): > > FileStream forceNewFileNamed: filename do: [:aFile | > FLSerializer newDefault > serialize: ($e) on: aFile binary ] . > > FLMaterializer materializeFromFileNamed: filename. > > Doing the serialization and materialization in the same 4.0 image works, but > materializing in a 5.0 image throws an error (a different one this time - > "MessageNotUnderstood: receiver of ""adaptToNumber:andSend:"" is nil") > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4918909.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 15, 2016

Re: [Pharo-dev] [squeak-dev] Re: large images

by John Brant

The time I was talking about was the time to quit the image without saving. This time seems to be dependent on the size of the image. For example, a 100MB image quits almost immediately, but a couple GB one takes 5 or so seconds and my 7GB one was taking ~15 seconds. John Brant On 10/14/2016 05:34 PM, David T. Lewis wrote: > Hi, > > Let's measure where the time is going before we fix it. I have saved V3 images > of that size and more, and it takes a very long time to write the image file > independent of any GC or finalization actions that need to happen. We should > measure this on a large Spur image save, but I suspect that the dominant factor > will turn out to be the time that it takes to flush all those gigabytes out > to storage. Garbage collection and finalization actions might be just round-off > error. > > Dave > > > On Fri, Oct 14, 2016 at 08:29:13AM -0700, Eliot Miranda wrote: >> Hi Both, >> >> let me try again :-/ >> >>> On Oct 8, 2016, at 10:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Nice! >>> >>> I put Eliot in CC :). >>> >>> @Eliot: John was playing with some large images and I asked him if he could save/load to see what happens. The report is below. Nice job :). >>> >>> Doru >>> >>> >>>> On Oct 8, 2016, at 7:48 PM, John Brant <brant(a)refactoryworkers.com> wrote: >>>> >>>> I loaded my model (6.8GiB on linux), saved the image (7.2GB), and started the image. It all worked. It took a few minutes to load the image, but it worked. It takes ~15 seconds to quit an image that large. I'm not sure what quit is doing, but it appears to be dependent on the image size. >> >> Regrettably the squeak vm does a full gc on snapshot, and then, unavoidably, it does a scan of all contexts in the heap, changing any with machine code pcs to have bytecode pcs so that the image can be restarted on a different version/platform. It then writes the heap segments to the file. >> >> I guess the scan could be folded into the gc. This is a long time to wait! >> >> The gc makes sense only as a way of voiding new space; image loading is simplified only having to load old space segments. It does /not/ make sense semantically because and finalization actions it triggers cannot be responded to until after the snapshot. >> >> Instead, it makes much more sense for the image to invoke a full gc immediately prior to snapshot, and drain the finalization queue (something I guess will happen implicitly due to finalization process priority). This means that expected finalization activities such as flushing and closing output files will actually take place. The existing architecture effectively throws these actions away. >> >> Both squeak and pharo communities could do well to discuss this and agree on an approach. >> >> >>>> >>>> >>>> John Brant >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> >

Oct. 15, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sean P. DeNigris

Eliot Miranda-2 wrote > Is that character code legal unicode? No, but that turned out to be a red herring! This simple experiment seems to show a fundamental problem when serializing in 4.0 (non-spur) and materializing in 5.0 (spur): FileStream forceNewFileNamed: filename do: [:aFile | FLSerializer newDefault serialize: ($e) on: aFile binary ] . FLMaterializer materializeFromFileNamed: filename. Doing the serialization and materialization in the same 4.0 image works, but materializing in a 5.0 image throws an error (a different one this time - "MessageNotUnderstood: receiver of ""adaptToNumber:andSend:"" is nil") ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4918909.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 15, 2016