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

bloc readiness for a simple mindmap

by Peter Uhnak

Hi, I wanted to ask about Bloc: 1) how stable is the API? e.g. if some overhaul changes to unify/whatever are planned 2) I saw in the techtalk that you can align elements (to center, bottom, ...), however is that possible with lines? Lines have to rotate, morph shape, etc. 3) Are non-straight lines possible? (e.g. bezier, arc) The idea for me is to make a simple mindmap - elements with some text, icons, math symbols inside - connectors (non-straight lines) between elements To me (apart from the lines) it seems like it should be already doable. Also either my (Morphic) Pharo is really slow, or Bloc (in the video) is superfast (everything is happening instantly). Thanks, Peter

Jan. 27, 2017

Re: [Pharo-dev] Debugger layout again

by stepharong

Why can't we have a spec like message to set the configurations people like? > Hi again, > > there is still no way to change the debugger layout to have it the same > way as Mooseâ¦ Why did we change layout in Pharo in the first place? It > was so nice: you had the stack with the whole highlighting on the side, > so you could see more. > > Why do we have to make things unusable in Pharo? > Uko > > P.S. ok, ok, I guess I will just move to Moose. -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 27, 2017

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

by stepharong

I think that there is a key aspect in the story: Risk management. In addition I see the following problems: addition without removal. - if we integrate bloc in the future it means that we will have Athens for Morphic and the tools that we will use while developing the rest AND Sparta for the external window. Now I think that we should throw away Athens if it does not support the future scenario but have a Sparta-MorphicFriendly variation to replace Athens so that we can continue to work. I mean we CANNOT continue to stack libraries on the side of each others. Because it makes us super slow to move. This is also a part of risk management. Each time that we improve the **current** infrastructure we build a MILESTONE. If you want to go the everest you build intermediary camps in case of tempest you can rest there and restart. In Bloc and Brick I see no camp. Let us look at SDL and OS-Window. So now it is bad and terrible. If we do not do anything we will have MorphHand the ugly + SDL20 is not useful + OSWindow the stupid + GTK the great Come on this is not possible! If you do not prepare integration and milestone I can tell you that the integration will not happen. And your risk gets higher and higher. So far I did not see any roadmap and a roadmap should place such concerns on the table. For me having Bloc and Brick with horrible borders around the windows would be just perfect. And not having SVG support for hyper fancy morphs too. Let us think incrementally. Why we cannot have a scenario - Default and Simple - Advanced and risky where you load your mozz2d lib Stef PS: I agree with norbert.

Jan. 27, 2017

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

by Aliaksei Syrel

