Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
well… after sending this mail I stayed thinking and I think something like this is precisely what I have to do :) so I will do an important change to zeroconf to ensure newer versions do not screw with older ones. cheers, Esteban On 23 Mar 2015, at 09:06, Esteban Lorenzano esteba...@gmail.com wrote: On 22 Mar 2015, at 22:56, Dale Henrichs dale.henri...@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
Re: [Pharo-dev] [Pharo4] Failing tests on CI server
testBehaviorRespectsPolymorphismWithTraitBehavior is also fixed in upstream. On Mon, Mar 23, 2015 at 2:07 PM, Marcus Denker marcus.den...@inria.fr wrote: Hi We have 4 failing tests left, one is already fixed but not yet in the release: GLMTabulatorMorphicTest#testSpawnTabulator - fixed upstream TxAthensLayoutTest#testScrollToLargeX BehaviorTest#testBehaviorRespectsPolymorphismWithTraitBehavior ClassDescriptionTest#testClassDescriptionRespectsPolymorphismWithTraitDescription
Re: [Pharo-dev] Old Pharo Mac VM on pharo.org
On 23 Mar 2015, at 10:27, Norbert Hartl norb...@hartl.name wrote: Am 23.03.2015 um 09:51 schrieb Noury Bouraqadi bouraq...@gmail.com mailto:bouraq...@gmail.com: 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 ? No, I think latest is more less a direct copy of the latest successful build on jenkins. That would be a no-go to offer as the vm to use. VMs have have releases as well. And in the same directory there is a stable.zip which is the right one. And it is from september. Everything else is in the hands of esteban. this :) but seriously: I’ve been having some problems to promote a newer vm as stable, concretely in the pharo-minimal step. I wanted to have new one for Pharo4, but I’m not arriving either… so I will move it as soon as I find a solution, I’m sorry :( Esteban Norbert
Re: [Pharo-dev] Issue Validator Report - Service Temporarily Unavailable
thanks Christophe. On Mon, Mar 23, 2015 at 8:17 PM, Christophe Demarey christophe.dema...@inria.fr wrote: Jenkins was down. I just restarted it. Le 23 mars 2015 à 13:04, Ben Coman a écrit : I went to review an issue validation report and got Service Temporarily Unavailable https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/27809//artifact/validationReport.html cheers -ben
[Pharo-dev] Morphs becoming unresponsive
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
[Pharo-dev] [Pharo4] Failing tests on CI server
Hi We have 4 failing tests left, one is already fixed but not yet in the release: GLMTabulatorMorphicTest#testSpawnTabulator - fixed upstream TxAthensLayoutTest#testScrollToLargeX BehaviorTest#testBehaviorRespectsPolymorphismWithTraitBehavior ClassDescriptionTest#testClassDescriptionRespectsPolymorphismWithTraitDescription
Re: [Pharo-dev] Issue Validator Report - Service Temporarily Unavailable
Jenkins was down. I just restarted it. Le 23 mars 2015 à 13:04, Ben Coman a écrit : I went to review an issue validation report and got Service Temporarily Unavailable https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/27809//artifact/validationReport.html cheers -ben smime.p7s Description: S/MIME cryptographic signature
[Pharo-dev] Issue Validator Report - Service Temporarily Unavailable
I went to review an issue validation report and got Service Temporarily Unavailable https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/27809//artifact/validationReport.html cheers -ben
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
On Mon, Mar 23, 2015 at 3:15 PM, kilon alios kilon.al...@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
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
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.uh...@gmail.com wrote: On Mon, Mar 23, 2015 at 3:15 PM, kilon alios kilon.al...@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
Re: [Pharo-dev] Morphs becoming unresponsive
On Mon, Mar 23, 2015 at 9:06 PM, Henrik Johansen henrik.s.johan...@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
[Pharo-dev] [pharo-project/pharo-core] 395d15: 40577
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 395d1598748873bf4a4d1c194585e53f2821216c https://github.com/pharo-project/pharo-core/commit/395d1598748873bf4a4d1c194585e53f2821216c Author: Jenkins Build Server bo...@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
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
On 23 Mar 2015, at 09:24, Marcus Denker marcus.den...@inria.fr wrote: On 23 Mar 2015, at 09:17, Tudor Girba tu...@tudorgirba.com wrote: Hi, On Mon, Mar 23, 2015 at 9:16 AM, Max Leske maxle...@gmail.com wrote: On 23 Mar 2015, at 09:06, Esteban Lorenzano esteba...@gmail.com wrote: On 22 Mar 2015, at 22:56, Dale Henrichs dale.henri...@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
Re: [Pharo-dev] Old Pharo Mac VM on pharo.org
Am 23.03.2015 um 09:51 schrieb Noury Bouraqadi bouraq...@gmail.com: 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 ? No, I think latest is more less a direct copy of the latest successful build on jenkins. That would be a no-go to offer as the vm to use. VMs have have releases as well. And in the same directory there is a stable.zip which is the right one. And it is from september. Everything else is in the hands of esteban. Norbert
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
stepharo wrote Could you stop crying because this is a bit boring? Could you address my policy suggestion instead of crying? ;) It would've taken the same amount of time to answer my message productively instead of lawyering it by pointing out the one example out of three that you could turn back around on me and ignoring everything else. stepharo wrote So instead of crying help. I've participated in fixing hundreds of issues, and that's just on the new issue tracker. Is that a reasonable comment? - Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814344.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
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.
Re: [Pharo-dev] [Moose-dev] Re: The Grapher charting engine
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...@gmail.com wrote: is desviation a typo of deviation? HwaJong 2015. 3. 21., 아침 6:18, Alexandre Bergel alexandre.ber...@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-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
On Mon, Mar 23, 2015 at 2:33 PM, Sean P. DeNigris s...@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 -- den...@acm.org http://www.marcusdenker.de
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40577 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] GLMBrick whats next?
Hi Aliaksei, this is a good and interesting read, especially the feedback on making it fast (solution to some performance problems in Morphic). However, I have the feeling that the css inspired layout syntax is a step backward on what is/was Morphic (which is using other morphs to constrain and adjust layout in the same way as TeX/LaTeX instead of adding padding, align). Was that syntax choosen because layouting with filler Morphs is considered too slow or too complex to be understandable? Regards, Thierry Le 23/03/2015 20:54, Aliaksei Syrel a écrit : Hi, Sorry if my reply will be too long, but I tried to summarise our experience with Morphic/Brick and give some useful feedback or even provide ideas. Who wants will read :) Brick is not a thin layer anymore. It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born out of need. Spotter is completely built using Brick and Rubric. No morphs are used at all (except Rubric of course). All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from original Morph only Canvas (without drawing) and MorphicEvents. Everything else was rewritten from scratch. During some period of time Brick was able to render itself on Athens canvas, but we dropped it because of Font issues in athens. Spotter is not the only tool written using Brick, GLMPager - a pane pager in GT-Inspector, GT-Playground and GT-Debugger is also completely done using Brick. Almost all tab labels and tab selector in GT tools are Bricks. I could say that we collected quite some experience building it. Now I would like to enumerate features of UI framework we used to solve encountered problems. * Local bound coordinates. Nothing to say more here :) It's somehow obvious to have. * Detects graph of Bricks that should be invalidated when Brick triggers invalidation. So there is no need to invalidate the whole graph. o For example if Brick fills parent it means that it doesn't depend on children (simple and most common situation). So if any child triggers invalidation there is no need to invalidate parent as it doesn't depend on them. The same works in reversed way. o Build graph separately for each dimension: width and height. If only height of Brick was changed and children depend only on width, there is no need to invalidate them = x2 faster. o Invalidate resizing and re layouting separately. If there is no need to reposition bricks when size changes we just skip it. * Link subbricks in a DoubleLinked list. So subbrickAfter and subbrickBefore could be done in O(1). Morphic does it in O(n). It iterates over the whole submorphs collection of the owner finds index if current morph and then returns submorphs at: index +/-1. submorphAfter is used when morphic tries to detect which morph should take focus. Take a look at: MorphnextMorphWantingFocus. It iterates over owner's subbricks and for each asks submorphAfter (O(n)) - resulting time O(n^2)! That is why opening a window with a lot of submorphs takes so many time, especially system browser for big classes. * Native support of /paddings/ with css-like syntax: padding: anArrayOrInteger paddingTop: anInteger paddingRight: anInteger paddingBottom: anInteger paddingLeft: anInteger padding: 10. top, right, bottom, left padding are 10px padding: #(10 20). top, bottom padding 10px. left, right padding 20px padding: #(10 20 30). top 10px. left, right 20px. bottom 30px padding: #(10 20 30 40). top 10px, right 20px, bottom 30px, left 40px * Native support of /margins/ with css-like syntax: margin: anArrayOrInteger marginTop: anInteger marginRight: anInteger marginBottom: anInteger marginLeft: anInteger Have the same syntax as padding. * Native support of dynamic /minHeight, minWidth, maxHeight, maxWidth/ minWidth: anIntegerOrBlock actually any object that implements brickValue: maxHeight: anIntegerOrBlock minHeight: [ : brick | brick label width * 2 ]. minHeight: 200. maxWidth: [ self height / 2 ]. maxWidth: 100. * Native support of /z-index/, so we don't rely on subbricks' order any more if one brick should be drawn above/below others. Works the same as css one. zIndex: 2. default value is 1 * Native support of /floating /bricks. Floating bricks don't influence on any other neighbour bricks in layout. floating: aSymbol floating: #right. top right brick's corner matches top right parent's corner + corresponding paddings and margins floating: #center. will be in the center of the parent and doesn't care about other subbricks Example use case is scroll bar in spotter - it has floating: #right and zIndex: 2 so it appears above all list elements. (+ some margins to
Re: [Pharo-dev] choose event in Bern on March 31: alain plantec on Bloc + working session on Pharo IDE
Nice :) Doru On Mon, Mar 23, 2015 at 11:11 PM, Max Leske maxle...@gmail.com wrote: Cool! I’m in! On 23 Mar 2015, at 22:37, Tudor Girba tu...@tudorgirba.com wrote: Hi, On March 31, we will have a one day of Pharo in Bern: 10:15 - 11:00 Talk by Alain Plantec on Bloc: Reinventing Morphic Registration: https://www.eventbrite.com/e/bloc-reinventing-morphic-choose-talk-tickets-5790681083 11:00 - 17:00 Working session on the Pharo IDE Registration: https://www.eventbrite.com/e/pharo-ide-choose-working-session-tickets-16283404100 The event will be held at the Software Composition Group: Schützenmattstrasse 14, Room 107, Bern The event is sponsored by CHOOSE a subgroup of the Swiss Informatics Society and hosted by the Software Composition Group at the University of Bern. They are primarily organized for CHOOSE and SI members, but the events are open for other students and professionals as well. Cheers, Doru -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] choose event in Bern on March 31: alain plantec on Bloc + working session on Pharo IDE
Cool! I’m in! On 23 Mar 2015, at 22:37, Tudor Girba tu...@tudorgirba.com wrote: Hi, On March 31, we will have a one day of Pharo in Bern: 10:15 - 11:00 Talk by Alain Plantec on Bloc: Reinventing Morphic Registration: https://www.eventbrite.com/e/bloc-reinventing-morphic-choose-talk-tickets-5790681083 https://www.eventbrite.com/e/bloc-reinventing-morphic-choose-talk-tickets-5790681083 11:00 - 17:00 Working session on the Pharo IDE Registration: https://www.eventbrite.com/e/pharo-ide-choose-working-session-tickets-16283404100 https://www.eventbrite.com/e/pharo-ide-choose-working-session-tickets-16283404100 The event will be held at the Software Composition Group: Schützenmattstrasse 14, Room 107, Bern The event is sponsored by CHOOSE a subgroup of the Swiss Informatics Society and hosted by the Software Composition Group at the University of Bern. They are primarily organized for CHOOSE and SI members, but the events are open for other students and professionals as well. Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com/ Every thing has its own flow
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
On 23 Mar 2015, at 17:38, Dale Henrichs dale.henri...@gemtalksystems.com wrote: I don't need zeroconf for my Pharo1.1 app, either. Alternate download methods would be fine. I continue to support Metacello on all of the older versions of Pharo and I do use zeroconf there, but if there is an alternate download mechanism then I can use that for testing … Download will be available eternally: http://files.pharo.org/image/ http://files.pharo.org/image/ http://files.pharo.org/vm/ http://files.pharo.org/vm/ Marcus
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
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.henri...@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
Re: [Pharo-dev] GLMBrick whats next?
Hi, Sorry if my reply will be too long, but I tried to summarise our experience with Morphic/Brick and give some useful feedback or even provide ideas. Who wants will read :) Brick is not a thin layer anymore. It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born out of need. Spotter is completely built using Brick and Rubric. No morphs are used at all (except Rubric of course). All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from original Morph only Canvas (without drawing) and MorphicEvents. Everything else was rewritten from scratch. During some period of time Brick was able to render itself on Athens canvas, but we dropped it because of Font issues in athens. Spotter is not the only tool written using Brick, GLMPager - a pane pager in GT-Inspector, GT-Playground and GT-Debugger is also completely done using Brick. Almost all tab labels and tab selector in GT tools are Bricks. I could say that we collected quite some experience building it. Now I would like to enumerate features of UI framework we used to solve encountered problems. - Local bound coordinates. Nothing to say more here :) It's somehow obvious to have. - Detects graph of Bricks that should be invalidated when Brick triggers invalidation. So there is no need to invalidate the whole graph. - For example if Brick fills parent it means that it doesn't depend on children (simple and most common situation). So if any child triggers invalidation there is no need to invalidate parent as it doesn't depend on them. The same works in reversed way. - Build graph separately for each dimension: width and height. If only height of Brick was changed and children depend only on width, there is no need to invalidate them = x2 faster. - Invalidate resizing and re layouting separately. If there is no need to reposition bricks when size changes we just skip it. - Link subbricks in a DoubleLinked list. So subbrickAfter and subbrickBefore could be done in O(1). Morphic does it in O(n). It iterates over the whole submorphs collection of the owner finds index if current morph and then returns submorphs at: index +/-1. submorphAfter is used when morphic tries to detect which morph should take focus. Take a look at: MorphnextMorphWantingFocus. It iterates over owner's subbricks and for each asks submorphAfter (O(n)) - resulting time O(n^2)! That is why opening a window with a lot of submorphs takes so many time, especially system browser for big classes. - Native support of *paddings* with css-like syntax: padding: anArrayOrInteger paddingTop: anInteger paddingRight: anInteger paddingBottom: anInteger paddingLeft: anInteger padding: 10. top, right, bottom, left padding are 10px padding: #(10 20). top, bottom padding 10px. left, right padding 20px padding: #(10 20 30). top 10px. left, right 20px. bottom 30px padding: #(10 20 30 40). top 10px, right 20px, bottom 30px, left 40px - Native support of *margins* with css-like syntax: margin: anArrayOrInteger marginTop: anInteger marginRight: anInteger marginBottom: anInteger marginLeft: anInteger Have the same syntax as padding. - Native support of dynamic *minHeight, minWidth, maxHeight, maxWidth* minWidth: anIntegerOrBlock actually any object that implements brickValue: maxHeight: anIntegerOrBlock minHeight: [ : brick | brick label width * 2 ]. minHeight: 200. maxWidth: [ self height / 2 ]. maxWidth: 100. - Native support of *z-index*, so we don't rely on subbricks' order any more if one brick should be drawn above/below others. Works the same as css one. zIndex: 2. default value is 1 - Native support of *floating *bricks. Floating bricks don't influence on any other neighbour bricks in layout. floating: aSymbol floating: #right. top right brick's corner matches top right parent's corner + corresponding paddings and margins floating: #center. will be in the center of the parent and doesn't care about other subbricks Example use case is scroll bar in spotter - it has floating: #right and zIndex: 2 so it appears above all list elements. (+ some margins to make it fancy). - Native support of horizontal and vertical *aligning*. hAlign: aSymbol vAlign: aSymbol hAlign: #right. vAlign: #center. - Horizontal and vertical *shrinking* to fit children. It is possible to have in one brick two subbricks where one shrink wraps and other fills parent. hShrinkWrap. vShrinkWrap. - Horizontal and vertical *filling* with support of percents and min/max height/width. If in brick one child shrink wraps width (or have static width) and other fills 100% of parent's width, filling one will take only available space left by shrinking (or static) brick. hSpaceFill: aFloat - fills aFloat percents of parent's width hSpaceFill. - alias for 100 percents. vSpaceFill: aFloat - fills aFloat percents of
Re: [Pharo-dev] [vwnc] The Grapher charting engine
Hi! If you're heading to make Roassal the best visualizing engine of the Universe then what are your intentions with connecting it to the outer world ? This is a rather broad question :-) While our visualizations are meant to run in a standard Smalltalk environment, they are exportable to HTML. Interaction are also preserved. Here are two simple examples: https://dl.dropboxusercontent.com/u/31543901/TMP/memoryBlueprintExample.html https://dl.dropboxusercontent.com/u/31543901/TMP/memoryBlueprintExample.html https://dl.dropboxusercontent.com/u/31543901/online/WebReport/seisms.html https://dl.dropboxusercontent.com/u/31543901/online/WebReport/seisms.html And a larger and more complex example is in the file https://dl.dropboxusercontent.com/u/31543901/TMP/ExampleReport.zip https://dl.dropboxusercontent.com/u/31543901/TMP/ExampleReport.zip check the file Example.pillar.html Will it remain a multiplatform toolbox ? Or are you heading towards a BI desktop or Web app ? Roassal will remain closely linked to Smalltalk (VisualWorks Pharo). Cheers, Alexandre Regards, Maarten MOSTERT 28 Av Alphonse Denis 83400 Hyères, France +33 676411296 http://stakepoint.com/ http://stakepoint.com/ Alexandre Bergel alexandre.ber...@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: 855A292C-DE42-4FF5-83ED-49477CDAA250.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 http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. 855A292C-DE42-4FF5-83ED-49477CDAA250.png
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
On 23 Mar 2015, at 17:43, Marcus Denker marcus.den...@inria.fr wrote: On 23 Mar 2015, at 17:38, Dale Henrichs dale.henri...@gemtalksystems.com mailto:dale.henri...@gemtalksystems.com wrote: I don't need zeroconf for my Pharo1.1 app, either. Alternate download methods would be fine. I continue to support Metacello on all of the older versions of Pharo and I do use zeroconf there, but if there is an alternate download mechanism then I can use that for testing … Download will be available eternally: http://files.pharo.org/image/ http://files.pharo.org/image/ http://files.pharo.org/vm/ http://files.pharo.org/vm/ The thing is that get.pharo.org http://get.pharo.org/ is more than a download. People will expect that it *works*. And we can not (we really can not) support all versions of Pharo. E.g. Spur. Soon we will have a VM that can not run old images. If we keep get.pharo.org http://get.pharo.org/ for 1.4, people expect it to work. And we will have to provide a VM for the old version. Then at some point, this VM will not work anymore on the then current linux. Then people expect us to fix that. Just downloads is a different thing: this is an archive, use it at your own risk. Marcus
Re: [Pharo-dev] [Moose-dev] Re: [Pharo-users] loading Glamour in Pharo 4
On 23-03-15 20:47, Johan Fabry wrote:
I think it is pretty telling that 2 different persons basically had
the same issue in 3 days. Should this issue be considered as something
to have fixed for the Pharo 4 release?
That would be nice. Do we know how it should be fixed?
It is something I expect people to run into rather often.
Stephan
On Mar 23, 2015, at 14:53, Andrei Chis chisvasileand...@gmail.com
mailto:chisvasileand...@gmail.com wrote:
There are several tools in Pharo that depend on Glamour.
If you update glamour to the latest version you also need to update
the tools that depend on it.
This script updated everything:
{ { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }.
{ 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }.
{ 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }.
{ 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }.
{ 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }.
{ 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }.
} do: [ :spec |
Gofer new
smalltalkhubUser: spec second project: spec third;
package: spec first;
load ].
ConfigurationOfGToolkitCore loadDevelopment.
If you are interested just in the Roassal presented you could try and
only load the package Glamour-Roassal2-Presentations + Roassal.
However, depending on what changes you might need to also update glamour.
Cheers,
Andrei
On Mon, Mar 23, 2015 at 6:47 PM, Peter Uhnák i.uh...@gmail.com
mailto:i.uh...@gmail.com wrote:
After loading Glamour dev in Pharo 40
~~~
Gofer new
smalltalkhubUser: 'Moose' project: 'Glamour';
package: 'ConfigurationOfGlamour';
load.
(Smalltalk at: #ConfigurationOfGlamour)
perform: #loadDevelopment
~~~
when I try opening Playground I get
AnObsoleteGLMLiveStringBrick(Object)doesNotUnderstand: #textLogic:
And Spotter throws
GLMHintableActionButtonBrick(Object)doesNotUnderstand:
#addUpAction:
Am I missing some extra dependency?
Thanks,
Peter
___
Moose-dev mailing list
moose-...@iam.unibe.ch mailto:moose-...@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Save our in-boxes! http://emailcharter.org ---
Johan Fabry - http://pleiad.cl/~jfabry http://pleiad.cl/%7Ejfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile
___
Moose-dev mailing list
moose-...@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Re: [Pharo-dev] [Moose-dev] Re: [Pharo-users] loading Glamour in Pharo 4
One can load a newer version of monticello to be able to force the loading
of dependent configurations.
Still this would not fix the underlying issue: one cannot update a library
from the system without also updating the tools that depend on it.
For example, if morphic would be loaded through a configuration you could
not load the latest version of morphic without also loading the latest
version of all the tools.
The best solution could be to not depend on glamour #development unless
really needed.
Cheers,
Andrei
On Mon, Mar 23, 2015 at 9:06 PM, stephan step...@stack.nl wrote:
On 23-03-15 20:47, Johan Fabry wrote:
I think it is pretty telling that 2 different persons basically had the
same issue in 3 days. Should this issue be considered as something to have
fixed for the Pharo 4 release?
That would be nice. Do we know how it should be fixed?
It is something I expect people to run into rather often.
Stephan
On Mar 23, 2015, at 14:53, Andrei Chis chisvasileand...@gmail.com
wrote:
There are several tools in Pharo that depend on Glamour.
If you update glamour to the latest version you also need to update the
tools that depend on it.
This script updated everything:
{ { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }.
{ 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }.
{ 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }.
{ 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }.
{ 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }.
{ 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }.
} do: [ :spec |
Gofer new
smalltalkhubUser: spec second project: spec third;
package: spec first;
load ].
ConfigurationOfGToolkitCore loadDevelopment.
If you are interested just in the Roassal presented you could try and
only load the package Glamour-Roassal2-Presentations + Roassal.
However, depending on what changes you might need to also update glamour.
Cheers,
Andrei
On Mon, Mar 23, 2015 at 6:47 PM, Peter Uhnák i.uh...@gmail.com wrote:
After loading Glamour dev in Pharo 40
~~~
Gofer new
smalltalkhubUser: 'Moose' project: 'Glamour';
package: 'ConfigurationOfGlamour';
load.
(Smalltalk at: #ConfigurationOfGlamour)
perform: #loadDevelopment
~~~
when I try opening Playground I get
AnObsoleteGLMLiveStringBrick(Object)doesNotUnderstand: #textLogic:
And Spotter throws
GLMHintableActionButtonBrick(Object)doesNotUnderstand: #addUpAction:
Am I missing some extra dependency?
Thanks,
Peter
___
Moose-dev mailing list
moose-...@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Save our in-boxes! http://emailcharter.org ---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile
___
Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
Yes… I was asking to see how can we proceed, because we cannot continue distributing as now. In the course of the conversation I found a solution that will please everyone… and will allow us to keep giving also zeroconf scripts without needing to download source versions for all (which was, in fact, the problem I was trying to fix). It will require some file reorganisation and the concept of “blessed vm”: a version we will distribute with the image version (it will be a vm for pharo1, one for pharo2, etc… each one with their sources… And yes… that means a bit more work to configure if you have multiple image-versions… but in the long way is the only way we can ensure how an image and a vm works together :) So, no need to continue arguing :) cheers, Esteban On 23 Mar 2015, at 18:12, Dale Henrichs dale.henri...@gemtalksystems.com wrote: Marcus, This makes perfect sense to me ... If zeroconf is only used for the supported versions of Pharo that is perfectly fair ... When a version goes off of zeroconf support it would be convenient if one could find the appropriate eternal download urls for the image/vm otherwise how would I know? Keep in mind, that I use zeroconf to download for travis-based tests and I don't have a physical disk to look at ... and it is possible that I won't know that a particular version has gone off of zeroncof support until my build fails ... so it would be _convenient_ to be able to lookup the image/vm combo that I need to use... Dale The thing is that get.pharo.org http://get.pharo.org/ is more than a download. People will expect that it *works*. And we can not (we really can not) support all versions of Pharo. E.g. Spur. Soon we will have a VM that can not run old images. If we keep get.pharo.org http://get.pharo.org/ for 1.4, people expect it to work. And we will have to provide a VM for the old version. Then at some point, this VM will not work anymore on the then current linux. Then people expect us to fix that. Just downloads is a different thing: this is an archive, use it at your own risk. Marcus
Re: [Pharo-dev] Suggestions menu entry not in GTPlayground Any reason why?
Rename temp, extract temp, extract method (requires class to be supplied) On Mar 22, 2015 11:01 AM, Tudor Girba tu...@tudorgirba.com wrote: Because I haven't seen a suggestion for the Workspace. Could you give me concrete examples of suggestions that work in the Workspace? Doru On Sun, Mar 22, 2015 at 10:14 AM, p...@highoctane.be p...@highoctane.be wrote: Or how to get them back? TIA Phil -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] GLMBrick whats next?
Thanks for this reply, Alex. Doru On Mon, Mar 23, 2015 at 8:54 PM, Aliaksei Syrel alex.sy...@gmail.com wrote: Hi, Sorry if my reply will be too long, but I tried to summarise our experience with Morphic/Brick and give some useful feedback or even provide ideas. Who wants will read :) Brick is not a thin layer anymore. It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born out of need. Spotter is completely built using Brick and Rubric. No morphs are used at all (except Rubric of course). All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from original Morph only Canvas (without drawing) and MorphicEvents. Everything else was rewritten from scratch. During some period of time Brick was able to render itself on Athens canvas, but we dropped it because of Font issues in athens. Spotter is not the only tool written using Brick, GLMPager - a pane pager in GT-Inspector, GT-Playground and GT-Debugger is also completely done using Brick. Almost all tab labels and tab selector in GT tools are Bricks. I could say that we collected quite some experience building it. Now I would like to enumerate features of UI framework we used to solve encountered problems. - Local bound coordinates. Nothing to say more here :) It's somehow obvious to have. - Detects graph of Bricks that should be invalidated when Brick triggers invalidation. So there is no need to invalidate the whole graph. - For example if Brick fills parent it means that it doesn't depend on children (simple and most common situation). So if any child triggers invalidation there is no need to invalidate parent as it doesn't depend on them. The same works in reversed way. - Build graph separately for each dimension: width and height. If only height of Brick was changed and children depend only on width, there is no need to invalidate them = x2 faster. - Invalidate resizing and re layouting separately. If there is no need to reposition bricks when size changes we just skip it. - Link subbricks in a DoubleLinked list. So subbrickAfter and subbrickBefore could be done in O(1). Morphic does it in O(n). It iterates over the whole submorphs collection of the owner finds index if current morph and then returns submorphs at: index +/-1. submorphAfter is used when morphic tries to detect which morph should take focus. Take a look at: MorphnextMorphWantingFocus. It iterates over owner's subbricks and for each asks submorphAfter (O(n)) - resulting time O(n^2)! That is why opening a window with a lot of submorphs takes so many time, especially system browser for big classes. - Native support of *paddings* with css-like syntax: padding: anArrayOrInteger paddingTop: anInteger paddingRight: anInteger paddingBottom: anInteger paddingLeft: anInteger padding: 10. top, right, bottom, left padding are 10px padding: #(10 20). top, bottom padding 10px. left, right padding 20px padding: #(10 20 30). top 10px. left, right 20px. bottom 30px padding: #(10 20 30 40). top 10px, right 20px, bottom 30px, left 40px - Native support of *margins* with css-like syntax: margin: anArrayOrInteger marginTop: anInteger marginRight: anInteger marginBottom: anInteger marginLeft: anInteger Have the same syntax as padding. - Native support of dynamic *minHeight, minWidth, maxHeight, maxWidth* minWidth: anIntegerOrBlock actually any object that implements brickValue: maxHeight: anIntegerOrBlock minHeight: [ : brick | brick label width * 2 ]. minHeight: 200. maxWidth: [ self height / 2 ]. maxWidth: 100. - Native support of *z-index*, so we don't rely on subbricks' order any more if one brick should be drawn above/below others. Works the same as css one. zIndex: 2. default value is 1 - Native support of *floating *bricks. Floating bricks don't influence on any other neighbour bricks in layout. floating: aSymbol floating: #right. top right brick's corner matches top right parent's corner + corresponding paddings and margins floating: #center. will be in the center of the parent and doesn't care about other subbricks Example use case is scroll bar in spotter - it has floating: #right and zIndex: 2 so it appears above all list elements. (+ some margins to make it fancy). - Native support of horizontal and vertical *aligning*. hAlign: aSymbol vAlign: aSymbol hAlign: #right. vAlign: #center. - Horizontal and vertical *shrinking* to fit children. It is possible to have in one brick two subbricks where one shrink wraps and other fills parent. hShrinkWrap. vShrinkWrap. - Horizontal and vertical *filling* with support of percents and min/max height/width. If in brick one child shrink wraps width (or have static width) and other fills 100% of parent's width, filling one will take only
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
On 22 Mar 2015, at 22:56, Dale Henrichs dale.henri...@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
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
On 23 Mar 2015, at 09:06, Esteban Lorenzano esteba...@gmail.com wrote: On 22 Mar 2015, at 22:56, Dale Henrichs dale.henri...@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
[Pharo-dev] [pharo-project/pharo-core] d94d14: 40576
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d94d140065ff6e75a3a5d56d0c3882df35bd3094 https://github.com/pharo-project/pharo-core/commit/d94d140065ff6e75a3a5d56d0c3882df35bd3094 Author: Jenkins Build Server bo...@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
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
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 steph...@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.
[Pharo-dev] Old Pharo Mac VM on pharo.org
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
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
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.
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
On 23 Mar 2015, at 09:17, Tudor Girba tu...@tudorgirba.com wrote: Hi, On Mon, Mar 23, 2015 at 9:16 AM, Max Leske maxle...@gmail.com mailto:maxle...@gmail.com wrote: On 23 Mar 2015, at 09:06, Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com wrote: On 22 Mar 2015, at 22:56, Dale Henrichs dale.henri...@gemtalksystems.com mailto:dale.henri...@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
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
Hi, On Mon, Mar 23, 2015 at 9:16 AM, Max Leske maxle...@gmail.com wrote: On 23 Mar 2015, at 09:06, Esteban Lorenzano esteba...@gmail.com wrote: On 22 Mar 2015, at 22:56, Dale Henrichs dale.henri...@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
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
On 22 Mar 2015, at 23:41, Sean P. DeNigris s...@clipperadams.com wrote: 15086 Ctrl + Arrow Behaviour which disabled horizontal mouse scrolling, which I've come to depend on in my projects Was this not a side effect of a change *you* did? Marcus
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
On 22 Mar 2015, at 22:56, Dale Henrichs dale.henri...@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
Re: [Pharo-dev] GLMBrick whats next?
2015-01-06 10:55 GMT+01:00 Nicolai Hess nicolaih...@web.de: Thank you for this explanation 2014-12-31 23:47 GMT+01:00 Aliaksei Syrel alex.sy...@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 tu...@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 tu...@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 steph...@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
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40576 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 91064b: 40578
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 91064b690c36f70c2984272991ade982bccabd30 https://github.com/pharo-project/pharo-core/commit/91064b690c36f70c2984272991ade982bccabd30 Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-03-23 (Mon, 23 Mar 2015) Changed paths: M GT-Inspector.package/GTExample.class/instance/accessing/title_.st M GT-Inspector.package/GTExampleExtractionStrategy.class/instance/example creation/createExampleForExamplePragma_from_.st A GT-InspectorExtensions-Core.package/extension/Character/class/exampleA.st A GT-InspectorExtensions-Core.package/extension/Character/class/exampleSpace.st A GT-InspectorExtensions-Core.package/extension/Class/class/exampleClass.st A GT-InspectorExtensions-Core.package/extension/Collection/class/exampleEmptyArray.st A GT-InspectorExtensions-Core.package/extension/Collection/class/exampleOrderedCollectionWithOneElement.st A GT-InspectorExtensions-Core.package/extension/Date/class/exampleToday.st A GT-InspectorExtensions-Core.package/extension/DateAndTime/class/exampleNow.st A GT-InspectorExtensions-Core.package/extension/Duration/class/exampleOneDay.st A GT-InspectorExtensions-Core.package/extension/Duration/class/exampleOneHour.st A GT-InspectorExtensions-Core.package/extension/Duration/class/exampleOneMinute.st A GT-InspectorExtensions-Core.package/extension/GLMBrowser/class/exampleBasic.st A GT-InspectorExtensions-Core.package/extension/GLMPane/class/exampleBasic.st A GT-InspectorExtensions-Core.package/extension/GLMPresentation/class/exampleBasic.st A GT-InspectorExtensions-Core.package/extension/GLMSystemWindow/class/exampleEmptyBrowser.st A GT-InspectorExtensions-Core.package/extension/GlobalVariable/class/exampleSmalltalk.st A GT-InspectorExtensions-Core.package/extension/Integer/class/example42.st A GT-InspectorExtensions-Core.package/extension/Object/class/exampleBasic.st A GT-InspectorExtensions-Core.package/extension/RBMessageNode/class/exampleAddition.st M GT-InspectorExtensions-Core.package/extension/RBProgramNode/instance/gtInspectorSourceCodeIn_.st A GT-InspectorExtensions-Core.package/extension/Symbol/class/exampleFourtyTwo.st A GT-InspectorExtensions-Core.package/extension/Time/class/exampleNow.st A GT-Playground.package/GTPlayBook.class/class/accessing-defaults/defaultCacheDirectory.st A GT-Playground.package/GTPlayBook.class/class/accessing-defaults/defaultCustomDirectory.st A GT-Playground.package/GTPlayBook.class/class/accessing-defaults/defaultDirectory.st M GT-Playground.package/GTPlayBook.class/class/accessing/cacheDirectory.st M GT-Playground.package/GTPlayBook.class/class/accessing/cacheDirectory_.st A GT-Playground.package/GTPlayBook.class/class/accessing/customDirectory.st A GT-Playground.package/GTPlayBook.class/class/accessing/customDirectory_.st R GT-Playground.package/GTPlayBook.class/class/accessing/defaultCacheDirectory.st A GT-Playground.package/GTPlayBook.class/class/examples/gtExampleEmpty.st A GT-Playground.package/GTPlayBook.class/class/initializing/initialize.st A GT-Playground.package/GTPlayBook.class/class/initializing/startUp.st A GT-Playground.package/GTPlayBook.class/class/initializing/startUp_.st A GT-Playground.package/GTPlayBook.class/class/private/basicEnsureDistinctDirectory_.st A GT-Playground.package/GTPlayBook.class/class/private/cleanUp.st A GT-Playground.package/GTPlayBook.class/class/private/ensureDistinctDirectory_.st A GT-Playground.package/GTPlayBook.class/class/private/reset.st A GT-Playground.package/GTPlayBook.class/class/private/resetDirectories.st R GT-Playground.package/GTPlayBook.class/class/protocol/cleanUp.st R GT-Playground.package/GTPlayBook.class/class/protocol/reset.st M GT-Playground.package/GTPlayBook.class/definition.st A GT-Playground.package/GTPlayBook.class/instance/accessing-defaults/defaultPages.st A GT-Playground.package/GTPlayBook.class/instance/accessing-defaults/defaultPagesLimit.st A GT-Playground.package/GTPlayBook.class/instance/accessing-dynamic/allFiles.st A GT-Playground.package/GTPlayBook.class/instance/accessing-dynamic/allFilesSorted.st A GT-Playground.package/GTPlayBook.class/instance/accessing-dynamic/files.st A GT-Playground.package/GTPlayBook.class/instance/accessing-dynamic/pagesSorted.st R GT-Playground.package/GTPlayBook.class/instance/accessing/addPageIfInteresting_.st R GT-Playground.package/GTPlayBook.class/instance/accessing/addPage_.st R GT-Playground.package/GTPlayBook.class/instance/accessing/initialize.st M GT-Playground.package/GTPlayBook.class/instance/accessing/pages.st A GT-Playground.package/GTPlayBook.class/instance/accessing/pagesLimit.st A GT-Playground.package/GTPlayBook.class/instance/accessing/pagesLimit_.st R
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40578 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] [Moose-dev] Re: [Pharo-users] loading Glamour in Pharo 4
Hi,
After the release of Pharo 4, we will release Moose with all stable
configurations. This should work afterwards.
Then we will move the development of Moose to Pharo 5.
Cheers,
Doru
On Mon, Mar 23, 2015 at 9:10 PM, Andrei Chis chisvasileand...@gmail.com
wrote:
One can load a newer version of monticello to be able to force the loading
of dependent configurations.
Still this would not fix the underlying issue: one cannot update a library
from the system without also updating the tools that depend on it.
For example, if morphic would be loaded through a configuration you could
not load the latest version of morphic without also loading the latest
version of all the tools.
The best solution could be to not depend on glamour #development unless
really needed.
Cheers,
Andrei
On Mon, Mar 23, 2015 at 9:06 PM, stephan step...@stack.nl wrote:
On 23-03-15 20:47, Johan Fabry wrote:
I think it is pretty telling that 2 different persons basically had the
same issue in 3 days. Should this issue be considered as something to have
fixed for the Pharo 4 release?
That would be nice. Do we know how it should be fixed?
It is something I expect people to run into rather often.
Stephan
On Mar 23, 2015, at 14:53, Andrei Chis chisvasileand...@gmail.com
wrote:
There are several tools in Pharo that depend on Glamour.
If you update glamour to the latest version you also need to update the
tools that depend on it.
This script updated everything:
{ { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }.
{ 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }.
{ 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }.
{ 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }.
{ 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }.
{ 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }.
} do: [ :spec |
Gofer new
smalltalkhubUser: spec second project: spec third;
package: spec first;
load ].
ConfigurationOfGToolkitCore loadDevelopment.
If you are interested just in the Roassal presented you could try and
only load the package Glamour-Roassal2-Presentations + Roassal.
However, depending on what changes you might need to also update glamour.
Cheers,
Andrei
On Mon, Mar 23, 2015 at 6:47 PM, Peter Uhnák i.uh...@gmail.com wrote:
After loading Glamour dev in Pharo 40
~~~
Gofer new
smalltalkhubUser: 'Moose' project: 'Glamour';
package: 'ConfigurationOfGlamour';
load.
(Smalltalk at: #ConfigurationOfGlamour)
perform: #loadDevelopment
~~~
when I try opening Playground I get
AnObsoleteGLMLiveStringBrick(Object)doesNotUnderstand: #textLogic:
And Spotter throws
GLMHintableActionButtonBrick(Object)doesNotUnderstand: #addUpAction:
Am I missing some extra dependency?
Thanks,
Peter
___
Moose-dev mailing list
moose-...@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Save our in-boxes! http://emailcharter.org ---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile
___
Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
Every thing has its own flow
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
I do not see how discussing the fact that we could via a trick (I failed to find it) navigate methods in the same name in other classes without having to click on the class, catgeory and methods would have solve the problem that I introduced a bug while trying to add this extra behavior? Then you do not understand my point: I integrated the scroll fix from jan because a change was breaking their flow. And ??? How can I possibly know that it would break your fixes that apparently broke their flow. You see what I mean? I could also simply ignore issue that I do not know or contributed too but it would slow down the process, isn't? Stef stepharo wrote Could you stop crying because this is a bit boring? Could you address my policy suggestion instead of crying? ;) It would've taken the same amount of time to answer my message productively instead of lawyering it by pointing out the one example out of three that you could turn back around on me and ignoring everything else. stepharo wrote So instead of crying help. I've participated in fixing hundreds of issues, and that's just on the new issue tracker. Is that a reasonable comment? - Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814344.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Morphs becoming unresponsive
WW, Thanks! El lun., 23 de mar. de 2015 a la(s) 9:29 p. m., stepharo steph...@free.fr escribió: + 1 Thanks Henrik!!! Le 23/3/15 16:17, Ben Coman a écrit : On Mon, Mar 23, 2015 at 9:06 PM, Henrik Johansen henrik.s.johan...@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
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
Sean I have no problem to discuss. Now I had 35 methods in 35 different classes to slightly changes and we should be able to avoid to select and click all the times. Stef Le 23/3/15 18:48, Sean P. DeNigris a écrit : Marcus Denker-4 wrote 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 NB: I said IDE UI workflow changes, which seem to be a relatively small percentage of the overall changes, but seem to cause the most disruption. I know that you guys had a rough time trying to make progress before the fork. I understand that Pharo has a big dream and that there will be worthwhile pain getting there. If we can't agree to discuss the most high-risk, low frequency changes, how about at least a dev list notification about those particular changes? - Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814460.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [pharo-project/pharo-core] 395d15: 40577
On 23 Mar 2015, at 18:35, Andrei Chis chisvasileand...@gmail.com mailto:chisvasileand...@gmail.com wrote: Can you notify me when a slice related to rubric is integrated. I need to merge it back to the Rubric repo. Yes…. I wanted to commit this but I have no rights. (this external repo stuff is really complex and slow) Too much I would say. Cheers, Andrei On Mon, Mar 23, 2015 at 4:28 PM, GitHub nore...@github.com mailto:nore...@github.com wrote: Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 395d1598748873bf4a4d1c194585e53f2821216c https://github.com/pharo-project/pharo-core/commit/395d1598748873bf4a4d1c194585e53f2821216c Author: Jenkins Build Server bo...@pharo-project.org mailto:bo...@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 http://script576.st/ A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script577.st http://script577.st/ R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40576.st http://update40576.st/ A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40577.st http://update40577.st/ M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/build.st http://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
Re: [Pharo-dev] Morphs becoming unresponsive
+ 1 Thanks Henrik!!! Le 23/3/15 16:17, Ben Coman a écrit : On Mon, Mar 23, 2015 at 9:06 PM, Henrik Johansen henrik.s.johan...@veloxit.no mailto:henrik.s.johan...@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
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
Why do you start fun discussion when I'm not connected :). I like the idea of the distinction between archive and supported. I like archives :)
Re: [Pharo-dev] GLMBrick whats next?
---BeginMessage--- thanks a lot for these explanations. yep! very promising :) I would love to see all these improvements implemented in Bloc. Le 23 mars 2015 à 20:54, Aliaksei Syrel alex.sy...@gmail.com a écrit : What we really want to have in Bloc is an easy way to detect that user clicked outside of specific morph. I will investigate this Cheers Alain ---End Message---
[Pharo-dev] choose event in Bern on March 31: alain plantec on Bloc + working session on Pharo IDE
Hi, On March 31, we will have a one day of Pharo in Bern: 10:15 - 11:00 Talk by Alain Plantec on Bloc: Reinventing Morphic Registration: https://www.eventbrite.com/e/bloc-reinventing-morphic-choose-talk-tickets-5790681083 11:00 - 17:00 Working session on the Pharo IDE Registration: https://www.eventbrite.com/e/pharo-ide-choose-working-session-tickets-16283404100 The event will be held at the Software Composition Group: Schützenmattstrasse 14, Room 107, Bern The event is sponsored by CHOOSE a subgroup of the Swiss Informatics Society and hosted by the Software Composition Group at the University of Bern. They are primarily organized for CHOOSE and SI members, but the events are open for other students and professionals as well. Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [pharo-project/pharo-core] 395d15: 40577
Andrei proposed to move every package that is not under a team in PharoExtras. I think that would make sense, but we did not have time to do it for Pharo 4. Cheers, Doru On Mon, Mar 23, 2015 at 9:29 PM, stepharo steph...@free.fr wrote: On 23 Mar 2015, at 18:35, Andrei Chis chisvasileand...@gmail.com wrote: Can you notify me when a slice related to rubric is integrated. I need to merge it back to the Rubric repo. Yes…. I wanted to commit this but I have no rights. (this external repo stuff is really complex and slow) Too much I would say. Cheers, Andrei On Mon, Mar 23, 2015 at 4:28 PM, GitHub nore...@github.com wrote: Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 395d1598748873bf4a4d1c194585e53f2821216c https://github.com/pharo-project/pharo-core/commit/395d1598748873bf4a4d1c194585e53f2821216c Author: Jenkins Build Server bo...@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 -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
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... Such a prejudiced mischaracterisation! Marcus, listen to yourself. Please, look into your heart and rethink this. Yes, sorry... that was formulated far too strong... :-) But if I look back I sometimes think that it would have been better to try and fail than to get convinced in a Mailinglist discussion to not even start... Marcus
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
On 23 Mar 2015, at 17:16, Dale Henrichs dale.henri...@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
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
Did I ask for support? I asked to be able to continue to be able to continue to download older versions of Pharo. If you say no, then you say no. If you intend to cutoff the downloads for older versions of Pharo, then I would ask that you give me a couple of months warning. If you say no, then you say no. The original question was ... Is anyone using zerconf for Pharo2.0 and I answered your question... I'm not sure that it costs you anything (other than goodwill) by allowing folks to download older versions of Pharo ... Supporting older versions of Pharo is another kettle of fish ... Dale On 3/23/15 9:20 AM, Marcus Denker wrote: On 23 Mar 2015, at 17:16, Dale Henrichs dale.henri...@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
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
I don't need zeroconf for my Pharo1.1 app, either. Alternate download methods would be fine. I continue to support Metacello on all of the older versions of Pharo and I do use zeroconf there, but if there is an alternate download mechanism then I can use that for testing ... Dale On 3/23/15 1:16 AM, Max Leske wrote: On 23 Mar 2015, at 09:06, Esteban Lorenzano esteba...@gmail.com wrote: On 22 Mar 2015, at 22:56, Dale Henrichs dale.henri...@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
Re: [Pharo-dev] [pharo-project/pharo-core] 395d15: 40577
Can you notify me when a slice related to rubric is integrated. I need to merge it back to the Rubric repo. Cheers, Andrei On Mon, Mar 23, 2015 at 4:28 PM, GitHub nore...@github.com wrote: Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 395d1598748873bf4a4d1c194585e53f2821216c https://github.com/pharo-project/pharo-core/commit/395d1598748873bf4a4d1c194585e53f2821216c Author: Jenkins Build Server bo...@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
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
On Mon, Mar 23, 2015 at 7:19 AM, Marcus Denker marcus.den...@inria.fr wrote: On Mon, Mar 23, 2015 at 2:33 PM, Sean P. DeNigris s...@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... Such a prejudiced mischaracterisation! Marcus, listen to yourself. Please, look into your heart and rethink this. Keep in mind that you can find a reason to *not* do something for *anything*. Marcus -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de -- best, Eliot
Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?
Marcus, This makes perfect sense to me ... If zeroconf is only used for the supported versions of Pharo that is perfectly fair ... When a version goes off of zeroconf support it would be convenient if one could find the appropriate eternal download urls for the image/vm otherwise how would I know? Keep in mind, that I use zeroconf to download for travis-based tests and I don't have a physical disk to look at ... and it is possible that I won't know that a particular version has gone off of zeroncof support until my build fails ... so it would be _convenient_ to be able to lookup the image/vm combo that I need to use... Dale The thing is that get.pharo.org http://get.pharo.org is more than a download. People will expect that it *works*. And we can not (we really can not) support all versions of Pharo. E.g. Spur. Soon we will have a VM that can not run old images. If we keep get.pharo.org http://get.pharo.org for 1.4, people expect it to work. And we will have to provide a VM for the old version. Then at some point, this VM will not work anymore on the then current linux. Then people expect us to fix that. Just downloads is a different thing: this is an archive, use it at your own risk. Marcus
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
On Mon, Mar 23, 2015 at 10:04 AM, Marcus Denker marcus.den...@inria.fr wrote: 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... Such a prejudiced mischaracterisation! Marcus, listen to yourself. Please, look into your heart and rethink this. Yes, sorry... that was formulated far too strong... :-) But if I look back I sometimes think that it would have been better to try and fail than to get convinced in a Mailinglist discussion to not even start... Yes, I'm sure many, if not all of us know what you mean. But there are naysayers in almost any community /and/ there is a time for caution in almost all software communities. I think Sean's request for careful discussion of UI changes late in the release cycle is sane. We can perhaps all try and be less defensive. But I hope we'll all continue having fun! -- best, Eliot
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
On 23 Mar 2015, at 17:49, Eliot Miranda eliot.mira...@gmail.com wrote: On Mon, Mar 23, 2015 at 7:19 AM, Marcus Denker marcus.den...@inria.fr wrote: On Mon, Mar 23, 2015 at 2:33 PM, Sean P. DeNigris s...@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... Such a prejudiced mischaracterisation! Marcus, listen to yourself. Please, look into your heart and rethink this. Maybe it is a bit too strongly formulated, but certain discussions do tend to contain arguments that Marcus is referring too. I recall a discussion some days ago about #withIndexDo: vs #doWithIndex: where the provisory conclusion was 'we cannot change we'll leave everything like it is' with arguments that referred to history, ANSI and cross-dialect compatibility. And there are many API discussions like that. It must have been a different world 30, 40 years ago when it must have been possible to actually design fundamental API's and have the ability to change it. Pharo exists because we want that back. Keep in mind that you can find a reason to *not* do something for *anything*. Marcus -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de -- best, Eliot
Re: [Pharo-dev] UI Workflows Are Like Snowflakes
Marcus Denker-4 wrote 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 NB: I said IDE UI workflow changes, which seem to be a relatively small percentage of the overall changes, but seem to cause the most disruption. I know that you guys had a rough time trying to make progress before the fork. I understand that Pharo has a big dream and that there will be worthwhile pain getting there. If we can't agree to discuss the most high-risk, low frequency changes, how about at least a dev list notification about those particular changes? - Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814460.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [pharo-project/pharo-core] 395d15: 40577
On 23 Mar 2015, at 18:35, Andrei Chis chisvasileand...@gmail.com wrote: Can you notify me when a slice related to rubric is integrated. I need to merge it back to the Rubric repo. Yes…. I wanted to commit this but I have no rights. (this external repo stuff is really complex and slow) Cheers, Andrei On Mon, Mar 23, 2015 at 4:28 PM, GitHub nore...@github.com mailto:nore...@github.com wrote: Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core https://github.com/pharo-project/pharo-core Commit: 395d1598748873bf4a4d1c194585e53f2821216c https://github.com/pharo-project/pharo-core/commit/395d1598748873bf4a4d1c194585e53f2821216c https://github.com/pharo-project/pharo-core/commit/395d1598748873bf4a4d1c194585e53f2821216c Author: Jenkins Build Server bo...@pharo-project.org mailto:bo...@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 http://script576.st/ A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script577.st http://script577.st/ R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40576.st http://update40576.st/ A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40577.st http://update40577.st/ M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/build.st http://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 https://pharo.fogbugz.com/f/cases/15190 14924 Failing tests: testClassDescriptionRespectsPolymorphismWithTraitDescription https://pharo.fogbugz.com/f/cases/14924 https://pharo.fogbugz.com/f/cases/14924 15189 Extended search vs. Code search https://pharo.fogbugz.com/f/cases/15189 https://pharo.fogbugz.com/f/cases/15189 http://files.pharo.org/image/40/40577.zip http://files.pharo.org/image/40/40577.zip
[Pharo-dev] Unique Mouse Wheel Events
Cross-posted to Pharo dev, Squeak dev, and Squeak VM lists (but Pharo list rejected so I am reposting there separately)... Recently, we discovered on the Pharo dev list that the key combination used to fake wheel events - ctrl + arrowKey - may be a bit too simple. Apparently ctrl+horizontalArrowKey is a standard in-use combo in Linux and Windows, so adding horizontal wheel events broke some users' workflows. So I propose ctrl + alt + shift + cmd + arrowKey. The new combo is: very unlikely to be typed backward-compatible with existing Pharo and Squeak images, which only checks that either cmd or ctrl is pressed frees up ctrl + arrow for our Linux/Windows friends For Pharo, there is: https://github.com/pharo-project/pharo-vm/pull/72 Fogbugz Issue 15209: Mouse Wheel Events Keyboard Clash, with a slice all ready on the image side once the VM patch is integrated. NB: I changed the combo in the VM for Mac OS and OSX. Are these the only two platforms that fake wheel events? I searched a bit but didn't see similar logic for other platforms... - Cheers, Sean -- View this message in context: http://forum.world.st/Unique-Mouse-Wheel-Events-tp4814475.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] choose event in Bern on March 31: alain plantec on Bloc + working session on Pharo IDE
Will the talks be recorded? p.s. please, please, please ;) - Cheers, Sean -- View this message in context: http://forum.world.st/choose-event-in-Bern-on-March-31-alain-plantec-on-Bloc-working-session-on-Pharo-IDE-tp4814547p4814610.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] choose event in Bern on March 31: alain plantec on Bloc + working session on Pharo IDE
fingers crossed. On Mon, Mar 23, 2015 at 10:33 PM, Sean P. DeNigris s...@clipperadams.com wrote: Will the talks be recorded? p.s. please, please, please ;) - Cheers, Sean -- View this message in context: http://forum.world.st/choose-event-in-Bern-on-March-31-alain-plantec-on-Bloc-working-session-on-Pharo-IDE-tp4814547p4814610.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- Bernardo E.C. Sent from a cheap desktop computer in South America.
