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

Re: [Pharo-project] FilePlugin changed it's behavior?

by Sean P. DeNigris

Sean P. DeNigris wrote > > There's something weird and scary going on with FilePlugin... > * Issue 6050: ensureDirectory looks strange > http://code.google.com/p/pharo/issues/detail?id=6050 > * http://forum.world.st/FilePlugin-bug-td4634074.html > Fixed... see http://forum.world.st/FileReference-gt-gt-exists-not-working-td4634285.html -- View this message in context: http://forum.world.st/FilePlugin-changed-it-s-behavior-tp4633565p4634362.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 11, 2012

Re: [Pharo-project] FileReference >> #exists not working?

by Sean P. DeNigris

Sean P. DeNigris wrote > > * Issue 6050: ensureDirectory looks strange > http://code.google.com/p/pharo/issues/detail?id=6050 > The code snippet works now with the Jenkins Cog VM at https://ci.lille.inria.fr/pharo/job/Cog-VM/ (build #45 - last successful) Good... that was a scary one. How was it resolved? -- View this message in context: http://forum.world.st/FileReference-exists-not-working-tp4634285p4634359.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 11, 2012

[Pharo-project] FileReference should throw error when deleting unexisting files?

by Mariano Martinez Peck

So if we now do: 'afileThatDoesntExist' asFileReference delete I get a PrimitiveFailed. If this is what we want, can I add: FileReference >> deleteIfExists self exists ifTrue: [ self delete] or something like that? because lots of places (tearDown of tests) I want to remove crao which may or may not exist... thanks -- Mariano http://marianopeck.wordpress.com

June 11, 2012

Re: [Pharo-project] FileReference >> #exists not working?

by Mariano Martinez Peck

On Mon, Jun 11, 2012 at 5:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > both were same problem and both *should* (not completely sure, he) work on > latest vm, please check :) > please, tell me EXACTLY which job. https://ci.lille.inria.fr/pharo/view/VM-dev/ has 6 jobs. https://ci.lille.inria.fr/pharo/view/Cog/ has 11 jobs https://ci.lille.inria.fr/pharo/view/VM/ has 1 job. so...which one? > (if we can get jenkings to work again, :) > > > > On Jun 11, 2012, at 4:20 PM, Sean P. DeNigris wrote: > > > > > EstebanLM wrote > >> > >> can be related to http://code.google.com/p/pharo/issues/detail?id=5693 > >> > > > > That one was effecting symlinks. It's more probably related to... > > > > http://forum.world.st/FilePlugin-changed-it-s-behavior-td4633565.html > > There's something weird and scary going on with FilePlugin... > > * Issue 6050: ensureDirectory looks strange > > http://code.google.com/p/pharo/issues/detail?id=6050 > > * http://forum.world.st/FilePlugin-bug-td4634074.html > > > > -- > > View this message in context: > http://forum.world.st/FileReference-exists-not-working-tp4634285p4634300.ht… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- Mariano http://marianopeck.wordpress.com

June 11, 2012

[Pharo-project] FileStream not opening file, if file opened elsewhere

by Jimmie Houchin

Hello, I have run into what seems to be a bug in FileStream/StandardFileStream. I attempt to open a file. f := StandardFileStream oldFileNamed: 'pathToFile'. If file is open elsewhere for editing, f = nil. If the file is not open elsewhere, then the file opens properly. If I attempt to open read only. f := StandardFileStream readOnlyFileNamed: 'pathToFile'. Opens the file properly. It seems to me that returning nil is an ugly response. I had no knowledge why the file was not opening. At the time did not know I had it open in another application. Failing silently is not nice. I would have preferred an Error message or something telling me that the file was open elsewhere and even possibly letting me open as readOnly. When we attempt to open a file with a filename that does not exist, we get the nice option of either selecting (or correcting) a file name which exists or creating a new file with the specified name. With a small amount of naive browsing, I was not able to find where the understanding of the file being locked elsewhere is found. So I only offer my experience. Thanks. Jimmie

June 11, 2012

[Pharo-project] Undeclared in Spec

by Pavel Krivanek

Hi, we have got two new Undeclared and thus failing testUndeclared. Both Undeclared are related to Spec - references to instance variable widget and references to global SpecLayout. -- Pavel

June 11, 2012

[Pharo-project] [update 2.0] #20129

by StÃ©phane Ducasse

20129 ----- - Issue 5967: Use FileSystem for everything (part Five). **THANKS** camillo for this effort.... Collections-Abstract-CamilloBruni.165 Collections-Native-CamilloBruni.7 Collections-Arrayed-CamilloBruni.68 MenuRegistration-CamilloBruni.39 Polymorph-Widgets-CamilloBruni.641 System-CommandLine-CamilloBruni.23 System-Change Notification-MarcusDenker.25 Tools-CamilloBruni.859 Refactoring-Spelling-CamilloBruni.30 System-Platforms-CamilloBruni.20 System-Text-CamilloBruni.211 StartupPreferences-CamilloBruni.47 System-Installers-MarcusDenker.18 Spec-Tools-CamilloBruni.27 System-Object Storage-CamilloBruni.160 System-FilePackage-CamilloBruni.67 Zinc-HTTP-CamilloBruni.257 Zinc-Tests-CamilloBruni.132 KernelTests-CamilloBruni.411 Ring-Core-Kernel-CamilloBruni.58 Ring-Tests-Kernel-CamilloBruni.26 Traits-CamilloBruni.418 Ring-Monticello-CamilloBruni.3

June 11, 2012

Re: [Pharo-project] Pharo 2.0 Jenkins build failing

by Sean P. DeNigris

Fix attached to: Issue 6055: [BUG] New System Progress doesn't work when headless http://code.google.com/p/pharo/issues/detail?id=6055 > 2.0 > > When headless and displaying progress, with used to be a no-op, now there > is a BlockClosure DNU label:. This is because progress used to use a block > that was pretending to be a class, so #value: would get sent everywhere, > with the "selector" as the argument (e.g. value: #label). Now that we have > a real progress object, we are sending #label: explicitly. Since > CommandLineUIManager wasn't updated, it's still passing a block ([:bar > |]), which obviously doesn't understand #label: > > The attached st files fix CommandLineUIManager to use a > DummySystemProgressItem instead of a block. > > There will be more refactoring of the entire system progress framework, > but let's get it working, one step at a time. > > N.B. The DummySystemProgressItem was temporarily placed in its own > category to avoid making Morphic-Widgets dirty, which would be wiped out > as the updates to 20119 are loaded > -- View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634339.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 11, 2012

[Pharo-project] [update 2.0] #20128

by StÃ©phane Ducasse

20128 ----- - Issue 5967: Use FileSystem for everything (part Four). **THANKS** camillo for this effort.... Making sure we can save the image :) Yes previous version was in a strange stateâ¦ Stef and Camillo

June 11, 2012

[Pharo-project] [update 2.0] #20127

by StÃ©phane Ducasse

20127 ----- - Issue 5967: Use FileSystem for everything (part three). **THANKS** camillo for this effort.... Files-CamilloBruni.ducasse.251 System-FileRegistry-CamilloBruni.16 System-Support-CamilloBruni.634 Kernel-CamilloBruni.1103 Stef and Camillo

June 11, 2012