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

Do you think VersionBrowser is counterintuitive?

by Denis Kudriashov

Hi. I always catch myself that I am completely lost in method versions (and feel pain :)). There is no clue what at the left pane and what at the right pane. Now I realize that VersionBrowser is trying to compare selected version versus next version (according to list order). So right pane shows selected version and left pane shows next one. For me all of these is super non intuitive but maybe it is only my problem. So here I want to ask about your experience. Do you feel same? I would prefer if VersionBrowser will always compare selected version versus current version in image with actual image version on the left and selected version on the right. What you think? Best regards, Denis

Dec. 23, 2016

Re: [Pharo-dev] [Pharo-users] Pharo 5 and retina displays in 2016?

by Tim Mackinnon

Thanks for the update - that is exciting and gives me some hope. What do we need to do to help bloc advance at pace? Tim Sent from my iPhone > On 23 Dec 2016, at 01:22, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi Tim, > > itâs coming, but it needs some time: https://twitter.com/aliakseisyrel/status/812065956856025088 > >> On 1 Dec 2016, at 14:44, Tim Mackinnon <tim(a)testit.works> wrote: >> >> To give people a better view of this - here is the Pharo image next to the mail client (Iâm not sure if the screen captures really do it justice as when you scale them down in a picture everything looks fine - however if I zoom into that bottom corner in a second image it might make it more obvious). >> >> I think this has been a problem brewing for a while, but if most contributors donât have retina screens (although they are getting much more common now) then I guess it goes unnoticed. I suspect in the next few years, as people start replacing machines - it will gain more visibility. >> >> I find it quite distracting when switching from mail or other apps to Pharo and then you notice the fuzziness. Maybe if you spend a few hours in the code you might adjust. >> >> Tim >> >> >> >> The following is the bottom corner zoom in to show what I mean by fuzzy: >> >> >> <PastedGraphic-2.png> >>> On 30 Nov 2016, at 23:53, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>>> On 30/11/16 20:32, Sven Van Caekenberghe wrote: >>>> Maybe, but the thing is, you are looking at it half size, in some >>>> sense, when it is on a Retina display. Anyway, to me, it is OK, but >>>> my eyes are no longer what they used to be. I can imagine young >>>> people being more sensitive to it. >>> >>> Nah, it just is blurry. I've played a bit with krono's vm, and it is >>> a very noticable difference. Much better readable and less tiring. >>> And you mostly only notice when trying to go back from HiDPI to low. >>> >>> Stephan >

Dec. 23, 2016

Re: [Pharo-dev] [Pharo-users] Pharo 5 and retina displays in 2016?

by Stephan Eggermont

On 23/12/16 01:22, Yuriy Tymchuk wrote: > itâs coming, but it needs some > time: https://twitter.com/aliakseisyrel/status/812065956856025088 That is nice, and a different solution. The needed changes were very limited, stability problems might have been resulting from gc during bitblit. Stephan

Dec. 23, 2016

Re: [Pharo-dev] [Pharo-users] Pharo 5 and retina displays in 2016?

by Yuriy Tymchuk

Hi Tim, itâs coming, but it needs some time: https://twitter.com/aliakseisyrel/status/812065956856025088 > On 1 Dec 2016, at 14:44, Tim Mackinnon <tim(a)testit.works> wrote: > > To give people a better view of this - here is the Pharo image next to the mail client (Iâm not sure if the screen captures really do it justice as when you scale them down in a picture everything looks fine - however if I zoom into that bottom corner in a second image it might make it more obvious). > > I think this has been a problem brewing for a while, but if most contributors donât have retina screens (although they are getting much more common now) then I guess it goes unnoticed. I suspect in the next few years, as people start replacing machines - it will gain more visibility. > > I find it quite distracting when switching from mail or other apps to Pharo and then you notice the fuzziness. Maybe if you spend a few hours in the code you might adjust. > > Tim > > > > The following is the bottom corner zoom in to show what I mean by fuzzy: > > > <PastedGraphic-2.png> >> On 30 Nov 2016, at 23:53, Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: >> >> On 30/11/16 20:32, Sven Van Caekenberghe wrote: >>> Maybe, but the thing is, you are looking at it half size, in some >>> sense, when it is on a Retina display. Anyway, to me, it is OK, but >>> my eyes are no longer what they used to be. I can imagine young >>> people being more sensitive to it. >> >> Nah, it just is blurry. I've played a bit with krono's vm, and it is >> a very noticable difference. Much better readable and less tiring. >> And you mostly only notice when trying to go back from HiDPI to low. >> >> Stephan >> >> >

Dec. 23, 2016

Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?

by Ben Coman

http://car.mines-douai.fr/category/pharos/ https://pleiad.cl/research/software/lrp cheers -ben On Fri, Dec 23, 2016 at 4:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi, > > i wonder, are there any projects to run/connect Pharo with ROS(robot > operating system) > i'm interested in any bits, starting from basic ones, > since i'm gonna to work with it in closest future, so would be nice to use > Pharo > & stand on a shoulders of others, of course, to learn it fester and > understand it better. > > -- > Best regards, > Igor Stasenko. >

