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

Re: [Pharo-dev] memoized vs once

by Igor Stasenko

On 27 January 2017 at 00:28, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > On Thu, Jan 26, 2017 at 2:02 PM, stepharong <stepharong(a)free.fr> wrote: > >> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <astares(a)gmx.de> >> wrote: >> >> ... >> >> >>> 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. >> >> In other words, this is creating a constant inside the method > (#asMethodConstant) instead of making the method return a constant (which > would be your #asConstantMethod). > If I have that right. > In any case, not having the contracted 'Const' would be nice. > > ah.. that sounds similar to what i proposed for computed literals, that has been computed at compilation time and placed in method's literal frame, a simple catch by reserving special selector for it, i.e..: mymethod ^ (something that should be computed , and takes a loong time) asMethodLiteral but that, of course, won't work if you would want to cache results based on method's input parameters. > -cbc > >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >> > -- Best regards, Igor Stasenko.

Jan. 26, 2017

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

by Aliaksei Syrel

Hi *According to conclusion above, we will plan how to migrate to Cairo.* We will need help with Pango. Cheers, Alex On 26 January 2017 at 23:45, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi > > (My previous email was not a joke, I don't try to troll anyone. Let tolls > do their job in other places) > *Let's forget Moz2D for a moment :) Imagine that it does not exist. *It > was done just for fun and is even not in pharo repo. ( > https://github.com/syrel/Moz2D) We needed something that works and it > was made investing just a few months of time of a single anonymous student > during summer exams session and vacations. > > I would like to start maybe one of the most important discussion that will > influence Pharo and will dictate how system will look like in a few years. > I invite everyone to join this discussion, especially board and consortium > members. Because here is where business starts. > > 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? > > Let me first put my two cents in. > > 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? > > Here are some modern technologies commonly used for mentioned parts: > > 1. Skia, Direct2D, CoreGraphics, Cairo > 2. Fontconfig, Freetype2 > 3. HarfBuzz > 4. Pango, OpenType > 5. Graphite2, FriBidi > 6. Imagemagic, SVG filters libraries > 7. Vulkan, OpenGL > 8. wxWidgets, QT, GTK, SDL2 > 9. todo > 10. todo > > Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea! > > Let's assume that we stop on Cairo + Pango. According to pango.com > > The integration of Pango with Cairo (http://cairographics.org/) provides >> a complete solution with high quality text handling and graphics rendering. > > > According to the this potential technology stack we will have: > > - Cairo for vector graphics and rendering of basic shapes > - Pango for text rendering > - SDL2 for window and events management > > What we will not get: > > - Support of filters; Cairo does not support gaussian blur. 3D > transformations, we will not be able to not implement card flip animation. > Never reach the same performance if using platform native frameworks (e.g. > Direct2D on windows). Cairo will not die, but there is zero progress. > - 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 > <https://bugs.freedesktop.org/show_bug.cgi?id=92777>). > - Borderless or transparent window with SDL2. Also, did you notice > that sdl2 window turns black/white while resizing? There is no way to get a > continuous window resize event with SDL2 (https://bugzilla.libsdl.org/s > how_bug.cgi?id=2077). The issue is that events stop firing while user > is resizing a window because main thread is blocked. *Bug is already 3 > years old. *Indeed SDL2 is used for games, however how often do gamers > resize game window? > - Stateless API. Must have for a graphical framework like Bloc where > canvas state is not shared between visual elements. It means that while > rendering users must not clean the state of a canvas after every draw call. > > Bloc is not my or Glenn's or Doru's personal property. We suggest, you > decide. It would be great if community could invest money and time in a > working and appropriate solution. > > P.S. If we would not care, we would agree with you instantly and even not > bothered ourselves trying to spend time on finding cheap solution for such > a complex problem. > > P.P.S Sorry for a long email :) > > Cheers, > Alex > > On 26 January 2017 at 21:10, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > >> Hi, >> >> Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 >> (for fonts) + Graphite (glyphs shaping technology in order to use them >> within vector graphics engine) + cross platform OpenGL / Vulkan >> context/device provider for hardware acceleration + implement Filters for >> effects (blur, lights, color matrix filters, etc...). >> >> Without all those technologies bloc WILL progress, from 80's to 00's. >> Still decades behind :) >> >> Cheers >> >> On Jan 26, 2017 20:40, "stepharong" <stepharong(a)free.fr> wrote: >> >>> I think that instead of investigating gtk (yet another library to bind >>> and carry around), >>> it would be smarter to have Sparta back-end using an accelerated Cairo + >>> pango. >>> Why? Because >>> - For example Cairo will not disappear in the future (here you >>> will tell me that it does not have all the full >>> features.... I think that Bloc should deliver Brick first and >>> focus on this because else it will stay a nice >>> experiment.) >>> - We do not have bench with an accelerated compiled version so >>> no idea if this is good enough. >>> - Cairo is about 1.5 mb vs 20Mb and it is packaged. >>> >>> I share the concerns of Esteban about the maintenance of such Mozz2d >>> bundling and he was pretty >>> clear with me, he will not maintain it nor take any responsibility about >>> pharo using it. >>> >>> So having a Cairo Sparta back-end would be a smart move. >>> Stef >>> >>> >>> >>> >>> >>> Hi, >>>> >>>> Thank you for the intensive set of issues you raised during the Bloc >>>> presentation. I think it is worthwhile addressing them more thoroughly, so >>>> let me start with the issue that seemed to have caused the most worries: >>>> Sparta & Moz2D. >>>> >>>> Please keep in mind that while I am involved to some extent in Bloc, >>>> the real credits for the current state go to Glenn and Alex. >>>> >>>> Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/Platf >>>> orm/GFX/Moz2D) offers an advanced backend and using it puts us on par >>>> with the rendering speed of a web browser, which is a significant added >>>> value over what we have now. >>>> >>>> However, as it was noted, it does come with a cost due to the fact that >>>> it is not available as standalone with only the features we are interested >>>> in. The vector graphics part is actually buildable out of the box. However, >>>> the text support needs to be extracted out of Moz2D, and this is where the >>>> patching scripts are used. The patches are there only for compilation >>>> purposes and not for features and they are applied automatically. You can >>>> see it here: >>>> https://github.com/syrel/Moz2D >>>> >>>> Alex updated recently the Moz2D version and it worked without problems. >>>> Of course, future changes in Moz2D might imply changes in this script as >>>> well, and this implies that we will need to maintain that script. And we >>>> could imagine applying these patches on the trunk of Moz2D to see if they >>>> work, and we can also imagine engaging with the Moz2D owners to see if we >>>> can find a middle ground. >>>> >>>> Now, letâs put this into perspective. We are currently using Athens and >>>> the Cairo backend. While Cairo is provided as a standalone library it has >>>> not seen significant advances since Mozzila shifted its focus towards >>>> Moz2D. So, sticking with it might not be an ideal strategy either. >>>> >>>> Furthermore, just like Athens, Sparta is an abstraction that allows us >>>> to switch the underlying backend should we need to. Until now we did not >>>> find a cross-platform backend that is as advanced and complete as Moz2D, >>>> but there is no reason to think that none other will appear in the future. >>>> Skia is an alternative but it is only a vector graphic engine without text >>>> support, so using it would imply to have another library for the text >>>> support. >>>> >>>> Sparta also comes with a reasonable set of tests that is aimed at >>>> testing the basic Moz2D functionality to make sure that the assumptions on >>>> top of which Sparta is built are correct. >>>> >>>> All in all, I think that the current situation is not ideal, but there >>>> is already enough engineering in place to actually make it work. And I >>>> definitely think that the potential it opens is rather significant. >>>> >>>> And, if more people look at the scripts, we might find even better and >>>> cheaper ways to express it. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "We cannot reach the flow of things unless we let go." >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> >

Jan. 26, 2017

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

by Martin McClure

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

Jan. 26, 2017

HandMorph>>#processEvents

by phil＠highoctane.be

Why do we have this twice in processEvents? self mouseOverHandler processMouseOver: lastMouseEvent ? Well, maybe that is not there that things happen but if you spy on mouseEnter and mouseLeave events, you will notice that they are both sent **twice** all the time. I think that this happens so often that we would benefit from getting rid of that twice enter/leave thing (and it is really annoying to have to deal with these two events when you expect only one. I am not "entering entering" a rectangle). processEvents "Process user input events from the local input devices." | evt evtBuf type hadAny | ActiveEvent ifNotNil: ["Meaning that we were invoked from within an event response. Make sure z-order is up to date" self mouseOverHandler processMouseOver: lastMouseEvent]. hadAny := false. [(evtBuf := Sensor nextEvent) isNil] whileFalse: [evt := nil. "for unknown event types" type := evtBuf first. type = EventTypeMouse ifTrue: [recentModifiers := evtBuf sixth. evt := self generateMouseEvent: evtBuf]. type = EventTypeKeyboard ifTrue: [recentModifiers := evtBuf fifth. evt := self generateKeyboardEvent: evtBuf]. type = EventTypeDragDropFiles ifTrue: [evt := self generateDropFilesEvent: evtBuf]. type = EventTypeWindow ifTrue:[evt := self generateWindowEvent: evtBuf]. "All other events are ignored" (type ~= EventTypeDragDropFiles and: [evt isNil]) ifTrue: [^self]. evt isNil ifFalse: ["Finally, handle it" self handleEvent: evt. hadAny := true. "For better user feedback, return immediately after a mouse event has been processed." (evt isMouse and: [evt isMouseWheel not]) ifTrue: [^self]]]. "note: if we come here we didn't have any mouse events" mouseClickState notNil ifTrue: ["No mouse events during this cycle. Make sure click states time out accordingly" mouseClickState handleEvent: lastMouseEvent asMouseMove from: self]. hadAny ifFalse: ["No pending events. Make sure z-order is up to date" self mouseOverHandler processMouseOver: lastMouseEvent] Clues? Phil

Jan. 26, 2017

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

by Aliaksei Syrel

Hi (My previous email was not a joke, I don't try to troll anyone. Let tolls do their job in other places) *Let's forget Moz2D for a moment :) Imagine that it does not exist. *It was done just for fun and is even not in pharo repo. ( https://github.com/syrel/Moz2D) We needed something that works and it was made investing just a few months of time of a single anonymous student during summer exams session and vacations. I would like to start maybe one of the most important discussion that will influence Pharo and will dictate how system will look like in a few years. I invite everyone to join this discussion, especially board and consortium members. Because here is where business starts. 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? Let me first put my two cents in. 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/minimaxir/big-list-of-naughty-st rings) 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? Here are some modern technologies commonly used for mentioned parts: 1. Skia, Direct2D, CoreGraphics, Cairo 2. Fontconfig, Freetype2 3. HarfBuzz 4. Pango, OpenType 5. Graphite2, FriBidi 6. Imagemagic, SVG filters libraries 7. Vulkan, OpenGL 8. wxWidgets, QT, GTK, SDL2 9. todo 10. todo Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea! Let's assume that we stop on Cairo + Pango. According to pango.com The integration of Pango with Cairo (http://cairographics.org/) provides a > complete solution with high quality text handling and graphics rendering. According to the this potential technology stack we will have: - Cairo for vector graphics and rendering of basic shapes - Pango for text rendering - SDL2 for window and events management What we will not get: - Support of filters; Cairo does not support gaussian blur. 3D transformations, we will not be able to not implement card flip animation. Never reach the same performance if using platform native frameworks (e.g. Direct2D on windows). Cairo will not die, but there is zero progress. - 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). - Borderless or transparent window with SDL2. Also, did you notice that sdl2 window turns black/white while resizing? There is no way to get a continuous window resize event with SDL2 (https://bugzilla.libsdl.org/s how_bug.cgi?id=2077). The issue is that events stop firing while user is resizing a window because main thread is blocked. *Bug is already 3 years old. *Indeed SDL2 is used for games, however how often do gamers resize game window? - Stateless API. Must have for a graphical framework like Bloc where canvas state is not shared between visual elements. It means that while rendering users must not clean the state of a canvas after every draw call. Bloc is not my or Glenn's or Doru's personal property. We suggest, you decide. It would be great if community could invest money and time in a working and appropriate solution. P.S. If we would not care, we would agree with you instantly and even not bothered ourselves trying to spend time on finding cheap solution for such a complex problem. P.P.S Sorry for a long email :) Cheers, Alex On 26 January 2017 at 21:10, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 > (for fonts) + Graphite (glyphs shaping technology in order to use them > within vector graphics engine) + cross platform OpenGL / Vulkan > context/device provider for hardware acceleration + implement Filters for > effects (blur, lights, color matrix filters, etc...). > > Without all those technologies bloc WILL progress, from 80's to 00's. > Still decades behind :) > > Cheers > > On Jan 26, 2017 20:40, "stepharong" <stepharong(a)free.fr> wrote: > >> I think that instead of investigating gtk (yet another library to bind >> and carry around), >> it would be smarter to have Sparta back-end using an accelerated Cairo + >> pango. >> Why? Because >> - For example Cairo will not disappear in the future (here you >> will tell me that it does not have all the full >> features.... I think that Bloc should deliver Brick first and >> focus on this because else it will stay a nice >> experiment.) >> - We do not have bench with an accelerated compiled version so no >> idea if this is good enough. >> - Cairo is about 1.5 mb vs 20Mb and it is packaged. >> >> I share the concerns of Esteban about the maintenance of such Mozz2d >> bundling and he was pretty >> clear with me, he will not maintain it nor take any responsibility about >> pharo using it. >> >> So having a Cairo Sparta back-end would be a smart move. >> Stef >> >> >> >> >> >> Hi, >>> >>> Thank you for the intensive set of issues you raised during the Bloc >>> presentation. I think it is worthwhile addressing them more thoroughly, so >>> let me start with the issue that seemed to have caused the most worries: >>> Sparta & Moz2D. >>> >>> Please keep in mind that while I am involved to some extent in Bloc, the >>> real credits for the current state go to Glenn and Alex. >>> >>> Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/Platf >>> orm/GFX/Moz2D) offers an advanced backend and using it puts us on par >>> with the rendering speed of a web browser, which is a significant added >>> value over what we have now. >>> >>> However, as it was noted, it does come with a cost due to the fact that >>> it is not available as standalone with only the features we are interested >>> in. The vector graphics part is actually buildable out of the box. However, >>> the text support needs to be extracted out of Moz2D, and this is where the >>> patching scripts are used. The patches are there only for compilation >>> purposes and not for features and they are applied automatically. You can >>> see it here: >>> https://github.com/syrel/Moz2D >>> >>> Alex updated recently the Moz2D version and it worked without problems. >>> Of course, future changes in Moz2D might imply changes in this script as >>> well, and this implies that we will need to maintain that script. And we >>> could imagine applying these patches on the trunk of Moz2D to see if they >>> work, and we can also imagine engaging with the Moz2D owners to see if we >>> can find a middle ground. >>> >>> Now, letâs put this into perspective. We are currently using Athens and >>> the Cairo backend. While Cairo is provided as a standalone library it has >>> not seen significant advances since Mozzila shifted its focus towards >>> Moz2D. So, sticking with it might not be an ideal strategy either. >>> >>> Furthermore, just like Athens, Sparta is an abstraction that allows us >>> to switch the underlying backend should we need to. Until now we did not >>> find a cross-platform backend that is as advanced and complete as Moz2D, >>> but there is no reason to think that none other will appear in the future. >>> Skia is an alternative but it is only a vector graphic engine without text >>> support, so using it would imply to have another library for the text >>> support. >>> >>> Sparta also comes with a reasonable set of tests that is aimed at >>> testing the basic Moz2D functionality to make sure that the assumptions on >>> top of which Sparta is built are correct. >>> >>> All in all, I think that the current situation is not ideal, but there >>> is already enough engineering in place to actually make it work. And I >>> definitely think that the potential it opens is rather significant. >>> >>> And, if more people look at the scripts, we might find even better and >>> cheaper ways to express it. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "We cannot reach the flow of things unless we let go." >>> >>> >>> >>> >>> >>> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >>

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Chris Cunningham

On Thu, Jan 26, 2017 at 2:02 PM, stepharong <stepharong(a)free.fr> wrote: > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <astares(a)gmx.de> > wrote: > > ... > > >> 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. > > In other words, this is creating a constant inside the method (#asMethodConstant) instead of making the method return a constant (which would be your #asConstantMethod). If I have that right. In any case, not having the contracted 'Const' would be nice. -cbc > -- > Using Opera's mail client: http://www.opera.com/mail/ > >

Jan. 26, 2017

athens dead code?

by stepharong

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. -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by stepharong

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. > > Finding good names is really hardest part in programming... > > Thanks > T. > -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 26, 2017

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

by stepharong

My last mail on that topic Esteban told me that we should recompile the cairo lib with acceleration enabled. Now probably Mozz2d is the coolest techno right now. We read about Azure when Igor started to build athens. Athens was designed to make sure that when Cairo dies we do not have to rewritte everything. Stef On Thu, 26 Jan 2017 22:55:25 +0100, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Moz2D looks pretty great and the stateless argument makes sense. > > Furthermore there is an isolation layer. > Interesting reads: > https://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/ > > http://robert.ocallahan.org/2011/09/graphics-api-design.html > > https://wiki.mozilla.org/Platform/GFX/Moz2D > > https://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h > > Having browser grade speed views in a OSWindow is enabling. > > Cairo is not going to give us super speedy UIs, sorry, just check the > demos we have in the image, they are sluggish. > > Phil > > > > On Thu, Jan 26, 2017 at 10:27 PM, stepharong <stepharong(a)free.fr> wrote: >> >> >>> Hi, >>> >>> Then we will need Cairo + SDL2 (that does not work for us) >> >> I do not get why SDL20 would not work for us while it is used by gaming >> engines. Are we that special? >> We built interactive applications for Thales with complex event touch >> and now suddenly "it does not work for us" TM. >> I have the impression that each time I see Bloc we need something more >> special (now this is Gtk) >> To me it looks like it is a systematic "fuite en avant" with even more >> Mb consumption each time. >> Personally I do not care of blur and effects, or color max filters. >> Right now you do not even have a single example of something that is >> not a littledemo. >> >> Why we cannot have a tk/tcl or red-language like working system? I mean >> working now and not relyingon multiple MB of code extracted from an >> existing project? >> >>> + Freetype2 (for fonts) + Graphite (glyphs shaping technology in order >>> to use them within vector graphics engine) + cross platform OpenGL / >>> Vulkan context/device provider for hardware >>>acceleration + >>> implement Filters for effects (blur, lights, color matrix filters, >>> etc...). >>> >>> Without all those technologies bloc WILL progress, from 80's to 00's. >>> Still decades behind :) >> >> Well I would prefer to have something from the 00 working now that from >> 2016 not working. >> Because now what I will do is continuing to work on Morphic because >> this is what I have.You see I removed graphics from my future books. >> You probably do not care.In the future I will concentrate on anything >> else than graphics and widgets like that I will have no frustration. >> Hacking the compiler finally should be a lot nicer.You see next week I >> go to visit alain and I will not discuss nor work on such topics like >> that no frustration. >> Finally I will not comment anymore on Bloc anymore. I should not have. >> You do not seem to understand my point so I will shut up but years will >> pass before Bloc will be integrated in Pharo, becauseintegrated means >> maintained by us in case the guys behind bloc/brick get hired by >> anybody else on earth. >> >> You seem to underestimate that part. >> Ok you are super right and I'm super wrong. >> Stef >> >> >> > -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 26, 2017

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

by stepharong

On Thu, 26 Jan 2017 22:36:47 +0100, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Stef, > > There was a misunderstanding. Alex was just listing the need of > underlying technologies for the features that Bloc already supports. > > Letâs restart this conversation. He will send an explanatory email. I understood it correctly. I just took a maintenance cost evaluation position and to me this is not sustainable. Stef

Jan. 26, 2017