October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] XML package is barking at load time
by StÃ©phane Ducasse Oct. 31, 2010

Oct. 31, 2010

in seaside3.0 On Oct 31, 2010, at 10:55 AM, stephane ducasse wrote: > Gofer new > squeaksource: 'XMLSupport'; > package: 'XML-Parser'; load. > > raise error because of tests not present. > > Did I do something wrong? > > > Then why the configuration load pastell? > > why this is squeakCommon? Does it work if this is in pharo? > > Why do we load SIXX in gemstone? > > This configuration looks like a mess. Can somebody fix that. > core should load the parser > sixx may be sixx > pastell should load core and pastell > > Stef > > > version105: spec > <version: '1.0.5' imports: #('1.0.5-baseline' )> > > spec for: #'common' do: [ > spec blessing: #stable. > spec author: 'Alexandre Bergel'. > spec timestamp: '10/5/2010 14:06'. > ]. > > spec for: #'squeakCommon' do: [ > spec > package: 'XML-Parser' with: 'XML-Parser-AlexandreBergel.93'; > package: 'Pastell' with: 'Pastell-Alexandre_Bergel.18'.]. > > spec for: #'gemstone' do: [ > spec project: 'Grease Core' with: '1.0-rc'. > spec > package: 'XML-Parser' with: 'XML-Parser.g-DaleHenrichs.93'; > package: 'SIXX' with: 'SIXX-NorbertHartl.171'.]. > > > > Stef >

1 0

Re: [Pharo-project] how to load magritte in seaside 3.0?
by StÃ©phane Ducasse Oct. 31, 2010

Oct. 31, 2010

Ok I will use magritte2. should I load grease too? Stef On Oct 31, 2010, at 10:41 AM, Lukas Renggli wrote: > Magritte 2 uses Grease as a portability layer and works well on Seaside 3. > > Magritte 1 has its own portability layer, works well on Seaside 2.8, > but also 3 (I think). > > You should use Magritte 2 on Seaside 3. > > Lukas > > > > On 31 October 2010 10:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> thanks lukas >> >> what is magritte2 vs magritte? >> Because I 'm trying to rebuild an old image of mine that use an old version of magritte >> >> Stef >> >> On Oct 31, 2010, at 10:11 AM, Lukas Renggli wrote: >> >>> Until somebody figures out why the configuration does not work you >>> could use the following script from >>> http://github.com/renggli/builder/blob/master/scripts/magritte2.st. Of >>> course this assumes that Seaside 3 is already loaded. >>> >>> Gofer new >>> renggli: 'magritte2'; >>> package: 'Magritte-Model'; >>> package: 'Magritte-Pharo-Model'; >>> package: 'Magritte-Seaside'; >>> package: 'Magritte-Pharo-Seaside'; >>> package: 'Magritte-Morph'; >>> package: 'Magritte-Tests-Model'; >>> package: 'Magritte-Tests-Pharo-Model'; >>> load. >>> >>> Lukas >>> >>> On 31 October 2010 09:38, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>> Hi >>>> >>>> I want to load magritte with Seaside 3.0 and I followed >>>> >>>> http://book.pharo-project.org/book/PharoTools/Magritte/ >>>> >>>> Magritte2 For Pharo With Seaside 3 >>>> >>>> Gofer it >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfMagritte'; >>>> load. >>>> (ConfigurationOfMagritte2 project version: '2.0.5') load >>>> >>>> but I does not load. >>>> >>>> Stef >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

2 1

[Pharo-project] how to load magritte in seaside 3.0?
by stephane ducasse Oct. 31, 2010

Oct. 31, 2010

Hi I want to load magritte with Seaside 3.0 and I followed http://book.pharo-project.org/book/PharoTools/Magritte/ Magritte2 For Pharo With Seaside 3 Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMagritte'; load. (ConfigurationOfMagritte2 project version: '2.0.5') load but I does not load. Stef

2 1

Re: [Pharo-project] Issues Tagged 1.2 on the BugTracker
by Marcus Denker Oct. 31, 2010

Oct. 31, 2010

On Oct 31, 2010, at 9:45 AM, StÃ©phane Ducasse wrote: > Thanks marcus. > So what is the process do we declare 1.2 beta? > -> Declare it. -> Change the version number with an update. We should do that soon. Of course, after that only "show stopper" bug fixes are allowed. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] [OffTopoc] Symbol understands value: nice hehehehehhe
by StÃ©phane Ducasse Oct. 31, 2010

Oct. 31, 2010

