- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by stepharo

+1 I love Sunit as specification validation. I like doctest just a validated doc. I do not care that the are used as tests. This is not the main goal to me The goal is make sure that the reader understand fast. I like that there are in the comments because in a PharoDoc the examples woudl be there. Sytef > > > > On Sep 16, 2016, at 8:37 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > > + 1 > > > > Changing the language metamodel for simple validated > comments is a huge effort for nothing. > > Clement is good at VM level but not at other level :) > > I think there is a misunderstanding :). I do not see any > implication to the language meta-model in the remark of Clement. > > In fact, I expressed exactly the same opinion, that the design > of things like PythonDoc comes from the fact that those people > do not rely on an IDE, so their design focuses on the only > thing they have: source code. Clement remarked that we already > have SUnit tests and he suggested that we could just enhance > the IDE to present them next to the methods. This might > actually be less straightforward with SUnit because it was not > made for preserving links to the code, but it can work out of > the box with something like GTExamples. > > > Yes, the language meta-model is already too complex in Pharo IMHO, > let's not make it even more complex. I should have precised that's > not what I meant if this was not obvious to everyone. > > /1. Method docs with examples, so a user can see an example usage > of a method (sunit test methods sometimes aren't good "examples")/ > /2. We already had (and still have) some method docs where the > example code just won't work anymore because the methods or > classes used/ > > Nicolai, > > I'm suggesting to show the SUnit test code (or example code, or > whatever) next to the method, and being able to create a unit test > this way instead of only the existing green/red button and the > "browse tests" entry in the right click menu. For existing methods > having in their comment executable code to test how they work (as > you mentioned), the code can just be moved to the test shown in > the pane next to it (through a script discovering all cases like > that or manually). > > The example usage would still be shown next to the code for the > user, except it would already be under version control as existing > SUnit tests are, it can now have syntax coloring which is not > present in comments, it's automatically executed by each Pharo > build through SUnit hence detecting regressions and the meta-model > is not getting more complex at all. As Tudor said, it's only about > IDE changes. > > I believe that some SUnit tests are sometimes not good examples > because they're higher level tests (application tests, business > tests) while as for python doctests it's only relevant to show > unit tests next to the method the unit test validates. Currently I > believe Nautilus discovers tests and add the green/red button > based on name conventions. Foo>>bar has this feature if > FooTests>>testBar is implemented. So it's either a matter of > improving this heuristic or educating the community with this > existing name convention. In any case, I don't think it's more > changes for the user than having to learn convention in the > comments/pragmas. > > > Yes, we should d some experiments with different solutions and see > what works. > > I like the simplicity of having code in comments, at the moment I > don't like when we use the code highlighter, because this looks a bit > confusing. > > I would like a better link between methods and sunit tests, too. > > I still don't think that unit tests can fully replace code examples. > And having a possibility to validate the code from method comments > would be nice. > > For example, some time ago there were some examples in Color methods like > wheel: thisMany > "Return a collection of thisMany colors evenly spaced around the > color wheel." > "Color showColors: (Color wheel: 12)" > > the method #showColors: was long gone, so I replaced the comment to > use #inspect instead. > > But this code example is not about validation, a unit test would look like > > self assert:(Color wheel: 12) equals: {(Color r: 0.7000000000000001 g: > 0.07 b: 0.07 alpha: 1.0). (Color r: 0.7000000000000001 .....} > > This code example is about a simple usage: "how would Color wheel:12 > look like ? Ha just inspect the result and see yourself" > > And having a way to detect when the code example "Color showColors: > .." doesn't work anymore because the method was > removed, or if the Code example > "(CompiledMethod compiledMethodAt: #author) author" > doesn't work anymore because the method was moved from CompiledMethod > to Compiled code ;-) > would be nice. > > Yes maybe we can find another way to link real example code (not code > in comments) to the actual method with better tool support, but we can > not cover this with unit tests style methods alone. > > Even a simple example like: > 'pharo' capitalized " >>> 'Pharo'" > this reads better than > self assert:'pharo' capitalized equals:'Pharo' > Ok, it is not that bad to understand the usage of 'capitalized', its > iput and output from this unit test, but not all unit tests are > written like that. Some tests are mostly about testing corner cases or > an implementation detail, > or other code that isn't even considered to be used outside of the test. > > So, yes, we should do some more experiments and see. > > > > > > > > > > > > > > Cheers, > Doru > > > > Stef > > > > Le 16/9/16 Ã 14:18, Denis Kudriashov a Ã©crit : > >> > >> 2016-09-16 13:42 GMT+02:00 ClÃ©ment Bera > <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: > >> Why don't you just change nautilus to have two text areas, > one with the test corresponding to the method and the other > one with the method's code ? > >> > >> You're saying: > >> Their values is active documentation that can be > automatically validated. > >> That can also be applied to test we've already had with > SUnit. If the only difference you want is to display the test > next to the method, then it's an IDE problem, nothing has to > be changed but the IDE. > >> > >> In python they have no other choices than putting tests in > comments because their IDE is a text editor, they cannot > create other panes or anything like that. > >> > >> It is of course true. But Stef suggestion is really much > much simpler. It is just convention how to write examples > inside comments. Then tools could work with them and Nicolai > already provide simple extension for Nautilus. > >> We already has a lot of comments with examples inside. > Making them discoverable and testable will be nice. > >> > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > > >

Sept. 20, 2016

Re: [Pharo-dev] SharedPool method definitions do not resolve Class names

by ClÃ©ment Bera

Are SharedPool supposed to be instantiated ? Why did you need to instantiate a SharedPool ? I only use them (maybe mistakenly) by setting with class-side methods the default values of the SharedPool class variables, then use the poolDictionary: keyword to access those variables values from other classes. I thought that was the only way they should be used. Please explain me the other use-cases for a shared pool. On Tue, Sep 20, 2016 at 10:38 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-09-19 16:02 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> This is probably my lack of understanding but I found this surprising >> behaviour.... >> >> I was trying to add a method to a subclass of FFIExternalEnumeration >> and it was not recognising classes. I traced this back to SharedPool >> which can be demostrated by trying to save the following method... >> >> SharedPool >> test1 >> ^Object >> >> >> reports... "Unknown variable: Object please correct, or cancel:" >> >> >> Any insights? >> > > I think it is a bug. SharedPool implement some special lookup to make the > SharedPool variable lookup work. But it seems this conflicts with the > variable lookup for > globals. > > >> cheers -ben >> >> >

Sept. 20, 2016

Re: [Pharo-dev] SharedPool method definitions do not resolve Class names

by Marcus Denker

> On 20 Sep 2016, at 10:38, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-09-19 16:02 GMT+02:00 Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: > This is probably my lack of understanding but I found this surprising > behaviour.... > > I was trying to add a method to a subclass of FFIExternalEnumeration > and it was not recognising classes. I traced this back to SharedPool > which can be demostrated by trying to save the following method... > > SharedPool >> test1 > ^Object > > > reports... "Unknown variable: Object please correct, or cancel:" > > > Any insights? > > I think it is a bug. SharedPool implement some special lookup to make the SharedPool variable lookup work. But it seems this conflicts with the variable lookup for > globals. Yes, I think so, too. It should be possible to do the right thing (lookup local, then global). Marcus

Sept. 20, 2016

Re: [Pharo-dev] SharedPool method definitions do not resolve Class names

by Nicolai Hess

2016-09-19 16:02 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > This is probably my lack of understanding but I found this surprising > behaviour.... > > I was trying to add a method to a subclass of FFIExternalEnumeration > and it was not recognising classes. I traced this back to SharedPool > which can be demostrated by trying to save the following method... > > SharedPool >> test1 > ^Object > > > reports... "Unknown variable: Object please correct, or cancel:" > > > Any insights? > I think it is a bug. SharedPool implement some special lookup to make the SharedPool variable lookup work. But it seems this conflicts with the variable lookup for globals. > cheers -ben > >

Sept. 20, 2016

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