- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Version dependent Metacello Platform

by Dale Henrichs

On 9/20/16 11:12 AM, Torsten Bergmann wrote: > Hi, > > the expression > > MetacelloPlatform current defaultRepositoryDescription > > returns the meta repo for pharo 3 ('http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main') > even when run in Pharo 6. > > This is because MetacelloPharoCommonPlatform has a single subclass "MetacelloPharo30Platform". > > I guess this is because Metacello scripting API was integrated back in Pharo 3. Yes ... > Do we need to > update this to a MetacelloPharo60Platform in Pharo 6 ? > This _is_ a feature of Metacello in the sense that if a repository: is not included in a `Metacello new` expression, the default repository is used, but with that said, it is clearly not used very heavily:) I still think it would be useful to be able to write: Metacello new baseline: 'xxxx'; load and get the proper project loaded for the image, but I can't force folks to use this form --- especially if the default isn't correct;) It's still not clear whether folks have actually begun using the scripting API as much as they should --- the old way of sending load to a ConfigurationOf is at least 3 years out of date ... Dale

Sept. 21, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by Henrik Sperre Johansen

Tudor Girba-2 wrote > Now, this is something cool, I think. Letâs investigate this further. One > issue is whether the Pragma class should be modified to take into account > the new semantics. > > Cheers, > Doru A major disadvantage is that in other Smalltalks supporting tags, block scoping isn't simply ignored/treated as a regular method tag, but a syntax error. So a change would benefit from some degree of coordination. With upcoming split between Clean/Other blocks you also have decide polymorphically the valid execution scope; context-free clean blocks can be executed as examples anywhere, non-clean ones will only be valid inspecting/debugging a live object. The same idea can, for the same reasons, also be applied to implement asserts that are entirely free when disabled; [<assert> param satisfiesSomeCondition] A change in global assert setting could recompile affected methods, adding/removing #value calls to the block in AST as appropriate. -- View this message in context: http://forum.world.st/pharo-project-pharo-core-edd9f3-60220-tp4915481p49163… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 21, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by Tudor Girba

Now, this is something cool, I think. Letâs investigate this further. One issue is whether the Pragma class should be modified to take into account the new semantics. Cheers, Doru > On Sep 20, 2016, at 10:41 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-09-19 16:24 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> On 19 Sep 2016, at 4:03 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> >>> On 17 Sep 2016, at 4:17 , Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>> >>>>> Hi All, >>>>> >>>>> >>>>> >>>>> _,,,^..^,,,_ (phone) >>>>>> On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.denker(a)inria.fr> >>>>>> wrote: >>>>>> >>>>>> >>>>>>>> >>>>>>>> We can change it back and maybe add support for the reformatter to not >>>>>>>> convert it to the literal array #(3 #+ 4) . >>>>>>> >>>>>>> I do not know in fact this is why I asked :) >>>>>>> Now may be my idea to use pragma to get something like pythondoctest is >>>>>>> a bad idea >>>>>>> but I really want to have literal programming. >>>>>>> What do you think? >>>>>> I like the idea to show examples/tests close to code, but pragmas are >>>>>> not really good... >>>>>> >>>>>>> If we have ' ' then it would be good that the syntax higlighter works >>>>>>> with a special mode inside the ' ' >>>>>> >>>>>> it is just a string. How do you know that it contains code? >>>>>> >>>>>> Would you highlight all string in all code as if it contained code? Or >>>>>> would you add this just for >>>>>> Pragmas? But even there, strings are string, not code. >>>>>> >>>>>> I think we can conclude that pragmas are not a good solution to the >>>>>> problem, as they are far >>>>>> too limited to express code. >>>>> >>>>> I think that's not a safe conclusion. We know from Igor's use of Kieran >>>>> arrays for C signatures in the UFFI, and can easily extrapolate here, that >>>>> arbitrary Smalltalk expressions /can/ be expressed in literal arrays. S >>>>> expressions work for lisp. >>>>> >>>>> In this particular case special casing pretty printing of literal arrays >>>>> in pragmas would be all that's needed to make the code look beautiful. Why >>>>> throw the baby out with the bath water? It would be so easy to make this >>>>> work well. >>>> >>>> >>>> We can try this as well. And it is far more easier to work with this >>>> expressions if they are pragma arguments, than to parse the comment to find >>>> some code within. >>>> On the other hand, it looks much nicer if we have the examples right in the >>>> method doc. you have some text describing the method, some code, some more >>>> text about the reslt. >>>> >>>> >>>>> >>>>> >>>>> The only thing I'd do would be to print like this to make it clear that >>>>> the argument t is a literal Array and not some magic form of code: >>>>> >>>>> <expr: #(3 + 4) result: 7> >>>>> >>>> >>>> Yes, I would like to change this anyway, even for literal arrays for ffi, >>>> calls like >>>> >>>> mouseStateX: x y: y >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >>>> errorCode> >>>> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) ) >>>> >>>> this will be reformatted to >>>> >>>> mouseStateX: x y: y >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >>>> 'errorCode'> >>>> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y)) >>> >>> errr, yuck! Thats not pretty at all. Is there some way to avoid >>> that? As I've been getting started with FFI its been really nice >>> visually to see a *direct* correspondence between the C header file >>> declaration and the in-Image method. >> >> +1, that's about the main thought behind it... >> As long as the only required use of a # inside of literal arrays is differentiating whether something is a literal string or symbol, changing to format *all* symbols using it seems somewhat overzealous. >> >> Personally, if a solution using method properties/+ browser improvements to show/create them in a good way is out of the question, >> I have a weakness for using empty blocks as method-local, syntax-highlighted code comments (at least compared to special comment syntax, or pragmas backed by a whole literal -> ST parser). >> Though lately, the code critic (rightly, and very usefully, in the cases where it's a user error) points out they are dead code, and the IR optimizes them out entirely, meaning they miss out on senders/implementors/refactorings functionality. (Full blocks would potentially let us change the IR to leave them alone, put them in the literal slot and be searchable, at no additional runtime-cost/use in bytecodes) >> >> Cheers, >> Henry > > Now imagine if tags were scoped, and you could do > > Number >> #+ aNumber > <prim ....> > [ <insertInlineExampleTagNameHere> 3 + 4 == 7 ]. > ^self fallbackAdd: aNumber > > And have the browser pick it up, and either > - collapse it > - display text with alpha < 1 > > Make the code critic aware as well, and no more warnings of unused blocks when used for examples! > > Cheers, > Henry > > Hm, dead blocks, nice idea. > > see attached cs, you can file it in and have to uncomment one line in RBParser>>#parseBlock (the parsePragmasInto: aNode line) > to activate pragmas in blocks, now you can add a "dead block" like > > [<example> 3+4] > > and the icon styler lets you execute (inspect) the code. > (Just a quick and dirty implementation) > > > > <exampmle_blocks.cs><example_blocks.png> -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Sept. 20, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by Nicolai Hess

