April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with Traits, Ring, RPcakage and Obsoletes

by Mariano Martinez Peck

On Thu, Apr 19, 2012 at 12:21 AM, Fernando Olivero <fernando.olivero(a)usi.ch>wrote: > Hi Mariano, we should be able to "silently" create temporal classes, > without notifying the system. > > Have you tried something like this: > > > default := RPackage organizer. > [ > default unregister. > SystemChangeNotifier uniqueInstance doSilently: [ > Object subclass: #TemporalClassForFuel > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'FuelTests']. > > ] ensure:[ > (Smalltalk globals classNamed: 'TemporalClassForFuel' ) > removeFromSystem:false. > default register]. > > Hi Fernando. Thanks, but it doesn't seem to work. I put a halt in SystemChangeNotifier >> classAdded: aClass inCategory: aCategoryName Then I modfified ClassFactoryForTestCase: newSubclassOf: aClass instanceVariableNames: ivNamesString classVariableNames: classVarsString category: category | newClass default | default := RPackage organizer. [ default unregister. SystemChangeNotifier uniqueInstance doSilently: [ newClass := aClass subclass: self newName instanceVariableNames: ivNamesString classVariableNames: classVarsString poolDictionaries: '' category: (self packageName, '-', category) asSymbol. ]. ] ensure:[ default register]. self createdClasses add: newClass. ^newClass And when creating a class, it still halts on #classAdded: aClass inCategory: aCategoryName Look attached screenshot. Thanks > Saludos, > Fernando > > On Wed, Apr 18, 2012 at 11:49 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Hi guys. I am running some tests with Fuel. In such test I create > classes and traits. The problem is that I get a: "MessageNotUnderstood: > receiver of "isProvided" is nil" > > Everything starts (it seems) when I do #addToComposition: and I > receive a MethodRecategorized event and RPackage calls > #systemMethodRecategorizedActionFrom: > > There, the problem is with -> method isProvidedByATrait > > the class of the method is 'AnObsoleteClassForTestToBeDeleted1' > > And the error finally arrives to #providedLocatedMethod where it does > "each method isProvided" the problem is that "each" is a > RGMethodDefinition with everything in nil except 'name' and 'annotations'. > > I attach PharoDebug.log. > > Any help is really appreaciated. > > > > Thanks, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- Mariano http://marianopeck.wordpress.com

April 19, 2012

Re: [Pharo-project] OSProcess - is process done?

by GastÃ³n Dall' Oglio

Forget to say something, if I unload and reload the OSProcess package, then starts working well again. El 19 de abril de 2012 09:27, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com > escribiÃ³: > Hi. > > I use OSProcess in Windows (XP and Seven) and I notice that it hang when I > open the image with OSProcess already loaded. I try in > Seaside-3.0.7-OneClick and Pharo-1.4-14438-OneClick, and I get same error. > > Step to reproduce: > 1. Load OSProcess in a clean image. I use this snippet: > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOSProcess'; > load. > ((Smalltalk at: #ConfigurationOfOSProcess) project version: #stable) load. > > 2. Save and quit. > 3. Open same image, with OSProcess already load. > 4. Inspect this: > OSProcess command: 'dir'. > > You can notice that process never is completed, however the operating > system window where running is already closed. If you inspect previous code > after step 1 (before save and quit) the process is completed. > > In another hand, I notice that in the ConfigurationOfOSProcess>>baseline44 > there is a OSProcess-Tests package, but this there isn't in the repo, and > the tests classes are loaded with just load OSProcess package. I don't want > load the tests in the deploy images. Maybe I do something wrong. > > Regards. > > > El 18 de abril de 2012 21:07, David T. Lewis <lewis(a)mail.msen.com>escribiÃ³: > > On Wed, Apr 18, 2012 at 02:47:38PM -0700, Sean P. DeNigris wrote: >> > Sometimes, OSProcess hangs even though the underlying command has >> completed. >> > >> > For example, on Mac 10.7.3: >> > p := PipeableOSProcess waitForCommand: 'ps -ax -o pid,command' >> "never >> > returns" >> > even though "p upToEnd" immediately returns the output if I use >> #command: >> > instead of waiting. >> > >> > How best to handle this? >> > >> > Thanks. >> > Sean >> >> PipeableOSProcess class>>waitForCommand: is just a loop that waits for >> the command (running in an external process) to complete. If the command >> does not complete, it keeps looping. >> >> The program that you are running (/bin/ps) will try to exit after it has >> written all of its output to its standard output, which in this case is >> a pipe connected back to your VM. But if the pipe fills up (the operating >> system will put some limit on this), the /bin/ps program will block trying >> to write to its output until somebody reads some of that data from the >> pipe. If nobody reads the output, the /bin/ps program will just block >> forever, and it will seem to be "stuck" and will never exit. >> >> What to do? Read the data from the output of the PipeableOSProcess. The >> /bin/ps program will then be unblocked, and it will finish writing its >> output and then exit normally. >> >> Dave >> >> >> >

April 19, 2012

Re: [Pharo-project] OSProcess - is process done?

by GastÃ³n Dall' Oglio

Hi. I use OSProcess in Windows (XP and Seven) and I notice that it hang when I open the image with OSProcess already loaded. I try in Seaside-3.0.7-OneClick and Pharo-1.4-14438-OneClick, and I get same error. Step to reproduce: 1. Load OSProcess in a clean image. I use this snippet: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOSProcess'; load. ((Smalltalk at: #ConfigurationOfOSProcess) project version: #stable) load. 2. Save and quit. 3. Open same image, with OSProcess already load. 4. Inspect this: OSProcess command: 'dir'. You can notice that process never is completed, however the operating system window where running is already closed. If you inspect previous code after step 1 (before save and quit) the process is completed. In another hand, I notice that in the ConfigurationOfOSProcess>>baseline44 there is a OSProcess-Tests package, but this there isn't in the repo, and the tests classes are loaded with just load OSProcess package. I don't want load the tests in the deploy images. Maybe I do something wrong. Regards. El 18 de abril de 2012 21:07, David T. Lewis <lewis(a)mail.msen.com> escribiÃ³: > On Wed, Apr 18, 2012 at 02:47:38PM -0700, Sean P. DeNigris wrote: > > Sometimes, OSProcess hangs even though the underlying command has > completed. > > > > For example, on Mac 10.7.3: > > p := PipeableOSProcess waitForCommand: 'ps -ax -o pid,command' "never > > returns" > > even though "p upToEnd" immediately returns the output if I use > #command: > > instead of waiting. > > > > How best to handle this? > > > > Thanks. > > Sean > > PipeableOSProcess class>>waitForCommand: is just a loop that waits for > the command (running in an external process) to complete. If the command > does not complete, it keeps looping. > > The program that you are running (/bin/ps) will try to exit after it has > written all of its output to its standard output, which in this case is > a pipe connected back to your VM. But if the pipe fills up (the operating > system will put some limit on this), the /bin/ps program will block trying > to write to its output until somebody reads some of that data from the > pipe. If nobody reads the output, the /bin/ps program will just block > forever, and it will seem to be "stuck" and will never exit. > > What to do? Read the data from the output of the PipeableOSProcess. The > /bin/ps program will then be unblocked, and it will finish writing its > output and then exit normally. > > Dave > > >

April 19, 2012

Re: [Pharo-project] TWM on Pharo 1.4

by Benjamin

Yep, there is also a Nautilus flag, feel free to use it ;) Thanks in advance, Ben On Apr 19, 2012, at 2:11 PM, Frank Shearar wrote: > Are you happy with a bug just on the main Pharo buglist? > > frank > > On 19 April 2012 13:07, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> Please, if you have a way to reproduce it, open a bug entry :) >> >> I am a bit busy right now, but I promise to have a look asap ;) >> >> Ben >> >> >> On Apr 19, 2012, at 1:48 PM, Frank Shearar wrote: >> >>> On 19 April 2012 12:11, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>> It was clearly a Nautilus problem (and I just fixed it) >>>> >>>> The problem is that the Browser API is not clearly defined, messy, and far too huge :s >>>> So I add the methods step by step when someone encounter an issue. >>>> >>>> >>>> Thanks for reporting, >>> >>> Thanks for fixing, Ben! I just needed to load >>> Nautilus-BenjaminVanRyseghem.251 and I'm good to go! >>> >>> Er, but I just found another problem. In my newly-added Browser I went >>> to ConfigurationOfTilingWindowManager>>#version13: (so I could prepare >>> a patch for Laurent), and got a SubscriptOufOfBounds: 1 in >>> CompiledMethod(Object)>>errorSubscriptBounds:. I can't reproduce this >>> in a vanilla Pharo-1.4 and your just-released ConfigurationOfNautilus, >>> so I'll see if I can't get a shorter "here's how to reproduce the >>> problem" recipe later. >>> >>> frank >>> >>>> Ben >>>> >>>> On Apr 19, 2012, at 12:24 PM, Frank Shearar wrote: >>>> >>>>> Hi Laurent, >>>>> >>>>> I noticed your announcement and eagerly fired up the latest TWM using >>>>> Cog r2550. I selected "New browser" under "Browser actions" and ran >>>>> into an MNU: Nautilus class >> #openBrowser. >>>>> >>>>> That obviously sounds like a Nautilus problem; I bring it to your >>>>> attention just because it's your release, and you'd know better than I >>>>> whether it's Nautilus or a configuration problem. >>>>> >>>>> Thanks for the release though! >>>>> >>>>> frank >>>>> >>>> >>>> >>> >> >> >