Dec. 23, 2016

Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?

by ClÃ©ment Bera

Hi Igor. People at Mines de douai were working on Pharo with ROS. Contact Luc Fabresse or Noury Bouraqadi, people like Santiago, Guillermo polito or Nick Papoulias may also be aware of the work. I don't know what was done exactly. Have fun. On Thu, Dec 22, 2016 at 9:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi, > > i wonder, are there any projects to run/connect Pharo with ROS(robot > operating system) > i'm interested in any bits, starting from basic ones, > since i'm gonna to work with it in closest future, so would be nice to use > Pharo > & stand on a shoulders of others, of course, to learn it fester and > understand it better. > > -- > Best regards, > Igor Stasenko. >

Dec. 22, 2016

Q: any work around ROS has been done on Pharo?

by Igor Stasenko

Hi, i wonder, are there any projects to run/connect Pharo with ROS(robot operating system) i'm interested in any bits, starting from basic ones, since i'm gonna to work with it in closest future, so would be nice to use Pharo & stand on a shoulders of others, of course, to learn it fester and understand it better. -- Best regards, Igor Stasenko.

Dec. 22, 2016

Re: [Pharo-dev] MQTT for Pharo

by Sven Van Caekenberghe

Back on topic, MQTT, I added more/better functional units tests and more comments, as well as variants against a local broker. Here is a more complete example: "Fork a process that reads 10 temperature sensor values" [ (Array streamContents: [ :stream | | count | count := 1. MQTTExperimentalClient new clientId: 'listener'; open; subscribeToTopic: '/device/42/outside-temperature'; runWith: [ :message | stream nextPut: message contents asInteger. (count := count + 1) > 10 ifTrue: [ ConnectionClosed signal ] ] ]) inspect ] fork. "Post 10 temperature sensor value readings, using a new client/connection each time" 1 to: 10 do: [ :i | MQTTExperimentalClient new atLeastOnce; open; sendMessage: i asByteArray toTopic: '/device/42/outside-temperature'; close ] Sven > On 21 Dec 2016, at 21:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 21 Dec 2016, at 18:19, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> >>> On 21 Dec 2016, at 16:52 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> On 21 Dec 2016, at 16:04, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>> >>>>> >>>>> On 21 Dec 2016, at 14:57 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> Hendrik, >>>>> >>>>> Thank you for this detailed feedback. >>>>> >>>>>> On 21 Dec 2016, at 12:44, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>>>> >>>>>> Hi Sven! >>>>>> One thing I noticed when testing the RabbitMQ client with keepalive > 0, was connection being closed and all subscriptions lost when receiving large payloads, due to timeout before the keepalive packet could be sent before waiting to receive next object. >>>>> >>>>> Indeed, I used my Stamp (STOMP) Rabbit MQ client as a model for the MQTT one - there is a lot of similarity, especially in concept. >>>>> >>>>> Keep alive processing is not that easy. I tried to do it by using read timeouts as a source of regular opportunities to check for the need to process keep alive logic. But of course, if you have no outstanding read (in a loop), that won't work. >>>>> >>>>> The fact that receiving a large payload would trigger an actual keep alive time out is not something that I have seen myself. It seems weird that the reading/transferring of incoming data would not count as activity against keep alive, no ? >>>> >>>> I never had a chance to investigate fully, but I distinctly remember having the same reaction! >>>> It's quite awhile ago now, so my memory might be hazy, take the following with an appropriate amount of grains of salt. >>>> >>>> The first times I encountered it, it seemed quite random, occuring after extended periods of client inactivity after receiving only small payloads... >>>> Setting a much shorter keepalive timeout than the default was/is very useful in reproducing/verifying if it is an issue. >>>> The timeouts then occurred relatively shortly after I'd received a single payload with no other activity, and disappeared once I removed the resetting of lastActivity timestamp on reads, indicating that for at least rabbitmq (3.5 was the version at the time, I believe), receiving data was *not* being counted as keep-alive activity. >>>> >>>> The issue of receiving large payloads blocking writing in time was still unresolved, consistently cut off in the middle of (its own!) multi-MB payload transfers due to keepalive packet not being sent. >>>> I couldn't see a solution other than abandoning the elegant single-threaded approach and do keepalive as a separate high-priority process, but the architectural choice for the app changed at this point to not include a MQ in first delivery, so the more involved rewrite for doing so before deploying in production, kinda got stranded :/ >>> >>> Instinctively it feels like messaging and multi-MB payloads would not be a good fit, at least I would suspect that they are an edge case. But maybe I am wrong. >>> >>> I think that the code in StampMedium>>#readBodyBytes: and StampMedium>>#readBodyString: could be refactored to use a loop with chunk buffers and at the same time check the elapsed time to fire back keep alive pings if necessary. A ping too much would not hurt, better safe than sorry. But is is hard to catch any/all network slowdowns, any IO operation could hang/timeout. >>> >>> But all this would assume that the problematic situation can be recreated. >> >> Absolutely, far from certain the MQTT server implementations work the same. >> >> This is the test code I used for rabbit: >> >> consumer1 := StampClient new >> timeout:1; >> heartbeat: 5000; >> login: 'guest'; >> passcode: 'guest'; >> open; >> subscribeTo: '/exchange/testall'; >> yourself. >> [[ consumer1 runWith:[:message | Transcript crShow: '1 read: ', message body]] ensure: [consumer1 close]] forkAt: Processor userInterruptPriority . >> >> producer := StampClient new >> login: 'guest'; >> passcode: 'guest'; >> open; yourself. >> >> [1 to: 10000 do: [:i | producer sendText: i asString to: '/exchange/testall']] forkAt: Processor systemBackgroundPriority. >> >> Sometimes, but not always, this would fail, either during processing, or some time after. >> >> A screenshot of how it looks when a disconnect happens during processing due to heartbeat failing can be found at: >> https://tresor.it/s#HN4RG9PEX1SYyKy4NcM31w > > I installed RabbitMQ 3.6.4 on my Mac and tried your example and it succeeded ;-) But I modified it slightly so that both threads have a stop condition (I also used /queue instead of /exchange but I don't know if that makes a difference). > > limit := 10000. > > consumer1 := StampClient new > timeout:1; > heartbeat: 5000; > login: 'guest'; > passcode: 'guest'; > open; > subscribeTo: '/queue/testall'; > yourself. > > producer := StampClient new > login: 'guest'; > passcode: 'guest'; > open; > yourself. > > [ [ consumer1 runWith: [ :message | Transcript crShow: '1 read: ', message body. message body = limit asString ifTrue: [ ConnectionClosed signal ] ] ] ensure: [ consumer1 close ] ] forkAt: Processor userInterruptPriority. > > [ 1 to: limit do: [ :i | producer sendText: i asString to: '/queue/testall' ]. producer close ] forkAt: Processor systemBackgroundPriority. > > > You did see the #testSimpleWorkQueue unit test ? > And the StampBenchmarkTests ? > You could also try running StampBenchmark manually with higher loads. > > > What I mean is that I normally use the #writeWithReceipt: and #clientIndividualAck subscriptions with explicit ack/nack responses. The reason is that the way you do it (although allowed and the fastest way), there is no traffic flow regulation: the producer basically sends everything in one big go (because it does not wait for receipts from the server), the consumer gets all messages in one big batch from the broker - socket stream buffers at different levels will just fill up. > > All this does not yet explain your problem, I know. > > > I also did a checkin because I still had this modification in my image: > > === > Name: Stamp-SvenVanCaekenberghe.24 > Author: SvenVanCaekenberghe > Time: 21 December 2016, 9:54:27.217571 pm > UUID: ee3a7276-6e00-4143-9c3e-03a320c14ea6 > Ancestors: Stamp-HolgerHansPeterFreyther.23 > > StampClient > - minor refactoring in #writeHeartbeatIfNeeded (#wasInactive ForTooLong) > - add #touch call to #writeNoFlush: > === > > Just to make sure we're on the same version (I am still using Pharo 4 for this, BTW). > >> Cheers, >> Henry

