- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Sven Van Caekenberghe

On 04 Sep 2013, at 11:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Sep 4, 2013, at 10:54 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 04 Sep 2013, at 10:47, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> In all my other projects using zinc and RFB I didn't see the problem. But then I don't save images in production. >> >> Images are very cool and very useful, but saving images in production is a no go, it is asking for trouble, IMHO. > > yes, but preparing an image for production often includes opening RFB and save it in that state :) I certainly understand, but using Metacello configurations, CI servers, zero-conf command line tools, the command line handlers and startup scripts you can build production images much more reliably and repeatably, instead of fiddling around in an interactive image. There are even some crude REPL tools available if you want to inspect running production images. That being said: in an ideal world, you should be able to run some tools in Pharo in a local image, connect to a remote image, and work there. We will get there, I am sure. > Esteban > >> >> Sven >> >> >> > >

Sept. 4, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Esteban Lorenzano

On Sep 4, 2013, at 11:03 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 04 Sep 2013, at 10:53, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> >>> On 04 Sep 2013, at 08:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> >>>> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >>>> >>>>> On 09/03/2013 12:25 PM, StÃ©phane Ducasse wrote: >>>>>> If you do not give us more information we will never be able to fix it. >>>>>> And may be 3.0 will still have the problem and you will start using system that is 3 year old. >>>>>> I can understand that you get in a situation where you cannot do otherwise but do not expect >>>>>> us to fix magically things. >>>>>> >>>>>> Stef >>>>> >>>>> >>>>> Hi Stef, >>>>> >>>>> For reporting the RFB issue I made a thread >>>>> (http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-td4704…) >>>>> and uploaded a Pharo 2 image to dropbox where if you execute this code: >>>>> >>>>> >>>>> RFBServer start >>>>> Smalltalk snapshot: true andQuit: false >>>>> >>>>> >>>>> The image locks up using the 'pharo' VM and works fine using eliots vm. >>>>> The uploaded image is Pharo-20619 with only RFB loaded. >>>>> >>>>> >>>> I really do not like RFBâ¦ we do not use it at all in the daily development, yet it people >>>> load it for production environments. >>>> >>>> For me, the system we use every day should be identical to the production environment, >>>> else it is very hard to get a stable system. >>>> >>>> (We need to make what people get of of using RFB part of the base system: remote browsing >>>> and debugging). >>> >>> I totally agree: the why use RFB part and the remote browsing/debugging replacement part. On the other hand, if people want to use some library, that should be possible. >>> >>> The problem is this case is (again) that have a user (no offence Paul) of some external library that says 'I take a stock image + a library and it does not work in some specific case: pharo people help me please' while the maintainer of RFB is nowhere to be seen or heard of, let alone that he would be willing to take responsibility for how his/her software runs on recent Pharo image/vm/platform combinations - it _is_ a lot of work to maintain open source software. >>> >>> I looked a little bit at the RFB code: it is pretty OK AFAIKT, but it does hackery stuff with networking. And Paul's problem only occurs if you save an image with RFB connections open on Linux on a specific VM. It will require dedication to debug this.. >>> >> I agree what you said in general. But my gut tells me that it isn't RFBs fault triggering the problem. I had the scenario "save image with open RFB connection" in mind. If you have a linux server and debugging stuff this is just the case you use. I did examine that. I started the image with a script that 1 minute later did save and quit. So there was an open RFB server socket listening but no connect. Doing a http request that triggers a database lookup (zinc and dbxtalk) within that minute the image goes into 100% CPU usage on reopening. >> >> So I wouldn't be so sure it is RFB. > > Yeah, I know, but Paul case was just with a stock image/vm + RFB and it was triggered by the image save. Like I said, these things are hard. yes, but I cannot reproduce it. It is workign perfectly fine in my machine and my 2 virtual machines with windows and linux. I will like to know which vm version are you using. Esteban > >> Norbert >> >>> Sven >>> >>>>> The other problem I had with Pharo 2 is the ever growing image size I >>>>> reported here: >>>>> >>>>> http://forum.world.st/development-image-memory-use-180MB-in-Pharo-2-vs-40MB… >>>>> >>>>> I understand this is due to some leaks involving morphs and announcers >>>>> and things that are fixed in pharo 3 but not pharo 2. >>>>> >>>> We are in the process of fixing them, but have not fixed all yet. I always thought that we would >>>> back port when we have fixed the problem completely in 3.0 >>>> >>>> Marcus >>>> >>>> >>> >>> >> >> > >

