- Pharo-dev - lists.pharo.org

Re: [Pharo-project] I don't agree with DummyXXX

by Sebastian Nozzi

What about "SilentXXX"? 2012/11/21 Camillo Bruni <camillobruni(a)gmail.com>: >>>> why? >>>> >>>> It is not a complete NULL UIManager. A NullUIManager would implement all >>>> the API and do nothing (or implement nothing but only #doesNotUnderstand: >>>> doing nothing or something like that) DummyUIManger DOES stuff, but it >>>> makes sures not to end up calling the UI (like progress bar, notifications, >>>> confirmations, etc). So, in this particular case, HeadlessUIManager is much >>>> more accurate for me than Null. >>>> >>> then you will need to explain EVERY time to users why they should use >>> CommandLineUIManager, or NonInteractiveUIManager for headless mode, >>> rather than HeadlessUIManager. >>> Good luck with that :) >>> >> >> this is, btw , one of the reasons why i picked NonInteractive name >> instead of calling it 'headless'. >> Because it is more precise. And Camillo also used 'CommandLine' >> instead of 'Headless'. >> >> In this regard, Dummy/Null is much more precise with describing >> behavior of that ui manager class than headless. > > exactly! :)

Nov. 21, 2012

Re: [Pharo-project] [update 2.0] #20414

by Pavel Krivanek

I'll prepare a slice -- Pavel On Wed, Nov 21, 2012 at 4:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi Stef, >> >> because this method can be called from Form class >> #fromFileNamed: >> and can work in case you use native binary Form representation. > > I would move fromFileNamed: too > > Stef > >> Any idea how to solve it in more cleaner way? >> >> Cheers, >> -- Pavel >> >> >> >> On Wed, Nov 21, 2012 at 2:50 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Pavel >>> >>> why not moving this class on the ImageWriter package >>> because >>> - I do not like this Smalltalk globals at: ifPresent: >>> especially when there is no default. >>> >>> - This method does not make sense without the ImageReadWriter >>> >>> >>> Form classSide>>fromBinaryStream: (in category 'instance creation') -----fromBinaryStream: aBinaryStream >>> "Read a Form or ColorForm from given file, using the first byte of the file to guess its format. Currently handles: GIF, uncompressed BMP, and both old and new DisplayObject writeOn: formats, JPEG, and PCX. Return nil if the file could not be read or was of an unrecognized format." >>> >>> | firstByte | >>> aBinaryStream binary. >>> firstByte := aBinaryStream next. >>> firstByte = 1 ifTrue: [ >>> "old Squeakform format" >>> ^ self new readFromOldFormat: aBinaryStream]. >>> firstByte = 2 ifTrue: [ >>> "new Squeak form format" >>> ^ self new readFrom: aBinaryStream]. >>> >>> "Try for JPG, GIF, or PCX..." >>> "Note: The following call closes the stream." >>> + Smalltalk globals at: #ImageReadWriter ifPresent: [:imageReadWriter | >>> + ^ imageReadWriter formFromStream: aBinaryStream] >> > >

Nov. 21, 2012

Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:?

by Dale Henrichs

Doru, I guess because I don't agree that the following statement would be true: there will never be a regular version named 'stable' I know that in git I can have a branch named 'stable' and a tag named 'stable' and that causes problems ... for me. Besides, the set of symbolic versions is not restricted to #stable and #development ... one could choose to define a symbolic version called #default or #'1.0'... I intend for there to be two namespaces the linear version namespace and the symbolic version namespace to make a clear distinction between the two, because they have different semantics. One shouldn't be surprised that when version #stable of project foo is loaded the current version of the project is '1.0' on one day and '1.1' on the next. Or when they load #'1.0' that the current version is '1.0-beta.19'. This distinction is obviously not important to you and I am okay with that:) Dale ----- Original Message ----- | From: "Tudor Girba" <tudor(a)tudorgirba.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, November 21, 2012 10:50:37 AM | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? | | The question is the same I asked when you introduced them :): | Why are symbolic versions treated differently from normal ones? | | This has two dimensions: | - why have a different pragma at all? | - why have the distinction between symbols and versions, given that | there will never be a regular version named 'stable'? | | Cheers, | Doru | | | On 21 Nov 2012, at 19:27, Dale Henrichs <dhenrich(a)vmware.com> wrote: | | > Stef, | > | > I'm not sure which context you are talking about ... the symbolic | > version #stable can be used as an argument anywhere that the | > linear version '1.1' can be used, so I think that it is true that | > symbolic versions can be used in a #version: message ... | > | > So I guess I need a little more context ... | > | > Dale | > | > ----- Original Message ----- | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | > | Sent: Friday, November 16, 2012 2:19:02 PM | > | Subject: [Pharo-project] Metacello Why symbolicversion and not | > | simply tagged version:? | > | | > | Dale | > | | > | in my goal to reduce the complexity of metacello, I'm wondering | > | why | > | symbolic versions could not be expressed as version: | > | | > | because | > | | > | version: #stable | > | version: #development | > | | > | are symbolic versions and there is no clash possible with | > | | > | version: '1.1' | > | | > | Stef | > | | > | | > | | -- | www.tudorgirba.com | | "Things happen when they happen, | not when you talk about them happening." | | |

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Esteban Lorenzano

yes, next week :) On Nov 21, 2012, at 8:05 PM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > AFAIK the idea was to integrate NB into Pharo 2.0. > So shouldnt this be done first ... > > >

