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

Re: [Pharo-project] Metacello loading semantics

by StÃ©phane Ducasse

> 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. Ok I was not aware of that and I will > > 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? Yes I will try. I disabled the cache disabling because loading 800 packages to try is a pain :) > > 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] when do we go beta?

by Mariano Martinez Peck

+1 for including only NB and then just bug fixes. No new stuff. So...slots and new classbuilder will be for next release. Same for Opal I guess. On Wed, Nov 21, 2012 at 11:30 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Please! > Because I refrain myself to fix and changes so we should focus on bug > fixing and not opening new things. > > > I was thinking on going beta next week, actually :) > > > > > >>> 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. > > Thanks sven. > > > -- Mariano http://marianopeck.wordpress.com

Nov. 21, 2012

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

by StÃ©phane Ducasse

On Nov 21, 2012, at 8:16 PM, Dale Henrichs wrote: > 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 would not. I would like that Metacello constraints the space. Because we should have less option and more structured supported scenarios. > 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. Ok it was not clear to me that they have a 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. How this can be possible? Ok you mean because the guy changed the stable definition. > 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 StÃ©phane Ducasse

Please! Because I refrain myself to fix and changes so we should focus on bug fixing and not opening new things. > I was thinking on going beta next week, actually :) > > >>> 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. Thanks sven.

Nov. 21, 2012

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

by StÃ©phane Ducasse

On Nov 21, 2012, at 5:59 PM, Gary Chambers wrote: > Who knows... despite the (1.4 to 2.0 transition) we've had to stay on 1.4 for stability/sanity since we have a live product. We can understand. Now we hope that the new aspect will really interest you ;) We re thinking about tools to help companies migrating. We are designing a new change model recording refactoring so that we can also propose changes summary. We improved a lot but the road is long. Stef > Will take a while to ascertain the impact. Guess we go once final for us. > > Sorry not had the time to follow the 2.0 progression in use. > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, November 21, 2012 4:19 PM > Subject: [Pharo-project] when do we go beta? > > >> Stef > >

Nov. 21, 2012

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

by Igor Stasenko

On 21 November 2012 01:20, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > "The font is then responsible for providing the drawing commands and > metrics for the particular glyph when it's drawn." > > sounds like Cocoa delegates rendering to the font. > Cocoa? I don't know where you took this citation from, but it is actually how Athens dealing with this stuff: it asks font to provide an instance of glyph renderer, suitable for rendering on athens surface. And yes, the glyph renderer is then responsible for delivering glyphs to surface by issuing appropriate drawing commands :) -- Best regards, Igor Stasenko.

Nov. 21, 2012

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

by Igor Stasenko

On 20 November 2012 21:33, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2012/11/21 Denis Kudriashov <dionisiydk(a)gmail.com> >> >> Hello. >> >> Can you add me as project contributor. I try to upload version with >> detailed comment from my first mail but can't. > > > My smalltalkhub nickname "dionisiy" done -- Best regards, Igor Stasenko.

Nov. 21, 2012

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

by Igor Stasenko