April 19, 2012

Re: [Pharo-project] TWM on Pharo 1.4

by Frank Shearar

Are you happy with a bug just on the main Pharo buglist? frank On 19 April 2012 13:07, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Please, if you have a way to reproduce it, open a bug entry :) > > I am a bit busy right now, but I promise to have a look asap ;) > > Ben > > > On Apr 19, 2012, at 1:48 PM, Frank Shearar wrote: > >> On 19 April 2012 12:11, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>> It was clearly a Nautilus problem (and I just fixed it) >>> >>> The problem is that the Browser API is not clearly defined, messy, and far too huge :s >>> So I add the methods step by step when someone encounter an issue. >>> >>> >>> Thanks for reporting, >> >> Thanks for fixing, Ben! I just needed to load >> Nautilus-BenjaminVanRyseghem.251 and I'm good to go! >> >> Er, but I just found another problem. In my newly-added Browser I went >> to ConfigurationOfTilingWindowManager>>#version13: (so I could prepare >> a patch for Laurent), and got a SubscriptOufOfBounds: 1 in >> CompiledMethod(Object)>>errorSubscriptBounds:. I can't reproduce this >> in a vanilla Pharo-1.4 and your just-released ConfigurationOfNautilus, >> so I'll see if I can't get a shorter "here's how to reproduce the >> problem" recipe later. >> >> frank >> >>> Ben >>> >>> On Apr 19, 2012, at 12:24 PM, Frank Shearar wrote: >>> >>>> Hi Laurent, >>>> >>>> I noticed your announcement and eagerly fired up the latest TWM using >>>> Cog r2550. I selected "New browser" under "Browser actions" and ran >>>> into an MNU: Nautilus class >> #openBrowser. >>>> >>>> That obviously sounds like a Nautilus problem; I bring it to your >>>> attention just because it's your release, and you'd know better than I >>>> whether it's Nautilus or a configuration problem. >>>> >>>> Thanks for the release though! >>>> >>>> frank >>>> >>> >>> >> > >