Sept. 4, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Esteban Lorenzano

On Sep 4, 2013, at 10:54 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 04 Sep 2013, at 10:47, Norbert Hartl <norbert(a)hartl.name> wrote: > >> In all my other projects using zinc and RFB I didn't see the problem. But then I don't save images in production. > > Images are very cool and very useful, but saving images in production is a no go, it is asking for trouble, IMHO. yes, but preparing an image for production often includes opening RFB and save it in that state :) Esteban > > Sven > > >

Sept. 4, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Esteban Lorenzano

On Sep 4, 2013, at 10:47 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 04.09.2013 um 01:13 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >> >>> On 09/03/2013 12:25 PM, StÃ©phane Ducasse wrote: >>>> If you do not give us more information we will never be able to fix it. >>>> And may be 3.0 will still have the problem and you will start using system that is 3 year old. >>>> I can understand that you get in a situation where you cannot do otherwise but do not expect >>>> us to fix magically things. >>>> >>>> Stef >>> >>> >>> Hi Stef, >>> >>> For reporting the RFB issue I made a thread >>> (http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-td4704…) >>> and uploaded a Pharo 2 image to dropbox where if you execute this code: >>> >>> >>> RFBServer start >>> Smalltalk snapshot: true andQuit: false >>> >>> >>> The image locks up using the 'pharo' VM and works fine using eliots vm. >>> The uploaded image is Pharo-20619 with only RFB loaded. >> >> I will check this (after SUG) >> >>> >>> >>> >>> >>> The other problem I had with Pharo 2 is the ever growing image size I >>> reported here: >>> >>> http://forum.world.st/development-image-memory-use-180MB-in-Pharo-2-vs-40MB… >>> >>> I understand this is due to some leaks involving morphs and announcers >>> and things that are fixed in pharo 3 but not pharo 2. >>> >>> I have not gotten the impression that that fix will be backported, and >>> even if it will it hasn't been yet so because of that and the RFB issue >>> above I can't use Pharo 2 right now. >> >> this is weird, because is the first time I see a report (well, I saw the other thread too) about this. >> and Pharo2 is productive since more than 8 months now (and I have some production stuff on it)... and I never seen it. >> This is likely not for the same reasons as pharo3 leaks (which btw are just partially solved, the leaks are still there). >> >> I would like to have that image to take a look, if possible, because is super-weird. >> >>> > I reported a similar problem. I'm doing a project for that I need to use zinc, DBXTalk and RFB. Zinc provides a http interface which triggers a database lookup. In my scenario I can save the image until the first request is fired. Every image that will be saved later will bring up an empty window and 100% CPU usage on reopening. I just had some time to track it down. I can see this behavior on my mac laptop as well as on my linux server. I suspected dbxtalk until Paul brought up the RFB case. But I need to spend more time for tracking down the error or producing a reproducable image showing the effect. > In all my other projects using zinc and RFB I didn't see the problem. But then I don't save images in production. Norbert, I was talking about the "inflation" problem in that paragraph, not the RFB hang... can you confirm it? And well, yes RFB+Zinc+DBXTalk can be a combination to look... a lot of FFI/Plugin interaction there (specially if using Zodiac). Esteban > > Norbert > >>> Hope this helps and thanks for following up >>> >>> >>> Paul >>> >> >> > >

