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

Re: [Pharo-dev] [regression reporter]regression occurred

by Ben Coman

On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: > Number>>#brickValue: must die ! > > > On 25 Feb 2015, at 15:53, no-reply(a)ci.inria.fr wrote: > > > > > https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/labe… > > > > 1 regressions found. > > > KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses > > > On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 25 Feb 2015, at 16:04, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > It is already fixed and will be integrated with GT > > When will this happen? this test fails since *WEEKS*, yet I could have > fixed it in 5 minutes. But I canât. > We make ourselves completely powerless. This does not make me feel good. > On Wed, Feb 25, 2015 at 11:11 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > > Normally GT should be released more often. This time while Jenkins was > down we did a lot of changes and now it takes some time to prepare > everything for integration. Also at the moment of previous release moose > didn't run tests like BehaviourTest and others. :) > > > Thats a fair reason, but philosophically we still have a feature branch holding up a bug fix, because we have a a single-branch workflow. Consider a future where Pharo has more external packages, where a hypothetical package (with less diligent developers than GT) has a longer feature development cycle. Should bug fixes be held up? Or should external packages have a bug-fix-branch and a feature-development-branch - with a workflow where before the feature-development-branch is integrated, it merges in any bug-fix-branch commits. p.s. It would be interesting if we could get a github-style commit network graph derived from mcz files. cheers -ben

Feb. 26, 2015

Re: [Pharo-dev] [pharo-project/pharo-core]

by Alexandre Bergel

Just wondering: is there any meaning to these emails from github? Cheers, Alexandre > On Feb 26, 2015, at 11:29 AM, GitHub <noreply(a)github.com> wrote: > > Branch: refs/tags/40513 > Home: https://github.com/pharo-project/pharo-core -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 26, 2015

