October 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Monticello and HTTPS

by StÃ©phane Ducasse

On Oct 11, 2013, at 5:52 PM, Manfred KrÃ¶hnert <mkroehnert42(a)googlemail.com> wrote: > Thanks StÃ©phane, > > we appreciate that :-) I'm sincere :). I believe that we have an excellent stack for doing web dev Zinc/Zodiac/Oauth/.â¦ Voyage/Magritte/ Seaside/ Reef/Amber I would love to have more companies working in Pharo because we will all benefit from it. When I see the impact of BetaNine or Pinesoft on Pharo. Stef > Best, > Manfred > > > > > On Thu, Oct 10, 2013 at 8:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > welcome > > we like amber :) > > Stef > > On Oct 10, 2013, at 3:41 PM, Manfred KrÃ¶hnert <mkroehnert42(a)googlemail.com> wrote: > > > Hi everyone, > > > > I am one of the guys helping Nico with Amber. > > > > Now, I recently started to experiment with Pharo for a small project. > > After some reading and experimenting I was able to get something running thanks to the good documentation available. > > > > While I was on the go I tried to save my code with Monticello on a private WebDAV share. > > However, the server is only accessible via HTTPS which resulted in an error accessing it from the Monticello browser. > > > > Now my question is if HTTPS is supported by Montichello or not. > > Since the server is accessed with username/password I'd rather not use plain HTTP. > > > > Best, > > Manfred > > >

Oct. 11, 2013

Re: [Pharo-users] Spec Lists - setting the selection

by StÃ©phane Ducasse

On Oct 11, 2013, at 2:47 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Thanks for the example :) > > Indeed, the documentation is a bit outdated since Spec is still improving a lot, > a changing a bit in its API. > > One of my goal now is to write proper doc for Spec :) youpi! > > Ben > > On Oct 11, 2013, at 8:23 AM, 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 ). > > this could be changed in: > > list := self newList. > >> >> 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 >> >> >

Oct. 11, 2013

Re: [Pharo-users] Simple Spec Examples

by Johan Fabry

I agree with Camillo in that I think it would be better to use specific selectors, e.g. selectedItem:withParents: as it better reveals the intention. Just my 2 cents ... On Oct 11, 2013, at 3:23 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > 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> > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Oct. 11, 2013

Re: [Pharo-users] Simple Spec Examples

by Camillo Bruni

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>

Oct. 11, 2013

Re: [Pharo-users] Simple Spec Examples

by btc＠openinworld.com

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

Oct. 11, 2013

Re: [Pharo-users] Simple Spec Examples

by btc＠openinworld.com

Oct. 11, 2013

Re: [Pharo-users] Simple Spec Examples

by btc＠openinworld.com

Oct. 11, 2013

Re: [Pharo-users] Monticello and HTTPS

by Manfred KrÃ¶hnert

