May 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] StampClient produce only and dealing with heartbeat

by Sven Van Caekenberghe

Hi Holger, Thanks for using Stamp, your feedback and off-list improvements. This is really important. Here are some general answers to the questions you asked. First: I have not yet used a producer only scenario, in a real system. Your questions are very valid, basically you/we have to figure out how to best do this. As you are probably aware (and contrary to the fact that the protocol looks a lot like HTTP), the protocol is asynchronous, with independent reading and writing and interleaved messages. This is harder to deal with. My idea with the current implementation is that I want to separate the pure protocol (reading/writing frames from/on a medium) from the handling logic and especially from the multiprocessing logic. I want the main code base to be free of locks and extra threads - a pure single threaded event handling loop should remain possible. What I have currently running in production (reliably over days/weeks) is what can be seen in StampClient>>#runWith: The idea is that you keep on reading in a loop with a short timeout. This loop handles the heartbeat and maintains an inbox. It is still free of multithreading code or locks - these need to be added by users of the API in the block. I would guess that your scenario needs a similar mechanism. However, you need a regular opportunity to send something out. Thinking out loud, what about something like StampClient>>#runWith: receiveBlock do: sendBlock where receiveBlock is like it is now, and sendBlock is called regularly, basically when the loop goes through another cycle, to give you the opportunity to send something, being sure to have exclusive access. In the sendBlock you could query your sharedQueue that is being filled by another process, properly MP safe. The invocation of #runWith:do: should of course be forked. Does that make sense ? Sven > On 18 May 2016, at 16:10, Holger Freyther <holger(a)freyther.de> wrote: > > Dear Sven, > > I started to use the StampClient and intend to use it to produce data but for heartbeat and other parts I need to read from the socket as well. I wonder about the best strategy to deal with it. > > The naive approach. > > > [ > | event sendFrame | > event := sharedQueue next. > sendFrame := self newSendFrameTo: queueName > sendFrame text: event convertToText. > stampClient write: sendFrame. > ] fork. > > > But now the StampClient enforces a non-zero hearbeat.. so I could write something like this > > [ > | event sendFrame | > event := sharedQueue nextWaitFor: stampClient timeout * 3. > event isNil > ifTrue: [stampClient writeHeartBeat] > ifFalse: [self convertAndSendEvent: event]. > ] fork. > > > But now I face the issue (but maybe I had it before as well) that the server will itself send an empty frame as its heartbeat function and I need to read it. So I could write... > > [ > event := sharedQueue... > "try to read all pending events? How often to repeat it read everything??" > stampClient readNextFrame. > ... > ] fork > > > > Or to make it more involved? And create a reader and writer? > > procConsume := [ > [stampClient runWith: [:msg | " do nothing " ]] ifCurtailed: [connectionClosed...handling]. > ] fork. > > procProduce := [ > [ > | event sendFrame | > event := sharedQueue next. > sendFrame := self newSendFrameTo: queueName > sendFrame text: event convertToText. > stampClient write: sendFrame. > ] ensure: [procConsume... do what exactly? > ] fork. > > So the last options seems to be the best. But how to deal with with re-connects? How to not have have "procConsume" write the heartbeat data in the middle of the produced event? After all > > How did you solve that? Is the problem space clear enough? > > > holger > >

May 19, 2016

Re: [Pharo-users] Retina support in Pharo

by Tudor Girba

