QGIS Planet

Processing just got a new testing framework to improve the long-term stability of this important plugin. And you can help to improve it, even if you are not a software developer! This is yet another piece in our never-stopping crusade to…

Dia is a nice cross platform application
for diagram drawing. It can be scripted via Python,
which opens the possibility to generate code from Dia diagrams.

Below we’ll create a python plugin that generates C code from UML state
machine diagrams. Doing the same for other languages should be trivial.

The first thing you need is Unai Estébanez Sevilla’s nice finite state
machine code generator. The version
that we are using here has been abstracted in order to be able to produce
code in various languages.

This python plugin implements an exporter
to C code. To use it, you need to put
it, along with the
base exporter into your local
plugins directory under ~/.dia/python.

Let’s have a quick look at the code.

First we import the dia python module and the exporter base functionality:

import dia
import uml_stm_export

Then we create our C exporter class that inherits from the generic
exporter:

class CDiagramRenderer(uml_stm_export.SimpleSTM):

Next we define how the beginning of our generated code file should look
like. That could include general infrastructure independent of the
state machine diagram at hand. In our case, we want to encapsulate the
generated state machine code within a function:

CODE_PREAMBLE="void config_stm(STM_t* stm) {"

We also define the postamble to close the function. After that come
generic functions that implement the class constructor
init(self) and functions responsible for calling
the dia object parser begin_render(self,data,filename).

Now we define our output generator end_render(self). We
first traverse dia’s objects in order to find the state machine’s
initial state:

Finally please permit me to thank all the people that created such a powerful
tool free for us to use:

Unai Estébanez Sevilla for the original STM generator

Steffen Macke and Hans Breuer, Dia’s current busy maintaners

Alexander Larsson, Dia’s original author

all the other contributors to Dia and free software

Panter for inviting me to their fabulous work week in
Greece where most of the hacking on the generator was done and
Combitool who supported this work by needing
a state machine generator in their current project.

PS: Unai’s original text generator is now also “just” a “simple” addon

Dia is a nice cross platform application
for diagram drawing. It can be scripted via Python,
which opens the possibility to generate code from Dia diagrams.

Below we’ll create a python plugin that generates C code from UML state
machine diagrams. Doing the same for other languages should be trivial.

The first thing you need is Unai Estébanez Sevilla’s nice finite state
machine code generator. The version
that we are using here has been abstracted in order to be able to produce
code in various languages.

This python plugin implements an exporter
to C code. To use it, you need to put
it, along with the
base exporter into your local
plugins directory under ~/.dia/python.

Let’s have a quick look at the code.

First we import the dia python module and the exporter base functionality:

import dia
import uml_stm_export

Then we create our C exporter class that inherits from the generic
exporter:

class CDiagramRenderer(uml_stm_export.SimpleSTM):

Next we define how the beginning of our generated code file should look
like. That could include general infrastructure independent of the
state machine diagram at hand. In our case, we want to encapsulate the
generated state machine code within a function:

CODE_PREAMBLE="void config_stm(STM_t* stm) {"

We also define the postamble to close the function. After that come
generic functions that implement the class constructor
init(self) and functions responsible for calling
the dia object parser begin_render(self,data,filename).

Now we define our output generator end_render(self). We
first traverse dia’s objects in order to find the state machine’s
initial state:

Finally please permit me to thank all the people that created such a powerful
tool free for us to use:

Unai Estébanez Sevilla for the original STM generator

Steffen Macke and Hans Breuer, Dia’s current busy maintaners

Alexander Larsson, Dia’s original author

all the other contributors to Dia and free software

Panter for inviting me to their fabulous work week in
Greece where most of the hacking on the generator was done and
Combitool who supported this work by needing
a state machine generator in their current project.

PS: Unai’s original text generator is now also “just” a “simple” addon

Abstract