Dec. 22, 2016

Re: [Pharo-dev] Pharo on Raspberry, how? Who?

by Igor Stasenko

On 22 December 2016 at 22:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 22 Dec 2016, at 21:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > > > > On 22 December 2016 at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > On 22 Dec 2016, at 20:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > > > > > so, as i understand VM comes by default with raspbian installation, or > what? > > > > yes, there is one included, it is not a Pharo one, for recent Pharo > images you need a very recent one. > > > > .. which can be dl/ed from... ? > > > > > and what are those: > > > https://bintray.com/estebanlm/pharo-vm/download_file?file_ > path=pharo-linux-ARMv6.0b8386a.zip > > > > > > ? > > > > that is a pharo one. > > > > hmm, you left me confused.. which one will work? > > the one in the link, or a newer one at the same place. > > > btw, do i need a specially prepared image? just asking in case if anyone > has one.. > > no, a standard 5.0 will do. > ookay... will try it tomorrow.. thanks, Sven, you are very helpful, as always! > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Dec. 22, 2016

Re: [Pharo-dev] Pharo on Raspberry, how? Who?

by Sven Van Caekenberghe

> On 22 Dec 2016, at 21:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 22 December 2016 at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 22 Dec 2016, at 20:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > > so, as i understand VM comes by default with raspbian installation, or what? > > yes, there is one included, it is not a Pharo one, for recent Pharo images you need a very recent one. > > .. which can be dl/ed from... ? > > > and what are those: > > https://bintray.com/estebanlm/pharo-vm/download_file?file_path=pharo-linux-… > > > > ? > > that is a pharo one. > > hmm, you left me confused.. which one will work? the one in the link, or a newer one at the same place. > btw, do i need a specially prepared image? just asking in case if anyone has one.. no, a standard 5.0 will do. > -- > Best regards, > Igor Stasenko.

Dec. 22, 2016