RE: How should no-op setter methods be filed in Bugzilla?

[Felix Schumacher]

Am 28. November 2016 20:18:22 MEZ, schrieb "Epp, Jeremiah W (Contractor)" 
:
>Whoops, forgot to address this after my machine was rebooted by a power
>outage and then work got in the way.  Sorry about that.
>
>> -Original Message-
>> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
>> Sent: Tuesday, November 15, 2016 2:51 PM
>> To: dev@jmeter.apache.org
>> Subject: Re: How should no-op setter methods be filed in Bugzilla?
>>
>> Am 14.11.2016 um 20:20 schrieb Epp, Jeremiah W (Contractor):
 -Original Message-
 From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]

 I have attached a test case that models this, with the only
>downside,
 that it works with current trunk.
>>>
>>> Thank you, though I have to admit I'm not sure how to correctly run
>that.
>>> Unfortunately, nor do I really have time to get deep in this problem
>right
>>> now.  The example was really just to show the _class_ of problem
>I've had to
>>> work around. There have been a slew of these.
>>
>> Is this class of problems, those classes, that use instance variables
>for
>> state instead of jmeter-properties?
>
>Beg your pardon?  I was saying its representative of a category of
>similar
>examples that only differ in the class and method name.

The class you mentioned uses an instance variable instead of using 
this.setProperty(...), so I thought that this might be your problem and wanted 
to ask, of the other examples you found, have the same property (that is, not 
using setProperty).

>
>>> Let's try this: if you were going to export those postProcessors in
>your
>>> test to a JMX file on the disk, what would the code look like?
>>
>> Well, if I remember correctly, you are using JMeter in quite some
>> interesting ways, that are not the usual ones. So it may very well
>be,
>> that you find interesting behaviour.
>
>I'd say it's a moderately interesting application at most.  I've only
>had to
>extend one class; 99% of what I have is pretty obvious use of the APIs.
>
>> The only way I save elements is to let JMeter save them and I haven't
>> looked to deeply into that, yet.
>
>I've tried.  XStream is kind of obtuse, and I'm still trying to figure
>out
>the point where the data structure is lowered to a HashTree that
>SaveService
>can work with.  If I knew that, I might be able to _fix_ it.

I would love to hear more about this, when you have something to report here.

Regards,
Felix

>
>Regards,
>Wyatt
>
>Confidentiality Notice: This electronic message transmission, including
>any attachment(s), may contain confidential, proprietary, or privileged
>information from Chemical Abstracts Service ("CAS"), a division of the
>American Chemical Society ("ACS"). If you have received this
>transmission in error, be advised that any disclosure, copying,
>distribution, or use of the contents of this information is strictly
>prohibited. Please destroy all copies of the message and contact the
>sender immediately by either replying to this message or calling
>614-447-3600.

RE: How should no-op setter methods be filed in Bugzilla?

[Epp, Jeremiah W (Contractor)]

Whoops, forgot to address this after my machine was rebooted by a power
outage and then work got in the way.  Sorry about that.

> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Tuesday, November 15, 2016 2:51 PM
> To: dev@jmeter.apache.org
> Subject: Re: How should no-op setter methods be filed in Bugzilla?
>
> Am 14.11.2016 um 20:20 schrieb Epp, Jeremiah W (Contractor):
>>> -Original Message-
>>> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
>>>
>>> I have attached a test case that models this, with the only downside,
>>> that it works with current trunk.
>>
>> Thank you, though I have to admit I'm not sure how to correctly run that.
>> Unfortunately, nor do I really have time to get deep in this problem right
>> now.  The example was really just to show the _class_ of problem I've had to
>> work around. There have been a slew of these.
>
> Is this class of problems, those classes, that use instance variables for
> state instead of jmeter-properties?

Beg your pardon?  I was saying its representative of a category of similar
examples that only differ in the class and method name.

>> Let's try this: if you were going to export those postProcessors in your
>> test to a JMX file on the disk, what would the code look like?
>
> Well, if I remember correctly, you are using JMeter in quite some
> interesting ways, that are not the usual ones. So it may very well be,
> that you find interesting behaviour.

I'd say it's a moderately interesting application at most.  I've only had to
extend one class; 99% of what I have is pretty obvious use of the APIs.

> The only way I save elements is to let JMeter save them and I haven't
> looked to deeply into that, yet.

I've tried.  XStream is kind of obtuse, and I'm still trying to figure out
the point where the data structure is lowered to a HashTree that SaveService
can work with.  If I knew that, I might be able to _fix_ it.

Regards,
Wyatt

Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from Chemical Abstracts Service ("CAS"), a division of the American Chemical 
Society ("ACS"). If you have received this transmission in error, be advised 
that any disclosure, copying, distribution, or use of the contents of this 
information is strictly prohibited. Please destroy all copies of the message 
and contact the sender immediately by either replying to this message or 
calling 614-447-3600.

RE: Ideas for 3.2

[Epp, Jeremiah W (Contractor)]

> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Sunday, November 27, 2016 5:58 AM
> To: dev@jmeter.apache.org
> Subject: Re: Ideas for 3.2
>
> Am 23.11.2016 um 23:04 schrieb Philippe Mouawad:
>> - Undo/Redo : I sent a mail on this one and a possible way to
>> implement it
>
> It would be nice to have it working, but it seems like an awful lot to do,
> to get it working.

I'd suggest waiting until you have a better idea of how the internals will
look after refactoring.  That'll inform the undo API and might even make
things easier if you play it right.

>> - Your idea: possible rework of core architecture to at least
>> introduce a pool of threads or switch to async model allowing us to
>> take advantage of async io
>
> I still think we should experiment in that direction, but it seems to be a
> really big step and shouldn't be done in a hurry.

IMHO, the first step of any major internals work is divorcing the test plan
export format from the straight serialisation of the ListedHashTree.

>> In a previous discussion we had a LONNNG discussion on DSL.
>
> The demo looked really intriguing, but I have no knowledge in that
> direction to help out.

Since we're (finally!) nearing the end of this product cycle, I may be able
to argue in favour of allocating some of my time to assist with this.  I do
think this is something that's worth committing to.

Regards,
Wyatt

Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from Chemical Abstracts Service ("CAS"), a division of the American Chemical 
Society ("ACS"). If you have received this transmission in error, be advised 
that any disclosure, copying, distribution, or use of the contents of this 
information is strictly prohibited. Please destroy all copies of the message 
and contact the sender immediately by either replying to this message or 
calling 614-447-3600.

RE: Ideas for 3.2

[Epp, Jeremiah W (Contractor)]

> -Original Message-
> From: Philippe Mouawad [mailto:philippe.moua...@gmail.com]
> Sent: Sunday, November 27, 2016 7:54 AM
> To: dev@jmeter.apache.org
> Subject: Re: Ideas for 3.2
>
> On Sun, Nov 27, 2016 at 11:57 AM, Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>>> Couldn't we start simply by trying to replace XML by JSON as an
>>> output/input format ? XStream has an implementation for this.
>>>
>> I JSON really that much more readable compared to XML?
>>
> JSON is more readable but the XStream one might not be, I can investigate
> this more

More readable?  Eeh, sorta.  It's certainly (a lot) lighter-weight to
parse and it's a decent bog-standard textual data format.  But readability
(for humans) can become awfully spotty when you start nesting data
structures.  If the XStream JSON output is as neurotic as the XML, it'll be
much, much worse.

Honestly, rather than simply abandoning XML, JMeter could do substantially
better just by using it as a proper format instead of a serialisation.

>>> We wouldn't drop XML yet.
>>>
>> We shouldn't.
>>
>I agree

Though it'll probably end up being painful to maintain, especially never
remove the ability to load it.  Keeping backward compatible reading is much
more important than forward compatible export.

Regards,
Wyatt

Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from Chemical Abstracts Service ("CAS"), a division of the American Chemical 
Society ("ACS"). If you have received this transmission in error, be advised 
that any disclosure, copying, distribution, or use of the contents of this 
information is strictly prohibited. Please destroy all copies of the message 
and contact the sender immediately by either replying to this message or 
calling 614-447-3600.

Re: svn commit: r1771648 - /jmeter/trunk/src/components/org/apache/jmeter/visualizers/SummaryReport.java

[Antonio Gomes Rodrigues]

Not clear for me too

Can you replace iff by if and only if ?

Antonio

2016-11-28 8:33 GMT+01:00 Philippe Mouawad :

> On Monday, November 28, 2016, Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
> >
> >
> > Am 27. November 2016 22:10:53 MEZ, schrieb pmoua...@apache.org
> > :
> > >Author: pmouawad
> > >Date: Sun Nov 27 21:10:53 2016
> > >New Revision: 1771648
> > >
> > >URL: http://svn.apache.org/viewvc?rev=1771648=rev
> > >Log:
> > >typo
> > >
> > >Modified:
> > >jmeter/trunk/src/components/org/apache/jmeter/visualizers/
> > SummaryReport.java
> > >
> > >Modified:
> > >jmeter/trunk/src/components/org/apache/jmeter/visualizers/
> > SummaryReport.java
> > >URL:
> > >http://svn.apache.org/viewvc/jmeter/trunk/src/components/
> > org/apache/jmeter/visualizers/SummaryReport.java?rev=
> > 1771648=1771647=1771648=diff
> > >===
> > ===
> > >---
> > >jmeter/trunk/src/components/org/apache/jmeter/visualizers/
> > SummaryReport.java
> > >(original)
> > >+++
> > >jmeter/trunk/src/components/org/apache/jmeter/visualizers/
> > SummaryReport.java
> > >Sun Nov 27 21:10:53 2016
> > >@@ -164,7 +164,7 @@ public class SummaryReport extends Abstr
> > > }
> > >
> > > /**
> > >- * @return true iff all functors can be found
> > >+ * @return true if all functors can be found
> >
> > Are you sure that this was an typo?
> >
> > Iff means "if and only if".
>
> Sorry Felix, was not clear for me
>
> >
> > Regards,
> > Felix
> >
> > >  * @deprecated - only for use in testing
> > >  * */
> > > @Deprecated
> >
> >
>
> --
> Cordialement.
> Philippe Mouawad.
>