October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

by Glenn CavarlÃ©

Denis Kudriashov wrote > I can't take it. Duplication is always bad. There is no reason for it. I agree, is always bad if there is no real reason to duplicate but i think there is a real argument for Bloc. OSWindow cannot be the only one backend for Bloc so Bloc events cannot be based on OSEvents. We need also a backend for mobile devices with a completely different implementation than the OSWindow one. OSWindow is not adapted for non-window-based platforms like mobiles. For example, on Android, we have to deal with activities and to convert Android events to Bloc events. Denis Kudriashov wrote > And BlOSWindowEventHandler will work directly with SDL event with full > access to raw event data. No need for intermediate level It is interesting only if performances are substantially improved. Because it is also duplication, you duplicates in Bloc the OSWindow conversion code without any added value. Moreover, this does not prevent the duplication of Event hierarchy. OSWindow is already used in other projects and these users will not be happy if we remove OSEvents ;). It is clear that every layer has a cost which should not be neglected. But right now, i think this cost is counterbalanced by the possibility to move transparently on different windowing backends. I'm ok if everybody wants to merge Bloc and OSWindow as a single project but I doubt this is the case. Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920265.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Denis Kudriashov

2016-10-26 15:40 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2016-10-26 13:48 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)gmail.com>: > >> Denis Kudriashov wrote >> > And now how to activate Halo menu to place with elements on screen? >> >> There is no built-in Halo menu because Menu is based on widgets (aka >> Brick). >> But there is a basic kind of Halo with basic tools (move, resize, inspect) >> that can be use on any elements. >> You can find some uses of BlElementSelection in examples. >> > > Nice. I found it and some bug (I guess). > Try example #exampleRectWithElChildren and double click on internal > element them try to resize it. You will see wrong size. > Also rotation work strangely. It rotates over left top of selection border. But I think it should be over selection center

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Denis Kudriashov

2016-10-26 13:48 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)gmail.com>: > Denis Kudriashov wrote > > And now how to activate Halo menu to place with elements on screen? > > There is no built-in Halo menu because Menu is based on widgets (aka > Brick). > But there is a basic kind of Halo with basic tools (move, resize, inspect) > that can be use on any elements. > You can find some uses of BlElementSelection in examples. > Nice. I found it and some bug (I guess). Try example #exampleRectWithElChildren and double click on internal element them try to resize it. You will see wrong size.

Oct. 26, 2016

Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

by Denis Kudriashov

Hi Glenn. Thank's for answer. 2016-10-26 13:29 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)gmail.com>: > More generally, i think that, to stay consistent, Bloc should not reuse > directly (and everywhere) some part of underlying libraries even if > sometime > these parts seems to match directly. > I can't take it. Duplication is always bad. There is no reason for it. I think we just don't need OSEvent's. Real low level is SDL events hierarchy. And OSSDL2WindowHandle built OSEvent's from them: OSSDL2WindowHandle>>handleNewSDLEvent: sdlEvent ^ sdlEvent accept: self But we can delegate this processing to osWindow osWindow handleNewSDLEvent: sdlEvent which then will call eventsHandler of given window. And BlOSWindowEventHandler will work directly with SDL event with full access to raw event data. No need for intermediate level.

Oct. 26, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Nicolas Cellier

