- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Float parsed as a Fraction bug

by J. Vuletich (mail lists)

Hi Eliot, Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Juan, > > On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) > <juanlists(a)jvuletich.org> wrote: > >> Hi Folks, >> >> Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini >> vMac). >> 1e-3 "printIt" (1/1000) >> 1e-3 class "printIt" Fraction >> 1e3 "printIt" 1000 >> 1e3 class "printIt" SmallInteger >> >> This has always been the behavior in Squeak too. > > Â > What happens if you try compiling a method containing a literal > Fraction and both debug it and decompile it.Â > The attach shows that in ST-80 a CompiledMethod can contain a Fraction literal. Source code form for that is '1e-3'. Debugger works as in Squeak or Cuis. >> Also check these comments from Dan: >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.ht… > > Â > Dan doesn't say anything about Fraction literals in this message. He does talk about scientific notation '1e3' and '1e-3' meaning not Float, but SmallInteger and Fraction. The subject of this thread is "Float parsed as Fraction bug". Â >> I don't think this is a bug at all. > > Â > What, that 1e-3 is a Fraction, not a Float? Â Yes. That, and allowing for Fraction literals in methods. >> BTW, Cuis also supports 1r111111111111 = 12 after this :) Cheers, Juan Vuletich

Aug. 7, 2014

Re: [Pharo-dev] [squeak-dev] Float parsed as a Fraction bug

by Levente Uzonyi

On Thu, 7 Aug 2014, Eliot Miranda wrote: > Hi Juan, > > On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) <juanlists(a)jvuletich.org> wrote: > > Hi Folks, > > Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini vMac). > 1e-3 "printIt" (1/1000) > 1e-3 class "printIt" Fraction > 1e3 "printIt" 1000 > 1e3 class "printIt" SmallInteger > > This has always been the behavior in Squeak too. > > > What happens if you try compiling a method containing a literal Fraction and both debug it and decompile it.Â > > Also check these comments from Dan: http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.ht… > > > Dan doesn't say anything about Fraction literals in this message. I guess the key parts are >>Lowercase 'e' is used to designate the exponent of a floating point >>number (as are 'd' and 'q'). It is illegal to specify an exponent for >>what is otherwise an integer--eg, 10e10 is illegal, while 10.0e10 is >>legal. and "Radix, digits and exponent defined analogously over ints, largeInts, and Floats." > Â > > I don't think this is a bug at all. > > > What, that 1e-3 is a Fraction, not a Float? If 1e-3 is a Float, shouldn't 1e3 be a Float too? Levente

Aug. 7, 2014

Versionner: can't create new version - bug?

by Sean P. DeNigris

1. Make changes to a package of a MetaC project 2. In Versionner, the "Release version" button is disabled. Tried everything I could think of - in left list selected latest version, then baseline, created new baseline, committed package - but couldn't get it un-gray I think as soon as project packages are committed there should be an option to release based on latest versions, no? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-can-t-create-new-version-bug-tp4772373.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 7, 2014

Re: [Pharo-dev] [squeak-dev] Float parsed as a Fraction bug

by Eliot Miranda

