August 2014 - Pharo-dev - lists.pharo.org

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

by stepharo

I'm happy that the video made by camillo is still served by the fogbugs web site because it explains really well the process. Stef On 7/8/14 21:48, Benjamin Pollack wrote: > On Aug 7, 2014, at 9:47 AM, stepharo <stepharo(a)free.fr> wrote: > >>> 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? > Yep, it helps. The issue isnât that it was complex; itâs that it was undocumented. The new links are helpful. Excellent! You will that getting your first fixes in the system is a great and cool feeling. >

Aug. 7, 2014

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

by MartinW

Could you extend http://pharo.org/contribute-propose-fix a bit? And add a screenshot of Slice Maker (I attach one). The following text would have helped me (I paste the markdown. I also posted it on NoteHub for a better reading experience http://www.notehub.org/2014/8/7/how-to-propose-a-bug-fix) #How to propose a bug fix: ##Prerequesites: In order to propose a bug fix or enhancement for Pharo you need: - an account at the [Pharo Issue Tracker on Fogbugz](https://pharo.fogbugz.com), - a [SmalltalkHub](http://smalltalkhub.com) account and - the commit right for the [Pharo Inbox on SmalltalkHub](http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) (Ask on the [Pharo Developers mailinglist](http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.… for the commit right). ##Procedure: - Take the latest stable or latest development system, ideally using the latest virtual machine. - Do a fix for a given bug, or a new bug you entered to the issue tracker. - Create a slice (group of packages): - Open the Monticello Browser. - Open the Slice Maker by clicking the **+Slice** button. - In Slice Maker enter the Fogbugz issue number and **grab** the issue summary. - Select all dirty packages affected by your bug fix. - Publish the slice to the inbox: - Select the whole slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit your slice. - Verify that your fix loads: take a fresh image and load the slice you published. - Update the bug entry to mention that you submitted a slice in the inbox. You can also contribute to Pharo by proposing enhancements following the same process. Note that all code submitted to the Pharo repositories is licensed under the MIT license. Do not forget to sign the license agreement. <http://forum.world.st/file/n4772388/SliceMaker.png> -- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-righ… 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 stepharo

thanks tim I took into account your feedback ;) have a look On 7/8/14 18:10, Tim Mackinnon wrote: > 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: > o Create or Verify there is an issue in the Fogbugz issue > tracker <https://pharo.fogbugz.com/default.asp?W41> (use link > to https://pharo.fogbugz.com) > o Get the latest stable or development image, ideally using the > latest virtual machine (check the download section). > o Create a code fix (ideally with a unit test exercising the > working code) > o Create a Monticello slice (group of packages) using the MC > browser, and add the dirty packages > o Publish the slice in the inbox > o Verify that your fix loads into a clean image > o 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 > <mailto:ml-node+s1294792n4772306h66@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 >> <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. >> NAML >> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> >> >

Aug. 7, 2014

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

by Benjamin Pollack

On Aug 7, 2014, at 9:47 AM, stepharo <stepharo(a)free.fr> wrote: >> 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? Yep, it helps. The issue isnât that it was complex; itâs that it was undocumented. The new links are helpful.

Aug. 7, 2014

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

by Eliot Miranda

On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) < juanlists(a)jvuletich.org> wrote: > 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. then if you feel strongly change it back, but you need to fix this: (1/2) isLiteral false when you do so. Also check these comments from Dan: >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2000- > March/013368.html > >> >> >> 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 > -- best, Eliot

Aug. 7, 2014

Re: [Pharo-dev] Deprecator

by stepharo

> 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 :) improve it and we will check the side effects :) > But if I can succeed doing that, I can keep using RB rewriter of course. >

Aug. 7, 2014

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