[pharo-project/pharo-core] 446c22: 40513

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 446c22b4124aefd20398ecb846326defe09313f1 https://github.com/pharo-project/pharo-core/commit/446c22b4124aefd20398ecb8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-26 (Thu, 26 Feb 2015) Changed paths: M ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/accessing/stable_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/baselines/baseline25_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/baselines/baseline26_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/versions/version256_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/versions/version261_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/versions/version262_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script512.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script513.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40512.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40513.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/README.md A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/class/instance creation/on_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/definition.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/accessing/linesDo_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/accessing/nextLine.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/beWide.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/bufferStream_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/close.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/initialize.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/on_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/private/streamContents_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/testing/atEnd.st A Zinc-Character-Encoding-Tests.package/ZnFastLineReaderTests.class/README.md A Zinc-Character-Encoding-Tests.package/ZnFastLineReaderTests.class/definition.st A Zinc-Character-Encoding-Tests.package/ZnFastLineReaderTests.class/instance/testing/testLinesDo.st A Zinc-Character-Encoding-Tests.package/ZnFastLineReaderTests.class/instance/testing/testNextLine.st M Zinc-HTTP.package/ZnClient.class/instance/cleanup/close.st A Zinc-HTTP.package/ZnClient.class/instance/options/certificate.st A Zinc-HTTP.package/ZnClient.class/instance/options/certificate_.st M Zinc-HTTP.package/ZnClient.class/instance/private logging/logConnectionEstablishedTo_started_.st M Zinc-HTTP.package/ZnClient.class/instance/private/newConnectionTo_.st A Zinc-HTTP.package/ZnClient.class/instance/testing/isBadRequest.st M Zinc-HTTP.package/ZnClientLogEvent.class/instance/printing/printContentsOn_.st M Zinc-HTTP.package/ZnDefaultServerDelegate.class/instance/initialization/initialize.st M Zinc-HTTP.package/ZnDefaultServerDelegate.class/instance/responses/formTest1_.st A Zinc-HTTP.package/ZnDefaultServerDelegate.class/instance/responses/formTest2_.st A Zinc-HTTP.package/ZnDefaultServerDelegate.class/instance/responses/formTest3_.st M Zinc-HTTP.package/ZnDigestAuthenticator.class/class/accessing/md5Hash_.st M Zinc-HTTP.package/ZnEntity.class/class/instance creation/readBinaryFrom_usingType_andLength_.st A Zinc-HTTP.package/ZnEntity.class/instance/initialize-release/readBinaryFrom_.st A Zinc-HTTP.package/ZnEntityReader.class/instance/private/withDefaultUtf8Decoding_.st M Zinc-HTTP.package/ZnEntityReader.class/instance/public/readEntity.st A Zinc-HTTP.package/ZnEntityWriter.class/instance/private/withDefaultUtf8Encoding_.st M Zinc-HTTP.package/ZnEntityWriter.class/instance/public/writeEntity_.st M Zinc-HTTP.package/ZnLogEvent.class/class/convenience/logToTranscript.st M Zinc-HTTP.package/ZnMimePart.class/class/instance creation/fieldName_fileName_entity_.st A Zinc-HTTP.package/ZnMimePart.class/class/instance creation/readBinaryFrom_.st M Zinc-HTTP.package/ZnMimePart.class/instance/accessing/fileName.st A Zinc-HTTP.package/ZnMimePart.class/instance/initialize-release/readBinaryFrom_.st R Zinc-HTTP.package/ZnMultiPartFormDataEntity.class/instance/initialization/initialize.st A Zinc-HTTP.package/ZnMultiPartFormDataEntity.class/instance/initialize-release/initialize.st A Zinc-HTTP.package/ZnMultiPartFormDataEntity.class/instance/initialize-release/readBinaryFrom_.st M Zinc-HTTP.package/ZnMultiPartFormDataEntity.class/instance/initialize-release/readFrom_.st R Zinc-HTTP.package/ZnMultiPartFormDataEntity.class/instance/private/parse_boundary_.st A Zinc-HTTP.package/ZnMultiPartFormDataEntity.class/instance/private/parse_boundary_binary_.st M Zinc-HTTP.package/ZnNetworkingUtils.class/instance/public/socketStreamToUrlDirectly_.st A Zinc-HTTP.package/ZnResponse.class/instance/testing/isBadRequest.st M Zinc-HTTP.package/ZnServerGenericLogEvent.class/instance/printing/printContentsOn_.st M Zinc-HTTP.package/ZnServerLogEvent.class/instance/printing/printContentsOn_.st M Zinc-HTTP.package/ZnSingleThreadedServer.class/instance/private logging/logConnectionAccepted_.st M Zinc-HTTP.package/ZnSingleThreadedServer.class/instance/private logging/logConnectionClosed_.st R Zinc-HTTP.package/ZnSingleThreadedServer.class/instance/private logging/logServerErrorOld_.st M Zinc-HTTP.package/ZnSingleThreadedServer.class/instance/private logging/logServerSocketBound.st M Zinc-HTTP.package/ZnSingleThreadedServer.class/instance/private/releaseServerSocket.st M Zinc-Resource-Meta-Core.package/ZnMimeType.class/class/class initialization/initialize.st M Zinc-Resource-Meta-Core.package/ZnMimeType.class/class/instance creation/fromString_.st A Zinc-Resource-Meta-Core.package/ZnMimeType.class/class/private/initializeSubTypeBinaryCache.st A Zinc-Resource-Meta-Core.package/ZnMimeType.class/class/private/textSubTypeFragments.st M Zinc-Resource-Meta-Core.package/ZnMimeType.class/definition.st M Zinc-Resource-Meta-Core.package/ZnMimeType.class/instance/testing/isBinary.st M Zinc-Resource-Meta-Core.package/ZnUrl.class/README.md M Zinc-Resource-Meta-Core.package/ZnUrl.class/instance/converting/inContextOf_.st M Zinc-Resource-Meta-Core.package/ZnUrl.class/instance/parsing/parseFrom_defaultScheme_.st M Zinc-Resource-Meta-Core.package/ZnUrl.class/instance/parsing/parsePath_.st A Zinc-Resource-Meta-Core.package/ZnUrl.class/instance/parsing/withRelativeReference_.st A Zinc-Resource-Meta-Core.package/ZnUrl.class/instance/private/processRelativeReference_.st M Zinc-Resource-Meta-Core.package/ZnUrl.class/instance/testing/isAbsolute.st M Zinc-Resource-Meta-Core.package/ZnUrlOperation.class/README.md M Zinc-Resource-Meta-Core.package/ZnUrlOperation.class/class/operations/handlerForOperation_with_on_.st A Zinc-Resource-Meta-Tests.package/ZnMimeTypeTests.class/instance/accessing/someNonBinaryMimeTypes.st M Zinc-Resource-Meta-Tests.package/ZnMimeTypeTests.class/instance/testing/testIsBinary.st A Zinc-Resource-Meta-Tests.package/ZnUrlTests.class/instance/testing/testReferenceResolution.st A Zinc-Resource-Meta-Tests.package/ZnUrlTests.class/instance/testing/testSchemeInQuery.st M Zinc-Tests.package/ZnEntityTests.class/instance/testing/testMultiPartFormDataWriteRead.st A Zinc-Tests.package/ZnEntityTests.class/instance/testing/testMultiPartFormDataWriteReadBinary.st M Zinc-Tests.package/ZnServerTests.class/instance/testing/testFormTest1.st A Zinc-Tests.package/ZnServerTests.class/instance/testing/testFormTest2.st A Zinc-Tests.package/ZnServerTests.class/instance/testing/testFormTest3.st A Zinc-Tests.package/ZnServerTests.class/instance/testing/testFormTest3Unspecified.st A Zodiac-Core.package/ZdcPluginSSLSession.class/instance/accessing/logging.st A Zodiac-Core.package/ZdcPluginSSLSession.class/instance/accessing/logging_.st A Zodiac-Core.package/ZdcPluginSSLSession.class/instance/initialize/enableLogging.st M Zodiac-Core.package/ZdcPluginSSLSession.class/instance/initialize/initialize.st M Zodiac-Core.package/ZdcPluginSSLSession.class/instance/primitives/primitiveSSL_setIntProperty_toValue_.st A Zodiac-Core.package/ZdcPluginSSLSession.class/instance/private/constantsSQSSL%5FPROP%5FLOGLEVEL.st Log Message: ----------- 40513 14870 Update Zn Februari 2015 https://pharo.fogbugz.com/f/cases/14870 http://files.pharo.org/image/40/40513.zip