Nov. 21, 2012

[Pharo-project] when do we go beta?

by Torsten Bergmann

AFAIK the idea was to integrate NB into Pharo 2.0. So shouldnt this be done first ...

Nov. 21, 2012

Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:?

by Tudor Girba

The question is the same I asked when you introduced them :): Why are symbolic versions treated differently from normal ones? This has two dimensions: - why have a different pragma at all? - why have the distinction between symbols and versions, given that there will never be a regular version named 'stable'? Cheers, Doru On 21 Nov 2012, at 19:27, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Stef, > > I'm not sure which context you are talking about ... the symbolic version #stable can be used as an argument anywhere that the linear version '1.1' can be used, so I think that it is true that symbolic versions can be used in a #version: message ... > > So I guess I need a little more context ... > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | Sent: Friday, November 16, 2012 2:19:02 PM > | Subject: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? > | > | Dale > | > | in my goal to reduce the complexity of metacello, I'm wondering why > | symbolic versions could not be expressed as version: > | > | because > | > | version: #stable > | version: #development > | > | are symbolic versions and there is no clash possible with > | > | version: '1.1' > | > | Stef > | > | > -- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."

Nov. 21, 2012

Re: [Pharo-project] Metacello loading semantics

by Tudor Girba

Hi Dale, The question is how to get all packages that will be loaded for a given configuration version in the correct order. We want to obtain that to provide a flattened configuration version based on what is in the image. Cheers, Doru On 21 Nov 2012, at 19:33, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Stef, > > If you need to leverage the multi-package load, you can do that in Metacello by using the #atomic loadType in the project method of your configuration: > > project > ^ project > ifNil: [ > "Bootstrap Metacello if it is not already loaded" > self class ensureMetacello. > project := self projectClass new projectAttributes: self customProjectAttributes. "Create the Metacello project" > project versionNumberClass: self versionNumberClass. > project class versionConstructorClass on: self project: project. "Construct the project" > project loadType: #'atomic'. "change to #atomic if desired" > project ] > > With #atomic, all of the packages are loaded in one multi-package load. with #linear (the default) each package is loaded individually. > > If you inspect the loadDirectives that are produced by the #record message, the load type is encoded in the class of the directive, so you can tell whether #linear or #atomic loadTypes are used in the configurations... > > Does this help? > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | Sent: Saturday, November 17, 2012 11:28:03 AM > | Subject: [Pharo-project] Metacello loading semantics > | > | Hi dale > | > | I implemented a little tool that > | - create a kind of specification (version, package, repo) for all > | the packages reachable from a configurationOf > | (see below method method > | packagesAndAssociatedRepositoriesFromConfigurationRecord ) > | > | It generates a script looking as follows: > | script3 > | ^ #( > | #('ConfigurationOfFame-TudorGirba.5.mcz' > | 'http://www.squeaksource.com/Fame/' 'ConfigurationOfFame' ) > | #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz' > | 'http://www.squeaksource.com/MooseAlgos/' > | 'ConfigurationOfMooseAlgos' ) > | #('ConfigurationOfGlamour-TudorGirba.98.mcz' > | 'http://www.squeaksource.com/Glamour/' 'ConfigurationOfGlamour' > | ) > | #('ConfigurationOfDSM-AlexandreBergel.56.mcz' > | 'http://www.squeaksource.com/dsm/' 'ConfigurationOfDSM' ) > | #('ConfigurationOfKumpel-AlexandreBergel.3.mcz' > | 'http://www.squeaksource.com/Kumpel/' 'ConfigurationOfKumpel' ) > | #('ConfigurationOfSmallDudâ¦â¦â¦â¦.) > | > | - I keep the order given by Metacello. I extract the information as > | follows: > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: > | aConfigurationRecord > | "| record | > | record := ((Smalltalk globals at: #ConfigurationOfMoose) project > | version: 'default') ignoreImage: true; record. > | self packagesAndAssociatedRepositoriesFromConfigurationRecord: > | record > | " > | > | | pkgs | > | pkgs := OrderedCollection new. > | aConfigurationRecord loadDirective packageDirectivesDo: > | [:directive | > | pkgs add: > | {directive spec name, '*'. > | (self removeCache: directive spec workingCopy > | repositoryGroup repositories) anyOne > | locationWithTrailingSlash} ]. > | ^ pkgs > | > | > | - then I try to load the package as follows: > | > | flatVersion47: spec > | <version: '4.7-flat'> > | > | spec for: #common do: [ > | self populateSpec: spec with: self script3 ] > | > | I load them doing > | (ConfigurationOfMoose project version: '4.7-flat') load > | Now It does not work because after fetching all the packages, the > | system complain that some classes that will be loaded later are not > | present. > | I imagine that you use Gofer and that Gofer does not use the merging > | semantics of MC over multiple projects (that you can have multiple > | package in any order and that the classes get loaded - as I use it > | for the scriptLoader and below). > | > | > | - before I was doing it by doing a diff between the pharo package > | and the one loaded and I was loading the specification after > | installing the repository > | and the working copies using the MCVersionLoader and it worked I > | could reload completely Moose! > | > | > | load: aCollectionOfPackageString > | "self new > | load: #( 'Famix-C-TudorGirba.15' > | 'Famix-Core-NicolasAnquetil.201'))" > | > | | loader | > | loader := MCVersionLoader new. > | (self newerVersionsIn: aCollectionOfPackageString) > | do: [ :fn | loader addVersion: (self loadVersionFromFileNamed: fn). > | (Delay forSeconds: 2) wait.] > | displayingProgress: 'Adding versions...'. > | loader hasVersions ifTrue: [loader load]. > | > | > | So my question is > | - Does the packageDirectivesDo: provide an order that I can use to > | load package with the gofer-load on project at a time? > | May be my code does not keep the same order but I payed attention to > | this point. I will check that further. > | > | - may be I could extend Gofer to support multiple project merge > | loading. > | > | So right now I'm stuck and this is sad because freezing a complex > | configuration is really needed. > | > | Stef > | > | > | > | > | > | > -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

