February 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] b6ce9b: 40507

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: b6ce9b4070449bcb3b9d5565ad8923f9fcf2e7af https://github.com/pharo-project/pharo-core/commit/b6ce9b4070449bcb3b9d5565… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-25 (Wed, 25 Feb 2015) Changed paths: M ConfigurationOfShoreLineReporter.package/ConfigurationOfShoreLineReporter.class/instance/versions/stable_.st A ConfigurationOfShoreLineReporter.package/ConfigurationOfShoreLineReporter.class/instance/versions/version012_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script507.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40507.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M ShoreLine-Report-Core.package/SlReportExtractor.class/instance/extraction/extractMetadata.st M ShoreLine-Report-Core.package/SlReportMessage.class/definition.st A ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/auto.st A ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/auto_.st M ShoreLine-Report-Core.package/SlReportMessage.class/instance/converting/metadata.st M ShoreLine-Report-Core.package/SlReporter.class/class/accessing/mimeType.st R ShoreLine-Report-Core.package/SlReporter.class/instance/actions/sendReport_.st A ShoreLine-Report-Core.package/SlReporter.class/instance/actions/serializeAndSend_.st A ShoreLine-Report-Core.package/SlReporter.class/instance/actions/serialize_.st M ShoreLine-Report-UI.package/SlReportWindow.class/instance/actions/openHelp.st M ShoreLine-Report-UI.package/SlReportWindow.class/instance/actions/submit.st Log Message: ----------- 40507 14987 ShoreLine Reporter version 0.1.2 https://pharo.fogbugz.com/f/cases/14987 http://files.pharo.org/image/40/40507.zip

Feb. 25, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40507 Home: https://github.com/pharo-project/pharo-core

Feb. 25, 2015

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

by Andrei Chis

On Wed, Feb 25, 2015 at 10:08 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2015-02-20 16:59 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> >> On Fri, Feb 20, 2015 at 4:53 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> >>> >>> >>> >>> 2015-02-08 13:01 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> >>>> Hi Nicolai, >>>> >>>> >>>> >>>> On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <nicolaihess(a)web.de> >>>> wrote: >>>> >>>>> 14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools >>>>> #development >>>>> "From this version onwards the development version should be >>>>> integrated." >>>>> >>>>> Is this a good idea? Does the #development version always include >>>>> *all* the latest >>>>> changes, because after Andrei opened >>>>> 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools >>>>> (which got integrated in 40475) >>>>> I uploaded some changes for issue >>>>> 14608 <https://pharo.fogbugz.com/default.asp?14608> >>>>> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to >>>>> Spotter methods >>>>> I set the status to "Fix Review needed", >>>>> >>>> but my changes are integrated in 40475 too! >>>>> >>>> >>>> I think that in the current situation, it is actually a good idea. And >>>> yes, the integration does include all latest versions of GT-related >>>> packages. >>>> >>>> Before changing to development, we required a stable release for the >>>> integration. That implied: >>>> 1. creating a stable release and >>>> 2. integrating it in the Pharo through a separate issue. >>>> >>>> Yet, in GT we all work on the very latest version, and creating a >>>> "stable" release is somewhat artificial given the speed at which things are >>>> changing now. Creating the "stable" version also led to delays between a >>>> fix in GT and an integration in Pharo (sometimes measured in weeks). >>>> >>> >>> It still takes weeks. the last GToolkitCore integration was 3 weeks ago. >>> >> >> That's because of two reasons: (1) we did some changes that took longer, >> and (2) by the time we were ready to commit the jenkins went off. So, this >> time it is not so representative. We do want this to happen faster. >> >> >> >>> >>>> So, in the case of GT requiring the stable release did not provide any >>>> added value, but it has the negative consequence of delays. >>>> >>>> I am not satisfied with the way external packages are handled. >>>>> 1. if there is not one slice/changeset per issue, it is even less >>>>> likely someone will >>>>> review the changes. >>>>> 2. you don't know who works when on a issue. They are solved in a bulk. >>>>> 3. a new configuration might not only includes bugfixes but new >>>>> features as well. >>>>> 4. often we have unbound globals / undeclared references or other test >>>>> failures. >>>>> >>>>> Can we use the build server for those external projects (like >>>>> GToolkitCore, Athens, TxText), >>>>> and that if a project makes a new configuration, it uses the same >>>>> issue validator for loading and testing that configuration? >>>>> >>>> >>>> We already have a GToollkitCore job, but it only runs the GT tests. >>>> Perhaps this is not enough? >>>> https://ci.inria.fr/moose/job/gtoolkitcore/ >>>> >>> >>> It would be nice if it runs some of the image validation tests >>> ReleaseTest >>> ClassTest >>> BehaviorTest >>> ... >>> >> >> It now runs the ReleaseTest. We can add the ClassTest and BehaviorTest. >> What other tests should we add? >> >> Doru >> > > Given that extensions like GTInspector and GTSpotter often extent core > classes I would run at least these tests: > > ReleaseTest > ClassTest > ClassDescriptionTest > BehaviorTest > (TraitTest - this is awfully slow) > Added all except TraitTest. Cheers, Andrei > > > >> >> >> >>> That way we can we see early enough, if GT-Extensions will break some >>> validation rules (unresovled externals / Obsolete classes / Polymorphism >>> Trait/Class) >>> >>> >>> >>>> >>>> But, could the Monkey not be able to run all tests before an >>>> integration of the development version? >>>> >>> >>> I don't know if the Monkey can load Configurations. >>> >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

