- Pharo-dev - lists.pharo.org

Re: [Pharo-project] FileSystem differences between Pharo-2.0 and Pharo-1.4

by Sean P. DeNigris

Camillo Bruni-3 wrote > > ah ok, so then maybe it's only writeStream / readStream | do? > I think so... -- View this message in context: http://forum.world.st/FileSystem-differences-between-Pharo-2-0-and-Pharo-1-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 8, 2012

Re: [Pharo-project] Versionner: Committing a config commits twice

by Sean P. DeNigris

Juan Pablo Sandoval wrote > > Yes, I worked in this issue. You can try with the development version of > Versionner. > I loaded with: Gofer new url: 'http://ss3.gemstone.com/ss/Versionner'; package: 'ConfigurationOfVersionner'; load. ConfigurationOfVersionner project development load:#('Core' 'Spec'). To use in Pharo 2.0, requires a change for SystemAnnouncer (patched mcz attached to Nabble post [1]). On 1.4 #14457, from VersionnerSpecBrowser>>initializeWidgets, I got: UndefinedObject(Object)>>doesNotUnderstand: #contents: Receiver: nil Arguments and temporary variables: aMessage: contents: [:configuration | self iconForConfiguration: configuration]...etc... exception: MessageNotUnderstood: receiver of "contents:" is nil resumeValue: nil Receiver's instance variables: nil IconListModel>>icons: Receiver: an IconListModel Arguments and temporary variables: aBlock: [:configuration | self iconForConfiguration: configuration] Receiver's instance variables: dependents: nil bindings: a BindingsHolder focusOrder: nil owner: a VersionnerSpecBrowser window: nil spec: nil extentHolder: a NewValueHolder needRebuild: a NewValueHolder isEventForNextFocusBlock: a NewValueHolder isEventForPreviousFocusBlock: a NewValueHolder helpHolder: a NewValueHolder borderWidth: a NewValueHolder borderColor: a NewValueHolder enabledHolder: a NewValueHolder selectionHolder: a SelectionValueHolder listHolder: a CollectionValueHolder menuHolder: a NewValueHolder shortcutsHolder: a NewValueHolder multiSelectionHolder: a DictionaryValueHolder multiSelection: a NewValueHolder allowToSelect: a NewValueHolder listItemsCache: nil filteringBlockHolder: a NewValueHolder sortingBlockHolder: a NewValueHolder wrapBlockHolder: a NewValueHolder iconHolder: a NewValueHolder VersionnerSpecBrowser>>initializeWidgets Receiver: a VersionnerSpecBrowser Arguments and temporary variables: Receiver's instance variables: dependents: a DependentsArray(an IconListModel an IconListModel an IconListMode...etc... bindings: a BindingsHolder focusOrder: nil owner: nil window: nil spec: nil extentHolder: a NewValueHolder needRebuild: a NewValueHolder isEventForNextFocusBlock: a NewValueHolder isEventForPreviousFocusBlock: a NewValueHolder configurations: an IconListModel versions: nil baselines: nil toolbar: nil [1] http://forum.world.st/file/n4643611/Versionner-Core-Model-SeanDeNigris.16.m… Versionner-Core-Model-SeanDeNigris.16.mcz -- View this message in context: http://forum.world.st/Versionner-Committing-a-config-commits-twice-tp463898… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 8, 2012

Re: [Pharo-project] FileSystem differences between Pharo-2.0 and Pharo-1.4

by Camillo Bruni

> >> >> in pharo 1.4 #fileStream and #fileStreamDo: & Co are not working >> properly... >> > > Cami, are you sure? I've been using #fileStreamDo: in 1.4, and it seems to > eventually send: > openFileStream: path writable: writable > | fullPath | > fullPath := self stringFromPath: path. > "redirect over the default implementation" > ^ writable > ifFalse: [ FileStream readOnlyFileNamed: fullPath ] > ifTrue: [ FileStream fileNamed: fullPath ] > which returns aFileStream > > Sean ah ok, so then maybe it's only writeStream / readStream | do?

Aug. 8, 2012

Re: [Pharo-project] I'm going to integrate Metacello into Pharo 2.0

by StÃ©phane Ducasse

esteban I hope to get back soon to shape but today and yesterday I had to slow down and take some naps. What I see is that I'm getting better. Stef On Aug 8, 2012, at 8:15 PM, Esteban Lorenzano wrote: > > On Aug 8, 2012, at 8:06 PM, Francois Stephany <tulipe.moutarde(a)gmail.com> wrote: > >> I wonder if it's necessary. I like to update a running (seaside) app using Metacello while it's running. >> >> Am I the only one doing that? >> >> On 08/08/12 03:22, Esteban Lorenzano wrote: >>> Of course, I will make sure that it is unloaded in a #cleanUpForProduction. >> > > no, you are not the only one, I use it for my running projects too :) > > but well... if it is not in your project you always can re-load it with #ensureMetacello > > all of this will change when I finish the new release process, btw... but for that I need time to work on it :) > > Esteban

Aug. 8, 2012

Re: [Pharo-project] I'm going to integrate Metacello into Pharo 2.0

by Francois Stephany