Thanks for this point of view. Just to put a bit of perspective. Indeed, first impressions do count, and now we start to be able to address this part. It took a long time to be able to get to this point, and until now most of the efforts were internal facing (new compiler, new debugger, new VM, new UFFI etc). We are still not in polishing mode, though. We still have internal pieces to fit together (like 64 bit, Sista, image changes management and some others) and we still need a more flexible UI part (which is what the Bloc effort is about). Especially with Bloc, we are approaching the surface, and I strongly believe the future changes will have more visible effects. Cheers, Doru > On May 18, 2016, at 3:39 PM, J.F. Rick <self(a)je77.com> wrote: > > My guess is that retina support through Athens rendering and 64-bit are critical to greater adoption of Pharo for several reasons: > (1) First impressions matter greatly. If I try to get someone into Pharo and the first thing they see is a pixelated screen, they will have an immediate bad reaction. My students believed that Pharo was a toy language because of the pixelated rendering. Even when I explained why, I'm not sure they believed me (sure, prof, we believe you). The interface being slow also gives the impression that the entire system is slow. So, speed improvements from Spur are less tangible. For most newcomers, interface speed = system speed. > (2) One of the first things newcomers will want to do with a new system is some sort of graphical user interface. Pharo's morphic is quite nice but the BitBlt rendering is off putting. So, even if newcomers buy that there are reasons for the rendering being not great, they will likely conclude that it isn't a system for them. > (3) The vast majority of OSes are 64-bit and 32-bit packages are getting deprecated. So, even if there are nice ways to interface with the outside world, they are being held back. So, very small things, like sound on Ubuntu, don't work. It's not really worth fixing that until Pharo is 64-bit. Again, it looks like Pharo is behind the curve, rather than ahead of it. > > Now, that stated, I understand why things are the way they are. There are limited resources and there are things that take priority. In addition, there is the tension between Pharo as an engine for research ideas (roughly equates to the things where Pharo is ahead of the curve) and Pharo as a general purpose environment (most notable in places where Pharo is behind the curve). > > Pharo5 is a major accomplishment and I am excited by it. It is awesome what was accomplished. I have faith in the leadership in setting priorities and great appreciation for those putting in the time. My point in posting this is not to criticize past development or priorities but just to make the case that these two things on the horizon (retina support, 64-bit) are important to my use of Pharo and how newcomers will view the system. I wish I could contribute but the VM things are out of my zone of competence. > > Cheers, > > Jeff > > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

May 19, 2016

Re: [Pharo-users] GLMFormatedPresentation>>format bug?

by Alistair Grant

Hi Tudor, On Wed, May 18, 2016 at 09:26:51AM +0200, Tudor Girba wrote: > Hi, > > > On May 16, 2016, at 7:59 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > On Mon, May 16, 2016 at 05:42:54AM +0200, Tudor Girba wrote: > > > > ... > >> It works because the format block takes an optional argument with the input > >> entity. However, the semantics are not going to be quite the same. In > >> isolation, the behavior will be identical. However, the difference comes when > >> you try to reuse a presentation. > >> > >> Letâs look at an example. This is how an AST node displays the source: > >> > >> RBProgramNode>>gtInspectorSourceCodeIn: composite > >> <gtInspectorPresentationOrder: 30> > >> ^ composite pharoMethod > >> title: 'Source codeâ; > >> display: [ self source ]; > >> ... > >> > >> Like this, the block closure can simply delegate to the corresponding ast node > >> to display the source: > >> > >> BlockClosure>>gtInspectorSourceCodeIn: composite > >> <gtInspectorPresentationOrder: 40> > >> self sourceNode gtInspectorSourceCodeIn: composite > >> > >> And a keymap object which holds a block in an action instance variable, can > >> simply delegate to the block closure object to display the source: > >> > >> KMKeymap>>gtInspectorSourceCodeIn: composite > >> <gtInspectorPresentationOrder: 30> > >> ^ self action gtInspectorSourceCodeIn: composite > >> > >> > >> If the ProgramNode definition would have been implemented like: > >> display: [ :each | each source ] > >> > >> then when inspecting the block object, we would have gotten the block object as > >> each, and not the AST node. > >> > >> Does this explanation make sense? > > > > So using this code is going to be more flexible than > > > > ^ composite text > > title: 'Meme'; > > format: [self asText] > > > > since the format object isn't supplied the optional arguments. > > Actually, the less flexible approach is: > format: [ :each | each source ] > > Given that you define the extension directly in the class of the object you want to inspect, you essentially always want to apply the transformations on self, regardless of the âeachâ block argument. In this way, you can reuse this presentation in other objects through delegation like I mentioned above. > > In any case, I am happy to hear that you want to extend you object. Could you let us know the use case? I'm porting my personal note taking system that I originally developed in Python / Django about 5 years ago to Pharo. The main entity is what I call a "meme", which simply has a name, label and description. Any number of attachments may be added, e.g. URLs, links to external files, internally managed files, etc. Meme's are related to each other as parents / children or peers. The approach I'm taking is to be able to view each of the objects in the standard Pharo inspectors, so for a meme its' name, label and description are displayed as formatted text with clickable links (thus the question that started this thread), relations to other memes are displayed in a RTMondrian force graph (at the moment). Being able to inspect the objects obviously helps with the debugging and gives the system a live / exploratory feel. Once that is working, I'll start on a more custom interface which will be more practical for actual note taking. Does that answer your question? Cheers, Alistair

