September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Issue tracker] Action needed

by Marcus Denker

It would be especially nice if people wo *submitted* an issue tacker entry in the past would take up the role of a âissue stewardâ, that is: make sure the issue gets closed. - Is it still relevant? - Was it already fixed? - Is it really important? If nobody (and not you, either, cared for 8 months?) - Push people to help. Ask on the mailing list! Put together a team. Fix it. What is clear is that with 620 open issues, nothing will happen âautomaticallyâ. (thankfully one thing: after 12 month of inactivity, your issue gets auto-closedâ¦) Marcus > On 20 Sep 2016, at 09:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello, > > We have *a lot* (really a lot!!) half-finished, âdiscussion stopped in the middleâ kind of issues > on the issue tracker. > > It would *really* be nice if people could check older issues and push for a conclusion! > > It is *much* easier to finish issues for those who spend already time on it as opposed to > someone reading and following the whole discussion. > > We are at 622 open issues: > > https://pharo.fogbugz.com/f/filters/57/All-newest-first > > > Marcus

Sept. 20, 2016

[Pharo6] Failing tests on CI: 6

by Marcus Denker

Hi, We have 6 tests failing on the CI: SmalllintManifestCheckerTest.testCriticsOf SmalllintManifestCheckerTest.testToDoOf - tests need to be updated, will be fixed with next QA update ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits - fixed upstream SystemAnnouncerLiveTest.testNoDeadSubscriptions Announcements.Tests.Core.Tests.WeakAnnouncerTest.testNoDeadWeakSubscriptions ClassDescriptionTest.testClassDescriptionRespectsPolymorphismWithTraitDescription #iconNamed: in ClassDescription. Any help to get this number down is welcome! Marcus

Sept. 20, 2016

[Issue tracker] Action needed

by Marcus Denker

Hello, We have *a lot* (really a lot!!) half-finished, âdiscussion stopped in the middleâ kind of issues on the issue tracker. It would *really* be nice if people could check older issues and push for a conclusion! It is *much* easier to finish issues for those who spend already time on it as opposed to someone reading and following the whole discussion. We are at 622 open issues: https://pharo.fogbugz.com/f/filters/57/All-newest-first Marcus

Sept. 20, 2016

EpSelection DNU (Pharo 60231)

by Nicolai Hess

