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

Re: [Pharo-dev] Update question

by Sean P. DeNigris

kilon.alios wrote > I tried it a few times, and had nothing but problems with it. We have > discussed here several times and from what I have learned there several > technical limitation. I initially had a bad experience as well. I probably didn't give it a fair trial, but also IIRC at that time the image folder was not configurable. Anyway, I had a much different experience with the latest version. I keep it in "Development Mode" (available in the settings) so I have full access to the IDE. <http://forum.world.st/file/n4814762/Screenshot_2015-03-24_09.png> ----- Cheers, Sean -- View this message in context: http://forum.world.st/Update-question-tp4814680p4814762.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 24, 2015

Google Code Shutdown

by Sean P. DeNigris

In case anyone hasn't heard, Google Code will shut down entirely on January 25, 2016. I was following these Smalltalk projects there: magritte-metamodel moose-technology seaside marsonpharo nativeboost metacello squeaksource3 phratch - already on GitHub per Jannik The easiest action seems to be to export to GitHub, for which Google Code even provides a button! I just used it for one of my projects and it was pretty painless. - Sean Cross-posted to ESUG, pharo-dev, squeak-dev, seaside-dev, magritte, metacello ----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 24, 2015

Re: [Pharo-dev] Update question

by Torsten Bergmann

@Norbert: I also use PharoLauncher, this way I can download clean 3.0/4.0 or prepackaged (Moose, Boostrap) images at own will, clone, copy as I like and with a fresh image it is easy to see if code is loading cleanly, ... I have to give up nothing. I can still profit from image development as I can save my image as usual and continue with it later. @Kilon: Integrating PharoLauncher in the standard image would not make sense. Then I use PharoLauncher to download an image with a prepackaged PharoLauncher, ... Â If you mean that it should be the default tool to download when getting Pharo 4.0 or Pharo 3.0 from the download page or from zeroconf then I would agree. Maybe some more help is needed for Pharo newbees then. But I would vote for it as I would download/install Pharo one time on a machine and then choose - download - start the image that I like. Â Gesendet:Â Dienstag, 24. MÃ¤rz 2015 um 11:25 Uhr Von:Â "kilon alios" <kilon.alios(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] Update question I tried it a few times, and had nothing but problems with it. We have discussed here several times and from what I have learned there several technical limitation. Â I am using pharolauncher non stop and wonder why Pharolauncher is not integrated inside Pharo yet. I have added my code inside the configuration browser (Ephestos, Nireas) and Installing my code back in a fresh image is just a two click process. Â On Tue, Mar 24, 2015 at 12:13 PM, Norbert Hartl <norbert(a)hartl.name> wrote:Today I wanted (again) to update my image and it can't find GT packages. So I'm interested how the community deals with that. Do you take fresh downloaded images regularly? Or you do not update? Is it just me? thanks, Norbert Â

March 24, 2015

Which one to use? [WAS: Re: GLMBrick whats next?]

by Esteban Lorenzano

