July 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Bug in MailA

by Sven Van Caekenberghe

Thank you. > On 03 Jul 2016, at 13:25, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > Done! > > Cheers, > Bernhard > >> Am 03.07.2016 um 00:08 schrieb Ben Coman <btc(a)openinworld.com>: >> >> On Sun, Jul 3, 2016 at 3:16 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>> Hi, >>> >>> The following code goes into an endless loop: >>> MailAddressParser addressesIn: 'romeo&julia@verona.itâ >>> >>> Itâs because of the ampersand. The fix is trivial, because the bug just was a typo. >>> >>> Fix and test are in the Pharo50Inbox: >>> Network-Mail-BernhardPieber.46.mcz >>> Network-Tests-BernhardPieber.14.mcz >>> >>> Cheers, >>> Bernhard >> >> Thanks Bernhard. >> Can you log an issue for it on >> and submit this in Slice format. >> Instructions at http://pharo.org/contribute-propose-fix >> This makes it easier to review and the integration system only works >> with Slices & Configurations. >> >> cheers -ben > >

July 3, 2016

Re: [Pharo-dev] Bug in MailA

by Bernhard Pieber

I wonder about the process for fixes for Pharo 4.0? Is it the same? If Iâd put the equivalent fix into the Pharo40Inbox, would it be integrated? Cheers, Bernhard > Am 03.07.2016 um 08:46 schrieb stepharo <stepharo(a)free.fr>: > > Thanks Bernhard > > - can you open a bug entry? > > - publish a slice? (press slice + bug number) > > Our integration tool and process work this way > > Stef > > Le 2/7/16 Ã 21:16, Bernhard Pieber a Ã©crit : >> Hi, >> >> The following code goes into an endless loop: >> MailAddressParser addressesIn: 'romeo&julia@verona.itâ >> >> Itâs because of the ampersand. The fix is trivial, because the bug just was a typo. >> >> Fix and test are in the Pharo50Inbox: >> Network-Mail-BernhardPieber.46.mcz >> Network-Tests-BernhardPieber.14.mcz

July 3, 2016

Re: [Pharo-dev] Bug in MailA

by Bernhard Pieber

Done! Cheers, Bernhard > Am 03.07.2016 um 00:08 schrieb Ben Coman <btc(a)openinworld.com>: > > On Sun, Jul 3, 2016 at 3:16 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> Hi, >> >> The following code goes into an endless loop: >> MailAddressParser addressesIn: 'romeo&julia@verona.itâ >> >> Itâs because of the ampersand. The fix is trivial, because the bug just was a typo. >> >> Fix and test are in the Pharo50Inbox: >> Network-Mail-BernhardPieber.46.mcz >> Network-Tests-BernhardPieber.14.mcz >> >> Cheers, >> Bernhard > > Thanks Bernhard. > Can you log an issue for it on > and submit this in Slice format. > Instructions at http://pharo.org/contribute-propose-fix > This makes it easier to review and the integration system only works > with Slices & Configurations. > > cheers -ben

July 3, 2016

Re: [Pharo-dev] Bug in MailA

by Ben Coman

On Sun, Jul 3, 2016 at 6:08 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Sun, Jul 3, 2016 at 3:16 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> Hi, >> >> The following code goes into an endless loop: >> MailAddressParser addressesIn: 'romeo&julia@verona.itâ >> >> Itâs because of the ampersand. The fix is trivial, because the bug just was a typo. >> >> Fix and test are in the Pharo50Inbox: >> Network-Mail-BernhardPieber.46.mcz >> Network-Tests-BernhardPieber.14.mcz >> >> Cheers, >> Bernhard >> >> >> > > Thanks Bernhard. > Can you log an issue for it on > and submit this in Slice format. > Instructions at http://pharo.org/contribute-propose-fix > This makes it easier to review and the integration system only works > with Slices & Configurations. > > cheers -ben P.S. Once your Slice is integrated, see instructions at the bottom of [1] to get yourself added to the contributors page. [1] http://pharo.org/about cheers -ben

July 3, 2016

Re: [Pharo-dev] Bug in MailA

by stepharo

Thanks Bernhard - can you open a bug entry? - publish a slice? (press slice + bug number) Our integration tool and process work this way Stef Le 2/7/16 Ã 21:16, Bernhard Pieber a Ã©crit : > Hi, > > The following code goes into an endless loop: > MailAddressParser addressesIn: 'romeo&julia@verona.itâ > > Itâs because of the ampersand. The fix is trivial, because the bug just was a typo. > > Fix and test are in the Pharo50Inbox: > Network-Mail-BernhardPieber.46.mcz > Network-Tests-BernhardPieber.14.mcz > > Cheers, > Bernhard > > > >

July 3, 2016

Re: [Pharo-dev] Bug in MailA

by Ben Coman