Sept. 4, 2013

Re: [Pharo-users] Laser Game

by ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½

I thought about that:) SketchMorph is used to create game board, so I need it. Can I use some other Morph? Mark 2013/9/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Sep 3, 2013, at 12:07 PM, ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> wrote: > > I was dealing with laser game on pharo and found two problems. > 1. LedMorph is missing but it's ok, I downloaded it (Morphic Extras). > > > you cn find it under my repository on Smalltalkhub > > 2.SketchMorph is missing too, and I have some difficulties with it. When > trying to load it (Morphic Basic) with Monticello browser an error occurs. > Any ideas? > > > Remove reference to SketchMorph. > > Stef > > > > 2013/9/2 ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> > >> Thanks) >> >> >> 2013/9/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> >>> On Sep 2, 2013, at 2:05 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Hi, >>> >>> yes it can. This is where your adventure begins :) >>> >>> Also I think that I may be easier to follow the tutorial step by step >>> with Pharo. Then you'll solve problems just when they appear and not end up >>> with a tons of unknown stuff. >>> >>> >>> ;) >>> >>> >>> Uko >>> >>> >>> On 2 Ð²ÐµÑ. 2013, at 15:02, ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> wrote: >>> >>> As was suggested above I tried to load Laser Game on Pharo 2.0 and it >>> didn't work. >>> Can this problem be solved? >>> >>> >>> 2013/8/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> >>>> >>>> On Aug 16, 2013, at 11:11 AM, ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> wrote: >>>> >>>> Hi, everyone! >>>> I have been working on a tutorial 'how to make a game using smalltalk' >>>> and developed this game ( Laser Game ) on Squeak, as it is an example of >>>> development on Squeak. I'm learning, so it's a great experience for me. >>>> Laser Game is my first game and it's not complicated, but for me it took >>>> long time to make. >>>> Links: >>>> 1. http://squeak.preeminent.org/tut2007/html/ - website of tutorial >>>> 2. http://smalltalkhub.com/#!/~MarkRizun/LaserGame/source - Laser Game >>>> Comments are welcome:) >>>> >>>> >>>> I thought that you were doing it on Pharo. >>>> It would be good to have it on pharo and to know what are the changes >>>> at the morphic level. >>>> >>>> Mark >>>> >>>> >>>> >>>> >>> >>> >>> >> > >

Sept. 4, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Sven Van Caekenberghe