And wellâ¦ I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: - we have Morphic, and itâs upcoming replace, Brick (but Brick is not in the image, so the pain there is less) - we have Spec to support our tooling. - we have Glamour to supportâ¦ well, our tooling too. - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). GTTools team has also stated they would use Bloc is they could/when they can. - We have the old Text Editor - We have Rubric, which was stated to be âold stuffâ and deprecated - We have also the new TxModel which intends to replace both, Text Editor and Rubricâ¦ but it cannot be used right now (or better: It cannot replace none of the previous yet) Soâ¦ which one to use? We, the board, have something clear and some other not so clear yet, for example: - we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) - Spec needs work too - Glamour will be replaced by Brick, so do not use it - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel. So wellâ¦ yes this is a mess. Yes we are aware. No we donât know when things will improve, but *they will*. In the mean time as a Pharo user, I would like to know which one should I use for my projectsâ¦ this is my recommendation: - Do not use âdirectâ Morphic unless doing graphics - Use TxModel and if you cannot, Rubric - Use Brick or Spec, not Glamour (because Brick will replace it soon) And of course, I would help with fixes and reports on everything :) cheers, Esteban > On 24 Mar 2015, at 12:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Nicolai, > > I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :) > > Let's recap. > > Brick was created to support GT. We wanted GT in the image, hence Brick is in the image as part of Glamour. In the meantime, Brick has grown and it's now an almost standalone framework, but it is not yet advisable to use it apps because it will likely change more. > > As Alex says, we do not want to have two competing new projects running in parallel (Brick and Bloc) and fragmenting the effort even more. That is why, for Pharo 5 we want to invest in Bloc. The interesting thing is that while Bloc starts from scratch, Brick already works and has quite some high level widgets and logic built in. Brick is already going in the same direction expected by Bloc, so we will likely have the opportunity of moving Brick on top of Bloc (Alex already did an experiment in this direction). > > Concretely, on March 31 and April 1 (no joke :)), we have a session in Bern where Alain Plantec will join us to look into how to approach this problem concretely. > > All in all, you should see Brick as a pragmatic intermediary step towards removing Morph. I agree that it can be better (what cannot be), but I disagree we should discard GT because of it. > > Cheers, > Doru > > > On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > > > 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>>: > 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 :) > > Hi, > thank you, this is a really great source of information, and it would be heplful > to have this kind of write up somewhere else (not in the mailinglist). > But I did not question why we may need brick or why it is done. > My question was, what are the feature plans, is it just an experiment that > can vanish, so it is better to not use it for the core tools. Or is it meant to be > THE new framework we should gain our focus on. > > > 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. > > This is something I don't understand. As we integrated GT-Tools into the image, Rubric > slipped in as it is need by GT. I asked what is the background, what are the feature plans > and complained about the undocumented core classes, that makes it difficult to see > what changed compared to the old text classes. Alain said he doesn't plan to do further > work on Rubric. > So, WHY don't we replace and migrate the existing classes now and clean it up. It takes so > much resources to maintain both. Every theme change, every change on shortcuts/menus/keymapping, the athens drawing, all has to be double checked - It is so exhausting. > > > No morphs are used at all (except Rubric of course). > > Well, all Bricks ARE morphs, they share the same state and api. > > All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from original Morph only Canvas (without drawing) and MorphicEvents. > > If so, the clean/better way would be to extract those part into a "ProtoMorph" or a "PlainMorph". > and subclass from that once for Brick and again for Morphs. > Now we have Bricks, that are looking like a Morph, but aren't used to be one, and probable doesn't even work if they are used as Morphs. > (Sure this is true for other Morphsubclasses as well, but that does not means it doesn't hurt if we do more of this). > > 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. > There are even more issues for Athens, and they don't vanish magically. There are some issues > on fogbugz just waiting for some feedback, preferable from people intending to use 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. > > > ... > > > We really would like to move all tools to Bloc as soon as possible, but we just need something right now that works and can be used in current version. > > But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it is needed to push > this into the release. > > I think we will never (but who knows) announce Brick as separate project. In our minds it is just useful helper library. > > For me, this just disqualifies Brick from being used in the core image. > > > I see that many things in the GToolkit are better than the old one (theming/layouting/delegate behavior in sub(classes/bricks). Great, it makes fun to work with it,extending the inspector or Spotter search. > > But I don't understand why this is pushed that way and on top of the old system/classes instead of cleaning that up. > > > nicolai > > > Thanks for reading :) > > Cheers, > Alex > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

March 24, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Tudor Girba

Hi, I think I might have misunderstood your mail :). Tthe intention behind Brick is not to be a separate framework but an internal tool for GT. At least not now, and at least not before we investigate how we get to the end goal of having a vectorial canvas (hence Bloc). Is this satisfying? Cheers, Doru On Tue, Mar 24, 2015 at 1:44 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-03-24 12:37 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi Nicolai, >> >> I am surprised by your conclusion that the current Brick implementation >> disqualifies it from being part of the Core :) >> > > not the implementation, the uncertainty of its purpose - a GT private > implementation / a public framework. > > >> >> >> All in all, you should see Brick as a pragmatic intermediary step towards >> removing Morph. I agree that it can be better (what cannot be), but I >> disagree we should discard GT because of it. >> > > I did not say "discard GT" . Brick is in the image, but I don't want to > have it in the > core image *as another UI-library* next to what we already have - without > cleaning that up. > > You know the questions on the mailing list about what framework to use for > creating an application:pure Morphic/Polymorph/Spec/Glamour, > and yes I am sure people will come and ask "hey how can I create such cool > looking application like spotter". > It is already difficult for new people to step in, and get an idea how to > work in pharo, or find information about the different frameworks. > > Nicolai > > > > >> >> Cheers, >> Doru >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 24, 2015

