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

Re: [Pharo-dev] feenk log

by Stephane Ducasse

Nice explanation. Aliaksei do you add it to the BLSpace class comment? Stef On Fri, Nov 10, 2017 at 10:36 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > 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. > > 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 >> >

Nov. 11, 2017

Re: [Pharo-dev] feenk log

by Stephane Ducasse

Thanks Doru this is cool to see this happening. Stef On Fri, Nov 10, 2017 at 7:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Over the past couple of weeks Alex worked on stabilizing a first beta01 version for Pharo 6.1: > https://twitter.com/feenkcom/status/929031849879461889 > > This is available as a beta01 tag in the pharo61 branch here: > https://github.com/pharo-graphics/Bloc/tree/beta01 > > The main readme was updated with instructions and links: > https://github.com/pharo-graphics/Bloc > > An overview of the improvements: > - improved animations support that also works for scaling > https://twitter.com/feenkcom/status/927617393194610693 > - improved debugging support for transformations > https://twitter.com/feenkcom/status/926040946130612224 > - support for programatic testing of bloc mouse events: > https://twitter.com/feenkcom/status/925672206763511808 > - updated MemoryGame tutorial: > http://files.pharo.org/books-pdfs/booklet-Bloc/2017-11-09-memorygame.pdf > https://github.com/pharo-graphics/Tutorials > - extended examples that offer a 52% coverage > - new Bloc world menu for easily accessing Bloc examples and reseting the Universe > > Cheers, > The feenk team > > -- > www.tudorgirba.com > www.feenk.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > >

Nov. 11, 2017

Tonel and class definition changes

by Denis Kudriashov

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>: > On 10 Nov 2017, at 13:05, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-11-10 16:30 GMT+01:00 Martin McClure <martin(a)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. > 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.

Nov. 11, 2017

Re: [Pharo-dev] Alternative window manager

by Stephane Ducasse

Tx Phil! On Sat, Nov 11, 2017 at 11:37 AM, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > I need to give it some love as the keybindings are all acting bad. > Aerosnap style stuff to be added as well. > > There is an issue with integrating the world menu due to morphic changes. > Do I disabled it. > > I'll give it a shot for 6.1 as it is now a 5 > 0 thing. > Phil > > On Nov 10, 2017 22:36, "Alistair Grant" <akgrant0710(a)gmail.com> wrote: >> >> Hi Thomas, >> >> On 10 November 2017 at 11:46, Thomas Dupriez >> <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >> > Hello, >> > >> > Does an alternative window manager for pharo exist? >> > >> > For some reasons I always end up with a tangled mess of windows when >> > using >> > the default one. My biggest gripe is that new windows tend to open on >> > top of >> > other windows, blocking the view even if there is still empty space >> > elsewhere. >> > >> > I watched this video ( https://www.youtube.com/watch?v=Wx0eNaGzAZU ) >> > about >> > the i3 window manager for linux and how it paves the screen with the >> > windows >> > to optimise screen space and make things look less messy, and was >> > wondering >> > whether something like that existed for pharo. >> > >> > Cheers, >> > Thomas >> >> Have you looked at Tiling Window Manager? It doesn't solve the >> problem of windows opening on top of each other, but makes it easy to >> position them: >> >> Metacello new >> baseline: 'TilingWindowManager'; >> repository: 'github://Pharophile/TilingWindowManager:master/packages'; >> load. >> >> >> If there's another window manager that is similar to i3 or Awesome I'd >> love to hear about it. :-) >> >> >> Cheers, >> Alistair >> >

Nov. 11, 2017

Thanks for he TDD improvement!

by Stephane Ducasse

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. Stef

Nov. 11, 2017

Re: [Pharo-dev] Alternative window manager

by philippe.back＠highoctane.be