Hi Juan, On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) < juanlists(a)jvuletich.org> wrote: > Hi Folks, > > Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini vMac). > 1e-3 "printIt" (1/1000) > 1e-3 class "printIt" Fraction > 1e3 "printIt" 1000 > 1e3 class "printIt" SmallInteger > > This has always been the behavior in Squeak too. > What happens if you try compiling a method containing a literal Fraction and both debug it and decompile it. > Also check these comments from Dan: > http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.ht… > Dan doesn't say anything about Fraction literals in this message. > I don't think this is a bug at all. > What, that 1e-3 is a Fraction, not a Float? > BTW, Cuis also supports 1r111111111111 = 12 after this :) > > Cheers, > Juan Vuletich > > Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Wed, 6 Aug 2014, Eliot Miranda wrote: >> >> Hi Levente, >>> >>> On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi <leves(a)elte.hu> wrote: >>> On Wed, 6 Aug 2014, Eliot Miranda wrote: >>> >>> Hi All, >>> Squeak trunk also suffers from the Float parsed as a >>> Fraction bug: >>> >>> 1e-8 class Fraction >>> 1.0e8 class Float >>> >>> >>> I'm not entirely sure about it being a bug. I've checked Squeak 3.8 >>> (pre-SqNumberParser), and it also parsed that literal as a Fraction. If I >>> want a Float, I can be explicit and use 1.0e-8. >>> >>> >>> IMO it very much *is* a bug. Smalltalk-80 has never supported Fraction >>> literals. They're always written as division expressions. Fraction >>> answers false to isLiteral. Just because it worked that way >>> doesn't mean it was right. I suspect no one noticed. Allowing Fraction >>> literals feels like a big change to me. >>> >> It's more like undefined behavior than a bug IMHO, though the lack of >> #isLiteral makes me think that the Fractions are not intentional. >> Interesting how Nicolas's SqNumberParser behaves the same way as the >> previous number parser in this case. >> >> >> >>> I made a modified version of Fraction >> #printOn:base: which >>> outputs the literal format if possible. The change "fixes" the debugger >>> (note that itw was way less broken in Squeak than in Pharo >>> anyway). >>> The only drawback I found is that some fractions become a bit more >>> "complex" when printed, e.g. 3/4 => 75e-2 >>> >>> >>> OK, but is this the right fix? What does everybody think? Keep the >>> language unchanged or add Fraction literals and add another incompatibility >>> with other dialects? >>> >> I don't think that anyone ever used this "feature" before, so doing what >> other dialects do is probably the best way to resolve this. > > > Agreed. Smalltalk-80 v2 had no literal fractions. ObjectWorks and > VisualWorks have never had literal fractions. I can't speak for other > dialects, but I'm fairly sure none of the Smalltalk/V, Team/V lineage had > literal Fractions either. > > >> If Fractions are literals >>> - what is the semantics of 1/0 (easy, it is not a literal, but needs to >>> be stated)? >>> - what is [1/0.1] on: ZeroDivide do: [:ex| #error] ? Is it 10.0 or >>> #error, i.e. is 1/0.1 10.0 or 1 / 0 followed by the Integer 1? >>> >> I did not propose to make all fractions literals. My implementation >> simply prints decimal fractions with the exponent notation, e.g. 3/4 is >> printed as 75-e2, but 2/3 is still printed as (2/3). >> >> >> Levente >> >> >> >>> Levente >>> -- >>> eek! Eliot >>> >>> -- >>> best,Eliot >>> >>> >> >> >> > > > > > -- > best, > Eliot > > > > -- best, Eliot

Aug. 7, 2014

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by Alexandre Bergel

