- Pharo-dev - lists.pharo.org

Re: [Pharo-project] String asPacked/fromPacked:

by Martin Dias

Ok, so I will open an issue to nuke it! 3.0 ? On Wed, Feb 27, 2013 at 11:26 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 27 Feb 2013, at 11:19, Martin Dias <tinchodias(a)gmail.com> wrote: > >> Hi >> >> I discovered this protocol in String hierarchy. Are you familiar with it? >> >> The method comment of #fromPacked: is: >> "Convert from a longinteger to a String of length 4." >> >> The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work. >> >> In examples: >> >> ByteString fromPacked: 'text' asPacked. ---> 'text' >> ByteString fromPacked: 'martin' asPacked. ---> 'rtin' >> WideString fromPacked: ('text' asWideString asPacked). ---> error >> >> >> >> WideString>>asPacked can be easily fixed adding an explicit return to >> the calculation (it's now implicitly returning self). >> >> But... it only encodes one letter: >> >> WideString fromPacked: 'martin' asWideString asPacked ---> 'n' >> >> >> I checked that in Squeak 4.3 there are not senders too. >> >> So... Should we fix the WideString implementation, or directly remove >> this protocol? >> >> Martin > > It might have something to do with pre Mac OS X days, Mac creator/type codes. > > Unless this follows some open standard with a spec, I would say nuke it. > > Doing something like this without specifying encoding strikes me as dangerous. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Feb. 27, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by Sven Van Caekenberghe

On 27 Feb 2013, at 11:19, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi > > I discovered this protocol in String hierarchy. Are you familiar with it? > > The method comment of #fromPacked: is: > "Convert from a longinteger to a String of length 4." > > The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work. > > In examples: > > ByteString fromPacked: 'text' asPacked. ---> 'text' > ByteString fromPacked: 'martin' asPacked. ---> 'rtin' > WideString fromPacked: ('text' asWideString asPacked). ---> error > > > > WideString>>asPacked can be easily fixed adding an explicit return to > the calculation (it's now implicitly returning self). > > But... it only encodes one letter: > > WideString fromPacked: 'martin' asWideString asPacked ---> 'n' > > > I checked that in Squeak 4.3 there are not senders too. > > So... Should we fix the WideString implementation, or directly remove > this protocol? > > Martin It might have something to do with pre Mac OS X days, Mac creator/type codes. Unless this follows some open standard with a spec, I would say nuke it. Doing something like this without specifying encoding strikes me as dangerous. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 27, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by Marcus Denker

On Feb 27, 2013, at 11:19 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi > > I discovered this protocol in String hierarchy. Are you familiar with it? > > The method comment of #fromPacked: is: > "Convert from a longinteger to a String of length 4." > > The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work. > > In examples: > > ByteString fromPacked: 'text' asPacked. ---> 'text' > ByteString fromPacked: 'martin' asPacked. ---> 'rtin' > WideString fromPacked: ('text' asWideString asPacked). ---> error > > > > WideString>>asPacked can be easily fixed adding an explicit return to > the calculation (it's now implicitly returning self). > > But... it only encodes one letter: > > WideString fromPacked: 'martin' asWideString asPacked ---> 'n' > > > I checked that in Squeak 4.3 there are not senders too. > > So... Should we fix the WideString implementation, or directly remove > this protocol? > If something is only in the MethodFinder referenced it shows that it is very very old. (We really need to clean up the MethodFinder, it references a lot of crap). remove. Marcus

Feb. 27, 2013

[Pharo-project] String asPacked/fromPacked:

by Martin Dias

Hi I discovered this protocol in String hierarchy. Are you familiar with it? The method comment of #fromPacked: is: "Convert from a longinteger to a String of length 4." The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work. In examples: ByteString fromPacked: 'text' asPacked. ---> 'text' ByteString fromPacked: 'martin' asPacked. ---> 'rtin' WideString fromPacked: ('text' asWideString asPacked). ---> error WideString>>asPacked can be easily fixed adding an explicit return to the calculation (it's now implicitly returning self). But... it only encodes one letter: WideString fromPacked: 'martin' asWideString asPacked ---> 'n' I checked that in Squeak 4.3 there are not senders too. So... Should we fix the WideString implementation, or directly remove this protocol? Martin