Sorry for being slow minded, yes of course financial apps is exactly the case where round: would be usefull and NEEDS to be exact. 2016-10-26 14:23 GMT+02:00 test <wkassens(a)libello.com>: > Hi Nicolas, > yes, i know. suppose you calc some financial thing and one intermediate > result will be in $. you have to round this Fraction-result to 2 decimals. > now you use this to further calc basepoints as the final result. you have > to convert this to 3 decimals. looking at this final result with 2 decimals > can be be irritating for a moment, if you debug the calcs. and <g> btw i > never use scaledDecimals. > werner > > > On 10/26/2016 02:06 PM, Nicolas Cellier wrote: > > > > 2016-10-26 13:11 GMT+02:00 test <wkassens(a)libello.com>: > >> Hi Nicolas, >> regarding rounding Fractions: >> i use fractions if i want to get an exact result (eg for comparing the >> result with Float calculations). if #round: returns a Float all further >> calcs (with Fractions) will get contaminated, since the rest will become >> Floats too. Hence the "asScaledDecimal: numberOfWishedDecimal" seems better >> to me, but i wonder why these transformations at the end are necessary at >> all? just for the looks? i'd suppose every person, who knows how to use >> Fractions, also knows how to append a #asScaledDecimal: to a result by >> himself, should he want that. >> >> taking as an example financial calcs that first use 2 decimals. >> occasionaly the final result will be basepoints, often small ones like >> 0.003. with scaledDecimals the result would be (ok, look like) 0 since >> scaledDecimals also contaminate the calc. of course one could correct this >> simply with an #asScaledDecimal:3 at the end. nevertheless a first look at >> the zero result would surprise me for a tenth of a second. >> werner >> >> >> Hi Werner, > I don't know the purpose of round: at all. > Most often this kind of message was used before printing probably because > lack of versatile formatted print messages. > In Squeak I replaced most usages of roundTo: by printShowing(Max) > DecimalPlaces:. > Now if it has been added in Pharo and other languages, there must be some > use cases I presume. > Maybe the analysis could be carried on these use cases? > > Beware, converting a Fraction asScaledDecimal will NOT round. > Only the printString is rounded, but the number keeps its whole precision. > Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s. > > ScaledDecimals as they are now are just Fraction with a different > printString... > Not very much added value. > > Nicolas > > >> On 10/26/2016 09:58 AM, Nicolas Cellier wrote: >> >> >> >> 2016-10-26 9:14 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >>> Hi nicolas >>> >>> So what is the solution? We can integrate fast a solution. >>> I would really like to see them fix in Pharo 60. >>> I'm writing a book for newbie and this is the third time I change one >>> chapter >>> so may be I should stop and throw away this chapter. >>> >>> >> 1) for Fraction: >> >> round: numberOfWishedDecimal >> v := 10 raisedTo: numberOfWishedDecimal. >> ^ ((self * v) rounded / v) asFloat >> >> or just replace asFloat if you wish to remain exact: >> >> round: numberOfWishedDecimal >> v := 10 raisedTo: numberOfWishedDecimal. >> ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal >> >> 2) for Float, it is in 15471: >> >> round: numberOfWishedDecimal >> | v maxNumberOfDecimals | >> maxNumberOfDecimals := self class precision - 1 - (self exponent max: >> self class emin). >> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. >> v := 10 raisedTo: numberOfWishedDecimal. >> ^ ((self asFraction * v) rounded / v) asFloat >> >> or if Fraction already answers a Float: >> >> round: numberOfWishedDecimal >> | maxNumberOfDecimals | >> maxNumberOfDecimals := self class precision - 1 - (self exponent max: >> self class emin). >> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. >> ^ self asFraction round: numberOfWishedDecimal >> >> It's slower than current implementation, but will round exactly to the >> nearest Float. >> It's possible to have faster implementation up to 22 decimals if you >> provide a fused-multiply-accumulate primitive... >> >> >> > >

Oct. 26, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