Nov. 21, 2012

Re: [Pharo-project] I don't agree with DummyXXX

by Camillo Bruni

>>> why? >>> >>> It is not a complete NULL UIManager. A NullUIManager would implement all >>> the API and do nothing (or implement nothing but only #doesNotUnderstand: >>> doing nothing or something like that) DummyUIManger DOES stuff, but it >>> makes sures not to end up calling the UI (like progress bar, notifications, >>> confirmations, etc). So, in this particular case, HeadlessUIManager is much >>> more accurate for me than Null. >>> >> then you will need to explain EVERY time to users why they should use >> CommandLineUIManager, or NonInteractiveUIManager for headless mode, >> rather than HeadlessUIManager. >> Good luck with that :) >> > > this is, btw , one of the reasons why i picked NonInteractive name > instead of calling it 'headless'. > Because it is more precise. And Camillo also used 'CommandLine' > instead of 'Headless'. > > In this regard, Dummy/Null is much more precise with describing > behavior of that ui manager class than headless. exactly! :)

Nov. 21, 2012

Re: [Pharo-project] I don't agree with DummyXXX

by Esteban A. Maringolo

I vote for Null* For me Deaf* reminds me the DeafObject of Dolphin which always returns itself (or true to #mustBeBoolean). It is some kind of /dev/null, useful to the creation of the GUI, where some objects aren't available yet and might get an undesired message. Regards! -- View this message in context: http://forum.world.st/I-don-t-agree-with-DummyXXX-tp4656199p4656255.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 21, 2012

Re: [Pharo-project] Metacello loading semantics

by Dale Henrichs

Stef, If you need to leverage the multi-package load, you can do that in Metacello by using the #atomic loadType in the project method of your configuration: project ^ project ifNil: [ "Bootstrap Metacello if it is not already loaded" self class ensureMetacello. project := self projectClass new projectAttributes: self customProjectAttributes. "Create the Metacello project" project versionNumberClass: self versionNumberClass. project class versionConstructorClass on: self project: project. "Construct the project" project loadType: #'atomic'. "change to #atomic if desired" project ] With #atomic, all of the packages are loaded in one multi-package load. with #linear (the default) each package is loaded individually. If you inspect the loadDirectives that are produced by the #record message, the load type is encoded in the class of the directive, so you can tell whether #linear or #atomic loadTypes are used in the configurations... Does this help? Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Saturday, November 17, 2012 11:28:03 AM | Subject: [Pharo-project] Metacello loading semantics | | Hi dale | | I implemented a little tool that | - create a kind of specification (version, package, repo) for all | the packages reachable from a configurationOf | (see below method method | packagesAndAssociatedRepositoriesFromConfigurationRecord ) | | It generates a script looking as follows: | script3 | ^ #( | #('ConfigurationOfFame-TudorGirba.5.mcz' | 'http://www.squeaksource.com/Fame/' 'ConfigurationOfFame' ) | #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz' | 'http://www.squeaksource.com/MooseAlgos/' | 'ConfigurationOfMooseAlgos' ) | #('ConfigurationOfGlamour-TudorGirba.98.mcz' | 'http://www.squeaksource.com/Glamour/' 'ConfigurationOfGlamour' | ) | #('ConfigurationOfDSM-AlexandreBergel.56.mcz' | 'http://www.squeaksource.com/dsm/' 'ConfigurationOfDSM' ) | #('ConfigurationOfKumpel-AlexandreBergel.3.mcz' | 'http://www.squeaksource.com/Kumpel/' 'ConfigurationOfKumpel' ) | #('ConfigurationOfSmallDudâ¦â¦â¦â¦.) | | - I keep the order given by Metacello. I extract the information as | follows: | | packagesAndAssociatedRepositoriesFromConfigurationRecord: | aConfigurationRecord | "| record | | record := ((Smalltalk globals at: #ConfigurationOfMoose) project | version: 'default') ignoreImage: true; record. | self packagesAndAssociatedRepositoriesFromConfigurationRecord: | record | " | | | pkgs | | pkgs := OrderedCollection new. | aConfigurationRecord loadDirective packageDirectivesDo: | [:directive | | pkgs add: | {directive spec name, '*'. | (self removeCache: directive spec workingCopy | repositoryGroup repositories) anyOne | locationWithTrailingSlash} ]. | ^ pkgs | | | - then I try to load the package as follows: | | flatVersion47: spec | <version: '4.7-flat'> | | spec for: #common do: [ | self populateSpec: spec with: self script3 ] | | I load them doing | (ConfigurationOfMoose project version: '4.7-flat') load | Now It does not work because after fetching all the packages, the | system complain that some classes that will be loaded later are not | present. | I imagine that you use Gofer and that Gofer does not use the merging | semantics of MC over multiple projects (that you can have multiple | package in any order and that the classes get loaded - as I use it | for the scriptLoader and below). | | | - before I was doing it by doing a diff between the pharo package | and the one loaded and I was loading the specification after | installing the repository | and the working copies using the MCVersionLoader and it worked I | could reload completely Moose! | | | load: aCollectionOfPackageString | "self new | load: #( 'Famix-C-TudorGirba.15' | 'Famix-Core-NicolasAnquetil.201'))" | | | loader | | loader := MCVersionLoader new. | (self newerVersionsIn: aCollectionOfPackageString) | do: [ :fn | loader addVersion: (self loadVersionFromFileNamed: fn). | (Delay forSeconds: 2) wait.] | displayingProgress: 'Adding versions...'. | loader hasVersions ifTrue: [loader load]. | | | So my question is | - Does the packageDirectivesDo: provide an order that I can use to | load package with the gofer-load on project at a time? | May be my code does not keep the same order but I payed attention to | this point. I will check that further. | | - may be I could extend Gofer to support multiple project merge | loading. | | So right now I'm stuck and this is sad because freezing a complex | configuration is really needed. | | Stef | | | | | |

Nov. 21, 2012