Hi I am very thankful to all participants in the discussion! Moz2D is not integrated in Pharo, it is an optional third party library that helped us to model and provide architectural support of a variety of features that were not possible with Morphic and are not possible with Cairo (or not so easy to do). It does not mean that we hate Morphic or dislike Cairo, it is just different :) I read all emails very carefully and clearly understand your fears. "What if he leaves?" "Do we want Esteban to maintain yet another VM related stuff? (because when something breaks he is almost the only one who can help, thanks!)" "Why is it 20Mb?!" The point is to find balance of pros and cons. Exactly as you wrote: more features => higher complexity => increase in costs => where to find fundings. I absolutely agree with the idea of having a "core" cheap backend that is easy to maintain and costs almost nothing. We are looking into a backend for Sparta based on Cairo. Bindings will be based on the latest stable cairo-1.14.8 ( https://www.cairographics.org/news/cairo-1.14.8) we will also add support of different surfaces including accelerated ones in order to be ready for compiled cairo with enabled acceleration. Cheers, Alex On 27 January 2017 at 12:36, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > On Jan 27, 2017, at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > (I was going to answer a big mail but my observations/concerns are > mostly targeted by Norbert and Stef) > > > >> On 27 Jan 2017, at 10:49, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi, > >> > >> Thanks for the detailed analysis. > >> > >> In summary, Cairo+Pango+SDL2 provide enough support to get a subset of > Sparta working that would be equivalent with the Athens that we already > have. In other words, with such a backend, when we would tell Sparta to use > a blur effect, it will simply do nothing and the image environment can > continue to work as it does now. > >> > >> I hope that everyone agrees that this is a reasonable fallback scenario > that we can count on. And I think this is in line with what Stef was saying > as well. > >> > >> With this in mind, we should also remember that the Moz2D backend works > now which means that we can now focus on Brick to close the loop and > provide a complete stack that more people can start utilizing, and we can > come back to the alternative backend later. > >> > >> Does this path to action address the worry related to the future of > Sparta backends? > > > > thanks Doruâ¦. I think having a base system that works in all scenarios > (even if we miss some features) and is easy to maintain is important. > > Ok, so this means that worry is addressed with this strategy. > > > > Then you can have a different backend for complex stuff (is more or less > the same about Ronieâs Woodenâ¦ I love to have the possibility of doing the > things Ronie do with that, but I would never target to build my UI system > on top of it). > > Of course, choosing a technology depends on the value that you want to > create with it. > > > > Even with this simplification, I would like to know why you choose to > strip a library from a project instead testing, for example Skia (I know, > Skia api is not stable, and is C++ and C bindings are still unstable), but > wellâ¦ others maybe. > > As I mentioned before, the stripping is only done for the text support > part, not for the vector graphics support that Skia also supports. The > Skia-equivalent part from Moz2D is compilable as is. > > > > And some precisions: > > > > - SDL2 do allow transparent windows and windows without decorations. > https://wiki.libsdl.org/SDL_SetWindowOpacity, > https://wiki.libsdl.org/SDL_CreateWindow (and the flags section) > > - Cairo do allow acceleration, we need to compile it with right backend. > > - I disagree is a dead technology. Instead, is a very mature > technologyâ¦ thatâs why forum is not too active (even if as far as I see, it > was never too active). Yes, maybe is not in the hype, but is cool and allow > us to do very nice things. > > - examples on images are slow because of how they are programmed, not > because of cairo :) > > Great points. It looks like we already have the right knowledge in-house > :). > > > > cheers! > > Esteban > > > > ps: instead ânot doing anythingâ non-suported-operations could throw a > notification (a silent one)? > > Sure. > > Doru > > > > >> > >> Cheers, > >> Doru > >> > >> > >> > >>> On Jan 26, 2017, at 11:45 PM, 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: > >>> â¢ Do we need Bloc or Morphic2 or %name your favourite framework%? > >>> â¢ How advanced and modern do you want it to be? > >>> â¢ What technology stack do we want to use for our new graphical > framework? > >>> â¢ What platforms and operating systems do we want to support? > >>> â¢ How flexible technology stack should be? (some parts may change > in the future) > >>> â¢ Who will pay for it? > >>> â¢ How many engineers can community afford? > >>> â¢ Do you know how much other systems invest in graphical > frameworks? > >>> â¢ 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: > >>> â¢ Vector graphics library to render shapes (fill, stroke, path > builder, composition and blending operators) > >>> â¢ Font service library (to support different font formats and > collect information about local fonts installed in the system) > >>> â¢ Text layout engine (this is where glyph positioning magic > happens, link above too) > >>> â¢ Text shaping engine (for high quality text rendering, to > understand the problem => http://behdad.org/text/) > >>> â¢ Complex script library (to support ligatures, split glyphs and > other UTF8 stuff, remember https://github.com/minimaxir/b > ig-list-of-naughty-strings) > >>> â¢ Image processing library (for various image effects, like > gaussian blur, morphology filter, gamma, displacement map, just to name a > few) > >>> â¢ Hardware acceleration. Software rendering is nice, however, > modern UIs are full of fancy stuff that require hardware acceleration. > >>> â¢ Window and Event management library. With support of borderless > and semi-transparent windows + good support of touchpad. > >>> â¢ 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. > >>> â¢ Make the whole beast cross platform. > >>> > >>> Did I miss something? > >>> > >>> Here are some modern technologies commonly used for mentioned parts: > >>> â¢ Skia, Direct2D, CoreGraphics, Cairo > >>> â¢ Fontconfig, Freetype2 > >>> â¢ HarfBuzz > >>> â¢ Pango, OpenType > >>> â¢ Graphite2, FriBidi > >>> â¢ Imagemagic, SVG filters libraries > >>> â¢ Vulkan, OpenGL > >>> â¢ wxWidgets, QT, GTK, SDL2 > >>> â¢ todo > >>> â¢ 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/Platform/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/ > >>> > >>> > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Every thing should have the right to be different." > > -- > www.tudorgirba.com > www.feenk.com > > "Presenting is storytelling." > > >

Jan. 27, 2017

Re: [Pharo-dev] memoized vs once

by Dimitris Chloupis

> Hmm. Our language doesn't have method variables, either - class > variables, instance variables, and temp variables (among others). > > Maybe this should be called 'asTempConstant' ? (although a 'temporary > constant' sound really, really weird...) > > -cbc > Indeed , "temp variables" is what is named. I do not think we have to include "constant". There are other ways to express something that does not change. maybe "asReadOnlyTempVariable" or "asImmutableTempVariable" ?

Jan. 27, 2017

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

Now we have integrated case 19613 <https://pharo.fogbugz.com/f/cases/19613/> with VisualWorks names. But I propose better names 19614 <https://pharo.fogbugz.com/f/cases/19614/Better-names-for-NoModificationErro…>. It would be nice if you put some notes about it (at issue page). 2017-01-26 22:39 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Guess the method is wrong given the comment. > > Shouldn't it be [param anyMask: 1] instead of [param anyMask: 2] ? > > Phil > > On Wed, Jan 25, 2017 at 2:14 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> I introduced the method #supportsWriteBarrier in Pharo 6. >> >> You can backport it if you want: >> >> VirtualMachine>>#supportsWriteBarrier >> "Answer whether the VM observes the per-object read-only flag and >> consequently >> aborts writes to inst vars of, and fails primitives that attempt to >> write, to read-only objects." >> >> ^(self parameterAt: 65) >> ifNil: [false] >> ifNotNil: >> [:param| "In older VMs this is a boolean reflecting >> MULTIPLE_BYTECODE_SETS" >> param isInteger "In newer VMs it is a set of integer flags, bit 1 of >> which is IMMUTABILITY" >> ifTrue: [param anyMask: 2] >> ifFalse: [false]] >> >> >> >> On Wed, Jan 25, 2017 at 2:06 PM, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> >>> The "latest" Windows VM I do use has no such method. >>> >>> Virtual Machine >>> --------------- >>> C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\la >>> testvm\pharo.exe >>> CoInterpreter * VMMaker.oscog-eem.2090 uuid: >>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017 >>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: >>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017 >>> VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date: >>> Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442 >>> https://github.com/pharo-project/pharo-vm.git $ >>> >>> Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0 >>> VMMaker versionString VM: 201701151442 https://github.com/pharo-proje >>> ct/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins: >>> 201701151442 https://github.com/pharo-project/pharo-vm.git $ >>> CoInterpreter * VMMaker.oscog-eem.2090 uuid: >>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017 >>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: >>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017 >>> >>> [image: Inline image 1] >>> >>> >>> On Wed, Jan 25, 2017 at 1:54 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <norbert(a)hartl.name> >>>> wrote: >>>> >>>>> Does anyone know the state of immutability support in vm and image? >>>>> The latest vm downloadable is compiled with >>>>> >>>>> IMMUTABILITY=1 >>>>> >>>>> (Esteban said that). When I open a pharo6 image with this VM and do: >>>>> >>>>> ASUser new >>>>> setIsReadOnlyObject: true; >>>>> name: 'foo' >>>>> >>>>> with >>>>> >>>>> ASUser>>#name: arg1 >>>>> name := arg1 >>>>> >>>>> I don't get an exception. Is there something missing or am I not >>>>> understanding? >>>>> >>>> >>>> Hi Norbert, >>>> >>>> Thank you very much for looking read-only objects. >>>> >>>> When mutating an instance variable, the VM triggers a call-back that by >>>> default does nothing. In your case, running your code does not raise an >>>> exception but the object should not be modified either. If you want an >>>> exception, you need to change the call-back code, i.e., the method >>>> Object>>#attemptToAssign: value withIndex: index. For example, you could >>>> write: >>>> >>>> Object>>#attemptToAssign: value withIndex: index >>>> | process | >>>> self notify: 'object changed !'. >>>> process := Processor activeProcess. >>>> [ process suspendedContext: process suspendedContext sender ] forkAt: >>>> Processor activePriority + 1. >>>> Processor yield. >>>> >>>> Then, your code should open a notification window with 'object >>>> changed', and proceeding keeps running the code without mutating the object. >>>> >>>> One needs to build a ModificationTracker framework on top of the VM >>>> support I introduced. Multiple things are required, like default behavior >>>> in this call-back and in primitive failure code. I am willing to support >>>> and help anyone willing to build such a framework, but I won't build it >>>> myself. >>>> >>>> If you have any other questions or if you find bug don't hesitate to >>>> ask further questions >>>> >>>> Best, >>>> >>>> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your >>>> system, if this is not the case it means the VM does not support read-only >>>> objects. >>>> >>>> Clement >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Norbert >>>>> >>>> >>>> >>> >> >

Jan. 27, 2017

Re: [Pharo-dev] HandMorph>>#processEvents

by Denis Kudriashov

There is issue 19388 <https://pharo.fogbugz.com/f/cases/19388/MouseEnter-and-MouseLeave-are-trigg…> . According to Henrik problem is related to Morphic logic and not to window management. 2017-01-27 8:15 GMT+01:00 stepharong <stepharong(a)free.fr>: > Probably a bug. > I started to clean this part 4 years ago and my changes got killed by SDL > + OS Window and > now apparently SDL 20 is not good enough. > May be in 3 years from now it will be cleaned, who knows. > > Stef > > 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 > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ >

Jan. 27, 2017

Re: [Pharo-dev] memoized vs once

by Chris Cunningham

On Fri, Jan 27, 2017 at 7:12 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > 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.. >> :) >> >> > I think that C++ tries to avoid this confusion by not using "method" for > the members of a method, so for example it does not define variables inside > a method as "method variables" but rather "local variables" so AFAIK C++ > has "constant method" as a method that is not allowed to change but it does > not have or at least I have not seen "method constant' as a variable > inside a method that does not change but rather refers to it as "method's > local constant variable" while "constant" alone is implying "global > constant variable". > > In case C++ did define as you said the confusion would extend even more > to what you mention because "method constant" would imply a method local > constant variable and not a return type. > > As Python zen's states "its better to be explicit than implicit" . Sure > long names take more time to type(unless you use auto completion) but they > avoid such confusions and the need to take a look at the documentation. > Hmm. Our language doesn't have method variables, either - class variables, instance variables, and temp variables (among others). Maybe this should be called 'asTempConstant' ? (although a 'temporary constant' sound really, really weird...) -cbc

Jan. 27, 2017

Re: [Pharo-dev] memoized vs once

by Dimitris Chloupis

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.. > :) > > I think that C++ tries to avoid this confusion by not using "method" for the members of a method, so for example it does not define variables inside a method as "method variables" but rather "local variables" so AFAIK C++ has "constant method" as a method that is not allowed to change but it does not have or at least I have not seen "method constant' as a variable inside a method that does not change but rather refers to it as "method's local constant variable" while "constant" alone is implying "global constant variable". In case C++ did define as you said the confusion would extend even more to what you mention because "method constant" would imply a method local constant variable and not a return type. As Python zen's states "its better to be explicit than implicit" . Sure long names take more time to type(unless you use auto completion) but they avoid such confusions and the need to take a look at the documentation.

Jan. 27, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60362 Home: https://github.com/pharo-project/pharo-core

Jan. 27, 2017