Before I was contributing to Pharo core much more than now. I have the impression the fogbugz website does not help me. Maybe because I do not find stopper bug anymore. Or maybe because I am focussing entirely to Moose and Roassal. But I prefer the code google Website. Alexandre > Le 07-08-2014 Ã 9:47, stepharo <stepharo(a)free.fr> a Ã©crit : > > >> Okay, so thatâs good, but you guys really need to improve the documentation on the mechanical walkthrough of how to actually claim and submit a bug fix. >> >> Today, I happened to have some spare time, so I figured, what the hell, why not see if I canât fix some bugs blocking the Pharo 4 release. Itâs a reach, granted, but I used to be good at Smalltalk, Iâm still a good programmer, and I figure at least one of the blockers is in the really-annoying-but-technically-easy bucket that no one was willing to touch yet, so chances are good. >> >> Armed with my old knowledge of how Squeak contrib used to work, I at least got as far as manually downloading a VM, manually downloading a .changes/.image, and manually downloading a .sources. Then I go to pharo.org andâ¦ >> >> Well, hmm. No instructions on the submission or development process? Well, no matter, I know you guys use FogBugz, so maybe on the FogBugz wiki? The landing page is unhelpful; clicking on the word âhereâ at âReporting or Fixing a Bug?â takes me to http://pharo.org/get-involved which is a 404. Heading back, I try âDocumentationâ, which contains a lot of documentation, but none how to submit fixes. > You know the guy doing the video remove it because it was in rage against us. > We were not aware that it was linked them. > >> Likewise, I can get great info on the workflow of a bug, but not on how to move code through that workflow. >> >> At this point, by luck, I realize that thereâs a link to âContributeâ in the TOC in FogBugz. Brilliant, exactly what I want! And it has a video walkthrough, no less, which takes me to http://vimeo.com/75183993 andâ¦nope, thatâs a 404 again. Thankfully, the link below it appears to let me download a nice MP4, which does walk me throughâ¦submitting a slice. I actually have no idea if this is the right way to do things anymore, but given that you guys seem to have a super-active GitHub repo, I kind of doubt it. And while thereâs some documentation scattered around about how to use Git and Pharo, itâs not centralized or obvious. >> >> Itâs up to the community to be involved with the tools they love and to submit patches, and youâre totally right to remind everyone that itâs up to us to improve Pharo if we want to keep it alive, but itâs up to the core team to make sure that itâs easy for us to do so, and I think that Pharoâs not doing terribly well on that front right now. > We add a description on the old web site but he got lost. > Now in a nutshell, to submit a fix > > - donwload latest image (there is a script on download) > - do a fix for a giving bug > - publish a slice press (+ slice) in MC, add the dirty packages > - publish it in the inbox (click on inbox and press save) > - take a fresh image. > - reload it and check that it fixes the problem (open MC and click on inbox + open). > > Does it help? > Was it so complex? > >> âBenjamin >

Aug. 7, 2014

Re: [Pharo-dev] [squeak-dev] Float parsed as a Fraction bug

by J. Vuletich (mail lists)

Hi Folks, Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini vMac). 1e-3 "printIt" (1/1000) 1e-3 class "printIt" Fraction 1e3 "printIt" 1000 1e3 class "printIt" SmallInteger This has always been the behavior in Squeak too. Also check these comments from Dan: http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.ht… I don't think this is a bug at all. BTW, Cuis also supports 1r111111111111 = 12 after this :) Cheers, Juan Vuletich Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: > On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Wed, 6 Aug 2014, Eliot Miranda wrote: >> >>> Hi Levente, >>> >>> On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi <leves(a)elte.hu> wrote: >>> Â Â Â On Wed, 6 Aug 2014, Eliot Miranda wrote: >>> >>> Â Â Â Â Â Â Hi All, >>> Â Â Â Â Â Â Â Â Squeak trunk also suffers from the Float parsed as a >>> Fraction bug: >>> >>> Â Â Â Â Â Â 1e-8 class Fraction >>> Â Â Â Â Â Â 1.0e8 class Float >>> >>> I'm not entirely sure about it being a bug. I've checked Squeak 3.8 >>> (pre-SqNumberParser), and it also parsed that literal as a Fraction. >>> If I want a Float, I can be explicit and use 1.0e-8. >>> >>> IMO it very much *is* a bug. Â Smalltalk-80 has never supported >>> Fraction literals. Â They're always written as division expressions. >>> Â Fraction answers false to isLiteral. Â Just because it worked that way >>> doesn't mean it was right. Â I suspect no one noticed. Â Allowing >>> Fraction literals feels like a big change to me. >> >> It's more like undefined behavior than a bug IMHO, though the lack of >> #isLiteral makes me think that the Fractions are not intentional. >> Interesting how Nicolas's SqNumberParser behaves the same way as the >> previous number parser in this case. >> >>> Â Â Â I made a modified version of Fraction >> #printOn:base: which >>> outputs the literal format if possible. The change "fixes" the >>> debugger (note that itw was way less broken in Squeak than in Pharo >>> Â Â Â anyway). >>> Â Â Â The only drawback I found is that some fractions become a bit >>> more "complex" when printed, e.g. 3/4 => 75e-2 >>> >>> OK, but is this the right fix? Â What does everybody think? Â Keep the >>> language unchanged or add Fraction literals and add another >>> incompatibility with other dialects? >> >> I don't think that anyone ever used this "feature" before, so doing >> what other dialects do is probably the best way to resolve this. > > Â > Agreed. Â Smalltalk-80 v2 had no literal fractions. Â ObjectWorks and > VisualWorks have never had literal fractions. Â I can't speak for other > dialects, but I'm fairly sure none of the Smalltalk/V, Team/V lineage > had literal Fractions either. > Â > >>> If Fractions are literals >>> - what is the semantics of 1/0 (easy, it is not a literal, but needs >>> to be stated)? >>> - what is [1/0.1] on: ZeroDivide do: [:ex| #error] ? Â Is it 10.0 or >>> #error, i.e. is 1/0.1 10.0 or 1 / 0 followed by the Integer 1? >> >> I did not propose to make all fractions literals. My implementation >> simply prints decimal fractions with the exponent notation, e.g. 3/4 is >> printed as 75-e2, but 2/3 is still printed as (2/3). >> >> Levente >> >>> Â >>> Â Â Â Levente >>> Â Â Â Â Â Â -- >>> Â Â Â Â Â Â eek! Eliot >>> >>> -- >>> best,Eliot >>> Â >> >> Â > > Â > -- > best, Eliot

