- Pharo-dev - lists.pharo.org

Re: [Pharo-project] DemoMode should not change Fonts only sizes?

by Mariano Martinez Peck

Thanks Serge. I talked after with Alain and he explains me everything :) he told me you will integrate new fonts (from cuis) into the image and that will have larger fonts available...then no need to use FreeType :) Please let us know if this gets done. Thanks Mariano On Tue, Sep 14, 2010 at 12:55 PM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > 2010/9/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Alain, I was trying the DemoMode before my talk at ESUG and I thought > > that it would be better if this guy only changes the size of the fonts. I > am > > not sure if changing the fonts is good. > > > > For example, right now it is using FreeType with DejaVu. Since Pharo1.1 > dev > > doesn't use them, there is no folder "Fonts" with themâ¦..thus they are > not > > found and ugly fonts are rendered. > > Yes i already talk with Alain about this problem. One option was to > include severals sizes of bitmap DejaVu font. > > BTW, we fix with Alain a problem of browser switches rendering with > the demo font during the Smalltallk Camp here in Barcelona. > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 21, 2010

Re: [Pharo-project] [Pharo-users] Support for SCIM on Linux

by Mariano Martinez Peck

Ahh and you can open a ticket :) On Tue, Sep 21, 2010 at 11:50 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi David. I have no idea. I just cc'ed pharo-dev in case someone can help > you. > > Cheers > > Mariano > > > On Fri, Sep 17, 2010 at 6:23 PM, DavidWilson <djwilson(a)bluewin.ch> wrote: > >> >> Hi >> >> I'm trying to input Tibetan (i.e. Unicode) characters using the SCIM input >> method (Wylie tibetan aka EWTS) on Ubuntu (10.4). >> (N.B. That's not the same as a different keyboard layout!) >> >> SCIM works ok for OpenOffice and even for gedit, but not in Pharo, ie it >> is >> installed correctly and working. >> >> I suspect it's because Pharo consumes the keyboard input directly, and >> doesn't let SCIM do its stuff (essentially aggregating keystrokes before >> sending the unicode on to application). >> >> It would be nice to hear from a) anyone who's got this to work in Pharo, >> or >> b) someone who can confirm what I suspect. >> >> The equivalent works fine on Mac! >> >> David >> -- >> View this message in context: >> http://forum.world.st/Support-for-SCIM-on-Linux-tp2544095p2544095.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >

Sept. 21, 2010

Re: [Pharo-project] [Pharo-users] Support for SCIM on Linux

by Mariano Martinez Peck

Hi David. I have no idea. I just cc'ed pharo-dev in case someone can help you. Cheers Mariano On Fri, Sep 17, 2010 at 6:23 PM, DavidWilson <djwilson(a)bluewin.ch> wrote: > > Hi > > I'm trying to input Tibetan (i.e. Unicode) characters using the SCIM input > method (Wylie tibetan aka EWTS) on Ubuntu (10.4). > (N.B. That's not the same as a different keyboard layout!) > > SCIM works ok for OpenOffice and even for gedit, but not in Pharo, ie it is > installed correctly and working. > > I suspect it's because Pharo consumes the keyboard input directly, and > doesn't let SCIM do its stuff (essentially aggregating keystrokes before > sending the unicode on to application). > > It would be nice to hear from a) anyone who's got this to work in Pharo, or > b) someone who can confirm what I suspect. > > The equivalent works fine on Mac! > > David > -- > View this message in context: > http://forum.world.st/Support-for-SCIM-on-Linux-tp2544095p2544095.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Sept. 21, 2010

Re: [Pharo-project] A pattern for GUI programming (Morphic, Cuis, etc)

by Mariano Martinez Peck

