- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Location of Metacello package dependency

by Pharo4Stef

We were discussing about that. My point is that the system should work if the catalog fall apart. Now others told me that in other community this is the inverse. People only refer to the catalog. Since we did not get last year and this year the engineer I requested to work on the validation of distirbution we did not make progress on that front because we are busy. For me I do not use SqueakSource not because it is written Squeak but because I think that squeaksource is over and too old. Stef > I'm currently browsing the various ConfigurationOf in MetaRepoForPharo30 catalog hoping to find a pattern to serve as guidelines, but what I see is a messy variety of solutions: > > - direct reference to specific source repositories of package B as Johan suggested (and the successive baselines are effectively tracking motions of B) > IMO the worst thing, I don't manage B and don't want to update my ConfigurationOfA each time B moves. > > - references to ConfigurationOfB thru squeaksource MetacelloRepository. > My preferred solution. I don't care if the catalog is centralized on squeaksource, Smalltalkhub or whatever, but I want a centralized catalog Me too. Now the question is the following one. Ideally I would like to have one inbox and that configuration move to the catalog for their version. (Because I do not see the point of having around old versions of projects that do not load in the given version). I explained that in the Pharo vision document. Now may be other solutions are better. Stef > > - refrences thru MetaRepo catalog du jour (tracking motions of MetaRepo across baselines) > My original question, using secondary catalogs is not a problem if they are just a duplicata, but I prefer to ask, because it sounds strange to have multiple catalogs just to implement a filter (the filter being select those packages that are tested and approved in pharo x.y)... Certainly a workaround for a missing feature of Metacello. > > - a mixture of the 3 solutions above for some packages! > That appears as randomness from my POV, or like of guidance > > So again, what are the best practices currently, and could we think of it in a bit longer term? > > > 2014-03-22 21:51 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > 2014-03-22 21:27 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: > > I don't understand what squeaksource has to do with that. > With main repository, I mean the repository of the project itself. > > Almost all ConfigurationOfXXX are hosted together with the project itself. They are also referenced in that repo. The MetacelloRepo or MetaRepos are almost always secondary copies (if not, they should be) > > Johan > > > Arghh NOOOO, so that is really going to be a problem for me ! > With MetacelloRepository I absolutely don't care where to find a specific package, I have some kind of centralized catalog. > > Now, if I must track each and every motion of package B from squeaksource to ss3 to SmalltalkHub to github to (what's next ?), the idea of catalog is completely broken then... > > Nicolas > > > On 22 Mar 2014, at 21:10, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> OK, if the MetacelloRepository on squeaksource can still serve as reference, I'm perfectly OK with it, I don't know why I had this impression that anything beginning with those 6 letters was going to be seen as a problem ;) >> >> >> 2014-03-22 18:53 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: >> Why can you not reference the main repository? The meta repository is just a place where the configuration loader tool fetches them. >> >> Platform-specific elements go in the separate 'sections' of a baseline or version method. >> >> Don't make separate branches of the same ConfigurationOf class. You will not only make your life hard but also confuse all users! >> >> Maybe you can explain why you think you need those? >> >> Johan >> >> On 22 Mar 2014, at 18:20, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> I have some packages A that depend on another package B. >>> In Metacello, I can easily declare the dependency >>> spec >>> className: 'ConfigurationOfB'; >>> versionString: #'stable'; >>> repository: 'http://www.squeaksource.com/MetacelloRepository' ]. >>> But the repository is hardcoded here. >>> >>> My problem is that I'd like to edit a ConfigurationOfA valid for pharo 1.x, 2.0.x and 3.0.x (so far so good) and put a copy in MetaRepoForPharo20 and another copy in MetaRepoForPharo30. >>> >>> Since the repository is hardcoded, this is going to be a problem because the MetaRepo will then cross-ref other repositories and weaken robustness or miss uptodate ConfigurationOfB... >>> >>> I'd like to avoid maintaining many branches of ConfigurationOfA. >>> >>> How do others resolve this? >> > >

March 22, 2014

Re: [Pharo-dev] Bug in Rectangle?

by Pharo4Stef

> > You did not fix everything that was fixed in Squeak. > Example: > > rect1 := 10@10 corner: 40@40. > empty2 := 30@30 corner: 20@20. > (rect1 intersects: empty2) - > true I think that we should not use intersect: anymore because it does not make sense. > What I see is that you provided intersect:ifNone: to avoid producing empty rectangle in the first place - or to produce explicitely empty 0@0 extent: 0@0. > > But > - not all intersect: senders have been changed, Indeed we should probably continue > - some senders have been changed questionably (allowedArea in IdentifierChooserMorph is re-implementing RealEstateAgent class maximumUsableArea differently) > - I don't know if intersect: was the sole source of empty rectanglesâ¦ No around 160 layoutFrame and others > Until all producers have been eradicated, the empty invariant still exists, and Rectangle methods must still be guarded against empty rectangle edge cases. > Right now, it is not enforced everywhere (see intersects: case above). > > Right now you're in the middle of the bridge, but that's OK if the emptiness invariant eradication is still planned, it's just a temporary transition.. If I remember correctly the goal is to never have never width.

March 22, 2014

Re: [Pharo-dev] Location of Metacello package dependency

by Nicolas Cellier

I'm currently browsing the various ConfigurationOf in MetaRepoForPharo30 catalog hoping to find a pattern to serve as guidelines, but what I see is a messy variety of solutions: - direct reference to specific source repositories of package B as Johan suggested (and the successive baselines are effectively tracking motions of B) IMO the worst thing, I don't manage B and don't want to update my ConfigurationOfA each time B moves. - references to ConfigurationOfB thru squeaksource MetacelloRepository. My preferred solution. I don't care if the catalog is centralized on squeaksource, Smalltalkhub or whatever, but I want a centralized catalog - refrences thru MetaRepo catalog du jour (tracking motions of MetaRepo across baselines) My original question, using secondary catalogs is not a problem if they are just a duplicata, but I prefer to ask, because it sounds strange to have multiple catalogs just to implement a filter (the filter being select those packages that are tested and approved in pharo x.y)... Certainly a workaround for a missing feature of Metacello. - a mixture of the 3 solutions above for some packages! That appears as randomness from my POV, or like of guidance So again, what are the best practices currently, and could we think of it in a bit longer term? 2014-03-22 21:51 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > 2014-03-22 21:27 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: > > I don't understand what squeaksource has to do with that. >> With main repository, I mean the repository of the project itself. >> >> Almost all ConfigurationOfXXX are hosted together with the project >> itself. They are also referenced in that repo. The MetacelloRepo or >> MetaRepos are almost always secondary copies (if not, they should be) >> >> Johan >> >> > Arghh NOOOO, so that is really going to be a problem for me ! > With MetacelloRepository I absolutely don't care where to find a specific > package, I have some kind of centralized catalog. > > Now, if I must track each and every motion of package B from squeaksource > to ss3 to SmalltalkHub to github to (what's next ?), the idea of catalog is > completely broken then... > > Nicolas > > >> On 22 Mar 2014, at 21:10, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> OK, if the MetacelloRepository on squeaksource can still serve as >> reference, I'm perfectly OK with it, I don't know why I had this impression >> that anything beginning with those 6 letters was going to be seen as a >> problem ;) >> >> >> 2014-03-22 18:53 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: >> >>> Why can you not reference the main repository? The meta repository is >>> just a place where the configuration loader tool fetches them. >>> >>> Platform-specific elements go in the separate 'sections' of a baseline >>> or version method. >>> >>> Don't make separate branches of the same ConfigurationOf class. You will >>> not only make your life hard but also confuse all users! >>> >>> Maybe you can explain why you think you need those? >>> >>> Johan >>> >>> On 22 Mar 2014, at 18:20, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> I have some packages A that depend on another package B. >>> In Metacello, I can easily declare the dependency >>> >>> spec >>> className: 'ConfigurationOfB'; >>> versionString: #'stable'; >>> repository: 'http://www.squeaksource.com/MetacelloRepository' ]. >>> >>> But the repository is hardcoded here. >>> >>> My problem is that I'd like to edit a ConfigurationOfA valid for pharo >>> 1.x, 2.0.x and 3.0.x (so far so good) and put a copy in MetaRepoForPharo20 >>> and another copy in MetaRepoForPharo30. >>> >>> Since the repository is hardcoded, this is going to be a problem because >>> the MetaRepo will then cross-ref other repositories and weaken robustness >>> or miss uptodate ConfigurationOfB... >>> >>> I'd like to avoid maintaining many branches of ConfigurationOfA. >>> >>> How do others resolve this? >>> >>> >> >

March 22, 2014

Re: [Pharo-dev] Bug in Rectangle?

by Nicolas Cellier

2014-03-22 12:23 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2014-03-22 12:20 GMT+01:00 Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > > From the st80 ages, rectangle have allways been oriented. >> You have an origin and a corner inst var, not 2 corners or vertices. >> And you have creation messages Rectangle class>>origin:corner: >> The conventions are that of latin scribes, the orientation of rectangle >> should be (left->right , top->down) >> >> There is an assumption that a rectangle with negative width (right->left) >> or height (bottom->top) should be treated as empty. >> And this was globally well maintained except a few breakages introduced >> in Squeak along the years (but I hope I corrected most of the slips since >> then). >> >> Now Igor and Stephane had another view more geometric and un-oriented, >> and wanted to change conventions/handling of empty rectangles in Pharo. >> I don't know how far they went, or even if it is feasible at all... IMO, >> it's a recipe for maximizing breakage/gain ratio. >> >> Note that VW has Rectangle class>>vertex:vertex:, and we probably should >> add such message... >> >> >> >> Something like: > > Point>>vertex: aPoint > ^aRectangle vertex: self vertex: aPoint > > Rectangle class>>vertex: point1 vertex: point2 > ^self origin: (point1 min: point2) corner: (point1 max: point2) > > Oh, I see that this exists already, it's named (point1 rect: point2) in Squeak and (point1 rectangle: point2) in Pharo3.0, so Noury that's what you should be using. >> 2014-03-21 15:15 GMT+01:00 Noury Bouraqadi <bouraqadi(a)gmail.com>: >> >> Inverting the origin and the corner of a rectangle changes the result of >>> intersection. >>> I guess it's a bug, though I imagine that changing the code of Rectangle >>> is likely to have deep/undesired consequences.. >>> >>> (0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true >>> (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false >>> !!!! >>> >>> Noury >>> >>> >>> >>> >>> >> >

March 22, 2014

Re: [Pharo-dev] Location of Metacello package dependency

by Nicolas Cellier

2014-03-22 21:27 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: > I don't understand what squeaksource has to do with that. > With main repository, I mean the repository of the project itself. > > Almost all ConfigurationOfXXX are hosted together with the project itself. > They are also referenced in that repo. The MetacelloRepo or MetaRepos are > almost always secondary copies (if not, they should be) > > Johan > > Arghh NOOOO, so that is really going to be a problem for me ! With MetacelloRepository I absolutely don't care where to find a specific package, I have some kind of centralized catalog. Now, if I must track each and every motion of package B from squeaksource to ss3 to SmalltalkHub to github to (what's next ?), the idea of catalog is completely broken then... Nicolas > On 22 Mar 2014, at 21:10, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > OK, if the MetacelloRepository on squeaksource can still serve as > reference, I'm perfectly OK with it, I don't know why I had this impression > that anything beginning with those 6 letters was going to be seen as a > problem ;) > > > 2014-03-22 18:53 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: > >> Why can you not reference the main repository? The meta repository is >> just a place where the configuration loader tool fetches them. >> >> Platform-specific elements go in the separate 'sections' of a baseline or >> version method. >> >> Don't make separate branches of the same ConfigurationOf class. You will >> not only make your life hard but also confuse all users! >> >> Maybe you can explain why you think you need those? >> >> Johan >> >> On 22 Mar 2014, at 18:20, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> I have some packages A that depend on another package B. >> In Metacello, I can easily declare the dependency >> >> spec >> className: 'ConfigurationOfB'; >> versionString: #'stable'; >> repository: 'http://www.squeaksource.com/MetacelloRepository' ]. >> >> But the repository is hardcoded here. >> >> My problem is that I'd like to edit a ConfigurationOfA valid for pharo >> 1.x, 2.0.x and 3.0.x (so far so good) and put a copy in MetaRepoForPharo20 >> and another copy in MetaRepoForPharo30. >> >> Since the repository is hardcoded, this is going to be a problem because >> the MetaRepo will then cross-ref other repositories and weaken robustness >> or miss uptodate ConfigurationOfB... >> >> I'd like to avoid maintaining many branches of ConfigurationOfA. >> >> How do others resolve this? >> >> >

March 22, 2014

Re: [Pharo-dev] Nautilus keyboard behavior

by phil＠highoctane.be

On Thu, Mar 20, 2014 at 4:29 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On 20 Mar 2014, at 15:48, Stephan Eggermont <stephan(a)stack.nl> wrote: > > 13100 triggered me to take a look at keyboard based navigation > in Nautilus. These should probably be a number of different issues. > > There seems to be no way to get from the text pane back to > methods-categories-classes-packages , both tab and right-arrow > are captured. > > > cmd+crt+left/right arrow > > > How do I open the menu on one of the top panes in Nautilus? > > > Do you need menu when you have shortcut for menu items? > Can you give me example of application where one can open a contextual > menu whiteout the mouse > (in OSX you cannot). > > Ctrl-Fn-F2 opens the Apple menu. > How do I open the History navigator? > > > By tabbing to it and pressing arrow down? > > I'd expect groups and hierarchy to be selectable with a key combination > when the packages pane is selected. > > > They are > > > > Ben >

March 22, 2014

Re: [Pharo-dev] Bug in Rectangle?

by Nicolas Cellier

2014-03-22 16:59 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > From the st80 ages, rectangle have allways been oriented. > You have an origin and a corner inst var, not 2 corners or vertices. > And you have creation messages Rectangle class>>origin:corner: > The conventions are that of latin scribes, the orientation of rectangle > should be (left->right , top->down) > > There is an assumption that a rectangle with negative width (right->left) > or height (bottom->top) should be treated as empty. > > > > And this was globally well maintained except a few breakages introduced in > Squeak along the years (but I hope I corrected most of the slips since > then). > > Now Igor and Stephane had another view more geometric and un-oriented, and > wanted to change conventions/handling of empty rectangles in Pharo. > I don't know how far they went, or even if it is feasible at all... IMO, > it's a recipe for maximizing breakage/gain ratio. > > > It is clearly not. :) > We removed bugs in the invalid rectangle areas and others. > And we fixed all the places that were created negative dimensions (like in > framelayout) because rectangle where hijack to represent two points that > were not > a rectangle. > We also introduce margin which is really nice to represent 1,2, or 4 > digits and avoid to overuse again a rectangle. > > You did not fix everything that was fixed in Squeak. Example: rect1 := 10@10 corner: 40@40. empty2 := 30@30 corner: 20@20. (rect1 intersects: empty2) - > true What I see is that you provided intersect:ifNone: to avoid producing empty rectangle in the first place - or to produce explicitely empty 0@0 extent: 0@0. But - not all intersect: senders have been changed, - some senders have been changed questionably (allowedArea in IdentifierChooserMorph is re-implementing RealEstateAgent class maximumUsableArea differently) - I don't know if intersect: was the sole source of empty rectangles... Until all producers have been eradicated, the empty invariant still exists, and Rectangle methods must still be guarded against empty rectangle edge cases. Right now, it is not enforced everywhere (see intersects: case above). Right now you're in the middle of the bridge, but that's OK if the emptiness invariant eradication is still planned, it's just a temporary transition.. Note that VW has Rectangle class>>vertex:vertex:, and we probably should > add such message... > > > > > 2014-03-21 15:15 GMT+01:00 Noury Bouraqadi <bouraqadi(a)gmail.com>: > >> Inverting the origin and the corner of a rectangle changes the result of >> intersection. >> I guess it's a bug, though I imagine that changing the code of Rectangle >> is likely to have deep/undesired consequences.. >> >> (0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true >> (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false >> !!!! >> >> Noury >> >> >> >> >> > >

March 22, 2014

Re: [Pharo-dev] Location of Metacello package dependency

by Johan Brichau

I don't understand what squeaksource has to do with that. With main repository, I mean the repository of the project itself. Almost all ConfigurationOfXXX are hosted together with the project itself. They are also referenced in that repo. The MetacelloRepo or MetaRepos are almost always secondary copies (if not, they should be) Johan > On 22 Mar 2014, at 21:10, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > OK, if the MetacelloRepository on squeaksource can still serve as reference, I'm perfectly OK with it, I don't know why I had this impression that anything beginning with those 6 letters was going to be seen as a problem ;) > > > 2014-03-22 18:53 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: >> Why can you not reference the main repository? The meta repository is just a place where the configuration loader tool fetches them. >> >> Platform-specific elements go in the separate 'sections' of a baseline or version method. >> >> Don't make separate branches of the same ConfigurationOf class. You will not only make your life hard but also confuse all users! >> >> Maybe you can explain why you think you need those? >> >> Johan >> >>> On 22 Mar 2014, at 18:20, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> I have some packages A that depend on another package B. >>> In Metacello, I can easily declare the dependency >>> spec >>> className: 'ConfigurationOfB'; >>> versionString: #'stable'; >>> repository: 'http://www.squeaksource.com/MetacelloRepository' ]. >>> But the repository is hardcoded here. >>> >>> My problem is that I'd like to edit a ConfigurationOfA valid for pharo 1.x, 2.0.x and 3.0.x (so far so good) and put a copy in MetaRepoForPharo20 and another copy in MetaRepoForPharo30. >>> >>> Since the repository is hardcoded, this is going to be a problem because the MetaRepo will then cross-ref other repositories and weaken robustness or miss uptodate ConfigurationOfB... >>> >>> I'd like to avoid maintaining many branches of ConfigurationOfA. >>> >>> How do others resolve this? >

March 22, 2014

Re: [Pharo-dev] Location of Metacello package dependency

by Nicolas Cellier

OK, if the MetacelloRepository on squeaksource can still serve as reference, I'm perfectly OK with it, I don't know why I had this impression that anything beginning with those 6 letters was going to be seen as a problem ;) 2014-03-22 18:53 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: > Why can you not reference the main repository? The meta repository is just > a place where the configuration loader tool fetches them. > > Platform-specific elements go in the separate 'sections' of a baseline or > version method. > > Don't make separate branches of the same ConfigurationOf class. You will > not only make your life hard but also confuse all users! > > Maybe you can explain why you think you need those? > > Johan > > On 22 Mar 2014, at 18:20, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I have some packages A that depend on another package B. > In Metacello, I can easily declare the dependency > > spec > className: 'ConfigurationOfB'; > versionString: #'stable'; > repository: 'http://www.squeaksource.com/MetacelloRepository' ]. > > But the repository is hardcoded here. > > My problem is that I'd like to edit a ConfigurationOfA valid for pharo > 1.x, 2.0.x and 3.0.x (so far so good) and put a copy in MetaRepoForPharo20 > and another copy in MetaRepoForPharo30. > > Since the repository is hardcoded, this is going to be a problem because > the MetaRepo will then cross-ref other repositories and weaken robustness > or miss uptodate ConfigurationOfB... > > I'd like to avoid maintaining many branches of ConfigurationOfA. > > How do others resolve this? > >

March 22, 2014

Re: [Pharo-dev] Image's size in pillar

by Natalia Tymchuk

Thank you. Best regards, Natalia On Mar 22, 2014, at 2:35 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Wed, Mar 19, 2014 at 3:22 PM, Natalia Tymchuk > <natalia.tymchuk(a)unikernel.net> wrote: >> I have one more question. I write the subscripts like it is written: >> @@subscript@@ and in html file it works, but in pdf not. For example: it is >> written x k + 1 instead of x k + 1 . Will this be fixed on pillar >> side, or what should I do to fix it on my side? > > > this is fixed as well in latest development versions of Pillar. I will > release a new version soon. Thanks for the report. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

March 22, 2014