Feb. 26, 2015

[pharo-project/pharo-core]

by GitHub

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

Feb. 26, 2015

Re: [Pharo-dev] OSProcess bug ?

by Ben Coman

On Thu, Feb 26, 2015 at 1:10 AM, jannik laval <jannik.laval(a)gmail.com> wrote: > Hi Dave, > > > > 2015-02-25 17:05 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > >> Hi Jannik, >> >> One other thing I just thought of: Check and see if your rostopic program >> is actually writing to standard output, as opposed to writing directly to >> /dev/tty. From a terminal window, I think you could do this: >> >> $ rostopic > out.txt >> > > Yes, it writes on the file after a ctrl-c. > Is that a hint? So if in one terminal you run $ rostopic > out.txt then without hitting ctrl-c, in another terminal view the contents of out.txt, is it empty? Do you get different behaviour with this between each of these mode [1]?... - *Latching mode* - rostopic will publish a message to /topic_name and keep it *latched* -- any new subscribers that come online after you start rostopic will hear this message. You can stop this at any time by pressing ctrl-C. *Once mode* - If you don't want to have to stop rostopic with ctrl-C, you can publish in *once mode*. rostopic will keep the message latched for 3 seconds, then quit. *Rate mode*. - In rate mode, rostopic will publish your message at a specific rate. For example, -r 10 will publish at 10hz. For file and piped input, this defaults to 10hz. Options: - -l, --latch New in Diamondback - Enable latch mode. Latching mode is the *default* when using command-line arguments. -r RATE - Enable *rate mode*. Rate mode is the *default* (10hz) when using piped or file input. -1, --once - Enable *once mode*. cheers -ben [1] http://wiki.ros.org/rostopic#rostopic_pub [2] http://answers.ros.org/question/59070/disable-latching-for-rostopic-in-pipi…

Feb. 26, 2015

Diffing while Merging Class Rename

by Sean P. DeNigris

It is difficult to see the actual changes when a merge includes a class rename, which just shows up as all methods removed from old class, and all methods created in new class. Is there a way to diff these methods? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Diffing-while-Merging-Class-Rename-tp4807854.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 26, 2015

Re: [Pharo-dev] Issue tracker: 13 issues to review

by Sean P. DeNigris

Marcus Denker-4 wrote > Of those, 13 issues are tagged for review: Down to 10: 14616 could use a unit test ;) but the fix looks good - waiting for the monkey to finish to resolve to-include... 14743 closed won't fix per issue comments ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-tracker-13-issues-to-review-tp4807759p4807850.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 26, 2015

