- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Seaside extensions and lowercase package names in Pharo

by Pharo4Stef

Chris There are several points: - we will maintain compatibility when filein/out using * - now I was not aware that the class extensions should be lower case. - Pharo should clean the packages because some of the extensions are for packages not existing anymore and other edge cases. Stef > On Fri, Jan 31, 2014 at 3:57 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Now that Pharo uses real packages beside categories I see some > lowercase "ghost" packages in Monticello Browser list after loading Seaside. > > To reproduce just load Seaside using config browser and check in > Monticello browser. > > > I guess this is coming from methods in lowercase extension > categories like "*seaside-pharo-core" which do not really > match "Seaside-Pharo-Core" package. > > Any comments? > > Using a star (*) and all-lowercase method category names has been the > convention for PackageInfo / Monticello for method extensions since > the beginning (that is, for many many years now). > > You'll undoubtedly run into this several more times - at least you will when bringing in older Monticello packages or those created outside of Pharo. Not all, but some. > > -cbc > Thx > T. > > >

Feb. 2, 2014

Re: [Pharo-dev] Comparing dates

by Paul DeBruicker

#translateTo: just shifts the timezone. So he's not adding hours to anything. Why are you adding hours to a Date in the first place? I don't understand. Does that make it the next day or the same day 2 hours past the start of the day in whatever timezone you are in, intuitively? I vote: b. Bug. #= should compare calendar (gregorian, julian etc,), year, month, day or year, day # of year sebastian(a)flowingconcept.com wrote > On Feb 1, 2014, at 12:26 PM, Sven Van Caekenberghe < > sven@ > > wrote: > >> Sebastian, >> >> In my 3.0 image >> >> | today | >> today := Date today. >> (today translateTo: 2 hours) = today. >> >> => false >> > > Yeah, here too > >> But what are you trying to accomplish ? > > Detect the most simple equality in the most conventional way. A true when > two dates refers to the same date of the calendar > > >> Dates are a bit ambiguous: my Feb 1st and your Feb 1st, in one sense they >> are the same, refer to the same date, but in another sense, yours started >> at a different point in time, right ? So are they equal ? > > Well dates are the same, thatâs the convention isnât it? Localisation and > time is what's different there. > > If you want to have time involved in the equation the logic step given our > options is that you use DateAndTime > > So, againâ¦ > > Is this a bug or a feature? > > 1. Feature: our convention is injecting time in dates so we are injecting > an incompatibility with intuition in exchange of a surprising precision* > > 2. Bug: Date #= should not compare start > > *a precision that is redundant because DateAndTime also have the > #translateTo: feature > > >> Sven >> >> On 01 Feb 2014, at 14:01, Sebastian Sastre < > sebastian@ > > wrote: >> >>> Can somebody please clarify if this is a bug or feature? >>> >>> thanks >>> >>> >>> >>> >>> On Jan 31, 2014, at 9:03 PM, Sebastian Sastre < > SEBASTIAN@ > > wrote: >>> >>>> self assert: Date today = Date today. >>>> >>>> today := Date today translateTo: 2 hours. >>>> self assert: today = Date today >>>> >>>> Is this right? >>>> >>>> >>>> >>>> >>> >>> >> >> -- View this message in context: http://forum.world.st/Comparing-dates-tp4740789p4741029.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 2, 2014

Re: [Pharo-dev] How to suck (and yet be awesome)

by Pharo4Stef

>> > > yeah, we have a strong intellectual bias. Thatâs great because we make a tool to expand our creativity and expressions of intelligence > > Kathyâs point is that we might be doing more to help others be great themselves through our product/tool/service (Pharo in this case) > > You do that all the time with your students > > They, as everybody, have many options to be heroâs (like solving things with Phyton/Ruby, etc) so our challenge is to have a smooth learning curve with fast positive feedback > > Clean APIâs helps a lot on that because itâs like the UI of the code > > Great tutorials on how to do popular arctifacts (todo lists, blogs, CRUD apps) is something that comes to mind for making a bridge between theory and practical positive results > > At least that worked incredibly well for Rails and other frameworks I like her point of view. I will change what I will wrote in my book and it is related to the discussion with the pool dictionary. stef

Feb. 2, 2014

Re: [Pharo-dev] Comparing dates

by Paul DeBruicker

