March 2014 - Pharo-dev - lists.pharo.org

Location of Metacello package dependency

by Nicolas Cellier

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] Random refactoring on UITheme or what?

by Ben Coman

Hilaire Fernandes wrote: > Sure. > Oh, by the way I realize the Polymoprh examples where scalped in Pharo3 > because of the protocol change of ListModel. This is really *not* nice. > Fixing that as well. > > Hilaire > Thanks Hilaire. > Le 22/03/2014 17:10, phil(a)highoctane.be a Ã©crit : > >> Pharo3Theme is a renamed glamourTheme under Watery with some leftovers. >> >> Maybe a PharoTheme just under UITheme would be cleaner. >> >>

March 22, 2014

Re: [Pharo-dev] Random refactoring on UITheme or what?

by Hilaire Fernandes

Sure. Oh, by the way I realize the Polymoprh examples where scalped in Pharo3 because of the protocol change of ListModel. This is really *not* nice. Fixing that as well. Hilaire Le 22/03/2014 17:10, phil(a)highoctane.be a Ã©crit : > Pharo3Theme is a renamed glamourTheme under Watery with some leftovers. > > Maybe a PharoTheme just under UITheme would be cleaner. > -- Dr. Geo http://drgeo.eu

March 22, 2014

Re: [Pharo-dev] Random refactoring on UITheme or what?

by phil＠highoctane.be

Pharo3Theme is a renamed glamourTheme under Watery with some leftovers. Maybe a PharoTheme just under UITheme would be cleaner. Phil Le 22 mars 2014 16:49, "Hilaire Fernandes" <hilaire.fernandes(a)gmail.com> a Ã©crit : > I don't think so. These are orthogonal. > > I will propose a simple hierarchy for the theme: > > UITheme > +-UIPharoTheme > +-UIVistaryTheme > +-UIWateryTheme > > I will propose to delete all the other themes as they should belong to > other package. > > Hilaire > > Le 22/03/2014 15:27, Nicolas Cellier a Ã©crit : > > Personnally, I find a huge progress in usability of 3.0 tools versus 2.0 > > which was really awfull. If it must be at the price of broken themes (we > > can hope temporarily), I buy it. > > -- > Dr. Geo http://drgeo.eu > > >

March 22, 2014

Re: [Pharo-dev] Bug in Rectangle?

by Pharo4Stef

> 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. > 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] Random refactoring on UITheme or what?

by Hilaire Fernandes

I don't think so. These are orthogonal. I will propose a simple hierarchy for the theme: UITheme +-UIPharoTheme +-UIVistaryTheme +-UIWateryTheme I will propose to delete all the other themes as they should belong to other package. Hilaire Le 22/03/2014 15:27, Nicolas Cellier a Ã©crit : > Personnally, I find a huge progress in usability of 3.0 tools versus 2.0 > which was really awfull. If it must be at the price of broken themes (we > can hope temporarily), I buy it. -- Dr. Geo http://drgeo.eu

March 22, 2014

Re: [Pharo-dev] Windows FileSystem '\test\bar' not an absolute path

by Ben Coman

