- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Working with Pharo on the Raspberry Pi

by Ben Coman

Thanks Torsten. This is a great write up. I think there is real opportunity here, someone is introduced to one thing new (a Pi), they are receptive to being introduced to a second new thing (Pharo) at the same time. And often it will be an individual decision that doesn't need to compete with corporate doctrine to use Java or Microsoft - but once they are exposed, usage may drift back into their corporate work. Maybe the next book could be: Pi/BeagleBone + Pharo + PharROS + Phratch + some accessories + a bit of electronics design. btw, a small grammar correction... > Now we want that the Pi starts this command Now we want the Pi to start this command cheers -ben On Mon, Oct 26, 2015 at 4:47 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > I wrote a small article on Medium on how to setup the Pi > with a touch screen and Pharo: > > https://medium.com/@astares/pharo-pi-9eef257b6a21#.gw72pe7uy > > Hope one or the other might be interested. > > Have fun > T. >

Nov. 1, 2015

Re: [Pharo-dev] tests should be green

by stepharo

>> > we need to write a script to delete all the wrong methods. >> > > I inspected the failing lint rule and executed on the dictionary: > > self keys do: [:classSymbol | > (self at: classSymbol) do: [:selector | > classSymbol asClass removeSelector: selector. > ]] > > resulting slice is committed: > https://pharo.fogbugz.com/f/cases/16254/ > Marcus we should NOT use asClass in the system. It is a bad concept because the environment is not explicit. It is a plague and we will fight it when we will want a real "remote" environment. Stef

Nov. 1, 2015

[ANN] RenoirSt 2.0.0 released!

by Gabriel Cotelli

Hi, I'm announcing a new official release of RenoirSt. See the announcement and changelog <https://plus.google.com/111529669851117270585/posts/AxCpTvnhhAb> Regarsd, Gabriel

Oct. 31, 2015

Re: [Pharo-dev] [Moose-dev] moving to Rubric in Glamour

by Alexandre Bergel

Yes this is great Alexandre > Le 30 oct. 2015 Ã 18:46, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > Thank you! > > Doru > >> On Fri, Oct 30, 2015 at 9:33 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> Hi, >> >> I moved Glamour to Rubric, deprecated those presentations that use PluggableTextMorph and moved almost all usages of presentations that rely on PluggableTextMorph. >> These changes are still only in the Moose branch to see if there are any ugly bugs. >> >> The changes to the glamour API are the following: >> >> - deprecated #smalltalkCode, #pharoPlayground and #rubricText >> - added #pharoScript >> >> If you use #smalltalkCode replace it with either #pharoMethod or #pharoScript >> If you use #rubricTest replace those usages with #text >> If you use #pharoPlayground replace those usages with #pharoScript (we changed this as the glamour playground is not the same at the GTPlayground and this was causing some confusion) >> For this I also renamed GLMPharoPlaygroundPresentation to GLMPharoScriptPresentation and GLMMorphicPharoPlaygroundRenderer to GLMMorphicPharoScriptRenderer. >> >> If you are using the latest moose let me know if you run into any problems or have questions. >> >> Cheers, >> Andrei >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 31, 2015

Re: [Pharo-dev] loading bloc or brick

by Aliaksei Syrel

I know why, will fix soon P.S. Post Bloc related stuff to Bloc mail list ;) On Oct 31, 2015 1:25 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> wrote: > Current Bloc or Brick bleedingEdge or development, can not be loaded in > > Pharo 5 : > > This package depends on the following classes: > BlMorphicCompatibleBlocSpace > You must resolve these dependencies before you will be able to load these > definitions: > BlOSWindowMorphicCompatibleBlocSpace > BlOSWindowMorphicCompatibleBlocSpace>>#defaultRootMorph > BlOSWindowMorphicCompatibleBlocSpace>>#redraw > > any ideas where I can find this >

Oct. 31, 2015

loading bloc or brick

by Nicolai Hess