May 18, 2016

Re: [Pharo-users] Downloading large files with a progress bar

by Offray Vladimir Luna CÃ¡rdenas

Hi, This is the code that finally did it: http://ws.stfx.eu/458U3WRKXAW1. I was really puzzled by the progress bar not being updated despite of the download being made (it took me several days to find what happen!). The thing is that the total size of the file was not being delivered by the datahub.io site, so there was no way to put it into the progress bar. I used an alternative approach reading the actual size against the total expected size (once you know the cause the solution took me a couple of hours, mostly learning about SystemProgressBar and JobProgressBar, the actual script took minutes.). Thanks Sven and Johan for helping me to figure this out. Cheers, Offray On 13/05/16 00:35, Sven Van Caekenberghe wrote: > When the UI thread is really busy, updating the UI can be problematic. > > An extra fork seems to help: > > (FileLocator temp / 'PharoV30.sources') ensureDelete. > > [ [ :bar | > bar title: 'Downloading Sources...'. > [ > ZnClient new > url: 'http://files.pharo.org/sources/PharoV30.sources'; > signalProgress: true; > downloadTo: FileLocator temp ] > on: HTTPProgress > do: [ :progress | > progress isEmpty ifFalse: [ bar current: progress percentage ]. > progress resume ] ] asJob run ] fork. > >> On 13 May 2016, at 01:00, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> >> Hi Sven, >> >> Thanks for your quick answer. I tried both approaches but I'm missing something. See my last attempt at http://ws.stfx.eu/KBVBAP72IWOO with the last one. I get a progress bar message, but not the advancements on it. What I'm missing? >> >> Cheers, >> >> Offray >> >> ps: The file I'm trying to download is covered by the Open Data Base License. >> >> On 12/05/16 17:24, Sven Van Caekenberghe wrote: >>> Hi Offray, >>> >>> The actual implementation of #saveContentsToFile: can be found in ZnHttpSaveContentsToFile>>#performOperation where you can see how ZnClient is invoked. Just copy that with signalProgress: true added and you should be good. >>> >>> Alternatively, you could wrap the first expression as follows: >>> >>> ZnSignalProgress >>> value: true >>> during: [ myUrl asUrl saveContentsToFile: file ] >>> >>> ZnSignalProgress is a DynamicVariable that is used by ZnClient to figure out if progress should be signalled. It takes precedence over the option #signalProgress. See #withProgressDo: if you are interested. >>> >>> HTH, >>> >>> Sven >>> >>>> On 13 May 2016, at 00:14, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>>> >>>> Hi, >>>> >>>> I'm using >>>> >>>> myUrl asUrl saveContentsToFile: file >>>> >>>> to download large files and is working fine. But I would like to add a progress bar to show the progress to the user. Previously I used >>>> >>>> =============== >>>> [: bar | >>>> bar title: aString. >>>> [ >>>> "A classical ZnClient download with signalProgress: true;" >>>> ] >>>> on: HTTPProgress >>>> do: [ :progress | >>>> progress isEmpty ifFalse: [ bar current: progress percentage ]. >>>> progress resume ]. >>>> ] asJob run. >>>> =============== >>>> >>>> but I don't know how to signal progress with "saveContentsToFile". >>>> >>>> Any hints? >>>> >>>> Thanks, >>>> >>>> Offray >>>> >>> >> >

