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

Re: [Pharo-users] MacOS headless but showing up in dock?

by Bernat Romagosa

Hi Esteban, The configuration didn't work out of the box. I had to load the bleeding edge version from the configuration, then manually load the latest Core and all MacOSX packages from the MC repo. I'll check appkido, thanks a lot! :) Bernat. 2014-05-30 14:17 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 30 May 2014, at 08:00, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > wrote: > > Installing Alien proved to be quite a challenge... but I managed! > > > why? configuration should work out of the box. > > > Now I got an instance of ObjectiveCAlien that (I think) represents some > kind of dock object, but I don't really know what to do with it... > > Here's what I have: > > #NSApplication inObjectiveC sharedApplication dockTile > > > What kind of methods does this take? I see ObjectiveCAlien is a proxy, so > I can't really browse what messages can I send it. Any hints? > > > > you can browse the Cocoa documentation (I use http://appkido.com but you > need xcode installed and docs intalled too). > > Esteban > > > Thanks!!! > Bernat. > > > 2014-05-27 15:44 GMT+02:00 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com > >: > >> OK! I'll try that! >> >> You sure deserve some credit in the Snap4Arduino MacOSX version... ;) >> >> Thanks a lot! >> Bernat. >> >> >> 2014-05-27 15:32 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >>> On 27 May 2014, at 10:13, Bernat Romagosa < >>> tibabenfortlapalanca(a)gmail.com> wrote: >>> >>> Hi Mariano, >>> >>> Thanks, I used this method, but my problem is I do need an icon in the >>> dock :) >>> >>> I'm using Pharo as a server, and I'd need the user to be able to stop it >>> without any command-line knowledge. >>> >>> Esteban, I'll try with Alien. I'm curious though, doesn't NativeBoost >>> replace Alien now? >>> >>> >>> yes, but the ObjC bridge for NB is not working (yet, and until I found >>> time to do it :( ) >>> better to use the Alien FFI until then, so you can do something like: >>> >>> #NSApplication asObjectiveC sharedApplication dockTile â¦ (and etc.) >>> >>> :) >>> >>> >>> >>> Esteban >>> >>> >>> Thanks! >>> >>> Bernat. >>> >>> >>> 2014-05-27 14:35 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> : >>> >>>> Hi Bernat, >>>> >>>> About a year ago I did implement that on the Pharo VM (the Pharo's >>>> branch of Cog). It was integrated as far as I remember. >>>> I copied pasted here the ANN I sent to the mailing list: >>>> >>>> >>>> Hello there, >>>> >>>> For a long time, Pharaoers and Squakers have been asking for headless support >>>> in the Cocoa VMs just as we have with Carbon VMs. Carbon is becoming a >>>> legacy framework so people needed this. >>>> >>>> I wanted to thanks Square [i] International <http://www.square-i.net/> for >>>> sponsoring me to implement such a support. Not only have they sponsored the >>>> development but they have also agreed to release it under MIT license for >>>> the community. This headless support will be included in the official >>>> Pharo VM and will be, therefore, accessible to everybody. >>>> >>>> The project is not yet finished but I do have a demo/prototype that I >>>> wanted to share with you so that you can test it and give me feedback. This >>>> VM should only work starting at OSX 10.6. >>>> >>>> *How to use it?* Basically it works this way: to have headless, just >>>> edit the Info.plist and set the flag LSBackgroundOnly to 1 (add the key if >>>> it is not present): >>>> >>>> <key>LSBackgroundOnly</key> >>>> <true/> >>>> >>>> When doing this, you don't even need the -headless anymore since, >>>> setting LSBackgroundOnly to 1, will cause the same effect (being the flag >>>> almost mandatory). If you don't want headless, put it to false or >>>> don't even put the key. If you don't set LSBackgroundOnly to 1 but send - >>>> headless, the VM will still be headless but you will see a little >>>> flash. If this flash bothers you, then set the flag. I am trying to get a >>>> way to avoid the "flash" while also avoiding to set LSBackgroundOnly to 1, >>>> but I still couldn't find it. Anyway, I think we can live with the current >>>> situation. >>>> >>>> *How to test it?* You should run the image with something like RFB or >>>> Seaside or whatever you can and then confirm if it is working even if you >>>> areheadless. As a matter of testing, I saved an image with seaside >>>> running in the port 5555. You can get both, this Seaside image and the VM >>>> withheadless from: >>>> https://www.dropbox.com/sh/r7qk49bxywk2xce/6N7-fdyx6V >>>> So if you run the VM headless with that image and go to >>>> localhost:5555, you should see that Seaside is running. >>>> >>>> I would appreciate if you can test it. And please let me know in which >>>> version of OSX you tried. Of course, the more of you who can test it, the >>>> better. Notice that this VM was compiled with LLVM GCC 4.2 and it may have >>>> some problems in older OSX versions (but I think it shouldn't). I still >>>> couldn't compile a VM with GNU GCC 4.2 as I get a crash :( >>>> >>>> *Expected results?* In headless mode, anything should be displayed >>>> (no window, no menu, no item in the dock and nothing appear when switching >>>> apps). When running headfull, everything should be normal. >>>> >>>> *Where is the code? *The code I have modified to the VM is committed >>>> to my own fork of the VM: >>>> https://gitorious.org/~marianopeck/cogvm/marianopecks-blessed >>>> Once the code is ready, I will do a pull request so that it can be >>>> integrated. >>>> >>>> >>>> >>>> On Tue, May 27, 2014 at 7:02 AM, Bernat Romagosa < >>>> tibabenfortlapalanca(a)gmail.com> wrote: >>>> >>>>> Hi list, >>>>> >>>>> is it possible to have Pharo run headless while still showing up in >>>>> the dock? >>>>> >>>>> In the same direction, is it possible to add contextual menu items to >>>>> the dock menu? Or for what matters, to the top system menu? >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> Bernat Romagosa. >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >>> >>> -- >>> Bernat Romagosa. >>> >>> >>> >> >> >> -- >> Bernat Romagosa. >> > > > > -- > Bernat Romagosa. > > > -- Bernat Romagosa.