Aug. 7, 2014

Metacello Projects: one canonical config/repo for all platforms

by Sean P. DeNigris

There are two things that have bothered me about our use of Metacello, but I couldn't explain exactly why until now. These are two guidelines that I think are important: 1. ConfigurationOfMyProject should live at repoOfMyProject. Any MetaRepoForXyz should only be a copy of this config 2. Platform-specific config sections are not optional Without these two things, we're back in Babbel. Here's why... I wrote a configuration that depended on several well-known projects. Someone had very generously updated the configs and placed them in metaReposForXyz (e.g. http://squeaksource.com/MetacelloRepository) so that's the repo I referenced in my config. In the meantime, the same was done for later Pharo versions (MetaRepoFor30, etc). Now I'm stuck - either I have to manually manage platform variations of project dependencies myself, or settle to only ever have my config work in latest Pharo - but I'll still have to update the repo url for each new version which is a pain. Of course I understand that editing directly in a MetaRepo is very tempting (and I've done it myself), it is a quick and dirty hack that subverts much of the value of Metacello. Of course, there are limits to our ability to follow #1, like where we don't have access to the repo, but it doesn't even seem like we're trying. And there are limits to #2 like maybe we don't know how to get it to work in Squeak, but we can at least keep Pharo versions working. I have been using Mariano's workflow of using latest Pharo as the reference implementation and adding compatibility shims for previous versions. If we don't take an extra moment to do it right, we simply push this work onto users. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-Projects-one-canonical-config-repo-for-all-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 7, 2014

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by Tim Mackinnon

Thats better - I think some overview text on the website and link to the wiki where more people can put finer details works very well. On the http://pharo.org/contribute-propose-fix page - perhaps we could do the same sort of thing too? Iâm thinking maybe the following text might be better? (and we put the exact details of how to use Monticello and slices on the wiki) First check you meet the submission requirements and are familiar with the more detailed [contribution steps] (use link: https://pharo.fogbugz.com/default.asp?W68) In Summary you will do the following: Create or Verify there is an issue in the Fogbugz issue tracker (use link to https://pharo.fogbugz.com) Get the latest stable or development image, ideally using the latest virtual machine (check the download section). Create a code fix (ideally with a unit test exercising the working code) Create a Monticello slice (group of packages) using the MC browser, and add the dirty packages Publish the slice in the inbox Verify that your fix loads into a clean image Update the bug entry to mention that you have submitted a slice to the inbox On 7 Aug 2014, at 14:55, stepharo [via Smalltalk] <ml-node+s1294792n4772306h66(a)n4.nabble.com> wrote: > I added a description on the contribute page > > http://pharo.org/contribute > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-righ… > To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. > NAML

Aug. 7, 2014

Re: [Pharo-dev] [squeak-dev] Float parsed as a Fraction bug

by Eliot Miranda

On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 6 Aug 2014, Eliot Miranda wrote: > > Hi Levente, >> >> On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Wed, 6 Aug 2014, Eliot Miranda wrote: >> >> Hi All, >> Squeak trunk also suffers from the Float parsed as a >> Fraction bug: >> >> 1e-8 class Fraction >> 1.0e8 class Float >> >> >> I'm not entirely sure about it being a bug. I've checked Squeak 3.8 >> (pre-SqNumberParser), and it also parsed that literal as a Fraction. If I >> want a Float, I can be explicit and use 1.0e-8. >> >> >> IMO it very much *is* a bug. Smalltalk-80 has never supported Fraction >> literals. They're always written as division expressions. Fraction >> answers false to isLiteral. Just because it worked that way >> doesn't mean it was right. I suspect no one noticed. Allowing Fraction >> literals feels like a big change to me. >> > > It's more like undefined behavior than a bug IMHO, though the lack of > #isLiteral makes me think that the Fractions are not intentional. > Interesting how Nicolas's SqNumberParser behaves the same way as the > previous number parser in this case. > > > >> I made a modified version of Fraction >> #printOn:base: which >> outputs the literal format if possible. The change "fixes" the debugger >> (note that itw was way less broken in Squeak than in Pharo >> anyway). >> The only drawback I found is that some fractions become a bit more >> "complex" when printed, e.g. 3/4 => 75e-2 >> >> >> OK, but is this the right fix? What does everybody think? Keep the >> language unchanged or add Fraction literals and add another incompatibility >> with other dialects? >> > > I don't think that anyone ever used this "feature" before, so doing what > other dialects do is probably the best way to resolve this. Agreed. Smalltalk-80 v2 had no literal fractions. ObjectWorks and VisualWorks have never had literal fractions. I can't speak for other dialects, but I'm fairly sure none of the Smalltalk/V, Team/V lineage had literal Fractions either. If Fractions are literals >> - what is the semantics of 1/0 (easy, it is not a literal, but needs to >> be stated)? >> - what is [1/0.1] on: ZeroDivide do: [:ex| #error] ? Is it 10.0 or >> #error, i.e. is 1/0.1 10.0 or 1 / 0 followed by the Integer 1? >> > > I did not propose to make all fractions literals. My implementation simply > prints decimal fractions with the exponent notation, e.g. 3/4 is printed as > 75-e2, but 2/3 is still printed as (2/3). > > > Levente > > > >> Levente >> -- >> eek! Eliot >> >> -- >> best,Eliot >> >> > > > -- best, Eliot

Aug. 7, 2014

Re: [Pharo-dev] Deprecator

by Camille Teruel

Sorry for delay, I was taken by some other business :) I fixed the bug you reported: check new version. On 7 aoÃ»t 2014, at 16:42, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > camille teruel wrote >> It's because I don't want users to have to know RB pattern syntax and also >> because I plan to not depend on the rewriter in future versions. > > Ah I see. RB is powerful and well-known. While easy to replace for simple > cases, I wonder if you might be forced to either limit that power or > reinvent the wheel... Why not just rely on RB, which was designed for this > and battle hardened over many years? There are some problems with RB rewriter in some cases. For example it's hard to rewrite the sender of one message inside a cascaded messages because it entails changing some surrounding nodes to be a correct transformation. There are other cases like that that don't do what one expects. I can have a look to fix these cases, but I'm afraid to break many tools relying on the current behavior of the rewriter :) But if I can succeed doing that, I can keep using RB rewriter of course. > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Deprecator-tp4769843p4772319.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 7, 2014