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

Re: [Pharo-dev] memoized vs once

by Igor Stasenko

On 27 January 2017 at 02:28, Ben Coman <btc(a)openinworld.com> wrote: > On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > > On 27 January 2017 at 01:30, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong <stepharong(a)free.fr> wrote: > >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <astares(a)gmx.de> > >> > wrote: > >> > > >> >> stepharong wrote: > >> >>> > >> >>> can we rename this selector? > >> >>> asMethodConst should be at least be renamed to asConstantMethod > >> >> > >> >> > >> >> When you use "as {something}" then "something" depicts the result of > >> >> the > >> >> conversion message sent to an object. > >> >> > >> >> Like in #asNumber or #asString which shows to what the receiver will > be > >> >> converted. > >> > > >> > > >> > Yes I thought that it was doing that. > >> >> > >> >> > >> >> > >> >> My understanding is that in the case discussed the receiver object is > >> >> NOT converted to a constant unchangeable method, so #asConstantMethod > >> >> would > >> >> not fit as a selector. > >> >> > >> >> Instead it is sent to an object that afterwards is a constant within > a > >> >> method > >> >> (so it will not be evaluated later at runtime again) so IMHO > >> >> #asMethodConstant > >> >> instead of #asMethodConst would be better. > >> > > >> > > >> > I do not understand any of them. > >> > >> method constant = constant of a method > > > >> constant method = method that does not change > >> > > are you sure? > > pretty sure. 'method' is the subject. 'constant' is the adjective that > modifies the subject. > Its a bit hard to explain that intrinsic feeling of what is right, > but maybe.... If the adjective follows the subject its usually > separated by little joining words. > http://www.grammar-monster.com/glossary/adjective_definition.htm > > > maybe it is > > constant method = method that returns constant? > > For me this does not compute. > But I understand rules differ in other languages and its hard to avoid > subtle influences from your primary language. > heh.. you see my pain! right now i have to deal with C++ and seeing all these const Type & foo const.. and cannot parse it.. :) And still, it could just be my personal bias. > So if you & Stef find it ambiguous, it may be for others and we should > aim to avoid that. > > Well, we have more general term for objects that do not change over their lifetime - immutable. And it is moare precise, if we're talking in smalltalk context. So, why borrowing rather alien term into our ecosystem, because i barely heard that anyone were using it, and saying something like 'constant object' or something like this, when talking smalltalk context. Because when you open this 'can' of constant method, what does it means being a constant? Is is that method's properties won't change, or all object(s) it is pointing to never change as well? > cheers -ben > > > > > apparently, that's why 'constant' term doesn't fits there, because > there's > > so many confusion about it. what are the constant in dynamic system, > after > > all? > > -- Best regards, Igor Stasenko.

Jan. 27, 2017

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

by Martin McClure

On 01/26/2017 05:12 PM, Nicolas Cellier wrote: > -0.0 sign is answering -1 at least since 1998, so we might have get used > to it ;) > I've done the job on Squeak trunk, the answer is we need to revise some > senders.... Thanks for looking into it. I'm afraid I don't have time to dig into this one further. A GemStone user noticed the difference between Pharo and GemStone behavior, and in this case it looked like it was the Pharo behavior that made less sense. Regards, -Martin

Jan. 27, 2017

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

by Nicolas Cellier

