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

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

by Henrik Johansen

> 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 <mailto:btc@openinworld.com>> wrote: >> >> On Sat, Sep 17, 2016 at 3:45 AM, 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)) >> >> 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

Sept. 19, 2016

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

by Esteban Lorenzano

> 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 <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. Esteban > > > > > > > Marcus > > > > > > > > > > > > > >

Sept. 19, 2016

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

by Henrik Johansen

> 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 <mailto:nicolaihess@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

Sept. 19, 2016

SharedPool method definitions do not resolve Class names

by Ben Coman

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? cheers -ben

Sept. 19, 2016

[pharo-project/pharo-core]

by GitHub

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

Sept. 19, 2016

[pharo-project/pharo-core] 23300c: 60231

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 23300c3292cdc36a28259beb4528f8a1ee587bd8 https://github.com/pharo-project/pharo-core/commit/23300c3292cdc36a28259beb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-19 (Mon, 19 Sep 2016) Changed paths: M DebuggerModel.package/DebugSession.class/instance/logging/logStackToFileIfNeeded.st M Reflectivity-Tools.package/Breakpoint.class/instance/install/install.st M Reflectivity-Tools.package/Breakpoint.class/instance/install/remove.st M Reflectivity-Tools.package/CounterIconStyler.class/instance/defaults/iconBlock_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60230.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60231.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60230.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60231.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60231 19110 DNU on menu counter https://pharo.fogbugz.com/f/cases/19110 19091 Problem adding breakpoint through suggestions https://pharo.fogbugz.com/f/cases/19091 19108 Logging error stack should not hang image and prevent opening debugger https://pharo.fogbugz.com/f/cases/19108 http://files.pharo.org/image/60/60231.zip

Sept. 19, 2016

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

by Nicolai Hess

2016-09-19 10:33 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > On Sat, Sep 17, 2016 at 8:18 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> > On Sep 16, 2016, at 8:37 PM, stepharo <stepharo(a)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>: >> >> 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 >> www.feenk.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> >> >> >

Sept. 19, 2016

Re: [Pharo-dev] updated FastTable

by Tudor Girba

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. 19, 2016

Re: [Pharo-dev] updated FastTable

by Nicolai Hess

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. > > > -- > www.tudorgirba.com > www.feenk.com > > "Don't give to get. Just give." > > > > > > > >

Sept. 19, 2016

Re: [Pharo-dev] Interrupting process which hangs on recursion

by Denis Kudriashov

2016-09-19 10:44 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Great work, Denis! > > We have to look at how the GTDebugger works with large stacks. Could you > please open an issue for that? > Done 19109 <https://pharo.fogbugz.com/f/cases/19109/GTDebugger-produces-too-much-contex…>

Sept. 19, 2016