There was a change for icons/iconnamed done on class EpSelection 1. this change needs to be done in epiceas repository as well (?) 2. one call is wrong (EpSelection>>#populateMenu) : icon: (self iconNamed: #smallSaveAsIcon); instead of icon: (self icons iconNamed: #smallSaveAsIcon);

Sept. 20, 2016

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

by Nicolai Hess

2016-09-19 19:14 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" < >> estebanlm(a)gmail.com>: >> > >> > >> >> On 16 Sep 2016, at 21:45, 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)) >> > >> > >> > this is uglyâ¦ also, it breaks the spirit of UFFI where the purpose of >> using the array literals to give a feeling close to the C method. >> > I already told before I disagree with this reformattingâ¦. So no, Iâm >> absolutely against forcing such kind of format. >> >> Where and when did you disagreed? >> I always thought this behavior of the formatter was like that from the >> beginning, and it wasn't changed afterward. >> >> My suggestion was, to change the formatter to *not* reformat these >> literal arrays, so we could at least use a pragma like >> <expr:#(3+4) res: 7> >> And don't have to use quotes. Or the ugly literal array form #(3 #+ 4) >> >> >> ah, then we agree :) >> >> > Generally speaking, reformatting 16rF0F0 into 61680 is never going to be a > good idea. > Same for carefully aligned arrays > #( > #( 16r00 16r01 16r03 16rFF ) > #( 16r00 16r01 16r03 16rFF ) > ) > or #[ > 16r00 16r01 16r03 16rFF > 16r00 16r01 16r03 16rFF > ] > Pharo now uses RBParser and a formatter based on RBParsers AST-Nodes, and here, at least the number format is preserved, but not the layout of the array. foo |a b| a := #[ 16r00 16r00 16rFF]. b := #( #(1 0 0) #(0 1 0) #(0 0 1)). will be formatted to foo | a b | a := #[16r00 16r00 16rFF]. b := #(#(1 0 0) #(0 1 0) #(0 0 1)) > > The canonical representation for these is absolutely unhelpful for a human. > The formatting expresses an intention (for example some data structure to > which the Array will be mapped...). > You can see plenty examples of things that should not be reformatted in > VMMaker. > > > >> > Esteban >> > >> >> >> >> >> >> >> >>> >> >>> > >> >>> > Marcus >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> >> >> >> > >> >> >> >

Sept. 20, 2016

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

by Nicolas Cellier

2016-09-19 19:14 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" < >> estebanlm(a)gmail.com>: >> > >> > >> >> On 16 Sep 2016, at 21:45, 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)) >> > >> > >> > this is uglyâ¦ also, it breaks the spirit of UFFI where the purpose of >> using the array literals to give a feeling close to the C method. >> > I already told before I disagree with this reformattingâ¦. So no, Iâm >> absolutely against forcing such kind of format. >> >> Where and when did you disagreed? >> I always thought this behavior of the formatter was like that from the >> beginning, and it wasn't changed afterward. >> >> My suggestion was, to change the formatter to *not* reformat these >> literal arrays, so we could at least use a pragma like >> <expr:#(3+4) res: 7> >> And don't have to use quotes. Or the ugly literal array form #(3 #+ 4) >> >> >> ah, then we agree :) >> >> > Generally speaking, reformatting 16rF0F0 into 61680 is never going to be a > good idea. > Same for carefully aligned arrays > #( > #( 16r00 16r01 16r03 16rFF ) > #( 16r00 16r01 16r03 16rFF ) > ) > or #[ > 16r00 16r01 16r03 16rFF > 16r00 16r01 16r03 16rFF > ] > > The canonical representation for these is absolutely unhelpful for a human. > The formatting expresses an intention (for example some data structure to > which the Array will be mapped...). > You can see plenty examples of things that should not be reformatted in > VMMaker. > > And of course, it's not limited to literals. These Integer methods are somehow understandable as long as human formatted: swap8bytes ^( self << 56 bitAnd: 16rff00000000000000) bitOr: ((self << 40 bitAnd: 16rff000000000000) bitOr: ((self << 24 bitAnd: 16rff0000000000) bitOr: ((self << 8 bitAnd: 16rff00000000) bitOr: ((self >> 8 bitAnd: 16rff000000) bitOr: ((self >> 24 bitAnd: 16rff0000) bitOr: ((self >> 40 bitAnd: 16rff00) bitOr: ( self >> 56 bitAnd: 16rff))))))) swap8bytesAlternative ^#( ( 56 16rff00000000000000) ( 40 16rff000000000000) ( 24 16rff0000000000) ( 8 16rff00000000) ( -8 16rff000000) (-24 16rff0000) (-40 16rff00) (-56 16rff)) inject: 0 into: [:result :shiftAndMask | result bitOr: ([:shift :mask | (self bitShift: shift) bitAnd: mask] valueWithArguments: shiftAndMask)] swap8bytesOtherAlternative | x | x := self. x := (x bitAnd: 16rFFFFFFFF00000000) >> 32 bitOr: (x bitAnd: 16r00000000FFFFFFFF) << 32. x := (x bitAnd: 16rFFFF0000FFFF0000) >> 16 bitOr: (x bitAnd: 16r0000FFFF0000FFFF) << 16. x := (x bitAnd: 16rFF00FF00FF00FF00) >> 8 bitOr: (x bitAnd: 16r00FF00FF00FF00FF) << 8. ^x swap8bytesYetAnotherAlternative ^{ [:x | (x bitAnd: 16rFFFFFFFF00000000) >> 32 bitOr: (x bitAnd: 16r00000000FFFFFFFF) << 32]. [:x | (x bitAnd: 16rFFFF0000FFFF0000) >> 16 bitOr: (x bitAnd: 16r0000FFFF0000FFFF) << 16]. [:x | (x bitAnd: 16rFF00FF00FF00FF00) >> 8 bitOr: (x bitAnd: 16r00FF00FF00FF00FF) << 8].} inject: self into: [:result :swapper | swapper value: result] For those found of annotations I suggest #<pleaseDontFormatMe> or since it's destinated to IDE/Tools > >> > Esteban >> > >> >> >> >> >> >> >> >>> >> >>> > >> >>> > Marcus >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> >> >> >> > >> >> >> >

Sept. 19, 2016

Re: [Pharo-dev] Ombu losing file on folder renaming

by Martin Dias

Couldn't reproduce in Ubuntu... may be in MacOS only? I will try in windows later. On Fri, Sep 9, 2016 at 12:58 PM, stepharo <stepharo(a)free.fr> wrote: > > Ah, it fails when using the absolute path, which doesn't exist > anymore...it would work by using a file locator , no? > > I do not know but I suspect that at each session restart this path should > be renewed. > > El 8/9/2016 12:32, "Damien Pollet" <damien.pollet(a)gmail.com> escribiÃ³: > >> The path you copied corresponds to before, or after the rename ? >> > It was before the rename. > > > > >

Sept. 19, 2016

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

by Nicolas Cellier

2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <estebanlm(a)gmail.com > >: > > > > > >> On 16 Sep 2016, at 21:45, 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)) > > > > > > this is uglyâ¦ also, it breaks the spirit of UFFI where the purpose of > using the array literals to give a feeling close to the C method. > > I already told before I disagree with this reformattingâ¦. So no, Iâm > absolutely against forcing such kind of format. > > Where and when did you disagreed? > I always thought this behavior of the formatter was like that from the > beginning, and it wasn't changed afterward. > > My suggestion was, to change the formatter to *not* reformat these literal > arrays, so we could at least use a pragma like > <expr:#(3+4) res: 7> > And don't have to use quotes. Or the ugly literal array form #(3 #+ 4) > > > ah, then we agree :) > > Generally speaking, reformatting 16rF0F0 into 61680 is never going to be a good idea. Same for carefully aligned arrays #( #( 16r00 16r01 16r03 16rFF ) #( 16r00 16r01 16r03 16rFF ) ) or #[ 16r00 16r01 16r03 16rFF 16r00 16r01 16r03 16rFF ] The canonical representation for these is absolutely unhelpful for a human. The formatting expresses an intention (for example some data structure to which the Array will be mapped...). You can see plenty examples of things that should not be reformatted in VMMaker. > > > Esteban > > > >> > >> > >> > >>> > >>> > > >>> > Marcus > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >> > > > > >