On 04 Sep 2013, at 10:53, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> On 04 Sep 2013, at 08:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >>> >>>> On 09/03/2013 12:25 PM, StÃ©phane Ducasse wrote: >>>>> If you do not give us more information we will never be able to fix it. >>>>> And may be 3.0 will still have the problem and you will start using system that is 3 year old. >>>>> I can understand that you get in a situation where you cannot do otherwise but do not expect >>>>> us to fix magically things. >>>>> >>>>> Stef >>>> >>>> >>>> Hi Stef, >>>> >>>> For reporting the RFB issue I made a thread >>>> (http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-td4704…) >>>> and uploaded a Pharo 2 image to dropbox where if you execute this code: >>>> >>>> >>>> RFBServer start >>>> Smalltalk snapshot: true andQuit: false >>>> >>>> >>>> The image locks up using the 'pharo' VM and works fine using eliots vm. >>>> The uploaded image is Pharo-20619 with only RFB loaded. >>>> >>>> >>> I really do not like RFBâ¦ we do not use it at all in the daily development, yet it people >>> load it for production environments. >>> >>> For me, the system we use every day should be identical to the production environment, >>> else it is very hard to get a stable system. >>> >>> (We need to make what people get of of using RFB part of the base system: remote browsing >>> and debugging). >> >> I totally agree: the why use RFB part and the remote browsing/debugging replacement part. On the other hand, if people want to use some library, that should be possible. >> >> The problem is this case is (again) that have a user (no offence Paul) of some external library that says 'I take a stock image + a library and it does not work in some specific case: pharo people help me please' while the maintainer of RFB is nowhere to be seen or heard of, let alone that he would be willing to take responsibility for how his/her software runs on recent Pharo image/vm/platform combinations - it _is_ a lot of work to maintain open source software. >> >> I looked a little bit at the RFB code: it is pretty OK AFAIKT, but it does hackery stuff with networking. And Paul's problem only occurs if you save an image with RFB connections open on Linux on a specific VM. It will require dedication to debug this.. >> > I agree what you said in general. But my gut tells me that it isn't RFBs fault triggering the problem. I had the scenario "save image with open RFB connection" in mind. If you have a linux server and debugging stuff this is just the case you use. I did examine that. I started the image with a script that 1 minute later did save and quit. So there was an open RFB server socket listening but no connect. Doing a http request that triggers a database lookup (zinc and dbxtalk) within that minute the image goes into 100% CPU usage on reopening. > > So I wouldn't be so sure it is RFB. Yeah, I know, but Paul case was just with a stock image/vm + RFB and it was triggered by the image save. Like I said, these things are hard. > Norbert > >> Sven >> >>>> The other problem I had with Pharo 2 is the ever growing image size I >>>> reported here: >>>> >>>> http://forum.world.st/development-image-memory-use-180MB-in-Pharo-2-vs-40MB… >>>> >>>> I understand this is due to some leaks involving morphs and announcers >>>> and things that are fixed in pharo 3 but not pharo 2. >>>> >>> We are in the process of fixing them, but have not fixed all yet. I always thought that we would >>> back port when we have fixed the problem completely in 3.0 >>> >>> Marcus >>> >>> >> >> > >

Sept. 4, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Norbert Hartl

Am 04.09.2013 um 10:54 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 04 Sep 2013, at 10:47, Norbert Hartl <norbert(a)hartl.name> wrote: > >> In all my other projects using zinc and RFB I didn't see the problem. But then I don't save images in production. > > Images are very cool and very useful, but saving images in production is a no go, it is asking for trouble, IMHO. > That's what I said without making something general out of it ;) Norbert

Sept. 4, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Sven Van Caekenberghe

On 04 Sep 2013, at 10:47, Norbert Hartl <norbert(a)hartl.name> wrote: > In all my other projects using zinc and RFB I didn't see the problem. But then I don't save images in production. Images are very cool and very useful, but saving images in production is a no go, it is asking for trouble, IMHO. Sven

