headers
Dierk Koenig | 2 Jan 2006 11:23
Favicon
Gravatar

[groovy-dev] backslash u in slashy string syntax

Hiall,

Strings can defined with the slashy syntax like
 String foo = /whatever/
This is a normal String even though mostly used for
defining regex pattern strings.
Backslashes need no escaping with this syntax.
 assert '\\x'==/\x/

but this doesn't work with \u since it expects a
unicode char declaration to follow
 assert '\\'==/\u/

-> General error during parsing: Did not find four digit hex character code.

I appears like a missing parser capability to me.
Should I raise a JIRA issue?

cheers
Mittie
Permalink | Reply | 22 comments |
headers
Guillaume Laforge | 2 Jan 2006 11:50
Picon
Gravatar

[groovy-dev] One last problem with multid arrays

Hi Jochen,

I just noticed that there's one little remaining problem with multid
arrays when you use as base element a class defined in the same source
unit as the one you're defining the array in, hence the following code
won't work:

groovy> class Foo {}
groovy> ff = new Foo[3][4]
groovy> go
Caught: java.lang.ClassFormatError: CommandLine (Illegal Class name "Foo[][]")

I've filed a JIRA issue for that:
http://jira.codehaus.org/browse/GROOVY-1197

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy
Permalink | Reply | 0 comments |
headers
Rasmus Aveskogh | 2 Jan 2006 12:00
Picon

[groovy-dev] Scoping and trace backs


Hi,

My company developes a provisioning application where the customer can
provide provisioning logics by writing scripts. The scripts are executed
within the application at runtine though the core engine written in Java.

Currently we have support for Beanshell and PHP but have glanced at Groovy
since the PHP integration uses proxy objects which isn't working well with
Hybernate, and Beanshell is a little strict when it comes to
functionality.

Groovy seems to have everything in terms of object/class bridging which
PHP lacks, while also supplying a lot of "script candy" (Groovy SQL,
working with Maps and Lists etc).

We did a little proof of concept and found some blockers which I would
like to check with you as I know you're doing extensive work on the
Reference Implementation now.

First of all I know you're working on scoping issues, and during our tests
with JSR-4 there were some issues associated with odd scope behaviour. If
I reused a variable name in a totally different scope I ended up with
internal NPE's which is my very next question: Will there be better stack
trace support?

Syntax errors and common errors are often easy to find, but every now and
then you end up with something like "Internal Error: NPE", which, in a
fairly large script is quite annoying. Beanshell would be a good role
model here.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jochen Theodorou | 2 Jan 2006 12:09
Picon
Gravatar

Re: [groovy-dev] Remembering imports in groovy shell

Martin C. Martin schrieb:
> 
[...]
> 
> Can we get groovysh doing this?  :)

I think yes, but currently I am busy with the bytecode of nested 
closures and shared variables.

bye blackdrag
Permalink | Reply | 0 comments |
headers
Jochen Theodorou | 2 Jan 2006 12:22
Picon
Gravatar

Re: [groovy-dev] Scoping and trace backs

Rasmus Aveskogh schrieb:

[...]
> Is there any progress on the scoping issues?

I am currently working on this doing a nearly a rewrite of the scoping. 
The old scoping made some assumption that are no longer true. Regarding 
scirpts... I think here will change some things. Declared variables will 
no longer be part of the binding. You spoke of NPE problems, it would be 
nice to give examples. When thinking about scirpts I see a possibility 
for things like

println x.toString()

where x is undefined before and not definedin the binding... This is 
impossible to check since the compiler doesn't know the binding's 
varibales in general.

> Will there be better error handling and trace back support?

what do you mean with better error handling? For backtraces... when 
using groovy from the command line without the debug flag, you will not 
see most of the trace since it is filtered. So... can you please make 
your wishes more concrete?

Just to know that we have to do something here and there is good, but to 
know what we should do is much better ;)

bye blackdrag
(Continue reading)

Permalink | Reply | 4 comments |
headers
John Wilson | 2 Jan 2006 12:21
Picon

Re: [groovy-dev] backslash u in slashy string syntax


On 2 Jan 2006, at 10:23, Dierk Koenig wrote:

>
> but this doesn't work with \u since it expects a
> unicode char declaration to follow
>  assert '\\'==/\u/
>
> -> General error during parsing: Did not find four digit hex  
> character code.
>
> I appears like a missing parser capability to me.
> Should I raise a JIRA issue?

This is intended and expected behaviour:)

Groovy behaves exactly like Java in handling \u. These character  
sequences are processed before the lexer sees the character stream  
(see section 3.3 of the JLS). This can lead to surprising behaviour  
in Java (a \u000D in a literal string is flagged as an error).

I think there's an arguable case for making Groovy behave differently  
to Java in this case so I would suggest that you raise a JIRA  
enhancement request. Implementation is very slightly complicated by  
the fact that you can have an arbitrary number of 'u' characters  
between the '\' and the first hex digit. If you would like the  
behaviour to change it would be most helpful if you would explain in  
detail what new behaviour you would like to see.

John Wilson
(Continue reading)

Permalink | Reply | 21 comments |
headers
Rasmus Aveskogh | 2 Jan 2006 13:08
Picon

Re: [groovy-dev] Scoping and trace backs


> Rasmus Aveskogh schrieb:
>
> [...]
>> Is there any progress on the scoping issues?
>
> I am currently working on this doing a nearly a rewrite of the scoping.
> The old scoping made some assumption that are no longer true. Regarding
> scirpts... I think here will change some things. Declared variables will
> no longer be part of the binding. You spoke of NPE problems, it would be
> nice to give examples. When thinking about scirpts I see a possibility
> for things like
>
> println x.toString()
>
> where x is undefined before and not definedin the binding... This is
> impossible to check since the compiler doesn't know the binding's
> varibales in general.

This is the example code I wrote:

import groovy.xml.MarkupBuilder;

if (true) {
   foo = "bar";
}

PrintWriter screen = new PrintWriter(new OutputStreamWriter(System.out),
true);
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dierk Koenig | 2 Jan 2006 14:12
Favicon
Gravatar

RE: [groovy-dev] backslash u in slashy string syntax

> Groovy behaves exactly like Java in handling \u. 

The special thing in Groovy is the slashy syntax.
In Java, there always is the doubled backslash to define the single
backslash char. That could potentially be used for disambiguation.
With the Groovy slashy string syntax that is no longer possible.

> in Java (a \u000D in a literal string is flagged as an error).

should we do the same?

> If you would like the  
> behaviour to change it would be most helpful if you would explain in  
> detail what new behaviour you would like to see.

I'm not yet sure about all details but I would like to see 

 assert 'groovy\\util' == /groovy\util/

otherwise we need to document the slashy syntax as
"...backslashes need no escaping unless the 'u' char follows, which
makes this syntax unusable..."
That would be really weird.

Can anybody think of a good solution?

cheers
Mittie
(Continue reading)

Permalink | Reply | 20 comments |
headers
Jochen Theodorou | 2 Jan 2006 14:40
Picon
Gravatar

Re: [groovy-dev] Scoping and trace backs

Rasmus Aveskogh schrieb:

[...]
> This is the example code I wrote:
> 
> import groovy.xml.MarkupBuilder;
> 
> if (true) {
>    foo = "bar";
> }
> 
> PrintWriter screen = new PrintWriter(new OutputStreamWriter(System.out),
> true);
> 
> def someBuilder = new MarkupBuilder(screen);
> 
> someBuilder.pe() {
>    foo = 1;
> }
> 
> I get an NPE on foo, which is a bit odd.

indeed... can you please fill a jira issue for this and assing it to me? 
I think the problem will be solved after my scoping changes, but it is 
good to ahve a test case. And don't forget to add example code or it 
will be difficult to reproduce it.

>>>Will there be better error handling and trace back support?
>>
>>what do you mean with better error handling? For backtraces... when
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jochen Theodorou | 2 Jan 2006 14:43
Picon
Gravatar

Re: [groovy-dev] backslash u in slashy string syntax

Dierk Koenig schrieb:

[...]
>>in Java (a \u000D in a literal string is flagged as an error).
> 
> should we do the same?

wekk uit was a decision to support \u00D anywher in the code, for 
example or method names befor we implemented the regex-expression. Now 
we have a conflict here.

bye blackdrag.
Permalink | Reply | 1 comment |

Gmane