Feb. 27, 2013

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by Frank Shearar

On 27 February 2013 08:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 27, 2013, at 9:20 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 27 February 2013 07:51, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >>> On Tue, Feb 26, 2013 at 7:43 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> On 26 February 2013 18:33, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>>> 2013/2/26 Marcus Denker <marcus.denker(a)inria.fr>: >>>>>> On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: >>>>> >>>>>>> If you count the number of packages in SmalltalkHub and compare them >>>>>>> to the ones in Npmjs.org, it is impressive how much we have. >>>>>> But isn't "package" more like "repository" on smalltalkhub? >>>>> >>>>> It is a Project, but on the explore screen it says Packages, so... who knows? :) >>>>> >>>>> But it is true that GitHub is to SmalltakHub what npm/gem is to...? >>>> >>>> No. GitHub and SmalltalkHub are repositories. Rubygems for Ruby (or >>>> clojars for Clojure, or CPAN for Perl) - are like SqueakMap - catalogs >>>> that point to packages/applications. >>> >>> IHMO, we don't need SqueakMap anymore. If we have ConfigurationOfXXX >>> packages for each project and >>> a different repositories for each Pharo distribution (like the one we >>> have already in SqueakSource), I guess we are very close >>> to the service proposed by SqueakMap. >> >> Sure, see Stef's and my recent exchange. I guess when I say >> "SqueakMap" I should say "SM-like". I don't necessarily mean using the >> existing SM, although it's perfectly usable (despite the rather aged >> web UI) - Chris Muller and I nag people into adding their packages to >> the catalog on a regular basis - but Stef wants something like what SM >> provides only in an assured fashion - "this package definitely works >> with this version because we tried it". > > Did you solve the problem that it was wasting ca. 4MB if memory because > it had a copy of the complete catalog (everything but the files) on the client? It would appear so: SM takes up 296kB at the moment, according to SpaceTally. > Marcus

Feb. 27, 2013

Re: [Pharo-project] pharo-contribution triggering for new Pharo versions

by Marcus Denker

On Feb 27, 2013, at 9:30 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Mon, Feb 25, 2013 at 3:17 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2013-02-25, at 15:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On Feb 25, 2013, at 3:01 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> how to setup the jobs on pharo-contribution to be executed with every >>>> new Pharo version? I tried simply to setup URL trigger on >>>> http://pharo.gforge.inria.fr/ci/image/20/ but it was not started for >>>> new versions. >>> >>> For Opal, I set a content trigger on >>> >>> https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/buildTimestamp >> >> I added a placeholder job >> https://ci.inria.fr/pharo-contribution/job/Pharo-2.0-Update-Trigger/ >> >> so you can just let it depend on that. >> > > The trigger doesn't work. > I think it was missing a http:// in the url. I changed to to trigger on https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/buildTimestamp so that a very dumb mistake when doing updates does not trigger the build. Marcus

Feb. 27, 2013

Re: [Pharo-project] VM unstable

by Sven Van Caekenberghe