Re: [Pharo-dev] Bug? JPEG reading ignores EXIF Orientation

by stepharo

We should improve the Image support because it is dated. Le 25/2/15 04:03, J.F. Rick a Ã©crit : > 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. 26, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Thierry Goubier

2015-02-26 14:04 GMT+01:00 stepharo <stepharo(a)free.fr>: > Thierry > > this is really interesting. Could you add the logic in some class comments > for the future? > Done in the v3 of the slice. A MCLazyVersionInfo puts ancestor and stepChilds data in WeakArrays to allow their memory to be reclaimed and reloaded on demand. For all purposes, a MCLazyVersionInfo behaves exactly like a MCVersionInfo with the same data, but: - let the ancestry (and step children) be garbage collected - and reload that ancestry (and stepChildren) from the MC repositories when accessed (MCLazyVersionInfo>>loadAncestorsAndStepChildren for the reload, MCLazyVersionInfo>>ancestors and MCLazyVersionInfo>>stepChildren for the access). MCLazyVersionInfo is installed just as the ancestor in a MCWorkingAncestry (the direct ancestry of a WorkingCopy, which is the state all packages take when they are loaded in an image). It allows a MCWorkingAncestry to still know which package it is coming from, and, of course, the MCLazyVersionInfo to be able to reload the relevant ancestry from the right package. Once installed, by flushing the Monticello package cache, all the stored ancestry is garbage collected, except the roots of those ancestry trees, which are the MCLazyVersionInfo instances inside the MCWorkingAncestry instances. Warnings: - Algorithms which traverse the entire ancestry chain of all packages will force a reload of all the packages contained in the image, which is a time and memory and network consuming process... - It should degrades gracefully when reloading becomes impossible (returns an empty ancestry, but keeps knowledge of the fact some ancestry is missing). But this has not been tested. Thierry > > Stef > > Le 26/2/15 10:15, Thierry Goubier a Ã©crit : > > Ok, > > a first slice is in, it's the first solution for now (second is just > extending the scheme). > > Loading the slice should install the lazy version and flush the caches > (does merging would initialize the class?) > > Thierry > > 2015-02-26 9:33 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> >>> >> And it behaves as the non-lazy one. >> >> There are a few things to change GUI-side to avoid an unnecessary >> loading of the complete ancestry of all the packages in the image, but this >> is workable. >> >> I see two ways of using it: >> >> as an "install, flush package cache before release and gain 5MB of RAM". >> If you start regularly developping (loading packages, etc...) then new >> packages will revert to non-lazy version info (without: 'please wait, I'm >> loading ancestry' moments). >> >> as a permanent change in MC. The change is a bit more intrusive (need >> to change how working copies are created) but, well, as long as the worked >> on packages are inside the in-memory MC package cache, behavior is exactly >> the same as a non-lazy version info. >> >> As you prefer. >> >> >> My focus is that we ship an image that is not growing indefinitely... so >> this means it needs to be part of the release. >> >> I don't care too much that the image is large when I work, but it >> should not come with all this data in memory when it can be calculated (or >> lazyly loaded) when needed. >> >> I added an issue: >> >> https://pharo.fogbugz.com/default.asp?14997 >> >> >> Thanks! >> >> Marcus >> >> > >

Feb. 26, 2015

Re: [Pharo-dev] Slots: weak slot

by Marcus Denker

> On 26 Feb 2015, at 14:02, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > With Camille we spent some minutes introducing a weak slot. A weak slot with a weak reference i.e., it is not taken into account by the garbage collector. If an object is only referenced by weak references it will be garbage collected. > > The nice thing about this is that now we can mix transparently weak and non-weak slots inside the same object. For example: > Object subclass: #MyWeakThingy > slots: { #weakLala => WeakSlot. > #normalInstVar } > classVariables: { } > category: âSlotTestGuille' Nice! WeakSlot linesOfCode ==> â24" > > We also implemented with Camille the #emit* methods to make it a bit faster. A simple benchmark in my machine shows that We should be able to use the byte code for reading/writing the tempVector hereâ¦ and access the inner array with no message send. (but it needs some API change in IRBuilder where we have them for now just in a version for the tempVector). Marcus

Feb. 26, 2015