On 18 November 2012 17:56, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-11-14, at 17:36, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello. >> >> I look deep at TxText package where Igor and Camillo introduced new text >> model. >> >> Text model based on sequence of span objects. There are now two kind of >> spans: CharacterSpan and LineSeparator. Each span has reference to next and >> previous spans. There is TxSelection object which contains cursor. So you >> can insert new text at cursor, you can cut selection, replace selection >> with another text. Such maniulation changes text model structure. It can >> create new span objects. It can split current span at cursor position, It >> can remove selected spans. Also you can move cursor up, down, left, right. >> Cursor always know about current span and span position. >> >> I like design :). And I want use this package. And I have questions and >> suggestions: >> >> 1) Cursor is end of selection object. So now when you move cursor selection >> changed, because start of selection stay same. Am I right? > > yes > >> I think cursor movement should always reset selection. It is what we see >> with basic text editors. >> But cursor now is just instance of TxPosition which implements simple >> position protocol (move left, up...). It just change current span and span >> position by movement. TxPosition knows nothing about TxSelection object. >> That's why I think Cursor class should be introduced here which alway reset >> text selection by any move. >> And if you want to change selection bounds just get explicitly start or end >> of selection and use position api. >> What do you think? > > Humm not so sure about this :). Your argument in favor of a default behavior > which conforms to other editors is definitely something to consider. In the > end it's not that much work to get the a decent default behavior. Somewhere > in the view where you modify the mode you can do `text selection collapse`. > > If you want you can try to implement it ;) and we see how it feels to use > it that way (most probably I will be in favor then..) > >> 2) Next question about changes notification of text model. First I want >> Cursor and Selection objects are annnouncers. So I can implement >> CursorPresenter and SelectionPresenter to show such objects and handle >> changes. For example when CursorMovedAnnouncement happen I can move cursor >> caret morph at appropriate position. > > this sounds like a good idea! I don't remember if we replace/create new > instances of the cursors/selections... This might have an impact on where > you want to listen for changes. But definitely we want something like that > to decouple the model from any view. > i have only one question: - shall we do this surgery (with announcer stuff) in base model, or - shall we make a separate model which wraps around existing model,and then provides a notification(s). my main source of disdain about notifications is that in single class we will have to mix an action and notification about it i.e.. Selection>>cut self doThingsToCut. ... self announcer announce: IJustCutMyself. this is IMO a bit stinky. I would prefer a notification(s) to be in a separate layer: SelectionWatcher/Controller>>cut selection cut. ... self announcer announce: SelectionWasJustCut despite that it looks like more costly in terms of implementation. But i don't like mixing multiple concerns in single place. >> Another idea is make span objects announcers. Maybe it is not good idea but >> I want to subscribe at SpanAdded, SpanRemoved. SpanChanged, SpanSplitted. >> With such events I can make very simple implementation of TextEditor as >> list of SpanMorph's. Maybe it is not optimized solution but I think it is >> most simple thing. So I want to try it. >> >> 3) What about auto wrap behaviour? >> If you have auto wrap option at text editors you have line width >> restriction. And you should spit real lines of text to visual lines which >> satisfed this restriction. And text mode should know about such restriction >> because any text insertion can require new visual lines creation. > > I don't think the basic model should know about the visual lines. We discussed > that for a while, but in the end that's purely a view on the basic model. > For instance if you want to get the insertion point when clicking on some > text view you have to take so many model-unrelated things into account > (global transformation, font sizes). > >> I think insertion single line text at span position should be executed by >> special "restriction object". It should return new characters of span which >> satisfied that restriction. And it should return new span object (or just >> remains characters) which will present new visual lines. Then this "remains >> characters" should be inserted to next span at 0 position. >> When wrap behavior not needed "restriction object" just inserts new text >> into current characters at given position and returns result. >> If you agree about such logic please suggest good name for such >> "restriction object" and instance variable where it will placed (at TxModel >> I think) >> >> Ok, now what do you think about all this? >> I want implement all my suggestions. But first I want listen your opinions. >> >> Best regards, >> Denis > > -- Best regards, Igor Stasenko.

Nov. 21, 2012

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

by Igor Stasenko

On 20 November 2012 21:31, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2012/11/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> > Text model based on sequence of span objects. There are now two kind of >> > spans: CharacterSpan and LineSeparator. Each span has reference to next and >> > previous spans. There is TxSelection object which contains cursor. So you >> > can insert new text at cursor, you can cut selection, replace selection with >> > another text. Such maniulation changes text model structure. It can create >> > new span objects. It can split current span at cursor position, It can >> > remove selected spans. Also you can move cursor up, down, left, right. >> > Cursor always know about current span and span position. >> >> If this is not in the class comments can you add it? > > > When I will have permissions once you will give me your username on smalltalk hub. :) -- Best regards, Igor Stasenko.

Nov. 21, 2012

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

