[groovy-user] [ANN]VTD-XML 2.10

[groovy-user] How to run GUI from Groovy Console

When I execute the following code from the Groovy Console, the whole
console exits! How do I modify the program so my program exits but
Groovy console does not so I can run the same program again?

Thanks,
siegfried

import javax.swing.JFrame;
import javax.swing.JLabel;

public class HelloWorldSwing {
  public static void main(String[] args) {
    JFrame frame = new JFrame("HelloWorldSwing");
    final JLabel label = new JLabel("Hello World");
    frame.getContentPane().add(label);

    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.pack();
    frame.setVisible(true);
  }
}

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] How to run GUI from Groovy Console

On Feb 28, 2011, at 6:29 PM, <siegfried@...>
<siegfried@...> wrote:
> When I execute the following code from the Groovy Console, the whole
> console exits! How do I modify the program so my program exits but
> Groovy console does not so I can run the same program again?
> 
> Thanks,
> siegfried
> 
> 
> 
> import javax.swing.JFrame;
> import javax.swing.JLabel;
> 
> public class HelloWorldSwing {
>  public static void main(String[] args) {
>    JFrame frame = new JFrame("HelloWorldSwing");
>    final JLabel label = new JLabel("Hello World");
>    frame.getContentPane().add(label);
> 
>    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

use DISPOSE_ON_CLOSE instead.  ^^^ will invoke System.exit();

--jason

>    frame.pack();
>    frame.setVisible(true);
>  }
> }
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
>    http://xircles.codehaus.org/manage_email
> 
> 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[groovy-user] println from second script is not redirected.

[groovy-user] Re: further processing of closure annotations

okay, i see. i found the corresponding code in AsmClassGenerator.visitAnnotationAttributes where
class ClosureWriter is used to generate the closure class for closure attributes.

it seems closure class generation in 1.7.8 is completely handled in
AsmClassGenerator.createClosureClass. i guess i have to copy large parts of
ClosureWriter.createClosureClass to introduce a custom closurewriter, to be compatible with closure
generation in 1.8.

Am 28.02.2011 um 22:58 schrieb Peter Niederwieser:

> I'd probably try one of the following:
> 
> 1. Rewrite the condition when the interface gets compiled (if necessary),
> compile it to a closure class (automatically done for you in Groovy 1.8),
> weave a call to the closure into implementing classes.
> 
> 2. Save the condition as a string, and recompile it to get back the AST when
> rewriting implementors. This is similar to what Spock does with failed
> assertions.
> 
> Cheers,
> Peter
> 
> 
> Andre Steingress wrote:
>> 
>> hi all,
>> 
>> i am currently working on interface contracts in gcontracts, that is,
>> allowing users to add  <at> Requires and  <at> Ensures to interface/abstract
>> methods.
>> 
>> in the end i am struggling with one central problem. i've done a few
>> attempts but none of them seemed to solve the following problem without
>> causing major (programmer) pain ;) 
>> 
>> let's assume we've got interface Stackable:
>> 
>> // ...
>> interface Stackable {
>> 
>>  <at> Requires({ !isEmpty() })
>> def pop()
>> 
>> boolean isEmpty()
>> }
>> 
>> during compilation of Stackable the closure expression is usually replaced
>> with some JVM compliant argument - Object.class, some String, etc. now
>> let's say we have a Stackable implementation class
>> 
>> // assume Stackable.class is already on the classpath 
>> class ArrayStack implements Stackable {
>> // ...
>> }
>> 
>> when compiling ArrayStack.groovy and Stackable.class is already on the
>> classpath, information about the interface's closure expression would
>> already be lost. some approaches that came to my mind in order to regain
>> access to closure expressions: regenerating the AST for all affected
>> interfaces, introducing a stub class implementing the interface and
>> partially reusing its byte-code (but that would force me to do some magic
>> with ASM), temporarily store the assertion's byte code as annotation
>> argument (it starts to hurt), ...
>> 
>> introducing an intermediate meta-data contract file would be an option,
>> but i want to get around doing this as long as possible. 
>> 
>> before i start to fiddle around with ASM byte code generation et al, i
>> wanted to know if you see a very obvious solution i've overlooked so far.
>> what would be the cleanest approach in terms of compliance to similar
>> parts in groovy?
>> 
>> thx in advance!
>> 
>> cheers, andre
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>> 
>>    http://xircles.codehaus.org/manage_email
>> 
>> 
>> 
>> 
> 
> -- 
> View this message in context: http://groovy.329449.n5.nabble.com/further-processing-of-closure-annotations-tp3404052p3404074.html
> Sent from the groovy - user mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
>    http://xircles.codehaus.org/manage_email
> 
> 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] println from second script is not redirected.

Re: [groovy-user] [ANN]VTD-XML 2.10

Re: [groovy-user] [ANN]VTD-XML 2.10

Re: [groovy-user] [ANN]VTD-XML 2.10

[groovy-user] Re: further processing of closure annotations

Andre Steingress wrote:
> 
> i guess i have to copy large parts of ClosureWriter.createClosureClass to
> introduce a custom closurewriter, to be compatible with closure generation
> in 1.8.
> 

Alternatively, you could only support interface contracts for Groovy 1.8 and
higher.

Cheers,
Peter

--

-- 
View this message in context: http://groovy.329449.n5.nabble.com/further-processing-of-closure-annotations-tp3404052p3404719.html
Sent from the groovy - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email