- Pharo-dev - lists.pharo.org

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

by phil＠highoctane.be

I am in the other boat for reading OrderPreservingDictionary. Phil On Mon, Oct 17, 2016 at 3:43 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sven Van Caekenberghe-2 wrote > > Of course it does, it wouldn't be very good if it didn't ;-) > > Great! > > I fell down on "STONWriterError: custom #stonOn: implementation needed for > variable/indexable class" for AbsolutePath. Is there an example of how to > handle this? I read the paper and googled, but didn't see one... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM- > Bug-for-Chinese-Characters-tp4918883p4919031.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 17, 2016

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

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Of course it does, it wouldn't be very good if it didn't ;-) Great! I fell down on "STONWriterError: custom #stonOn: implementation needed for variable/indexable class" for AbsolutePath. Is there an example of how to handle this? I read the paper and googled, but didn't see one... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919031.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2016

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

by Sven Van Caekenberghe

> On 16 Oct 2016, at 23:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > NorbertHartl wrote >> These changes are rare > > Thankfully :) > > > NorbertHartl wrote >> you are better off using STON > > But I thought STON does not preserve references. That wouldn't work for all > but the simplest models, no? Of course it does, it wouldn't be very good if it didn't ;-) See #testReferenceSharing and #testReferenceCycle for example > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919011.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 17, 2016

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

by Norbert Hartl

Sean, fuel relies on the fact that the environment for materialization is the same as where it has been serialized. So classes and methods need to be mostly the same. A non-spur to spur change is likely to make it fail. These changes are rare but sonetimes the need to be done. If you want to move data between different environments you are better off using STON. Norbert > Am 15.10.2016 um 23:28 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > 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. 16, 2016

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

by Sean P. DeNigris

NorbertHartl wrote > These changes are rare Thankfully :) NorbertHartl wrote > you are better off using STON But I thought STON does not preserve references. That wouldn't work for all but the simplest models, no? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919011.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 16, 2016

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