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

Old Pharo Mac VM on pharo.org

by Noury Bouraqadi

Hi, On http://pharo.org/download <http://pharo.org/download> I got the Mac VM dating back to sept 2014. Shouldn't it be http://files.pharo.org/vm/pharo/mac/latest.zip <http://files.pharo.org/vm/pharo/mac/latest.zip> ? Noury

March 23, 2015

Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?

by Sven Van Caekenberghe

> On 23 Mar 2015, at 09:24, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 23 Mar 2015, at 09:17, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> On Mon, Mar 23, 2015 at 9:16 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> > On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> > >> > >> >> On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> >> >> Damien, >> >> >> >> I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip) >> > >> > why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) >> > this âforever backward compatibilityâ ends up being really complicated. >> >> I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judgeâ¦ :) ). >> >> I do not judge. I pity :)) >> > > It is ok to use them, but people should not expect that packages and framework will be updated. > (and this even defeats the purpose: people use old version *becasue they do not want change*. > > If we update stuff under their feet (Zinc, Metacelloâ¦) this will lead to exactly what they do not want. > > We should consider old version to be frozen, *including* the frameworks and tools. > > Marcus I agree. It is of course up to each developer to decide how far back they want to support their code. But indeed, the reason to stay with an old(er) version is because you do not want change. Sven

March 23, 2015

[pharo-project/pharo-core]

by GitHub

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

March 23, 2015

[pharo-project/pharo-core] d94d14: 40576

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d94d140065ff6e75a3a5d56d0c3882df35bd3094 https://github.com/pharo-project/pharo-core/commit/d94d140065ff6e75a3a5d56d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-23 (Mon, 23 Mar 2015) Changed paths: M Kernel.package/Delay.class/README.md R Kernel.package/Delay.class/class/primitives/primSignal_atMilliseconds_.st M Kernel.package/Delay.class/definition.st M Kernel.package/Delay.class/instance/private - scheduler/schedulerResumptionTime.st R Kernel.package/Delay.class/instance/private/adjustResumptionTimeOldBase_newBase_.st R Kernel.package/Delay.class/instance/private/resumptionTime.st R Kernel.package/Delay.class/instance/private/resumptionTime_.st R Kernel.package/Delay.class/instance/private/signalWaitingProcess.st R Kernel.package/Delay.class/instance/public/beingWaitedOn.st R Kernel.package/Delay.class/instance/public/beingWaitedOn_.st R Kernel.package/Delay.class/instance/public/delayDuration.st R Kernel.package/Delay.class/instance/timer process/timingPriorityBeingWaitedOn_.st R Kernel.package/Delay.class/instance/timer process/timingPriorityResumptionTime_.st R Kernel.package/Delay.class/instance/timer process/timingPrioritySignalWaitingProcess.st R Kernel.package/DelayNullScheduler.class/instance/as yet unclassified/shutDown.st A Kernel.package/DelayNullScheduler.class/instance/snapshotting/shutDown.st M Kernel.package/DelayScheduler.class/README.md R Kernel.package/DelayScheduler.class/instance/primitives/primSignal_atMilliseconds_.st R Kernel.package/DelayWaitTimeout.class/instance/signaling/timingPrioritySignalWaitingProcess.st R Kernel.package/MonitorDelay.class/instance/private/timingPrioritySignalWaitingProcess.st A KernelTests.package/DelayNullSchedulerTest.class/README.md A KernelTests.package/DelayNullSchedulerTest.class/definition.st A KernelTests.package/DelayNullSchedulerTest.class/instance/tests/testNullDelay.st M Morphic-Widgets-Pluggable.package/PluggableTextMorph.class/instance/model access/setTextBasic_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor/visitNode_.st M Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testUninstallLinkAndRun.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script575.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script576.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40575.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40576.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40576 12569 TextModel should not move scroll when accepting text https://pharo.fogbugz.com/f/cases/12569 15141 More Cleanup after case 14353 Delay refactoring (part 2) https://pharo.fogbugz.com/f/cases/15141 15207 Undo compiler change from case 15196 https://pharo.fogbugz.com/f/cases/15207 http://files.pharo.org/image/40/40576.zip

March 23, 2015

Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?

by Marcus Denker

> On 23 Mar 2015, at 09:17, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > On Mon, Mar 23, 2015 at 9:16 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > > On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > > > >> On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: > >> > >> Damien, > >> > >> I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip <https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip>). > > > > why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) > > this âforever backward compatibilityâ ends up being really complicated. > > I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judgeâ¦ :) ). > > I do not judge. I pity :)) > It is ok to use them, but people should not expect that packages and framework will be updated. (and this even defeats the purpose: people use old version *becasue they do not want change*. If we update stuff under their feet (Zinc, Metacelloâ¦) this will lead to exactly what they do not want. We should consider old version to be frozen, *including* the frameworks and tools. Marcus

March 23, 2015

Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?

by Tudor Girba

Hi, On Mon, Mar 23, 2015 at 9:16 AM, Max Leske <maxleske(a)gmail.com> wrote: > > > On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > >> On 22 Mar 2015, at 22:56, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > >> > >> Damien, > >> > >> I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test > Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is > something funkily different between what is available on zeroconf for 1.3 > and what actually "works" for for 1.3 ( > https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip) > > > > why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with > the exception of some legacy apps) > > this âforever backward compatibilityâ ends up being really complicated. > > I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judgeâ¦ :) ). I do not judge. I pity :)) Doru But I donât need the zero conf scripts for those. > > > I want to deprecate zeroconf for, at least, all pharo < 2.0. > > > > why? > > because the scripts right now downloads one unique vm for all images. > Which means download of sources V1, V2, V3â¦ and starting next month V4. > > I want to remove at least one of those sources. > > > > Alsoâ¦ the upcoming spur VM will add another level of complexity to > zeroconf scripts (because is everything goes smooth, Pharo5 will dispatch > with spur, without backward compatibility). So it will be another V5 + the > different VMâ¦ > > > > What to do with those scripts? > > > > maybe deprecate the âvmâ part, and replace it for: > > > > /vm1 > > /vm2 > > /vm3 > > /vm4 > > /vmN > > > > â¦ and /vm downloading the latest stable (/vm4, next month) > > > > but thenâ¦ what to do with the > > > > /30+vm > > /40+vm > > > > scripts? > > yesâ¦ they *could* realise link is talking to âconvenient vmâ so it would > download /vm3 and /vm4â¦ but Iâm describing the problem, who grows > exponentially. > > Keeping âforever compatibilityâ is not good. > > It does not work. > > It does not scale. > > > > Esteban > > > >> Dale > >> > >> On 3/13/15 5:04 AM, Damien Cassou wrote: > >>> Esteban Lorenzano writes: > >>> > >>>> thatâ¦ is someone using it? > >>> I think the pharo-users mailing list is more appropriate > >>> > >> > >> > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 23, 2015

Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?