April 19, 2012

Re: [Pharo-project] TWM on Pharo 1.4

by Benjamin

Please, if you have a way to reproduce it, open a bug entry :) I am a bit busy right now, but I promise to have a look asap ;) Ben On Apr 19, 2012, at 1:48 PM, Frank Shearar wrote: > On 19 April 2012 12:11, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> It was clearly a Nautilus problem (and I just fixed it) >> >> The problem is that the Browser API is not clearly defined, messy, and far too huge :s >> So I add the methods step by step when someone encounter an issue. >> >> >> Thanks for reporting, > > Thanks for fixing, Ben! I just needed to load > Nautilus-BenjaminVanRyseghem.251 and I'm good to go! > > Er, but I just found another problem. In my newly-added Browser I went > to ConfigurationOfTilingWindowManager>>#version13: (so I could prepare > a patch for Laurent), and got a SubscriptOufOfBounds: 1 in > CompiledMethod(Object)>>errorSubscriptBounds:. I can't reproduce this > in a vanilla Pharo-1.4 and your just-released ConfigurationOfNautilus, > so I'll see if I can't get a shorter "here's how to reproduce the > problem" recipe later. > > frank > >> Ben >> >> On Apr 19, 2012, at 12:24 PM, Frank Shearar wrote: >> >>> Hi Laurent, >>> >>> I noticed your announcement and eagerly fired up the latest TWM using >>> Cog r2550. I selected "New browser" under "Browser actions" and ran >>> into an MNU: Nautilus class >> #openBrowser. >>> >>> That obviously sounds like a Nautilus problem; I bring it to your >>> attention just because it's your release, and you'd know better than I >>> whether it's Nautilus or a configuration problem. >>> >>> Thanks for the release though! >>> >>> frank >>> >> >> >

