July 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Bug in Date>>readFrom:pattern: ? Pharo2.0

by Sabine KnÃ¶fel

Hi, I created a bug, hoping that I filled out every field correctly. https://pharo.fogbugz.com/f/cases/11222/Date-readFrom-pattern-year-2-decima… Sabine On Wed, Jul 24, 2013 at 9:52 AM, StÃ©phane Ducasse [via Smalltalk] <ml-node+s1294792n4700428h63(a)n4.nabble.com> wrote: > Hello Sabine > probably a bug. > If you can write some tests and publish them on the bugtracker this will > help. > If you provide the fix (it will be faster to get it fixed) please run the > tests to make sure that we do not > introduce side effects. > > Stef > >> Hi, >> >> Date readFrom: '4.2.13' readStream pattern: 'd.m.yy' >> >> Does not return 4.2.2013 but 4.2.0013 >> >> The comment is saying >> "A year given using only two decimals is considered to be >2000" >> >> So, the comment is not ok or this is a bug? >> >> Sabine >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Bug-in-Date-readFrom-pattern-Pharo2-0-tp4700427.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > > > > > ________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Bug-in-Date-readFrom-pattern-Pharo2-0-tp4700427p47004… > To unsubscribe from Bug in Date>>readFrom:pattern: ? Pharo2.0, click here. > NAML -- View this message in context: http://forum.world.st/Bug-in-Date-readFrom-pattern-Pharo2-0-tp4700427p47004… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 24, 2013

Re: [Pharo-users] [Moose-dev] Re: [Pharo-dev] Re: [ann] snapshotcello

by StÃ©phane Ducasse