by Max Leske

> On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> Damien, >> >> I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip) > > why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) > this âforever backward compatibilityâ ends up being really complicated. I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judgeâ¦ :) ). But I donât need the zero conf scripts for those. > > I want to deprecate zeroconf for, at least, all pharo < 2.0. > > why? > because the scripts right now downloads one unique vm for all images. Which means download of sources V1, V2, V3â¦ and starting next month V4. > I want to remove at least one of those sources. > > Alsoâ¦ the upcoming spur VM will add another level of complexity to zeroconf scripts (because is everything goes smooth, Pharo5 will dispatch with spur, without backward compatibility). So it will be another V5 + the different VMâ¦ > > What to do with those scripts? > > maybe deprecate the âvmâ part, and replace it for: > > /vm1 > /vm2 > /vm3 > /vm4 > /vmN > > â¦ and /vm downloading the latest stable (/vm4, next month) > > but thenâ¦ what to do with the > > /30+vm > /40+vm > > scripts? > yesâ¦ they *could* realise link is talking to âconvenient vmâ so it would download /vm3 and /vm4â¦ but Iâm describing the problem, who grows exponentially. > Keeping âforever compatibilityâ is not good. > It does not work. > It does not scale. > > Esteban > >> Dale >> >> On 3/13/15 5:04 AM, Damien Cassou wrote: >>> Esteban Lorenzano writes: >>> >>>> thatâ¦ is someone using it? >>> I think the pharo-users mailing list is more appropriate >>> >> >> > >

March 23, 2015

Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?

by Esteban Lorenzano

> On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Damien, > > I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip) why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) this âforever backward compatibilityâ ends up being really complicated. I want to deprecate zeroconf for, at least, all pharo < 2.0. why? because the scripts right now downloads one unique vm for all images. Which means download of sources V1, V2, V3â¦ and starting next month V4. I want to remove at least one of those sources. Alsoâ¦ the upcoming spur VM will add another level of complexity to zeroconf scripts (because is everything goes smooth, Pharo5 will dispatch with spur, without backward compatibility). So it will be another V5 + the different VMâ¦ What to do with those scripts? maybe deprecate the âvmâ part, and replace it for: /vm1 /vm2 /vm3 /vm4 /vmN â¦ and /vm downloading the latest stable (/vm4, next month) but thenâ¦ what to do with the /30+vm /40+vm scripts? yesâ¦ they *could* realise link is talking to âconvenient vmâ so it would download /vm3 and /vm4â¦ but Iâm describing the problem, who grows exponentially. Keeping âforever compatibilityâ is not good. It does not work. It does not scale. Esteban > Dale > > On 3/13/15 5:04 AM, Damien Cassou wrote: >> Esteban Lorenzano writes: >> >>> thatâ¦ is someone using it? >> I think the pharo-users mailing list is more appropriate >> > >

March 23, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Nicolai Hess

