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

Re: [Pharo-project] Question about RPackage (bug?)

by Mariano Martinez Peck

On Thu, Aug 9, 2012 at 1:25 PM, Fernando Olivero <fernando.olivero(a)usi.ch>wrote: > Hi Mariano, > > I've been using RPackage so i stumbled on the same "problem". > RPackage maps System Categories (one to one), thus your problem > happens because there's no category named 'RPackage'. > > But for the rest it works. For example: (RPackageOrganizer default packageNamed: 'AST-Core') And there is no category 'AST-Core'. Moreover, I have just discovered that if I evaluate: RPackageOrganizer initialize. Then it appears :) > For example evaluate (RPackageOrganizer default packageNamed: > 'RPackage-Core') > > Saludos, > Fernando > > On Thu, Aug 9, 2012 at 12:24 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > (MCWorkingCopy allManagers collect: [:p | p package name] ) includes: > 'RPackage' -> true > > > > (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound > > > > bug? > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 9, 2012

Re: [Pharo-project] Question about RPackage (bug?)

by Fernando Olivero

Hi Mariano, I've been using RPackage so i stumbled on the same "problem". RPackage maps System Categories (one to one), thus your problem happens because there's no category named 'RPackage'. For example evaluate (RPackageOrganizer default packageNamed: 'RPackage-Core') Saludos, Fernando On Thu, Aug 9, 2012 at 12:24 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > (MCWorkingCopy allManagers collect: [:p | p package name] ) includes: 'RPackage' -> true > > (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound > > bug? > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 9, 2012

[Pharo-project] Question about RPackage (bug?)

by Mariano Martinez Peck

(MCWorkingCopy allManagers collect: [:p | p package name] ) includes: 'RPackage' -> true (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound bug? -- Mariano http://marianopeck.wordpress.com

Aug. 9, 2012

Re: [Pharo-project] color problem?

by Gary Chambers

Color values range from 0.0 to 1.0 use (Color r: 255 g: 255 b: 122 range: 255) alpha: 1.0 instead ;-) Regards, Gary ----- Original Message ----- From: "Esteban Lorenzano" <estebanlm(a)gmail.com> To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, August 08, 2012 5:05 PM Subject: [Pharo-project] color problem? > Hi, > > try: > > Color r: 255 g: 255 b: 122 alpha: 255. > > AFAIK, that should bring a yellow color. And it is not. > Anyone knows why? > > Esteban > >

Aug. 9, 2012

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

by Camillo Bruni

On 2012-08-09, at 03:31, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Cami, > > Given that I am using Pharo-1.4 FileSystem to develop for Pharo-2.0 it would be very useful to have equivalent functionality...especially if it won't take to long for you to provide it ... > > When you have a new version of FileSystem available for Pharo-1.4 let me know ... tomorrow I have a long train ride to do, so I will most probably fix by tomorrow evening.

Aug. 9, 2012

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

by Dale Henrichs

Cami, Given that I am using Pharo-1.4 FileSystem to develop for Pharo-2.0 it would be very useful to have equivalent functionality...especially if it won't take to long for you to provide it ... When you have a new version of FileSystem available for Pharo-1.4 let me know ... Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, August 8, 2012 10:35:54 AM | Subject: Re: [Pharo-project] FileSystem differences between Pharo-2.0 and Pharo-1.4 | | 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 :) | | | 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. 9, 2012

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