could we add that to the pharo online book ? On Mon, Sep 20, 2010 at 12:15 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Well, for the most part they do, aside from the "low-level" #mouseUp etc. > Though the "Views" would be idomatically cleaner, they'd also be rather > less flexible. > Always a trade-off somewhere ;-) > > As for changing the #changed mechanism, good luck! (massive job). > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" < > stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, September 19, 2010 10:59 AM > Subject: Re: [Pharo-project] A pattern for GUI programming (Morphic, > Cuis,etc) > > > > Gary >> >> what do you think about the main point of juan that View do not raise >> event to communicate to their models. >> I like that. >> >> Stef >> >> On Sep 18, 2010, at 3:23 PM, Juan Vuletich wrote: >> >> Hi Folks, >>> >>> I have developed a GUI programming style, after studying MVC, Morphic, >>> MVP and a few others. The model does not know anything about views, there >>> are no unneeded redraws, partial updates work correctly, etc. It is >>> implemented in the LightWidget hierarchy in Cuis. The documentation I wrote >>> is attached. >>> >>> Cheers, >>> Juan Vuletich >>> GUI programming with LightWidgets >>> ========================== >>> >>> Warning: Perhaps it is good to read >>> AnExampleOfLightWidgetsProgramming.txt prior to reading this... >>> >>> This document summarizes the way LightWidgets are intended to be used. >>> The style for GUI programming is based on PluggableViews in MVC and >>> PluggableMorphs in Morphic. The main idea is to have a reusable set of >>> standard widgets that can be customized when used. There is a strict >>> separation between views and models. Models don't know about views, they are >>> never aware of them. Views know about their model and update it directly. >>> Therefore views don't trigger events. >>> >>> This description is not only conceptual, or theoretic. The rules >>> described here are to actually be followed. >>> >>> GUIs are built by composing widgets. The main view is a subclass of >>> CompositeLW. There is a complete separation between Model and Views. >>> >>> Rule 1. Models should never include GUI code >>> ---------------------------------------------------------- >>> >>> They must be completely ignorant of possible Views that operate on them. >>> There could be at any time any number of different views active on the same >>> model. They could belong to different technologies or frameworks. They could >>> even be remote and run on a different computer. There could be no view at >>> all. For example, the model could be driven by scripts or reside on a server >>> and receive external commands. However, this document will only describe >>> local LightWidgets GUIs. >>> >>> Rule 2. Views should never include any model code >>> --------------------------------------------------------------- >>> >>> The view could be replaced anytime with a different one. Besides, a model >>> should be able to run without any GUI at all. So any logic that belongs in >>> the model but is included in the GUI will eventually be missing. The Views >>> should query and modify Models only through public protocols, called >>> 'Inquiries' and 'User Commands'. >>> >>> Rule 3. Views know about the model they operate on >>> ------------------------------------------------------------------- >>> >>> Views have an instance variable to hold their model. They can query Model >>> Inquiries when needed. They can also issue User Commands when appropriate. >>> Models are usually subclasses of ActiveModel. Let's consider a small >>> example. We are building a GUI to operate on some Person objects. We'll >>> consider an EntryField for the birthday of aPerson. LightWidget includes the >>> following instance variables: >>> >>> - target : Holds the Model. For our example, the model of the EntryField >>> would be the Person. We call it target, because sometimes it might be a view >>> - aspect : It is a symbol, the getter for the aspect we are showing. In >>> this case it would be #birthday. >>> - aspectAdaptor : It is a symbol, a message that is sent to the aspect to >>> adapt it to the widget. As the widget is an EntryField and the aspect is a >>> Date, the aspectAdaptor could be #asString. This relies the Model from the >>> need to provide an appropriate getter for each kind of possible widget for >>> each attribute. >>> - action : The action is the setter used to update the aspect on the >>> model. In this example, it is #birthday:. >>> - actionAdaptor : It is used to adapt the value the user entered in the >>> widget for use as an argument of action. In this example it could be >>> #asDate. >>> It is usually a good idea to initialize model aspects with reasonable >>> defaults, and avoid nil values. This saves a lot of #ifNil: messages in the >>> gui. >>> >>> Rule 4. View Structure >>> ---------------------------- >>> >>> A Model could have a tree-like structure. It could be composed of other >>> Models. This is not mandatory. >>> Views always have a tree-like structure. The leaves are simple widgets. >>> The internal nodes are CompositeLWs. They can all share the same model, or >>> they could could use different parts of the bigger model. Anyway, they are >>> customized with the aspec and action. >>> >>> Rule 5. GUI construction >>> ------------------------------ >>> >>> The construction of the Views tree and the customization of each widget >>> is done by a main view. The main view also specifies how the Views are >>> notified of model changes for updating. >>> >>> Rule 6. Instance variables in views >>> -------------------------------------------- >>> >>> Additional instance variables in GUIs are of two kinds: They can be uses >>> to hold sub-views, or to hold 'Model Extensions'. Possible uses of Model >>> Extensions include: >>> - Holding information that can be obtained from the aspect, but that >>> could be expensive and it makes sense to cache. For example, our EntryField >>> could hold an array if indices of word starts and ends or some other >>> internal detail. >>> - Holding state that is meaningful for the widget, but that it doesn't >>> make any sense to keep in the model. An example could be the cursor position >>> in our EntryField. Others could be visual options, such as a graph type or >>> graph style for an application generated graph. >>> - Not-yet-commited information, entered by the user, but awaiting for OK >>> / Cancel. >>> In general, Model Extensions usually are re-fetched from the model, or >>> re-set to default values when the model changes. >>> >>> Rule 7. View updating because of model changes >>> --------------------------------------------------------- >>> >>> Any widget (in fact, any Morph) can redraw itself when needed, with the >>> #changed method. But when there is a change in the Model, the views must be >>> updated appropriately. All the Model Extensions must be updated, and all >>> sub-views must be updated too. >>> >>> When there is a change in the Model, the Views must receive the >>> #modelChanged message. A main view (i.e. a view that is not subview of >>> another view with the same Model) must send itself #beMainViewOn: on >>> construction. This does 'target when: #selfChanged send: #safeModelChanged >>> to: self'. The Model must trigger event #selfChanged when appropriate. >>> #safeModelChanged will eventually update all subviews recursively. So only a >>> main view should receive the #selfChanged event. Models are usually >>> subclasses of ActiveModel, to use the more advanced events implementation >>> there. >>> >>> This is the implementation of #beMainViewOn: . This message should be >>> used to set the model of a main view. >>> >>> beMainViewOn: aModel >>> "We are a main view on aModel. >>> This means: >>> - aModel is a real model, i.e. not a widget. >>> - no aspect or aspectAdaptor. We show the whole thing. >>> - no action or actionAdaptor. There is no main action. >>> - we must update ourselves on #selfChanged event" >>> >>> self target: aModel aspect: nil aspectAdaptor: nil modelChangeEvent: >>> #selfChanged >>> >>> The main update method is #modelChanged. #safeModelChanged is only to >>> guarantee that the update is done in the User Interface process, in the >>> inter-cycle paus. The implementation of #modelChanged at LightWidget is: >>> >>> modelChanged >>> "The model changed is some way. >>> This is usually the pace to call #targetAspect to fetch the current value >>> of the aspect from the >>> model, and to store it in some Model Extension. >>> We must update all Model Extension instance variables with values from >>> the model (i.e. target) >>> or with appropriate defaults. >>> We must update ourselves and all subviews to reflect the model's new >>> state" >>> >>> self updateView >>> >>> #modelChanged must be reimplemented in classes with model extensions. >>> Check the implementors to see how they work. >>> >>> After updating the model and model extensions, #updateView is called. >>> This is the implementation at LightWidget: >>> >>> updateView >>> "The model or some Model Extension changed is some way. >>> We must update ourselves to reflect the new state. >>> >>> This is the place to update secondary Model Extensions or any other state >>> that must be updated >>> after model or Model Extension change. >>> >>> This method is usually reimplemented in CompositeLWs, to update subviews. >>> >>> The subviews should be sent one of the following messages: >>> target: >>> target:aspect: >>> target:aspect:aspectAdaptor: >>> target:aspect:aspectAdaptor:aspectChangeEvent: >>> to update their model and do a full update, as triggered by >>> #modelChanged" >>> >>> self changed >>> >>> Warning: Never implement other methods like #updateViews. If for >>> performance reasons the updating of subviews must be splitted in parts, then >>> the views and subviews must be restructured accordingly. Then, each part can >>> be updated as a whole with the #updateView method. Each part can be updated >>> by more specific model change events, or alternatively, they might be set >>> different submodels. Both options are described below. >>> >>> The update of widgets should never trigger the action of the widget. >>> >>> Rule 8. View updating because of Model Extension changes >>> ------------------------------------------------------------------------ >>> >>> If the target of a widget is another widget, the action is a User Command >>> on the target widget. These methods should not update the model, because if >>> this was the case, the target should be the model and not the widget. >>> Therefore, User Command methods in widgets can only update Model Extensions >>> or trigger view actions, such as opening new views, etc. If they update >>> Model Extensions they should call #updateView, so the change is shown in the >>> widget and its subviews. >>> >>> sampleUserCommand: data >>> modelExtension1 := data. >>> self updateView >>> "Must call updateView because the model didn't change, and it will not >>> trigger any change event" >>> >>> Rule 9. Subview updating because of submodel changes >>> -------------------------------------------------------------------- >>> >>> If the model has a tree-like structure, its view will send #beMainViewOn: >>> aSubModel to some subviews with a part of the model as the argument. In this >>> case, subviews will need to be notified of the events of their own models. >>> This is because the submodel might trigger the #selfChanged event, and only >>> the views on it should be updated. Views on the bigger model don't need to >>> be updated. This is good for performance when having complex models and >>> views. >>> >>> Rule 10. Subview updating because of model minor changes >>> ----------------------------------------------------------------------- >>> >>> There is another reason for subviews receiving event notifications. A >>> model could trigger a more specific #someAspectChanged event and NOT the >>> main #selfChanged event. This could be done to avoid superfluous and >>> extensive views updating. In this case, some specific view on the view tree >>> should receive the #updateView message, and only the widgets that are part >>> of it will be updated. >>> >>> So, the owing view should send >>> #target:aspect:aspectAdaptor:modelChangeEvent: to these subviews. The >>> implementation is: >>> >>> target: aModel aspect: aSymbol aspectAdaptor: anotherSymbol >>> modelChangeEvent: eventSymbol >>> "Widgets are notified of model changes by being sent #modelChanged. >>> This happens when: >>> - The widget is given a new model (or target widget), aspect or aspect >>> adaptor >>> - An owner view is updated >>> >>> In addition, main views are updated from model events. See #beMainViewOn: >>> >>> But other widgets might update on more specific events from the model. >>> This is useful to >>> update only a small subview, and not the whole main view. >>> >>> This message is sent to such widgets, to set this specific event. >>> >>> Warning: >>> When models change, they should trigger just one event. >>> It might be #selfChanged (the most general one) or a more specific one. >>> But it should not trigger more than one event for each change." >>> >>> self target: aModel aspect: aSymbol aspectAdaptor: anotherSymbol. >>> target when: eventSymbol send: #safeModelChanged to: self >>> >>> Warning: When a model triggers more specific change events we must make >>> sure some widget will be notified of them. Otherwise, those changes could >>> not be shown to the user. >>> >>> Pensar un cacho en como actualizar estas cuando ocurra la actualizacion >>> general. Creo que es justo cuando hay que decirle target:... SI! >>> >>> Rule 11. Accessing views >>> ------------------------------ >>> >>> Nobody should ever query a widget for value or status. A widget should >>> not even query itself for current value or such. The last value or state >>> entered by the user should be stored in the model and/or Model Extensions. >>> When needed, it should be retrieved from there. The only legitimate accesses >>> to subviews are in #initialize and in #updateView. Check implementors of >>> #updateView. >>> >>> Rule 12. Model updating >>> --------------------------- >>> >>> Views DO NOT trigger events. This is not "Event Oriented Programming". >>> This is Object Oriented Programming. The model is updated using the action >>> and the optative actionAdaptor. Methods that react to user activity should >>> update the model by just using the action, a simple message. They are not >>> allowed to ask the model for some other object to work on it. They are not >>> allowed to send other messages to the model. They are allowed to modify >>> Model Extensions. If they do, theyshould also call sned 'self modelChanged' >>> because an action might not modify the model and therefore there could not >>> be a model change event. See ButtonLW>>mouseUp: for an example of this. >>> >>> If you ever feel the need to update the object answered by the aspec, >>> instead of sending a new value to the model (ivar target), it is because >>> that aspect should be the real model. >>> >>> Rule 13. GUI building >>> ------------------------ >>> >>> Main views know about their subviews. Therefore it's them, in theire >>> #initialize method, who build the subviews and customizes them. Views are >>> created before assigning target or model to the main view. Afterwards, the >>> model or target is set, and #modelChanged is called. As seen before, this >>> will set the model or target of all subviews recursively. >>> >>> >>> Misc. notes >>> ------------------- >>> >>> I believe nobody should do #modelChanged, but only #safeModelChanged. >>> Think a bit about this. Maybe if we're certain we're in the UI process, >>> #modelChanged is ok... >>> >>> If a visual detail like #fontColor: in a LabelLW is updated, after >>> updating the ivar, the widget should do 'self changed'. Check the code to >>> see that it is actually done!An example of LightWidgets programming >>> =========================== >>> >>> The ProgrammingWithLightWidgets.txt document might be a little boring to >>> read with all those rules. This document, instead, shows the style of >>> LightWidgets programming based on a concrete example. It focuses on building >>> application guis, an not on building widgets themselves. GUIs done following >>> the LightWidgets ideas are very simple. Remembering the rules might seem a >>> bit rigid, but this avoids complexity in the GUI, making long term >>> mainteinance easier. >>> >>> The example I chose is the Local Users screen in Squeak STB, class >>> STBLocalUserEditorLW. Model are instances of STBLocalUser. >>> >>> Note that even though models are advised to inherit from ActiveModel, >>> STBLocalUser does not. This shows a general rule: Views don't have the right >>> to say how models should work. Models are independent of views. In this >>> case, STBLocalUser inherits from STBModel, the class of persistent objects >>> in the box. >>> >>> Local users are pretty simple objects. They have a userName, a password >>> (only a passwordHash is stored), and a list of groups the user belongs to. >>> >>> The GUI has the following widgets: >>> - An entry field for the name >>> - An entry field for the password >>> - A list of groups the user belongs to. Selecting one and doing <ok> >>> removes the group from the user >>> - A list of available groups (groups the user does not belong to). >>> Selecting one and doing <ok> adds the group to the user. >>> >>> In addition, we have: >>> - A 'Create new User' button >>> - A list of existing users. Selecting one and doing <ok> edits that user >>> - A 'Save' button >>> - A 'Close' button that exist without saving >>> - A 'Delete' button used to actually delete the currently edited user >>> >>> Class STBLocalUserEditorLW has several instance variables for holding its >>> widgets, one model extension 'password'. and one visual property: >>> 'backColor'. Instance variable 'backColor' is only there to avoid computing >>> it each time thescreen is redrawn. Instance variable 'password' is needed >>> because the STBLocalUser can not answer it. >>> >>> The model is an instance of STBLocalUser. However, the list of available >>> users does not depend on it. This list has content even if no model is >>> assigned yet. The model is set later, in messages #selectedUser: and >>> #newUser. >>> >>> Initialization >>> ----------------- >>> >>> Method #initialize creates all the widgets. It is quite long but it does >>> not do anything interesting. It just creates the widgets, lays them out, >>> adds them as submorphs, and stores them in instance variables. It also does >>> 'self newUser', so the user does not need to click the button before >>> entering data. >>> >>> Note that the target of all buttons is 'self', meaning that user commands >>> will be processed by the editor itself. In many cases, (as in the name >>> fields in this editor) the target of the actions would be the model instead. >>> >>> drawing >>> ------------ >>> >>> Method #drawOn: is there only because the backColor is defined in this >>> class. >>> >>> updating >>> ------------ >>> >>> #updateView - This method is called after a new model is set, or if model >>> changes. It sets labels to appropriate values, updates the current and >>> available group lists, and sets the STBUser as the target of the name field. >>> In addition it updates the users list. >>> >>> #password - helper method to access the password entered by the user. >>> >>> user commands >>> ----------------------- >>> >>> #newUser - Creates a new user and sets it as the model of the view. >>> >>> #selectedUser: - Sets the selected user as the model of the view. >>> (Persistent objects note: Persistence is paused, to be resumed in case of >>> save. If the user cancels, nothing should be persisted!) >>> >>> #password: - This is processed here (and not just in the model) to store >>> the password entered by the user. >>> >>> #addGroup: - This is processed here (and not just in the model) to >>> handle keyboard focus. >>> >>> #removeGroup: - This is processed here (and not just in the model) to >>> handle keyboard focus. >>> >>> #saveUser - This makes changes persistent, and logs stuff. >>> >>> #deleteUser - This removes the user from the persistent pool and logs >>> stuff. >>> >>> #cancel - This undoes any changes (by going back to the persisted state), >>> resumes persistence, and closes the editor >>> >>> That's all. It wasn't hard at all, was >>> it?_______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 21, 2010

