I don't think there is a way to tell GGTS to not insert the semicolon right now, but you could set up your formatter to remove semicolons then just format with CTRL + SHIFT + F after you generate code. From the menu go to Window -> Preferences -> Groovy -> Formatter and check Remove unnecessary semicolons.

Make sure that you're in the Grails perspective; that can impact some of the Groovy/Grails features and how Eclipse (even GGTS) leverages them. You'll find the perspective button in the upper right. If you're in Java or Debug, odd things like this may occur. Also, how are you creating and opening your Groovy files? Do you use the context menus or the Grails command prompt tool to issue orders like "create-controller"? If you're creating the files in some other way, try using those methods to generate them, and see if you get the same results.

Your app executes the JNI function very early, so that the debugger is not ready yet. Unfortunately, it takes a while for gdb to establish the remote connection, see http://visualgdb.com/documentation/appstartup Instead of fighting the windmills, add a button to your activity, and call the same native method onClick() of that button - it will be easier to catch the breakpoint. BTW, the warning about 95 libraries is perfectly normal. These are the system libraries which you don't want to debug, and don't have sources for.

No. Nothing is wrong. This is a limitation of groovy. It does not always produce a correct source locations for its class files. You are likely hitting a variant of http://jira.codehaus.org/browse/GROOVY-4505. We've fixed some of these problems, but more situations keep cropping up. That being said, I tried to reproduce using Groovy 1.8.6 and 2.1.5 and cannot. The debugger only stops on the expected line numbers. What versions of Groovy, Groovy-Eclipse and Eclipse are you using?

Turns out that instead of debugging it as a Remote Java Application, debugging it as a Web Application works. Still need to ensure that its in fact getting deployed to the correct tomcat installation directory. I've unchecked "Run built-in server" in the Debug Configuration for the Web Application type project. I've also ensured that eclipse has taken control of the tomcat installation identified in preferences. Manually setting the directory was not allowed as I had identified it separately in eclipse as THE tomcat installation dir.

That's the Groovy console, not the Grails console. They use the same code and look the same, but the Grails version hooks into the application, whereas the Groovy console just has access to the code. To run the console, go to Grails Tools | Open Grails Command Prompt and enter console in the text field. This is just a GUI wrapper for running grails console from the commandline.

First question: PDB files do not contain breakpoints info, they just have program information that enable debugging (matching statements with source code lines, etc ...) Second: Yes, that's the point of the remote debugger, so you can debug a remote process using your local visual studio.

This usually means the controllers aren't called. If it does work for certain controllers (within the same project) it just means: the code wont get called. So get a few steps up to see the correct controllers is called. (e.g. from the dispatch and then dive into until the controller gets loaded). And is it possible that you work remotely (e.g. from local to another server). Than it can take a little time before it the code is placed on the server. Just wait a few seconds and than try again. Since how can it break on a point that it doesn't know? Hope this helps to get you started to debugging it.

There is no such thing as "NodeClipse IDE" There are nodeclipse plugin (nodeclipse-1) Enide (set of plugins) Nodeclipse NTS (Eclipse distribution) You should have mentioned what exact version of Nodeclipse and Eclipse are you using. I am using Nodeclipse NTS 0.4.10 (based on Eclipse 4.3 Kepler) every day now. Just press F8 to resume. Since Nodeclipse 0.6 there is option to "no -break", that will use --debug without interrupting Node app on 1st line. From Node wiki There are 2 debug related node options: node --debug[=port] NodeApp.js node --debug-brk[=port] NodeApp.js The --debug option will just enable remote debugger connection on given port and then start the application normally. Even when debugger is connected to the running node instance later on, the sc

There are many issues, as indicated in the various comments. In summary: You don't check to see if your scanf() calls have succeeded. This could lead you to use those variables uninitialized. The way you are reading from matrix, you are only looking at the last N % 199 bytes of the last line (where the last line is N bytes long). Finally, you may be reading beyond your input buffer in this loop: for(gaps=0;gaps<4;letter++) if(buffer[letter]==' ') gaps++; If there are fewer than 4 gaps in the line, you will read beyond the end of the buffer looking for more gaps. You should stop at the end of the string. for(gaps=0;gaps<4;letter++) { if (buffer[letter]=='') break; if(buffer[letter]==' ') gaps++; }

I also obtain this error message. Also was troubles with the php.ini but more subtle. Try to find and delete a row like this extension=php_xdebug-... Consider to look at my answer here for details "Xdebug - command is not available".

You should be able to set up a conditional breakpoint by using a condition dependent on thread-local data. Two examples: Thread.currentThread().getName(), some value stored in a ThreadLocal.

