- Pharo-users - lists.pharo.org

http://www.zazzle.com.au/pharoshop
by Torsten Bergmann Oct. 12, 2013

Oct. 12, 2013

Stef wrote on user list >I would like to thank lusy and jeff for their effort. > >>Dear All, >> >> let me introduce a new store "PharoShop" >> http://www.zazzle.com.au/pharoshop >> >> Please note the products description - >> I'm not confident in my english and ready to accept your offers for inspire the customers :) >> >> Have a great day! >> >>Lusy Hi Stef, nice - take care: this product has a typo: Pharo.OGR instead of Pharo.org: http://www.zazzle.com.au/pharo_mousepad-144390617182821879 Bye T.

1 0

Re: [Pharo-users] Simple Spec Examples
by benjamin.vanryseghem.pharo＠gmail.com Oct. 11, 2013

Oct. 11, 2013

Indeed, it was just a first try to have something to build a reflection on :-) Changing the name is always easier than implementing something new (and it's also easier to have the community involved at this level). I think that #selectedItem is somehow wrong in the context of a tree. I will introduce a specific class to describe a path in the tree Ben ----- Reply message ----- De : "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> PourÂ : "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Objet : [Pharo-users] Simple Spec Examples Date : ven., oct. 11, 2013 21:08 agreed :) > Would it be possible to change the name of the selector? > > tree selectedItem: (1 -> 11) > > for me that implies that the tree contains an actual item (1 -> 11). > What you want is maybe, #selectedPath: or #selectedItem:1 withParents:{11} > > My general rule is: Each time you have to use an association or a point you do something wrong.. > It is hard to guess what this association should mean, so either make a domain object to describe > what you encode in the association or use specific selectors that say what the arguments mean. > > On 2013-10-11, at 19:52, btc(a)openinworld.com wrote: > >> btc(a)openinworld.com wrote: >>> Benjamin wrote: >>>> Ben >>>> >>>> On Oct 11, 2013, at 9:24 AM, btc(a)openInWorld.com wrote: >>>> >>>>>> btc(a)openinworld.com wrote: >>>>>>>> I found it hard to find documentation on Spec beyond [1],[2],[3], some of which seem to have changed some syntax since they were written. I've been piecing things together to work out how to set the selected item with the simplest example I could. Even though it turns out pretty simple, I thought I'd share in case it was useful for others that haven't dipped their toes into Spec yet. >>>>>> >>>>>> ComposableModel subclass: #TestSpec >>>>>> instanceVariableNames: 'list text' >>>>>> classVariableNames: '' >>>>>> poolDictionaries: '' >>>>>> category: 'BTCPlay' >>>>>> >>>>>> TestSpec >> initializeWidgets >>>>>> self instantiateModels: #( #list #ListModel ). >>>>>> >>>>>> TestSpec >> getList >>>>>> ^list >>>>>> >>>>>> TestSpec class >> mySpecLayout >>>>>> <spec:#default> >>>>>> ^ SpecLayout composed >>>>>> add:#getList ; >>>>>> yourself. >>>>>> >>>>>> Then from Workspace >>>>>> x := (TestSpec new openWithSpec ; yourself). >>>>>> x getList items: { 1 . 2 . 3 . 4}. >>>>>> x getList setSelectedItem: 2. >>>>>> >>>>>> cheers -ben >>>>>> >>>>>> [1] hal.inria.fr/hal-00759030/PDF/Spec-IWST12-Final.pdfâ >>>>>> [2] https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… >>> [3] http://hal.inria.fr/docs/00/70/80/67/PDF/SpecTechReport.pdf >>>>>> >>>>>> >>>>>> >>>>>>>> So here is the same thing with TreeModel. >>>>> >>>>> ComposableModel subclass: #TestSpec2 >>>>> instanceVariableNames: 'tree' >>>>> classVariableNames: '' >>>>> poolDictionaries: '' >>>>> category: 'BTCPlay' >>>>> >>>>> TestSpec2 >> initializeWidgets >>>>> self instantiateModels: #( #tree #TreeModel ). tree >>>>> childrenBlock: [ :treeItem | self haltOnce. (treeItem isKindOf: Association) ifTrue: [ treeItem value ] ifFalse: [ {} ] ]. >>>>> >>>>> TestSpec2 >> getTree >>>>> ^tree >>>>> >>>>> TestSpec2 class >> mySpecLayout >>>>> <spec:#default> >>>>> ^ SpecLayout composed >>>>> add:#getTree ; >>>>> yourself. >>>>> >>>>> Then from Workspace (referring to attached pic) >>>>> x := (TestSpec2 new openWithSpec ; yourself). >>>>> x getTree roots: { 10 -> { 11. 12 } . 20 -> { 21 . 22 } } . >>>>> x getTree selectedItem. "<Print It> --> 21 " >>>>> x getTree selectedItem: ???? >>>>> >>>>> Now how do I select a particular tree item at each level ? >>>>> eg. Select 10 and Select 12 ? >>>>> >>>>> cheers, ben >>>>>> >>>> There was something missing here at the two levels :) >>>> You can see case 11849[1] fixing the morphic issue >>>> and case 11850 [2] fixing the Spec problem :) >>>> Thanks. I'll try it. >>>> Then your example make me think that using association > to describe the path may lead to an ambiguous situation >>>> True. But to clarify things, ListModel suffers the same ambiguity as follows... >>> x := (TestSpec new openWithSpec ; yourself). >>> x getList items: { 1 . 2 . 3 . 2 . 4}. >>> x getList setSelectedItem: 2. >>> >>> ... ListModel and Treemodel should be consistent in this respect. >>> Musing further about this... >>> In the case of a multi-selection ListModel/TreeModel, it is probably reasonable to select all matching. >>> For a single-selection, I'm not sure. Considering ListModel first, maybe defaulting to selecting the first matching is reasonable, perhaps with a backup method to select the Nth match. Then again, if the identical object appears in the list multiple times, then #setSelectedItem: might visually highlight all occurances while still reporting only a single object with #selectedItems. I think part of a test would go... >>> >>> x getList items: { 1 . 2 . 3 . 2 . 4}. >>> x getList setSelectedItem: 2. >>> y := x getList selectedItem. >>> x getList setSelectedItem: y. >>> z := x getList selectedItem. >>> self assert: (y = z) >>> >>> ...which actually works so ListModel is cool in that regard - except maybe an option to visually highlight both 2s would be useful - but as a visual thing maybe that is a handled outside of ListModel. >>> Actually that should work the same with multi-selection. >>> >>> x getList items: { 1 . 2 . 3 . 2 . 4}. >>> x getList setSelectedItems: { 2. 3 }. >>> y := x getList selectedItems. >>> x getList setSelectedItems: y. >>> z := x getList selectedItems. >>> self assert: (y = z) >>> >>> Actually it seems there is no #setSelectedItems:. >>> How then do you save and restore a multi-selection. e.g.... >>> savedSelection := x getList selectedItems. >>> "other code that clears/modifies the selection - like refresh for additional items" >>> x getList selectedItems: savedSelection. >>> >>> cheers -ben >>> >>>> Ben >>>> >>>> [1] https://pharo.fogbugz.com/default.asp?11849 >>>> [2] https://pharo.fogbugz.com/default.asp?11850 >>>> >>>>>> >>>>> <Spec-TreeModel-simple-example.png> >>>>>> >>>> >>>> >>> >> I installed your slices from Issues 11849 & 11850 and it looks mostly good. >> >> Using a modified TreeModel example which I think provides a clearer/nicer example... >> >> TestSpec2 >> initializeWidgets >> self instantiateModels: #( #tree #TreeModel ). tree childrenBlock: [ :treeItem | (treeItem > 10000) ifTrue: [ #() ] ifFalse: [ (1 to: 3) collect: [ :i | treeItem * 10 + i ] ] ]. >> >> Then in Workspace... >> x := (TestSpec2 new openWithSpec ; yourself). >> x getTree roots: { 1. 2 . 1 . 11 }. >> x getTree expandRoots. >> x getTree selectedItem: 11. "left side of attached pic" >> x getTree selectedItem: (1 -> 11). "right side of attached pic" >> >> So the attached pic shows exhibits the behaviour I was musing about earlier - very cool. Before those slices there was no response to #selectedItem: from the widget. >> However a couple of things... >> >> 1. x getTree selectedItem: 12. >> x getTree selectedItem. "<PrintIt> --> 12" >> while... >> x getTree selectedItem: ( 1 -> 13 ). >> x getTree selectedItem. "<PrintIt> --> 1->13" >> >> I think you really want #selectedItem to return the same thing each time regardless of how it was set. That is, just the object. >> Andn further, it would be better to have a separate accessors #selectedItem and #selectedPath >> >> 2. The following doesn't work... >> x getTree selectedItem: { 1 -> 12 -> 121 }. >> >> cheers -ben >> >> >> >> >> >> <Issue-11849&11850.png> >

1 0

Start with a trivial improvement!
by Marcus Denker Oct. 10, 2013

Oct. 10, 2013

One nice way to get in the mood of doing (and at the same time testing the system) is to start with trivial improvements. This is especially nice as a "starter" when you never contributed any change to Pharo. And by trivial I mean *really* mean trivial: -> a typo in a comment -> remove a temp not accessed -> clean out some trivial dead code -> do a simplistic refactoring of a bad smell, even inside a single method -> document something -> structure bad stuff better so it is easier to replace later Taken in itself, single changes like these have no influence, but: -> they get you in a mood of doing. -> they make you feel that Pharo is "owned" by you. -> take 1000 of those trivialities and they *do* make a difference. -> next time something bothers you, you will have the context of "I can just fix it". The critic tools is one way of finding these places, another is to just note down every time you see a triviality and later go through that list. The bug tracker can be source, too. Marcus

5 5

visual clues help
by Paolo Piccinelli Oct. 10, 2013

Oct. 10, 2013

Good Morning Everyone, my name is Paolo Piccinelli and i'm a rookie in using Pharo. I installed the version 2.0, and I'd like to know what's the difference between a gray and white cube and a totally gray gift box near the name of the Packages. The first kind of cube, does it means that there are some classes missing in the package? Where can i find something about these visual clues?Thanks in advance for all the explanations. Best; Paolo

2 2

Pharo VM on Ubuntu PPA is ok now
by Damien Cassou Oct. 9, 2013

Oct. 9, 2013

Dear Pharo users on Ubuntu, there was a problem with the VM embedded in the ubuntu packages on the PPA (https://launchpad.net/~pharo/+archive/stable/) This bug has been solved! The bug was in the VM source code which has been fixed by upstream. Best, -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

1 0

Pharo Sprint Lille 18th October
by Marcus Denker Oct. 8, 2013

Oct. 8, 2013

What? Pharo Sprint When? Friday, 18th October, slowly starting at 9:30am Where? RMoD, Inria Lille, Building B, third floor http://rmod.lille.inria.fr/web/pier/contact As the building is not open, please contact us before if you plan to come.

1 0

Re: [Pharo-users] [ANN] Bootstrap for Seaside3 project (Release 0.1.0)
by Johan Fabry Oct. 8, 2013

Oct. 8, 2013

On Oct 8, 2013, at 1:27 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >> I just tried it and will be using it for real in a few weeks. It's really cool, thanks a lot !! > > Load the latest 0.2.0 - it now includes also support for hover.js, carousel, progress bar, ... as > well. Doing stuff on hover would be cool. But I don't see an example for hover.js. Could you include one? Thanks! ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

1 0

[ANN] Bootstrap for Seaside3 project (Release 0.1.0)
by Torsten Bergmann Oct. 7, 2013

Oct. 7, 2013

Hi, there are various frameworks out there helping you to ease common tasks in web development. One of them is Bootstrap (http://getbootstrap.com) that is used more and more to easily style web sites and web applications. We had wrappers for Bootstrap supporting Seaside in the past already: - the TwitterBootstrap project on SS3 from the Seaside team - the TBootstrap project from Gaston Dall Oglio Unfortunately these projects are not up to date with the latest Bootstrap version, not covered by tests, had no docu or examples, no CI, ... To provide better support for Bootstrap and Seaside3 development I created a fresh project called "Bootstrap for Seaside" (or "Bootstrap" for short). This new project is - nearly feature complete regarding components (Nav, Navbar, Jumbotron, Buttons, Alarms, Layouts, ...) - uses the latest Bootstrap libraries (http://getbootstrap.com) - covered by more than 160 tests - completed with an example browser that shows Bootstrap components and according Smalltalk code - available at STHub (http://smalltalkhub.com/#!/~TorstenBergmann/Bootstrap) - documented (see mentioned project website on STHub) with docu support for PharoOnlineHelp and catalog - controlled by CI (https://ci.inria.fr/pharo-contribution/job/Bootstrap/) - easily loadable using config browser in Pharo 2.0 Attached are some screenshots from the project itself. More details can be found in the more docu at the project site on SmalltalkHub. Just scroll down at the info page provided there. You can easily load it in a fresh Pharo 2.0 as "Bootstrap" from the config browser. It loads Seaside3 as a dependency. After loading evaluate ZnZincServerAdaptor startOn: 8080 to start the webserver and go to http://localhost:8080/bootstrap to browse the samples. Feel free to use it for your next Pharo/Seaside/Bootstrap based web project and thanks in advance for any contribution you may give to the project in the future. Bye T.

7 8

NYC for a group?
by Sung won Lim Oct. 6, 2013

Oct. 6, 2013

Hi, Just wondering if anyone on the list is around NYC, I think it'd be really great to have a smalltalk meeting group going in the city :) -s

8 9

Oct. 6, 2013

Hi Pharoers since we believe in quality and automation, here is a new chapter on Lint rule support in Pharo :) https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ws/Lint/Li… Stef

1 0