Re: [Pharo-project] [ANN] TDDFacilities - Restarting a test sends #tearDown and #setUp

by Fernando olivero

GREAT! Is there a ConfigurationOfTDDFacilities available? Fernando On Sep 20, 2010, at 9:23 PM, Hernan Wilkinson wrote: > Hi, > I created a new version of TDDFacilities (TDD-Facilities-HernanWilkinson.15) that includes: > > 1) When debugging a test and the test is changed or restarted, the messages #tearDown and #setUp are sent to the test to restart it in the correct state. (This is something I asked to Niall when showing SUnit 4 at Esug) > 2) Fixed and error with the "Create" button that did not appear when doing "Step Into" or "Step Over". > 3) Removed code to make it compatible with Pharo 1.1 > > I hope you like it! > Hernan. > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > > <ATT00001..txt>

Sept. 21, 2010

Re: [Pharo-project] [Metacello] Metacello as a package management system for Pharo

by Mariano Martinez Peck

On Mon, Sep 20, 2010 at 11:25 PM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > El lun, 20-09-2010 a las 22:31 +0200, Mariano Martinez Peck escribiÃ³: > > Hi folks. First of all, sorry for the long email (I guess it will be > > long). After thinking and discussing hundred of times in the mailing > > lists, last week we all meet and talk about Metacello and Pharo. Dale, > > Stef, Marcus, Esteban, all were present. I want to write down all the > > ideas and solution in order to: not to forget them; and to get > > feedback and opinions from you. > > > > Problems we want to face: > > > > 1) Right now a user CANNOT know which version of a project is the > > stable for a specific Pharo version. For example, suppose > > ConfigurationOfXXX. The user cannot know that XXX 3.45 is the stable > > for 1.0 and that XXX 5.7.3 is the one for 1.1....etc...so users end > > up confused not knowing which version to download. In addition, > > #latestVersion is not enough, because that will answer you the latest > > version, but that may not be the correct one for older Pharo images. > > Suppose in the previous case, latestVersion may answer 5.7.3 which may > > not work in Pharo 1.0..... We want the user to be able to autaticallly > > load the stable version for each pharo version without needing to know > > that. > > > > 2) Have a repository for each Pharo version so that someone can easily > > browse the available configurations for that Pharo version, and load > > them. Not only one as it is now woth MetacelloRepository. > > > > 3) Be self contained. Sometimes developers removed packages of > > versions from their repositories. In such case, Metacello cannot do > > anything and the load may not work anymore. We want to be able to > > reproduce the load and be able to load the same 10 years after. > > ok > > > > > Solution proposed: > > > > The proposed solution may not even involve Metacello. You may have > > heard about Metacello Project Loader developer by Esteban Lorenzano. > > See http://www.smallworks.com.ar/en/community/GoferProjectLoader > > The idea is rename that project to that it is a general name like > > GoferProjectManager or something like that, because now it will do > > load but also write :) > > I will call it GoferProjectManager in this email. > > > > The idea is that every developer of a configuration define the stable > > version for each Dialect version. There are two possible alternatives: > > > > a) That each Conf class implements #stableVersion: spec, which could > > be something like: > > > > ConfigurationOfXXX >> stableVersion: spec > > spec for: #Pharo1.0 do: [ ^ self version: '3.45' ]. > > spec for: #Pharo1.1 do: [ ^ self version: '5.7.3' ]. > > spec for: #Pharo1.2 do: [ self error: 'There is no stable > > version for Pharo 1.2' ]. > > spec for: #Gemstone do: [ ^ self version: '4.2' ]. > > ..... > > This implies that the stableVersion method will be heavily modified as > the software is ported to new platforms and new releases. Not a big > deal. Sometimes will imply that a merge will be needed when 2 developers > want to maintain the configuration. Yes...what how many times would you have a conflic? Anyway, as you said, a simple merge solves the problem. > Also, I feel that disconnects the > version method from the version string declaration/publication. again, > not a big issue either. > True. That's why we have also option b) > > > > > or something like that...the idea is that you define stable versions > > for each platform. > > > > The idea is that now the user could do something like this: > > ConfigurationOfXXX project stableVersion load > > but he won't do that ;) > > > > b) another approach is to specify something in each version, for > > example: > > > > ConfigurationOfXXX >> version345: spec > > <version: '3.45' imports: #('1.2-baseline')> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec description: 'Blah balh...'. > > spec platformVersion: 'Pharo 1.0' > > > > and > > > > ConfigurationOfXXX >> version573: spec > > <version: '5.7.3' imports: #('1.2-baseline')> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec description: 'Blah balh...'. > > spec platformVersion: 'Pharo 1.1' > > > > Now...any of those alternatives would solve problem 1) > > > As you say they are equivalent ways to state the same information. I > like this because it is only a place to modify the new version number. > I personally like this, but also I can imagine that this could lead to > big methods with conditionals for functionality that applies to more > than one release. > > Exactly. And this way it is a bit more complex to calculate. Suppose the user does ConfigurationOfXXX project stableVersion. There you have to check in which Pharo you are, then, check ALL selectors that are version methods, and get the selector that as in the code the pharo version you are in. But how to do that? maybe you have "Pharo 1.0" as a comment and maybe it is found? another is to run the execution over each method and then ask to the spec :) Fnally, you will have several versions for the same Pharo version. Suppose first I set 3.45 as stable for Pharo 1.0 but then I do it for 3.46 so....we have to take the last one. > Maybe the first option requires less work for Dale to support this > functionality. > > Yes, I think it is easier altought you may want to do the second one. > > > > Now to solve 3) the idea is that GoferProjectManager could provide > > something like this: > > > > (Gofer project 'XXX') publishVersion: '3.45' for: 'Pharo 1.0' > > or then > > (Gofer project 'XXX') publishVersion: '5.7.3' for: 'Pharo 1.1' > > etc... > > > > Then this would do different things: > > > > a) Automatically take the conf class (it is important the name > > conventions!!) > > b) Commit it into the correct Pharo repository version. For example > > for 3.4.5 it will commit it in PharoMetacelloRepository10 and 5.7.3 to > > PharoMetacelloRepository11 > > c) Traverse all the dependencies of all needed packages and commit all > > of them to PharoPackagesContainer10 or > > PharoPackagesContainer11....etc > > Dale sent few weeks ago a script that does that: takes a conf, a > > version and a repo and commits all the files to that repo. > > > > With all this we solve 2). The idea is that for EACH pharo version we > > will have 2 repositories, one for the confs and another one for the > > packages (as a backup). > > I like it. Now, when traversing dependencies, wouldn't be good to also > rewrite the repositories they point to so that they point to self > (repository). This way the problem 3 is solved too, because the > configuration already points to self and not the original repo? > > That's a good idea :) You mean...in order not to traverse it twice? with this we could save the call to #repositoriesOverrides. I guess it would be possible. > This maybe could be easier if Metacello could have a way to indirect > repository names from the configuration so that the metacello version > projects only referred a keyworkd and not the real package and then on > commiting the package to the repo, it would be rewritten or overriden > with the container repository? > > For example, instead of: > > spec for: #squeakCommon do: [ > spec > project: 'OSProcess' with: [ > spec > className: 'ConfigurationOfOSProcess'; > loads: #('default'); > file: 'ConfigurationOfOSProcess'; > repository: 'http://www.squeaksource.com/MetacelloRepository' ]. > spec > repository: 'http://www.squeaksource.com/Magma'; > package: 'WriteBarrier' with: [ > spec repository: 'http://www.squeaksource.com/WriteBarrier' ]; > > you'll write a baseline like: > > spec for: #squeakCommon do: [ > spec > project: 'OSProcess' with: [ > spec > className: 'ConfigurationOfOSProcess'; > loads: #('default'); > file: 'ConfigurationOfOSProcess'; > repository: #osProcessRepository ]. > spec > repository: 'http://www.squeaksource.com/Magma'; > package: 'WriteBarrier' with: [ > spec repository: #writeBarrierRepository ]; > > and will define the repositories somewhere else: > > ConfigurationOfXXX>>repositoryFor: aSymbol > ^ repoMap at: #aSymbol "This will return the real repo" > > > And when commiting, maybe the GoferProjectManager will create a subclass > with a method overriding the repository map to > > ConfigurationOfXXX>>repositoryFor: aSymbol > ^ 'http://www.squeaksource.com/PharoPackagesContainerXX' > Ok....I got the idea. > > > I haven't used repositoryOverrides so maybe this is nonsense and not > necessary and can be handled cleanly and better by Metacello itself. :) > > > And yes, I think itis handle by Metacello. But, as far as I understand, you can send the "#repositoryOverrides: newRepository" to a version. That will traverse all dependencies and then for each of them it traverse it does a "#repository: newRepository" . Once this is done, you can said "load" to the version. It seems they are 2 different approaches. > > > > The last point is that when loading we should load everything from the > > PharoPackagesContainer10 or PharoPackagesContainer11...but we don't > > want to change all our confs (for example, they are pointing to they > > own repos or MetacelloRepository)....so the solution is that we use > > GoferProjectManager to load. Example: > > > > Gofer project: 'XXX' loadStable > > > > and loadStable would be something like: > > > > self stableVersion repositoryOverrides: (self containerRepo); load > > > > The idea is that it can use #repositoriesOverride to override with the > > correct repository... > > > > So.....that's all. What do you think? does this make sense? > > > > Cheers > > > > Mariano > > > Overall I agree. The less the user has to type and know from where the > packages come the better for we all. > > :) > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > >

Sept. 21, 2010

[Pharo-project] Parsing HTML

by Alberto Bacchelli

Hi, Is there a package I can use to parse HTML? Thanks and ciao, Alberto

Sept. 21, 2010

Re: [Pharo-project] Launching class form command line ...

by Lukas Renggli

> How does Pharo execute classes from the command line? You can pass the filename of a .cs/.st file to the VM that gets filed-in on startup. > Is there a way to specify the class and the method to be called? Not directly. > Are command line arguments available? $ squeak --help Usage: squeak [<option>...] [<imageName> [<argument>...]] squeak [<option>...] -- [<argument>...] FBDev <option>s: -fbdev <dev> use framebuffer device <dev> (default: /dev/fb) -kbmap <file> load keymap from <file> (default: use kernel keymap) -msdev <dev> use mouse device <dev> (default: /dev/psaux) -msproto <protocol> use the given <protocol> for the mouse (default: ps2) -vtlock disallow all vt switching (for any reason) -vtswitch enable keyboard vt switching (Alt+FNx) Common <option>s: -encoding <enc> set the internal character encoding (default: MacRoman) -help print this help message, then exit -memory <size>[mk] use fixed heap size (added to image size) -mmap <size>[mk] limit dynamic heap size (default: 1024m) -noevents disable event-driven input support -notimer disable interval timer for low-res clock -pathenc <enc> set encoding for pathnames (default: UTF-8) -plugins <path> specify alternative plugin location (see manpage) -textenc <enc> set encoding for external text (default: UTF-8) -version print version information, then exit -vm-<sys>-<dev> use the <dev> driver for <sys> (see below) Deprecated: -display <dpy> quivalent to '-vm-display-X11 -display <dpy>' -headless quivalent to '-vm-display-X11 -headless' -nodisplay quivalent to '-vm-display-null' -nosound quivalent to '-vm-sound-null' -quartz quivalent to '-vm-display-Quartz' Notes: <imageName> defaults to `squeak.image'. -vtlock disables keyboard vt switching even when -vtswitch is enabled If `-memory' is not specified then the heap will grow dynamically. <argument>s are ignored, but are processed by the Squeak image. The first <argument> normally names a Squeak `script' to execute. Precede <arguments> by `--' to use default image. Available drivers: vm-sound-null vm-sound-custom vm-display-custom vm-display-null vm-display-fbdev -- Lukas Renggli www.lukas-renggli.ch

Sept. 21, 2010

[Pharo-project] Launching class form command line ...

by James Ladd

Hi All, How does Pharo execute classes from the command line? Is there a way to specify the class and the method to be called? Are command line arguments available? I want to put the same mechanism in Redline Smalltalk. Rgs, James.

Sept. 21, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Jimmie Houchin

Sept. 21, 2010