On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > On Jul 24, 2013, at 8:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >>> Stef, >>> >>> I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). >>> >>> However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. >> Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the >> existing configuration trees but this requires some work. > > I do not understand this point. What do you mean by "interpreting the configuration trees"? I mean going over the configurations with dependencies to recreate the tree structure but with versions. May be this is not needed because for versions we do not need dependencies so just group them per configurations. > > Doru > >>> >>> With that said it _is_ performing a useful function ... >>> >>> I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... >>> >>> Dale >>> >>> [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html >>> ----- Original Message ----- >>> | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> >>> | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" >>> | <pharo-dev(a)lists.pharo.org> >>> | Sent: Tuesday, July 23, 2013 2:17:50 PM >>> | Subject: [Moose-dev] Re: [ann] snapshotcello >>> | >>> | Nice to see SnapshotCello coming to live. May be it should be >>> | integrated to Metacello. >>> | Because everybody may need this cool feature. >>> | >>> | Stef >>> | >>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> >>> | wrote: >>> | >>> | > Hi, >>> | > >>> | > Stef and I developed Snapshotcello, a little utility that enables >>> | > you to freeze a snapshot of a given configuration based on what is >>> | > already loaded in your current image. >>> | > >>> | > The idea is simple. You develop against the latest versions of all >>> | > packages, and commit your changes for each package. When you are >>> | > ready for a release, you assemble your image, and generate a >>> | > snapshot version that can be reloaded later. >>> | > >>> | > Here is an example of how it can work to take a snapshot of a >>> | > development version: >>> | > Snapshotcello new >>> | > configurationClass: ConfigurationOfMoose; >>> | > configurationVersion: #development; >>> | > publishVersion: '4.8-snapshot' >>> | > >>> | > You can find more details here: >>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… >>> | > >>> | > You can get the code at: >>> | > Gofer new >>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; >>> | > package: 'ConfigurationOfSnapshotcello'; >>> | > load. >>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) >>> | > loadDevelopment >>> | > >>> | > Cheers, >>> | > Doru >>> | > >>> | > -- >>> | > www.tudorgirba.com >>> | > >>> | > "Every successful trip needs a suitable vehicle." >>> | > >>> | > >>> | > >>> | > >>> | > >>> | > _______________________________________________ >>> | > Moose-dev mailing list >>> | > Moose-dev(a)iam.unibe.ch >>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> | >>> | >>> | _______________________________________________ >>> | Moose-dev mailing list >>> | Moose-dev(a)iam.unibe.ch >>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> | >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > >

July 24, 2013

Re: [Pharo-users] Bug in Date>>readFrom:pattern: ? Pharo2.0

by StÃ©phane Ducasse

Hello Sabine probably a bug. If you can write some tests and publish them on the bugtracker this will help. If you provide the fix (it will be faster to get it fixed) please run the tests to make sure that we do not introduce side effects. Stef > Hi, > > Date readFrom: '4.2.13' readStream pattern: 'd.m.yy' > > Does not return 4.2.2013 but 4.2.0013 > > The comment is saying > "A year given using only two decimals is considered to be >2000" > > So, the comment is not ok or this is a bug? > > Sabine > > > > -- > View this message in context: http://forum.world.st/Bug-in-Date-readFrom-pattern-Pharo2-0-tp4700427.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 24, 2013

Bug in Date>>readFrom:pattern: ? Pharo2.0

by Sabine KnÃ¶fel

Hi, Date readFrom: '4.2.13' readStream pattern: 'd.m.yy' Does not return 4.2.2013 but 4.2.0013 The comment is saying "A year given using only two decimals is considered to be >2000" So, the comment is not ok or this is a bug? Sabine -- View this message in context: http://forum.world.st/Bug-in-Date-readFrom-pattern-Pharo2-0-tp4700427.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 24, 2013

Re: [Pharo-users] [Moose-dev] Re: [Pharo-dev] Re: [ann] snapshotcello

by Tudor Girba

Hi, On Jul 24, 2013, at 8:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > >> Stef, >> >> I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). >> >> However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. > Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the > existing configuration trees but this requires some work. I do not understand this point. What do you mean by "interpreting the configuration trees"? Doru >> >> With that said it _is_ performing a useful function ... >> >> I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... >> >> Dale >> >> [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html >> ----- Original Message ----- >> | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> >> | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" >> | <pharo-dev(a)lists.pharo.org> >> | Sent: Tuesday, July 23, 2013 2:17:50 PM >> | Subject: [Moose-dev] Re: [ann] snapshotcello >> | >> | Nice to see SnapshotCello coming to live. May be it should be >> | integrated to Metacello. >> | Because everybody may need this cool feature. >> | >> | Stef >> | >> | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> >> | wrote: >> | >> | > Hi, >> | > >> | > Stef and I developed Snapshotcello, a little utility that enables >> | > you to freeze a snapshot of a given configuration based on what is >> | > already loaded in your current image. >> | > >> | > The idea is simple. You develop against the latest versions of all >> | > packages, and commit your changes for each package. When you are >> | > ready for a release, you assemble your image, and generate a >> | > snapshot version that can be reloaded later. >> | > >> | > Here is an example of how it can work to take a snapshot of a >> | > development version: >> | > Snapshotcello new >> | > configurationClass: ConfigurationOfMoose; >> | > configurationVersion: #development; >> | > publishVersion: '4.8-snapshot' >> | > >> | > You can find more details here: >> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… >> | > >> | > You can get the code at: >> | > Gofer new >> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; >> | > package: 'ConfigurationOfSnapshotcello'; >> | > load. >> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) >> | > loadDevelopment >> | > >> | > Cheers, >> | > Doru >> | > >> | > -- >> | > www.tudorgirba.com >> | > >> | > "Every successful trip needs a suitable vehicle." >> | > >> | > >> | > >> | > >> | > >> | > _______________________________________________ >> | > Moose-dev mailing list >> | > Moose-dev(a)iam.unibe.ch >> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> | >> | >> | _______________________________________________ >> | Moose-dev mailing list >> | Moose-dev(a)iam.unibe.ch >> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> | >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

July 24, 2013

Re: [Pharo-users] [Moose-dev] Re: [ann] snapshotcello

by Tudor Girba

Hi, On Jul 23, 2013, at 11:51 PM, "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> wrote: > Stef, > > I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). What is not clear? I would be interested in describing our scenario in more details because I think this is a development pattern. But, I need some concrete questions to start from. > However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. I still do not understand why Versionner would be affected by the current versions given that we are only generating versions that should be immutable hence no need for management. > With that said it _is_ performing a useful function ... > > I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... Having a different way to store the information should be no problem. I am curious about your ideas. Cheers, Doru > Dale > > [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> > | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" > | <pharo-dev(a)lists.pharo.org> > | Sent: Tuesday, July 23, 2013 2:17:50 PM > | Subject: [Moose-dev] Re: [ann] snapshotcello > | > | Nice to see SnapshotCello coming to live. May be it should be > | integrated to Metacello. > | Because everybody may need this cool feature. > | > | Stef > | > | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> > | wrote: > | > | > Hi, > | > > | > Stef and I developed Snapshotcello, a little utility that enables > | > you to freeze a snapshot of a given configuration based on what is > | > already loaded in your current image. > | > > | > The idea is simple. You develop against the latest versions of all > | > packages, and commit your changes for each package. When you are > | > ready for a release, you assemble your image, and generate a > | > snapshot version that can be reloaded later. > | > > | > Here is an example of how it can work to take a snapshot of a > | > development version: > | > Snapshotcello new > | > configurationClass: ConfigurationOfMoose; > | > configurationVersion: #development; > | > publishVersion: '4.8-snapshot' > | > > | > You can find more details here: > | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… > | > > | > You can get the code at: > | > Gofer new > | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; > | > package: 'ConfigurationOfSnapshotcello'; > | > load. > | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) > | > loadDevelopment > | > > | > Cheers, > | > Doru > | > > | > -- > | > www.tudorgirba.com > | > > | > "Every successful trip needs a suitable vehicle." > | > > | > > | > > | > > | > > | > _______________________________________________ > | > Moose-dev mailing list > | > Moose-dev(a)iam.unibe.ch > | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | > | > | _______________________________________________ > | Moose-dev mailing list > | Moose-dev(a)iam.unibe.ch > | https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | > -- www.tudorgirba.com "Live like you mean it."

July 24, 2013

Re: [Pharo-users] [Pharo-dev] [Moose-dev] Re: [ann] snapshotcello

by StÃ©phane Ducasse

On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Stef, > > I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). > > However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work. > > With that said it _is_ performing a useful function ... > > I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... > > Dale > > [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> > | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" > | <pharo-dev(a)lists.pharo.org> > | Sent: Tuesday, July 23, 2013 2:17:50 PM > | Subject: [Moose-dev] Re: [ann] snapshotcello > | > | Nice to see SnapshotCello coming to live. May be it should be > | integrated to Metacello. > | Because everybody may need this cool feature. > | > | Stef > | > | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> > | wrote: > | > | > Hi, > | > > | > Stef and I developed Snapshotcello, a little utility that enables > | > you to freeze a snapshot of a given configuration based on what is > | > already loaded in your current image. > | > > | > The idea is simple. You develop against the latest versions of all > | > packages, and commit your changes for each package. When you are > | > ready for a release, you assemble your image, and generate a > | > snapshot version that can be reloaded later. > | > > | > Here is an example of how it can work to take a snapshot of a > | > development version: > | > Snapshotcello new > | > configurationClass: ConfigurationOfMoose; > | > configurationVersion: #development; > | > publishVersion: '4.8-snapshot' > | > > | > You can find more details here: > | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… > | > > | > You can get the code at: > | > Gofer new > | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; > | > package: 'ConfigurationOfSnapshotcello'; > | > load. > | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) > | > loadDevelopment > | > > | > Cheers, > | > Doru > | > > | > -- > | > www.tudorgirba.com > | > > | > "Every successful trip needs a suitable vehicle." > | > > | > > | > > | > > | > > | > _______________________________________________ > | > Moose-dev mailing list > | > Moose-dev(a)iam.unibe.ch > | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | > | > | _______________________________________________ > | Moose-dev mailing list > | Moose-dev(a)iam.unibe.ch > | https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | >

July 24, 2013

Re: [Pharo-users] [Moose-dev] Re: [ann] snapshotcello

by Dale K. Henrichs

Stef, I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. With that said it _is_ performing a useful function ... I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... Dale [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" | <pharo-dev(a)lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev(a)iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev(a)iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |

July 23, 2013

Re: [Pharo-users] [Moose-dev] [ann] snapshotcello

by StÃ©phane Ducasse

Nice to see SnapshotCello coming to live. May be it should be integrated to Metacello. Because everybody may need this cool feature. Stef On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image. > > The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later. > > Here is an example of how it can work to take a snapshot of a development version: > Snapshotcello new > configurationClass: ConfigurationOfMoose; > configurationVersion: #development; > publishVersion: '4.8-snapshot' > > You can find more details here: > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… > > You can get the code at: > Gofer new > smalltalkhubUser: 'girba' project: 'Snapshotcello'; > package: 'ConfigurationOfSnapshotcello'; > load. > (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every successful trip needs a suitable vehicle." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

July 23, 2013

[ann] snapshotcello

by Tudor Girba

Hi, Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image. The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later. Here is an example of how it can work to take a snapshot of a development version: Snapshotcello new configurationClass: ConfigurationOfMoose; configurationVersion: #development; publishVersion: '4.8-snapshot' You can find more details here: http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment Cheers, Doru -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

July 23, 2013

Re: [Pharo-users] Change the Package-Chooser-Dialog when using "Move to package..."?

by Benjamin

+ 1 000 000 Ben On Jul 23, 2013, at 5:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > + 1 > > ;) > > Stef > > On Jul 23, 2013, at 3:02 PM, MartinW <wm(a)fastmail.fm> wrote: > >> Hi, >> i always find the Package-Chooser-Dialog (See Screenshot) when using "Move >> to package..." (e.g. from Nautilus) very strange to use. >> Why not replacing it with "SearchFacade rPackageSearch" (See second >> Screenshot)? >> >> I tried by changing AbstractTool >> moveInNewPackage: >> >> from: >> moveInNewPackage: aCollection >> >> | labels reject lines oldIndex newName item aPackage | >> aCollection ifEmpty: [^ nil ]. >> aPackage := aCollection first package. >> labels := self model packages collect: [:each | each name]. >> lines := {0}. >> >> newName := UIManager default chooseOrRequestFrom: labels lines: lines >> title: ('Change Package (current: ', aPackage name,')'). >> newName ifNil: [ ^ nil ]. >> newName := newName asSymbol. >> >> item := self browsedEnvironment packageOrganizer packageNamed: newName. >> aCollection do: [:aClass | >> aPackage removeClass: aClass. >> item addClassDefinition: aClass. >> aClass category: item name ]. >> ^ item >> >> to: >> moveInNewPackage: aCollection >> >> | originalPackage newPackage | >> aCollection ifEmpty: [^ nil ]. >> originalPackage := aCollection first package. >> >> newPackage := SearchFacade rPackageSearch chooseFromOwner: self window. >> newPackage ifNil: [ ^ nil ]. >> >> aCollection do: [:aClass | >> originalPackage removeClass: aClass. >> newPackage addClassDefinition: aClass. >> aClass category: newPackage name ]. >> ^ newPackage >> >> <http://forum.world.st/file/n4700280/Old_Change_Package_Dialog.png> >> <http://forum.world.st/file/n4700280/Package_search.png> >> >> >> >> -- >> View this message in context: http://forum.world.st/Change-the-Package-Chooser-Dialog-when-using-Move-to-… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > >

July 23, 2013

Re: [Pharo-users] Pharo 2.0 and Android

by hilaire

You should ask Dimitry Golubovsky because he's the man who knows about VM on Androd. Hliaire -- View this message in context: http://forum.world.st/Pharo-2-0-and-Android-tp4698239p4700323.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Norbert Hartl

Max, Am 23.07.2013 um 17:27 schrieb Max Leske <maxleske(a)gmail.com>: > > On 23.07.2013, at 15:32, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> >> >> On Tue, Jul 23, 2013 at 9:48 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Mariano, >> >> Am 23.07.2013 um 14:43 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> Norbert, does the model have lots of strings? Because if so you can try using the compression. It may increase speed. There is always a trade off between the additional time of compressing/uncompressing. But if the model has quite an amount of strings, since writing to disk is also slow and the final stream would be smaller, it could be faster. >>> >> thanks. Yes, the model is a lot of Dictionaries having string keys. And there are lots more. The usage of the model is write once read many. And 30ms is good enough for me. So I might try compression only to see the difference. Well, and maybe to reduce storage size. The mcz is now 261 kb. >> >> Thanks, I'll see but I am already satisfied with the current approach. >> >> >> Mmmm I thought it was ready, sorry my bad. Seems it was not ready nor integrated: https://code.google.com/p/fuel/issues/detail?id=160 >> But I might be wrong. >> Max? > > No, that issue is still open. You're welcome to use the experimental version though (Fuel-MaxLeske.757.mcz in http://www.squeaksource.com/FuelExperiments) but keep in mind that this is a few months behind stable. > I'm not sure the priority is high enough to try. > The other idea however, that Mariano describes in the linked issue, is available but probably not desirable: simply pass a compressing stream to Fuel (see FLGZippedBasicSerializationTest for an example on how to do that). That will compress *all* data, not only strings (which is the idea outlined in the linked issue). > I don't think that will gain anything. A monticello package is written as zip. So I wouldn't expect much from an additional compression. thanks, Norbert > Cheers, > Max > > (Note: I don't read the users list so please put me on the CC explicitly if you want me to read on) > >> >> Cheers, >> >> >> Norbert >> >>> Cheers, >>> >>> >>> On Tue, Jul 23, 2013 at 9:40 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Am 23.07.2013 um 14:23 schrieb "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de>: >>> >>> > Norbert, >>> > >>> > Am 23.07.13 14:07, schrieb Norbert Hartl: >>> >> Joachim, >>> >> >>> >> I'm aware that you can do serialization/deserialization yourself. I was asking for something to help along the way because a have quite some model classes to cover. I want a more generalized way of doing it. As often I really think about things _after_ I've sent the mail :) >>> > >>> > We seem to have a lot in common here. Regard it this way: sending the mail made you think again. So the mail itself was all but useless. >>> >> I think I have to options: >>> >> >>> >> 1. The most generic one is serializing into Fuel and compile the ByteArray in a method. >>> >> 2. The most readable one will be using STON and compiling the STON string into a method >>> >> >>> >> Maybe I should try both. >>> > I'd be very interested in what you find. I guess Fuel is smaller and maybe even faster. STON, OTOH, is much friendlier for comparing versions and such. >>> > >>> Well, I can't look at the method but I don't find ByteArrays not that interesting anyway. So the actual size of the serialized byte array is >>> >>> (ByteArray streamContents: [:stream| >>> FLSerializer serialize: TCAP current model on: stream ]) size >>> >>> is 237445 Bytes. Serializing >>> >>> [ MAPExampleModels class compile: 'tcap >>> ^ ', (ByteArray streamContents: [:stream| >>> FLSerializer serialize: TCAP current model on: stream ]) storeString ] timeToRun >>> >>> took 647 ms >>> >>> but >>> >>> [FLMaterializer materializeFromByteArray: MAPExampleModels tcap] timeToRun >>> >>> took only 30ms. Basically I'm not fond of putting too much binary stuff into compiled methods but it is the most easy and reliable way of providing tests with test data. The whole grammar is stored in methods as well. It is text butâ¦. >>> >>> I think I stay with it for a while. >>> >>> Norbert >>> >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >

July 23, 2013

Re: [Pharo-users] Change the Package-Chooser-Dialog when using "Move to package..."?

by StÃ©phane Ducasse

+ 1 ;) Stef On Jul 23, 2013, at 3:02 PM, MartinW <wm(a)fastmail.fm> wrote: > Hi, > i always find the Package-Chooser-Dialog (See Screenshot) when using "Move > to package..." (e.g. from Nautilus) very strange to use. > Why not replacing it with "SearchFacade rPackageSearch" (See second > Screenshot)? > > I tried by changing AbstractTool >> moveInNewPackage: > > from: > moveInNewPackage: aCollection > > | labels reject lines oldIndex newName item aPackage | > aCollection ifEmpty: [^ nil ]. > aPackage := aCollection first package. > labels := self model packages collect: [:each | each name]. > lines := {0}. > > newName := UIManager default chooseOrRequestFrom: labels lines: lines > title: ('Change Package (current: ', aPackage name,')'). > newName ifNil: [ ^ nil ]. > newName := newName asSymbol. > > item := self browsedEnvironment packageOrganizer packageNamed: newName. > aCollection do: [:aClass | > aPackage removeClass: aClass. > item addClassDefinition: aClass. > aClass category: item name ]. > ^ item > > to: > moveInNewPackage: aCollection > > | originalPackage newPackage | > aCollection ifEmpty: [^ nil ]. > originalPackage := aCollection first package. > > newPackage := SearchFacade rPackageSearch chooseFromOwner: self window. > newPackage ifNil: [ ^ nil ]. > > aCollection do: [:aClass | > originalPackage removeClass: aClass. > newPackage addClassDefinition: aClass. > aClass category: newPackage name ]. > ^ newPackage > > <http://forum.world.st/file/n4700280/Old_Change_Package_Dialog.png> > <http://forum.world.st/file/n4700280/Package_search.png> > > > > -- > View this message in context: http://forum.world.st/Change-the-Package-Chooser-Dialog-when-using-Move-to-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 23, 2013

Re: [Pharo-users] [rmod] Post on how to install pharo

by StÃ©phane Ducasse

sure! You can have a look at the github repos and the readme. https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/120/artifa… I just finished it :) On Jul 23, 2013, at 2:53 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Next week you can show me gutenberg so next time I do it myself :P > > > On Tue, Jul 23, 2013 at 2:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ok will port your blog to gutenberg and we can compare and you let me know if the html is ok > after I can generate the stuff for the code. > > stef > > >> So far, the HTML tags supported are these: >> >> http://en.support.wordpress.com/code/#html-tags >> >> and the code should be exported as this: >> >> http://en.support.wordpress.com/code/posting-source-code/ >> >> For syntax coloring I'm using ruby, just like >> >> [code language="ruby"] >> self bla: 1 + super ble. >> [/code] >> >> >> >> On Tue, Jul 23, 2013 at 12:33 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> >> >> On Tue, Jul 23, 2013 at 12:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Guilermo >> >> I would like to turn your blog entry into Gutenberg. I will do it while reading it as a kata exercise. >> >> Nice! >> >> Now I'm thinking that I could write a outputer for Gutenberg to produce the blog contents. >> What is the format used to edit your blog? >> >> I'm writing in wordpress :/... It allows to write a post using a WYSIWYG and to write it in a kind of HTML. However, for embedding images and writing code it uses tags between brackets. I cannot find a cool description on what is exactly the format :(. >> >> Because like that we could change edit gutenberg file and get: >> latex >> html >> blog >> >> Nick Ager didn't show that pier can import wordpress? maybe he can tell better :) >> >> >> Stef >> >> On Jul 23, 2013, at 11:03 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >>> Hi guys, >>> >>> I've written a small post on the current mechanisms for download and deploy pharo images and vms. Of course it may not be complete, just wanted to make noise :). So, feedback and retweets are welcome ;). >>> >>> http://playingwithobjects.wordpress.com/2013/07/23/installing-pharo-in-many… >>> >>> Guille >> >> >> > >

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Max Leske