2015-01-06 10:55 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > Thank you for this explanation > > 2014-12-31 23:47 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > >> Bloc has a big future, for sure! I hope it will move Pharo to a very new >> level! As Doru said, Brick was born out of necessity. More exactly because >> of text resizing in Inspector. By default, if one wants to clip/resize text >> in tabs she uses clippingBounds. And clippingBounds is called during... >> what would it be?...during drawing! For example *TabExample open. *So >> morphic (in some cases) calculates geometry of submorphs during drawing. >> And very first version of Brick was build to shrink/clip tabs with content >> during layouting and not during drawing :) Simple like that. >> >> Cheers, >> Alex >> >> On Wed, Dec 31, 2014 at 10:13 PM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> >>> Of course, I meant to say that Brick is the incremental solution, not >>> Bloc :) >>> >>> Doru >>> >>> On Wed, Dec 31, 2014 at 2:08 PM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> Hi, >>>> >>>> Brick was born out of necessity. It is a thin layer on top of basic >>>> Morphic that is supposed to coexist with Morphic but not be bound by >>>> various problems Morphic has (such as the layout). Alex Syrel built it >>>> primarily for performance reasons and it was critical to make GTSpotter >>>> work. In the meantime, also the pager interface of GTInspector is using it >>>> as well. Currently, Brick is able to draw itself on Athens. >>>> >>>> About the relation with Bloc: we definitely do not want to end up with >>>> two solutions. Building Brick was a great learning experience. Bloc >>>> followed a rewrite from scratch approach, while Bloc is more incremental >>>> (it subclasses Morph) but it works in production. As both are able to work >>>> with Athens and both have local coordinates, I think it's a great >>>> opportunity to learn from both and find the one path that will be >>>> integrated in Pharo. Alex will be at the PharoDays and if Alain is >>>> available, he will work with Alain. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Wed, Dec 31, 2014 at 12:30 PM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>>> >>>>> Le 31/12/14 11:58, Nicolai Hess a Ã©crit : >>>>> >>>>>> I took a look at GLMBrick and I am wondering what is the intent: >>>>>> >>>>>> - a temporary solution until this functions/behavior are included in >>>>>> Morphic >>>>>> >>>>> would be nice. >>>>> >>>>>> - a layer on top of morphic without the intent to do this in Morphic >>>>>> any time. >>>>>> - a temporary solution until this functions/behaviors are implemented >>>>>> with bloc >>>>>> >>>>> >>>>> I hope the third but we will need more people participating to Bloc. >>>>> >>>>> I should continue to work on the documentation.... but it takes time. >>>>> >>>>>> >>>>>> nicolai >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > I would like to raise the question again. Brick is not a thin layer anymore. Looks more like a new framework (still, based on Morphic but "hiding" its origin). Spotter highly depends on this. There are some efforts to make spotter a central tool. And make it visible and discoverable for new users. It may be advertised as one of the hot feature of the new release. What do you want with brick ? A new framework or just an "implementation detail" for spotter? It is *really* important to clarify this. nicolai

March 23, 2015

Re: [Pharo-dev] UI Workflows Are Like Snowflakes

by Nicolai Hess

Don't fight against each other, there are more important things to do:) And of course, it won't hurt to do more discussions on the mailing list about UI changes. And of course, it won't hurt to have more people, regular looking at the issue tracker, commenting / fixing / reviewing issues. 2015-03-23 7:54 GMT+01:00 stepharo <stepharo(a)free.fr>: > Sean > > Could you stop crying because this is a bit boring? > Can we do mistake? Yes > How much time the change I did stayed? 20 hours? > About 15086 was it not a consequence of some of your changes? > Why did you review it? > > I think that you do not realize the difficulty to assess and integrate > code that you do not > develop. So instead of crying help. > > Stef > > Le 22/3/15 23:41, Sean P. DeNigris a Ã©crit : > > I am clear on Pharo's vision, so I'm happy to adapt to our dizzying pace >> of >> change that comes with progress toward it. >> >> But... there is one area where I feel we need a bit more consensus before >> blazing a trail... changes to the UI workflow of existing IDE tools. I'm >> not >> talking about GT, which aims to reinvent the IDE. I'm talking about subtle >> changes in the effect of certain button clicks or shortcuts which can lead >> to gnashing of teeth as unsuspecting users: >> 1. get a funny feeling that something is wrong, but can't quite put their >> finger on it >> 2. blame themselves that they must have been doing something different all >> along >> 3. start the bug report process only to eventually find out that this is a >> "feature" >> etc... >> >> These specifically threw me for a loop: >> 14890 Browsing a different class should select by default the previously >> browsed method >> which made it seem impossible to get back to a class template in >> Nautilus >> 14666 When doing a "implementors of" with a selector that has 1 >> implementor >> --> neverthless open method list >> which requires extra clicks to get back to the full power of a class >> browser for no apparent (to me at the time) gain >> 15086 Ctrl + Arrow Behaviour >> which disabled horizontal mouse scrolling, which I've come to depend >> on in >> my projects >> >> And so I have a Policy Suggestion: IDE UI workflow changes /must/ be >> discussed on the list prior to >> integration. >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/UI- >> Workflows-Are-Like-Snowflakes-tp4814234.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >> > >

March 23, 2015