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

Re: [Pharo-dev] Convention for "reset" methods

by Ben Coman

+1. I think "accessing" sometimes ends up the default catch-all. "Initialization" makes more sense for this. Cheers -ben On Sun, Nov 12, 2017 at 2:31 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > 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. 12, 2017

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

by Esteban Lorenzano

> On 12 Nov 2017, at 09:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > the only thing I can think now is you have a cache problem (older version of sources, older version of image, I don't know). > this is *exactly* what I did and worked: > > $ wget -O- get.pharo.org/64/61+vm <http://get.pharo.org/64/61+vm> | bash ah, and Iâd execute this in an empty dir so Iâm sure there is no caching stuff in the middle. > $ ./pharo-ui Pharo.image --no-default-preferences > > open playground > > LGitExternalStructure allSubclassesDo: #compileFields. > Metacello new > repository: 'github://estebanlm/libclang-pharo-bindings/src <github://estebanlm/libclang-pharo-bindings/src>'; > baseline: 'LibClang'; > load. > > that loaded correctly for me (macOS high sierra). > > Esteban > > >> On 11 Nov 2017, at 17:43, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >> >> Executed that. Now tried to do: >> >>> Metacello new >>> repository: 'github://estebanlm/libclang-pharo-bindings/src <github://estebanlm/libclang-pharo-bindings/src>'; >>> baseline: 'LibClang'; >>> load. >> >> >> And I'm back to "Could not resolve 'BaselineOfLibClang' >> >> <Pharo6.1-64.image 2017-11-11 12-41-07.png> >> >> Also tried the iceberg loader. I get... >> >> "No ssh-agent suitable credentials found". Why? Its a public repository. >> >> <Pharo6.1-64.image 2017-11-11 12-43-00.png> >> >> >> >> >>> On Nov 11, 2017, at 3:46 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@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 <github://estebanlm/libclang-pharo-bindings/src>'; >>> baseline: 'LibClang'; >>> load. >>> >>> Esteban >>> >>>> On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@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. 12, 2017

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

by Esteban Lorenzano

the only thing I can think now is you have a cache problem (older version of sources, older version of image, I don't know). this is *exactly* what I did and worked: $ wget -O- get.pharo.org/64/61+vm <http://get.pharo.org/64/61+vm> | bash $ ./pharo-ui Pharo.image --no-default-preferences open playground LGitExternalStructure allSubclassesDo: #compileFields. Metacello new repository: 'github://estebanlm/libclang-pharo-bindings/src <github://estebanlm/libclang-pharo-bindings/src>'; baseline: 'LibClang'; load. that loaded correctly for me (macOS high sierra). Esteban > On 11 Nov 2017, at 17:43, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Executed that. Now tried to do: > >> Metacello new >> repository: 'github://estebanlm/libclang-pharo-bindings/src <github://estebanlm/libclang-pharo-bindings/src>'; >> baseline: 'LibClang'; >> load. > > > And I'm back to "Could not resolve 'BaselineOfLibClang' > > <Pharo6.1-64.image 2017-11-11 12-41-07.png> > > Also tried the iceberg loader. I get... > > "No ssh-agent suitable credentials found". Why? Its a public repository. > > <Pharo6.1-64.image 2017-11-11 12-43-00.png> > > > > >> On Nov 11, 2017, at 3:46 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@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 <github://estebanlm/libclang-pharo-bindings/src>'; >> baseline: 'LibClang'; >> load. >> >> Esteban >> >>> On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@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. 12, 2017

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

by werner kassens

Hi, i dont agree with this pov. for example consider this mixed-mode calc: aFraction ln + aNumber. Fraction>>#ln returns a float and i suppose you dont want to change that eg by returning a quasi-NaN like "ResultNonRepresentableInTheSetOfFractionsError". if you suppress (2) and aNumber would be a Float youd get a float as result. if aNumber would be a fraction youd get a fraction as result and perhaps somebody could expect the result to be precise, but actually it can be less precise than in the first case (two roundings instead of one). this change just opens a can of worms. werner On 11/12/2017 08:15 AM, Tudor Girba wrote: > Hi, > > Indeed, I agree with this point of view. > > Can we distill a concrete path to action from this? > > Cheers, > Doru > > >> On Nov 11, 2017, at 11:58 AM, raffaello.giulietti(a)lifeware.ch wrote: >> >> 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. > -- > www.tudorgirba.com > www.feenk.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > > > >

Nov. 12, 2017

[Pharo 7.0-dev] Build #286: 20673 Categorize uncategorized methods in classes starting with H

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #286 was: SUCCESS. The Pull Request #467 was integrated: "20673 Categorize uncategorized methods in classes starting with H" Pull request url: https://github.com/pharo-project/pharo/pull/467 Issue Url: https://pharo.fogbugz.com/f/cases/20673 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 12, 2017

[Pharo 7.0-dev] Build #285: 20675 Categorize uncategorized methods in classes starting with D

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #285 was: SUCCESS. The Pull Request #469 was integrated: "20675 Categorize uncategorized methods in classes starting with D" Pull request url: https://github.com/pharo-project/pharo/pull/469 Issue Url: https://pharo.fogbugz.com/f/cases/20675 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 12, 2017

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

by Tudor Girba

Hi, Indeed, I agree with this point of view. Can we distill a concrete path to action from this? Cheers, Doru > On Nov 11, 2017, at 11:58 AM, raffaello.giulietti(a)lifeware.ch wrote: > > 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. -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Nov. 12, 2017

Re: [Pharo-dev] Convention for "reset" methods

by Sean P. DeNigris

CyrilFerlicot wrote > So my question is, should we have a conventional protocol for reset > methods? Out of those choices, accessing and instance creation seem the worst. I agree that initialization seems best out of those. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 12, 2017

Re: [Pharo-dev] feenk log

by Tudor Girba

Hi Denis, It is not a global function. It is a class-side method because it relies on the following logic: - if the element is attached to a space, it uses that space to dispatch the event. - otherwise, it creates a temporary space and uses that one. The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements. Cheers, Doru > On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Aliaksei > > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi Sean, > > Why not `anElement simulateClick`? > > Good question :) > We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that. > > First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... > That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue. > > Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? > To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this: > > BlSpace simulateClickOn: element. > > It looks like global function. According to your description I would expect: > aSpace simulateClickOn: element > > I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? > And what is actual use case for such simulations if we can just #fireEvent: as you wrote below? > > > In english it is quite nice: > > "dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element. > > P.S. Users can still send a BlClickEvent directly (informs 'click'): > > element := BlElement new. > element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. > element fireEvent: BlClickEvent new > > Cheers, > Alex > > On 10 November 2017 at 21:22, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote > > - support for programatic testing of bloc mouse events: > > https://twitter.com/feenkcom/status/925672206763511808 > > Why not `anElement simulateClick`? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

Nov. 11, 2017

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

by Todd Blanchard

Executed that. Now tried to do: > Metacello new > repository: 'github://estebanlm/libclang-pharo-bindings/src <github://estebanlm/libclang-pharo-bindings/src>'; > baseline: 'LibClang'; > load. And I'm back to "Could not resolve 'BaselineOfLibClang' Also tried the iceberg loader. I get... "No ssh-agent suitable credentials found". Why? Its a public repository. > On Nov 11, 2017, at 3:46 AM, 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 <github://estebanlm/libclang-pharo-bindings/src>'; > baseline: 'LibClang'; > load. > > Esteban > >> On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@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