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

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by Denis Kudriashov

2012/11/21 Camillo Bruni <camillobruni(a)gmail.com> > > To me text model should completly represent what user see at text view. > > Otherwise why you call it model? Otherwise it is just raw data like Text > in > > current TextMorph > > Model IS the raw base model, the view is what you see, that are definitely > two different things. > For instance where would you deal with hyphenation? dynamic layouts? > When I think about TextMorph model I think about object which can be used from tests or just workspace where no any view exists. And this is what you exactly implement with TxModel. You have TxModelTest where you move cursor, change selection, insert characters. And this is not depends on any possible text view. Great!. And without any thinking on text wrapping logic and others I can implement very SimpleTextMorph based on TxModel. You can imagine how simple can be implementation of multiline text view/editor based on such nice model. No crappy paragraphs and editors. Drawing morph can be just something like spans do: [:each | each drawOn: aCanvas] But now imagine that I want such morph with two options: autowrap by morph bounds and restrict lines by 10 characters. What should be changed for such behaviour? And maybe more clever question: what this options actually mean? In any case user just see list of text lines. And user can not know is this lines virtual (created by wrapping logic) or real (created by cr from source string). So logic of wrap lines is just splitting source string to visual lines by some restriction. (Same for hyphenation). But view just show list of lines (spans) and nothing more. And object which edit text (insert characters...) should know about "lines restrictions" and change span structure of text model appropriately. Now TxCharactersSpan implements full edit logic (#at:insert: method for example). To achive my suggestions new "restriction object" should be introduced and maybe special kind of spans. Maybe it should be called SpanBuilder (with WrappedTextSpanBuilder-like subclasses) Ok, this is my ideas. I try to implement it this weekend. What you mean by dynamic layouts? Best regards, Denis

Nov. 21, 2012

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

by Pavel Krivanek

http://code.google.com/p/pharo/issues/detail?id=7036 -- Pavel On Wed, Nov 21, 2012 at 8:40 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > 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 loading semantics

by Dale Henrichs

Doru, The loadDirectives structure is the structure that does the actual package load for metacello, so extracting the information from the loadDirectives is the correct technique for producing a list of packages in load order. From a cursory read of Stefs code he appears to be doing it correctly ... atomic/linear loadType is an important distinction that has to be taken into account when attempting to reproduce the Metacello load behavior without using Metacello... Of course in the end, it's the details like which packages/projects specifically are causing trouble that will help me figure out exactly where things are breaking down. I assume that when Metacello does the load, everything gets loaded correctly? If you want me to help build/debug a package flattener for Moose I would be glad to help, but I need more detailed information about what you are trying to do and why. Also having the actual code to look at and a reproducible test case makes addressing issues a ton easier...Perhaps making an image available with a workspace doit primed for failure is a good first step:) Dale ----- Original Message ----- | From: "Tudor Girba" <tudor(a)tudorgirba.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, November 21, 2012 10:49:12 AM | Subject: Re: [Pharo-project] Metacello loading semantics | | 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 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