On 27 Feb 2013, at 09:31, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 27, 2013, at 8:53 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Feb 27, 2013, at 12:57 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> we still get very undeterministic results from our build server. >>> I relaunched the Pharo-2.0-Tests several times with the exact same VM & Image configuration. >>> >>> BUT, the outcome of the test results varies each time a little bit |( >>> >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/176/testReport/ (windows crashed) >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/177/testReport/ (windows crashed, KernelTests.Chronology.DateTest.testDateAndTimeNow failing...) >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/178/testReport/ (KernelTests.Chronology.DateTest.testDateAndTimeNow on all) >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/179/testReport/ (!BOOM!) >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/180/testReport/ ... ditto ... >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/181/testReport/ (!BOOM! plus windows crash) >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/182/testReport/ (!BOOM! plus windows AND linux crash) >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/183/testReport/ (lots of failures all systems running, no chronology tests failing) >>> ... >>> >>> >>> so we still have to investigate this instability... >> >> It is strange. Form the image side: > > Even stranger > > https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/ > > My theory: strange clock related issues due to virtualisation? To rule out clock problems, you should check the SNTP client that I announced - this was exactly why I wrote it. The ZTimestamp unit tests will only pass if the clock difference is not greater than 2 seconds. If the clock is wrong on the machine, on Linux you can do sudo ntpdate pool.ntp.org to manually force a date/time sync. > But then why did it fail on the mac? > > Marcus > >

Feb. 27, 2013

Re: [Pharo-project] VM unstable

by Marcus Denker

On Feb 27, 2013, at 8:53 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 27, 2013, at 12:57 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> we still get very undeterministic results from our build server. >> I relaunched the Pharo-2.0-Tests several times with the exact same VM & Image configuration. >> >> BUT, the outcome of the test results varies each time a little bit |( >> >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/176/testReport/ (windows crashed) >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/177/testReport/ (windows crashed, KernelTests.Chronology.DateTest.testDateAndTimeNow failing...) >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/178/testReport/ (KernelTests.Chronology.DateTest.testDateAndTimeNow on all) >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/179/testReport/ (!BOOM!) >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/180/testReport/ ... ditto ... >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/181/testReport/ (!BOOM! plus windows crash) >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/182/testReport/ (!BOOM! plus windows AND linux crash) >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/183/testReport/ (lots of failures all systems running, no chronology tests failing) >> ... >> >> >> so we still have to investigate this instability... > > It is strange. Form the image side: Even stranger https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/ My theory: strange clock related issues due to virtualization? But then why did it fail on the mac? Marcus

Feb. 27, 2013

Re: [Pharo-project] pharo-contribution triggering for new Pharo versions

by Pavel Krivanek

On Mon, Feb 25, 2013 at 3:17 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-25, at 15:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Feb 25, 2013, at 3:01 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >>> Hi, >>> >>> how to setup the jobs on pharo-contribution to be executed with every >>> new Pharo version? I tried simply to setup URL trigger on >>> http://pharo.gforge.inria.fr/ci/image/20/ but it was not started for >>> new versions. >> >> For Opal, I set a content trigger on >> >> https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/buildTimestamp > > I added a placeholder job > https://ci.inria.fr/pharo-contribution/job/Pharo-2.0-Update-Trigger/ > > so you can just let it depend on that. > The trigger doesn't work. -- Pavel

Feb. 27, 2013

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by Marcus Denker

On Feb 27, 2013, at 9:20 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 27 February 2013 07:51, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> On Tue, Feb 26, 2013 at 7:43 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 26 February 2013 18:33, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>> 2013/2/26 Marcus Denker <marcus.denker(a)inria.fr>: >>>>> On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: >>>> >>>>>> If you count the number of packages in SmalltalkHub and compare them >>>>>> to the ones in Npmjs.org, it is impressive how much we have. >>>>> But isn't "package" more like "repository" on smalltalkhub? >>>> >>>> It is a Project, but on the explore screen it says Packages, so... who knows? :) >>>> >>>> But it is true that GitHub is to SmalltakHub what npm/gem is to...? >>> >>> No. GitHub and SmalltalkHub are repositories. Rubygems for Ruby (or >>> clojars for Clojure, or CPAN for Perl) - are like SqueakMap - catalogs >>> that point to packages/applications. >> >> IHMO, we don't need SqueakMap anymore. If we have ConfigurationOfXXX >> packages for each project and >> a different repositories for each Pharo distribution (like the one we >> have already in SqueakSource), I guess we are very close >> to the service proposed by SqueakMap. > > Sure, see Stef's and my recent exchange. I guess when I say > "SqueakMap" I should say "SM-like". I don't necessarily mean using the > existing SM, although it's perfectly usable (despite the rather aged > web UI) - Chris Muller and I nag people into adding their packages to > the catalog on a regular basis - but Stef wants something like what SM > provides only in an assured fashion - "this package definitely works > with this version because we tried it". Did you solve the problem that it was wasting ca. 4MB if memory because it had a copy of the complete catalog (everything but the files) on the client? Marcus

Feb. 27, 2013