2017-01-27 0:15 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: > On 01/26/2017 12:47 PM, Nicolas Cellier wrote: > > > > > > 2017-01-26 21:22 GMT+01:00 Martin McClure <martin(a)hand2mouse.com > > <mailto:martin@hand2mouse.com>>: > > [...] > > > The current implementation of #sign is > > > > self > 0 ifTrue: [^ 1]. > > (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. > > ^ 0 > > > > I'd propose factoring this into two simpler methods: > > > > sign > > self > 0 ifTrue: [^ 1]. > > self < 0 ifTrue: [^ -1]. > > ^ 0 > > > > > > maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard > > tells it should be 0 too? > > This addition makes sense to me. > > The standards help a *little* and suggest on alternative. > > ANSI Smalltalk acts like NaNs don't exist (basically, it lets > implementers do what they want for those values). > > ANSI Smalltalk relies on ISO/IEC 10967 of 1994 for numerics (even when > it *cannot* rely on 10967, it does, sigh). That spec only defines a > "sign" operation for floats with a definite numeric value, and says that > operations are *permitted* to accept infinities and NaNs, but does not > require this, nor say what the answer should be. > > The 2007 update of 10967 is somewhat more helpful. It replaces the > "sign" operation with one called "signum" which returns 1, -1, or NaN. > It returns 1 for positive zero and positive infinity, and -1 for > negative zero and negative infinity. If given a qNaN, it returns a qNaN. > If given a signaling NaN, it returns a qNaN but notifies the application > of an "invalid" situation. > > If we extend this to Smalltalk, I *think* this would have us answer qNaN > for qNaN, and for a sNaN signal a resumable exception (a Notification, > perhaps?) that if resumed would answer qNaN. This also seems to make > some sense -- NaNs are supposed to propagate, and asking the just plain > "sign" (as opposed to signBit or isSignMinus) of a NaN is more or less > nonsense. But if you prefer (-1 raisedTo: self signBit) I won't complain. > > I'm OK with answering NaN, it was just a question. An incomplete specification is an open door to useless differences > > > > That means that we'd have to refactor most (all?) senders of sign... > > > > Certainly should audit senders of sign, but I'd expect that most senders > don't really care about what the sign of -0.0 or NaNs are. The answer > would remain the same for all other receivers. > > Regards, > > -Martin > > -0.0 sign is answering -1 at least since 1998, so we might have get used to it ;) I've done the job on Squeak trunk, the answer is we need to revise some senders....

Jan. 27, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Ben Coman

On Fri, Jan 27, 2017 at 5:33 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-01-26 21:09 GMT+01:00 Bernhard Pieber <bernhard(a)pieber.com>: >> >> > - no Spec text model anymore. Rubric widgets are used directly. It >> > improves speed of building text editors >> This is really great. I love the Method Browser. > > > I also forgot to show in demo that it is possible to drag window tab to get > normal separate window (just drag it to free space in World). > I hope it will be enough because to my mind tabs are most suitable approach > but when you really need separate window you will just drag tab out. Cool! This should be intuitive enough from peoples experience with web browsers. cheers -ben

Jan. 27, 2017

Re: [Pharo-dev] [bloc] addressing the moz2d issue

by Ronie Salgado