by Igor Stasenko

On 20 November 2012 21:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > Can you add me as project contributor. I try to upload version with detailed > comment from my first mail but can't. > > 2012/11/18 Camillo Bruni <camillobruni(a)gmail.com> >> >> I don't think the basic model should know about the visual lines. We >> discussed >> that for a while, but in the end that's purely a view on the basic model. > > > If such behaviour will be at view simple Cursor>>moveUp/moveDown will never > work right from user perspective. So why you need cursor at text model which > will never reflect state of visual cursor at screen? > To me text model should completelly represent what user see at text view. > Otherwise why you call it model? Otherwise it is just raw data like Text in > current TextMorph. > because same model can have multiple different views. and each view can have different dimensions and show different portion(s) of model (text). The parts we implemented so far is about editing the model itself. Next step would be to implement text attribute(s) management, and then implement View(s) which will lay out the text for rendering it on screen. About cursor: The cursor is actually a convenience method in current model, to avoid using 'text selection end' every time. The selection/cursor in text model there because this should be is the only way how you can modify text: - you should not be able to modify text without using selection(s)/cursor. Any direct usage, like in existing Text , should be prohibited. Only high level operations via selection. And no illusions about that you can operate with text as with an ordinal Collection. If you want to turn text model into 'collection', you have to pay the price: use #asString. An way to treat text as a collection of characters is imo futile and falls short once you think how to introduce non-textual objects into text (images etc). More about selections: It is not necessary to have a direct correspondence between model selection and visual text editor selection/cursor. And often, actually would be counterproductive. Camillo may disagree, but i think the main purpose of selection/cursor objects and their protocol is to provide a convenient interface for editing the model. And the fact that you can have visual selection/cursor == model selection/cursoe is imo secondary to that, and completely unnecessary. Yes, we tried to map text navigation/selection protocol to look most natural, as if you editing the text in text editor. And tests which we have is actually telling that we're on the right way: we've been able to edit the text without having 'text editor' and without counting characters, but using high-level commands to cursor/selection. Which is IMO good. >> >> For instance if you want to get the insertion point when clicking on some >> text view you have to take so many model-unrelated things into account >> (global transformation, font sizes). > > > I think It can be solve easilly if text model will reflect visual lines of > text. > For example, imagine my simple idea where TextView is just list of > SpanMorph's. When user click on text concrete span morph will handle it > because TextView is just morph with submorphs (no special behaviour). So > target SpanMorph should just compute span position under mouse and change > text model cursor position appropriatelly. Then cursor will announce > #changed event and CursorMorph will reflect this automatically. > The decision to use spans was to denote a portion of text which has same attributes, so a rendering engine can set up all attributes once, at the start of span, and render all text characters in single pass, without need to do any other checks for attribute changes. I don't think representing spans with morphs will be a good idea. >> 3) What about auto wrap behaviour? >> If you have auto wrap option at text editors you have line width >> restriction. And you should spit real lines of text to visual lines which >> satisfed this restriction. And text mode should know about such restriction >> because any text insertion can require new visual lines creation. >> I think insertion single line text at span position should be executed by >> special "restriction object". It should return new characters of span which >> satisfied that restriction. And it should return new span object (or just >> remains characters) which will present new visual lines. Then this "remains >> characters" should be inserted to next span at 0 position. >> When wrap behavior not needed "restriction object" just inserts new text >> into current characters at given position and returns result. > > > Just remember two kinds of such line width restrictions: width in pixels and > width in characters. First is usual text wrapping behaviour when line width > restricted by view width. Last is when editor wrap lines which contains >100 > characters for example. > text wrapping is visual/layout information. The data flow when you rendering text is following: (Text) -> (Layout information) -> (Screen) The text , as a model , has nothing to do with layout information. More than that, don't forget about multiple views for same model, which can have different dimensions and different wrapping rules. So, it would be bad idea to mix layout information with text model itself. -- Best regards, Igor Stasenko.

Nov. 21, 2012