You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by D G <dm...@gmail.com> on 2012/06/13 14:11:00 UTC
new __Time function
For full context see here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53362
Needed a __time function with the ability to add n days before
returning a date string so I created one.
I'd happily create a new function or append the current one. Would
users prefer a
__time(format, variable, +/-Days) (reordered for compatebility)
where Days is the amount of days to add or subtract before returning a
formatted string.
or a new function?
proposal:
__timeMath(format, number, m|h|d|w|M|y**, variable)
** applied to number, ie +/- 1 minute, hour, day, week, month or year.
Only one option is possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: new __Time function
Posted by D G <dm...@gmail.com>.
Fair enough, I'll assume i'm the only one that needs a date other than
'right now' easily.
Same probably goes for stuff like 'hex2text', I added an extra view
mode to the TCP sampler which automatically converts hex to ascii. The
application I'm working with tends to require hex input, returning hex
output and I was tired of manually converting it :) If anyone is
interested I'll submit it.
I'll have a look at the bugs/enhancements list sometime and see if
there's anything I'd like to tackle.
On Fri, Jun 15, 2012 at 5:23 PM, sebb <se...@gmail.com> wrote:
> On 15 June 2012 16:12, D G <dm...@gmail.com> wrote:
>> I'd like to point at that I wanted to keep it simple. Just __Time
>> extended with a _tiny_ bit of extra functionality: +/- n days.
>> If I can modify JMeter to suit my tastes you can be reasonably sure I
>> can write a little beanshell script in order to accomplish this.
>> I was simply surprised that there wasn't a 'tomorrow' function (__TIme
>> + 1) already and offered to implement one but the feature creep so far
>> is quite impressive :)
>>
>> So just to be clear: I agree with you. But I'm asking the community
>> what they'd like and that seems to be: 'everything'. Which I admit has
>> a use case of course.
>
> I'm not sure it's true that the community want 'everything'.
>
> There have not yet been any use cases (apart from yours).
>
> There have been some implementation suggestions, but AFAICT that is
> from a developer point of view, not a user.
>
>> On Fri, Jun 15, 2012 at 5:04 PM, Sergio Boso <se...@bosoconsulting.it> wrote:
>>>
>>> Il 15/06/2012 10:13, D G ha scritto:
>>>
>>>> This all started as 'now + n days', so the __timeAdd methods works on
>>>> a now + something manner.
>>>>
>>>> New proposal:
>>>> __timeAdd(format, number*, m|h|d|w|M|y**, parseString, parseFormat,
>>>> variable)
>>>> where parseString is the string to be parsed into a date object and
>>>> ParseFormat is the format of the string to be parsed.
>>>
>>> I use to do that kind of things in Javascript, in a BSF pre or post
>>> processor.
>>>
>>> It takes just few lines of code, according to what you want to do.
>>>
>>> I'm keen to understand what would be the advantages of an integrated
>>> solution.
>>>
>>> regards
>>> Sergio
>>>
>>>> My criticism would be the growing number of (optional) parameters but
>>>> it's too easy to lose __Functions somewhere in a test. Don't like
>>>> using two functions to accomplish a task :)
>>>> Another would be requiring some knowledge of how Java parses data.
>>>> Though that should be reasonably trivial to learn for most strings.
>>>>
>>>> Also, it would be quite easy to allow parseString to accept a
>>>> float/epoch time and work with that.
>>>>
>>>> Thoughts?
>>>>
>>>> Regards,
>>>> Daniel
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> In caso di erronea ricezione da parte di persona diversa, siete pregati di
>>> eliminare il messaggio e i suoi allegati in modo definitivo dai vostri
>>> archivi e di volercelo comunicare immediatamente restituendoci il messaggio
>>> via e-mail al seguente indirizzosergio@bosoconsulting.it
>>> <ma...@yahoo.it>
>>> L’interessato può, inoltre, esercitare tutti i diritti di accesso sui propri
>>> dati previsti dal decreto 196/2003, tra i quali i diritti di rettifica,
>>> aggiornamento e cancellazione, inviando un messaggio
>>> all’indirizzo:sergio@bosoconsulting.it <ma...@yahoo.it>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: new __Time function
Posted by sebb <se...@gmail.com>.
On 15 June 2012 16:12, D G <dm...@gmail.com> wrote:
> I'd like to point at that I wanted to keep it simple. Just __Time
> extended with a _tiny_ bit of extra functionality: +/- n days.
> If I can modify JMeter to suit my tastes you can be reasonably sure I
> can write a little beanshell script in order to accomplish this.
> I was simply surprised that there wasn't a 'tomorrow' function (__TIme
> + 1) already and offered to implement one but the feature creep so far
> is quite impressive :)
>
> So just to be clear: I agree with you. But I'm asking the community
> what they'd like and that seems to be: 'everything'. Which I admit has
> a use case of course.
I'm not sure it's true that the community want 'everything'.
There have not yet been any use cases (apart from yours).
There have been some implementation suggestions, but AFAICT that is
from a developer point of view, not a user.
> On Fri, Jun 15, 2012 at 5:04 PM, Sergio Boso <se...@bosoconsulting.it> wrote:
>>
>> Il 15/06/2012 10:13, D G ha scritto:
>>
>>> This all started as 'now + n days', so the __timeAdd methods works on
>>> a now + something manner.
>>>
>>> New proposal:
>>> __timeAdd(format, number*, m|h|d|w|M|y**, parseString, parseFormat,
>>> variable)
>>> where parseString is the string to be parsed into a date object and
>>> ParseFormat is the format of the string to be parsed.
>>
>> I use to do that kind of things in Javascript, in a BSF pre or post
>> processor.
>>
>> It takes just few lines of code, according to what you want to do.
>>
>> I'm keen to understand what would be the advantages of an integrated
>> solution.
>>
>> regards
>> Sergio
>>
>>> My criticism would be the growing number of (optional) parameters but
>>> it's too easy to lose __Functions somewhere in a test. Don't like
>>> using two functions to accomplish a task :)
>>> Another would be requiring some knowledge of how Java parses data.
>>> Though that should be reasonably trivial to learn for most strings.
>>>
>>> Also, it would be quite easy to allow parseString to accept a
>>> float/epoch time and work with that.
>>>
>>> Thoughts?
>>>
>>> Regards,
>>> Daniel
>>>
>>>
>>
>>
>> --
>>
>>
>> In caso di erronea ricezione da parte di persona diversa, siete pregati di
>> eliminare il messaggio e i suoi allegati in modo definitivo dai vostri
>> archivi e di volercelo comunicare immediatamente restituendoci il messaggio
>> via e-mail al seguente indirizzosergio@bosoconsulting.it
>> <ma...@yahoo.it>
>> L’interessato può, inoltre, esercitare tutti i diritti di accesso sui propri
>> dati previsti dal decreto 196/2003, tra i quali i diritti di rettifica,
>> aggiornamento e cancellazione, inviando un messaggio
>> all’indirizzo:sergio@bosoconsulting.it <ma...@yahoo.it>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: new __Time function
Posted by D G <dm...@gmail.com>.
I'd like to point at that I wanted to keep it simple. Just __Time
extended with a _tiny_ bit of extra functionality: +/- n days.
If I can modify JMeter to suit my tastes you can be reasonably sure I
can write a little beanshell script in order to accomplish this.
I was simply surprised that there wasn't a 'tomorrow' function (__TIme
+ 1) already and offered to implement one but the feature creep so far
is quite impressive :)
So just to be clear: I agree with you. But I'm asking the community
what they'd like and that seems to be: 'everything'. Which I admit has
a use case of course.
On Fri, Jun 15, 2012 at 5:04 PM, Sergio Boso <se...@bosoconsulting.it> wrote:
>
> Il 15/06/2012 10:13, D G ha scritto:
>
>> This all started as 'now + n days', so the __timeAdd methods works on
>> a now + something manner.
>>
>> New proposal:
>> __timeAdd(format, number*, m|h|d|w|M|y**, parseString, parseFormat,
>> variable)
>> where parseString is the string to be parsed into a date object and
>> ParseFormat is the format of the string to be parsed.
>
> I use to do that kind of things in Javascript, in a BSF pre or post
> processor.
>
> It takes just few lines of code, according to what you want to do.
>
> I'm keen to understand what would be the advantages of an integrated
> solution.
>
> regards
> Sergio
>
>> My criticism would be the growing number of (optional) parameters but
>> it's too easy to lose __Functions somewhere in a test. Don't like
>> using two functions to accomplish a task :)
>> Another would be requiring some knowledge of how Java parses data.
>> Though that should be reasonably trivial to learn for most strings.
>>
>> Also, it would be quite easy to allow parseString to accept a
>> float/epoch time and work with that.
>>
>> Thoughts?
>>
>> Regards,
>> Daniel
>>
>>
>
>
> --
>
>
> In caso di erronea ricezione da parte di persona diversa, siete pregati di
> eliminare il messaggio e i suoi allegati in modo definitivo dai vostri
> archivi e di volercelo comunicare immediatamente restituendoci il messaggio
> via e-mail al seguente indirizzosergio@bosoconsulting.it
> <ma...@yahoo.it>
> L’interessato può, inoltre, esercitare tutti i diritti di accesso sui propri
> dati previsti dal decreto 196/2003, tra i quali i diritti di rettifica,
> aggiornamento e cancellazione, inviando un messaggio
> all’indirizzo:sergio@bosoconsulting.it <ma...@yahoo.it>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: new __Time function
Posted by Sergio Boso <se...@bosoconsulting.it>.
Il 15/06/2012 10:13, D G ha scritto:
> This all started as 'now + n days', so the __timeAdd methods works on
> a now + something manner.
>
> New proposal:
> __timeAdd(format, number*, m|h|d|w|M|y**, parseString, parseFormat, variable)
> where parseString is the string to be parsed into a date object and
> ParseFormat is the format of the string to be parsed.
I use to do that kind of things in Javascript, in a BSF pre or post processor.
It takes just few lines of code, according to what you want to do.
I'm keen to understand what would be the advantages of an integrated solution.
regards
Sergio
> My criticism would be the growing number of (optional) parameters but
> it's too easy to lose __Functions somewhere in a test. Don't like
> using two functions to accomplish a task :)
> Another would be requiring some knowledge of how Java parses data.
> Though that should be reasonably trivial to learn for most strings.
>
> Also, it would be quite easy to allow parseString to accept a
> float/epoch time and work with that.
>
> Thoughts?
>
> Regards,
> Daniel
>
>
--
In caso di erronea ricezione da parte di persona diversa, siete pregati di eliminare il messaggio e i suoi allegati in modo
definitivo dai vostri archivi e di volercelo comunicare immediatamente restituendoci il messaggio via e-mail al seguente
indirizzosergio@bosoconsulting.it <ma...@yahoo.it>
L’interessato può, inoltre, esercitare tutti i diritti di accesso sui propri dati previsti dal decreto 196/2003, tra i quali i
diritti di rettifica, aggiornamento e cancellazione, inviando un messaggio all’indirizzo:sergio@bosoconsulting.it
<ma...@yahoo.it>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: new __Time function
Posted by D G <dm...@gmail.com>.
This all started as 'now + n days', so the __timeAdd methods works on
a now + something manner.
New proposal:
__timeAdd(format, number*, m|h|d|w|M|y**, parseString, parseFormat, variable)
where parseString is the string to be parsed into a date object and
ParseFormat is the format of the string to be parsed.
My criticism would be the growing number of (optional) parameters but
it's too easy to lose __Functions somewhere in a test. Don't like
using two functions to accomplish a task :)
Another would be requiring some knowledge of how Java parses data.
Though that should be reasonably trivial to learn for most strings.
Also, it would be quite easy to allow parseString to accept a
float/epoch time and work with that.
Thoughts?
Regards,
Daniel
On Thu, Jun 14, 2012 at 10:53 PM, sebb <se...@gmail.com> wrote:
> On 14 June 2012 21:38, Philippe Mouawad <ph...@gmail.com> wrote:
>> Hello,
>> I prefer:
>> __timeAdd(format, number*, m|h|d|w|M|y**, variable)
>> * can be negative
>> ** applied to number, ie +/- 1 minute, hour, day, week, month or year.
>> Only one option is possible.
>
> What about the base time?
>
> The current proposal would only allow the user to adjust the current time.
> Each time it is invoked the base time may vary.
>
> Is there any need to apply the calculation to a pre-defined time, e.g.
> one extracted from a sampler response?
>
> Or perhaps to call __time() to set up a variable, and then use
> __timeAdd() to create various different times from it?
>
> If we are going to add a time calculator function, it should be as
> versatile as possible, without being too complicated to use or
> implement.
>
>> Regards
>> Philippe M.
>>
>> On Wed, Jun 13, 2012 at 2:11 PM, D G <dm...@gmail.com> wrote:
>>
>>> For full context see here:
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=53362
>>>
>>> Needed a __time function with the ability to add n days before
>>> returning a date string so I created one.
>>>
>>> I'd happily create a new function or append the current one. Would
>>> users prefer a
>>>
>>> __time(format, variable, +/-Days) (reordered for compatebility)
>>>
>>> where Days is the amount of days to add or subtract before returning a
>>> formatted string.
>>>
>>> or a new function?
>>>
>>> proposal:
>>>
>>> __timeMath(format, number, m|h|d|w|M|y**, variable)
>>>
>>> ** applied to number, ie +/- 1 minute, hour, day, week, month or year.
>>> Only one option is possible.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>>> For additional commands, e-mail: user-help@jmeter.apache.org
>>>
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: new __Time function
Posted by sebb <se...@gmail.com>.
On 14 June 2012 21:38, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello,
> I prefer:
> __timeAdd(format, number*, m|h|d|w|M|y**, variable)
> * can be negative
> ** applied to number, ie +/- 1 minute, hour, day, week, month or year.
> Only one option is possible.
What about the base time?
The current proposal would only allow the user to adjust the current time.
Each time it is invoked the base time may vary.
Is there any need to apply the calculation to a pre-defined time, e.g.
one extracted from a sampler response?
Or perhaps to call __time() to set up a variable, and then use
__timeAdd() to create various different times from it?
If we are going to add a time calculator function, it should be as
versatile as possible, without being too complicated to use or
implement.
> Regards
> Philippe M.
>
> On Wed, Jun 13, 2012 at 2:11 PM, D G <dm...@gmail.com> wrote:
>
>> For full context see here:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=53362
>>
>> Needed a __time function with the ability to add n days before
>> returning a date string so I created one.
>>
>> I'd happily create a new function or append the current one. Would
>> users prefer a
>>
>> __time(format, variable, +/-Days) (reordered for compatebility)
>>
>> where Days is the amount of days to add or subtract before returning a
>> formatted string.
>>
>> or a new function?
>>
>> proposal:
>>
>> __timeMath(format, number, m|h|d|w|M|y**, variable)
>>
>> ** applied to number, ie +/- 1 minute, hour, day, week, month or year.
>> Only one option is possible.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: new __Time function
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
I prefer:
__timeAdd(format, number*, m|h|d|w|M|y**, variable)
* can be negative
** applied to number, ie +/- 1 minute, hour, day, week, month or year.
Only one option is possible.
Regards
Philippe M.
On Wed, Jun 13, 2012 at 2:11 PM, D G <dm...@gmail.com> wrote:
> For full context see here:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53362
>
> Needed a __time function with the ability to add n days before
> returning a date string so I created one.
>
> I'd happily create a new function or append the current one. Would
> users prefer a
>
> __time(format, variable, +/-Days) (reordered for compatebility)
>
> where Days is the amount of days to add or subtract before returning a
> formatted string.
>
> or a new function?
>
> proposal:
>
> __timeMath(format, number, m|h|d|w|M|y**, variable)
>
> ** applied to number, ie +/- 1 minute, hour, day, week, month or year.
> Only one option is possible.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
--
Cordialement.
Philippe Mouawad.