[pharo-project/pharo-core] edd9f3: 60220
Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: edd9f3770d89ef3c48592411b97507dcb453bcef https://github.com/pharo-project/pharo-core/commit/edd9f3770d89ef3c48592411b... Author: Jenkins Build Server <board@pharo-project.org> Date: 2016-09-13 (Tue, 13 Sep 2016) Changed paths: M AST-Core.package/RBParser.class/instance/private-parsing/parsePragmaLiteral.st A AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testInvalidPragmaPosition.st R AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testInvalidPragmas.st A AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testPragmaImplicitLiteralArrayIsInvalid.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60219.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60220.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60219.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60220.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60220 19086 do not allow expressions as pragma arguments https://pharo.fogbugz.com/f/cases/19086 http://files.pharo.org/image/60/60220.zip
Hi nicolai Why we should not accept foo <func: (3+4) res:0> ^ self and be forced to put around '' foo < func: '(3+4)' res: 0 > ^ self I understand that we store literal but why you do not like it :). Stef
60220 19086 do not allow expressions as pragma arguments https://pharo.fogbugz.com/f/cases/19086
2016-09-13 21:00 GMT+02:00 stepharo <stepharo@free.fr>:
Hi nicolai
Why we should not accept
foo <func: (3+4) res:0> ^ self
and be forced to put around ''
foo < func: '(3+4)' res: 0 > ^ self
I understand that we store literal but why you do not like it :).
First of all, the old compiler did not accept this. And I am a bit sensitive about changes, we allow a different syntax just because RB happens to allow this (and maybe no one knows why or it just does not happens on purpose). And another reason, even without my fix, if we don't put quotes around that expression, the reformatting the source will convert this to: foo <func: #(3 #+ 4) res: 0> ^ self And, even if (3+4) looks like an expression, it is just a list of literals something like this: foo <func: ([[[}}}) res:0> ^ self would be allowed too. But of course this is only my own opinion :) We can change it back and maybe add support for the reformatter to not convert it to the literal array #(3 #+ 4) . nicolai
Stef
60220
19086 do not allow expressions as pragma arguments https://pharo.fogbugz.com/f/cases/19086
Hi nicolai
Why we should not accept
foo <func: (3+4) res:0> ^ self
and be forced to put around ''
foo < func: '(3+4)' res: 0 > ^ self
I understand that we store literal but why you do not like it :).
First of all, the old compiler did not accept this. And I am a bit sensitive about changes, we allow a different syntax just because RB happens to allow this (and maybe no one knows why or it just does not happens on purpose).
valid point.
And another reason, even without my fix, if we don't put quotes around that expression, the reformatting the source will convert this to:
foo <func: #(3 #+ 4) res: 0> ^ self
What I noticed is that I could not write foo <expr: 3 + 4 result: 7> but it worked when I put () so I did it in the new code I wrote.
And, even if (3+4) looks like an expression, it is just a list of literals something like this:
foo <func: ([[[}}}) res:0> ^ self
would be allowed too. This one is ugly
But of course this is only my own opinion :)
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? If we have ' ' then it would be good that the syntax higlighter works with a special mode inside the ' '
nicolai
Stef
60220 19086 do not allow expressions as pragma arguments https://pharo.fogbugz.com/f/cases/19086 <https://pharo.fogbugz.com/f/cases/19086>
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. Marcus
Hi,
On Sep 15, 2016, at 7:50 AM, Marcus Denker <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 second that. Furthermore, typical examples require more than one liners, and these should be factored out separately. Cheers, Doru
Marcus
-- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."
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. and then? you try and if it failed then in not code and you do not highlight it. KISS. No? 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 second that. Furthermore, typical examples require more than one liners, and these should be factored out separately.
I'm talking about basename "Returns the base of the basename, i.e. /foo/gloops.taz basename is 'gloops.taz' / basename is '/'" I do not think that it makes sense to have a separate example for this. Because you want to read everything I do not see why the following would not work. basename "Returns the base of the basename" <expr: '''/foo/gloops.taz'' asFileReference basename' result: 'gloops.taz'> Now I hate the extra ' for strings. We should invent a syntax to be put inside comments and that we can easily parse because we need to improve the use and discovery of the library. basename "Returns the base of the basename" " '/foo/gloops.taz' asFileReference basename >>> 'gloops.taz' " I cannot not do anything and just complain that our methods are not that well documented. We as a community should take this and build an super cool system. Stef
Hi, Given the current interest, I am raising the issue of GTExample again. I sent a while ago a thorough description of the current solution: http://gtoolkit.org/doc/Examples/examples.html The goal is to provide documentation for all methods and classes both by allowing simple examples (plain unary methods) and offering the potential of doing more than just simple things. Except for Nicolai, there was no other feedback. Is there an interest to have a conversation about it? Cheers, Doru
On Sep 15, 2016, at 8:40 PM, stepharo <stepharo@free.fr> wrote:
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. and then? you try and if it failed then in not code and you do not highlight it. KISS. No? 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 second that. Furthermore, typical examples require more than one liners, and these should be factored out separately.
I'm talking about
basename "Returns the base of the basename, i.e. /foo/gloops.taz basename is 'gloops.taz' / basename is '/'"
I do not think that it makes sense to have a separate example for this. Because you want to read everything
I do not see why the following would not work. basename "Returns the base of the basename" <expr: '''/foo/gloops.taz'' asFileReference basename' result: 'gloops.taz'>
Now I hate the extra ' for strings. We should invent a syntax to be put inside comments and that we can easily parse because we need to improve the use and discovery of the library.
basename "Returns the base of the basename" " '/foo/gloops.taz' asFileReference basename
'gloops.taz' "
I cannot not do anything and just complain that our methods are not that well documented. We as a community should take this and build an super cool system.
Stef
-- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."
2016-09-15 8:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Sep 15, 2016, at 7:50 AM, Marcus Denker <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 second that.
Furthermore, typical examples require more than one liners, and these should be factored out separately.
I really like the one liners that you can find im some method comments, like in Color class>>#wheel: if you are new to pharo and start exploring the system, it makes fun to see these little one lines and just execute it. (even if they aren't onelines like in some method in class Form).
Cheers, Doru
Marcus
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
Hi,
On Sep 15, 2016, at 10:16 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-15 8:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Sep 15, 2016, at 7:50 AM, Marcus Denker <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 second that.
Furthermore, typical examples require more than one liners, and these should be factored out separately.
I really like the one liners that you can find im some method comments, like in Color class>>#wheel: if you are new to pharo and start exploring the system, it makes fun to see these little one lines and just execute it. (even if they aren't onelines like in some method in class Form).
I like one liners, too. But, should a documentation mechanism be confined to only work with small examples? Cheers, Doru
Cheers, Doru
Marcus
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
-- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."
Furthermore, typical examples require more than one liners, and these should be factored out separately.
I really like the one liners that you can find im some method comments, like in Color class>>#wheel: if you are new to pharo and start exploring the system, it makes fun to see these little one lines and just execute it. (even if they aren't onelines like in some method in class Form).
Me too and what I like is that there are coupled to the method. I find a method and I guess it will help me and bam I read the example and I'm sure it is or not what I'm looking for. Stef
Cheers, Doru
> > Marcus > > > > > >
-- www.tudorgirba.com <http://www.tudorgirba.com> www.feenk.com <http://www.feenk.com>
"Every thing should have the right to be different."
2016-09-16 8:54 GMT+02:00 stepharo <stepharo@free.fr>:
Furthermore, typical examples require more than one liners, and these
should be factored out separately.
I really like the one liners that you can find im some method comments, like in Color class>>#wheel: if you are new to pharo and start exploring the system, it makes fun to see these little one lines and just execute it. (even if they aren't onelines like in some method in class Form).
Me too and what I like is that there are coupled to the method. I find a method and I guess it will help me and bam I read the example and I'm sure it is or not what I'm looking for.
My belief is that we have an IDE able to track metadata (here, examples) along with methods, and that there is no need to play with syntax extensions (which are a way of adding metadata to programming languages stuck in the file concept of the 60's). In short, a nice, OO way of adding information about a method / class / tag / package that the IDE knows how to relate to the code. Having the class comment pane open in Nautilus is already a step towards doing that. Regards, Thierry
Stef
Cheers, Doru
Marcus
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
On Fri, Sep 16, 2016 at 3:02 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-09-16 8:54 GMT+02:00 stepharo <stepharo@free.fr>:
Furthermore, typical examples require more than one liners, and these should be factored out separately.
I really like the one liners that you can find im some method comments, like in Color class>>#wheel: if you are new to pharo and start exploring the system, it makes fun to see these little one lines and just execute it. (even if they aren't onelines like in some method in class Form).
Me too and what I like is that there are coupled to the method. I find a method and I guess it will help me and bam I read the example and I'm sure it is or not what I'm looking for.
My belief is that we have an IDE able to track metadata (here, examples) along with methods, and that there is no need to play with syntax extensions (which are a way of adding metadata to programming languages stuck in the file concept of the 60's).
In short, a nice, OO way of adding information about a method / class / tag / package that the IDE knows how to relate to the code.
Having the class comment pane open in Nautilus is already a step towards doing that.
So another way to look at keeping example/tests close to the methods is for the Browser code pane to have tabs [Source] [Examples] [Tests] [Class Comment] where maybe [Tests] lists every test containing the selection from the method pane. Adding these same to GTDebugger (which already has a [Source] tab) would improve inter-tool consistency. Spare vertical space for the code-pane tabs might be obtained if the <claass> button is replaced by a class/instance treeview protocol-pane tree view, then <Class> button goes away, the <Hier.> button could move above the class-pane leaving a spare row for the code pane tabs to sit. Attached is a rough mockup. cheers -ben
Hi All, _,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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. 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>
Marcus
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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))
Marcus
On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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. Actually I think it would be useful to go a step further to have positional rather than named parameters for FFI methods. At the moment the method names still end up a bit mangled. This seems feasible since currently an open-round-bracket is invalid syntax if not preceded by an assignment or colon. e.g. myvar := (a + b). "okay" self setVar: (a + b). "okay" self setVar( a + b ). "currently invalid syntax - but could could represent an FFI call" defined like... SomeLibrary class >> setVar( newValue ) ^ self ffiCall: #( int setVar ( int newValue ) But I expect its not something we'd want to leap into. cheers -ben
On 17 Sep 2016, at 4:17 , Ben Coman <btc@openInWorld.com> wrote:
On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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
On 19 Sep 2016, at 4:03 , Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 17 Sep 2016, at 4:17 , Ben Coman <btc@openInWorld.com <mailto:btc@openinworld.com>> wrote:
On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.denker@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
2016-09-19 16:24 GMT+02:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 19 Sep 2016, at 4:03 , Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 17 Sep 2016, at 4:17 , Ben Coman <btc@openInWorld.com <btc@openinworld.com>> wrote:
On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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
Hm, dead blocks, nice idea. see attached cs, you can file it in and have to uncomment one line in RBParser>>#parseBlock (the parsePragmasInto: aNode line) to activate pragmas in blocks, now you can add a "dead block" like [<example> 3+4] and the icon styler lets you execute (inspect) the code. (Just a quick and dirty implementation)
Now, this is something cool, I think. Letâs investigate this further. One issue is whether the Pragma class should be modified to take into account the new semantics. Cheers, Doru
On Sep 20, 2016, at 10:41 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-19 16:24 GMT+02:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 19 Sep 2016, at 4:03 , Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 17 Sep 2016, at 4:17 , Ben Coman <btc@openInWorld.com> wrote:
On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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
Hm, dead blocks, nice idea.
see attached cs, you can file it in and have to uncomment one line in RBParser>>#parseBlock (the parsePragmasInto: aNode line) to activate pragmas in blocks, now you can add a "dead block" like
[<example> 3+4]
and the icon styler lets you execute (inspect) the code. (Just a quick and dirty implementation)
<exampmle_blocks.cs><example_blocks.png>
-- www.tudorgirba.com www.feenk.com "Presenting is storytelling."
Tudor Girba-2 wrote
Now, this is something cool, I think. Letâs investigate this further. One issue is whether the Pragma class should be modified to take into account the new semantics.
Cheers, Doru
A major disadvantage is that in other Smalltalks supporting tags, block scoping isn't simply ignored/treated as a regular method tag, but a syntax error. So a change would benefit from some degree of coordination. With upcoming split between Clean/Other blocks you also have decide polymorphically the valid execution scope; context-free clean blocks can be executed as examples anywhere, non-clean ones will only be valid inspecting/debugging a live object. The same idea can, for the same reasons, also be applied to implement asserts that are entirely free when disabled; [<assert> param satisfiesSomeCondition] A change in global assert setting could recompile affected methods, adding/removing #value calls to the block in AST as appropriate. -- View this message in context: http://forum.world.st/pharo-project-pharo-core-edd9f3-60220-tp4915481p491638... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 16 Sep 2016, at 21:45, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>: Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.denker@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
Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <estebanlm@gmail.com>:
On 16 Sep 2016, at 21:45, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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)
Esteban
Marcus
On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaihess@gmail.com> wrote:
Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
On 16 Sep 2016, at 21:45, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.denker@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
2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaihess@gmail.com> wrote:
Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <estebanlm@gmail.com
:
On 16 Sep 2016, at 21:45, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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 :)
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 19:14 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaihess@gmail.com> wrote:
Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" < estebanlm@gmail.com>:
On 16 Sep 2016, at 21:45, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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 :)
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
2016-09-19 19:14 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaihess@gmail.com> wrote:
Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" < estebanlm@gmail.com>:
On 16 Sep 2016, at 21:45, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <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 :)
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
2016-09-14 21:24 GMT+02:00 stepharo <stepharo@free.fr>:
Hi nicolai
Why we should not accept
foo <func: (3+4) res:0> ^ self
and be forced to put around ''
foo < func: '(3+4)' res: 0 > ^ self
I understand that we store literal but why you do not like it :).
First of all, the old compiler did not accept this. And I am a bit sensitive about changes, we allow a different syntax just because RB happens to allow this (and maybe no one knows why or it just does not happens on purpose).
valid point.
And another reason, even without my fix, if we don't put quotes around that expression, the reformatting the source will convert this to:
foo <func: #(3 #+ 4) res: 0> ^ self
What I noticed is that I could not write
foo <expr: 3 + 4 result: 7>
but it worked when I put () so I did it in the new code I wrote.
And, even if (3+4) looks like an expression, it is just a list of literals something like this:
foo <func: ([[[}}}) res:0> ^ self
would be allowed too.
This one is ugly
But of course this is only my own opinion :)
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?
So, until know, I didn't really know what pythondoctest is about. I first thought the "test" is about unit tests and thought our way how we can generate or jump from methods to the corresponding is better, but know I understand that it is about "perform regression testing by verifying that interactive examples are working" And that is of course a good idea.
If we have ' ' then it would be good that the syntax higlighter works with a special mode inside the ' '
Not for pragma arguments, I think this would be confusing. I did some expreiments with formatting code in comments. I 'll write shortly about it.
nicolai
Stef
60220
19086 do not allow expressions as pragma arguments https://pharo.fogbugz.com/f/cases/19086
So, until know, I didn't really know what pythondoctest is about. I first thought the "test" is about unit tests and thought our way how we can generate or jump from methods to the corresponding is better, but know I understand that it is about "perform regression testing by verifying that interactive examples are working" And that is of course a good idea.
To me this is more than that. This is having simple scenario always validated and in front of my nose when I read the code.
If we have ' ' then it would be good that the syntax higlighter works with a special mode inside the ' '
Not for pragma arguments, I think this would be confusing.
Yes I cam to the same conclusion than marcus.
I did some expreiments with formatting code in comments. I 'll write shortly about it.
nicolai
Stef
60220 19086 do not allow expressions as pragma arguments https://pharo.fogbugz.com/f/cases/19086 <https://pharo.fogbugz.com/f/cases/19086>
participants (12)
-
Ben Coman -
Eliot Miranda -
Esteban Lorenzano -
GitHub -
Henrik Johansen -
Henrik Sperre Johansen
-
Marcus Denker -
Nicolai Hess -
Nicolas Cellier -
stepharo -
Thierry Goubier -
Tudor Girba