I need to give it some love as the keybindings are all acting bad. Aerosnap style stuff to be added as well. There is an issue with integrating the world menu due to morphic changes. Do I disabled it. I'll give it a shot for 6.1 as it is now a 5 0 thing. Phil On Nov 10, 2017 22:36, "Alistair Grant" <akgrant0710(a)gmail.com> wrote: > Hi Thomas, > > On 10 November 2017 at 11:46, Thomas Dupriez > <thomas.dupriez(a)ens-paris-saclay.fr> wrote: > > Hello, > > > > Does an alternative window manager for pharo exist? > > > > For some reasons I always end up with a tangled mess of windows when > using > > the default one. My biggest gripe is that new windows tend to open on > top of > > other windows, blocking the view even if there is still empty space > > elsewhere. > > > > I watched this video ( https://www.youtube.com/watch?v=Wx0eNaGzAZU ) > about > > the i3 window manager for linux and how it paves the screen with the > windows > > to optimise screen space and make things look less messy, and was > wondering > > whether something like that existed for pharo. > > > > Cheers, > > Thomas > > Have you looked at Tiling Window Manager? It doesn't solve the > problem of windows opening on top of each other, but makes it easy to > position them: > > Metacello new > baseline: 'TilingWindowManager'; > repository: 'github://Pharophile/TilingWindowManager:master/packages'; > load. > > > If there's another window manager that is similar to i3 or Awesome I'd > love to hear about it. :-) > > > Cheers, > Alistair > >

Nov. 11, 2017

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

by Todd Blanchard

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 <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] feenk log

by Denis Kudriashov

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 >> >> >

Nov. 11, 2017

Re: [Pharo-dev] feenk log

by stephan

On 10-11-17 22:36, Aliaksei Syrel wrote: > 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. The adding of BlElements to the space, and setting up their responsibilities (to e.g. registering to send announcements to domain model objects, and receive them) is normally the responsibility of an object outside the space, I assume. Also, the creation of temporary instances of itself raises the question of exactly what to copy. Please elaborate a bit on the consequences of this for application and test design. Cheers, Stephan

Nov. 11, 2017

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

by Nicolas Cellier

2017-11-10 23:04 GMT+01:00 Florin Mateoc <fmateoc(a)gmail.com>: > On 11/10/2017 4:42 PM, Florin Mateoc wrote: > > On 11/10/2017 4:18 PM, Nicolas Cellier wrote: > > > > 2017-11-10 20:58 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: > >> On 11/10/2017 11:33 AM, raffaello.giulietti(a)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. > > > I don't think people have problems with understanding limited precision. > We do know that when we write 3.14.. we did not write Pi. > As long as it does not contradict the intuition that we developed early on > (and that's the problem with the binary representation of floats, not that > it is limited)... > > The problem is about wanting to preserve equivalence. With limited precision, forget about (a - b) isZero = (a=b), whatever the base we're using for printing numbers. > 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. > > > But I did not propose to drop floats, just to change the visible > representation of literals: 0.1 would mean a ScaledDecimal literal and 0.1f > would mean a float literal. The extra "f" would be a constant reminder that > something special is going on (the dangers of interpreting the literal as > an exact representation in base 10). > > > And there would still be a lot of places where we would continue to > judiciously use floats, such as in morphic. Just like today people don't > use fractions when they don't need their extra precision - ah, who am I > kidding? > Of course, most of the places where we use Float today in fact. Doesn't it mean that ScaledDecimals would solve essentially the problems we don't have? The major outcome is if we can have some notation for float telling about the rounding. Currently with syntactic color we can already mark Float that are not exactly the decimal they pretend to be without changing the syntax at all. So let's do that immediately. There are a lot of developers out there who would go to great lengths to > save an extra keystroke. :) > Well, I think it could be made to work (e.g. one of the low-hanging fixes > would be that multiplication of scaledDecimals would add their scales) and > it would complement nicely Smalltalk's seamless and intuitive largeIntegers > - just like largeIntegers liberate us from the tyranny of the hardware > representation for integers, we should also not be prisoners to the > hardware representation of floats. > But then division is the little grain of sand in the cog which makes ScaledDecimals to not scale. All fraction have a finite number of digits which are repeated, so it's not completely unsolvable. We could write 1.2357575757... as 1.23(57) for example, meaning 57 repeated ad libitum. In order to preserve nice properties of REPL we would completely throw the scale away and just have Decimals. The scale would be what it should: just a parameter passed to a variety of printing. We will then have to insert rounding operations manually for mitigating the problem, and somehow reinvent a more inconvenient Float... I don't think we would have to reinvent Float - this one would stay exactly the same (other than printing the extra f (or d)). But I agree that you raise an important point with precision/scale. We would indeed need to make ScaledDecimal more complicated. Because today 0.1s * 0.1s is printed as 0.0s1, even though 0.1s * 0.1s = (1/100) evaluates to true, which is nice. It's boring to allways play the role of Cassandra, but why do you think that Scheme and Lisp did not choose that path? Oh. come on, if Scheme and Lisp did it all already, why are we all here? :)

Nov. 10, 2017