Using string-eval in Ruby for metaprogramming is unnecessarily obscuring. Ruby’s more modern
and specific metaprogramming methods should be used instead whenever possible. This problem
is illustrated on the example of Ruby’s Forwardable class.

In detail…

Ruby’s Forwardable
class is using metaprogramming to forward calls from a frontend interface to an instance in the back
executing the call.

Metaprogramming is the discipline of making code that creates code. This task allready is rather
abstract and hard to grasp in itself. Having hard to grasp code is a liability. One of the goals
of writing code is allways to keep the code as simple and as well understandable as possible.

Additionaly, metaprogramming code itself is difficult to read and understand: that is because the
metaprogramming code will not necessarily express what the code it is creating is about, but only
how it is creating that code. As such the code it is creating can be invisible to you as a reader
of the source code - the created code will only start to exist at runtime.

One would therefore expect that programmers would try especially hard when they metaprogram to make
that particular kind of code expressive and easy to understand.

Another consequence of the fact that the code produced by metaprogramming is not necessarily visible,
is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the
programm works, but in addition, you won’t even be sure how the code that is executed looks like -
since it is only generated at runtime.

This post is focusing on the last problem: debugging of metaprogrammed code.

There are two approaches to metaprogramming. One is to have as far as possible compile-time parseable
code and the other is to let the code only be parsed at runtime.

As of version 1.9.2, Ruby’s Forwardable class is using the
latter. The metaprogramming code in Ruby 1.8.7 looks like this:

module_eval(<

As said, this has the consequence of the metaprogrammed code being completely invisible to the parser and other
tools such as editors and debuggers.

In other words, you are rather lost allready - otherwise you probably wouldn’t be stepping through
your code - and in that situation it happens that your debugger gets completely lost as well,
since it does not know any more where in the code it is and what it exactly is executing.

That’s nothing the programmer wishes for. In a situation where you are debugging you want to have
a maximally clear view of all state, including what code you are currently executing.

Chaning that situation requires making as much of the metaprogrammed code visible to the parser,
which is the second approach to metaprogramming mentioned previously:

Of course, with the string-eval approach to metaprogramming Ruby itself could do better by saving the string that is being
evaled to be able to refer to it later at step-through time. However currently we don’t have this option.

Abstract

Using string-eval in Ruby for metaprogramming is unnecessarily obscuring. Ruby’s more modern
and specific metaprogramming methods should be used instead whenever possible. This problem
is illustrated on the example of Ruby’s Forwardable class.

In detail…

Ruby’s Forwardable
class is using metaprogramming to forward calls from a frontend interface to an instance in the back
executing the call.

Metaprogramming is the discipline of making code that creates code. This task allready is rather
abstract and hard to grasp in itself. Having hard to grasp code is a liability. One of the goals
of writing code is allways to keep the code as simple and as well understandable as possible.

Additionaly, metaprogramming code itself is difficult to read and understand: that is because the
metaprogramming code will not necessarily express what the code it is creating is about, but only
how it is creating that code. As such the code it is creating can be invisible to you as a reader
of the source code - the created code will only start to exist at runtime.

One would therefore expect that programmers would try especially hard when they metaprogram to make
that particular kind of code expressive and easy to understand.

Another consequence of the fact that the code produced by metaprogramming is not necessarily visible,
is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the
programm works, but in addition, you won’t even be sure how the code that is executed looks like -
since it is only generated at runtime.

This post is focusing on the last problem: debugging of metaprogrammed code.

There are two approaches to metaprogramming. One is to have as far as possible compile-time parseable
code and the other is to let the code only be parsed at runtime.

As of version 1.9.2, Ruby’s Forwardable class is using the
latter. The metaprogramming code in Ruby 1.8.7 looks like this:

module_eval(<

As said, this has the consequence of the metaprogrammed code being completely invisible to the parser and other
tools such as editors and debuggers.

In other words, you are rather lost allready - otherwise you probably wouldn’t be stepping through
your code - and in that situation it happens that your debugger gets completely lost as well,
since it does not know any more where in the code it is and what it exactly is executing.

That’s nothing the programmer wishes for. In a situation where you are debugging you want to have
a maximally clear view of all state, including what code you are currently executing.

Chaning that situation requires making as much of the metaprogrammed code visible to the parser,
which is the second approach to metaprogramming mentioned previously:

Of course, with the string-eval approach to metaprogramming Ruby itself could do better by saving the string that is being
evaled to be able to refer to it later at step-through time. However currently we don’t have this option.

Abstract

Using string-eval in Ruby for metaprogramming is unnecessarily obscuring. Ruby’s more modern
and specific metaprogramming methods should be used instead whenever possible. This problem
is illustrated on the example of Ruby’s Forwardable class.

In detail…

Ruby’s Forwardable
class is using metaprogramming to forward calls from a frontend interface to an instance in the back
executing the call.

Metaprogramming is the discipline of making code that creates code. This task allready is rather
abstract and hard to grasp in itself. Having hard to grasp code is a liability. One of the goals
of writing code is allways to keep the code as simple and as well understandable as possible.

Additionaly, metaprogramming code itself is difficult to read and understand: that is because the
metaprogramming code will not necessarily express what the code it is creating is about, but only
how it is creating that code. As such the code it is creating can be invisible to you as a reader
of the source code - the created code will only start to exist at runtime.

One would therefore expect that programmers would try especially hard when they metaprogram to make
that particular kind of code expressive and easy to understand.

Another consequence of the fact that the code produced by metaprogramming is not necessarily visible,
is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the
programm works, but in addition, you won’t even be sure how the code that is executed looks like -
since it is only generated at runtime.

This post is focusing on the last problem: debugging of metaprogrammed code.

There are two approaches to metaprogramming. One is to have as far as possible compile-time parseable
code and the other is to let the code only be parsed at runtime.

As of version 1.9.2, Ruby’s Forwardable class is using the
latter. The metaprogramming code in Ruby 1.8.7 looks like this:

module_eval(<

As said, this has the consequence of the metaprogrammed code being completely invisible to the parser and other
tools such as editors and debuggers.

In other words, you are rather lost allready - otherwise you probably wouldn’t be stepping through
your code - and in that situation it happens that your debugger gets completely lost as well,
since it does not know any more where in the code it is and what it exactly is executing.

That’s nothing the programmer wishes for. In a situation where you are debugging you want to have
a maximally clear view of all state, including what code you are currently executing.

Chaning that situation requires making as much of the metaprogrammed code visible to the parser,
which is the second approach to metaprogramming mentioned previously:

Of course, with the string-eval approach to metaprogramming Ruby itself could do better by saving the string that is being
evaled to be able to refer to it later at step-through time. However currently we don’t have this option.

Abstract

Using string-eval in Ruby for metaprogramming is unnecessarily obscuring. Ruby’s more modern
and specific metaprogramming methods should be used instead whenever possible. This problem
is illustrated on the example of Ruby’s Forwardable class.

In detail…

Ruby’s Forwardable
class is using metaprogramming to forward calls from a frontend interface to an instance in the back
executing the call.

Metaprogramming is the discipline of making code that creates code. This task allready is rather
abstract and hard to grasp in itself. Having hard to grasp code is a liability. One of the goals
of writing code is allways to keep the code as simple and as well understandable as possible.

Additionaly, metaprogramming code itself is difficult to read and understand: that is because the
metaprogramming code will not necessarily express what the code it is creating is about, but only
how it is creating that code. As such the code it is creating can be invisible to you as a reader
of the source code - the created code will only start to exist at runtime.

One would therefore expect that programmers would try especially hard when they metaprogram to make
that particular kind of code expressive and easy to understand.

Another consequence of the fact that the code produced by metaprogramming is not necessarily visible,
is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the
programm works, but in addition, you won’t even be sure how the code that is executed looks like -
since it is only generated at runtime.

This post is focusing on the last problem: debugging of metaprogrammed code.

There are two approaches to metaprogramming. One is to have as far as possible compile-time parseable
code and the other is to let the code only be parsed at runtime.

As of version 1.9.2, Ruby’s Forwardable class is using the
latter. The metaprogramming code in Ruby 1.8.7 looks like this:

module_eval(<

As said, this has the consequence of the metaprogrammed code being completely invisible to the parser and other
tools such as editors and debuggers.

In other words, you are rather lost allready - otherwise you probably wouldn’t be stepping through
your code - and in that situation it happens that your debugger gets completely lost as well,
since it does not know any more where in the code it is and what it exactly is executing.

That’s nothing the programmer wishes for. In a situation where you are debugging you want to have
a maximally clear view of all state, including what code you are currently executing.

Chaning that situation requires making as much of the metaprogrammed code visible to the parser,
which is the second approach to metaprogramming mentioned previously:

Of course, with the string-eval approach to metaprogramming Ruby itself could do better by saving the string that is being
evaled to be able to refer to it later at step-through time. However currently we don’t have this option.

There are various approaches when trying to extend the Textile markup that RedCloth understands with own tags or syntax. Some approaches documented on the net have changed or don’t work any more, since RedCloth has been rewritten in Version 4.

Below is a fairly robust aproach, that is based on the assumption, that RedCloth leaves HTML tags inside the markup untouched and passes them on to the application consuming the translated markup.

The below code has been used in the Madek project. Madek, a Ruby On Rails application, uses irwi which provides a Wiki to Madek. And finally irwi uses RedCloth to do the rendering from Textile to HTML. That’s where we hook in.

We want to have a few special tags, which make the life of the Madek Wiki admin simpler, by letting him write the following inside the Textile markup:

There are various approaches when trying to extend the Textile markup that RedCloth understands with own tags or syntax. Some approaches documented on the net have changed or don’t work any more, since RedCloth has been rewritten in Version 4.

Below is a fairly robust aproach, that is based on the assumption, that RedCloth leaves HTML tags inside the markup untouched and passes them on to the application consuming the translated markup.

The below code has been used in the Madek project. Madek, a Ruby On Rails application, uses irwi which provides a Wiki to Madek. And finally irwi uses RedCloth to do the rendering from Textile to HTML. That’s where we hook in.

We want to have a few special tags, which make the life of the Madek Wiki admin simpler, by letting him write the following inside the Textile markup:

There are various approaches when trying to extend the Textile markup that RedCloth understands with own tags or syntax. Some approaches documented on the net have changed or don’t work any more, since RedCloth has been rewritten in Version 4.

Below is a fairly robust aproach, that is based on the assumption, that RedCloth leaves HTML tags inside the markup untouched and passes them on to the application consuming the translated markup.

The below code has been used in the Madek project. Madek, a Ruby On Rails application, uses irwi which provides a Wiki to Madek. And finally irwi uses RedCloth to do the rendering from Textile to HTML. That’s where we hook in.

We want to have a few special tags, which make the life of the Madek Wiki admin simpler, by letting him write the following inside the Textile markup:

Problem: I have a web site/page that I visit regularily which I want to annotate with my notes.

More specifically, I was regularly searching through the Homegate real estate hub looking for a new home. It goes without saying that I was again and again forgetting which objects I had already looked at, which objects were really interesting and I should check out more closely.

Therefore the need to annotate search results.

The here presented approach should be applicable for annotation of other web pages as well. It’s based on the observation, that restful web applications need to operate with asset IDs. These asset IDs can be reused to enrich the asset locally with additional data, such as notes. Thus we’re looking for those IDs in specific elements of the page and add a bit of HTML markup to those places.

Of course that aproach only works as long as the web site doesn’t heavily change its markup and doesn’t rendomly change asset IDs.

The idea is simple: add an input box to each search result, where you write your comment. When the focus leaves the input box, the comment is stored to localStorage.

Starting with Greasemonkey is quite easy. There are howtos and templates to start from, such as this one.

However, regular JavaScripting and Greasemonkey JavaScripting do not work in exactly the same way:

One of the differences is that Greasemonkey creates a separate JavaScript environment, in which the Greasemonkey scripts are executed. That is calling Javascript contained in the page from Greasemonkey and the inverse calling Greasemonkey scripts from the page is not possible by default. This is on purpose, so that the web page can not detect and not interfere with the Greasemonkey scripts, because you want your Greasemonkey scripts to work allways on some page, whether or not that page likes it or not. Therefore no interference is possible.

Greasemonkey however provides a standard way to access the web page’s scripts, and that’s through the “unsafeWindow” object, which is a reference to the web page’s environment.

I had two mechanisms I had to make accessible using the “unsafeWindow” handle:

the first was accessing JQuery, which is included by default by the Homegate page. Since I needed to use JQuery functions in my Greasemonkey script, I got a reference to it via the standard Greasemonkey precedure:

var jQuery = unsafeWindow['jQuery'];

the second mechanism that needed to cross the boundaries between the web page and Greasemonkey was callbacks from the web page to my Greasemonkey script. This is necessary, because I’m attaching “input” elements to each search result, which contain a note and which, “onblur”, need to call a function that saves the content of the input box. Here’s part that constructs the input element:

The next interesting thing you’ll note is usage of ‘locaStorage’. Support for the latter in browsers does not seem mature yet. One problem I’ve encountered when developing under Firefox 3.6 was that saving to ‘localStorage’ was not possible when cookies were disabled (see this report). Thus you’ll need to permanently enable cookies for Homegate in order for the script to be able to save its data.

Finally, while developing, a major problem was, that Firefox did not show me errors in the Greasemonkey scripts. Thus either the script would work or not work and fail completely silently. That made debugging a bit painful.

Problem: I have a web site/page that I visit regularily which I want to annotate with my notes.

More specifically, I was regularly searching through the Homegate real estate hub looking for a new home. It goes without saying that I was again and again forgetting which objects I had already looked at, which objects were really interesting and I should check out more closely.

Therefore the need to annotate search results.

The here presented approach should be applicable for annotation of other web pages as well. It’s based on the observation, that restful web applications need to operate with asset IDs. These asset IDs can be reused to enrich the asset locally with additional data, such as notes. Thus we’re looking for those IDs in specific elements of the page and add a bit of HTML markup to those places.

Of course that aproach only works as long as the web site doesn’t heavily change its markup and doesn’t rendomly change asset IDs.

The idea is simple: add an input box to each search result, where you write your comment. When the focus leaves the input box, the comment is stored to localStorage.

Starting with Greasemonkey is quite easy. There are howtos and templates to start from, such as this one.

However, regular JavaScripting and Greasemonkey JavaScripting do not work in exactly the same way:

One of the differences is that Greasemonkey creates a separate JavaScript environment, in which the Greasemonkey scripts are executed. That is calling Javascript contained in the page from Greasemonkey and the inverse calling Greasemonkey scripts from the page is not possible by default. This is on purpose, so that the web page can not detect and not interfere with the Greasemonkey scripts, because you want your Greasemonkey scripts to work allways on some page, whether or not that page likes it or not. Therefore no interference is possible.

Greasemonkey however provides a standard way to access the web page’s scripts, and that’s through the “unsafeWindow” object, which is a reference to the web page’s environment.

I had two mechanisms I had to make accessible using the “unsafeWindow” handle:

the first was accessing JQuery, which is included by default by the Homegate page. Since I needed to use JQuery functions in my Greasemonkey script, I got a reference to it via the standard Greasemonkey precedure:

var jQuery = unsafeWindow['jQuery'];

the second mechanism that needed to cross the boundaries between the web page and Greasemonkey was callbacks from the web page to my Greasemonkey script. This is necessary, because I’m attaching “input” elements to each search result, which contain a note and which, “onblur”, need to call a function that saves the content of the input box. Here’s part that constructs the input element:

The next interesting thing you’ll note is usage of ‘locaStorage’. Support for the latter in browsers does not seem mature yet. One problem I’ve encountered when developing under Firefox 3.6 was that saving to ‘localStorage’ was not possible when cookies were disabled (see this report). Thus you’ll need to permanently enable cookies for Homegate in order for the script to be able to save its data.

Finally, while developing, a major problem was, that Firefox did not show me errors in the Greasemonkey scripts. Thus either the script would work or not work and fail completely silently. That made debugging a bit painful.

Problem: I have a web site/page that I visit regularily which I want to annotate with my notes.

More specifically, I was regularly searching through the Homegate real estate hub looking for a new home. It goes without saying that I was again and again forgetting which objects I had already looked at, which objects were really interesting and I should check out more closely.

Therefore the need to annotate search results.

The here presented approach should be applicable for annotation of other web pages as well. It’s based on the observation, that restful web applications need to operate with asset IDs. These asset IDs can be reused to enrich the asset locally with additional data, such as notes. Thus we’re looking for those IDs in specific elements of the page and add a bit of HTML markup to those places.

Of course that aproach only works as long as the web site doesn’t heavily change its markup and doesn’t rendomly change asset IDs.

The idea is simple: add an input box to each search result, where you write your comment. When the focus leaves the input box, the comment is stored to localStorage.

Starting with Greasemonkey is quite easy. There are howtos and templates to start from, such as this one.

However, regular JavaScripting and Greasemonkey JavaScripting do not work in exactly the same way:

One of the differences is that Greasemonkey creates a separate JavaScript environment, in which the Greasemonkey scripts are executed. That is calling Javascript contained in the page from Greasemonkey and the inverse calling Greasemonkey scripts from the page is not possible by default. This is on purpose, so that the web page can not detect and not interfere with the Greasemonkey scripts, because you want your Greasemonkey scripts to work allways on some page, whether or not that page likes it or not. Therefore no interference is possible.

Greasemonkey however provides a standard way to access the web page’s scripts, and that’s through the “unsafeWindow” object, which is a reference to the web page’s environment.

I had two mechanisms I had to make accessible using the “unsafeWindow” handle:

the first was accessing JQuery, which is included by default by the Homegate page. Since I needed to use JQuery functions in my Greasemonkey script, I got a reference to it via the standard Greasemonkey precedure:

var jQuery = unsafeWindow['jQuery'];

the second mechanism that needed to cross the boundaries between the web page and Greasemonkey was callbacks from the web page to my Greasemonkey script. This is necessary, because I’m attaching “input” elements to each search result, which contain a note and which, “onblur”, need to call a function that saves the content of the input box. Here’s part that constructs the input element:

The next interesting thing you’ll note is usage of ‘locaStorage’. Support for the latter in browsers does not seem mature yet. One problem I’ve encountered when developing under Firefox 3.6 was that saving to ‘localStorage’ was not possible when cookies were disabled (see this report). Thus you’ll need to permanently enable cookies for Homegate in order for the script to be able to save its data.

Finally, while developing, a major problem was, that Firefox did not show me errors in the Greasemonkey scripts. Thus either the script would work or not work and fail completely silently. That made debugging a bit painful.

User Defined Variables

Clear Loop Variable

This step is not strictly necessary in our example here, however if you want to reuse this sequence of steps more than one time - that is call it from different places, then you need to clear the loop variable first.

Debug

Since creating these steps was not easy, I’ve put a debug statement in so that I see, when JMeter calls into these steps and to see how the variables are set.

The While Controler

Here we really start the loop.

I’m not sure whether if would be better to use BeanShell commands here instead - using JavaScript to test the loop condition works in any case…

Getting the page

We get the page we want to check.

Extract the data we want to check from the page and assign it to our loop variable

Make sure our request is not being cached

It’s better - as far as we can - to be sure we force the web application to recreate the page we’re waiting for to change. I’m not sure I’ve done it right here, however it works:

We use a “Cookie Manager” to carry forward cookies between calls

We set up our variables

The idea here being that we predefine the variables, so they would show up in the “Debug Sampler” which makes debugging easier, because you see at each step, whether the variable has the correct value or not. I do predefine the variables with a “non-value” so that I can see immediately whether the variable has been already assigned something during the execution of the test or not.

We go to a form submit page

We extract the AUTHTOKEN from that form

(The auth token is being used by the web application to prevent cross-site-scripting)

Notice that the extractor is set to extract the string from the HTTP reply-body.

We also extract the session cookie

This is because we want to pass the cookie to an outside application, so that it can call the web app from within the same session.

Notice that this time we told the extractor to extract the string from the HTTP reply-headers.

We now use all our extracted parameters to submit our order

Note that:

we are passing the AUTHTOKEN along with the HTTP POST

since we are not sure whether possibly the AUTHTOKEN contains some problematic character (in my case it was an equal sign ‘=’ that was interferring with the parameter encoding) we tell JMeter to URL-encode the string.

we also pass along another parameter telling the web app what we’re interested in getting back from our order

we are using HTTPS

Submitting the order will redirect us to the page that’ll show us the resulting order.

We extract the ORDER_ID from HTTP headers which would otherwise redirect us to the resulting page

The headers contain the location of the resulting order page where we would be redirected to.

Finally we download the resulting artefact with curl

Note that:

we are passing the SESSION_COOKIE to curl to be able to download the artifact in the same (potentially authenticated) session.

Upon starting JMeter you’ll see two branches: “Test Plan” and “WorkBench”.

“Test Plan” is the place where your tests will live.

What the purpose of “WorkBench” is, is not really clear. It seems to be meant to be a place to do your throw-away experimentation.

The really crucial “trap” of the “WorkBench” is however, that JMeter will throw away whatever you put into the “WorkBench” upon exit. JMeter will not save the contents of the “WorkBench” if you tell it to “Save” your work and you’ll loose whatever is in there. It will only save the contents of the “Test Plan” branch.

So be ware of putting anything in the “Work Bench”. You’re bound to get burned.

As tests get larger, or as steps need to be repeated you’ll want to structure your tests into distinct entities - these seem to be called “Modules” in JMeter.

However, there is no “Module” element JMeter. As a “Module” you can however use the “Simple Controller”. It allows you to drop other elements into it and to name them as a whole. I don’t know whether it has additional features such as providing scoping of any kind.

Thus if you need to “call” the same set of steps from different places, then you can place them in a “Simple Controller”. However you’ll need to place that controller somewhere and as such it will get executed in that place and order. You can prevent it being executed by disabling it:

even though being disabled, components inside a Controller still can be called and executed. Therefore, you can use a disabled “Simple Controller” as a repository for reusable components or modules:

On the picture you can see a “module repository” and a call to a specific “Module” inside it.

the “Debug Sampler” will emit “everything that’s known” to JMeter. That output can be displayed in the “View Results Tree Listener”:

have a look at the JMeter log file (which is usually dumped from where you’ve started JMeter)

check the output of one of the listeners such as the “View Results Tree Listener”.

if you need to debug regexes of a “Regular Expression Extractor” then you can have a look at the source code of the page you want to extract a value from inside the “View Results Tree Llistener” and enter the same regular expression in the “Search” field (searching is only implemented in JMeter > v2.4).

In that picture you can see JMeter matching and displaying the regex entered in the search field inside an HTML page retrieved though the “HTTP Client Sampler”.