Feb. 25, 2015

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

by Nicolai Hess

2015-02-20 16:59 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Fri, Feb 20, 2015 at 4:53 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> >> >> 2015-02-08 13:01 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >>> Hi Nicolai, >>> >>> >>> >>> On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>>> 14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools >>>> #development >>>> "From this version onwards the development version should be >>>> integrated." >>>> >>>> Is this a good idea? Does the #development version always include *all* >>>> the latest >>>> changes, because after Andrei opened >>>> 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools >>>> (which got integrated in 40475) >>>> I uploaded some changes for issue >>>> 14608 <https://pharo.fogbugz.com/default.asp?14608> >>>> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to >>>> Spotter methods >>>> I set the status to "Fix Review needed", >>>> >>> but my changes are integrated in 40475 too! >>>> >>> >>> I think that in the current situation, it is actually a good idea. And >>> yes, the integration does include all latest versions of GT-related >>> packages. >>> >>> Before changing to development, we required a stable release for the >>> integration. That implied: >>> 1. creating a stable release and >>> 2. integrating it in the Pharo through a separate issue. >>> >>> Yet, in GT we all work on the very latest version, and creating a >>> "stable" release is somewhat artificial given the speed at which things are >>> changing now. Creating the "stable" version also led to delays between a >>> fix in GT and an integration in Pharo (sometimes measured in weeks). >>> >> >> It still takes weeks. the last GToolkitCore integration was 3 weeks ago. >> > > That's because of two reasons: (1) we did some changes that took longer, > and (2) by the time we were ready to commit the jenkins went off. So, this > time it is not so representative. We do want this to happen faster. > > > >> >>> So, in the case of GT requiring the stable release did not provide any >>> added value, but it has the negative consequence of delays. >>> >>> I am not satisfied with the way external packages are handled. >>>> 1. if there is not one slice/changeset per issue, it is even less >>>> likely someone will >>>> review the changes. >>>> 2. you don't know who works when on a issue. They are solved in a bulk. >>>> 3. a new configuration might not only includes bugfixes but new >>>> features as well. >>>> 4. often we have unbound globals / undeclared references or other test >>>> failures. >>>> >>>> Can we use the build server for those external projects (like >>>> GToolkitCore, Athens, TxText), >>>> and that if a project makes a new configuration, it uses the same >>>> issue validator for loading and testing that configuration? >>>> >>> >>> We already have a GToollkitCore job, but it only runs the GT tests. >>> Perhaps this is not enough? >>> https://ci.inria.fr/moose/job/gtoolkitcore/ >>> >> >> It would be nice if it runs some of the image validation tests >> ReleaseTest >> ClassTest >> BehaviorTest >> ... >> > > It now runs the ReleaseTest. We can add the ClassTest and BehaviorTest. > What other tests should we add? > > Doru > Given that extensions like GTInspector and GTSpotter often extent core classes I would run at least these tests: ReleaseTest ClassTest ClassDescriptionTest BehaviorTest (TraitTest - this is awfully slow) > > > >> That way we can we see early enough, if GT-Extensions will break some >> validation rules (unresovled externals / Obsolete classes / Polymorphism >> Trait/Class) >> >> >> >>> >>> But, could the Monkey not be able to run all tests before an integration >>> of the development version? >>> >> >> I don't know if the Monkey can load Configurations. >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Feb. 25, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40506 Home: https://github.com/pharo-project/pharo-core