April 19, 2012

Re: [Pharo-project] lagging in the interface

by StÃ©phane Ducasse

On Apr 17, 2012, at 4:25 PM, Hilaire Fernandes wrote: > When using Pharo under tablet (both iPad and Android), we have noted > some lag in the user interface when clicking a button. Indeed sometime > you have to press twice a button to get the press event caught by Pharo. > > This problem does not occur with Squeak 3.9 and same StackVM. > > Any idea? No. Do you have a case? Stef

April 19, 2012

Re: [Pharo-project] Domain pharo.org

by StÃ©phane Ducasse

excellent! Stef > ... we do have the domain pharo.org now (configured to forward to pharo-project.org) > > > Marcus

April 19, 2012

Re: [Pharo-project] TWM on Pharo 1.4

by Frank Shearar

On 19 April 2012 12:11, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > It was clearly a Nautilus problem (and I just fixed it) > > The problem is that the Browser API is not clearly defined, messy, and far too huge :s > So I add the methods step by step when someone encounter an issue. > > > Thanks for reporting, Thanks for fixing, Ben! I just needed to load Nautilus-BenjaminVanRyseghem.251 and I'm good to go! Er, but I just found another problem. In my newly-added Browser I went to ConfigurationOfTilingWindowManager>>#version13: (so I could prepare a patch for Laurent), and got a SubscriptOufOfBounds: 1 in CompiledMethod(Object)>>errorSubscriptBounds:. I can't reproduce this in a vanilla Pharo-1.4 and your just-released ConfigurationOfNautilus, so I'll see if I can't get a shorter "here's how to reproduce the problem" recipe later. frank > Ben > > On Apr 19, 2012, at 12:24 PM, Frank Shearar wrote: > >> Hi Laurent, >> >> I noticed your announcement and eagerly fired up the latest TWM using >> Cog r2550. I selected "New browser" under "Browser actions" and ran >> into an MNU: Nautilus class >> #openBrowser. >> >> That obviously sounds like a Nautilus problem; I bring it to your >> attention just because it's your release, and you'd know better than I >> whether it's Nautilus or a configuration problem. >> >> Thanks for the release though! >> >> frank >> > >

April 19, 2012

Re: [Pharo-project] moose build broke due to ConfigurationOfNautilus

by Benjamin

You are right, I had totally forgotten than Moose was depending on Nautilus :s But now, it should not change for a while (the configuration API ^^) Sorry again, Ben On Apr 19, 2012, at 1:15 PM, Tudor Girba wrote: > Hi, > > It's not a problem. > > I fixed the problem easily, but I was just raising the issue so that > we can prevent it in the future, perhaps through communication. > > Cheers, > Doru > > > On Thu, Apr 19, 2012 at 1:05 PM, Benjamin > <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> I am sorry :( >> >> But we were preparing Nautilus for Pharo 2.0, and we wanted to reduce the amount of groups to not disturb to much users. >> >> So now there are 'core' and 'release' groups... >> >> >> Sorry again, and thank you for using Nautilus :) >> >> Ben >> >> On Apr 19, 2012, at 8:17 AM, Tudor Girba wrote: >> >>> Hi, >>> >>> The Moose build just broke due to the loadRefactorings method being removed from ConfigurationOfNautilus. >>> >>> In general, it would be great to remove as little methods as possible from Configuration classes. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Speaking louder won't make the point worthier." >>> >>> >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

April 19, 2012