Hi Nicolas, yes, i know. suppose you calc some financial thing and one intermediate result will be in $. you have to round this Fraction-result to 2 decimals. now you use this to further calc basepoints as the final result. you have to convert this to 3 decimals. looking at this final result with 2 decimals can be be irritating for a moment, if you debug the calcs. and <g> btw i never use scaledDecimals. werner On 10/26/2016 02:06 PM, Nicolas Cellier wrote: > > > 2016-10-26 13:11 GMT+02:00 test <wkassens(a)libello.com > <mailto:wkassens@libello.com>>: > > Hi Nicolas, > regarding rounding Fractions: > i use fractions if i want to get an exact result (eg for comparing > the result with Float calculations). if #round: returns a Float > all further calcs (with Fractions) will get contaminated, since > the rest will become Floats too. Hence the "asScaledDecimal: > numberOfWishedDecimal" seems better to me, but i wonder why these > transformations at the end are necessary at all? just for the > looks? i'd suppose every person, who knows how to use Fractions, > also knows how to append a #asScaledDecimal: to a result by > himself, should he want that. > > taking as an example financial calcs that first use 2 decimals. > occasionaly the final result will be basepoints, often small ones > like 0.003. with scaledDecimals the result would be (ok, look > like) 0 since scaledDecimals also contaminate the calc. of course > one could correct this simply with an #asScaledDecimal:3 at the > end. nevertheless a first look at the zero result would surprise > me for a tenth of a second. > werner > > > Hi Werner, > I don't know the purpose of round: at all. > Most often this kind of message was used before printing probably > because lack of versatile formatted print messages. > In Squeak I replaced most usages of roundTo: by > printShowing(Max)DecimalPlaces:. > Now if it has been added in Pharo and other languages, there must be > some use cases I presume. > Maybe the analysis could be carried on these use cases? > > Beware, converting a Fraction asScaledDecimal will NOT round. > Only the printString is rounded, but the number keeps its whole precision. > Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s. > > ScaledDecimals as they are now are just Fraction with a different > printString... > Not very much added value. > > Nicolas > > On 10/26/2016 09:58 AM, Nicolas Cellier wrote: >> >> >> 2016-10-26 9:14 GMT+02:00 stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> Hi nicolas >> >> So what is the solution? We can integrate fast a solution. >> I would really like to see them fix in Pharo 60. >> I'm writing a book for newbie and this is the third time I >> change one chapter >> so may be I should stop and throw away this chapter. >> >> >> 1) for Fraction: >> >> round: numberOfWishedDecimal >> v := 10 raisedTo: numberOfWishedDecimal. >> ^ ((self * v) rounded / v) asFloat >> >> or just replace asFloat if you wish to remain exact: >> >> round: numberOfWishedDecimal >> v := 10 raisedTo: numberOfWishedDecimal. >> ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal >> >> 2) for Float, it is in 15471: >> >> round: numberOfWishedDecimal >> | v maxNumberOfDecimals | >> maxNumberOfDecimals := self class precision - 1 - (self >> exponent max: self class emin). >> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. >> v := 10 raisedTo: numberOfWishedDecimal. >> ^ ((self asFraction * v) rounded / v) asFloat >> >> or if Fraction already answers a Float: >> >> round: numberOfWishedDecimal >> | maxNumberOfDecimals | >> maxNumberOfDecimals := self class precision - 1 - (self >> exponent max: self class emin). >> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. >> ^ self asFraction round: numberOfWishedDecimal >> >> It's slower than current implementation, but will round exactly >> to the nearest Float. >> It's possible to have faster implementation up to 22 decimals if >> you provide a fused-multiply-accumulate primitive... > >

Oct. 26, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Nicolas Cellier

