2016-09-19 19:14 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:
>
>
> 2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>
>>
>> On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>
>>
>> Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <
>> esteba...@gmail.com>:
>> >
>> >
>> >> On 16 Sep 2016, at 21:45, Nicolai Hess <nicolaih...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> 2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com>:
>> >>>
>> >>> Hi All,
>> >>>
>> >>>
>> >>>
>> >>> _,,,^..^,,,_ (phone)
>> >>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.den...@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
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> >>
>> >
>>
>>
>>
>
