November 2017 - Pharo-dev - lists.pharo.org

Convention for "reset" methods

by Cyril Ferlicot

Hi, Torsten is doing a really cool job by cleaning the protocols of Pharo. Smalltalk has a lot of conventions and if we want the users to apply them we need to have a clean Pharo. On that subject I was wonderingâ¦ Do we have a real convention for "reset" methods? With this script: ((RPackageOrganizer default packages flatCollect: #methods) select: [ :each | each selector = #reset ]) collect: #protocol as: Bag We can see that there is different way to do. 25 in accessing 11 in initialization 10 in positioning 10 in instance creation And some others less popular choices. So my question is, should we have a conventional protocol for reset methods? For now, most of them are in "accessing", but it cause a violation of the RBUnaryAccessingMethodWithoutReturnRule. Personally I think that "initialization" protocol make the more sens. If the community agree on it we could - Recategorize - Make sure the automatic categorizer follow the convention - Add a rule/test to check that Waiting for your thoughts :) -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 11, 2017

Re: [Pharo-dev] Is fileout on the change sorter working in Pharo 70?

by Alistair Grant

Hi Stef & Stephan, On 8 November 2017 at 22:29, stephan <stephan(a)stack.nl> wrote: > On 08-11-17 22:03, Stephane Ducasse wrote: >> >> File @ /Users/ducasse/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS > > > Yes, this is looks like one of the problems I have with PharoLauncher > directories. It is unclear to me what is kept with the vm and what with the > image. I asked about it in users > > Stephan Could this be one of the side effects of issue #5723, which changed the definition of the workingDirectory from the image location to the OS (shell) working directory (despite the small issue number, it was only merged around 12 Oct 2017)? I don't use PharoLauncher, but assuming it is the result of #5723, it would probably make sense to modify the launcher to set the working directory to the image directory before launching pharo. Cheers, Alistair

Nov. 11, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Esteban Lorenzano

> On 11 Nov 2017, at 08:53, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Esteban > there is not hook to be able to avoid such bugs. I do not understand :) the problem is that this issue do not happen in P7â¦ I wonder why? but well, we need to add a step to P6 64bits building. Esteban > > Stef > > On Sat, Nov 11, 2017 at 12:46 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> got it. >> I was able to reproduce it. >> >> turns out there is a problem in the 32-64 bits conversion and libgit2 >> bindings. >> >> you need to execute this: >> >> LGitExternalStructure allSubclassesDo: #compileFields. >> >> before execute this: >> >> Metacello new >> repository: 'github://estebanlm/libclang-pharo-bindings/src'; >> baseline: 'LibClang'; >> load. >> >> Esteban >> >> >> On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> Any help? >> >> On Nov 10, 2017, at 8:49 AM, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> Yes, trying to install your libclang. >> >> Pharo is brand new download of whatever is on the website - 6.1-64 bit >> version (yes I know its not tested - I was going to test it). >> OSX Sierra. >> I have Xcode and all that goes with it installed (my day job is IoT projects >> with accompanying iPhone apps and occasionally web services development). >> >> Homebrew packages installed include... >> >> appledoc gmp nettle >> autoconf gnutls nmap >> aws-elasticbeanstalk gobject-introspection node >> awscli graphite2 openssl >> basset_ios harfbuzz openssl(a)1.1 >> bazel icu4c p11-kit >> boot2docker imagemagick pango >> c-ares jpeg pcre >> cairo libcroco pixman >> cmake libffi pkg-config >> coreutils libgcrypt python >> cvs libgpg-error python3 >> dfu-util libpng rbenv >> docker librsvg readline >> fontconfig libssh2 redis >> freetype libtasn1 ruby-build >> gdbm libtiff sqlite >> gdk-pixbuf libtool unar >> geoip libunistring wget >> gettext libusb wireshark >> ghostscript little-cms2 xz >> glib lua >> >> >> >> On Nov 10, 2017, at 1:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> I would need a way to reproduce this. >> >> pharo version? (6.1?) >> vm version? >> operating system? >> project you try to install? (I guess is libclang) >> >> anything I should know about your environment? (image is clean/new? are you >> behind a proxy? whatever that can help) >> >> Esteban >> >> On 10 Nov 2017, at 00:08, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> #(0 25 1) >> >> On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> (LGitLibrary uniqueInstance version) >> >> >> >> >> >> >

Nov. 11, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Stephane Ducasse

Tx esteban I agree :) On Fri, Nov 10, 2017 at 7:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > none of them, Iâm sorry :) > I think we can do a lot better with just a bit of effort. > > Esteban > >> On 10 Nov 2017, at 15:26, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> I would prefer the last one. >> Regularity over exception. >> Now the parser should just be good :) >> >> Stef >> >> On Fri, Nov 10, 2017 at 7:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 10 Nov 2017, at 19:12, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Hi sven >>>> >>>> Do you have an example because I do not understand your doubling. >>> >>> Sure, >>> >>> Bla { bla:bla } [ >>> self isFoo ifTrue: [ #foo >>> ] >>> ifFalse: [ [ "block" #bar >>> ]] >>> ] >>> >>> would have to become >>> >>> Bla { bla:bla } [ >>> self isFoo ifTrue: [ #foo >>> ]] >>> ifFalse: [ [ "block" #bar >>> ]]] >>> ] >>> >>> but this very rare (because usually code is intended). >>> >>> Nicolas' latest idea is cool too (use as much ['s as needed to avoid conflict). So the example would then become >>> >>> Bla { bla:bla } [[[ >>> self isFoo ifTrue: [ #foo >>> ] >>> ifFalse: [ [ "block" #bar >>> ]] >>> ]]] >>> >>>> stef >>>> >>>> >>>> On Fri, Nov 10, 2017 at 11:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> Hi, >>>>> >>>>> Right now, TonelParser>>#methodBody looks a bit dangerous (too complex), and Nicolas already found some breaking cases as well a one possible solution. I was thinking a bit along the same lines, so here is a proposal. >>>>> >>>>> Overall I think we should keep the current readability of Tonel as much as possible (it is very important for diffs), while still being correct - i.e. no method source, even convoluted ones, possibly in different languages should break the encoding. >>>>> >>>>> The problem is how to quickly scan a stream for the closing $] (which occurs as a single character on a line by its own). Especially in Pharo source code, that situation (a conflict between the proper marker and actual source) is very rare, since code is usually intended. But is can occur and must be dealt with. >>>>> >>>>> The proposal is to just double the $] but only on lines that could conflict (which are lines consisting of only $]'s). The code itself becomes quite simple and remains fast enough. >>>>> >>>>> Here is some code to play with (EOL fixed to #cr for demo purposes): >>>>> >>>>> writer := [ :stream :methodSourceString | >>>>> stream nextPut: $[; cr. >>>>> methodSourceString linesDo: [ :line | >>>>> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >>>>> ifTrue: [ stream << $] ]. >>>>> stream << line; cr ]. >>>>> stream nextPut: $]; cr ]. >>>>> >>>>> reader := [ :stream | | line | >>>>> (stream peekFor: $[) ifTrue: [ stream nextLine ] ifFalse: [ self error ]. >>>>> String streamContents: [ :out | >>>>> [ (line := stream nextLine) = ']' ] whileFalse: [ >>>>> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >>>>> ifTrue: [ out << line allButFirst ] >>>>> ifFalse: [ out << line ]. >>>>> out cr ] ] ]. >>>>> >>>>> encoded := String streamContents: [ :out | writer value: out value: (Collection>>#inject:into:) sourceCode ]. >>>>> >>>>> (reader value: encoded readStream) = ((Collection>>#inject:into:) sourceCode, String cr). >>>>> >>>>> escapedEncoded := String streamContents: [ :out | writer value: out value: 'test >>>>> "Make sure there is no whitespace at line start to force an escape" >>>>> self isFoo ifTrue: [ #foo >>>>> ] >>>>> ifFalse: [ [ "block" #bar >>>>> ]] >>>>> ' ]. >>>>> >>>>> (reader value: escapedEncoded readStream). >>>>> >>>>> What do you think ? >>>>> Did I miss any special cases ? >>>>> Is the price (very occasional insertion of an extra #] in the source code) worth the advantage (a simple, safe scheme). >>>>> >>>>> Sven >>>>> >>>>> PS: Note that several tools line syntax highlighting and double-click next to brackets have problems with weird delimiters such as in the above code ;-) >>>>> >>>>> >>>> >>> >>> >> > >

Nov. 11, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Stephane Ducasse

Esteban there is not hook to be able to avoid such bugs. Stef On Sat, Nov 11, 2017 at 12:46 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > got it. > I was able to reproduce it. > > turns out there is a problem in the 32-64 bits conversion and libgit2 > bindings. > > you need to execute this: > > LGitExternalStructure allSubclassesDo: #compileFields. > > before execute this: > > Metacello new > repository: 'github://estebanlm/libclang-pharo-bindings/src'; > baseline: 'LibClang'; > load. > > Esteban > > > On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Any help? > > On Nov 10, 2017, at 8:49 AM, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Yes, trying to install your libclang. > > Pharo is brand new download of whatever is on the website - 6.1-64 bit > version (yes I know its not tested - I was going to test it). > OSX Sierra. > I have Xcode and all that goes with it installed (my day job is IoT projects > with accompanying iPhone apps and occasionally web services development). > > Homebrew packages installed include... > > appledoc gmp nettle > autoconf gnutls nmap > aws-elasticbeanstalk gobject-introspection node > awscli graphite2 openssl > basset_ios harfbuzz openssl(a)1.1 > bazel icu4c p11-kit > boot2docker imagemagick pango > c-ares jpeg pcre > cairo libcroco pixman > cmake libffi pkg-config > coreutils libgcrypt python > cvs libgpg-error python3 > dfu-util libpng rbenv > docker librsvg readline > fontconfig libssh2 redis > freetype libtasn1 ruby-build > gdbm libtiff sqlite > gdk-pixbuf libtool unar > geoip libunistring wget > gettext libusb wireshark > ghostscript little-cms2 xz > glib lua > > > > On Nov 10, 2017, at 1:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > I would need a way to reproduce this. > > pharo version? (6.1?) > vm version? > operating system? > project you try to install? (I guess is libclang) > > anything I should know about your environment? (image is clean/new? are you > behind a proxy? whatever that can help) > > Esteban > > On 10 Nov 2017, at 00:08, Todd Blanchard <tblanchard(a)mac.com> wrote: > > #(0 25 1) > > On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > (LGitLibrary uniqueInstance version) > > > > > >

Nov. 11, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Esteban Lorenzano

got it. I was able to reproduce it. turns out there is a problem in the 32-64 bits conversion and libgit2 bindings. you need to execute this: LGitExternalStructure allSubclassesDo: #compileFields. before execute this: Metacello new repository: 'github://estebanlm/libclang-pharo-bindings/src'; baseline: 'LibClang'; load. Esteban > On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Any help? > >> On Nov 10, 2017, at 8:49 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >> >> Yes, trying to install your libclang. >> >> Pharo is brand new download of whatever is on the website - 6.1-64 bit version (yes I know its not tested - I was going to test it). >> OSX Sierra. >> I have Xcode and all that goes with it installed (my day job is IoT projects with accompanying iPhone apps and occasionally web services development). >> >> Homebrew packages installed include... >> >> appledoc gmp nettle >> autoconf gnutls nmap >> aws-elasticbeanstalk gobject-introspection node >> awscli graphite2 openssl >> basset_ios harfbuzz openssl(a)1.1 >> bazel icu4c p11-kit >> boot2docker imagemagick pango >> c-ares jpeg pcre >> cairo libcroco pixman >> cmake libffi pkg-config >> coreutils libgcrypt python >> cvs libgpg-error python3 >> dfu-util libpng rbenv >> docker librsvg readline >> fontconfig libssh2 redis >> freetype libtasn1 ruby-build >> gdbm libtiff sqlite >> gdk-pixbuf libtool unar >> geoip libunistring wget >> gettext libusb wireshark >> ghostscript little-cms2 xz >> glib lua >> >> >> >>> On Nov 10, 2017, at 1:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> I would need a way to reproduce this. >>> >>> pharo version? (6.1?) >>> vm version? >>> operating system? >>> project you try to install? (I guess is libclang) >>> >>> anything I should know about your environment? (image is clean/new? are you behind a proxy? whatever that can help) >>> >>> Esteban >>> >>>> On 10 Nov 2017, at 00:08, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>> >>>> #(0 25 1) >>>> >>>>> On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>>> >>>>> (LGitLibrary uniqueInstance version) >>>> >>> >> >

Nov. 11, 2017

Re: [Pharo-dev] Tonel and class definition changes

by Esteban Lorenzano

> On 11 Nov 2017, at 07:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > I extracted my question from previous thread about encoding issue in Tonel. > > 2017-11-10 18:08 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > On 10 Nov 2017, at 13:05, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> 2017-11-10 16:30 GMT+01:00 Martin McClure <martin(a)hand2mouse.com <mailto:martin@hand2mouse.com>>: >> Tonel is intended to be, I believe: >> * For Smalltalk primarily (although there are other languages) >> * Be for any Smalltalk dialect (although the first implementation is for Pharo, it is being ported to GemStone, and we intend to port it to VW and VA) >> >> Interesting how it will be handled when Pharo will use slots abstraction exclusively. And more simple, when there will be only package and tags instead of class categories. >> >> To be more clear. Imaging that instead of #instanceVariables field Pharo will use #slots. And instead of #category it will be #package and #tags > > what does it has to do with this thread? > > My question was related to the sentence that Tonel is intended to be for any Smalltalk dialect. If Pharo will use #slots, #package and #tags names in class definition format it will be not compatible to other smalltalks. we will use #slots and other implementations will use #instVars platforms will need to translate themâ¦ for example, we will be able to interpret instVars as simple slots and categories as packages, they can do the same (it can be more complicated for slots, but at the end, is also doable) tonel is a portable cross dialect format, but that does not means that what is saved for pharo is immediately loadable in other platforms and viceversa. When working for compatibility, framework designers takes the differences into account: they do not use traits and sometimes they need a compatibility layer (Seaside, Iâm watching you). With slots they will need to do the same, and most probably they will not use them, sadly. > > handling that is trivial: once we actually have slots (bah, we have them, but once we *use* them) and once we move to package+tags, we just adapt the descriptions. Thatâs the advantage of using STON to keep them. > > And what will happen then? We will again regenerate all sources/history? > When we will switch to new names every class will be modified in following commit. or incremental (while working). I still do not decide how to proceed since is a problem we still do not have. I have plenty of things I need to decide right now, I can wait a bit for this one :) Esteban >

Nov. 11, 2017

Re: [Pharo-dev] Thanks for he TDD improvement!

by Stephane Ducasse

Yes we should fix what get on our way. The next item is the bad widget for selecting a package taht we all hate. On Sat, Nov 11, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-11-11 11:47 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi >> >> this is super cool to get tests refreshed in nautilus when we define >> the method in the debugger. I was always bored when I do demo to have >> the rerun the tests. >> >> TX because this is super cool >> We should continue to improve the user experience in Pharo. > > > Yes, every little thing leads to big improvement. We should repeat it every > day :). I was annoyed by this issue all the time but not force myself to fix > it. > >> >> >> Stef >> >

Nov. 11, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by raffaello.giulietti＠lifeware.ch

On 2017-11-10 22:18, Nicolas Cellier wrote: > > > 2017-11-10 20:58 GMT+01:00 Martin McClure <martin(a)hand2mouse.com > <mailto:martin@hand2mouse.com>>: > > On 11/10/2017 11:33 AM, raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> wrote: > > Doing only Fraction->Float conversions in mixed mode won't > preserve = as > an equivalence relation and won't enable a consistent ordering > with <=, > which probably most Smalltalkers consider important and enjoyable > properties. > > Good point. I agree that Float -> Fraction is the more desirable > mode for implicit conversion, since it can always be done without > changing the value. > > Nicolas gave some convincing examples on why most > programmers might want to rely on them. > > > Also, as I mentioned, most Smalltalkers might prefer keeping > away from > the complex properties of Floats. Doing automatic, implicit > Fraction->Float conversions behind the scenes only exacerbates the > probability of encountering Floats and of having to deal with their > weird and unfamiliar arithmetic. > > One problem is that we make it easy to create Floats in source code > (0.1), and we print Floats in a nice decimal format but by default > print Fractions in their reduced fractional form. If we didn't do > this, Smalltalkers might not be working with Floats in the first > place, and if they did not have any Floats in their computation they > would never run into an implicit conversion to *or* from Float. > > As it is, if we were to uniformly do Float -> Fraction conversion on > mixed-mode operations, we would get things like > > (0.1 * (1/1)) printStringÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â --> > '3602879701896397/36028797018963968' > > Not incredibly friendly. > > > For those not practicing the litote: definitely a no go. > > > Regards, > -Martin > > > At the risk of repeating myself, unique choice for all operations is a > nice to have but not a goal per se. > > I mostly agree with Florin: having 0.1 representing a decimal rather > than a Float might be a better path meeting more expectations. > > But thinking that it will magically eradicate the problems is a myth. > > Shall precision be limited or shall we use ScaledDecimals ? > > With limited precision, we'll be back to having several Fraction > converting to same LimitedDecimal, so it won't solve anything wrt > original problem. > With illimted precision we'll have the bad property that what we print > does not re-interpret to the same ScaledDecimal (0.1s / 0.3s), but > that's a detail. > The worse thing is that long chain of operations will tend to produce > monster numerators denominators. > And we will all have long chain when resizing a morph with proportional > layout in scalable graphics. > We will then have to insert rounding operations manually for mitigating > the problem, and somehow reinvent a more inconvenient Float... > It's boring to allways play the role of Cassandra, but why do you think > that Scheme and Lisp did not choose that path? > I don't know why Lisper got this way. They justify the conversion choice for comparison (equivalence of = and total ordering of <=) but for the arithmetic operations there does not seem to be a clearly stated rationale. Are they happy with their choice? I haven't the foggiest idea. Don't get me wrong: I understand the Fraction->Float choice for the sake of more speed. But this increase in speed is not functionally transparent: it is not like an increase in the clock rate of a CPU, it's not like a better performing division algorithm, a faster implementation of sorting or a JIT compiler. This increase in speed, rather, comes at the cost of a shift in functionality and cognitive load, because even + or 0.1 have not their conventional semantics. It's not that Floats are wrong by themselves, it's that their operations seem weird at first and at odd with the familiar behavior. Again, I'm not addressing the experts in floating point computation here: they know how to deal with it. Thus, I expect that the developers of numerically intensive libraries or packages, like 2D or 3D graphics, are fully aware of the trade-offs and are in a position to make an explicit choice: either monster denominators in fractions or more care with floats, but always in control. Here, I'm targeting the John Doe Smalltalker which usually uses well-crafted, well-performing libraries and probably only performs a few thousand mixed Fraction/Float computations on his own, and then speed trade-offs do not matter. He is better served with implicit, automatic Float->Fraction conversions in both comparisons and operations. For him, less cognitive load and less surprises are probably an added value.

Nov. 11, 2017

Re: [Pharo-dev] Thanks for he TDD improvement!

by Denis Kudriashov

2017-11-11 11:47 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi > > this is super cool to get tests refreshed in nautilus when we define > the method in the debugger. I was always bored when I do demo to have > the rerun the tests. > > TX because this is super cool > We should continue to improve the user experience in Pharo. > Yes, every little thing leads to big improvement. We should repeat it every day :). I was annoyed by this issue all the time but not force myself to fix it. > > Stef > >

Nov. 11, 2017