2016-09-19 16:24 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 19 Sep 2016, at 4:03 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > On 17 Sep 2016, at 4:17 , Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > 2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > Hi All, > > > > _,,,^..^,,,_ (phone) > > On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > We can change it back and maybe add support for the reformatter to not > convert it to the literal array #(3 #+ 4) . > > > I do not know in fact this is why I asked :) > Now may be my idea to use pragma to get something like pythondoctest is > a bad idea > but I really want to have literal programming. > What do you think? > > I like the idea to show examples/tests close to code, but pragmas are > not really good... > > If we have ' ' then it would be good that the syntax higlighter works > with a special mode inside the ' ' > > > it is just a string. How do you know that it contains code? > > Would you highlight all string in all code as if it contained code? Or > would you add this just for > Pragmas? But even there, strings are string, not code. > > I think we can conclude that pragmas are not a good solution to the > problem, as they are far > too limited to express code. > > > I think that's not a safe conclusion. We know from Igor's use of Kieran > arrays for C signatures in the UFFI, and can easily extrapolate here, that > arbitrary Smalltalk expressions /can/ be expressed in literal arrays. S > expressions work for lisp. > > In this particular case special casing pretty printing of literal arrays > in pragmas would be all that's needed to make the code look beautiful. Why > throw the baby out with the bath water? It would be so easy to make this > work well. > > > > We can try this as well. And it is far more easier to work with this > expressions if they are pragma arguments, than to parse the comment to find > some code within. > On the other hand, it looks much nicer if we have the examples right in the > method doc. you have some text describing the method, some code, some more > text about the reslt. > > > > > The only thing I'd do would be to print like this to make it clear that > the argument t is a literal Array and not some magic form of code: > > <expr: #(3 + 4) result: 7> > > > Yes, I would like to change this anyway, even for literal arrays for ffi, > calls like > > mouseStateX: x y: y > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode> > ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) ) > > this will be reformatted to > > mouseStateX: x y: y > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > 'errorCode'> > ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y)) > > > errr, yuck! Thats not pretty at all. Is there some way to avoid > that? As I've been getting started with FFI its been really nice > visually to see a *direct* correspondence between the C header file > declaration and the in-Image method. > > > +1, that's about the main thought behind it... > As long as the only required use of a # inside of literal arrays is > differentiating whether something is a literal string or symbol, changing > to format *all* symbols using it seems somewhat overzealous. > > Personally, if a solution using method properties/+ browser improvements > to show/create them in a good way is out of the question, > I have a weakness for using empty blocks as method-local, > syntax-highlighted code comments (at least compared to special comment > syntax, or pragmas backed by a whole literal -> ST parser). > Though lately, the code critic (rightly, and very usefully, in the cases > where it's a user error) points out they are dead code, and the IR > optimizes them out entirely, meaning they miss out on senders/implementors/refactorings > functionality. (Full blocks would potentially let us change the IR to leave > them alone, put them in the literal slot and be searchable, at no > additional runtime-cost/use in bytecodes) > > Cheers, > Henry > > > Now imagine if tags were scoped, and you could do > > Number >> #+ aNumber > <prim ....> > [ <insertInlineExampleTagNameHere> 3 + 4 == 7 ]. > ^self fallbackAdd: aNumber > > And have the browser pick it up, and either > - collapse it > - display text with alpha < 1 > > Make the code critic aware as well, and no more warnings of unused blocks > when used for examples! > > Cheers, > Henry > Hm, dead blocks, nice idea. see attached cs, you can file it in and have to uncomment one line in RBParser>>#parseBlock (the parsePragmasInto: aNode line) to activate pragmas in blocks, now you can add a "dead block" like [<example> 3+4] and the icon styler lets you execute (inspect) the code. (Just a quick and dirty implementation)