Here's a standard solution. It makes it very easy to restore the previous window configuration. (winner-mode) (global-set-key (kbd "<f7>") 'winner-undo) (global-set-key (kbd "C-<f7>") 'winner-redo)

It is most likely a bug in the IDE, see Bug 384187. Are you using the latest Photran version? At How do I set breakpoints using the Photran IDE in Eclipse? it is claimed that this bug has already been fixed. If everything works properly (which it should), debugging in Eclipse is just as easy as it is in Matlab. Fortran has a long history in numerical computations that is why we have such a vast amount of legacy Fortran code. However, if I started learning a new programming language I would either learn C or C++.

I think what you are looking for is Array.prototype.push.apply( results, newContext.querySelectorAll( 'div') ); The push method you are looking for is a prototype method of Array type. or as a short hand [].push.apply( results, newContext.querySelectorAll( 'div') );

To avoid trace into the Delphi RTL units when you press F7, You must uncheck the option Use debug .dcus

I don't have a copy of 2008 to verify, but the newer editions (2010 and 2012) you can set a break point and then right click the red circle in the editor to unveil some options to provide a condition.

Any differences in killing processes by these two approaches? Yes. In DDMS, "Stop Process" kills the process. With "Force Stop", not only is the process killed, but it is moved into the "stopped" state, where nothing in that app will run again until somebody manually runs one of that app's components (typically: the user launches an activity from the home screen). You can read more about the stopped state in the Android 3.1 documentation.

The debugger highlights the code that is just about to be executed. When the debugger says you are in method b() it is simply telling you that it is about to debug method b()

The debugger is not lying. You're assuming that all the keys of the map should be stored in the private keySet field of the HashMap. But this is not the case. This variable is lazily populated when the keySet() method is called. Just look at the method implementation. If you want to know something about your map, use its documented, specified API: use the Display view, type functions.keySet(), right-click and choose "Evaluate", and then you'll really get the key set of the map.

Have you tried using m2e-wtp? Check out this screencast to see how web resource filtering works with profiles in m2e-wtp : http://goo.gl/RysBw Note the profile management UI comes from JBoss Tools and can be installed standalone.

No need to set breakpoints, F7 is the shortcut for "Debugger step into" which will do exactly what you're trying to do, step through the program stopping at every line. If you want to skip certain method calls, F8 ("Debugger step over") can also be helpful.

You need to debug the client code from the browser like firebug if running client in Firefox. Or Chrome Dev tool if Chrome is used. Here are the steps: From Eclipse, right click the 'index.html' file Goto Run-As menu --> Select JavaScript Web Application It will launch Web Browser and load the index.html file and Aptana internal server will be running without you doing anything. Browser setting is"Preferences/General/Web Browser" Then you can follow the firebug to debug if using Firefox and to set breakpoints.

localhost:9999 is what Eclipse is going to use to communicate with your application. On your browser, you still access your application on localhost:9000 (default) or however you would access your application had you just done play run. Basically, you've configured your debugging correctly in Eclipse. Now, with your configuration selected from the Debug Configuration, click Debug (or selected your configuration from the Debug As toolbar button). Eclipse will attach to localhost:9999. Browse to localhost:9000 like you normally would to access your application. That's it. Eclipse will pause on any breakpoints you have set, etc.

It seems that everybody should be seeing the same problem with node-inspector version 0.2.0beta4. The problem is in the way how breakpoints are managed: The front-end remembers break-points in browser's local storage and restores them after the relevant file is loaded. When you start mocha with --debug-brk and stop on the first line, your specfiles are not loaded yet, so the front-end does not restore your breakpoints. When you resume mocha execution, front-end can't restore breakpoints quickly enough in the short window between a specfile is parsed and run. In fact mocha may exit before the V8 debugger has a change to notify front-end about new scripts being parsed! Another workaround for this issue is to add debugger; statement in the specfile where you want to trigger a breakpoint.

I found the solution : I change the “ to ' So. the 168815 blabla/ product_group_and_eshop_global_id blaee/test/test "<unique_string>products in the</unique_string><TotalNumberUniquestring>2</TotalNumberUniquestring><currentNumberUniquestring>1</currentNumberUniquestring><div_OR_table_navigatin_instructions><divORTableForward_skip>1</divORTableForward_skip> <divForward_in>1</divForward_in></div_OR_table_navigatin_instructions><type_of_product_substring>SEARCH</type_of_product_substring><where_to_search_the_name>title</where_to_search_the_name><currency>$</currency><price_extraction_start_Key>$</price_extraction_start_Key><price_extraction_end_Key>&lt<

You can select multiple start-up projects from the solution's properties (set the Action to: Start with debugging) in order to use the debugger in both projects. As Ashley Medway pointed out, if the MVC applications starts the winforms app, the debugger won't handle the winforms app.

Right click on the project -> Configure -> Convert to Groovy project. Are you sure this project is not a maven or gradle project? The src/main/groovy source folder implies one of those.

If you put a debugger; statement and you're using IE, the browser will throw a "Script Debugging" error and prompt you for a debugging tool, you can select VS 2008 from the list. Make sure to have the "Disable Script Debugging" options in IE unchecked. Alternatively, you can use "Debug > Attach To Process" and attach the debugger to your browser processes, after that you can put a regular break point from visual studio on your javascript code and it will work.

It's been a while since i last saw 1.7 in the plugin. I guess it got outdated and removed. This page (near the bottom) tells that Groovy 1.7 is deprecated for GGTS (which, i guess, uses Groovy-eclipse): Deprecating of Groovy 1.7 support The Groovy 1.7 support in GGTS has been deprecated. It is still possible to install it for this release, but it will be removed in future releases. If you need to install the Groovy 1.7 compiler, then: Go to Help -> Install new software Choose the Springsource update site to work with Uncheck Group items by category, As shown in the image: Is that doesn't work, maybe you can try to install an older version of Groovy-eclipse from http://dist.springsource.org/.

Lets say you want to run "Test Case 1" which has multiple steps (13 in your case). It also has a groovy step "G1" (test index 1) from where you are initiating the test execution. What happens when you run the test Case from G1 is the test case executes its test steps 1 by one and as soon as it reaches G1 it start executing again because that's what you are doing in that step. Hence you end up with an infinite loop. What you should do is keep the step that starts the execution out of the test case that has to be executed. Traditionally such a script is called a driver script and is either a separate test case or outside the application itself. To solve your problem you could do one of the following. 1. Disable the step G1 from where you are starting the execution so that when the test ru

If you are not using the latest version of Groovy-Eclipse, try upgrading. Using Groovy-Eclipse 2.8.0, I can control String color in Preferences -> Groovy -> Editor right along with Bracket color, Operator color, etc.

You basically want a way to run groovy scripts from outside of Eclipse plugin. Then you can add it to your start menu or anywhere else you want. There are shell scripts called 'groovy' or 'groovy.bat' depending on your platform which is part of the Groovy runtime. Once the runtime is installed you can just run groovy like any other script groovy foo/MyScript.groovy [arguments] Take a look at Groovy - Running and this tutorial section.

this code works on my juno eclipse, junit 4.10 and groovy 2.0.6. i started with your code, but had to fool around with the imports as some of the annotations were red. i also had to add the .class to parameterized. import org.junit.Test import org.junit.runner.RunWith import org.junit.runners.Parameterized import org.junit.runners.Parameterized.Parameters @RunWith(Parameterized.class) public class TestParams { final int a public TestParams(int a) { this.a = a } @Parameters public static Collection<Object[]> data() { def cases = new Object[2][1] cases[0][0] = 3 cases[1][0] = 4 Arrays.asList(cases) } @Test public void test() { println "a = $a" } }

To initiate a method, main you must pass in a string array (String[] something). Use the following. public static void main(String[] args) { System.out.println("Hello World")! }

Maria-Helena I just hit this issue as well and discovered that facebook's scraper was appearing as a inbound JSON request. Since that particular route was set up to handle both JSON and HTML responses, FB was getting a big gnarly JSON blob instead of the actual web page. Not sure if this solves your exact problem, but hopefully sparks some fresh ideas!

You don't need to add declare(ticks) to all your files. one entry point would be enough: <?php function my_tick() { echo 'tick'; } register_tick_function('my_tick'); declare (ticks=1) { include("lib.php"); echo "1"; test(); } and lib.php: <?php echo "2"; function test(){ echo "3"; } and as you are looking for a code-based solution i assume your sources do provide single entry point.

Debuggers generally clears data, i.e. setting variables to zero. If you check for e.g. NULL pointers, but forget to initialize the variable(s) you check, then it will work in the debugger but not when you run the program outside the debugger.

Use byebug instead. It was created to overcome debugger's problems with ruby-2.0.0, like the one that makes it "step" when you use command "next", unexpectedly leading you to framework sources. Disclaimer: I'm byebug's author

I think the best solution here, is to use regexes. What this function does is pretty simple: you add a path to it, and it will scan that path for python files. If found one, open it in both read and write modes, and replaces all the text of pattern to repl, and then write the changes back to the file. Script: import os import re def fix_pys(path, pattern, repl): for root, dirs, files in os.walk(path): for f in files: name, ext = os.path.splitext(f) if ext == '.py': with open(os.path.join(root, f), 'r+') as py: new_py = re.sub(pattern, repl, py.read()) py.seek(0) py.write(new_py) py.truncate() Usage: fix_pys( '/Users/me/my_folder', r'type((w+))s*=