String>>howManyMatch: Bug or feature ?

by Noury Bouraqadi

Hi, The normal behavior 'abc' howManyMatch: 'abd' --> 2. I got suprized the way Blanks and new lines are handled. '\**' withCRs howManyMatch: '\\**' withCRs. --> 2 instead of 1 'ab\ **' withCRs howManyMatch: 'ab\\**' withCRs. --> 4 instead of 3 '\ **' withCRs howManyMatch: '\\**' withCRs. --> 3 instead of 1 'ab\ **' withCRs howManyMatch: 'ab\\**' withCRs. --> 5 instead of 3 The behavior is the same in both Pharo 3 and Pharo 4. Reading the code of does not help me understand why it's this way String>>howManyMatch: string "Count the number of characters that match up in self and aString." | count shorterLength | count := 0. shorterLength := self size min: string size. 1 to: shorterLength do: [:index | (self at: index) = (string at: index ) ifTrue: [ count := count + 1 ]]. ^ count Noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

March 24, 2015

[pharo-project/pharo-core]

by GitHub

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

March 24, 2015

[pharo-project/pharo-core] 79e66b: 40580

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 79e66b97d7783fe020fc952f5f5e797f3b0f3a72 https://github.com/pharo-project/pharo-core/commit/79e66b97d7783fe020fc952f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-24 (Tue, 24 Mar 2015) Changed paths: R Athens-Balloon.package/AthensBalloonSurface.class/instance/paints/createLinearGradient_origin_corner_.st R Athens-Cairo.package/AthensCairoSurface.class/instance/paints/createLinearGradient_origin_corner_.st R Athens-Core.package/AthensSurface.class/instance/paints/createLinearGradient_origin_corner_.st R Athens-Examples.package/VGTigerDemo.class/class/as yet unclassified/checkDataSizes.st R Athens-Examples.package/VGTigerDemo.class/class/as yet unclassified/commands.st R Athens-Examples.package/VGTigerDemo.class/class/as yet unclassified/runDemo.st R Athens-Examples.package/VGTigerDemo.class/class/as yet unclassified/tigerCommandCount.st R Athens-Examples.package/VGTigerDemo.class/class/as yet unclassified/tigerMaxX.st R Athens-Examples.package/VGTigerDemo.class/class/as yet unclassified/tigerMaxY.st R Athens-Examples.package/VGTigerDemo.class/class/as yet unclassified/tigerMinX.st R Athens-Examples.package/VGTigerDemo.class/class/as yet unclassified/tigerMinY.st R Athens-Examples.package/VGTigerDemo.class/class/as yet unclassified/tigerPointsCount.st A Athens-Examples.package/VGTigerDemo.class/class/private/checkDataSizes.st A Athens-Examples.package/VGTigerDemo.class/class/private/commands.st A Athens-Examples.package/VGTigerDemo.class/class/private/tigerCommandCount.st A Athens-Examples.package/VGTigerDemo.class/class/private/tigerMaxX.st A Athens-Examples.package/VGTigerDemo.class/class/private/tigerMaxY.st A Athens-Examples.package/VGTigerDemo.class/class/private/tigerMinX.st A Athens-Examples.package/VGTigerDemo.class/class/private/tigerMinY.st A Athens-Examples.package/VGTigerDemo.class/class/private/tigerPointsCount.st A Athens-Examples.package/VGTigerDemo.class/class/run/runDemo.st R Athens-Examples.package/VGTigerDemo.class/instance/as yet unclassified/convertPathData2.st R Athens-Examples.package/VGTigerDemo.class/instance/as yet unclassified/initialize.st R Athens-Examples.package/VGTigerDemo.class/instance/as yet unclassified/runDemo.st A Athens-Examples.package/VGTigerDemo.class/instance/conversion/convertPathData2.st A Athens-Examples.package/VGTigerDemo.class/instance/initialization/initialize.st A Athens-Examples.package/VGTigerDemo.class/instance/run/runDemo.st M ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/symbolic versions/stable_.st A ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version31_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script579.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script580.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40579.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40580.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40580 15210 load new configuration of Athens 3.1 https://pharo.fogbugz.com/f/cases/15210 http://files.pharo.org/image/40/40580.zip

March 24, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Nicolai Hess