On 23.07.2013, at 15:32, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Tue, Jul 23, 2013 at 9:48 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Mariano, > > Am 23.07.2013 um 14:43 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Norbert, does the model have lots of strings? Because if so you can try using the compression. It may increase speed. There is always a trade off between the additional time of compressing/uncompressing. But if the model has quite an amount of strings, since writing to disk is also slow and the final stream would be smaller, it could be faster. >> > thanks. Yes, the model is a lot of Dictionaries having string keys. And there are lots more. The usage of the model is write once read many. And 30ms is good enough for me. So I might try compression only to see the difference. Well, and maybe to reduce storage size. The mcz is now 261 kb. > > Thanks, I'll see but I am already satisfied with the current approach. > > > Mmmm I thought it was ready, sorry my bad. Seems it was not ready nor integrated: https://code.google.com/p/fuel/issues/detail?id=160 > But I might be wrong. > Max? No, that issue is still open. You're welcome to use the experimental version though (Fuel-MaxLeske.757.mcz in http://www.squeaksource.com/FuelExperiments) but keep in mind that this is a few months behind stable. The other idea however, that Mariano describes in the linked issue, is available but probably not desirable: simply pass a compressing stream to Fuel (see FLGZippedBasicSerializationTest for an example on how to do that). That will compress *all* data, not only strings (which is the idea outlined in the linked issue). Cheers, Max (Note: I don't read the users list so please put me on the CC explicitly if you want me to read on) > > Cheers, > > > Norbert > >> Cheers, >> >> >> On Tue, Jul 23, 2013 at 9:40 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 23.07.2013 um 14:23 schrieb "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de>: >> >> > Norbert, >> > >> > Am 23.07.13 14:07, schrieb Norbert Hartl: >> >> Joachim, >> >> >> >> I'm aware that you can do serialization/deserialization yourself. I was asking for something to help along the way because a have quite some model classes to cover. I want a more generalized way of doing it. As often I really think about things _after_ I've sent the mail :) >> > >> > We seem to have a lot in common here. Regard it this way: sending the mail made you think again. So the mail itself was all but useless. >> >> I think I have to options: >> >> >> >> 1. The most generic one is serializing into Fuel and compile the ByteArray in a method. >> >> 2. The most readable one will be using STON and compiling the STON string into a method >> >> >> >> Maybe I should try both. >> > I'd be very interested in what you find. I guess Fuel is smaller and maybe even faster. STON, OTOH, is much friendlier for comparing versions and such. >> > >> Well, I can't look at the method but I don't find ByteArrays not that interesting anyway. So the actual size of the serialized byte array is >> >> (ByteArray streamContents: [:stream| >> FLSerializer serialize: TCAP current model on: stream ]) size >> >> is 237445 Bytes. Serializing >> >> [ MAPExampleModels class compile: 'tcap >> ^ ', (ByteArray streamContents: [:stream| >> FLSerializer serialize: TCAP current model on: stream ]) storeString ] timeToRun >> >> took 647 ms >> >> but >> >> [FLMaterializer materializeFromByteArray: MAPExampleModels tcap] timeToRun >> >> took only 30ms. Basically I'm not fond of putting too much binary stuff into compiled methods but it is the most easy and reliable way of providing tests with test data. The whole grammar is stored in methods as well. It is text butâ¦. >> >> I think I stay with it for a while. >> >> Norbert >> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Norbert Hartl

HernÃ¡n, Am 23.07.2013 um 16:13 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > El 23/07/2013 9:01, Norbert Hartl escribiÃ³: >> >> Am 23.07.2013 um 13:20 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> >>> Have a look at InstanceEncoder >>> >>> http://www.smalltalkhub.com/#!/~hernan/InstanceEncoder >>> >> Thanks, how would you say it works compared to store an Fuel ByteArray? >> > > This is not difficult to test. First save your image and download this file, is the chromosome 22 of a human reference genome (about 10mb of gzip file): > > | client ttr object fileName fStream | > fileName := 'hs_alt_HuRef_chr22.fa.gz'. > [ client := (FTPClient openOnHostNamed: 'ftp.ncbi.nlm.nih.gov') > loginUser: 'anonymous' password: ''; > binary; > changeDirectoryTo: 'genomes/H_sapiens/CHR_22'. > (FileStream newFileNamed: fileName) > binary; > nextPutAll: (client getFileNamed: fileName); > close ] > on: NetworkError, LoginFailedException > do: [ : ex | self error: 'Connection failed' ]. > > Now storing with InstanceEncoder: > > fileName := 'hs_alt_HuRef_chr22.fa.gz'. > ttr := [ Object store: fileName asFileReference contents asSelector: #storedObjectInstanceEncoder ] timeToRun. > (Duration milliSeconds: ttr) asSeconds. > > And with Fuel > > Smalltalk garbageCollect. > fileName := 'hs_alt_HuRef_chr22.fa.gz'. > ttr := [ Object class compile: 'storedObjectFuel > ^ ', (ByteArray streamContents: [ : stream | FLSerializer serialize: fileName asFileReference contents on: stream ]) storeString ] timeToRun. > (Duration milliSeconds: ttr) asSeconds. > > Results for writing > =================== > InstanceEncoder avg: 8 sec. > Fuel avg: 45 sec. > > And reading scripts: > > [ Object storedObjectInstanceEncoder ] timeToRun. > [ FLMaterializer materializeFromByteArray: Object storedObjectFuel ] timeToRun > > Results for reading > =================== > InstanceEncoder avg: 3955 msec > Fuel avg: 70 msec > > And the final cleaning of course :) > > Object class removeSelector: #storedObjectFuel. > Object class removeSelector: #storedObjectInstanceEncoder. > Thanks for the evaluation. I was more thinking about _how_ it works. But I take "similar" as an answer for now. :) Norbert >> Norbert >>> >>> El 23/07/2013 7:47, Norbert Hartl escribiÃ³: >>>> I try to untangle my modules. I have a parser that creates a model and a tool that uses that model. For testing it is convenient to just generate the model and work with it. But this way I introduce dependencies which always pulls everything in. >>>> >>>> In order to untangle I would need a way to easily serialize the runtime model into methods or something similar. Anything that can be transported via monticello is ok. I just don't want to have dependencies to present of external files. That would just change the problem but not solving it. >>>> >>>> Any ideas? >>>> >>>> Norbert >>>> >>> >>> >> >> >> . >> > >

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by HernÃ¡n Morales Durand

El 23/07/2013 9:01, Norbert Hartl escribiÃ³: > > Am 23.07.2013 um 13:20 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > >> Have a look at InstanceEncoder >> >> http://www.smalltalkhub.com/#!/~hernan/InstanceEncoder >> > Thanks, how would you say it works compared to store an Fuel ByteArray? > This is not difficult to test. First save your image and download this file, is the chromosome 22 of a human reference genome (about 10mb of gzip file): | client ttr object fileName fStream | fileName := 'hs_alt_HuRef_chr22.fa.gz'. [ client := (FTPClient openOnHostNamed: 'ftp.ncbi.nlm.nih.gov') loginUser: 'anonymous' password: ''; binary; changeDirectoryTo: 'genomes/H_sapiens/CHR_22'. (FileStream newFileNamed: fileName) binary; nextPutAll: (client getFileNamed: fileName); close ] on: NetworkError, LoginFailedException do: [ : ex | self error: 'Connection failed' ]. Now storing with InstanceEncoder: fileName := 'hs_alt_HuRef_chr22.fa.gz'. ttr := [ Object store: fileName asFileReference contents asSelector: #storedObjectInstanceEncoder ] timeToRun. (Duration milliSeconds: ttr) asSeconds. And with Fuel Smalltalk garbageCollect. fileName := 'hs_alt_HuRef_chr22.fa.gz'. ttr := [ Object class compile: 'storedObjectFuel ^ ', (ByteArray streamContents: [ : stream | FLSerializer serialize: fileName asFileReference contents on: stream ]) storeString ] timeToRun. (Duration milliSeconds: ttr) asSeconds. Results for writing =================== InstanceEncoder avg: 8 sec. Fuel avg: 45 sec. And reading scripts: [ Object storedObjectInstanceEncoder ] timeToRun. [ FLMaterializer materializeFromByteArray: Object storedObjectFuel ] timeToRun Results for reading =================== InstanceEncoder avg: 3955 msec Fuel avg: 70 msec And the final cleaning of course :) Object class removeSelector: #storedObjectFuel. Object class removeSelector: #storedObjectInstanceEncoder. Cheers, HernÃ¡n > Norbert >> >> El 23/07/2013 7:47, Norbert Hartl escribiÃ³: >>> I try to untangle my modules. I have a parser that creates a model and a tool that uses that model. For testing it is convenient to just generate the model and work with it. But this way I introduce dependencies which always pulls everything in. >>> >>> In order to untangle I would need a way to easily serialize the runtime model into methods or something similar. Anything that can be transported via monticello is ok. I just don't want to have dependencies to present of external files. That would just change the problem but not solving it. >>> >>> Any ideas? >>> >>> Norbert >>> >> >> > > > . >

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Mariano Martinez Peck

On Tue, Jul 23, 2013 at 9:48 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Mariano, > > Am 23.07.2013 um 14:43 schrieb Mariano Martinez Peck < > marianopeck(a)gmail.com>: > > Norbert, does the model have lots of strings? Because if so you can try > using the compression. It may increase speed. There is always a trade off > between the additional time of compressing/uncompressing. But if the model > has quite an amount of strings, since writing to disk is also slow and the > final stream would be smaller, it could be faster. > > thanks. Yes, the model is a lot of Dictionaries having string keys. And > there are lots more. The usage of the model is write once read many. And > 30ms is good enough for me. So I might try compression only to see the > difference. Well, and maybe to reduce storage size. The mcz is now 261 kb. > > Thanks, I'll see but I am already satisfied with the current approach. > > Mmmm I thought it was ready, sorry my bad. Seems it was not ready nor integrated: https://code.google.com/p/fuel/issues/detail?id=160 But I might be wrong. Max? Cheers, > Norbert > > Cheers, > > > On Tue, Jul 23, 2013 at 9:40 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 23.07.2013 um 14:23 schrieb "jtuchel(a)objektfabrik.de" < >> jtuchel(a)objektfabrik.de>: >> >> > Norbert, >> > >> > Am 23.07.13 14:07, schrieb Norbert Hartl: >> >> Joachim, >> >> >> >> I'm aware that you can do serialization/deserialization yourself. I >> was asking for something to help along the way because a have quite some >> model classes to cover. I want a more generalized way of doing it. As often >> I really think about things _after_ I've sent the mail :) >> > >> > We seem to have a lot in common here. Regard it this way: sending the >> mail made you think again. So the mail itself was all but useless. >> >> I think I have to options: >> >> >> >> 1. The most generic one is serializing into Fuel and compile the >> ByteArray in a method. >> >> 2. The most readable one will be using STON and compiling the STON >> string into a method >> >> >> >> Maybe I should try both. >> > I'd be very interested in what you find. I guess Fuel is smaller and >> maybe even faster. STON, OTOH, is much friendlier for comparing versions >> and such. >> > >> Well, I can't look at the method but I don't find ByteArrays not that >> interesting anyway. So the actual size of the serialized byte array is >> >> (ByteArray streamContents: [:stream| >> FLSerializer serialize: TCAP current model on: stream ]) >> size >> >> is 237445 Bytes. Serializing >> >> [ MAPExampleModels class compile: 'tcap >> ^ ', (ByteArray streamContents: [:stream| >> FLSerializer serialize: TCAP current model on: stream ]) >> storeString ] timeToRun >> >> took 647 ms >> >> but >> >> [FLMaterializer materializeFromByteArray: MAPExampleModels tcap] timeToRun >> >> took only 30ms. Basically I'm not fond of putting too much binary stuff >> into compiled methods but it is the most easy and reliable way of providing >> tests with test data. The whole grammar is stored in methods as well. It is >> text butâ¦. >> >> I think I stay with it for a while. >> >> Norbert >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

July 23, 2013

Change the Package-Chooser-Dialog when using "Move to package..."?

by MartinW

Hi, i always find the Package-Chooser-Dialog (See Screenshot) when using "Move to package..." (e.g. from Nautilus) very strange to use. Why not replacing it with "SearchFacade rPackageSearch" (See second Screenshot)? I tried by changing AbstractTool >> moveInNewPackage: from: moveInNewPackage: aCollection | labels reject lines oldIndex newName item aPackage | aCollection ifEmpty: [^ nil ]. aPackage := aCollection first package. labels := self model packages collect: [:each | each name]. lines := {0}. newName := UIManager default chooseOrRequestFrom: labels lines: lines title: ('Change Package (current: ', aPackage name,')'). newName ifNil: [ ^ nil ]. newName := newName asSymbol. item := self browsedEnvironment packageOrganizer packageNamed: newName. aCollection do: [:aClass | aPackage removeClass: aClass. item addClassDefinition: aClass. aClass category: item name ]. ^ item to: moveInNewPackage: aCollection | originalPackage newPackage | aCollection ifEmpty: [^ nil ]. originalPackage := aCollection first package. newPackage := SearchFacade rPackageSearch chooseFromOwner: self window. newPackage ifNil: [ ^ nil ]. aCollection do: [:aClass | originalPackage removeClass: aClass. newPackage addClassDefinition: aClass. aClass category: newPackage name ]. ^ newPackage <http://forum.world.st/file/n4700280/Old_Change_Package_Dialog.png> <http://forum.world.st/file/n4700280/Package_search.png> -- View this message in context: http://forum.world.st/Change-the-Package-Chooser-Dialog-when-using-Move-to-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 23, 2013

Re: [Pharo-users] [rmod] Post on how to install pharo

by Guillermo Polito

Next week you can show me gutenberg so next time I do it myself :P On Tue, Jul 23, 2013 at 2:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Ok will port your blog to gutenberg and we can compare and you let me know > if the html is ok > after I can generate the stuff for the code. > > stef > > > So far, the HTML tags supported are these: > > http://en.support.wordpress.com/code/#html-tags > > and the code should be exported as this: > > http://en.support.wordpress.com/code/posting-source-code/ > > For syntax coloring I'm using ruby, just like > > [code language="ruby"] > self bla: 1 + super ble. > [/code] > > > > On Tue, Jul 23, 2013 at 12:33 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> >> >> On Tue, Jul 23, 2013 at 12:24 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Guilermo >>> >>> I would like to turn your blog entry into Gutenberg. I will do it while >>> reading it as a kata exercise. >>> >> >> Nice! >> >> >>> Now I'm thinking that I could write a outputer for Gutenberg to produce >>> the blog contents. >>> What is the format used to edit your blog? >>> >> >> I'm writing in wordpress :/... It allows to write a post using a WYSIWYG >> and to write it in a kind of HTML. However, for embedding images and >> writing code it uses tags between brackets. I cannot find a cool >> description on what is exactly the format :(. >> >> >>> Because like that we could change edit gutenberg file and get: >>> latex >>> html >>> blog >>> >> >> Nick Ager didn't show that pier can import wordpress? maybe he can tell >> better :) >> >> >>> >>> Stef >>> >>> On Jul 23, 2013, at 11:03 AM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>> Hi guys, >>> >>> I've written a small post on the current mechanisms for download and >>> deploy pharo images and vms. Of course it may not be complete, just wanted >>> to make noise :). So, feedback and retweets are welcome ;). >>> >>> >>> http://playingwithobjects.wordpress.com/2013/07/23/installing-pharo-in-many… >>> >>> Guille >>> >>> >>> >> > >

July 23, 2013

Re: [Pharo-users] [rmod] Post on how to install pharo

by StÃ©phane Ducasse

Ok will port your blog to gutenberg and we can compare and you let me know if the html is ok after I can generate the stuff for the code. stef > So far, the HTML tags supported are these: > > http://en.support.wordpress.com/code/#html-tags > > and the code should be exported as this: > > http://en.support.wordpress.com/code/posting-source-code/ > > For syntax coloring I'm using ruby, just like > > [code language="ruby"] > self bla: 1 + super ble. > [/code] > > > > On Tue, Jul 23, 2013 at 12:33 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Tue, Jul 23, 2013 at 12:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Guilermo > > I would like to turn your blog entry into Gutenberg. I will do it while reading it as a kata exercise. > > Nice! > > Now I'm thinking that I could write a outputer for Gutenberg to produce the blog contents. > What is the format used to edit your blog? > > I'm writing in wordpress :/... It allows to write a post using a WYSIWYG and to write it in a kind of HTML. However, for embedding images and writing code it uses tags between brackets. I cannot find a cool description on what is exactly the format :(. > > Because like that we could change edit gutenberg file and get: > latex > html > blog > > Nick Ager didn't show that pier can import wordpress? maybe he can tell better :) > > > Stef > > On Jul 23, 2013, at 11:03 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> Hi guys, >> >> I've written a small post on the current mechanisms for download and deploy pharo images and vms. Of course it may not be complete, just wanted to make noise :). So, feedback and retweets are welcome ;). >> >> http://playingwithobjects.wordpress.com/2013/07/23/installing-pharo-in-many… >> >> Guille > > >

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Norbert Hartl

Mariano, Am 23.07.2013 um 14:43 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > Norbert, does the model have lots of strings? Because if so you can try using the compression. It may increase speed. There is always a trade off between the additional time of compressing/uncompressing. But if the model has quite an amount of strings, since writing to disk is also slow and the final stream would be smaller, it could be faster. > thanks. Yes, the model is a lot of Dictionaries having string keys. And there are lots more. The usage of the model is write once read many. And 30ms is good enough for me. So I might try compression only to see the difference. Well, and maybe to reduce storage size. The mcz is now 261 kb. Thanks, I'll see but I am already satisfied with the current approach. Norbert > Cheers, > > > On Tue, Jul 23, 2013 at 9:40 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 23.07.2013 um 14:23 schrieb "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de>: > > > Norbert, > > > > Am 23.07.13 14:07, schrieb Norbert Hartl: > >> Joachim, > >> > >> I'm aware that you can do serialization/deserialization yourself. I was asking for something to help along the way because a have quite some model classes to cover. I want a more generalized way of doing it. As often I really think about things _after_ I've sent the mail :) > > > > We seem to have a lot in common here. Regard it this way: sending the mail made you think again. So the mail itself was all but useless. > >> I think I have to options: > >> > >> 1. The most generic one is serializing into Fuel and compile the ByteArray in a method. > >> 2. The most readable one will be using STON and compiling the STON string into a method > >> > >> Maybe I should try both. > > I'd be very interested in what you find. I guess Fuel is smaller and maybe even faster. STON, OTOH, is much friendlier for comparing versions and such. > > > Well, I can't look at the method but I don't find ByteArrays not that interesting anyway. So the actual size of the serialized byte array is > > (ByteArray streamContents: [:stream| > FLSerializer serialize: TCAP current model on: stream ]) size > > is 237445 Bytes. Serializing > > [ MAPExampleModels class compile: 'tcap > ^ ', (ByteArray streamContents: [:stream| > FLSerializer serialize: TCAP current model on: stream ]) storeString ] timeToRun > > took 647 ms > > but > > [FLMaterializer materializeFromByteArray: MAPExampleModels tcap] timeToRun > > took only 30ms. Basically I'm not fond of putting too much binary stuff into compiled methods but it is the most easy and reliable way of providing tests with test data. The whole grammar is stored in methods as well. It is text butâ¦. > > I think I stay with it for a while. > > Norbert > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Mariano Martinez Peck

Norbert, does the model have lots of strings? Because if so you can try using the compression. It may increase speed. There is always a trade off between the additional time of compressing/uncompressing. But if the model has quite an amount of strings, since writing to disk is also slow and the final stream would be smaller, it could be faster. Cheers, On Tue, Jul 23, 2013 at 9:40 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 23.07.2013 um 14:23 schrieb "jtuchel(a)objektfabrik.de" < > jtuchel(a)objektfabrik.de>: > > > Norbert, > > > > Am 23.07.13 14:07, schrieb Norbert Hartl: > >> Joachim, > >> > >> I'm aware that you can do serialization/deserialization yourself. I was > asking for something to help along the way because a have quite some model > classes to cover. I want a more generalized way of doing it. As often I > really think about things _after_ I've sent the mail :) > > > > We seem to have a lot in common here. Regard it this way: sending the > mail made you think again. So the mail itself was all but useless. > >> I think I have to options: > >> > >> 1. The most generic one is serializing into Fuel and compile the > ByteArray in a method. > >> 2. The most readable one will be using STON and compiling the STON > string into a method > >> > >> Maybe I should try both. > > I'd be very interested in what you find. I guess Fuel is smaller and > maybe even faster. STON, OTOH, is much friendlier for comparing versions > and such. > > > Well, I can't look at the method but I don't find ByteArrays not that > interesting anyway. So the actual size of the serialized byte array is > > (ByteArray streamContents: [:stream| > FLSerializer serialize: TCAP current model on: stream ]) > size > > is 237445 Bytes. Serializing > > [ MAPExampleModels class compile: 'tcap > ^ ', (ByteArray streamContents: [:stream| > FLSerializer serialize: TCAP current model on: stream ]) > storeString ] timeToRun > > took 647 ms > > but > > [FLMaterializer materializeFromByteArray: MAPExampleModels tcap] timeToRun > > took only 30ms. Basically I'm not fond of putting too much binary stuff > into compiled methods but it is the most easy and reliable way of providing > tests with test data. The whole grammar is stored in methods as well. It is > text butâ¦. > > I think I stay with it for a while. > > Norbert > > > > -- Mariano http://marianopeck.wordpress.com

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Norbert Hartl