btc(a)openinworld.com wrote: > Ben Coman wrote: >> >> I have some strong concerns about the semantics of FileSystem on MS >> Windows treating '\directory' as a relative path rather than an >> absolute path. >> >> For example currently... >> '/tmp/test.txt' asFileReference fullName --> >> 'C:\Users\Ben\AppData\Roaming\Pharo\images\30790\tmp\test.txt' >> >> when it _should_ go... >> '/tmp/test.txt' asFileReference fullName --> 'C:\tmp\x.txt' >> >> This seems to be by design per '\test\bar' below... >> >> WindowsStoreTest>>testAbsolutePath >> #('c:\' 'C:\temp' 'A:\temp\test') do: [:each | >> self assert: (WindowsStore current pathFromString: each) >> isAbsolute ] >> WindowsStoreTest>>testRelativePath >> #('a' 'bin\foo' 'temp\test' '\test\bar') do: [:each | >> self assert: (WindowsStore current pathFromString: each) >> isRelative ] >> >> However taking as reference the Windows Command Shell (cmd.exe)... >> (1) C:\> mkdir \a\b\a\c >> (2) C:\> cd a >> (3) C:\a> cd b >> (4) C:\a\b> cd \a >> (5) C:\a> >> >> observe that after 'cd \a' (4) the working directory becomes absolute >> 'C:\a' rather than relative 'C:\a\b\a' . >> >> Microsoft defines [1] a file name is RELATIVE to the current >> directory if it DOES NOT begin with: >> * A single backslash, for example, "\directory" or "\file.txt". This >> is also referred to as an ABSOLUTE path. >> >> Indeed all Windows applications I know operate this way. Using >> different semantics is a bug. >> >> [1] >> http://msdn.microsoft.com/en-us/library/aa365247.aspx#fully_qualified_vs._r… >> >> >> What are your thoughts? >> cheers -ben >> >> > I propose something like the following changes... > > WindowsStoreTest>>testAbsolutePath > #('c:\' 'C:\temp' 'A:\temp\test' '\test\bar') do: [:each | > "<--MODIFIED" > self assert: (WindowsStore current pathFromString: each) > isAbsolute ] > WindowsStoreTest>>testRelativePath > #('a' 'bin\foo' 'temp\test' 'C:temp\test' ) do: [:each | > "<--MODIFIED" > self assert: (WindowsStore current pathFromString: each) > isRelative ] > > Path>>absoluteWindowsPathRegex > ^ (absoluteWindowsPathRegex ifNil: [ > absoluteWindowsPathRegex := '([a-zA-Z]\:)?\\.*' asRegex ]) > copy "<--MODIFIED" " absoluteWindowsPathRegex := > '[a-zA-Z]\:\\.*' asRegex ]) copy" "<--PREVIOUS" > Path>>first "<--ADDED" > ^ self at: 1. > WindowsStore>>printPath: aPath on: aStream > (aPath first includes: $:) ifFalse: [ aStream nextPutAll: self > currentDisk ; nextPut: self delimiter ]. "<--ADDED" > aPath printOn: aStream delimiter: self delimiter > WindowsStore>>currentDisk "<--ADDED" > "Assumes workingDirectory is always an absolute path" > ^ disk ifNil: [ disk = FileSystem workingDirectory path first ] > > after which... > '/tmp/test.txt' asFileReference fullName > --> 'C:\tmp\test.txt' > > This needs some polish. I haven't looked for adverse effects yet. > However Pathtest, FileReferenceTest, FileSystemTest & WindowsStoreTest > are all green. > > What do your think? > cheers -ben > > This is an important issue for Windows users. The fix has had a few iterations and is ready for wider testing [1]. Assistance to test and advise if the result is reasonable would be appreciated. [1] https://pharo.fogbugz.com/f/cases/13065/Windows-FileSystem-test-bar-not-an-… cheers -ben

March 22, 2014

Re: [Pharo-dev] Bug in Rectangle?

by Pharo4Stef

https://pharo.fogbugz.com/default.asp?13116 > Point>>vertex: aPoint > ^aRectangle vertex: self vertex: aPoint > > Rectangle class>>vertex: point1 vertex: point2 > ^self origin: (point1 min: point2) corner: (point1 max: point2)

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. >> >> Finally, it seems that the conventions about emptyness were preserved in Pharo so far, as you can notice in Rectangle comment. Though, the Squeak changes ensuring this invariant still do not have been integrated: https://code.google.com/p/pharo/issues/detail?id=2601 https://pharo.fogbugz.com/f/cases/2649/don-t-let-an-empty-Rectangle-interse… (A change of bug number is not the best thing here, it make things harder to follow... like my remarks in https://pharo.fogbugz.com/f/cases/7108/Rectangle-intersects-and-if-none) 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) > > >> >> 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] Random refactoring on UITheme or what?

by Nicolas Cellier

Personnally, I find a huge progress in usability of 3.0 tools versus 2.0 which was really awfull. If it must be at the price of broken themes (we can hope temporarily), I buy it. 2014-03-22 15:14 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > > > Speaking of that, one will notice that the class comment of UITheme has > the examples list: > > > > Common superclass for User Interface themes. Provides methods for > creating new morphs in a standard way, various "services" like a file > dialog, message dialogs etc. and also methods for customising aspects of > the appearance of various morphs. > > Though conceptually abstract, no code is "missing". Subclasses, > therefore, should override the aspects they wish to change. > > > > UITheme exampleBasicControls > > UITheme exampleBuilder > > UITheme exampleColorControls > > UITheme exampleDialogs > > UITheme exampleGroups > > UITheme exampleOtherControls > > UITheme exampleWindowWithToolbars > > > > But in 3.0 it is not in there, it moved to Widgets in > 'Morphic-Examples-Widgets' > > indeed! > > > with: > > > > ExampleBuilderMorph > > WidgetExamples > > > > Maybe worth a change in the class comment. > > Yes! > I think that many changes missed a deprecation or information to help > people migrating. >

March 22, 2014