May 18, 2016

Scrollable Spec Model

by Peter UhnÃ¡k

Hi, anyone has any experience with scrollable (arbitrary) Spec Model? e.g. I have a long list of buttons and fixed outer container windowâ¦ â As far as I can see scrolling is only available on morphic side, so I am not sure how to augment itâ¦ (Although we should probably allow scrolling on Spec side in some way) Thanks, Peter

May 18, 2016

Re: [Pharo-users] Retina support in Pharo

by CÃ©drick BÃ©ler

Hereâs a screenshot on a 5K iMac. Reading a Â« retina Â» pdf in background just to compare. Ok itâs a bit pixelated but I can notice it only if Iâm 20cm from the screen (usually Iâm 60cm). So perfectly usable. Of course retina support will give a sharper Â« look Â» but itâs not that important to me (to be honest I just realized it was pixelated when reading the post). Cheers, CÃ©drik

May 18, 2016

StampClient produce only and dealing with heartbeat

by Holger Freyther

Dear Sven, I started to use the StampClient and intend to use it to produce data but for heartbeat and other parts I need to read from the socket as well. I wonder about the best strategy to deal with it. The naive approach. [ | event sendFrame | event := sharedQueue next. sendFrame := self newSendFrameTo: queueName sendFrame text: event convertToText. stampClient write: sendFrame. ] fork. But now the StampClient enforces a non-zero hearbeat.. so I could write something like this [ | event sendFrame | event := sharedQueue nextWaitFor: stampClient timeout * 3. event isNil ifTrue: [stampClient writeHeartBeat] ifFalse: [self convertAndSendEvent: event]. ] fork. But now I face the issue (but maybe I had it before as well) that the server will itself send an empty frame as its heartbeat function and I need to read it. So I could write... [ event := sharedQueue... "try to read all pending events? How often to repeat it read everything??" stampClient readNextFrame. ... ] fork Or to make it more involved? And create a reader and writer? procConsume := [ [stampClient runWith: [:msg | " do nothing " ]] ifCurtailed: [connectionClosed...handling]. ] fork. procProduce := [ [ | event sendFrame | event := sharedQueue next. sendFrame := self newSendFrameTo: queueName sendFrame text: event convertToText. stampClient write: sendFrame. ] ensure: [procConsume... do what exactly? ] fork. So the last options seems to be the best. But how to deal with with re-connects? How to not have have "procConsume" write the heartbeat data in the middle of the produced event? After all How did you solve that? Is the problem space clear enough? holger

May 18, 2016

Re: [Pharo-users] Retina support in Pharo

by J.F. Rick

My guess is that retina support through Athens rendering and 64-bit are critical to greater adoption of Pharo for several reasons: (1) First impressions matter greatly. If I try to get someone into Pharo and the first thing they see is a pixelated screen, they will have an immediate bad reaction. My students believed that Pharo was a toy language because of the pixelated rendering. Even when I explained why, I'm not sure they believed me (sure, prof, we believe you). The interface being slow also gives the impression that the entire system is slow. So, speed improvements from Spur are less tangible. For most newcomers, interface speed = system speed. (2) One of the first things newcomers will want to do with a new system is some sort of graphical user interface. Pharo's morphic is quite nice but the BitBlt rendering is off putting. So, even if newcomers buy that there are reasons for the rendering being not great, they will likely conclude that it isn't a system for them. (3) The vast majority of OSes are 64-bit and 32-bit packages are getting deprecated. So, even if there are nice ways to interface with the outside world, they are being held back. So, very small things, like sound on Ubuntu, don't work. It's not really worth fixing that until Pharo is 64-bit. Again, it looks like Pharo is behind the curve, rather than ahead of it. Now, that stated, I understand why things are the way they are. There are limited resources and there are things that take priority. In addition, there is the tension between Pharo as an engine for research ideas (roughly equates to the things where Pharo is ahead of the curve) and Pharo as a general purpose environment (most notable in places where Pharo is behind the curve). Pharo5 is a major accomplishment and I am excited by it. It is awesome what was accomplished. I have faith in the leadership in setting priorities and great appreciation for those putting in the time. My point in posting this is not to criticize past development or priorities but just to make the case that these two things on the horizon (retina support, 64-bit) are important to my use of Pharo and how newcomers will view the system. I wish I could contribute but the VM things are out of my zone of competence. Cheers, Jeff

May 18, 2016

Re: [Pharo-users] Get a String during the execution

by Julien Delplanque

No problem. :-) ++ Julien On 18/05/16 15:12, Valentin Ryckewaert wrote: > Hello julien, > > cyril helped me i'm using UIManager default textEntry: 'Type something'. > and it's exactly what I was looking for ! > > Thanks you for your answer, i'll check openModal anyway ! :) > > Valentin > > 2016-05-18 15:05 GMT+02:00 Julien Delplanque <julien(a)tamere.eu>: > >> Hello Valentin, >> >> You should check the World>>#openModal: message. >> >> I think this is what you are looking for. :-) >> >> Regards, >> >> Julien >> >> >> On 18/05/16 14:08, Valentin Ryckewaert wrote: >> >>> Hi ! >>> >>> I'm trying to make a method able to ask the user to write something which >>> will be used in the method. >>> During my method execution, a pop up appear on the screen, the user write >>> anything 'test' for exemple, and then the method continue using this >>> string. >>> >>> The code looks like this: >>> MyClass>>dostuff >>> mypopup := MyPopup new. >>> mypopup openDialogWithSpec. >>> mypopup window okAction: [ date := mapop input text. dostuff with the >>> variable date ]." >>> >>> And then I execute this method: >>> MyClass new dostuff. >>> SessionManager default snapshot: false andQuit: true (To close Pharo) >>> >>> The problem is that the method dostuff wait the proc of the popup to make >>> what is in the bloc but continue execution and close Pharo. >>> I would like to be able to stop execution of the code just after mypopup >>> window okAction and to reactivate it in the bloc executed when it's proc. >>> Is it possible? >>> >>> Valentin >>> >>> >>