Why are you adding hours to a Date in the first place? I don't understand. Does that make it the next day or the same day 2 hours past the start of the day in whatever timezone you are in, intuitively? I vote: b. Bug. #= should compare calendar (gregorian, julian etc,), year, month, day or year, day # of year On Feb 1, 2014, at 12:26 PM, Sven Van Caekenberghe <sven@> wrote: > Sebastian, > > In my 3.0 image > > | today | > today := Date today. > (today translateTo: 2 hours) = today. > > => false > Yeah, here too > But what are you trying to accomplish ? Detect the most simple equality in the most conventional way. A true when two dates refers to the same date of the calendar > Dates are a bit ambiguous: my Feb 1st and your Feb 1st, in one sense they > are the same, refer to the same date, but in another sense, yours started > at a different point in time, right ? So are they equal ? Well dates are the same, thatâs the convention isnât it? Localisation and time is what's different there. If you want to have time involved in the equation the logic step given our options is that you use DateAndTime So, againâ¦ Is this a bug or a feature? 1. Feature: our convention is injecting time in dates so we are injecting an incompatibility with intuition in exchange of a surprising precision* 2. Bug: Date #= should not compare start *a precision that is redundant because DateAndTime also have the #translateTo: feature > Sven > > On 01 Feb 2014, at 14:01, Sebastian Sastre <sebastian@> wrote: > >> Can somebody please clarify if this is a bug or feature? >> >> thanks >> >> >> >> >> On Jan 31, 2014, at 9:03 PM, Sebastian Sastre <SEBASTIAN@> wrote: >> >>> self assert: Date today = Date today. >>> >>> today := Date today translateTo: 2 hours. >>> self assert: today = Date today >>> >>> Is this right? >>> >>> >>> >>> >> >> > > -- View this message in context: http://forum.world.st/Comparing-dates-tp4740789p4741022.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 2, 2014

Re: [Pharo-dev] test failures in downloaded image 30733

by btc＠openinworld.com

Feb. 2, 2014

test failures in downloaded image 30733 - OpenToolTest>>#testOpenBrowseOnInstalledTraitMethod

by btc＠openinworld.com

btc(a)openinworld.com wrote: > For diligence and curiosity leading up to the Pharo3 release, I > downloaded build image 30733 (with PharoLauncher) and immediately ran > all tests, which reported 7 failures and 1 error (see attached > snapshot). Error "KeyNotFound: key #localSelectors not found in MethodDictionary" occurrs in .... OpenToolTest>>#testOpenBrowseOnInstalledTraitMethod | browser | browser := (Class>>#localSelectors) browse. browser changed. browser close. Using PharoLauncher to manually bisect between builds by inspecting "Class>>#localSelectors" in Workspace * works for http://files.pharo.org/image/30/30520.zip * errors for http://files.pharo.org/image/30/30521.zip ----------- From Build 30521 Log Message: 11995 MenuMorph>>addList: sends #iconNamed: to an instance of Pharo3Theme, which raises a warning of deprecation. https://pharo.fogbugz.com/f/cases/11995 #localSelectors add to Trait so cleanup is possible in a second step ----------- Logged as https://pharo.fogbugz.com/f/cases/12771 I don't how to proceed with this. cheers -ben

Feb. 2, 2014

Re: [Pharo-dev] test failures in downloaded image 30733

by Marcus Denker

On 02 Feb 2014, at 14:31, btc(a)openinworld.com wrote: > For diligence and curiosity leading up to the Pharo3 release, I downloaded build image 30733 (with PharoLauncher) Getting an image green is a lot of little, trivial, hard workâ¦ and green always means âGreen in this contextâ. Just headless vs. non-headless changes a lot, for example. Another wonderful thing is that tests are fine when run individually, but fail when running all tests. We need to think about automatic UI testingâ¦ Loading an external package changes *everything*. We do not have a a release criterium that all tests are green after loading external packages. > and immediately ran all tests, which reported 7 failures and 1 error (see attached snapshot). Now presumably these did not occur in the CI build since otherwise it would not have been available to PharoLauncher, so this raises a few questions/ideas: > > 1. Why the discrepancy / how did these slip through ? Perhaps some difference in local environment / difference in VM? Can anyone else reproduce this for 30733? I've logged an new case [1] for this where I plan to either link to existing cases or add a subcase for each failure. Please add your results there, particularly if you see a known issue. > > Here are my failures... > BlockClosureTest>>#testTrace Not failing for me > JobTest>>#testCurrent Not failing for me > MetacelloRepositorySqueakCommonTestCase>>#testAsRepositorySpecFor > MetacelloRepositorySqueakCommonTestCase>>#testDirectoryRepository > MetacelloRepositorySqueakCommonTestCase>>#testFileTreeRepository Not failing fo rme > ReleaseTest>>#testObsoleteClasses Not failing for me > SimmulateMouseSpecification>>#testSimulateRightClick yes, that is failing > and errors... > OpenToolTest>>#testOpenBrowseOnInstalledTraitMethod > yes. The last two are examples of UI tests that are not run on the Build server in a way that they could fail. > 3. Assuming Pharo3 will go through a Release Candidate phase, Normally the idea is that we will just release. In the past we used an elaborate process, but the reality is that nobody looks at release candidates. You can tell 5 times that the release candidate will be released unchanged and people should check: they will not. They will download the release, though, and then complain that the âobviousâ thing X is not fixed that that the people who managed the release process did everything wrong. Because âreleaseâ means bug free. By magic. Marcus