Hi Sven, thanks for the pointers. I'll have a look over the weekend and report back. Best, Manfred On Thu, Oct 10, 2013 at 9:08 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Manfred, > > On 10 Oct 2013, at 20:17, Manfred KrÃ¶hnert <mkroehnert42(a)googlemail.com> > wrote: > > > Hi again, > > > > the webdav share is located on an OwnCloud instance. > > It is possible to get a directory listing of the specific directory with > the following ZnClient request: > > > > ZnClient new username: 'X' password: 'Y'; get: ' > https://owncloud.server.de/remote.php/webdav/monticello' > > Excellent, that means that it fundamentally works ! > > Maybe you can try the same for accessing an actual .mcz file, just to be > sure. > > > In a Pharo 2.0 image do the following steps: > > > > * MonticelloBrowser: select package > > * MonticelloBrowser->'+Repository' > > * add location: 'https://owncloud.server.de/remote.php/webdav/monticello' > username: 'X' password: 'Y' > > * MonticelloBrowser->'Open' > > > > * ProgressBar with the following name shows up: > > 'Loading all file names from > https://owncloud.server.de/remote.php/webdav/monticello' > > It gets interrupted by a PreDebugWindow with title > > 'MCRepositoryError: Could not access > https://owncloud.server.de/remote.php/webdav/monticello: > ZnHttpUnsuccessful: 404 Not Found' > > > > Opening the Debugger gives the following stacktrace > > > > MCHttpRepository>>loadAllFileNames in Block: [:exception | (exception > className beginsWith: 'Zn...etc... > > BlockClosure>>cull: > > MethodContext(ContextPart)>>handleSignal: in Block: [self > exceptionHandlerBlock cull: exception] > > BlockClosure>>ensure: > > MethodContext(ContextPart)>>handleSignal: > > MethodContext(ContextPart)>>handleSignal: > > ZnHttpUnsuccessful(Exception)>>signal > > ZnClient>>handleResponse > > ZnClient>>executeWithRedirectsRemaining: > > ZnClient>>executeWithRetriesRemaining: in Block: [self > executeWithRedirectsRemaining: self maxNumbe...etc... > > BlockClosure>>on:do: > > ZnClient>>executeWithRetriesRemaining: > > ZnClient>>executeWithTimeout in Block: [self > executeWithRetriesRemaining: self numberOfRe...etc... > > BlockClosure>>on:do: > > ZnClient>>executeWithTimeout in Block: [[self > executeWithRetriesRemaining: self numberOfR...etc... > > ZnClient>>withTimeoutDo: in Block: [^ block value] > > ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [p > psValueAt: index put: anObject.... > > BlockClosure>>ensure: > > ZnConnectionTimeout(DynamicVariable)>>value:during: > > ZnConnectionTimeout class(DynamicVariable class)>>value:during: > > ZnClient>>withTimeoutDo: > > ZnClient>>executeWithTimeout > > ZnClient>>execute in Block: [result := self executeWithTimeout] > > ZnClient>>withProgressDo: in Block: [^ block value] > > ZnSignalProgress(DynamicVariable)>>value:during: in Block: [p psValueAt: > index put: anObject.... > > BlockClosure>>ensure: > > ZnSignalProgress(DynamicVariable)>>value:during: > > ZnSignalProgress class(DynamicVariable class)>>value:during: > > ZnClient>>withProgressDo: > > ZnClient>>execute > > Have a look at MCHTTPRepository>>#loadAllFileNames and notice how a query > parameter is added, maybe that is the culprit ? Also, a trailing slash is > added, that could be a problem for the server as well. > > Else, you will have to look at the stack trace in the debugger and try to > understand what is going on. > > Sven > > > Trying to copy .mcz files to the new repository afterwards triggers the > same error. > > However, the selected .mcz file gets copied to the WebDAV share. > > > > The used operating system is OS X 10.6.8. > > The 'System Reporter' shows the following info: > > > > Image: > > Pharo2.0 > > Latest update: #20616 > > > > VM: > > Mac Cocoa Cog 5.8b12 21-Sep-10 > > Jenkins build #14535 > > > > Thanks, > > Manfred > > > > > > > > > > On Thu, Oct 10, 2013 at 4:00 PM, Manfred KrÃ¶hnert < > mkroehnert42(a)googlemail.com> wrote: > > Hello Sven, > > > > > > On Thu, Oct 10, 2013 at 3:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Hi Manfred, > > > > On 10 Oct 2013, at 15:41, Manfred KrÃ¶hnert <mkroehnert42(a)googlemail.com> > wrote: > > > > > Hi everyone, > > > > > > I am one of the guys helping Nico with Amber. > > > > > > Now, I recently started to experiment with Pharo for a small project. > > > After some reading and experimenting I was able to get something > running thanks to the good documentation available. > > > > > > While I was on the go I tried to save my code with Monticello on a > private WebDAV share. > > > However, the server is only accessible via HTTPS which resulted in an > error accessing it from the Monticello browser. > > > > > > Now my question is if HTTPS is supported by Montichello or not. > > > Since the server is accessed with username/password I'd rather not use > plain HTTP. > > > > > > Best, > > > Manfred > > > > It should work. But I am not aware of any official, public repositories > that run HTTPS, so its hard to test. I also understand that it could be > difficult to give stack traces, but details are necessary to make any > progress on helping you. > > > > One thing you could try is to access the repository directly: i.e. > create a ZnClient that tries to read the listing or a specific package. > > > > Sven > > > > thanks for the initial info that it should work. > > > > I would have given further details but currently I can't access the > machine where I tried it. > > I'll try your suggestion and provide a more detailed report as soon as > possible. > > > > Best, > > Manfred > > > > > > >

Oct. 11, 2013

Re: [Pharo-users] Monticello and HTTPS

by Manfred KrÃ¶hnert

Thanks StÃ©phane, we appreciate that :-) Best, Manfred On Thu, Oct 10, 2013 at 8:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > welcome > > we like amber :) > > Stef > > On Oct 10, 2013, at 3:41 PM, Manfred KrÃ¶hnert <mkroehnert42(a)googlemail.com> > wrote: > > > Hi everyone, > > > > I am one of the guys helping Nico with Amber. > > > > Now, I recently started to experiment with Pharo for a small project. > > After some reading and experimenting I was able to get something running > thanks to the good documentation available. > > > > While I was on the go I tried to save my code with Monticello on a > private WebDAV share. > > However, the server is only accessible via HTTPS which resulted in an > error accessing it from the Monticello browser. > > > > Now my question is if HTTPS is supported by Montichello or not. > > Since the server is accessed with username/password I'd rather not use > plain HTTP. > > > > Best, > > Manfred > > >

Oct. 11, 2013

Re: [Pharo-users] Simple Spec Examples (was: Spec Lists - setting the selection)

by Benjamin

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 :) Then your example make me think that using association to describe the path may lead to an ambiguous situation Ben [1] https://pharo.fogbugz.com/default.asp?11849 [2] https://pharo.fogbugz.com/default.asp?11850 > > > > <Spec-TreeModel-simple-example.png>

Oct. 11, 2013