Current Bloc or Brick bleedingEdge or development, can not be loaded in Pharo 5 : This package depends on the following classes: BlMorphicCompatibleBlocSpace You must resolve these dependencies before you will be able to load these definitions: BlOSWindowMorphicCompatibleBlocSpace BlOSWindowMorphicCompatibleBlocSpace>>#defaultRootMorph BlOSWindowMorphicCompatibleBlocSpace>>#redraw any ideas where I can find this

Oct. 31, 2015

Re: [Pharo-dev] [Moose-dev] moving to Rubric in Glamour

by Tudor Girba

Thank you! Doru On Fri, Oct 30, 2015 at 9:33 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > I moved Glamour to Rubric, deprecated those presentations that use > PluggableTextMorph and moved almost all usages of presentations that rely > on PluggableTextMorph. > These changes are still only in the Moose branch to see if there are any > ugly bugs. > > The changes to the glamour API are the following: > > - deprecated #smalltalkCode, #pharoPlayground and #rubricText > - added #pharoScript > > If you use #smalltalkCode replace it with either #pharoMethod or > #pharoScript > If you use #rubricTest replace those usages with #text > If you use #pharoPlayground replace those usages with #pharoScript (we > changed this as the glamour playground is not the same at the GTPlayground > and this was causing some confusion) > For this I also renamed GLMPharoPlaygroundPresentation to > GLMPharoScriptPresentation and GLMMorphicPharoPlaygroundRenderer to > GLMMorphicPharoScriptRenderer. > > If you are using the latest moose let me know if you run into any problems > or have questions. > > Cheers, > Andrei > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 30, 2015

Re: [Pharo-dev] Write (rubric) text changes back to the object in GTInspector

by Nicolai Hess

2015-10-30 19:30 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > Cool example. > I slightly modified it and added it to the glamour examples :) > > | browser morph | > morph := StringMorph new. > morph font:(LogicalFont familyName: 'Source Code Pro' pointSize: 30). > browser := GLMTabulator new. > browser > row: #main; > row: #preview. > browser transmit > to: #main; > andShow: [ :a | a text > onChangeOfPort: #text act: [ :text | > morph contents:text text] ]. > browser transmit > to: #preview; > andShow: [ :a | a morph > title: 'Preview'; > display: [ morph ] ]. > > ^ browser openOn: 'some text' > > cool! > On Fri, Oct 30, 2015 at 11:47 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 2015-10-30 16:32 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >> >>> Hi, >>> >>> You can try this: >>> >>> composite := GLMCompositePresentation new. >>> composite pharoPlayground >>> title: 'Script'; >>> variableBindings: [ { #x -> 1. #y -> 2 } ]. >>> composite >>> openOn: 'x+y'. >>> >>> For the moment only script presentations can have variables. >>> >>> Btw #pharoPlayground and #rubricText will be deprecated in the latest >>> version in favour of #pharoScript and #text >>> >>> Cheers, >>> Andrei >>> >>> On Fri, Oct 30, 2015 at 11:14 AM, Torsten Bergmann <astares(a)gmx.de> >>> wrote: >>> >>>> Hi, >>>> >>>> if one has an inspector extension that shows a textual iVar of an object >>>> representing code (using #rubricText, #pharoMethod or #pharoPlayground) >>>> as in this example: >>>> >>>> gtInspectorSourceIn: composite >>>> <gtInspectorPresentationOrder: 30> >>>> ^ composite pharoMethod >>>> title: 'Source'; >>>> smalltalkClass: [ self methodClass ]; >>>> display: [ self getSource ]; >>>> act: [ self browse ] icon: GLMUIThemeExtraIcons >>>> glamorousBrowse entitled: 'Browse' >>>> >>>> What is the best/correct way to set the iVar when the text is typed so >>>> the >>>> state of the iVar represents the lively editing in the inspector >>>> extension? >>>> >>>> Or is there a way to realize this somehow with Glamour ports using the >>>> #text port? >>>> >>> >> >> you can define an action on a port change: >> onChangeOfPort:act: >> >> | browser morph | >> morph := StringMorph new openInWorld. >> morph font:(LogicalFont familyName: 'Source Code Pro' pointSize: 30). >> browser := GLMTabulator new. >> browser >> row: #main. >> (browser transmit) >> to: #main; >> andShow: [ :a | a rubricText >> onChangeOfPort: #text act: [ :text | >> morph contents:text text] ]. >> >> ^ browser openOn:'type some text' >> >> This will open a StringMorph and a GlamourBrowser. >> If you change the text in the browser, it will change the contents of the >> string morph. >> >> >> >>>> Thanks >>>> T. >>>> >>> >>> >> >

