[Pharo-dev] Serious problem with ConfigurationOfBootstrap - Error: Apparent loop in import expansion
Hello, The load of the 0.12.2 version gives a error. Quite annoying as Boostrap is quite needed for webdev :-( What changed? Loading 0.12.2 of ConfigurationOfBootstrap...'Errors in script loaded from /Users/philippeback/project/BuildBaseWorker.st' Error: Apparent loop in import expansion MetacelloVersionConstructor(Object)error: MetacelloVersionConstructorcollectAllVersionsFromVersionImportPragmasInto:using:satisfiedPragmas: MetacelloVersionConstructorcalculate:project: MetacelloVersionConstructoron:project: in Block: [ :cache | ... MetacelloPharo30Platform(MetacelloPlatform)stackCacheFor:cacheClass:at:doing: in Block: [ :dict | ... MetacelloPharo30Platform(MetacelloPlatform)useStackCacheDuring:defaultDictionary: in Block: [ ^ aBlock value: dict ] BlockClosureon:do: MetacelloPharo30Platform(MetacelloPlatform)useStackCacheDuring:defaultDictionary: MetacelloPharo30Platform(MetacelloPlatform)stackCacheFor:cacheClass:at:doing: MetacelloPharo30Platform(MetacelloPlatform)stackCacheFor:at:doing: MetacelloVersionConstructoron:project: MetacelloVersionConstructor classon:project: ConfigurationOfSeaside3project MetacelloMCProjectSpecprojectClassProject MetacelloMCProjectSpecversion MetacelloMCProjectSpec(MetacelloProjectSpec)versionOrNil in Block: [ self version ] BlockClosureon:do: MetacelloMCProjectSpec(MetacelloProjectSpec)versionOrNil MetacelloMCProjectSpecloadPackageList MetacelloMCVersionpackageAndProjectNamesToLoad:loader: in Block: [ :prj | ... OrderedCollectiondo: MetacelloMCVersionpackageAndProjectNamesToLoad:loader: MetacelloMCVersiondefaultPackageNamesToLoad: MetacelloMCVersiondoLoadRequiredFromArray: in Block: [ ... BlockClosureensure: MetacelloMCVersiondoLoadRequiredFromArray: MetacelloMCVersionload GoferMetacelloLoadloadConfiguration GoferMetacelloLoadexecute Goferexecute:do:
Re: [Pharo-dev] Some methods missing in Behavior
On 10 Oct 2014, at 15:25, Marcus Denker marcus.den...@inria.fr wrote: On 10 Oct 2014, at 14:36, jdelg...@lsi.upc.edu mailto:jdelg...@lsi.upc.edu wrote: Yes, evaluate: (Behavior new) compile: 'thisIsATest ^2' ah, that indeed should work… I will check and fix it in Pharo3 and Pharo4 For Pharo4: https://pharo.fogbugz.com/f/cases/14215/Fix-for-Behavior-new-compile
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40298 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] e02b61: 40298
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: e02b61b339b6a93f43e7d05042b8de38244c30c3 https://github.com/pharo-project/pharo-core/commit/e02b61b339b6a93f43e7d05042b8de38244c30c3 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-10-11 (Sat, 11 Oct 2014) Changed paths: M Manifest-Core.package/extension/RBClassEnvironment/instance/smallLintCritics.st A Manifest-Core.package/extension/RBDoNotSendSuperInitializeInClassSideRule/class/uniqueIdentifierName.st A Manifest-Core.package/extension/RBDoNotSendSuperInitializeInClassSideRule/instance/category.st M Manifest-Core.package/extension/RBVariableEnvironment/instance/smallLintCritics.st M Monticello.package/MCPackageManager.class/class/event registration/registerInterestOnSystemChangesOnAnnouncer_.st A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/README.md A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/definition.st A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/instance/accessing/group.st A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/instance/accessing/name.st A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/instance/initialization/initialize.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script298.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40298.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 40298 14213 Replace Announcer#on:send:to:s senders in Monticello https://pharo.fogbugz.com/f/cases/14213 14098 allClassesAndTraits significantly different from allClassesAndTraitsDo: https://pharo.fogbugz.com/f/cases/14098 10288 Add a lint rule to check that class initialize method does not calls super initialize https://pharo.fogbugz.com/f/cases/10288 http://files.pharo.org/image/40/40298.zip
[Pharo-dev] [Pharo4] just 5 tests failing
Here are all the Failing tests in Pharo4, with a link to the issue tracker. We should try to get it green, not much left to do: Related to NativeBoost: ReleaseTest#testMethodsWithUnboundGlobals https://pharo.fogbugz.com/f/cases/13982 https://pharo.fogbugz.com/f/cases/13982 AJx64AssemblerTests#testStringOps64Mnemonics https://pharo.fogbugz.com/f/cases/14033 https://pharo.fogbugz.com/f/cases/14033 Related to GT: ——— ReleaseTest#testUndeclared https://pharo.fogbugz.com/f/cases/14168 https://pharo.fogbugz.com/f/cases/14168 ClassTest#testClassRespectsPolymorphismWithTrait https://pharo.fogbugz.com/f/cases/14172 https://pharo.fogbugz.com/f/cases/14172 ReleaseTest ObsoleteTest#testFixObsoleteSharedPools https://pharo.fogbugz.com/f/cases/14165 https://pharo.fogbugz.com/f/cases/14165
Re: [Pharo-dev] OSProcess in 3.0
On Fri, Oct 10, 2014 at 01:32:27PM -0400, David T. Lewis wrote: Le 10/10/2014 17:52, David T. Lewis a ?crit : 2014-10-10 14:09 GMT+02:00 David T. Lewis le...@mail.msen.com: Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area. Hi Dave, Would it has a chance of slowing down things a lot? There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it. I don't this so, but I am not certain. The update for PipeableOSProcess affects only the methods in PipeableOSProcess classcommand: and closely related methods. If GitFileTree is using that idiom, then it is certainly possible that I have introduced a bug that does not show up in my unit tests. Typical code in GitFileTree is this: [ c := PipeableOSProcess command: ''. output := c output. ... ] ensure: [c closePipes] Maybe it's triggering something. Thierry Hmmm... I wonder if the #closePipes is causing a problem now. I don't know if I ever tested to see if sending closePipes works after the pipes are already closed, and my recent change closes the pipes after #output is evaluated. I'll check it when I get home. I tried this in both Squeak trunk and Pharo 3.0: (1 to: 100) collect: [:e | | c output | [c := PipeableOSProcess command: 'ls -lt'. output := c output. ] ensure: [c closePipes]. output ]. I get the expected results, and no open file handles left over. The #closePipes is no longer needed, so this can now be simplified as follows, which also leaves no open file handles: (1 to: 100) collect: [:e | (PipeableOSProcess command: 'ls -lt') output]. I am not sure what the issue is when used with GitFileTree, but it does not look like the change to PipeableOSProcess class command: is directly involved. But ... I'm probably missing something. If you are fairly sure the that problem is related to the the PipeableOSProcess change, then the only other thing I can think of right now is that there may be some other places in GitFileTree where PipeableOSProcess is being used in a different way, and maybe I caused a problem there due the the change in the #command: methods. But this a a complete guess, I really do not know. Dave
