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

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

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

by Sebastian Sastre

be careful with precision vs. intuition conventions each of them have benefits for the long and short term also a price On Nov 21, 2012, at 4:14 PM, Igor Stasenko wrote: > On 21 November 2012 15:11, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 21 November 2012 14:55, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>> >>> On Wed, Nov 21, 2012 at 4:50 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> On 21 November 2012 12:47, Fernando Olivero <fernando.olivero(a)usi.ch> >>>> wrote: >>>>> I totally agree. Dummy does not tell me about the class. >>>>> >>>>> Are there just 3 uses of Dummy in the core? >>>>> >>>>> We should either use Null or use a specific prefix always, so its form >>>>> a >>>>> consisten pattern. >>>>> >>>>> DummyUIManager -> NullUIManager >>>>> >>>> yes, not "Headless" please. >>>> >>> >>> 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. > > -- > Best regards, > Igor Stasenko. >

Nov. 21, 2012

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

by Dale Henrichs

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 | |

Nov. 21, 2012

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

by Igor Stasenko

On 21 November 2012 15:11, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 November 2012 14:55, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Wed, Nov 21, 2012 at 4:50 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> On 21 November 2012 12:47, Fernando Olivero <fernando.olivero(a)usi.ch> >>> wrote: >>> > I totally agree. Dummy does not tell me about the class. >>> > >>> > Are there just 3 uses of Dummy in the core? >>> > >>> > We should either use Null or use a specific prefix always, so its form >>> > a >>> > consisten pattern. >>> > >>> > DummyUIManager -> NullUIManager >>> > >>> yes, not "Headless" please. >>> >> >> 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. -- Best regards, Igor Stasenko.

Nov. 21, 2012

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

by Esteban Lorenzano

I was thinking on going beta next week, actually :) On Nov 21, 2012, at 6:32 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 21 Nov 2012, at 17:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> when do we go beta? > > I have been using 2.0 for months now, it has been very stable (apart from some hiccups). > > It is so much better that it would be immoral to keep this from the world ;-) > > We just have to declare a stabilization period in which we refrain from big/dangerous changes and work more on stability and testing. > > My 2c, > > Sven > > >

Nov. 21, 2012

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

by Igor Stasenko

On 21 November 2012 14:55, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Nov 21, 2012 at 4:50 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 21 November 2012 12:47, Fernando Olivero <fernando.olivero(a)usi.ch> >> wrote: >> > I totally agree. Dummy does not tell me about the class. >> > >> > Are there just 3 uses of Dummy in the core? >> > >> > We should either use Null or use a specific prefix always, so its form >> > a >> > consisten pattern. >> > >> > DummyUIManager -> NullUIManager >> > >> yes, not "Headless" please. >> > > 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 :) >> > Fernando >> > >> > On Wed, Nov 21, 2012 at 4:34 PM, Mariano Martinez Peck >> > <marianopeck(a)gmail.com> wrote: >> >> >> >> From what I understand, Dummy means something different. I have using >> >> that >> >> for class names. More accurate names can be found. >> >> I would rename: >> >> >> >> DummyUIManager -> HeadlessUIManager >> >> DummySystemProgressItem -> NullSystemProgressItem >> >> DummySoundSystem -> NullSoundSystem >> >> >> >> what do you think? do you have better names? >> >> >> >> -- >> >> Mariano >> >> http://marianopeck.wordpress.com >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

Nov. 21, 2012

Re: [Pharo-project] Loading NBOpenGL in pharo 2

by Igor Stasenko

On 21 November 2012 13:17, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > ok, I'll update the config. About the fonts, do you know if these clases > were removed from pharo? > apparently they were removed. I don't remember where, but there should be a separate package to load these classes back (so we can add it to config to load them). > > On Wed, Nov 21, 2012 at 12:40 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 21 November 2012 12:28, Javier PimÃ¡s <elpochodelagente(a)gmail.com> >> wrote: >> > Igor, while loading ConfigurationOfNBOpenGL this things are missing: >> > >> > NBUnsignedLong >> > >> hmm.. this is because latest version of NativeBoost renamed this class >> to NBUInt32 >> that means we need to update config of opengl, >> and of course update this dependency. >> >> > TTFontReader >> > TTFontDescription >> > TTGlyph >> > >> this needs for demo to work.. but sure , it is not required for opengl >> to function. >> > >> > are they still needed? >> > >> > -- >> > Lic. Javier PimÃ¡s >> > Ciudad de Buenos Aires >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Lic. Javier PimÃ¡s > Ciudad de Buenos Aires -- Best regards, Igor Stasenko.

Nov. 21, 2012

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

by Mariano Martinez Peck

On Wed, Nov 21, 2012 at 4:50 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 November 2012 12:47, Fernando Olivero <fernando.olivero(a)usi.ch> > wrote: > > I totally agree. Dummy does not tell me about the class. > > > > Are there just 3 uses of Dummy in the core? > > > > We should either use Null or use a specific prefix always, so its form a > > consisten pattern. > > > > DummyUIManager -> NullUIManager > > > yes, not "Headless" please. > > 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. > Fernando > > > > On Wed, Nov 21, 2012 at 4:34 PM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> From what I understand, Dummy means something different. I have using > that > >> for class names. More accurate names can be found. > >> I would rename: > >> > >> DummyUIManager -> HeadlessUIManager > >> DummySystemProgressItem -> NullSystemProgressItem > >> DummySoundSystem -> NullSoundSystem > >> > >> what do you think? do you have better names? > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Nov. 21, 2012