Sept. 20, 2016

Re: [Pharo-dev] glitches in text selection

by Nicolai Hess

Yes, see case 19113, fixed in 60233 2016-09-20 21:35 GMT+02:00 stepharo <stepharo(a)free.fr>: > Since I'm selecting a lot Smalltalk ui icons.... I noticed that there is a > bug in text selection. > > I thought it was me but no I select well the beginning of the expression > that I see the cursor jumping around....And missing > a couple of characters. > > > Stef > > >

Sept. 20, 2016

Re: [Pharo-dev] How do recover change with epicea?

by stepharo

even better Smalltalk tools changeList browseRecentLog does not show any changes :) So I redownloaded the latest version of tried - changes something - exist without saving - reopening the image And I could not reproduce the bug.... Shit. So I lost my time. Stef > Hi > > i introduced a loop (yes totally stupid) in menu morph icon :) > so I had to quit my image. > I thought that epicea would show me all the changes and I could not > find how to do it. > I do not know how to invoke the old recover lost changes... so so far > I lost 40 min of dev :( > > I have no idea what is monitor vs log set in Epicea. > And log set is just with the changes I'm doing :( not the ones I lost :( > > In cutting alpha image it would be good to make sure that we cannot > lose our work :( > Stef > > >

Sept. 20, 2016

How do recover change with epicea?

by stepharo

Hi i introduced a loop (yes totally stupid) in menu morph icon :) so I had to quit my image. I thought that epicea would show me all the changes and I could not find how to do it. I do not know how to invoke the old recover lost changes... so so far I lost 40 min of dev :( I have no idea what is monitor vs log set in Epicea. And log set is just with the changes I'm doing :( not the ones I lost :( In cutting alpha image it would be good to make sure that we cannot lose our work :( Stef

Sept. 20, 2016

glitches in text selection

by stepharo

Since I'm selecting a lot Smalltalk ui icons.... I noticed that there is a bug in text selection. I thought it was me but no I select well the beginning of the expression that I see the cursor jumping around....And missing a couple of characters. Stef

Sept. 20, 2016

Re: [Pharo-dev] Maintainer of DependencyAnalyser: Action needed

by stepharo

Le 19/9/16 Ã 10:49, Christophe Demarey a Ã©crit : > Didnât we switch to the strategy integrate first into Pharo and notify maintainer afterwards? Yes it is the model :) > It is hard to follow because sometimes integration goes directly into Pharo with slices and other time, it is included through configurations. > > I will produce a new version of the config and update the issue. > >> Le 16 sept. 2016 Ã 13:25, marcus.denker(a)inria.fr a Ã©crit : >> >> Whoever maintains DependencyAnalyser: There is a fix ready since 22 August 2016. >> >> We need to get this into the system *soon*. >> >> https://pharo.fogbugz.com/f/cases/18963/DANode-browseClass-sends-unimplemen… >> >> >> Marcus > >

Sept. 20, 2016

Re: [Pharo-dev] updated FastTable

by stepharo

Hi torsten We will integrate it. Looks easy. Now I'm jumping from meetings to meetings then to budgets and.... Stef Le 20/9/16 Ã 15:48, Torsten Bergmann a Ã©crit : > Hi > > there is another annoying bug regarding FastTable: https://pharo.fogbugz.com/f/cases/19116/ > that is easily fixed. > Anyone able to review/integrate? > > Thx > T. > >> Gesendet: Montag, 19. September 2016 um 11:35 Uhr >> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] updated FastTable >> >> Hi Nicolai, >> >> >>> On Sep 19, 2016, at 10:57 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> 2016-09-18 23:52 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> Hi, >>> >>> I just noticed that the most recent changes to FastTable that were present in Pharo60 were not in the main repo of estebanlm/FastTable. >>> >>> This caused anything that depended on the development version of FastTable to break the MessageBrowser. >>> >>> I pushed the latest version from Pharo60/main in the estebanlm/FastTable, and things look fine now. >>> >>> Cheers, >>> Doru >>> >>> Uh, yes, I reviewed issue 18606 but forgot that this would touch an external project. >>> Thank you Doru. >> No problem at all. >> >> Doru >> >> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Don't give to get. Just give." >>> >>> >>> >>> >>> >>> >>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "In a world where everything is moving ever faster, >> one might have better chances to win by moving slower." >> >> >> >> >> >> >

Sept. 20, 2016