Feb. 25, 2015

[pharo-project/pharo-core] 0797fd: 40506

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 0797fd97e70c33eaede50bc03cf323d3a1542fbc https://github.com/pharo-project/pharo-core/commit/0797fd97e70c33eaede50bc0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-25 (Wed, 25 Feb 2015) Changed paths: M FileSystem-Core.package/FileSystemStore.class/instance/public/creationTime_.st M FileSystem-Core.package/FileSystemStore.class/instance/public/modificationTime_.st M FileSystem-Core.package/FileSystemStore.class/instance/public/size_.st A FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests/testNonExistentEntryAt.st A FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests/testNonExistentFileSize.st M Kernel.package/Metaclass.class/instance/initialize-release/instanceVariableNames_.st M Morphic-Core.package/MorphicEventDispatcher.class/instance/dispatching/dispatchEvent_with_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script506.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40506.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Slot.package/OldClassBuilderAdapter.class/instance/adapted api/class_instanceVariableNames_.st A Spec-Tools.package/KeymapBrowser.class/README.md A Spec-Tools.package/KeymapBrowser.class/class/specs/defaultSpec.st A Spec-Tools.package/KeymapBrowser.class/class/system menu/keymapBrowserMenuOn_.st A Spec-Tools.package/KeymapBrowser.class/definition.st A Spec-Tools.package/KeymapBrowser.class/instance/accessing/clearFilterButton.st A Spec-Tools.package/KeymapBrowser.class/instance/accessing/clearFilterButton_.st A Spec-Tools.package/KeymapBrowser.class/instance/accessing/filterField.st A Spec-Tools.package/KeymapBrowser.class/instance/accessing/filterField_.st A Spec-Tools.package/KeymapBrowser.class/instance/accessing/kmTable.st A Spec-Tools.package/KeymapBrowser.class/instance/accessing/kmTable_.st A Spec-Tools.package/KeymapBrowser.class/instance/initialization/initializePresenter.st A Spec-Tools.package/KeymapBrowser.class/instance/initialization/initializeWidgets.st A Spec-Tools.package/KeymapBrowser.class/instance/private/browseDefinitionOfSelectedShortcut.st A Spec-Tools.package/KeymapBrowser.class/instance/private/collectAllShortcuts.st A Spec-Tools.package/KeymapBrowser.class/instance/private/inspectActionOfSelectedShortcut.st A Spec-Tools.package/KeymapBrowser.class/instance/private/menu_shifted_.st A Spec-Tools.package/KeymapBrowser.class/instance/private/setFilter_.st A Spec-Tools.package/KeymapBrowser.class/instance/private/wrapItem_.st A Spec-Tools.package/KeymapBrowser.class/instance/protocol/initialExtent.st Log Message: ----------- 40506 14983 MorphicEventDispatcher>>#dispatchEvent:with: needs to nil morph instance https://pharo.fogbugz.com/f/cases/14983 14862 /is/this/possible? asFileReference size https://pharo.fogbugz.com/f/cases/14862 13004 Key Mapping should have a GUI interface to show all definitions https://pharo.fogbugz.com/f/cases/13004 14965 #class:instanceVariableNames: not needed in OldClassBuilderAdapter https://pharo.fogbugz.com/f/cases/14965 http://files.pharo.org/image/40/40506.zip

Feb. 25, 2015

Re: [Pharo-dev] How Far We've Come!

by Tudor Girba