Am 23.07.2013 um 14:23 schrieb "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de>: > Norbert, > > Am 23.07.13 14:07, schrieb Norbert Hartl: >> Joachim, >> >> I'm aware that you can do serialization/deserialization yourself. I was asking for something to help along the way because a have quite some model classes to cover. I want a more generalized way of doing it. As often I really think about things _after_ I've sent the mail :) > > We seem to have a lot in common here. Regard it this way: sending the mail made you think again. So the mail itself was all but useless. >> I think I have to options: >> >> 1. The most generic one is serializing into Fuel and compile the ByteArray in a method. >> 2. The most readable one will be using STON and compiling the STON string into a method >> >> Maybe I should try both. > I'd be very interested in what you find. I guess Fuel is smaller and maybe even faster. STON, OTOH, is much friendlier for comparing versions and such. > Well, I can't look at the method but I don't find ByteArrays not that interesting anyway. So the actual size of the serialized byte array is (ByteArray streamContents: [:stream| FLSerializer serialize: TCAP current model on: stream ]) size is 237445 Bytes. Serializing [ MAPExampleModels class compile: 'tcap ^ ', (ByteArray streamContents: [:stream| FLSerializer serialize: TCAP current model on: stream ]) storeString ] timeToRun took 647 ms but [FLMaterializer materializeFromByteArray: MAPExampleModels tcap] timeToRun took only 30ms. Basically I'm not fond of putting too much binary stuff into compiled methods but it is the most easy and reliable way of providing tests with test data. The whole grammar is stored in methods as well. It is text butâ¦. I think I stay with it for a while. Norbert

July 23, 2013