Sept. 19, 2016

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

by Esteban Lorenzano

> On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > > > > > >> On 16 Sep 2016, at 21:45, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > >> > >> > >> > >> 2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: > >>> > >>> Hi All, > >>> > >>> > >>> > >>> _,,,^..^,,,_ (phone) > >>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@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)) > > > > > > this is uglyâ¦ also, it breaks the spirit of UFFI where the purpose of using the array literals to give a feeling close to the C method. > > I already told before I disagree with this reformattingâ¦. So no, Iâm absolutely against forcing such kind of format. > > Where and when did you disagreed? > I always thought this behavior of the formatter was like that from the beginning, and it wasn't changed afterward. > > My suggestion was, to change the formatter to *not* reformat these literal arrays, so we could at least use a pragma like > <expr:#(3+4) res: 7> > And don't have to use quotes. Or the ugly literal array form #(3 #+ 4) > ah, then we agree :) > > > > Esteban > > > >> > >> > >> > >>> > >>> > > >>> > Marcus > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >> > > >

Sept. 19, 2016

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

by Nicolai Hess

Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <estebanlm(a)gmail.com>: > > >> On 16 Sep 2016, at 21:45, 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)) > > > this is uglyâ¦ also, it breaks the spirit of UFFI where the purpose of using the array literals to give a feeling close to the C method. > I already told before I disagree with this reformattingâ¦. So no, Iâm absolutely against forcing such kind of format. Where and when did you disagreed? I always thought this behavior of the formatter was like that from the beginning, and it wasn't changed afterward. My suggestion was, to change the formatter to *not* reformat these literal arrays, so we could at least use a pragma like <expr:#(3+4) res: 7> And don't have to use quotes. Or the ugly literal array form #(3 #+ 4) > > Esteban > >> >> >> >>> >>> > >>> > Marcus >>> > >>> > >>> > >>> > >>> > >>> > >>> >> >

Sept. 19, 2016