+1 especially when this is specific to a given system > I like the idea of using fooValue: instead of value:. > > On 10/30/10 14:15 , Tudor Girba wrote: >> We use this pattern in Mondrian scripts, Glamour scripts, and in Moose scripts for navigating models. >> >> However, we are most of the times doing it with other Symbol selectors. For example: >> - in Mondrian, we use moValue: >> - in Glamour, we use glamourValue: >> >> Using dedicated extensions enable us to control the kinds of semantics we want in the scripting. For example, the glamourValue: is different from moValue:. >> >> Cheers, >> Doru >> >> >> On 30 Oct 2010, at 22:56, Andres Valloud wrote: >> >>> Mariano, >>> >>> On 10/30/10 13:14 , Mariano Martinez Peck wrote: >>> >>>> 100% agree. It was just funny for me, how could I do that, just >>>> implementing Synbol>> value: >>>> Just something curious and funny. Not to really use it. >>> >>> I agree with this, polymorphism is awesome. For instance, something I did with Assessments was to make objects polymorphic with classes. This device allows Assessments to run SUnit tests without needing to touch any of the test case classes (you can just create pseudo-classes that pretend to be the classes you need but can't have). And you get to implement #new on the instance side :). >>> >>> Andres. >>> >> >> -- >> www.tudorgirba.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> . >> >

2 1

[Pharo-project] [update 1.2] #12221
by Marcus Denker Oct. 31, 2010

Oct. 31, 2010

12221 ----- Issue 2815: Must kick me to provide TEasilyThemed helpers for all widgets (first part) Issue 3186: UndoManagerTest needs to be moved to a test package Issue 3176: Move Debugger tests from Tools to ToolsTest Issue 3175: Remove strange Packages -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Changes not working since update
by StÃ©phane Ducasse Oct. 31, 2010

Oct. 31, 2010

may be this is related to the strange registration to smalltalk that caused the recentMessages to not contain changes too. On Oct 31, 2010, at 9:22 AM, Marcus Denker wrote: > > On Oct 31, 2010, at 9:21 AM, Marcus Denker wrote: >> >> >> I checked: yes, one needs to open the changesorter once to get any >> changes recorded. >> >> This is a bug... maybe some #initialize call is missing in the cleanup code? > > > > http://code.google.com/p/pharo/issues/detail?id=3189 > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

1 0

Re: [Pharo-project] Issues Tagged 1.2 on the BugTracker
by StÃ©phane Ducasse Oct. 31, 2010

Oct. 31, 2010

Thanks marcus. So what is the process do we declare 1.2 beta? Stef On Oct 31, 2010, at 9:17 AM, Marcus Denker wrote: > 37 out of 387: > > http://code.google.com/p/pharo/issues/list?cursor=2858 > > ... not all are showstoppers. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

1 0

Re: [Pharo-project] Changes not working since update
by Marcus Denker Oct. 31, 2010

Oct. 31, 2010

On Oct 31, 2010, at 9:21 AM, Marcus Denker wrote: > > > I checked: yes, one needs to open the changesorter once to get any > changes recorded. > > This is a bug... maybe some #initialize call is missing in the cleanup code? http://code.google.com/p/pharo/issues/detail?id=3189 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Changes not working since update
by Marcus Denker Oct. 31, 2010

Oct. 31, 2010

On Oct 31, 2010, at 2:47 AM, Igor Stasenko wrote: > after updating pharo core image (Update #12220), > the list of changes is just one: 'Unnamed', Yes, that comes from the #releaseCleanup cleaning the changesets. > also, it was empty once i tried to check what changes i did to image, > after some coding. > Once i created a new changeset, and changed few things, these changes > recorded properly in new changeset I checked: yes, one needs to open the changesorter once to get any changes recorded. This is a bug... maybe some #initialize call is missing in the cleanup code? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Changes not working since update
by Igor Stasenko Oct. 31, 2010

Oct. 31, 2010

after updating pharo core image (Update #12220), the list of changes is just one: 'Unnamed', also, it was empty once i tried to check what changes i did to image, after some coding. Once i created a new changeset, and changed few things, these changes recorded properly in new changeset -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] [OffTopoc] Symbol understands value: nice hehehehehhe
by Mariano Martinez Peck Oct. 30, 2010

Oct. 30, 2010

Hi. Today I was giving a lesson and I was trying something something like this: ByteString allInstances select: [ :aString | aString size > 1000 ] But sometimes, we want (not in this example) delegate the behavior to the object, for example: ByteString allInstances select: [ :aString | aString isTooBig ] And then....I (actually, a classmate told me) realised that Symbol understands value: too. So I can do this: ByteString allInstances select: #isTooBig and it also works :) Interesting, isn't it ? cheers Mariano ps: if everybody already know this, please forgive my completly ignorance

3 5

[Pharo-project] [ANN 1.2] pre-built core1.2#12220
by Marcus Denker Oct. 30, 2010

Oct. 30, 2010

https://gforge.inria.fr/frs/download.php/27719/PharoCore-1.2-12220.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Wrong O2 loaded by default
by Johan Fabry Oct. 30, 2010

Oct. 30, 2010

Hi all, DEVImageWorkspaces openExternalProjectWorkspace shows a script for O2 that loads a version that is not up to date and therefore does not work in Pharo 1.1 Could some Metacello or O2 wizard please solve this problem? -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

2 1

[Pharo-project] [update 1.2] #12220
by Marcus Denker Oct. 30, 2010

Oct. 30, 2010

12220 ----- Issue 2387: Workspace Issue 2903: EntryFieldMorph>>hasErrors: aBoolean Issue 3174: Cleanup packages -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] A pattern for GUI programming (Morphic, Cuis, etc)
by Juan Vuletich Oct. 30, 2010

Oct. 30, 2010

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?

8 14

[Pharo-project] [Idiom] 'myfile.txt' asFileName readStream contents
by Hannes Hirzel Oct. 30, 2010

Oct. 30, 2010

Hello Randal Schwartz writes in his blog http://methodsandmessages.posterous.com/writestreams-of-consciousness-going… about streams citing Derek Williams http://derekwilliams.us/?p=1411 He gives the following as an example of elegant syntax of Smalltalk 'myfile.txt' asFileName readStream contents This does not work in Squeak nor in Pharo. It produces a ReadStream on the contents of the _String_ 'myfile.txt'. i.e. the ByteString with 10 elements. Comments? Regards Hannes

3 5

Re: [Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file
by StÃ©phane Ducasse Oct. 30, 2010

Oct. 30, 2010

Thanks! and welcome back. Stef On Oct 11, 2010, at 7:16 AM, Sheridan Mahoney wrote: > I've just re-entered the Pharo world after a long(ish) absence, and wanted to report a > new bug submission; here's the breakdown: > > Pharo image: dev > Pharo core version: Pharo-1.1.1-- Latest update: #11414 > Virtual machine used: 4.0.3.2202 Unix VM > OS: Ubuntu Lucid Lynx 10.04 > Class browser used if applicable: SystemBrowser default > > Steps to reproduce: > 1. start pharo > 2. open a Shout workspace > 3. select the just-opened workspace > 4. Ctrl-right button to get the meta-click window > 5. select 'save morph in file' > 6. hit 'ok' to proffered name for file > 7. a message box comes up that reads 'please wait while objects are > counted'. > 8. shortly after that an error is generated: > 'Error: this context was not included in the ImageSegment' > > > I'm planning on doing more research, but wanted to get the issue reported. > > Cheers, > Sheridan > > PS - so far I really like 1.1.1 !!! Good work, gang! > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 4

Oct. 29, 2010

On Oct 28, 2010, at 5:05 PM, Pavel Krivanek wrote: > Hi, > > I uploaded a new version of PharoKernel. It has several new properties: > - better scripts processing > - separate dictionaries for images, scripts, reports and downloaded packages > - It is able to load Network, Monticello and Gopher (image included), > however it needs some next fixes to work properly > - ImageMap and ImageGraph included in the archive > > https://gforge.inria.fr/frs/download.php/27699/PharoKernel-1.2-12217.zip > > The most important thing that should be done in Pharo is to split > Tests package to be able to load Monticello tests separately. Yes and that they follow the pattern > If Monticello and Gofer will work well then it should be quite simple > to prepare PharoCore Configuration to load the rest of PharoCore. Yes this is the vision but now our problem is to port our integration process to it. We will certainly changes it anyway because it slows us down (does not scale) but it requires to have a good alternative. Stef

3 3

Re: [Pharo-project] [update 1.2] #12217
by Marcus Denker Oct. 29, 2010

Oct. 29, 2010

On Oct 27, 2010, at 8:01 PM, Tony Fleig wrote: > In my Pharo core image there is indeed a Software Update entry under System, but when I select it a window pops up that says "0 new update file(s) processed." > > In my Seaside One-Click Image, there is no Software Update entry at all. -> only core images can be updated. Reason: updates do not cover packages managed outside (e.g. OmniBrowser, OCompletion). Yet the Core changes can make these packages not work anymore due to e.g. deprecation of code. -> Core images only load the updates of their release. that is, a 1.1 image loads updates for 1.1.1, but not for 1.2. Reason: You do not want to load experimental updates in a production system. All of this is far from perfect and should be improved. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

Oct. 29, 2010

On Oct 29, 2010, at 10:12 AM, Fernando Olivero wrote: > Hi Luc, great work! > > I found it useful to enhance my Gaucho search widgets ( that can now > ported to Pharo on top of the new system navigation ), and provide > contextualized searches in a cleaner manner. > > Are the environments you are using those of the RefactoringEngine ? right now there are just instances of system dictionary. Now the goal is to change the superclass or add one in between SystemDictionary to add RBEnvironment API or modified API so that systemDictionary can play the role of a leave in the RB Environment composite structure. So the idea is that we will be able to bridge smoothly RBEnvironment and SystemDictionary and we will be able to run cooooool queries. Gorgeous isnt :) Stef > > Fernando > > > On Fri, Oct 29, 2010 at 10:04 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >> Hi all, >> >> I >> committed SLICE-Issue-00001-MakeSystemNavigationEnvironmentAware-LucFabresse.2 in PharoTaskForces. >> Now SystemNavigation is environment aware. >> There two test classes : >> - SystemNavigationTest has been modified to test SystemNavigation on >> Smalltalk globals >> - SystemNavigationOnNewlyCreatedEnvironmentTest tests SystemNavigation >> on a new Environment >> have look >> at SystemNavigationOnNewlyCreatedEnvironmentTest>>testEnsureDefaultEnvironmentNotUsed >> ClassFactoryWithOrganizationForTestCase has been added to easily create >> classes >> ClassFactoryWithOrganizationForTestCaseTest test this latter class. >> Merge well in 12218 and tests are green. >> #Luc >> >

2 1

Oct. 29, 2010

thanks marcus. Stef On Oct 29, 2010, at 6:15 PM, Marcus Denker wrote: > 12219 > ----- > > Issue 3145: Glamourous Theme integration > Issue 3171: Fix an Undeclared ref in UndoRecord > Issue 3170: Catchall for trivial cleanups > Issue 2994: PharoKernel Part 18 (part 2) > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

1 0

[Pharo-project] Thoughts on Monticello/GIT?
by Geert Claes Oct. 29, 2010

Oct. 29, 2010

A feedback post on the ESUG list from the GSoC somehow turned into an idea sandpit. I would like to test the water about one of the ideas to get a feeling about what people thoughts are regarding Pharo/GIT? Some groundwork has already been done via the gitocello (I like the name) project. Paolo Bonzini-2 wrote: > > ... For the VCS, I've always been surprised there's no git or svn backend > for Monticello. It wouldn't seem _too_ hard to have a directory per > package and replace each .mcz file with a commit in that directory. > > Alternatively, there's actually very little GST-specific code in > http://github.com/timfel/gitocello (a Squeak+Monticello <-> GST+git > bridge), so if someone wants to play with it... > -- View this message in context: http://forum.world.st/Thoughts-on-Monticello-GIT-tp3019086p3019086.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 3

[Pharo-project] GraphViz in pharo
by Guillermo Polito Oct. 29, 2010

Oct. 29, 2010

Hi! I downloaded Graphviz yesterday in my ubuntu machine using pharo 1.1.1 with cog, and graphviz worked very well :). Today I'm using a pharo 1.1 image and 4.0.2 VM on windows machine and I can't make it work :(. Graphviz needs OSProcess and CommandShell. I downloaded them, but there are some problems: - For windows it uses Win32Shell, which isn't in my Pharo Image of course :P. So I replaced it by CommandShell but it is still failing. - I'm trying to use CommandShell on its own, but I have the folowing result: *$ ls cannot access system to run 'ls'* GraphViz was adapted to pharo this year on June by "SR". Â¿Does someone know who's him or her? Â¿Can someone send me a tip? Thanks! Guille

6 6

[Pharo-project] Glamour theme now loads in Pharo1.2
by Fernando Olivero Oct. 29, 2010

Oct. 29, 2010

Name: Glamour-Morphic-Theme-FernandoOlivero.22 Author: FernandoOlivero Time: 28 October 2010, 3:26:49 pm UUID: fa2bf315-5143-4e38-8e1d-6563510b1169 Ancestors: Glamour-Morphic-Theme-tg.21 Ported the style to Pharo1.2. Dropped the usage of MenuIcons, because this class was deprecated, now each theme defines its own Icons class. See GLMUIThemeIcons.

3 2