Thanks Sean. And thank you everyone else around here as well :) Doru On Tue, Feb 24, 2015 at 11:06 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Thanks, Sean, for these nice words. > > I especially like all the young people covering a wide range of projects, > there is too much to track in detail. > > And, yes, we missed you ! > > > On 24 Feb 2015, at 22:28, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > It was so much fun watching the Pharo Days videos! Thanks for recording > them > > and I hope to be there next time :) > > > > Somewhere halfway through the playlist, it hit me how easily I was > > downloading all the projects and images being talked about. I was > > copy/pasting one-line Metacello scripts out of github READMEs, clicking > in > > the Configuration Browser, or downloading the latest code from CI - and > it > > all "just worked"!!! > > > > Remember not too long ago when we were passing around custom scripts to > load > > multiple dependent packages, and explaining to outsiders that "we don't > need > > github because Smalltalk invented SCM" (or whatever) while we created the > > future invisibly, hidden away from the rest of the world? > > > > After laying down so many building blocks (like FileSystem) that take the > > system out of the way of creative expression, it is exciting to finally > be > > tackling some of the high-impact things... you know the ones we've been > > avoiding... like Morphic, development tools, and the text editors. > > > > And the steady streams of new talent and funding seem likely to keep the > > successes coming. > > > > So CONGRATULATIONS, Pharo Community!!!! We deserve it. > > > > Now get back to work - we've got a future to create ;) > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/How-Far-We-ve-Come-tp4807408.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 25, 2015

Bug? JPEG reading ignores EXIF Orientation

by J.F. Rick

A lot of mobile phone cameras use the EXIF metadata of JPEG to indicate the orientation of the image (i.e., vertical vs horizontal, upside down, etc.). In Pharo 3 (I doubt it has changed in Pharo 4), that data is ignored. So, when you convert a photo taken from a mobile device to a form, it will probably be in the wrong orientation. This is true for both JPEGReadWriter and PluginBasedJPEGReadWriter. Anybody got any knowledge about this? If not, I'll add it as a bug to FogBugz. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Feb. 25, 2015

Re: [Pharo-dev] OSProcess bug ?

by David T. Lewis

On Tue, Feb 24, 2015 at 08:33:41PM +0100, jannik laval wrote: > Hi pharoers, > > I am playing with OSProcess. > I am using an example, and I am annoyed with a strange bug: > > Here is the code I want to execute, and does not work: > ==== > |thread process output| > myCmd := 'rostopic bw /turtle1/pose'. > thread := [process := (PipeableOSProcess command: myCmd) ] fork. > 3 second wait. > output := process upToEnd. > output inspect. > thread terminate. > === Hi Jannik, I am not familiar with the rostopic command, but it is common for some Unix programs to flush their output when the stdout is connected to /dev/tty (a terminal), but not necessarily if connected to a pipe or to a file. So it may be that the running rostopic program is producing output, but that the output has not yet been flushed to the pipe connected to your PipeableOSProcess. Your #upToEnd call will read the available data from the OS pipe, but it will not read data that was "written" by the rotopic program, but not yet flushed out to the OSPipe. So I am guessing that this may be why the data seems to be missing. I notice also that you are putting your PipeableOSProcess into a separate Smalltalk process using #fork. This is probably not necessary, so try getting rid of the #fork and the later thread terminate. It will not fix the problem for you, but it will simplify the code. Dave > > 'rostopic bw /turtle1/pose' is a command that is a loop displaying the > current bandwidth of a ROS process. In a terminal, it works fine. With > OSProcess the output value is empty. > > My source code is correct: if I replace myCmd by : > myCmd := 'ping localhost'. > > It is a loop too, and it returns a correct string. > > I have clearly no idea of where I have to search... Any help or discussion > about that would be great :) > > Thank you, > > Oups, some infos: > I am using Ubuntu 14.04 > Pharo3.0 with Moose 5.0, latest update: #30863 > The script I use (rostopic) is a python script (does it impact ?) > > > -- > > ~~Jannik Laval~~ > ??cole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info > http://car.mines-douai.fr/

Feb. 25, 2015

Re: [Pharo-dev] Torch repo?

by Stephan Eggermont

On 24/02/15 10:41, Yuriy Tymchuk wrote: > Hi, > > is there anywhere a repo of the Torch project by Veronica? Sure, it is still on squeaksource Stephan

Feb. 24, 2015