Oct. 30, 2015

moving to Rubric in Glamour

by Andrei Chis

Hi, I moved Glamour to Rubric, deprecated those presentations that use PluggableTextMorph and moved almost all usages of presentations that rely on PluggableTextMorph. These changes are still only in the Moose branch to see if there are any ugly bugs. The changes to the glamour API are the following: - deprecated #smalltalkCode, #pharoPlayground and #rubricText - added #pharoScript If you use #smalltalkCode replace it with either #pharoMethod or #pharoScript If you use #rubricTest replace those usages with #text If you use #pharoPlayground replace those usages with #pharoScript (we changed this as the glamour playground is not the same at the GTPlayground and this was causing some confusion) For this I also renamed GLMPharoPlaygroundPresentation to GLMPharoScriptPresentation and GLMMorphicPharoPlaygroundRenderer to GLMMorphicPharoScriptRenderer. If you are using the latest moose let me know if you run into any problems or have questions. Cheers, Andrei

Oct. 30, 2015

Re: [Pharo-dev] Metacello and preparing a release?

by Dale Henrichs

On 10/30/2015 10:04 AM, Eliot Miranda wrote: > Hi Dale, > > but why can't Metacello provide something really simple that automatically generates a configuration with all the prerequisites fully defined as fixed specific versions? Then Holger can easily freeze his release using the new confit and continue his internal development using his current configuration. Your suggestion implies that Holger would have to "take ownership" of the generated configuration and he would no longer be using the "official" configurations ... If the official configurations for the projects he is using change, how do you propose he merge in those changes? In git the version that you check out _is already_ a collection of the "fixed specific versions", so there is no need to create and maintain an "automatic configuration generator" .... that's the SCMs job. When using git things get simpler rather than more complex. For example just compare the ConfigurationOfSeaside3[1] (mzc repo) and the BaselineOfSeaside3[2] (git repo). On method count alone there are ~10 times more methods in ConfigurationOfSeaside3 than in BaselineOfSeaside3 ... then look at the methods themselves! [1] http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/Configurati… [2] https://github.com/SeasideSt/Seaside/tree/master/repository/BaselineOfSeasi… > Why is is about the repository and not the versions? Because versions _should_ be managed by the repository, not the package manager ... git and other disk based SCMS give me a single SHA (or other identifier) that uniquely identifies the collection of files on disk .. one can tag this SHA and give it a version name ... this is the job of an SCM ... The ConfigurationOf was invented to fill in the gap between what you could do with Monticello and what needed to be done --- which was to tag a _collection_ of packages with a version name --- and manage project and package dependencies .... Metacello does this. But there is more to "to be done" than just tagging a _collection_ of pages with a version name ... One should be able to see the differences between versions: changes to packages plus added and removed packages. Metacello does not do this. One should be able to merge one version into another. Metacello does not do this. Git and other SCM based SCM do show you diffs between versions and you can merge changes between two different versions... as an added bonus you can include your documentation, images and shell scripts in the same directory structure and version them altogether in one swell foop. Rather than attempt to duplicate the entire range of functionality that git and other disk-based SCMs provide, I choose to leverage existing functionality and put my effort into inventing new things in Smalltalk.... Dale

Oct. 30, 2015