2015-03-24 12:37 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Nicolai, > > I am surprised by your conclusion that the current Brick implementation > disqualifies it from being part of the Core :) > not the implementation, the uncertainty of its purpose - a GT private implementation / a public framework. > > > All in all, you should see Brick as a pragmatic intermediary step towards > removing Morph. I agree that it can be better (what cannot be), but I > disagree we should discard GT because of it. > I did not say "discard GT" . Brick is in the image, but I don't want to have it in the core image *as another UI-library* next to what we already have - without cleaning that up. You know the questions on the mailing list about what framework to use for creating an application:pure Morphic/Polymorph/Spec/Glamour, and yes I am sure people will come and ask "hey how can I create such cool looking application like spotter". It is already difficult for new people to step in, and get an idea how to work in pharo, or find information about the different frameworks. Nicolai > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 24, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Esteban Lorenzano

> On 24 Mar 2015, at 12:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Nicolai, > > I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :) it was not that what disqualifies it. It is the âwe will not announce itâ part :) I mean: if it is not a separated framework then is not appropriate to use it for other stuff outside its intended purpose (doing GTTools). Esteban > > Let's recap. > > Brick was created to support GT. We wanted GT in the image, hence Brick is in the image as part of Glamour. In the meantime, Brick has grown and it's now an almost standalone framework, but it is not yet advisable to use it apps because it will likely change more. > > As Alex says, we do not want to have two competing new projects running in parallel (Brick and Bloc) and fragmenting the effort even more. That is why, for Pharo 5 we want to invest in Bloc. The interesting thing is that while Bloc starts from scratch, Brick already works and has quite some high level widgets and logic built in. Brick is already going in the same direction expected by Bloc, so we will likely have the opportunity of moving Brick on top of Bloc (Alex already did an experiment in this direction). > > Concretely, on March 31 and April 1 (no joke :)), we have a session in Bern where Alain Plantec will join us to look into how to approach this problem concretely. > > All in all, you should see Brick as a pragmatic intermediary step towards removing Morph. I agree that it can be better (what cannot be), but I disagree we should discard GT because of it. > > Cheers, > Doru > > > On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > > > 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>>: > 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 :) > > Hi, > thank you, this is a really great source of information, and it would be heplful > to have this kind of write up somewhere else (not in the mailinglist). > But I did not question why we may need brick or why it is done. > My question was, what are the feature plans, is it just an experiment that > can vanish, so it is better to not use it for the core tools. Or is it meant to be > THE new framework we should gain our focus on. > > > 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. > > This is something I don't understand. As we integrated GT-Tools into the image, Rubric > slipped in as it is need by GT. I asked what is the background, what are the feature plans > and complained about the undocumented core classes, that makes it difficult to see > what changed compared to the old text classes. Alain said he doesn't plan to do further > work on Rubric. > So, WHY don't we replace and migrate the existing classes now and clean it up. It takes so > much resources to maintain both. Every theme change, every change on shortcuts/menus/keymapping, the athens drawing, all has to be double checked - It is so exhausting. > > > No morphs are used at all (except Rubric of course). > > Well, all Bricks ARE morphs, they share the same state and api. > > All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from original Morph only Canvas (without drawing) and MorphicEvents. > > If so, the clean/better way would be to extract those part into a "ProtoMorph" or a "PlainMorph". > and subclass from that once for Brick and again for Morphs. > Now we have Bricks, that are looking like a Morph, but aren't used to be one, and probable doesn't even work if they are used as Morphs. > (Sure this is true for other Morphsubclasses as well, but that does not means it doesn't hurt if we do more of this). > > 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. > There are even more issues for Athens, and they don't vanish magically. There are some issues > on fogbugz just waiting for some feedback, preferable from people intending to use 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. > > > ... > > > We really would like to move all tools to Bloc as soon as possible, but we just need something right now that works and can be used in current version. > > But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it is needed to push > this into the release. > > I think we will never (but who knows) announce Brick as separate project. In our minds it is just useful helper library. > > For me, this just disqualifies Brick from being used in the core image. > > > I see that many things in the GToolkit are better than the old one (theming/layouting/delegate behavior in sub(classes/bricks). Great, it makes fun to work with it,extending the inspector or Spotter search. > > But I don't understand why this is pushed that way and on top of the old system/classes instead of cleaning that up. > > > nicolai > > > Thanks for reading :) > > Cheers, > Alex > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

March 24, 2015