Re: [Pharo-users] Laser Game
I should look at the tutorial because it looks really strange to me to use a sketchMorph for a board game. On Sep 4, 2013, at 11:09 AM, Маркіян Різун wrote: > 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 > > On Sep 3, 2013, at 12:07 PM, Маркіян Різун 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 Маркіян Різун >> Thanks) >> >> >> 2013/9/2 Stéphane Ducasse >> >> On Sep 2, 2013, at 2:05 PM, Yuriy Tymchuk 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, Маркіян Різун 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 On Aug 16, 2013, at 11:11 AM, Маркіян Різун 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 > > >>> >> >> >> > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On Sep 4, 2013, at 6:30 PM, p...@highoctane.be wrote: > I was using 2.0 > Yes, this is what I understood from the original report. Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On 09/04/2013 09:31 AM, Mariano Martinez Peck wrote: > > Paul are you also using DBXTalk just by chance in that image? > > Cheers, No I haven't used DBXTalk yet.
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
phil was working with 3.0 (afaik) mariano was having problems with flushing monticello caches. I think it was not the same. Esteban On Sep 4, 2013, at 5:32 PM, Paul DeBruicker wrote: > On 09/04/2013 12:54 AM, Esteban Lorenzano wrote: >> I'm not sure what we are seeing in pharo3 is the same problem reported in >> pharo2. >> Of course if it is, we will backport. >> But "inflation" problem in ph3 is very consistent and repeatable, the >> problem reported in ph2... well, I never seen it before, and we have just >> one report (and I assume that we have more than one hundred production >> projects with that version). >> So is likely something different (also some of the detected leaks are due to >> changes in ph3, not present in the older version). >> >> Esteban > > > heres two more reports about image size in another thread (Phil & Mariano): > > http://forum.world.st/Large-images-reasons-WAS-Re-Pharo-2-0-with-Seaside-DBXTalk-GlorpDBX-Magritte-3-TWBS-is-getting-slower-tp4701743.html > > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On 09/04/2013 12:54 AM, Esteban Lorenzano wrote: > I'm not sure what we are seeing in pharo3 is the same problem reported in > pharo2. > Of course if it is, we will backport. > But "inflation" problem in ph3 is very consistent and repeatable, the problem > reported in ph2... well, I never seen it before, and we have just one report > (and I assume that we have more than one hundred production projects with > that version). > So is likely something different (also some of the detected leaks are due to > changes in ph3, not present in the older version). > > Esteban heres two more reports about image size in another thread (Phil & Mariano): http://forum.world.st/Large-images-reasons-WAS-Re-Pharo-2-0-with-Seaside-DBXTalk-GlorpDBX-Magritte-3-TWBS-is-getting-slower-tp4701743.html
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On 09/04/2013 02:44 AM, Esteban Lorenzano wrote: > I will like to know which vm version are you using. > > Esteban the one thats packaged with the one-clicks 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano Jenkins build #14535 Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux plugin path: /home/paul/pharo/pharo2.0/bin [default: /home/paul/pharo/pharo2.0/bin/]
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
mm DBXTalk and image save sounded a bell... When we developed OpenDBXDriver, we idea was to make it as simple as possible for the final user. One thing we did was to automatically disconnect all opened connections at system shutdown...so that not to let connections open in the DB. Now I realized that we have this: DBXConnection class >> shutDown self allInstancesDo: [:each | each shutDown] but it should actually be DBXConnection class >> shutDown: quitting quitting ifTrue: [ self allInstancesDo: [:each | each shutDown] I fixed this some time ago (OpenDBXDriver-MarianoMartinezPeck.38) Maybe this could be related? Paul are you also using DBXTalk just by chance in that image? Cheers, On Wed, Sep 4, 2013 at 1:00 PM, Esteban Lorenzano wrote: > phil was working with 3.0 (afaik) > mariano was having problems with flushing monticello caches. > > I think it was not the same. > > Esteban > > On Sep 4, 2013, at 5:32 PM, Paul DeBruicker wrote: > > > On 09/04/2013 12:54 AM, Esteban Lorenzano wrote: > >> I'm not sure what we are seeing in pharo3 is the same problem reported > in pharo2. > >> Of course if it is, we will backport. > >> But "inflation" problem in ph3 is very consistent and repeatable, the > problem reported in ph2... well, I never seen it before, and we have just > one report (and I assume that we have more than one hundred production > projects with that version). > >> So is likely something different (also some of the detected leaks are > due to changes in ph3, not present in the older version). > >> > >> Esteban > > > > > > heres two more reports about image size in another thread (Phil & > Mariano): > > > > > http://forum.world.st/Large-images-reasons-WAS-Re-Pharo-2-0-with-Seaside-DBXTalk-GlorpDBX-Magritte-3-TWBS-is-getting-slower-tp4701743.html > > > > > > > > > -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
I was using 2.0 --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Wed, Sep 4, 2013 at 6:00 PM, Esteban Lorenzano wrote: > phil was working with 3.0 (afaik) > mariano was having problems with flushing monticello caches. > > I think it was not the same. > > Esteban > > On Sep 4, 2013, at 5:32 PM, Paul DeBruicker wrote: > > > On 09/04/2013 12:54 AM, Esteban Lorenzano wrote: > >> I'm not sure what we are seeing in pharo3 is the same problem reported > in pharo2. > >> Of course if it is, we will backport. > >> But "inflation" problem in ph3 is very consistent and repeatable, the > problem reported in ph2... well, I never seen it before, and we have just > one report (and I assume that we have more than one hundred production > projects with that version). > >> So is likely something different (also some of the detected leaks are > due to changes in ph3, not present in the older version). > >> > >> Esteban > > > > > > heres two more reports about image size in another thread (Phil & > Mariano): > > > > > http://forum.world.st/Large-images-reasons-WAS-Re-Pharo-2-0-with-Seaside-DBXTalk-GlorpDBX-Magritte-3-TWBS-is-getting-slower-tp4701743.html > > > > > > > > > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On 09/04/2013 12:14 AM, Sven Van Caekenberghe wrote: > 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.. > > Sven No offence taken. The RFB error happens without connections. It also happens on the Mac and XP using the VM's in those platforms' one-clicks from pharo-project.org in both Pharo 1.4 and Pharo 2. It does not happen using 1.4 and eliot's vm (2776). I've been using this VM for pharo 2 work: ~/pharo/pharo2.0$ ./pharo -version 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano Jenkins build #14535 Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux plugin path: /home/paul/pharo/pharo2.0/bin [default: /home/paul/pharo/pharo2.0/bin/] Often (many more times than emails I write) I blame Pharo or Linux (or some random JS library I'm using) for being broken and 99% of the time I come to find that its just some dumb code I wrote that's broken. In this instance because the image locks up and I can't use the alt+. (or cmd + .) to break out of it to diagnose the problem I don't know what to do other than report it.
Re: [Pharo-users] [Pharo-dev] Pharo Sprint in Buenos Aires
From the doodle we're around 7, so I'd count with something like 10 people? And yes, I think internet connection is a requirement, at least for updating the issue tracker. On 2013-09-04, at 10:32, Nicolas Passerini wrote: > I think UTN is not a good idea for a Pharo sprint, because we will need a > good Internet connection and that can not be guaranteed here. > (Or correct me and tell me that Internet connection is not a must, so we > can meet here at UTN without problems). > > How much people is coming to the Sprint? > > > On Wed, Sep 4, 2013 at 10:12 AM, Sebastian Tleye wrote: > >> The Pabellon 1 is closed on saturdays afternoon, but have you asked for >> Pabellon 2? I think it's open on saturdays (i don't know if it is possible >> to book a room) >> >> >> 2013/9/4 Guillermo Polito >> >>> Probably UTN? >>> >>> >>> On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni wrote: >>> So it looks like we are going to do the Pharo sprint in Buenos Aires Saturday, the 14th of September. The question is now where do we meet? The original idea was to reserver a room at the UBA, but that is not possible the weekend. Any suggestions? On 2013-09-03, at 09:05, Mariano Martinez Peck wrote: > Cool. I'll be there, of course! > Keep us informed. > Cheers, > > > On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni wrote: > >> everything is open so far, guido had the idea of reserving a room at the >> UBA, >> we will have more details tomorrow :) >> >> On 2013-09-02, at 21:24, Gisela Decuzzi wrote: >>> Great! The idea is to spend the full day? Or do you have any planed time? >>> >>> >>> 2013/9/2 Camillo Bruni >>> I spend a month in Buenos Aires working together with Guido Chari @ the UBA, we take this opportunity to organize a Pharo sprint outside France ;) We are in early preparation phase and the date nor location isn't fixed yet, so if you are motivated to join, can mark possible dates on this doodle: http://doodle.com/qey7iieqm5yr4wwy cheers, camillo >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >>> >> signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-users] [Pharo-dev] Pharo Sprint in Buenos Aires
The Pabellon 1 is closed on saturdays afternoon, but have you asked for Pabellon 2? I think it's open on saturdays (i don't know if it is possible to book a room) 2013/9/4 Guillermo Polito > Probably UTN? > > > On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni wrote: > >> So it looks like we are going to do the Pharo sprint in Buenos Aires >> Saturday, the 14th of September. >> The question is now where do we meet? >> The original idea was to reserver a room at the UBA, but that is not >> possible the weekend. >> Any suggestions? >> >> On 2013-09-03, at 09:05, Mariano Martinez Peck >> wrote: >> >> > Cool. I'll be there, of course! >> > Keep us informed. >> > Cheers, >> > >> > >> > On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni > >wrote: >> > >> >> everything is open so far, guido had the idea of reserving a room at >> the >> >> UBA, >> >> we will have more details tomorrow :) >> >> >> >> On 2013-09-02, at 21:24, Gisela Decuzzi >> wrote: >> >>> Great! The idea is to spend the full day? Or do you have any planed >> time? >> >>> >> >>> >> >>> 2013/9/2 Camillo Bruni >> >>> >> I spend a month in Buenos Aires working together with Guido Chari @ >> the >> UBA, >> we take this opportunity to organize a Pharo sprint outside France ;) >> >> We are in early preparation phase and the date nor location isn't >> fixed >> yet, >> so if you are motivated to join, can mark possible dates on this >> doodle: >> >> http://doodle.com/qey7iieqm5yr4wwy >> >> cheers, >> camillo >> >> >> >> >> >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> >> >
Re: [Pharo-users] How to get the return value of a context?
Am 04.09.2013 um 14:19 schrieb Norbert Hartl : > interleavedCtx := [ | foo | > foo := self dummySend > … > ] It doesn't work with a temp inside the block. Using a method temp does what I think it does. So the very hackish way of doing it is at the moment | foo | ... interleavedCtx := [ foo := self dummy. … foo ] asContext. interleavedCtx pc: intermediateCtx startpc + 2. interleavedCtx swapSender: (targetCtx swapSender: interleavedCtx) I hope there is a more elaborate way of doing this (beside calculating the byte code offset more reliable). Norbert
Re: [Pharo-users] [Pharo-dev] Pharo Sprint in Buenos Aires
Probably UTN? On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni wrote: > So it looks like we are going to do the Pharo sprint in Buenos Aires > Saturday, the 14th of September. > The question is now where do we meet? > The original idea was to reserver a room at the UBA, but that is not > possible the weekend. > Any suggestions? > > On 2013-09-03, at 09:05, Mariano Martinez Peck > wrote: > > > Cool. I'll be there, of course! > > Keep us informed. > > Cheers, > > > > > > On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni >wrote: > > > >> everything is open so far, guido had the idea of reserving a room at the > >> UBA, > >> we will have more details tomorrow :) > >> > >> On 2013-09-02, at 21:24, Gisela Decuzzi > wrote: > >>> Great! The idea is to spend the full day? Or do you have any planed > time? > >>> > >>> > >>> 2013/9/2 Camillo Bruni > >>> > I spend a month in Buenos Aires working together with Guido Chari @ > the > UBA, > we take this opportunity to organize a Pharo sprint outside France ;) > > We are in early preparation phase and the date nor location isn't > fixed > yet, > so if you are motivated to join, can mark possible dates on this > doodle: > > http://doodle.com/qey7iieqm5yr4wwy > > cheers, > camillo > > >> > >> > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > >
Re: [Pharo-users] [Pharo-dev] Pharo Sprint in Buenos Aires
So it looks like we are going to do the Pharo sprint in Buenos Aires Saturday, the 14th of September. The question is now where do we meet? The original idea was to reserver a room at the UBA, but that is not possible the weekend. Any suggestions? On 2013-09-03, at 09:05, Mariano Martinez Peck wrote: > Cool. I'll be there, of course! > Keep us informed. > Cheers, > > > On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni wrote: > >> everything is open so far, guido had the idea of reserving a room at the >> UBA, >> we will have more details tomorrow :) >> >> On 2013-09-02, at 21:24, Gisela Decuzzi wrote: >>> Great! The idea is to spend the full day? Or do you have any planed time? >>> >>> >>> 2013/9/2 Camillo Bruni >>> I spend a month in Buenos Aires working together with Guido Chari @ the UBA, we take this opportunity to organize a Pharo sprint outside France ;) We are in early preparation phase and the date nor location isn't fixed yet, so if you are motivated to join, can mark possible dates on this doodle: http://doodle.com/qey7iieqm5yr4wwy cheers, camillo >> >> > > > -- > Mariano > http://marianopeck.wordpress.com signature.asc Description: Message signed with OpenPGP using GPGMail
[Pharo-users] How to get the return value of a context?
I'm trying to interleave some behavior in the normal execution flow. For this I do something like targetCtx := self findTargetContext. interleavedCtx := [ self doSomething ] asContext. interleavedCtx swapSender: (targetCtx swapSender: interleavedCtx). Basically this works pretty fine. Now I have the case that targetCtx returns a value that was assigned to a variable in the original code bar := self methodOfTheTargetCtx What is a good way to get the return value of targetCtx? I think there is an easy way but I didn't find it. Even my very hacky tries failed. I did a manual test by having interleavedCtx := [ | foo | foo := self dummySend … ] and setting the pc of the context just after the "send: dummySend" which is "popIntoTemp: 1". I thought at least that should bring the return value to foo but it didn't work. Maybe I'm doing just something stupid on the way. Some hints for enlightenment would be fine. thanks, Norbert
Re: [Pharo-users] Laser Game
2013/9/4 p...@highoctane.be > you can get a rectanglemorph and a Form I'll try that) Thank you
Re: [Pharo-users] Laser Game
you can get a rectanglemorph and a Form On Wednesday, September 4, 2013, Маркіян Різун wrote: > I thouqght 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 >> >> On Sep 3, 2013, at 12:07 PM, Маркіян Різун 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 Маркіян Різун >>> >>> Thanks) >>> >>> 2013/9/2 Stéphane Ducasse On Sep 2, 2013, at 2:05 PM, Yuriy Tymchuk 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, Маркіян Різун 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 > > On Aug 16, 2013, at 11:11 AM, Маркіян Різун 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 > > >>> >> >> > > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On Sep 4, 2013, at 12:10 PM, Norbert Hartl wrote: > > Am 04.09.2013 um 11:43 schrieb Esteban Lorenzano : > >> >> On Sep 4, 2013, at 10:54 AM, Sven Van Caekenberghe wrote: >> >>> >>> On 04 Sep 2013, at 10:47, Norbert Hartl 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 :) >> > It is a good thing to avoid that. Why? Because it is not automatically > reproducible. If it is it might be better to put it in a start script. I let > my images build by CI which I copy then on the target machine (in a script of > course :) ). Then there are start scripts that e.g. start the RFB server. And > those things always works until I save the image and change this way the > prerequisites of the process. Or did you mean something different? in practice is the same. you have a "preparation script" that opens a RFB and saves the image. If you say that doing it that way is not good, then I disagree: pharo is image based and if we do not keep the power of having a "ready to start" image (in production too), then we are losing something important. ... and we are transforming a necessity (not doing something because is buggy) into a virtue... and that's just plain wrong :) but I think we are now talking of different things :) > > Norbert > > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On Sep 4, 2013, at 10:54 AM, Sven Van Caekenberghe wrote: > > On 04 Sep 2013, at 10:47, Norbert Hartl 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 > > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On Sep 4, 2013, at 11:03 AM, Sven Van Caekenberghe wrote: > > On 04 Sep 2013, at 10:53, Norbert Hartl wrote: > >> >> Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe : >> >>> >>> On 04 Sep 2013, at 08:57, Marcus Denker wrote: >>> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker 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-td4704639.html) > 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-in-Pharo-1-4-tp4699207.html > > 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 >>> >>> >> >> > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
Am 04.09.2013 um 11:43 schrieb Esteban Lorenzano : > > On Sep 4, 2013, at 10:54 AM, Sven Van Caekenberghe wrote: > >> >> On 04 Sep 2013, at 10:47, Norbert Hartl 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 :) > It is a good thing to avoid that. Why? Because it is not automatically reproducible. If it is it might be better to put it in a start script. I let my images build by CI which I copy then on the target machine (in a script of course :) ). Then there are start scripts that e.g. start the RFB server. And those things always works until I save the image and change this way the prerequisites of the process. Or did you mean something different? Norbert
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On 04 Sep 2013, at 11:43, Esteban Lorenzano wrote: > > On Sep 4, 2013, at 10:54 AM, Sven Van Caekenberghe wrote: > >> >> On 04 Sep 2013, at 10:47, Norbert Hartl 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 >> >> >> > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
Am 04.09.2013 um 11:41 schrieb Esteban Lorenzano : > > On Sep 4, 2013, at 10:47 AM, Norbert Hartl wrote: > >> >> Am 04.09.2013 um 01:13 schrieb Esteban Lorenzano : >> >>> >>> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker 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-td4704639.html) 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-in-Pharo-1-4-tp4699207.html 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? No, I didn't look at that. So nothing to say. Norbert > 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 >>> >>> >> >> > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On Sep 4, 2013, at 10:47 AM, Norbert Hartl wrote: > > Am 04.09.2013 um 01:13 schrieb Esteban Lorenzano : > >> >> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker 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-td4704639.html) >>> 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-in-Pharo-1-4-tp4699207.html >>> >>> 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 >>> >> >> > >
Re: [Pharo-users] Laser Game
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 > > On Sep 3, 2013, at 12:07 PM, Маркіян Різун 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 Маркіян Різун > >> Thanks) >> >> >> 2013/9/2 Stéphane Ducasse >> >>> >>> On Sep 2, 2013, at 2:05 PM, Yuriy Tymchuk 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, Маркіян Різун 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 >>> On Aug 16, 2013, at 11:11 AM, Маркіян Різун 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 >>> >>> >>> >> > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On 04 Sep 2013, at 10:53, Norbert Hartl wrote: > > Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe : > >> >> On 04 Sep 2013, at 08:57, Marcus Denker wrote: >> >>> >>> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker 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-td4704639.html) 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-in-Pharo-1-4-tp4699207.html 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 >>> >>> >> >> > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
Am 04.09.2013 um 10:54 schrieb Sven Van Caekenberghe : > > On 04 Sep 2013, at 10:47, Norbert Hartl 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
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On 04 Sep 2013, at 10:47, Norbert Hartl 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
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe : > > On 04 Sep 2013, at 08:57, Marcus Denker wrote: > >> >> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker 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-td4704639.html) >>> 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-in-Pharo-1-4-tp4699207.html >>> >>> 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 >> >> > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
Am 04.09.2013 um 01:13 schrieb Esteban Lorenzano : > > On Sep 4, 2013, at 12:42 AM, Paul DeBruicker 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-td4704639.html) >> 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-in-Pharo-1-4-tp4699207.html >> >> 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 >> > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On Sep 4, 2013, at 9:55 AM, Esteban Lorenzano wrote: >>> >>> >> 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 > > I'm not sure what we are seeing in pharo3 is the same problem reported in > pharo2. > Of course if it is, we will backport. > But "inflation" problem in ph3 is very consistent and repeatable, the problem > reported in ph2... well, I never seen it before, and we have just one report > (and I assume that we have more than one hundred production projects with > that version). > So is likely something different (also some of the detected leaks are due to > changes in ph3, not present in the older version). > Yes, the problem in Pharo2 seems to be related purely to morph extensions hanging around. https://pharo.fogbugz.com/f/cases/11290/There-are-far-more-instances-of-MorphExtension-than-Morph (yes, I should have added a parent case for "back port to 2.0"). Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On Sep 4, 2013, at 8:57 AM, Marcus Denker wrote: > > On Sep 4, 2013, at 12:42 AM, Paul DeBruicker 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-td4704639.html) >> 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 undertand what you want and why do you say that you do not like RFB... but we are still far from the real answer and also people will always load their own third part libraries and that should be possible. Of course, since they not part of the core libraries, we do not have to take responsibility of those packages (we cannot take responsibility for all packages around)... but problem reported is a VM freeze, and that is of interest for us, so I still will take a look. Also, as I said... I have RFB running in 2.0 so it shouldn't have problems. > >> >> >> 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-in-Pharo-1-4-tp4699207.html >> >> 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 I'm not sure what we are seeing in pharo3 is the same problem reported in pharo2. Of course if it is, we will backport. But "inflation" problem in ph3 is very consistent and repeatable, the problem reported in ph2... well, I never seen it before, and we have just one report (and I assume that we have more than one hundred production projects with that version). So is likely something different (also some of the detected leaks are due to changes in ph3, not present in the older version). Esteban > > Marcus > >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
> 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-td4704639.html) > 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. Ok I remember. We will have a look. > 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-in-Pharo-1-4-tp4699207.html Ok. > I understand this is due to some leaks involving morphs and announcers > and things that are fixed in pharo 3 but not pharo 2. Yes igor and esteban spent some times and they are probably some left. ( sadly :) doing is more difficult than doing nothing) > 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. I understand. Thanks for the email. > Hope this helps and thanks for following up Yes! > > > Paul >
Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed
On 04 Sep 2013, at 08:57, Marcus Denker wrote: > > On Sep 4, 2013, at 12:42 AM, Paul DeBruicker 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-td4704639.html) >> 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.. 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-in-Pharo-1-4-tp4699207.html >> >> 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 > >