Oh right, that makes sense. Haha time is scarce, good luck! On 08/08/12 11:15, Esteban Lorenzano wrote: > > On Aug 8, 2012, at 8:06 PM, Francois Stephany <tulipe.moutarde(a)gmail.com> wrote: > >> I wonder if it's necessary. I like to update a running (seaside) app using Metacello while it's running. >> >> Am I the only one doing that? >> >> On 08/08/12 03:22, Esteban Lorenzano wrote: >>> Of course, I will make sure that it is unloaded in a #cleanUpForProduction. >> > > no, you are not the only one, I use it for my running projects too :) > > but well... if it is not in your project you always can re-load it with #ensureMetacello > > all of this will change when I finish the new release process, btw... but for that I need time to work on it :) > > Esteban >

Aug. 8, 2012

Re: [Pharo-project] FileSystem differences between Pharo-2.0 and Pharo-1.4

by Sean P. DeNigris

Camillo Bruni-3 wrote > > in pharo 1.4 #fileStream and #fileStreamDo: & Co are not working > properly... > Cami, are you sure? I've been using #fileStreamDo: in 1.4, and it seems to eventually send: openFileStream: path writable: writable | fullPath | fullPath := self stringFromPath: path. "redirect over the default implementation" ^ writable ifFalse: [ FileStream readOnlyFileNamed: fullPath ] ifTrue: [ FileStream fileNamed: fullPath ] which returns aFileStream Sean -- View this message in context: http://forum.world.st/FileSystem-differences-between-Pharo-2-0-and-Pharo-1-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 8, 2012

Re: [Pharo-project] FileSystem differences between Pharo-2.0 and Pharo-1.4

by StÃ©phane Ducasse

On Aug 8, 2012, at 7:35 PM, Camillo Bruni wrote: > nope they won't work either... > I changed all of that in 2.0's FS overhaul. Maybe we should port these changes back to 1.4 to support a working version of FS there. > > All the stream selectors in 1.4 create a FSFileStream or so, which is a incomplete reimplementation of FileStream. They might work for a very limited set of operations, but AFAIK there is a big mem leak of low level file handlers which eventually will crash the VM. > > Porting the changes back to 1.4 for the FileStream subpart should be a 0.5h task (for me ;)). > > If esteban agrees to include these changes in 1.4 I am willing to create a patch :) thanks camillo I think that this is a good move. > > > On 2012-08-08, at 19:32, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> Cami, >> >> How about writeStream* and readStream* are those working? It looks like you used those variants in your FileTree pull request... >> >> Thanks, >> >> Dale >> >> ----- Original Message ----- >> | From: "Camillo Bruni" <camillobruni(a)gmail.com> >> | To: Pharo-project(a)lists.gforge.inria.fr >> | Sent: Wednesday, August 8, 2012 10:06:18 AM >> | Subject: Re: [Pharo-project] FileSystem differences between Pharo-2.0 and Pharo-1.4 >> | >> | in pharo 1.4 #fileStream and #fileStreamDo: & Co are not working >> | properly... >> | You'll still have to use something like >> | FileStream fileNamed: reference fullName >> | otherwise it should more or less work. >> | >> | >> | On 2012-08-08, at 18:36, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> | >> | > I'm starting a port of FileTree to Pharo-2.0 and I'm planning on >> | > using Pharo-1.4 (summer) to do the actual port, since I can't run >> | > my development environment in Pharo-2.0 (chicken and egg problem). >> | > >> | > I'm wondering if there are any significant differences between the >> | > FileSystem implementations on the two platforms that I should be >> | > aware of... >> | > >> | > Dale >> | > >> | >> | >> | >> > >

Aug. 8, 2012

Re: [Pharo-project] StartupPreferences gone wild in 1.4

by StÃ©phane Ducasse

On Aug 8, 2012, at 6:39 PM, Sean P. DeNigris wrote: > StartupPreferences calls #loadStartupScript (loading all the > StartupPreferences) ~10 times!! > > Also, will there be another 1.4 bug fix release? yes but probably with only severe show stopper. I guess that this one can do in the 1.4 next version > > Thanks, > Sean > > > > -- > View this message in context: http://forum.world.st/StartupPreferences-gone-wild-in-1-4-tp4643586.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 8, 2012

Re: [Pharo-project] I'm going to integrate Metacello into Pharo 2.0

by Esteban Lorenzano

On Aug 8, 2012, at 8:06 PM, Francois Stephany <tulipe.moutarde(a)gmail.com> wrote: > I wonder if it's necessary. I like to update a running (seaside) app using Metacello while it's running. > > Am I the only one doing that? > > On 08/08/12 03:22, Esteban Lorenzano wrote: >> Of course, I will make sure that it is unloaded in a #cleanUpForProduction. > no, you are not the only one, I use it for my running projects too :) but well... if it is not in your project you always can re-load it with #ensureMetacello all of this will change when I finish the new release process, btw... but for that I need time to work on it :) Esteban

Aug. 8, 2012

Re: [Pharo-project] I'm going to integrate Metacello into Pharo 2.0

by Francois Stephany

I wonder if it's necessary. I like to update a running (seaside) app using Metacello while it's running. Am I the only one doing that? On 08/08/12 03:22, Esteban Lorenzano wrote: > Of course, I will make sure that it is unloaded in a #cleanUpForProduction.

Aug. 8, 2012