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

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

by Marcus Denker

> On 23 Mar 2015, at 17:16, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > I still have production code (GemTools) that runs today in Pharo 1.1 ... > > I assume that others also have production code running in older versions of Pharo and Squeak and GemStone so I make sure that Metacello continues to work on those platforms ... > > Not everyone has the luxury of having the time to port their entire production catalog to the latest version of Pharo ... > > I don't demand that zeroconf support Pharo1.2 as long as there is a way that I can keep downloading Pharo1.2 ... but if you don't intend to support all releases of Pharo on zeroconf, then I will simply start using the alternate long term method in my scripts because I certainly don't want to have to change scripts that are working perfectly fine, because you've decided to drop support for a particular versionâ¦. > Even Microsoft does not support ever old version of Windows. How can we? Wouldnât it get indefinitely expensive? Marcus

March 23, 2015

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

by Dale Henrichs

I still have production code (GemTools) that runs today in Pharo 1.1 ... I assume that others also have production code running in older versions of Pharo and Squeak and GemStone so I make sure that Metacello continues to work on those platforms ... Not everyone has the luxury of having the time to port their entire production catalog to the latest version of Pharo ... I don't demand that zeroconf support Pharo1.2 as long as there is a way that I can keep downloading Pharo1.2 ... but if you don't intend to support all releases of Pharo on zeroconf, then I will simply start using the alternate long term method in my scripts because I certainly don't want to have to change scripts that are working perfectly fine, because you've decided to drop support for a particular version.... Dale On 3/22/15 11:46 PM, Marcus Denker 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) >> > I do not think that this is a good idea: we are not building a Museum. > For example, we improve the core libraries. It will make something like Metacello *very* complex to be compatible over so many versions back. > In the end, people who have this philosophy start to even request âto make this easierâ, and then tell us to stop changing. > > Make your live easier and do *not* support old versions! Everything gets easier and the world will be a happier place. > > Marcus > >

March 23, 2015

[pharo-project/pharo-core] 395d15: 40577

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 395d1598748873bf4a4d1c194585e53f2821216c https://github.com/pharo-project/pharo-core/commit/395d1598748873bf4a4d1c19… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-23 (Mon, 23 Mar 2015) Changed paths: M Rubric.package/RubEditingMode.class/class/menu/extendedSearchMenuOn_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script576.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script577.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40576.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40577.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/build.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/buildNewClass.st A Traits.package/TClassDescription.class/instance/slots/slotNamed_ifFound_.st A Traits.package/TClassDescription.class/instance/slots/slotNamed_ifFound_ifNone_.st A Traits.package/TraitDescription.class/instance/slots/slotNamed_ifFound_.st A Traits.package/TraitDescription.class/instance/slots/slotNamed_ifFound_ifNone_.st Log Message: ----------- 40577 15190 Nautilus incorrectly flags Error classes as "missing class comments" https://pharo.fogbugz.com/f/cases/15190 14924 Failing tests: testClassDescriptionRespectsPolymorphismWithTraitDescription https://pharo.fogbugz.com/f/cases/14924 15189 "Extended search" vs. "Code search" https://pharo.fogbugz.com/f/cases/15189 http://files.pharo.org/image/40/40577.zip

March 23, 2015

[pharo-project/pharo-core]

by GitHub

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

March 23, 2015

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

by kilon alios

I am referring to a general workflow that will ensure a user has a uniform experience GUI wise. For example a gui tool will have to use the tab system if it can be spanned in multiple instances, have a shortcut dialog that will appear in a specific way, tools that come with their own code editors respect general editor shortcuts etc etc . It will form the basis upon which GUIs that are integrated to pharo are based on and then also allow for freedom of expression on implementation details. A general agreement on how Pharo should behave GUI wise since GUI is such a huge deal for Pharo. On Mon, Mar 23, 2015 at 4:58 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > On Mon, Mar 23, 2015 at 3:15 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> It would be nice if there was a general guideline of GUI design that all >> tools would have to obey instead of giving complete freedom in creating a >> very fragmented experience. >> > Could you elaborate on this a little? Are you refering to Spec vs Glamour > (Brick)? Or issues inside of Spec, and/or Morphic? > > Peter > >

March 23, 2015

Re: [Pharo-dev] Morphs becoming unresponsive

by Ben Coman