May 18, 2016

Re: [Pharo-users] Get a String during the execution

by Valentin Ryckewaert

Hello julien, cyril helped me i'm using UIManager default textEntry: 'Type something'. and it's exactly what I was looking for ! Thanks you for your answer, i'll check openModal anyway ! :) Valentin 2016-05-18 15:05 GMT+02:00 Julien Delplanque <julien(a)tamere.eu>: > Hello Valentin, > > You should check the World>>#openModal: message. > > I think this is what you are looking for. :-) > > Regards, > > Julien > > > On 18/05/16 14:08, Valentin Ryckewaert wrote: > >> Hi ! >> >> I'm trying to make a method able to ask the user to write something which >> will be used in the method. >> During my method execution, a pop up appear on the screen, the user write >> anything 'test' for exemple, and then the method continue using this >> string. >> >> The code looks like this: >> MyClass>>dostuff >> mypopup := MyPopup new. >> mypopup openDialogWithSpec. >> mypopup window okAction: [ date := mapop input text. dostuff with the >> variable date ]." >> >> And then I execute this method: >> MyClass new dostuff. >> SessionManager default snapshot: false andQuit: true (To close Pharo) >> >> The problem is that the method dostuff wait the proc of the popup to make >> what is in the bloc but continue execution and close Pharo. >> I would like to be able to stop execution of the code just after mypopup >> window okAction and to reactivate it in the bloc executed when it's proc. >> Is it possible? >> >> Valentin >> >> > >

May 18, 2016