May 30, 2014

Re: [Pharo-users] Sending transactional emails from Pharo

by Norbert Hartl

Am 30.05.2014 um 14:57 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2014-05-30 6:41 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > >>> * It's pretty much free (though this is not a relevant factor ) >> Well, it is 12000 emails free per month. > > We will send arount 3000 per month, and the $1.5 per 10000 of Postmark > wasn't expensive either. > >>> Assuming you flag the transactions as "mailSent" or similar. >> Mariano is referring to a piece of code Iâve sent him. This one > >> ((mailResponse first at: 'status') = 'sent') >> ifTrue: [ self persistence changeStateOf: participant to: #emailSent ] >> ifFalse: [ self persistence changeStateOf: participant to: #emailFailed ]. >> self emptyOkResponse > > I was taking about a general pattern, of having a flag in the object, > a log or both. I just need a flag (actually two). > > >> There are a lot of ways you can do that. From your description I assume you >> have quite some incoming requests that should return quickly. Furthermore >> you want to keep exact track of the sent email and react to unexpected >> cases, right? > > Not really that much, but the email is not as important as the > transaction being submitted (through a REST url), so I try to separate > concerns as much as I can. > >> In my case I donât have these requirements. The request rate is pretty low >> and there is no effect to the user if a request to my handler takes longer. >> So I decided to use the synchronous API from Mandrill. So I get back the >> status immediately and can flag the action as OK or failed. I donât need >> more because if a message is not delivered from time to time it is no >> problem. So I guess Iâm in case #1 > > Here the volume isn't high, I'm simply worried about what a failure in > the sending of the mails could affect the "stability" of the whole > server (which is going to be a single image). > I donât think this is an issue. After my last fight with max external semaphores I have some use cases that use outgoing requests on incoming requests. Resource wise it is not a problem and if you put an exception handler around the mail sending it wonât affect the rest at all. Using a SharedQueue and detach the sending completely might be a good idea if you have doubts. Norbert >> If your requirements are different Iâd probably wouldnât take the effort to >> do #2. It gets complicated really quick. If we have another view on the >> Mandrill API webhooks come to the rescue [1]. In your request handler you >> send the message asynchronously. The status in the message is âqueuedâ then. >> If you have the webhooks registered you get called from mandrill whenever >> the status of a mail send changes. That is probably the best option because >> no need to poll anything.There is no support for that in the Mandrill API at >> the moment. But Iâm interested in this as well and could collaborate on >> that. > > Webhooks seems to be way to go if I want to defer the sending. > >> I think #3 would be really heavy weight for the task. My advize is not to do >> these kind of things until you really know that you need it. Complexity >> kills! > > I know... I won't do such thing unless there is another requirement > that justifies it. > However, I'm always tempted to use MQs an similars, it is the message > sending paradigm taken to a different level :D But a poor one :P Sometimes I tend to look at these things to. But then I see instead of the message sending I know you have (again) put some format as least common denominator in order to have your request take action. Context and all the important bits are lost that way. So even for a queue I would like to use something more close to our message sending. Norbert

May 30, 2014

Re: [Pharo-users] the mystery of dirty package

by Stephan Eggermont

Usman wrote: >It is second time in a week that I have to analyze a problem related to a package getting dirty because of loading another package. But when looking for changes, the >first package becomes clean again. A well-known reason can be found by taking a look in your package cache. If there are multiple versions of one package, there is a configuration problem. Lots of configurations refer to wrong versions of Grease & Magritte Stephan

May 30, 2014

Re: [Pharo-users] the mystery of dirty package

by Usman Bhatti

On Fri, May 30, 2014 at 1:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I do not quite understand. > > If it is an overriden method, the dirtyness should not go away when > looking for changes, no? In our case, there are no changes found. > > @Usman: what is the problematic method? > Grease overrides two methods in Collections-Abstract - Collection>>#contents - SequenceableCollection>>#sorted For the curious ones: in moose loading glamour makes collections-abstract package dirty. But doing changes makes the package clean. Doru, for Moose, the solution might be to update glamour config to use latest Grease as suggested by Stephan. > > Doru > > > On Fri, May 30, 2014 at 1:11 PM, Usman Bhatti <usman.bhatti(a)gmail.com> > wrote: > >> Tx for the pointer Thierry. >> >> So, I did a small script (because there were 314 methods) to see number >> of non-class-extension methods with and without loading the dirty marker >> package and I could spot the culprit. >> >> Running this script before and after loading the second package and doing >> a difference on the two sets shows determining the overridden method. >> >> methods := (RPackage organizer packageNamed: packageName) definedClasses >> flatCollect: [:class | class methodDict values]. >> methods := methods select: [:aMethod | aMethod category asString >> includesSubstring: '*']. >> >> >> regards, >> usman >> >> >> >> On Wed, May 28, 2014 at 4:30 PM, Goubier Thierry <thierry.goubier(a)cea.fr> >> wrote: >> >>> Hi Usman, >>> >>> look if the loaded package has overrides on other packages. If yes, it >>> will dirty them, and looking for changes will clean them. >>> >>> Thierry >>> >>> Le 28/05/2014 15:59, Usman Bhatti a Ã©crit : >>> >>> Hi, >>>> >>>> It is second time in a week that I have to analyze a problem related to >>>> a package getting dirty because of loading another package. But when >>>> looking for changes, the first package becomes clean again. >>>> >>>> >>>> One occurrence of the problem can be seen in the latest moose image: >>>> - download the latest image here:https://ci.inria.fr/ >>>> moose/job/moose-5.0/ >>>> - monticello browser -> Collections-Abstract -> changes and the package >>>> becomes clean. >>>> >>>> Any idea how to determine which method(s) from the incoming package >>>> might be causing changes in the loaded package? Or generally, how to go >>>> about correcting this problem? >>>> >>>> usman >>>> >>>> >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

May 30, 2014

Re: [Pharo-users] Sending transactional emails from Pharo

by Esteban A. Maringolo

2014-05-30 6:41 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> * It's pretty much free (though this is not a relevant factor ) > Well, it is 12000 emails free per month. We will send arount 3000 per month, and the $1.5 per 10000 of Postmark wasn't expensive either. >> Assuming you flag the transactions as "mailSent" or similar. > Mariano is referring to a piece of code Iâve sent him. This one > ((mailResponse first at: 'status') = 'sent') > ifTrue: [ self persistence changeStateOf: participant to: #emailSent ] > ifFalse: [ self persistence changeStateOf: participant to: #emailFailed ]. > self emptyOkResponse I was taking about a general pattern, of having a flag in the object, a log or both. I just need a flag (actually two). > There are a lot of ways you can do that. From your description I assume you > have quite some incoming requests that should return quickly. Furthermore > you want to keep exact track of the sent email and react to unexpected > cases, right? Not really that much, but the email is not as important as the transaction being submitted (through a REST url), so I try to separate concerns as much as I can. > In my case I donât have these requirements. The request rate is pretty low > and there is no effect to the user if a request to my handler takes longer. > So I decided to use the synchronous API from Mandrill. So I get back the > status immediately and can flag the action as OK or failed. I donât need > more because if a message is not delivered from time to time it is no > problem. So I guess Iâm in case #1 Here the volume isn't high, I'm simply worried about what a failure in the sending of the mails could affect the "stability" of the whole server (which is going to be a single image). > If your requirements are different Iâd probably wouldnât take the effort to > do #2. It gets complicated really quick. If we have another view on the > Mandrill API webhooks come to the rescue [1]. In your request handler you > send the message asynchronously. The status in the message is âqueuedâ then. > If you have the webhooks registered you get called from mandrill whenever > the status of a mail send changes. That is probably the best option because > no need to poll anything.There is no support for that in the Mandrill API at > the moment. But Iâm interested in this as well and could collaborate on > that. Webhooks seems to be way to go if I want to defer the sending. > I think #3 would be really heavy weight for the task. My advize is not to do > these kind of things until you really know that you need it. Complexity > kills! I know... I won't do such thing unless there is another requirement that justifies it. However, I'm always tempted to use MQs an similars, it is the message sending paradigm taken to a different level :D Regards! Esteban A. Maringolo

May 30, 2014

Re: [Pharo-users] the mystery of dirty package

by GOUBIER Thierry

________________________________ De : Pharo-users [pharo-users-bounces(a)lists.pharo.org] de la part de Tudor Girba [tudor(a)tudorgirba.com] EnvoyÃ© : vendredi 30 mai 2014 13:16 Ã : Any question about pharo is welcome Objet : Re: [Pharo-users] the mystery of dirty package I do not quite understand. If it is an overriden method, the dirtyness should not go away when looking for changes, no? In our case, there are no changes found If the overriden method (of say OriginalPackage) is redefined in a protocol named '*myPackage-override' by MyPackage, then asking MC for changes will consider that OriginalPackage is clean (and no changes will be found). A good example is ConfigurationOfGitFileTree as it is now. Upon loading it, you will see that it will set as dirty I think four packages, with all of them except one become clean when looking for changes... The one that shows changes has the overridden method not in an -override protocol (and I need to correct that someday). This is how MC processes overrides. Thierry @Usman: what is the problematic method? Doru On Fri, May 30, 2014 at 1:11 PM, Usman Bhatti <usman.bhatti(a)gmail.com<mailto:usman.bhatti@gmail.com>> wrote: Tx for the pointer Thierry. So, I did a small script (because there were 314 methods) to see number of non-class-extension methods with and without loading the dirty marker package and I could spot the culprit. Running this script before and after loading the second package and doing a difference on the two sets shows determining the overridden method. methods := (RPackage organizer packageNamed: packageName) definedClasses flatCollect: [:class | class methodDict values]. methods := methods select: [:aMethod | aMethod category asString includesSubstring: '*']. regards, usman On Wed, May 28, 2014 at 4:30 PM, Goubier Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>> wrote: Hi Usman, look if the loaded package has overrides on other packages. If yes, it will dirty them, and looking for changes will clean them. Thierry Le 28/05/2014 15:59, Usman Bhatti a Ã©crit : Hi, It is second time in a week that I have to analyze a problem related to a package getting dirty because of loading another package. But when looking for changes, the first package becomes clean again. One occurrence of the problem can be seen in the latest moose image: - download the latest image here:https://ci.inria.fr/moose/job/moose-5.0/ - monticello browser -> Collections-Abstract -> changes and the package becomes clean. Any idea how to determine which method(s) from the incoming package might be causing changes in the loaded package? Or generally, how to go about correcting this problem? usman -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92<tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95 -- www.tudorgirba.com<http://www.tudorgirba.com> "Every thing has its own flow"

May 30, 2014

Re: [Pharo-users] MacOS headless but showing up in dock?

by Esteban Lorenzano

On 30 May 2014, at 08:00, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Installing Alien proved to be quite a challenge... but I managed! why? configuration should work out of the box. > > Now I got an instance of ObjectiveCAlien that (I think) represents some kind of dock object, but I don't really know what to do with it... > > Here's what I have: > > #NSApplication inObjectiveC sharedApplication dockTile > > What kind of methods does this take? I see ObjectiveCAlien is a proxy, so I can't really browse what messages can I send it. Any hints? you can browse the Cocoa documentation (I use http://appkido.com but you need xcode installed and docs intalled too). Esteban > > Thanks!!! > Bernat. > > > 2014-05-27 15:44 GMT+02:00 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>: > OK! I'll try that! > > You sure deserve some credit in the Snap4Arduino MacOSX version... ;) > > Thanks a lot! > Bernat. > > > 2014-05-27 15:32 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 27 May 2014, at 10:13, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > >> Hi Mariano, >> >> Thanks, I used this method, but my problem is I do need an icon in the dock :) >> >> I'm using Pharo as a server, and I'd need the user to be able to stop it without any command-line knowledge. >> >> Esteban, I'll try with Alien. I'm curious though, doesn't NativeBoost replace Alien now? > > yes, but the ObjC bridge for NB is not working (yet, and until I found time to do it :( ) > better to use the Alien FFI until then, so you can do something like: > > #NSApplication asObjectiveC sharedApplication dockTile â¦ (and etc.) > > :) > > > > Esteban > >> >> Thanks! >> >> Bernat. >> >> >> 2014-05-27 14:35 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi Bernat, >> >> About a year ago I did implement that on the Pharo VM (the Pharo's branch of Cog). It was integrated as far as I remember. >> I copied pasted here the ANN I sent to the mailing list: >> >> >> Hello there, >> >> For a long time, Pharaoers and Squakers have been asking for headless support in the Cocoa VMs just as we have with Carbon VMs. Carbon is becoming a legacy framework so people needed this. >> >> I wanted to thanks Square [i] International for sponsoring me to implement such a support. Not only have they sponsored the development but they have also agreed to release it under MIT license for the community. This headless support will be included in the official Pharo VM and will be, therefore, accessible to everybody. >> >> The project is not yet finished but I do have a demo/prototype that I wanted to share with you so that you can test it and give me feedback. This VM should only work starting at OSX 10.6. >> >> How to use it? Basically it works this way: to have headless, just edit the Info.plist and set the flag LSBackgroundOnly to 1 (add the key if it is not present): >> >> <key>LSBackgroundOnly</key> >> <true/> >> >> When doing this, you don't even need the -headless anymore since, setting LSBackgroundOnly to 1, will cause the same effect (being the flag almost mandatory). If you don't want headless, put it to false or don't even put the key. If you don't set LSBackgroundOnly to 1 but send -headless, the VM will still be headless but you will see a little flash. If this flash bothers you, then set the flag. I am trying to get a way to avoid the "flash" while also avoiding to set LSBackgroundOnly to 1, but I still couldn't find it. Anyway, I think we can live with the current situation. >> >> How to test it? You should run the image with something like RFB or Seaside or whatever you can and then confirm if it is working even if you areheadless. As a matter of testing, I saved an image with seaside running in the port 5555. You can get both, this Seaside image and the VM withheadless from: https://www.dropbox.com/sh/r7qk49bxywk2xce/6N7-fdyx6V >> So if you run the VM headless with that image and go to localhost:5555, you should see that Seaside is running. >> >> I would appreciate if you can test it. And please let me know in which version of OSX you tried. Of course, the more of you who can test it, the better. Notice that this VM was compiled with LLVM GCC 4.2 and it may have some problems in older OSX versions (but I think it shouldn't). I still couldn't compile a VM with GNU GCC 4.2 as I get a crash :( >> >> Expected results? In headless mode, anything should be displayed (no window, no menu, no item in the dock and nothing appear when switching apps). When running headfull, everything should be normal. >> >> Where is the code? The code I have modified to the VM is committed to my own fork of the VM: https://gitorious.org/~marianopeck/cogvm/marianopecks-blessed >> Once the code is ready, I will do a pull request so that it can be integrated. >> >> >> >> On Tue, May 27, 2014 at 7:02 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: >> Hi list, >> >> is it possible to have Pharo run headless while still showing up in the dock? >> >> In the same direction, is it possible to add contextual menu items to the dock menu? Or for what matters, to the top system menu? >> >> Thanks! >> >> -- >> Bernat Romagosa. >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> -- >> Bernat Romagosa. > > > > > -- > Bernat Romagosa. > > > > -- > Bernat Romagosa.

May 30, 2014

Re: [Pharo-users] the mystery of dirty package

by Usman Bhatti

On Fri, May 30, 2014 at 1:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I do not quite understand. > > If it is an overriden method, the dirtyness should not go away when > looking for changes, no? > +1 > In our case, there are no changes found. > > @Usman: what is the problematic method? > Doru, I didn't try it in moose yet. I'll give it a try later in the afternoon and inform you. > > Doru > > > On Fri, May 30, 2014 at 1:11 PM, Usman Bhatti <usman.bhatti(a)gmail.com> > wrote: > >> Tx for the pointer Thierry. >> >> So, I did a small script (because there were 314 methods) to see number >> of non-class-extension methods with and without loading the dirty marker >> package and I could spot the culprit. >> >> Running this script before and after loading the second package and doing >> a difference on the two sets shows determining the overridden method. >> >> methods := (RPackage organizer packageNamed: packageName) definedClasses >> flatCollect: [:class | class methodDict values]. >> methods := methods select: [:aMethod | aMethod category asString >> includesSubstring: '*']. >> >> >> regards, >> usman >> >> >> >> On Wed, May 28, 2014 at 4:30 PM, Goubier Thierry <thierry.goubier(a)cea.fr> >> wrote: >> >>> Hi Usman, >>> >>> look if the loaded package has overrides on other packages. If yes, it >>> will dirty them, and looking for changes will clean them. >>> >>> Thierry >>> >>> Le 28/05/2014 15:59, Usman Bhatti a Ã©crit : >>> >>> Hi, >>>> >>>> It is second time in a week that I have to analyze a problem related to >>>> a package getting dirty because of loading another package. But when >>>> looking for changes, the first package becomes clean again. >>>> >>>> >>>> One occurrence of the problem can be seen in the latest moose image: >>>> - download the latest image here:https://ci.inria.fr/ >>>> moose/job/moose-5.0/ >>>> - monticello browser -> Collections-Abstract -> changes and the package >>>> becomes clean. >>>> >>>> Any idea how to determine which method(s) from the incoming package >>>> might be causing changes in the loaded package? Or generally, how to go >>>> about correcting this problem? >>>> >>>> usman >>>> >>>> >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

May 30, 2014

Re: [Pharo-users] the mystery of dirty package

by Tudor Girba

I do not quite understand. If it is an overriden method, the dirtyness should not go away when looking for changes, no? In our case, there are no changes found. @Usman: what is the problematic method? Doru On Fri, May 30, 2014 at 1:11 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Tx for the pointer Thierry. > > So, I did a small script (because there were 314 methods) to see number of > non-class-extension methods with and without loading the dirty marker > package and I could spot the culprit. > > Running this script before and after loading the second package and doing > a difference on the two sets shows determining the overridden method. > > methods := (RPackage organizer packageNamed: packageName) definedClasses > flatCollect: [:class | class methodDict values]. > methods := methods select: [:aMethod | aMethod category asString > includesSubstring: '*']. > > > regards, > usman > > > > On Wed, May 28, 2014 at 4:30 PM, Goubier Thierry <thierry.goubier(a)cea.fr> > wrote: > >> Hi Usman, >> >> look if the loaded package has overrides on other packages. If yes, it >> will dirty them, and looking for changes will clean them. >> >> Thierry >> >> Le 28/05/2014 15:59, Usman Bhatti a Ã©crit : >> >> Hi, >>> >>> It is second time in a week that I have to analyze a problem related to >>> a package getting dirty because of loading another package. But when >>> looking for changes, the first package becomes clean again. >>> >>> >>> One occurrence of the problem can be seen in the latest moose image: >>> - download the latest image here:https://ci.inria.fr/ >>> moose/job/moose-5.0/ >>> - monticello browser -> Collections-Abstract -> changes and the package >>> becomes clean. >>> >>> Any idea how to determine which method(s) from the incoming package >>> might be causing changes in the loaded package? Or generally, how to go >>> about correcting this problem? >>> >>> usman >>> >>> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> > -- www.tudorgirba.com "Every thing has its own flow"

May 30, 2014

Re: [Pharo-users] the mystery of dirty package

by Usman Bhatti

Tx for the pointer Thierry. So, I did a small script (because there were 314 methods) to see number of non-class-extension methods with and without loading the dirty marker package and I could spot the culprit. Running this script before and after loading the second package and doing a difference on the two sets shows determining the overridden method. methods := (RPackage organizer packageNamed: packageName) definedClasses flatCollect: [:class | class methodDict values]. methods := methods select: [:aMethod | aMethod category asString includesSubstring: '*']. regards, usman On Wed, May 28, 2014 at 4:30 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi Usman, > > look if the loaded package has overrides on other packages. If yes, it > will dirty them, and looking for changes will clean them. > > Thierry > > Le 28/05/2014 15:59, Usman Bhatti a Ã©crit : > > Hi, >> >> It is second time in a week that I have to analyze a problem related to >> a package getting dirty because of loading another package. But when >> looking for changes, the first package becomes clean again. >> >> >> One occurrence of the problem can be seen in the latest moose image: >> - download the latest image here:https://ci.inria.fr/moose/job/moose-5.0/ >> - monticello browser -> Collections-Abstract -> changes and the package >> becomes clean. >> >> Any idea how to determine which method(s) from the incoming package >> might be causing changes in the loaded package? Or generally, how to go >> about correcting this problem? >> >> usman >> >> > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

May 30, 2014