Feb. 2, 2014

Re: [Pharo-dev] Comparing dates

by Sebastian Sastre

On Feb 1, 2014, at 12:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Sebastian, > > In my 3.0 image > > | today | > today := Date today. > (today translateTo: 2 hours) = today. > > => false > Yeah, here too > But what are you trying to accomplish ? Detect the most simple equality in the most conventional way. A true when two dates refers to the same date of the calendar > Dates are a bit ambiguous: my Feb 1st and your Feb 1st, in one sense they are the same, refer to the same date, but in another sense, yours started at a different point in time, right ? So are they equal ? Well dates are the same, thatâs the convention isnât it? Localisation and time is what's different there. If you want to have time involved in the equation the logic step given our options is that you use DateAndTime So, againâ¦ Is this a bug or a feature? 1. Feature: our convention is injecting time in dates so we are injecting an incompatibility with intuition in exchange of a surprising precision* 2. Bug: Date #= should not compare start *a precision that is redundant because DateAndTime also have the #translateTo: feature > Sven > > On 01 Feb 2014, at 14:01, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Can somebody please clarify if this is a bug or feature? >> >> thanks >> >> >> >> >> On Jan 31, 2014, at 9:03 PM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: >> >>> self assert: Date today = Date today. >>> >>> today := Date today translateTo: 2 hours. >>> self assert: today = Date today >>> >>> Is this right? >>> >>> >>> >>> >> >> > >

Feb. 2, 2014

test failures in downloaded image 30733

by btc＠openinworld.com

For diligence and curiosity leading up to the Pharo3 release, I downloaded build image 30733 (with PharoLauncher) and immediately ran all tests, which reported 7 failures and 1 error (see attached snapshot). Now presumably these did not occur in the CI build since otherwise it would not have been available to PharoLauncher, so this raises a few questions/ideas: 1. Why the discrepancy / how did these slip through ? Perhaps some difference in local environment / difference in VM? Can anyone else reproduce this for 30733? I've logged an new case [1] for this where I plan to either link to existing cases or add a subcase for each failure. Please add your results there, particularly if you see a known issue. Here are my failures... BlockClosureTest>>#testTrace JobTest>>#testCurrent MetacelloRepositorySqueakCommonTestCase>>#testAsRepositorySpecFor MetacelloRepositorySqueakCommonTestCase>>#testDirectoryRepository MetacelloRepositorySqueakCommonTestCase>>#testFileTreeRepository ReleaseTest>>#testObsoleteClasses SimmulateMouseSpecification>>#testSimulateRightClick and errors... OpenToolTest>>#testOpenBrowseOnInstalledTraitMethod 2. How is the PharoLauncher VM synced with that used to test the Pharo CI builds ? (My VM comes from the PharoLauncher Windows Installer) 3. Assuming Pharo3 will go through a Release Candidate phase, apart from functionality testing which anyone may-or-not have time for, as many spectators as possible should download those Release Candidate images an just run All Tests. 4. It might be good for a small number of releases between now and Release Candidate to be designated for the community to similarly run All Tests - to reduce surprises at Release Candidate time? 5. I've seen times before when some failures as transitory/random (which had to do with unordered Sets being used by a test that presumed order). So at times when there are a lot of Pharoers together, such as at a Sprint, maybe the convention could be for everyone to run All Tests at the start of the day to provide broad comparison (and know you're starting with a clean slate) cheers -ben [1] https://pharo.fogbugz.com/f/cases/12770/

Feb. 2, 2014

Re: [Pharo-dev] ZTimestamp>>monthName spelling error

by Sven Van Caekenberghe

On 02 Feb 2014, at 10:44, Norbert Hartl <norbert(a)hartl.name> wrote: >> Now that example should work: >> >> (ZTimestampFormat fromString: 'Saturday, 3 February, 2001') >> german; >> format: Date today. >> >> => 'Samstag, 1 Februar, 2014â > > Does ZTimestampFormat handle the formatting of the date? If so then for germany it would be > > Samstag, 1. Februar 2014 ZTimestampFormat works 'by example', substituting known keys for actual values, possibly translated. It cannot reorder the specification. So it does not properly handle locale. But you could work around this limitation a bit by adjusting the format to the locale. In the above example: (ZTimestampFormat fromString: 'Saturday, 3. February 2001') german; format: Date today. should do the trick. Sven

Feb. 2, 2014