Sept. 4, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Norbert Hartl

Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 04 Sep 2013, at 08:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >> >>> On 09/03/2013 12:25 PM, StÃ©phane Ducasse wrote: >>>> If you do not give us more information we will never be able to fix it. >>>> And may be 3.0 will still have the problem and you will start using system that is 3 year old. >>>> I can understand that you get in a situation where you cannot do otherwise but do not expect >>>> us to fix magically things. >>>> >>>> Stef >>> >>> >>> Hi Stef, >>> >>> For reporting the RFB issue I made a thread >>> (http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-td4704…) >>> and uploaded a Pharo 2 image to dropbox where if you execute this code: >>> >>> >>> RFBServer start >>> Smalltalk snapshot: true andQuit: false >>> >>> >>> The image locks up using the 'pharo' VM and works fine using eliots vm. >>> The uploaded image is Pharo-20619 with only RFB loaded. >>> >>> >> I really do not like RFBâ¦ we do not use it at all in the daily development, yet it people >> load it for production environments. >> >> For me, the system we use every day should be identical to the production environment, >> else it is very hard to get a stable system. >> >> (We need to make what people get of of using RFB part of the base system: remote browsing >> and debugging). > > I totally agree: the why use RFB part and the remote browsing/debugging replacement part. On the other hand, if people want to use some library, that should be possible. > > The problem is this case is (again) that have a user (no offence Paul) of some external library that says 'I take a stock image + a library and it does not work in some specific case: pharo people help me please' while the maintainer of RFB is nowhere to be seen or heard of, let alone that he would be willing to take responsibility for how his/her software runs on recent Pharo image/vm/platform combinations - it _is_ a lot of work to maintain open source software. > > I looked a little bit at the RFB code: it is pretty OK AFAIKT, but it does hackery stuff with networking. And Paul's problem only occurs if you save an image with RFB connections open on Linux on a specific VM. It will require dedication to debug this.. > I agree what you said in general. But my gut tells me that it isn't RFBs fault triggering the problem. I had the scenario "save image with open RFB connection" in mind. If you have a linux server and debugging stuff this is just the case you use. I did examine that. I started the image with a script that 1 minute later did save and quit. So there was an open RFB server socket listening but no connect. Doing a http request that triggers a database lookup (zinc and dbxtalk) within that minute the image goes into 100% CPU usage on reopening. So I wouldn't be so sure it is RFB. Norbert > Sven > >>> The other problem I had with Pharo 2 is the ever growing image size I >>> reported here: >>> >>> http://forum.world.st/development-image-memory-use-180MB-in-Pharo-2-vs-40MB… >>> >>> I understand this is due to some leaks involving morphs and announcers >>> and things that are fixed in pharo 3 but not pharo 2. >>> >> We are in the process of fixing them, but have not fixed all yet. I always thought that we would >> back port when we have fixed the problem completely in 3.0 >> >> Marcus >> >> > >

Sept. 4, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Norbert Hartl

Am 04.09.2013 um 01:13 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > >> On 09/03/2013 12:25 PM, StÃ©phane Ducasse wrote: >>> If you do not give us more information we will never be able to fix it. >>> And may be 3.0 will still have the problem and you will start using system that is 3 year old. >>> I can understand that you get in a situation where you cannot do otherwise but do not expect >>> us to fix magically things. >>> >>> Stef >> >> >> Hi Stef, >> >> For reporting the RFB issue I made a thread >> (http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-td4704…) >> and uploaded a Pharo 2 image to dropbox where if you execute this code: >> >> >> RFBServer start >> Smalltalk snapshot: true andQuit: false >> >> >> The image locks up using the 'pharo' VM and works fine using eliots vm. >> The uploaded image is Pharo-20619 with only RFB loaded. > > I will check this (after SUG) > >> >> >> >> >> The other problem I had with Pharo 2 is the ever growing image size I >> reported here: >> >> http://forum.world.st/development-image-memory-use-180MB-in-Pharo-2-vs-40MB… >> >> I understand this is due to some leaks involving morphs and announcers >> and things that are fixed in pharo 3 but not pharo 2. >> >> I have not gotten the impression that that fix will be backported, and >> even if it will it hasn't been yet so because of that and the RFB issue >> above I can't use Pharo 2 right now. > > this is weird, because is the first time I see a report (well, I saw the other thread too) about this. > and Pharo2 is productive since more than 8 months now (and I have some production stuff on it)... and I never seen it. > This is likely not for the same reasons as pharo3 leaks (which btw are just partially solved, the leaks are still there). > > I would like to have that image to take a look, if possible, because is super-weird. > >> I reported a similar problem. I'm doing a project for that I need to use zinc, DBXTalk and RFB. Zinc provides a http interface which triggers a database lookup. In my scenario I can save the image until the first request is fired. Every image that will be saved later will bring up an empty window and 100% CPU usage on reopening. I just had some time to track it down. I can see this behavior on my mac laptop as well as on my linux server. I suspected dbxtalk until Paul brought up the RFB case. But I need to spend more time for tracking down the error or producing a reproducable image showing the effect. In all my other projects using zinc and RFB I didn't see the problem. But then I don't save images in production. Norbert >> Hope this helps and thanks for following up >> >> >> Paul >> > >

Sept. 4, 2013