[pharo-project/pharo-core] edd9f3: 60220

On 19 Sep 2016, at 16:49, Nicolai Hess <[hidden email]> wrote:

Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <[hidden email]>:
>
>
>> On 16 Sep 2016, at 21:45, Nicolai Hess <[hidden email]> wrote:
>>
>>
>>
>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda <[hidden email]>:
>>>
>>> Hi All,
>>>
>>>
>>>
>>> _,,,^..^,,,_ (phone)
>>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker <[hidden email]> 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
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>

2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 19 Sep 2016, at 16:49, Nicolai Hess <[hidden email]> wrote:

Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <[hidden email]>:
>
>
>> On 16 Sep 2016, at 21:45, Nicolai Hess <[hidden email]> wrote:
>>
>>
>>
>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda <[hidden email]>:
>>>
>>> Hi All,
>>>
>>>
>>>
>>> _,,,^..^,,,_ (phone)
>>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker <[hidden email]> 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
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>

2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 19 Sep 2016, at 16:49, Nicolai Hess <[hidden email]> wrote:

Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <[hidden email]>:
>
>
>> On 16 Sep 2016, at 21:45, Nicolai Hess <[hidden email]> wrote:
>>
>>
>>
>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda <[hidden email]>:
>>>
>>> Hi All,
>>>
>>>
>>>
>>> _,,,^..^,,,_ (phone)
>>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker <[hidden email]> 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
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>

On 19 Sep 2016, at 4:03 , Henrik Johansen <[hidden email]> wrote:

On 17 Sep 2016, at 4:17 , Ben Coman <[hidden email]> wrote:

On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <[hidden email]> wrote:

2016-09-16 18:42 GMT+02:00 Eliot Miranda <[hidden email]>:

Hi All,



_,,,^..^,,,_ (phone)

On Sep 14, 2016, at 10:50 PM, Marcus Denker <[hidden email]>
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