On Sun, Jul 3, 2016 at 3:16 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > Hi, > > The following code goes into an endless loop: > MailAddressParser addressesIn: 'romeo&julia@verona.itâ > > Itâs because of the ampersand. The fix is trivial, because the bug just was a typo. > > Fix and test are in the Pharo50Inbox: > Network-Mail-BernhardPieber.46.mcz > Network-Tests-BernhardPieber.14.mcz > > Cheers, > Bernhard > > > Thanks Bernhard. Can you log an issue for it on and submit this in Slice format. Instructions at http://pharo.org/contribute-propose-fix This makes it easier to review and the integration system only works with Slices & Configurations. cheers -ben

July 2, 2016

Bug in MailA

by Bernhard Pieber

Hi, The following code goes into an endless loop: MailAddressParser addressesIn: 'romeo&julia@verona.itâ Itâs because of the ampersand. The fix is trivial, because the bug just was a typo. Fix and test are in the Pharo50Inbox: Network-Mail-BernhardPieber.46.mcz Network-Tests-BernhardPieber.14.mcz Cheers, Bernhard

July 2, 2016

[pharo-project/pharo-core]

by GitHub

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

July 2, 2016

[pharo-project/pharo-core] f723d3: 60132

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: f723d388e7e31748cf5bff8b049f0fde14abeef5 https://github.com/pharo-project/pharo-core/commit/f723d388e7e31748cf5bff8b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-07-02 (Sat, 02 Jul 2016) Changed paths: A Kernel-Tests.package/MethodPragmaTest.class/instance/testing-method/testMethodSelector.st R Kernel-Tests.package/MethodPragmaTest.class/instance/testing-method/testSelector.st M Kernel-Tests.package/ObjectTest.class/instance/tests - debugging/testHaltOnce.st R Kernel.package/Deprecation.class/class/instance creation/method_explanation_on_in_.st M Kernel.package/Deprecation.class/definition.st A Kernel.package/Deprecation.class/instance/accessing/date_.st M Kernel.package/Deprecation.class/instance/accessing/deprecationDate.st M Kernel.package/Deprecation.class/instance/accessing/explanationString.st A Kernel.package/Deprecation.class/instance/accessing/explanation_.st M Kernel.package/Deprecation.class/instance/accessing/methodReference.st A Kernel.package/Deprecation.class/instance/accessing/method_.st A Kernel.package/Deprecation.class/instance/accessing/rule_.st M Kernel.package/Deprecation.class/instance/accessing/versionString.st A Kernel.package/Deprecation.class/instance/accessing/version_.st M Kernel.package/Deprecation.class/instance/handling/defaultAction.st A Kernel.package/Deprecation.class/instance/handling/logTranscript.st A Kernel.package/Deprecation.class/instance/handling/transform.st R Kernel.package/Deprecation.class/instance/initialize-release/method_explanation_on_in_.st M Kernel.package/Halt.class/class/halting/once.st R Kernel.package/Halt.class/class/once-reset/resetHaltOnce.st A Kernel.package/Halt.class/class/once-reset/resetOnce.st M Kernel.package/Object.class/instance/deprecation/deprecated_.st M Kernel.package/Object.class/instance/deprecation/deprecated_on_in_.st A Kernel.package/Object.class/instance/deprecation/deprecated_on_in_transformWith_.st M Kernel.package/Object.class/instance/deprecation/deprecated_transformWith_.st A Kernel.package/Pragma.class/instance/accessing-method/methodSelector.st M Morphic-Base.package/extension/WorldState/class/debugOn_.st M Reflectivity-Tools.package/HaltOnceIconStyler.class/instance/defaults/iconBlock_.st M Reflectivity-Tools.package/HaltOnceIconStyler.class/instance/defaults/iconLabelBlock_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60131.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60132.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60131.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60132.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Base.package/extension/Object/instance/inspectOnce.st Log Message: ----------- 60132 18670 Move the transformation code from #deprecated:transformWith: to Deprecation class https://pharo.fogbugz.com/f/cases/18670 18643 make "enable inspect haltOnce" work (Debug menu) https://pharo.fogbugz.com/f/cases/18643 18666 Introduce Pragma>>#methodSelector https://pharo.fogbugz.com/f/cases/18666 http://files.pharo.org/image/60/60132.zip

July 2, 2016

Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

by Max Leske

Itâs nice to see the enthusiasm (both pro and con) on this issue. I just want to clarify that it has nothing to do with a class room setting, where the changes file is being shared or copied so students have access. I have run into the corrupted .changes file problem myself a couple of times for two reasons mainly: a) Iâve done a lot of work but need to check something against code that wasnât modified (and no, checking package changes in Monticello wouldnât help in the case Iâm thinking of. Imagine for example a huge refactoring across multiple packages). So I open a second copy of the image. I keep both images open because its convenient but at some point I accidentally make a change in the wrong image. Now Iâm screwed. b) I forgot that I already had the image running (e.g. minimised). I start a fresh copy and work on it until I realise that some of my method sources are broken. Again: screwed. Another thing I want to mention is that the semantics of flush depend on the operating / file system (I have experienced this first hand between Linux (ext4) and OS X (HSF+)). Just because youâve flushed youâre buffer doesnât mean that the contents have actually been written to the file. So while it may be true that there is a #flush missing somewhere I would not expect that adding the #flush will solve the problem entirely (which is one reason for proposing a locking mechanism in the first place). Cheers, Max

July 2, 2016