Hi, Vulkan support. Never with cairo. Pure OpenGL too (try to compile cairo-gl > on mac, good luck!) There is a way to compile it with quartz support. As of > version 2.7.9, *XQuartz does not provide support for high-resolution > Retina displays to X11 apps*, which run in pixel-doubled mode on > high-resolution displays. (https://bugs.freedesktop.org/ > show_bug.cgi?id=92777). Do not rely on Vulkan for core libraries now. It is very green and it has lot of issues. For making Woden 2 with Vulkan on Linux, I had to fix and debug the Intel Vulkan driver myself. Anyway, Athens over Vulkan it is also not a problem, because I did an (incomplete) Athens backend using Woden 2. I have an abstraction for Vulkan(Linux and Windows, probably never available on apple machines), Metal(OS X and iOS) and D3D 12 (Windows, XBox One devkit). Right now I am working on getting Woden 2 working with Metal, which only works on 64 bits mode. Low-level UI framework (without widgets) consists of multiple parts: > > 1. Vector graphics library to render shapes (fill, stroke, path > builder, composition and blending operators) > 2. Font service library (to support different font formats and collect > information about local fonts installed in the system) > 3. Text layout engine (this is where glyph positioning magic happens, > link above too) > 4. Text shaping engine (for high quality text rendering, to understand > the problem => http://behdad.org/text/) > 5. Complex script library (to support ligatures, split glyphs and > other UTF8 stuff, remember https://github.com/mi > nimaxir/big-list-of-naughty-strings > <https://github.com/minimaxir/big-list-of-naughty-strings>) > 6. Image processing library (for various image effects, like gaussian > blur, morphology filter, gamma, displacement map, just to name a few) > 7. Hardware acceleration. Software rendering is nice, however, modern > UIs are full of fancy stuff that require hardware acceleration. > 8. Window and Event management library. With support of borderless and > semi-transparent windows + good support of touchpad. > 9. Custom written "Glue" library that allows all components to work > together. Since modern libs are implemented in C++ we would need to > implement C wrapper and a lot of integration tests. > 10. Make the whole beast cross platform. > > > Did I miss something? > You cannot have SVG style vectorial graphics and high performance graphics in the same time. SVG style paths are really hard to implement, and they cannot be implemented efficiently on hardware. Path filling and stroking are global operations that are best implemented using a serial software scanliner. GPUs are only able to rasterize points, lines, triangles and quads (usually decomposed in triangles). The primitives supported by GPUs only require local information, so they are very efficient to render. I do not understand why are you trying to copy the whole web rendering architecture, which is awful in terms of performance. I think that it is a far better idea to design a 2D graphics API, with the basic rendering primitives that are required for implementing a Widget toolkit, and then leave the SVG style vectorial graphics for some very special cases, such as drawing an actual SVG. This minimalistic graphics API could be implemented using Athens in the first place, then porting to OpenGL 2.0 ES for getting a performance boost, and then when there is a volunteer, it could be implemented with whatever bleeding edge or platform specific graphics API is available. The basics graphics primitives that I have in mind are the following: - Points - Lines (with width or without it) - Triangles - Convex polygons - Rounded rectangle - Circle / Ellipses - Render into a texture ( required for doing filtering) - Textured primitive - Some 2D filters, with the ability of making them optional - Text/Glyph drawing The graphics API should be explicit in terms that they could be two different memory spaces (CPU memory vs dedicated GPU memory), and that transferring resource such as textures can be very expensive. This kind of 2D graphics API could be also useful for developing 2D games using Pharo and OSWindow, an area where I am bit interested because it is far easier than a full 3D renderer. The API could be made partially stateless by passing the full description of how to render the primitives (colored or not, textured or not, 1 or 10 pixel wide lines, etc). It is impossible to make the API completely stateless, because the framebuffer where the rendering is happening by definition is not stateless ;) Best regards, Ronei 2017-01-26 20:36 GMT-03:00 Martin McClure <martin(a)hand2mouse.com>: > On 01/26/2017 02:45 PM, Aliaksei Syrel wrote: > > There are some real questions: > > > > 1. Do we need Bloc or Morphic2 or %name your favourite framework%? > > 2. How advanced and modern do you want it to be? > > 3. What technology stack do we want to use for our new graphical > framework? > > 4. What platforms and operating systems do we want to support? > > 5. How flexible technology stack should be? (some parts may change in > > the future) > > 6. Who will pay for it? > > 7. How many engineers can community afford? > > 8. Do you know how much other systems invest in graphical frameworks? > > 9. It is not a science project, isn't it? > > > > [...] > > Thanks for the analysis, Alex. It sounds like using Moz2d saves a lot of > work... > > -Martin > >

Jan. 27, 2017

Re: [Pharo-dev] memoized vs once

by Ben Coman

On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 27 January 2017 at 01:30, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong <stepharong(a)free.fr> wrote: >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <astares(a)gmx.de> >> > wrote: >> > >> >> stepharong wrote: >> >>> >> >>> can we rename this selector? >> >>> asMethodConst should be at least be renamed to asConstantMethod >> >> >> >> >> >> When you use "as {something}" then "something" depicts the result of >> >> the >> >> conversion message sent to an object. >> >> >> >> Like in #asNumber or #asString which shows to what the receiver will be >> >> converted. >> > >> > >> > Yes I thought that it was doing that. >> >> >> >> >> >> >> >> My understanding is that in the case discussed the receiver object is >> >> NOT converted to a constant unchangeable method, so #asConstantMethod >> >> would >> >> not fit as a selector. >> >> >> >> Instead it is sent to an object that afterwards is a constant within a >> >> method >> >> (so it will not be evaluated later at runtime again) so IMHO >> >> #asMethodConstant >> >> instead of #asMethodConst would be better. >> > >> > >> > I do not understand any of them. >> >> method constant = constant of a method >> constant method = method that does not change >> > are you sure? pretty sure. 'method' is the subject. 'constant' is the adjective that modifies the subject. Its a bit hard to explain that intrinsic feeling of what is right, but maybe.... If the adjective follows the subject its usually separated by little joining words. http://www.grammar-monster.com/glossary/adjective_definition.htm > maybe it is > constant method = method that returns constant? For me this does not compute. But I understand rules differ in other languages and its hard to avoid subtle influences from your primary language. And still, it could just be my personal bias. So if you & Stef find it ambiguous, it may be for others and we should aim to avoid that. cheers -ben > > apparently, that's why 'constant' term doesn't fits there, because there's > so many confusion about it. what are the constant in dynamic system, after > all?

Jan. 27, 2017

Re: [Pharo-dev] [bloc] addressing the moz2d issue

by Martin McClure

On 01/26/2017 02:45 PM, Aliaksei Syrel wrote: > There are some real questions: > > 1. Do we need Bloc or Morphic2 or %name your favourite framework%? > 2. How advanced and modern do you want it to be? > 3. What technology stack do we want to use for our new graphical framework? > 4. What platforms and operating systems do we want to support? > 5. How flexible technology stack should be? (some parts may change in > the future) > 6. Who will pay for it? > 7. How many engineers can community afford? > 8. Do you know how much other systems invest in graphical frameworks? > 9. It is not a science project, isn't it? > [...] Thanks for the analysis, Alex. It sounds like using Moz2d saves a lot of work... -Martin

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Igor Stasenko

On 27 January 2017 at 01:30, Ben Coman <btc(a)openinworld.com> wrote: > On Fri, Jan 27, 2017 at 6:02 AM, stepharong <stepharong(a)free.fr> wrote: > > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <astares(a)gmx.de> > wrote: > > > >> stepharong wrote: > >>> > >>> can we rename this selector? > >>> asMethodConst should be at least be renamed to asConstantMethod > >> > >> > >> When you use "as {something}" then "something" depicts the result of the > >> conversion message sent to an object. > >> > >> Like in #asNumber or #asString which shows to what the receiver will be > >> converted. > > > > > > Yes I thought that it was doing that. > >> > >> > >> > >> My understanding is that in the case discussed the receiver object is > >> NOT converted to a constant unchangeable method, so #asConstantMethod > >> would > >> not fit as a selector. > >> > >> Instead it is sent to an object that afterwards is a constant within a > >> method > >> (so it will not be evaluated later at runtime again) so IMHO > >> #asMethodConstant > >> instead of #asMethodConst would be better. > > > > > > I do not understand any of them. > > method constant = constant of a method > constant method = method that does not change > > are you sure? maybe it is constant method = method that returns constant? apparently, that's why 'constant' term doesn't fits there, because there's so many confusion about it. what are the constant in dynamic system, after all? HTH, cheers -ben > > -- Best regards, Igor Stasenko.

Jan. 26, 2017

Re: [Pharo-dev] athens dead code?

by Igor Stasenko

On 27 January 2017 at 00:06, stepharong <stepharong(a)free.fr> wrote: > > accept: aVisitor > ^ aVisitor lineSegment: self > accept: aVisitor > ^ aVisitor closeSegment: self > accept: aVisitor > ^ aVisitor moveSegment: self > > seems to invoke methods that do not exit > I check AthensLIneSegment is used so I do not understand why the methods > are broken. > > this is a part of visitor api for path segments. if you remove it, then users cannot use it for iterating trough path segments for converting them etc etc.. of course, it may be nit used by Athens itself.. but it doesn't means it is useless. > > -- > Using Opera's mail client: http://www.opera.com/mail/ > > -- Best regards, Igor Stasenko.

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Ben Coman

On Fri, Jan 27, 2017 at 6:02 AM, stepharong <stepharong(a)free.fr> wrote: > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <astares(a)gmx.de> wrote: > >> stepharong wrote: >>> >>> can we rename this selector? >>> asMethodConst should be at least be renamed to asConstantMethod >> >> >> When you use "as {something}" then "something" depicts the result of the >> conversion message sent to an object. >> >> Like in #asNumber or #asString which shows to what the receiver will be >> converted. > > > Yes I thought that it was doing that. >> >> >> >> My understanding is that in the case discussed the receiver object is >> NOT converted to a constant unchangeable method, so #asConstantMethod >> would >> not fit as a selector. >> >> Instead it is sent to an object that afterwards is a constant within a >> method >> (so it will not be evaluated later at runtime again) so IMHO >> #asMethodConstant >> instead of #asMethodConst would be better. > > > I do not understand any of them. method constant = constant of a method constant method = method that does not change HTH, cheers -ben

Jan. 26, 2017