2016-10-26 13:11 GMT+02:00 test <wkassens(a)libello.com>: > Hi Nicolas, > regarding rounding Fractions: > i use fractions if i want to get an exact result (eg for comparing the > result with Float calculations). if #round: returns a Float all further > calcs (with Fractions) will get contaminated, since the rest will become > Floats too. Hence the "asScaledDecimal: numberOfWishedDecimal" seems better > to me, but i wonder why these transformations at the end are necessary at > all? just for the looks? i'd suppose every person, who knows how to use > Fractions, also knows how to append a #asScaledDecimal: to a result by > himself, should he want that. > > taking as an example financial calcs that first use 2 decimals. > occasionaly the final result will be basepoints, often small ones like > 0.003. with scaledDecimals the result would be (ok, look like) 0 since > scaledDecimals also contaminate the calc. of course one could correct this > simply with an #asScaledDecimal:3 at the end. nevertheless a first look at > the zero result would surprise me for a tenth of a second. > werner > > > Hi Werner, I don't know the purpose of round: at all. Most often this kind of message was used before printing probably because lack of versatile formatted print messages. In Squeak I replaced most usages of roundTo: by printShowing(Max)DecimalPlaces:. Now if it has been added in Pharo and other languages, there must be some use cases I presume. Maybe the analysis could be carried on these use cases? Beware, converting a Fraction asScaledDecimal will NOT round. Only the printString is rounded, but the number keeps its whole precision. Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s. ScaledDecimals as they are now are just Fraction with a different printString... Not very much added value. Nicolas > On 10/26/2016 09:58 AM, Nicolas Cellier wrote: > > > > 2016-10-26 9:14 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi nicolas >> >> So what is the solution? We can integrate fast a solution. >> I would really like to see them fix in Pharo 60. >> I'm writing a book for newbie and this is the third time I change one >> chapter >> so may be I should stop and throw away this chapter. >> >> > 1) for Fraction: > > round: numberOfWishedDecimal > v := 10 raisedTo: numberOfWishedDecimal. > ^ ((self * v) rounded / v) asFloat > > or just replace asFloat if you wish to remain exact: > > round: numberOfWishedDecimal > v := 10 raisedTo: numberOfWishedDecimal. > ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal > > 2) for Float, it is in 15471: > > round: numberOfWishedDecimal > | v maxNumberOfDecimals | > maxNumberOfDecimals := self class precision - 1 - (self exponent max: > self class emin). > maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. > v := 10 raisedTo: numberOfWishedDecimal. > ^ ((self asFraction * v) rounded / v) asFloat > > or if Fraction already answers a Float: > > round: numberOfWishedDecimal > | maxNumberOfDecimals | > maxNumberOfDecimals := self class precision - 1 - (self exponent max: > self class emin). > maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. > ^ self asFraction round: numberOfWishedDecimal > > It's slower than current implementation, but will round exactly to the > nearest Float. > It's possible to have faster implementation up to 22 decimals if you > provide a fused-multiply-accumulate primitive... > > >

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Glenn CavarlÃ©

Denis Kudriashov wrote > And now how to activate Halo menu to place with elements on screen? There is no built-in Halo menu because Menu is based on widgets (aka Brick). But there is a basic kind of Halo with basic tools (move, resize, inspect) that can be use on any elements. You can find some uses of BlElementSelection in examples. Regard, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/How-to-try-Bloc-tp4920199p4920247.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Glenn CavarlÃ©

Hi Denis, The new version of Brick has no public (ready to use) version right now and only some basic widgets are implemented. I will finally move it to its "official" SmalltalkHub repository (Pharo/Brick) at the end of the week. After, you will be able to play with it ;). Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/How-to-try-Bloc-tp4920199p4920246.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 26, 2016

Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

by Glenn CavarlÃ©

Hi Denis and thanks for looking at this. Yes there is a duplication of the event hierarchy between Bloc and OSWindow. We discussed about the fusion of OSWindow and Bloc events one year ago at INRIA. We made the choice to keep Bloc independent from OSWindow because, among other things: - Bloc allows several windowing backends, for instance we had a morphic windowing backend (no longer maintained today) - OSEvents are too low level to be used directly in Bloc (nothing about source, target, propagation, consumption ...) - OSWindow has to stay low level and independent from high level preoccupations like the Bloc ones - Bloc has to provide an unified and consistent layer on top of underlying libraries The keyboard management is not yet finished in Bloc. numLock and capsLock seems to be missing, thanks for pointing this. Moreover, some keys are also merged like the left & right distinction between ctrl|alt|shift. If this distinction is really needed in the future maybe we will add it. Denis Kudriashov wrote > BlKeyModifiers encode smart boolean flags about keys back into integer > bits I decided to replace all booleans by one integer+masks because it seems to be more lightweight and this integer can be used directly for the hash key. It is just the internal representation and users don't have to care about this integer. If you think that leads to some issues, i'm not against booleans by nature ;). More generally, i think that, to stay consistent, Bloc should not reuse directly (and everywhere) some part of underlying libraries even if sometime these parts seems to match directly. We have to take care about dependencies between layers. The gain was obvious during the migration from Athens to Sparta. Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920239.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 26, 2016