On Mon, Mar 23, 2015 at 9:06 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > I just ran into a case where all morphs became unresponsive, and clicking > anywhere only gave me the World Menu. > > After some investigation, it turned out all the World submorphs had been > locked, and I could "unfreeze" them with the following (from a new > Workspace): > World submorphsDo: [ :aMorph | aMorph unlock ] > > What triggered it? > Well, the image had become unresponsive, so I clicked the close buttons a > couple of times (before trying good ol' cmd-dot, which brought up a > debugger on the old UI process and let me continue). > > The close dialog is modal, normally that's no problem, since the modal > morph locks all other morphs, no two can be opened at the same time (unless > you somehow let that modal morph open another), but the close triggered by > the system window's close button is special, since it is triggered outside > the control of the World. > > The bug is rare in occurrence, yet easy to trigger; press the window close > button twice, cancel one of the close dialogs, all windows that were open > will remain locked and seem unresponsive. > > It might be smart to rethink the whole modality concept to make the code > more robust/coherent, but for now an extra check for this single case in > PasteUpMorph >> windowEvent: (for instance, using a morph property) should > do the trick, I'll submit a slice shortly. > > Cheers, > Henry > Nice find. I've been hit by this a few times and been clueless. cheers -ben

March 23, 2015

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

by Peter UhnÃ¡k

On Mon, Mar 23, 2015 at 3:15 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > It would be nice if there was a general guideline of GUI design that all > tools would have to obey instead of giving complete freedom in creating a > very fragmented experience. > Could you elaborate on this a little? Are you refering to Spec vs Glamour (Brick)? Or issues inside of Spec, and/or Morphic? Peter

March 23, 2015

Re: [Pharo-dev] [Moose-dev] Re: The Grapher charting engine

by Alexandre Bergel

Yes. Although RTDevVarDecorator is not rooted into strong maths. It was more an experiment. If you look at the class RTDevVarDecorator, you will see it is quite simple. Adding decoration in a chart made with Grapher is very simple. Alexandre > On Mar 23, 2015, at 12:55 AM, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > > is desviation a typo of deviation? > > HwaJong > >> 2015. 3. 21., ìì¹¨ 6:18, Alexandre Bergel <alexandre.bergel(a)me.com> ìì±: >> >> Dear all, >> >> As many of you know, Grapher is a Ã¼ber-cool charting engine, part of Roassal. >> For people who do not know what Grapher is, here is a (compelling we hope) example: >> <Screen Shot 2015-03-20 at 6.12.22 PM.png> >> Which is obtained by the following script: >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> | b colors points ds pts dec lb | >> b := RTGrapher new. >> colors := Array with: Color red with: Color blue. >> points := OrderedCollection new. >> >> colors do: [ :c | >> ds := RTStackedDataSet new. >> pts := ((1 to: 100) collect: [ :i | 50 atRandom - 25 ]) cumsum. >> points add: pts. >> ds points: pts. >> dec := RTDevVarDecorator new. >> dec moveBehind; >> desviation: 0.5; >> color: (c alpha: 0.3); >> points: pts. >> ds connectUsing: (RTLine new color: (c alpha: 0.5); width: 1 ). >> b add: ds. >> b addDecorator: dec. >> ]. >> >> b axisX; axisY. >> b build. >> >> lb := RTLegendBuilder new. >> lb view: b view. >> colors doWithIndex: [ :c :i | >> lb addColor: c text: 'Series ', i printString ]. >> lb build. >> b view @ RTZoomableView. >> b view >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> >> In our grand vision of making Roassal the best visualizing engine of the Universe (we also know to be modest time to time, but not today :-), Grapher will play a very important role. We would like to stabilize Grapher and make it sure it happily fits everybody needs. You can help on it: >> >> - When you are tempted to look at the dark side of the planet (this is where R, JFreeChart, gnuplot, D3 and all their friends live), let us know. We will make sure to make you are happy again. >> >> - Share your wishlist with us. We already have a long todo list, but your opinion does matter and will take it seriously >> >> - we are open to contributions, which could be financial, bug fixe, enhancement, or simply encouragement. >> >> I am very happy to be surrounded by very smart engineers. Your encouragement are making them happy :-) >> >> Cheers, >> Alexandre, in the name of the Object Profile Team >> >> NB: sorry for the cross-list posting, but this email is very important for us, and for you we hope. >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 23, 2015

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

by Marcus Denker

On Mon, Mar 23, 2015 at 2:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > stepharo wrote > > Could you stop crying because this is a bit boring? > > Could you address my policy suggestion instead of crying? ;) For two of the issues, the change in iteraction was an unwanted side effect. Both where retracted. The third (sender of) happened the following: opening the browser on a single method was broken for a while, and it tool some effort to fix. While cursing this fact, I thought that this idea of opening a different tool with no way of knowing beforehand which one will open was never a good idea and that I always wanted to get rid of it. So I changed this to be able to work (the other bug was fixed some weeks later, too), and was thinking that if people would really not be able to life with that they would tell... Yours is the first comment about it. In general, the idea of "you have to ask and get the ok from the list for every change" is dangerous... the Smalltalk people are *extremely* conservative. If you ask, the only answer will be "NO". Smalltalk is perfect. There is nothing to improve. And even the bad things: people use the for decades. If we want change, it will be hard... Keep in mind that you can find a reason to *not* do something for *anything*. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

March 23, 2015

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

by kilon alios

It would be nice if there was a general guideline of GUI design that all tools would have to obey instead of giving complete freedom in creating a very fragmented experience. I think this will be necessary the more complex tools are integrated into Pharo.

March 23, 2015