Date   

Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Updated documentation for timedDispatch (#42)
	mama/c_cpp/src/c/mama/queue.h
	mama/dotnet/src/cs/MamaQueue.cs
	mama/c_cpp/src/cpp/mama/MamaQueue.h


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #186
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] Fixed Unittest Failures (#323)
	mama/c_cpp/src/c/plugin.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #185
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Re: OpenMAMA static analysis

Duane Pauls
 

For Visual Studio, it appears as though the support lifecycle model changed after VS 2010.  While VS2012 and VS2013 are already EOL, VS2008 and VS2010 are still on extended support.  If the intent is to be cautious, it probably makes sense to wait until MS ends extended support before dropping support from OpenMAMA.

 

The end of extended support dates are:

VS2008: 2018-04-10

VS2010: 2020-07-14

 

Cheers,

Duane

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: Tuesday, September 19, 2017 11:17 AM
To: Bill Torpey
Cc: openmama-dev
Subject: Re: [Openmama-dev] OpenMAMA static analysis

 

The question of support for visual studio is one for the community which I'll actually pose on a separate thread with its own subject so that people might read it, but since VS2013 only went EOL from microsoft a year ago, I expect there are a few out there still using it.

 

Last time we asked, there were still some 2008 users out there too. As you can see, we actually only got rid of 2005 support as recently as 2 years ago (I was keen to do it as 2008 introduced proper msbuild support so we could finally upgrade to newer visual studio project formats). I'm keen to move forward too, but I don't want to alienate our client base either, so any movement forward would need to have 100% community support.

 

Generally for static code analysis, I'm all for it - it tends to prevent issues that weren't even considered. However it would be a lower priority for me behind a few other outstanding CI tasks related to making us more comfortable in merging changes, namely:

  • CI and removal of warnings for Java builds
  • Unit tests in CI environment for C#
  • Windows CI for pull requests (possibly appveyor)
  • Set up of jenkins multi platform builds for windows and linux (which is now possible since they both use the same CI script)

It does continue the gradual increase in sophistication for CI we have had in the last couple of years though... first of all we got unit tests working, then we got warnings removed on linux, now they're gone on windows, but yes I definitely want to always be moving towards a better CI environment which includes static analysis... but they tend to be slow burning tasks so it might take a while to be part of our day-to-day maintenance, but I'd happily accept any static code analysis related changes in the interim.

 

Cheers,

Frank

 

On Tue, Sep 19, 2017 at 2:08 PM, Bill Torpey <wallstprog@...> wrote:

Hi Damian: 

 

Thanks for the feedback.  I’ve made some comments below.

 

Regards,

 

Bill

 

On Sep 19, 2017, at 3:17 AM, Damian Maguire <dmagdrums@...> wrote:

 

Hey Bill, 

 

Great to get your feedback here, and welcome to the dev list. Absolutely the right place for this sort of discussion - GitHub is I think are more geared towards individual issues rather than larger project discussions such as this. 

 

Myself and Frank have spent a good bit of time discussing the subject of static analysis in the OpenMAMA codebase actually (some of the other contributors I think are aware of my interest in that area), and I think the community as a whole would be more than happy to see a stronger focus on it going forward. When support was added for building with Clang, we actually added native support for the Clang static analysis tools via scan-build - https://github.com/OpenMAMA/OpenMAMA/blob/master/site_scons/site_tools/scan-build.py - which means you can actually build and analyse within a single step:

 

    scan-build --use-c=/path/to/clang --use-cxx=/path/to/clang++ --use-analyzer=/path/to/clang scons ...

 

I'd love to see similar integration with other tools going forward (including CPPCheck, and the Google Santizer Suite), so if you have experience in that area I'd be happy to review any contributions. 

 

Right now, getting static analysis working with other tools is somewhat dependent on the build tooling.  I use a custom build script that runs scons under bear to create the compilation database required by my scripts.  The build script is somewhat specific to my environment, so I don’t know how useful it would be to others. but I’ve attached it just in case.

 

 

 

However, once you’ve got a compilation database built (and cppcheck installed), you can use the scripts at https://github.com/btorpey/static to run analysis using both clang and cppcheck, e.g.:

 

cc_cppcheck.sh -i common/c_cpp/src/c/ -i mama/c_cpp/src/c/ -c 2>&1 | tee cppcheck.csv

 

Similar scripts exist for clang-check and clang-tidy (although afaict clang-tidy does everything that clang-check does and more).

 

 

Regarding any fixes you want to submit, I say get them raised and get them in - given Frank's Windows warning hunt is coming to an end (for now) tackling some of these feels like a natural next step.

 

I guess I’m curious about what others think about relative priorities, and/or whether there is are natural “owners” for different parts of the code-base that might want to have input.

 



The only thing I would add, and related to your comment about the scope problems, is any changes will need to take into account the breadth of compilers OpenMAMA has to support and that unfortunately means continuing with the C89/C99 cross breed that older versions of Visual Studio rely on. This isn't so much an OpenMAMA stylistic choice as one that's been forced on us by compiler support, but the wider user community relies on us continuing to adhere to this as a standard (for now ;-)).  

 

Curious if there’s a timetable for requiring VS2013 (the first MS compiler that doesn’t have this problem).  As you’re probably aware, the K&R style is “officially” frowned on, at least in the C++ Core Guidelines (https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es21-dont-introduce-a-variable-or-constant-before-you-need-to-use-it).  I notice that even some of Frank’s side projects (zmq, omnm) deviate from K&R style, which is understandable given how archaic it is.

 

In the meantime, it’s easy enough to filter out those warnings.

 

 

Great to hear you're getting to use OpenMAMA as part of your day job as well. Any feedback you have about your experience the community will be delighted to hear, including in the form of blog posts, so work away. If you want someone to review, or have any questions, I'm happy to help as well. 

 

Thanks.  I’ll send out a link when the article is complete — certainly interested in any feedback.  In the meantime, you may want to check out the other articles in the series: http://btorpey.github.io/blog/categories/static-analysis/

 

 

Looking forward to seeing more of your work. 

 

You’ve already seen some, just under another moniker: https://github.com/pulls?utf8=%E2%9C%93&q=author%3Abill-torpey-ullink+

 

 

 

 

 

 

 

 

Thanks, 

 

Damian 

 

On Sat, Sep 16, 2017 at 7:27 PM Bill Torpey <wallstprog@...> wrote:

Hi all:

I've been working with OpenMAMA for a little while now as part of my "day job", and I've also been working with static analysis tools for some time, so I thought it would be fun to put the two together.

As a first step, I ran the OpenMAMA code through cppcheck, which has become my go-to tool for static analysis, and produced the attached reports.  (FWIW, clang is good too, but I find that cppcheck flags more suspect code, and for me more is usually better).

I'm not sure what the rest of the community thinks about the importance of static analysis -- personally I'm a big believer, and I'm happy to get on board with helping to resolve some of these if others agree that would be a Good Thing.

For the record, the analysis was done on the 6.2.1 release, using cppcheck version 1.80, and using the scripts I've previously published as part of an ongoing series of articles about static analysis on [my blog](http://btorpey.github.io/).  The specific command used was:

   cc_cppcheck.sh 2>&1 | grep -v '/cpp' | grep -v test | grep -v examples | grep -v stdout | tee cppcheck-180.out

The idea was to concentrate on the core OpenMAMA C code, so the command explicitly ignores C++ code, test and examples.  (As well as some mysterious occurences of `stdout` which I haven't had time to track down yet).

A few observations:

- At least one of these issues has been [fixed subsequent to the release](https://github.com/OpenMAMA/OpenMAMA/pull/310).
- There are a boat-load of "scope can be reduced" warnings -- in most cases these can probably be explained by the K&R-style of declarations that OpenMAMA uses as a standard.  (Unfortunately, in my opinion ;-(
- Similarly, there are a bunch of "reassigned a value before the old one has been used", likely with the same cause.
- There are also a bunch of "argument ... names different" warnings -- at least one of these has [bitten me in the past](https://github.com/OpenMAMA/OpenMAMA/issues/297).

As mentioned above, I'm very interested in the community's thoughts on where to go from here (if anywhere).

Regards,

Bill Torpey

P.S.  I'm posting this to the mailing list, rather than to the GitHub issues, but please let me know if you think that would be a more appropriate place.

P.P.S.  I'm also writing another article in my series on static analysis in which I'll be using this analysis to discuss the benefits of static analysis in general, and cppcheck in particular.  This should in no way be seen as a criticism of the OpenMAMA code -- I've been working with OpenMama (as well as DataFabric) for quite a while, and it's a truly unique and impressive effort.  So, kudos to all for making OpenMAMA what it is -- but if we can make it even better, that's to everyone's benefit.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 


Re: OpenMAMA static analysis

Frank Quinn <fquinn.ni@...>
 

The question of support for visual studio is one for the community which I'll actually pose on a separate thread with its own subject so that people might read it, but since VS2013 only went EOL from microsoft a year ago, I expect there are a few out there still using it.

Last time we asked, there were still some 2008 users out there too. As you can see, we actually only got rid of 2005 support as recently as 2 years ago (I was keen to do it as 2008 introduced proper msbuild support so we could finally upgrade to newer visual studio project formats). I'm keen to move forward too, but I don't want to alienate our client base either, so any movement forward would need to have 100% community support.

Generally for static code analysis, I'm all for it - it tends to prevent issues that weren't even considered. However it would be a lower priority for me behind a few other outstanding CI tasks related to making us more comfortable in merging changes, namely:
  • CI and removal of warnings for Java builds
  • Unit tests in CI environment for C#
  • Windows CI for pull requests (possibly appveyor)
  • Set up of jenkins multi platform builds for windows and linux (which is now possible since they both use the same CI script)
It does continue the gradual increase in sophistication for CI we have had in the last couple of years though... first of all we got unit tests working, then we got warnings removed on linux, now they're gone on windows, but yes I definitely want to always be moving towards a better CI environment which includes static analysis... but they tend to be slow burning tasks so it might take a while to be part of our day-to-day maintenance, but I'd happily accept any static code analysis related changes in the interim.

Cheers,
Frank

On Tue, Sep 19, 2017 at 2:08 PM, Bill Torpey <wallstprog@...> wrote:
Hi Damian: 

Thanks for the feedback.  I’ve made some comments below.

Regards,

Bill

On Sep 19, 2017, at 3:17 AM, Damian Maguire <dmagdrums@...> wrote:

Hey Bill, 

Great to get your feedback here, and welcome to the dev list. Absolutely the right place for this sort of discussion - GitHub is I think are more geared towards individual issues rather than larger project discussions such as this. 

Myself and Frank have spent a good bit of time discussing the subject of static analysis in the OpenMAMA codebase actually (some of the other contributors I think are aware of my interest in that area), and I think the community as a whole would be more than happy to see a stronger focus on it going forward. When support was added for building with Clang, we actually added native support for the Clang static analysis tools via scan-build - https://github.com/OpenMAMA/OpenMAMA/blob/master/site_scons/site_tools/scan-build.py - which means you can actually build and analyse within a single step:

    scan-build --use-c=/path/to/clang --use-cxx=/path/to/clang++ --use-analyzer=/path/to/clang scons ...

I'd love to see similar integration with other tools going forward (including CPPCheck, and the Google Santizer Suite), so if you have experience in that area I'd be happy to review any contributions. 

Right now, getting static analysis working with other tools is somewhat dependent on the build tooling.  I use a custom build script that runs scons under bear to create the compilation database required by my scripts.  The build script is somewhat specific to my environment, so I don’t know how useful it would be to others. but I’ve attached it just in case.



However, once you’ve got a compilation database built (and cppcheck installed), you can use the scripts at https://github.com/btorpey/static to run analysis using both clang and cppcheck, e.g.:

cc_cppcheck.sh -i common/c_cpp/src/c/ -i mama/c_cpp/src/c/ -c 2>&1 | tee cppcheck.csv

Similar scripts exist for clang-check and clang-tidy (although afaict clang-tidy does everything that clang-check does and more).


Regarding any fixes you want to submit, I say get them raised and get them in - given Frank's Windows warning hunt is coming to an end (for now) tackling some of these feels like a natural next step.

I guess I’m curious about what others think about relative priorities, and/or whether there is are natural “owners” for different parts of the code-base that might want to have input.


The only thing I would add, and related to your comment about the scope problems, is any changes will need to take into account the breadth of compilers OpenMAMA has to support and that unfortunately means continuing with the C89/C99 cross breed that older versions of Visual Studio rely on. This isn't so much an OpenMAMA stylistic choice as one that's been forced on us by compiler support, but the wider user community relies on us continuing to adhere to this as a standard (for now ;-)).  

Curious if there’s a timetable for requiring VS2013 (the first MS compiler that doesn’t have this problem).  As you’re probably aware, the K&R style is “officially” frowned on, at least in the C++ Core Guidelines (https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es21-dont-introduce-a-variable-or-constant-before-you-need-to-use-it).  I notice that even some of Frank’s side projects (zmq, omnm) deviate from K&R style, which is understandable given how archaic it is.

In the meantime, it’s easy enough to filter out those warnings.


Great to hear you're getting to use OpenMAMA as part of your day job as well. Any feedback you have about your experience the community will be delighted to hear, including in the form of blog posts, so work away. If you want someone to review, or have any questions, I'm happy to help as well. 

Thanks.  I’ll send out a link when the article is complete — certainly interested in any feedback.  In the meantime, you may want to check out the other articles in the series: http://btorpey.github.io/blog/categories/static-analysis/


Looking forward to seeing more of your work. 

You’ve already seen some, just under another moniker: https://github.com/pulls?utf8=%E2%9C%93&q=author%3Abill-torpey-ullink+








Thanks, 

Damian 

On Sat, Sep 16, 2017 at 7:27 PM Bill Torpey <wallstprog@...> wrote:
Hi all:

I've been working with OpenMAMA for a little while now as part of my "day job", and I've also been working with static analysis tools for some time, so I thought it would be fun to put the two together.

As a first step, I ran the OpenMAMA code through cppcheck, which has become my go-to tool for static analysis, and produced the attached reports.  (FWIW, clang is good too, but I find that cppcheck flags more suspect code, and for me more is usually better).

I'm not sure what the rest of the community thinks about the importance of static analysis -- personally I'm a big believer, and I'm happy to get on board with helping to resolve some of these if others agree that would be a Good Thing.

For the record, the analysis was done on the 6.2.1 release, using cppcheck version 1.80, and using the scripts I've previously published as part of an ongoing series of articles about static analysis on [my blog](http://btorpey.github.io/).  The specific command used was:

   cc_cppcheck.sh 2>&1 | grep -v '/cpp' | grep -v test | grep -v examples | grep -v stdout | tee cppcheck-180.out

The idea was to concentrate on the core OpenMAMA C code, so the command explicitly ignores C++ code, test and examples.  (As well as some mysterious occurences of `stdout` which I haven't had time to track down yet).

A few observations:

- At least one of these issues has been [fixed subsequent to the release](https://github.com/OpenMAMA/OpenMAMA/pull/310).
- There are a boat-load of "scope can be reduced" warnings -- in most cases these can probably be explained by the K&R-style of declarations that OpenMAMA uses as a standard.  (Unfortunately, in my opinion ;-(
- Similarly, there are a bunch of "reassigned a value before the old one has been used", likely with the same cause.
- There are also a bunch of "argument ... names different" warnings -- at least one of these has [bitten me in the past](https://github.com/OpenMAMA/OpenMAMA/issues/297).

As mentioned above, I'm very interested in the community's thoughts on where to go from here (if anywhere).

Regards,

Bill Torpey

P.S.  I'm posting this to the mailing list, rather than to the GitHub issues, but please let me know if you think that would be a more appropriate place.

P.P.S.  I'm also writing another article in my series on static analysis in which I'll be using this analysis to discuss the benefits of static analysis in general, and cppcheck in particular.  This should in no way be seen as a criticism of the OpenMAMA code -- I've been working with OpenMama (as well as DataFabric) for quite a while, and it's a truly unique and impressive effort.  So, kudos to all for making OpenMAMA what it is -- but if we can make it even better, that's to everyone's benefit.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev


_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev



Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[Frank Quinn] Revert "MAMA: Moved background thread destroy to stop (#326)"
	mama/c_cpp/src/c/mama.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #184
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Re: Questions about MamaStartCallback

Frank Quinn <fquinn.ni@...>
 

Hi Yury,

I did have this proposed change merged, but have since discovered that it causes a deadlock in our unit test on windows.

On closer inspection, it looks like the problem is caused by the fact that making mama_stop blocking will effectively deadlock any application which attempts to call mama_stop from a MAMA event coming off the default queue (like our unit test application). Since I expect this is a common enough pattern, we'll have to revert this change.

Note that the argument to startBackground is misleadingly a stop callback - i.e. it will be called when mama_start *unblocks*. With this in mind, you should be able to get your MyMamaConnection destructor to wait on a semaphore raised by onStartComplete method (use mama_startBackgroundEx rather than mama_startBackground to provide a closure) to raise a semaphore to simulate the equivalent behaviour and prevent the crash.

Cheers,
Frank

On Mon, Aug 14, 2017 at 1:21 PM, Yury Batrakov <yury.batrakov@...> wrote:
Classification: Public

Hi guys,

As everybody knows there is possibility to start MAMA bridge in background thread in C++ API: function Mama::startBackground (mamaBridge bridgeImpl, MamaStartCallback* cb)
There are a couple of problems with this function though:
    1. We can't ignore "MAMA startup finished" event setting  the value for the second argument to nullptr - this can be fixed as a simple nullptr check in void MAMACALLTYPE stopCb (mama_status status, mamaBridge, void* closure) in mamacpp.cpp
    2. There is race condition between thread calling Mama::stop and internal MAMA thread spawned  by startBackground function. This race may lead to program crash.

Let me describe #2 - consider the following scenario:

We have a simple class MyMamaConnection

class MyMamaStartCallback : public MamaStartCallback {
    void onStartComplete (Wombat::MamaStatus status) override {
           // .... Some bridge specific callback code
    }
};

class MyMamaConnection {
    mamaBridge m_bridge;
    MyMamaStartCallback m_callback;

    MyMamaConnection() {
        Mama::startBackground (m_bridge, &m_callback)
    }

    ~MyMamaConnection() {
        Mama::stop(m_bridge);
    }
};

The crash occur in destructor because Mama::stop doesn't guarantee that no threads are still using m_callback pointer after this function exited. In our case MyMamaConnection's destructor destroys m_callback object while it is still in use by the thread created by Mama::startBackground.

Here are more details, file mama.c:

static void* mamaStartThread (void* closure)
{
...
    rval = mama_start (cb->mBridgeImpl); // Imagine user thread Thread_1 calling ~MyMamaConnection() from our example.

    // Current thread may be suspended by OS at this point while Thread_1 continues its work and deletes the object pointed by closure
...

    if (cb->mStopCallbackEx)

        // cb->mClosure points to destroyed object.

        cb->mStopCallbackEx (rval, cb->mBridgeImpl, cb->mClosure);
...
}

One of the possible solutions is to move this code from mama_close() to mama_stop():
                        // Get name of start background thread and destroy it
                        const char* threadName = wombatThread_getThreadName(middlewareLib->bridge->mStartBackgroundThread);
                        wombatThread_destroy (threadName);

Let me know if it's possible to have this fixed in the next release.


---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev


Re: OpenMAMA static analysis

Bill Torpey
 

Hi Damian: 

Thanks for the feedback.  I’ve made some comments below.

Regards,

Bill

On Sep 19, 2017, at 3:17 AM, Damian Maguire <dmagdrums@...> wrote:

Hey Bill, 

Great to get your feedback here, and welcome to the dev list. Absolutely the right place for this sort of discussion - GitHub is I think are more geared towards individual issues rather than larger project discussions such as this. 

Myself and Frank have spent a good bit of time discussing the subject of static analysis in the OpenMAMA codebase actually (some of the other contributors I think are aware of my interest in that area), and I think the community as a whole would be more than happy to see a stronger focus on it going forward. When support was added for building with Clang, we actually added native support for the Clang static analysis tools via scan-build - https://github.com/OpenMAMA/OpenMAMA/blob/master/site_scons/site_tools/scan-build.py - which means you can actually build and analyse within a single step:

    scan-build --use-c=/path/to/clang --use-cxx=/path/to/clang++ --use-analyzer=/path/to/clang scons ...

I'd love to see similar integration with other tools going forward (including CPPCheck, and the Google Santizer Suite), so if you have experience in that area I'd be happy to review any contributions. 

Right now, getting static analysis working with other tools is somewhat dependent on the build tooling.  I use a custom build script that runs scons under bear to create the compilation database required by my scripts.  The build script is somewhat specific to my environment, so I don’t know how useful it would be to others. but I’ve attached it just in case.



However, once you’ve got a compilation database built (and cppcheck installed), you can use the scripts at https://github.com/btorpey/static to run analysis using both clang and cppcheck, e.g.:

cc_cppcheck.sh -i common/c_cpp/src/c/ -i mama/c_cpp/src/c/ -c 2>&1 | tee cppcheck.csv

Similar scripts exist for clang-check and clang-tidy (although afaict clang-tidy does everything that clang-check does and more).


Regarding any fixes you want to submit, I say get them raised and get them in - given Frank's Windows warning hunt is coming to an end (for now) tackling some of these feels like a natural next step.

I guess I’m curious about what others think about relative priorities, and/or whether there is are natural “owners” for different parts of the code-base that might want to have input.


The only thing I would add, and related to your comment about the scope problems, is any changes will need to take into account the breadth of compilers OpenMAMA has to support and that unfortunately means continuing with the C89/C99 cross breed that older versions of Visual Studio rely on. This isn't so much an OpenMAMA stylistic choice as one that's been forced on us by compiler support, but the wider user community relies on us continuing to adhere to this as a standard (for now ;-)).  

Curious if there’s a timetable for requiring VS2013 (the first MS compiler that doesn’t have this problem).  As you’re probably aware, the K&R style is “officially” frowned on, at least in the C++ Core Guidelines (https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es21-dont-introduce-a-variable-or-constant-before-you-need-to-use-it).  I notice that even some of Frank’s side projects (zmq, omnm) deviate from K&R style, which is understandable given how archaic it is.

In the meantime, it’s easy enough to filter out those warnings.


Great to hear you're getting to use OpenMAMA as part of your day job as well. Any feedback you have about your experience the community will be delighted to hear, including in the form of blog posts, so work away. If you want someone to review, or have any questions, I'm happy to help as well. 

Thanks.  I’ll send out a link when the article is complete — certainly interested in any feedback.  In the meantime, you may want to check out the other articles in the series: http://btorpey.github.io/blog/categories/static-analysis/


Looking forward to seeing more of your work. 

You’ve already seen some, just under another moniker: https://github.com/pulls?utf8=%E2%9C%93&q=author%3Abill-torpey-ullink+







Thanks, 

Damian 

On Sat, Sep 16, 2017 at 7:27 PM Bill Torpey <wallstprog@...> wrote:
Hi all:

I've been working with OpenMAMA for a little while now as part of my "day job", and I've also been working with static analysis tools for some time, so I thought it would be fun to put the two together.

As a first step, I ran the OpenMAMA code through cppcheck, which has become my go-to tool for static analysis, and produced the attached reports.  (FWIW, clang is good too, but I find that cppcheck flags more suspect code, and for me more is usually better).

I'm not sure what the rest of the community thinks about the importance of static analysis -- personally I'm a big believer, and I'm happy to get on board with helping to resolve some of these if others agree that would be a Good Thing.

For the record, the analysis was done on the 6.2.1 release, using cppcheck version 1.80, and using the scripts I've previously published as part of an ongoing series of articles about static analysis on [my blog](http://btorpey.github.io/).  The specific command used was:

   cc_cppcheck.sh 2>&1 | grep -v '/cpp' | grep -v test | grep -v examples | grep -v stdout | tee cppcheck-180.out

The idea was to concentrate on the core OpenMAMA C code, so the command explicitly ignores C++ code, test and examples.  (As well as some mysterious occurences of `stdout` which I haven't had time to track down yet).

A few observations:

- At least one of these issues has been [fixed subsequent to the release](https://github.com/OpenMAMA/OpenMAMA/pull/310).
- There are a boat-load of "scope can be reduced" warnings -- in most cases these can probably be explained by the K&R-style of declarations that OpenMAMA uses as a standard.  (Unfortunately, in my opinion ;-(
- Similarly, there are a bunch of "reassigned a value before the old one has been used", likely with the same cause.
- There are also a bunch of "argument ... names different" warnings -- at least one of these has [bitten me in the past](https://github.com/OpenMAMA/OpenMAMA/issues/297).

As mentioned above, I'm very interested in the community's thoughts on where to go from here (if anywhere).

Regards,

Bill Torpey

P.S.  I'm posting this to the mailing list, rather than to the GitHub issues, but please let me know if you think that would be a more appropriate place.

P.P.S.  I'm also writing another article in my series on static analysis in which I'll be using this analysis to discuss the benefits of static analysis in general, and cppcheck in particular.  This should in no way be seen as a criticism of the OpenMAMA code -- I've been working with OpenMama (as well as DataFabric) for quite a while, and it's a truly unique and impressive effort.  So, kudos to all for making OpenMAMA what it is -- but if we can make it even better, that's to everyone's benefit.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


Re: OpenMAMA static analysis

Damian Maguire
 

Hey Bill, 

Great to get your feedback here, and welcome to the dev list. Absolutely the right place for this sort of discussion - GitHub is I think are more geared towards individual issues rather than larger project discussions such as this. 

Myself and Frank have spent a good bit of time discussing the subject of static analysis in the OpenMAMA codebase actually (some of the other contributors I think are aware of my interest in that area), and I think the community as a whole would be more than happy to see a stronger focus on it going forward. When support was added for building with Clang, we actually added native support for the Clang static analysis tools via scan-build - https://github.com/OpenMAMA/OpenMAMA/blob/master/site_scons/site_tools/scan-build.py - which means you can actually build and analyse within a single step:

    scan-build --use-c=/path/to/clang --use-cxx=/path/to/clang++ --use-analyzer=/path/to/clang scons ...

I'd love to see similar integration with other tools going forward (including CPPCheck, and the Google Santizer Suite), so if you have experience in that area I'd be happy to review any contributions. 

Regarding any fixes you want to submit, I say get them raised and get them in - given Frank's Windows warning hunt is coming to an end (for now) tackling some of these feels like a natural next step. The only thing I would add, and related to your comment about the scope problems, is any changes will need to take into account the breadth of compilers OpenMAMA has to support and that unfortunately means continuing with the C89/C99 cross breed that older versions of Visual Studio rely on. This isn't so much an OpenMAMA stylistic choice as one that's been forced on us by compiler support, but the wider user community relies on us continuing to adhere to this as a standard (for now ;-)).  

Great to hear you're getting to use OpenMAMA as part of your day job as well. Any feedback you have about your experience the community will be delighted to hear, including in the form of blog posts, so work away. If you want someone to review, or have any questions, I'm happy to help as well. 

Looking forward to seeing more of your work. 

Thanks, 

Damian 


On Sat, Sep 16, 2017 at 7:27 PM Bill Torpey <wallstprog@...> wrote:
Hi all:

I've been working with OpenMAMA for a little while now as part of my "day job", and I've also been working with static analysis tools for some time, so I thought it would be fun to put the two together.

As a first step, I ran the OpenMAMA code through cppcheck, which has become my go-to tool for static analysis, and produced the attached reports.  (FWIW, clang is good too, but I find that cppcheck flags more suspect code, and for me more is usually better).

I'm not sure what the rest of the community thinks about the importance of static analysis -- personally I'm a big believer, and I'm happy to get on board with helping to resolve some of these if others agree that would be a Good Thing.

For the record, the analysis was done on the 6.2.1 release, using cppcheck version 1.80, and using the scripts I've previously published as part of an ongoing series of articles about static analysis on [my blog](http://btorpey.github.io/).  The specific command used was:

   cc_cppcheck.sh 2>&1 | grep -v '/cpp' | grep -v test | grep -v examples | grep -v stdout | tee cppcheck-180.out

The idea was to concentrate on the core OpenMAMA C code, so the command explicitly ignores C++ code, test and examples.  (As well as some mysterious occurences of `stdout` which I haven't had time to track down yet).

A few observations:

- At least one of these issues has been [fixed subsequent to the release](https://github.com/OpenMAMA/OpenMAMA/pull/310).
- There are a boat-load of "scope can be reduced" warnings -- in most cases these can probably be explained by the K&R-style of declarations that OpenMAMA uses as a standard.  (Unfortunately, in my opinion ;-(
- Similarly, there are a bunch of "reassigned a value before the old one has been used", likely with the same cause.
- There are also a bunch of "argument ... names different" warnings -- at least one of these has [bitten me in the past](https://github.com/OpenMAMA/OpenMAMA/issues/297).

As mentioned above, I'm very interested in the community's thoughts on where to go from here (if anywhere).

Regards,

Bill Torpey

P.S.  I'm posting this to the mailing list, rather than to the GitHub issues, but please let me know if you think that would be a more appropriate place.

P.P.S.  I'm also writing another article in my series on static analysis in which I'll be using this analysis to discuss the benefits of static analysis in general, and cppcheck in particular.  This should in no way be seen as a criticism of the OpenMAMA code -- I've been working with OpenMama (as well as DataFabric) for quite a while, and it's a truly unique and impressive effort.  So, kudos to all for making OpenMAMA what it is -- but if we can make it even better, that's to everyone's benefit.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


OpenMAMA static analysis

Bill Torpey
 

Hi all:

I've been working with OpenMAMA for a little while now as part of my "day job", and I've also been working with static analysis tools for some time, so I thought it would be fun to put the two together.

As a first step, I ran the OpenMAMA code through cppcheck, which has become my go-to tool for static analysis, and produced the attached reports. (FWIW, clang is good too, but I find that cppcheck flags more suspect code, and for me more is usually better).

I'm not sure what the rest of the community thinks about the importance of static analysis -- personally I'm a big believer, and I'm happy to get on board with helping to resolve some of these if others agree that would be a Good Thing.

For the record, the analysis was done on the 6.2.1 release, using cppcheck version 1.80, and using the scripts I've previously published as part of an ongoing series of articles about static analysis on [my blog](http://btorpey.github.io/). The specific command used was:

cc_cppcheck.sh 2>&1 | grep -v '/cpp' | grep -v test | grep -v examples | grep -v stdout | tee cppcheck-180.out

The idea was to concentrate on the core OpenMAMA C code, so the command explicitly ignores C++ code, test and examples. (As well as some mysterious occurences of `stdout` which I haven't had time to track down yet).

A few observations:

- At least one of these issues has been [fixed subsequent to the release](https://github.com/OpenMAMA/OpenMAMA/pull/310).
- There are a boat-load of "scope can be reduced" warnings -- in most cases these can probably be explained by the K&R-style of declarations that OpenMAMA uses as a standard. (Unfortunately, in my opinion ;-(
- Similarly, there are a bunch of "reassigned a value before the old one has been used", likely with the same cause.
- There are also a bunch of "argument ... names different" warnings -- at least one of these has [bitten me in the past](https://github.com/OpenMAMA/OpenMAMA/issues/297).

As mentioned above, I'm very interested in the community's thoughts on where to go from here (if anywhere).

Regards,

Bill Torpey

P.S. I'm posting this to the mailing list, rather than to the GitHub issues, but please let me know if you think that would be a more appropriate place.

P.P.S. I'm also writing another article in my series on static analysis in which I'll be using this analysis to discuss the benefits of static analysis in general, and cppcheck in particular. This should in no way be seen as a criticism of the OpenMAMA code -- I've been working with OpenMama (as well as DataFabric) for quite a while, and it's a truly unique and impressive effort. So, kudos to all for making OpenMAMA what it is -- but if we can make it even better, that's to everyone's benefit.


RFC for Source Discovery

Frank Quinn <fquinn.ni@...>
 

Hi Folks,
 
We have a new RFC contributed by Arcontech to cover the upcoming Source Discovery functionality. Thanks very much to the Arcontech folks for taking the time to put this together.

You can find it listed here:
 
 
As a reminder of the RFC process and how to get involved, I'll refer you all to:
 
 
Pay particular attention to the most constructive ways to provide feedback: https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback
 
As per our process, we will leave this RFC open for a period of 2 weeks, after which point if there are no major concerns, the RFC design will be considered approved and work can begin.
 
Cheers,
Frank


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Microsoft Visual Studio Warning Cull (#320)
	common/c_cpp/src/c/windows/wUuid.c
	mama/c_cpp/src/cpp/mamacpp.vcxproj
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookWriter.cpp
	mama/c_cpp/src/cpp/MamaSourceManager.cpp
	mama/c_cpp/src/cpp/conflation/MamaConnection.cpp
	mama/c_cpp/src/cpp/fieldcache/MamaFieldCacheRecord.cpp
	mamda/c_cpp/src/cpp/options/MamdaOptionChainListener.cpp
	mamda/c_cpp/src/examples/orderbooks/mamdaatomicbookbuilder.vcxproj
	common/c_cpp/src/c/commonc.vcxproj
	mama/c_cpp/src/c/queue.c
	mamda/dotnet/src/cs/MamdaMultiSecurityManager.cs
	common/c_cpp/src/cpp/wombat/Lock.h
	mama/c_cpp/src/c/bridge/qpid/inbox.c
	mama/c_cpp/src/c/mama.c
	mamda/c_cpp/src/examples/orderbooks/bookpublisher.cpp
	mama/c_cpp/src/cpp/MamaInbox.cpp
	mama/c_cpp/src/c/msg.c
	mamda/c_cpp/src/cpp/MamdaConcreteBasicEvent.cpp
	mamda/c_cpp/src/examples/quoteticker.cpp
	mama/c_cpp/src/c/statslogger.c
	mamda/c_cpp/src/cpp/MamdaFieldState.cpp
	mama/c_cpp/src/c/playback/playbackpublisher.c
	mamda/c_cpp/src/examples/mamdaoptionchainer.vcxproj
	mamda/dotnet/src/examples/MamdaOptionChainViewExample/MamdaOptionChainViewExampleCS.csproj
	mama/c_cpp/src/cpp/MamaTransport.cpp
	mamda/dotnet/src/examples/MamdaOptionChainExample/MamdaOptionChainExampleCS.csproj
	mama/c_cpp/src/gunittest/c/mamamsg/msgiterationtests.cpp
	mamda/c_cpp/src/cpp/news/MamdaNewsManager.cpp
	common/c_cpp/src/c/wtable.c
	mama/c_cpp/src/c/bridge/qpid/msg.c
	mamda/c_cpp/src/cpp/news/MamdaNewsHeadline.cpp
	mamda/c_cpp/src/examples/orderbooks/atomicbookticker.cpp
	mama/dotnet/src/examples/MamaMultiSubscriber/MamaMultiSubscriberCS.cs
	mama/c_cpp/src/gunittest/cpp/UnitTestMamaCPP.vcxproj
	mama/c_cpp/src/examples/cpp/mamaftmembercpp.vcxproj
	mamda/c_cpp/src/examples/mamdamultipartticker.vcxproj
	common/c_cpp/src/c/thread.c
	common/c_cpp/src/c/windows/wombat/wConfig.h
	mamda/dotnet/src/cs/OrderBook/MamdaBookAtomicListener.cs
	mama/c_cpp/src/cpp/MamaTransportMap.cpp
	mama/c_cpp/src/examples/c/mamaiorc.vcxproj
	mama/c_cpp/src/c/datetime.c
	mamda/c_cpp/src/cpp/MamdaMultiParticipantManager.cpp
	mama/c_cpp/src/cpp/MamaQueue.cpp
	common/c_cpp/src/c/SConscript.win
	mamda/c_cpp/src/examples/multisecurityticker.cpp
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookBasicDelta.cpp
	mamda/c_cpp/src/cpp/MamdaBasicSubscription.cpp
	mama/c_cpp/src/examples/cpp/mamasubscribercpp.vcxproj
	mamda/c_cpp/src/examples/mamdaauctionticker.vcxproj
	mamda/c_cpp/src/testtools/tradeselftest.cpp
	mama/c_cpp/src/c/payload/qpidmsg/payload.c
	mama/c_cpp/src/c/playback/playbackFileParser.c
	mamda/c_cpp/src/cpp/options/MamdaOptionContract.cpp
	mama/c_cpp/src/cpp/MamaQueueGroup.cpp
	mamda/dotnet/src/cs/MamdaTradeListener.cs
	mamda/dotnet/src/examples/MamdaFundamentalTicker/MamdaFundamentalTicker.cs
	mama/c_cpp/src/testtools/capturereplay/c/captureconvert.c
	mamda/dotnet/src/cs/OrderBook/MamdaBookAtomicGap.cs
	mama/c_cpp/src/c/bridge/qpid/qpid.vcxproj
	mama/c_cpp/src/c/dqpublishermanager.c
	mamda/c_cpp/src/examples/mamdalisten.cpp
	mama/c_cpp/src/c/bridge/qpid/subscription.c
	mama/c_cpp/src/c/priceimpl.c
	mama/dotnet/src/examples/MamaIo/MamaIoCS.cs
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookConcreteComplexDelta.cpp
	mamda/dotnet/src/examples/MamdaAtomicBookTicker/MamdaAtomicBookTickerCS.csproj
	mamda/c_cpp/src/cpp/MamdaPubStatusFields.cpp
	mama/c_cpp/src/gunittest/c/UnitTestMamaC.vcxproj
	mama/dotnet/src/examples/MamaSubscriber/MamaSubscriberCS.csproj
	mamda/c_cpp/src/cpp/news/MamdaNewsFields.cpp
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookConcreteSimpleDelta.cpp
	mama/c_cpp/src/cpp/fieldcache/MamaFieldCacheField.cpp
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookChecker.cpp
	mamda/c_cpp/src/cpp/MamdaFundamentalListener.cpp
	mama/c_cpp/src/cpp/MamaBasicSubscription.cpp
	mamda/dotnet/src/cs/OrderBook/MamdaOrderBook.cs
	mama/c_cpp/src/examples/cpp/mamalistencpp.vcxproj
	mamda/c_cpp/src/examples/optionview.cpp
	mamda/dotnet/src/examples/MamdaListen/MamdaListenCS.csproj
	mama/c_cpp/src/cpp/MamaFt.cpp
	mama/c_cpp/src/c/subscription.c
	mamda/dotnet/src/cs/OrderBook/MamdaOrderBookListener.cs
	mamda/dotnet/src/examples/MamdaTradeTicker/MamdaTradeTickerCS.csproj
	mama/c_cpp/src/c/payload/qpidmsg/field.c
	mamda/c_cpp/src/examples/mamdacomboticker.vcxproj
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookSimpleDelta.cpp
	common/c_cpp/src/c/lookup2.c
	mama/c_cpp/src/testtools/load/cpp/mamachurncpp.vcxproj
	mama/c_cpp/src/examples/cpp/mamaftmembercpp.cpp
	mamda/c_cpp/src/cpp/MamdaSecStatusSymbolSourceAdapter.cpp
	mamda/c_cpp/src/cpp/MamdaQuoteChecker.cpp
	mama/c_cpp/src/c/dictionary.c
	mamda/c_cpp/src/cpp/MamdaPubStatusListener.cpp
	mama/c_cpp/src/c/bridge/qpid/transport.c
	mamda/c_cpp/src/examples/orderbooks/mamdabookpublisher.vcxproj
	common/c_cpp/src/c/windows/port.c
	mamda/c_cpp/src/examples/mamdaexamplecommon.vcxproj
	mama/c_cpp/src/c/entitlement/noop/noop.vcxproj
	mamda/c_cpp/src/cpp/MamdaSecStatusFields.cpp
	mamda/c_cpp/src/testtools/quoteselftest.cpp
	mama/c_cpp/src/c/log.c
	mama/c_cpp/src/cpp/MamaSourceGroup.cpp
	mama/c_cpp/src/cpp/fieldcache/MamaFieldCache.cpp
	mamda/c_cpp/src/testtools/bookselftest.cpp
	mamda/c_cpp/src/cpp/MamdaCheckerType.cpp
	mamda/c_cpp/src/examples/orderbooks/mamdalistenerBookPublisher.vcxproj
	mamda/c_cpp/src/examples/mamdaoptionview.vcxproj
	mamda/c_cpp/src/cpp/MamdaAuctionListener.cpp
	mamda/c_cpp/src/testtools/bookselftest.vcxproj
	mamda/c_cpp/src/examples/auctionticker.cpp
	mama/c_cpp/src/cpp/MamaMsgField.cpp
	mamda/c_cpp/src/cpp/MamdaQuoteFields.cpp
	mama/c_cpp/src/cpp/MamaLogFile.cpp
	mamda/dotnet/src/examples/MamdaMultiSecurityTicker/MamdaMultiSecurityTickerCS.csproj
	mama/c_cpp/src/cpp/MamaDispatcher.cpp
	mama/dotnet/src/examples/MamaSymbolListSubscriber/MamaSymbolListSubscriberCS.cs
	mama/dotnet/src/examples/MamaSymbolListSubscriber/MamaSymbolListSubscriberCS.csproj
	mamda/c_cpp/src/examples/orderbooks/listenerBookPublisher.cpp
	mamda/c_cpp/src/cpp/MamdaQuoteListener.cpp
	mama/c_cpp/src/cpp/mamacpp.cpp
	mamda/c_cpp/src/cpp/options/MamdaOptionFields.cpp
	common/c_cpp/src/gunittest/c/UnitTestCommonC.vcxproj
	mamda/c_cpp/src/examples/orderbooks/mamdaatomicbookticker.vcxproj
	mama/c_cpp/src/examples/c/mamaproxyc.vcxproj
	mamda/c_cpp/src/cpp/news/MamdaNewsStory.cpp
	mamda/c_cpp/src/examples/mamdafundamentallisten.vcxproj
	common/c_cpp/src/c/windows/strptime.c
	mamda/c_cpp/src/examples/dictrequester.cpp
	mama/c_cpp/src/cpp/version.rc
	mamda/c_cpp/src/cpp/MamdaOrderImbalanceType.cpp
	mama/c_cpp/src/c/bridge/qpid/qpidcommon.c
	mama/c_cpp/src/testtools/performance/cpp/mamapingpong_replycpp.vcxproj
	mama/c_cpp/src/c/payload/qpidmsg/qpidmsg.vcxproj
	mama/jni/src/c/mamajni.vcxproj
	mamda/dotnet/src/examples/MamdaAuctionTicker/MamdaAuctionTickerCS.csproj
	mama/c_cpp/src/cpp/MamaSourceGroupManager.cpp
	mamda/dotnet/src/cs/Options/MamdaOptionChainView.cs
	mamda/c_cpp/src/cpp/orderbooks/mamda/MamdaOrderBookCheckType.h
	mamda/c_cpp/src/cpp/MamdaSubscription.cpp
	mama/c_cpp/SConscript.win
	mama/c_cpp/src/testtools/load/cpp/mamachurncpp.cpp
	mamda/c_cpp/src/examples/news/mamdanewsticker.vcxproj
	mama/c_cpp/src/gunittest/c/UnitTestMamaDateTimeC.vcxproj
	mamda/c_cpp/src/cpp/MamdaMultiSecurityManager.cpp
	mamda/c_cpp/src/examples/fundamentallisten.cpp
	mama/c_cpp/src/c/payload/qpidmsg/qpidcommon.c
	mama/c_cpp/src/cpp/MamaSourceDerivative.cpp
	mama/c_cpp/src/cpp/MamaTimer.cpp
	mama/c_cpp/src/gunittest/c/UnitTestMamaPayloadC.vcxproj
	mama/c_cpp/src/cpp/MamaSymbolListFile.cpp
	mamda/c_cpp/src/cpp/options/mamdaoptions.vcxproj
	mamda/dotnet/src/cs/MamdaSecurityStatusUpdate.cs
	mama/c_cpp/src/cpp/MamaSymbolMapFile.cpp
	common/c_cpp/src/c/windows/machine_win.c
	mama/c_cpp/src/examples/c/mamaftmemberc.vcxproj
	mamda/c_cpp/src/cpp/news/MamdaNewsUtils.cpp
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookEntryManager.cpp
	mamda/c_cpp/src/cpp/orderbooks/mamdabook.vcxproj
	mamda/c_cpp/src/examples/orderbooks/bookticker.cpp
	mama/c_cpp/src/c/entitlement/noop/noop.h
	mama/c_cpp/src/cpp/conflation/MamaServerConnection.cpp
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookListener.cpp
	mama/c_cpp/src/examples/c/mamamultisubscriberc.vcxproj
	mama/c_cpp/src/c/payload/qpidmsg/iterator.c
	mamda/c_cpp/src/cpp/MamdaFundamentalFields.cpp
	mama/c_cpp/src/examples/cpp/mamasymbollistsubscribercpp.vcxproj
	mamda/c_cpp/src/examples/orderbooks/atomicbookbuilder.cpp
	mama/c_cpp/src/c/SConscript.win
	mama/c_cpp/src/examples/cpp/mamamsgpublishercpp.vcxproj
	mama/c_cpp/src/c/fieldcache/fieldcache.c
	mama/c_cpp/src/examples/c/mamasubscriberc.vcxproj
	mama/c_cpp/src/c/mama/msg.h
	common/c_cpp/src/cpp/commoncpp.vcxproj
	mama/c_cpp/src/examples/c/mamasymbollistsubscriberc.vcxproj
	mamda/c_cpp/src/cpp/mamda/MamdaCheckerType.h
	mama/c_cpp/src/c/fieldcache/fieldcachevector.c
	mamda/c_cpp/src/examples/mamdamultisecurityticker.vcxproj
	mamda/dotnet/src/cs/MamdaFundamentalHandler.cs
	mama/c_cpp/src/cpp/MamaIo.cpp
	mamda/c_cpp/src/cpp/orderbooks/MamdaQuoteToBookListener.cpp
	mamda/c_cpp/src/cpp/orderbooks/MamdaBookAtomicListener.cpp
	common/c_cpp/src/c/wombat/wCommon.h
	mama/c_cpp/src/cpp/MamaPublisher.cpp
	mamda/c_cpp/src/examples/tradeticker.cpp
	mamda/c_cpp/src/examples/news/newsticker.cpp
	mama/c_cpp/src/examples/cpp/mamaiocpp.cpp
	mamda/dotnet/src/examples/MamdaSecStatusTicker/MamdaSecStatusTickerCS.csproj
	mama/c_cpp/src/examples/c/mamainboxc.vcxproj
	mamda/c_cpp/src/cpp/MamdaTradeFields.cpp
	common/c_cpp/src/c/darwin/port.h
	mama/c_cpp/src/cpp/MamaSymbolList.cpp
	mama/c_cpp/src/c/ft.c
	mama/c_cpp/src/c/bridge/qpid/qpidbridgefunctions.h
	mama/dotnet/src/examples/MamaFtMember/MamaFtMemberCS.csproj
	mamda/dotnet/src/cs/MamdaSubscription.cs
	mama/c_cpp/src/cpp/MamaStat.cpp
	mamda/c_cpp/src/cpp/options/MamdaOptionSeriesUpdate.cpp
	mama/c_cpp/src/c/refreshtransport.c
	mama/c_cpp/src/examples/cpp/mamaiocpp.vcxproj
	mama/dotnet/src/examples/MamaInbox/MamaInboxCS.csproj
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookFields.cpp
	mamda/dotnet/src/cs/Options/MamdaOptionContract.cs
	mama/dotnet/src/examples/MamaPublisher/MamaPublisherCS.csproj
	site_scons/logger.py
	mamda/dotnet/src/cs/OrderBook/MamdaBookAtomicLevelHandler.cs
	mamda/c_cpp/src/examples/mamdapublisher.vcxproj
	mama/c_cpp/src/gunittest/c/payload/payloadgeneraltests.cpp
	mamda/c_cpp/src/examples/mamdapublisher.cpp
	mama/c_cpp/src/c/bridge/qpid/io.c
	mama/c_cpp/src/examples/cpp/mamapublishercpp.vcxproj
	mama/c_cpp/src/cpp/MamaReservedFields.cpp
	mamda/dotnet/src/cs/MamdaSecurityStatusRecap.cs
	mama/c_cpp/src/cpp/MamaPrice.cpp
	mamda/c_cpp/src/cpp/MamdaTradeChecker.cpp
	mamda/c_cpp/src/examples/comboticker.cpp
	mamda/dotnet/src/cs/mamdadotnet.csproj
	mamda/dotnet/src/examples/MamdaBookChurn/MamdaBookChurnCS.csproj
	mamda/dotnet/src/examples/MamdaMultiPartTicker/MamdaMultiPartTickerCS.csproj
	mamda/dotnet/src/cs/MamdaOrderImbalanceListener.cs
	mama/c_cpp/src/c/version.rc
	mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c
	mamda/c_cpp/src/cpp/MamdaTradeListener.cpp
	mama/c_cpp/src/cpp/MamaStatsCollector.cpp
	mamda/dotnet/src/cs/MamdaConcreteOrderImbalanceRecap.cs
	common/c_cpp/src/c/strutils.c
	mama/c_cpp/src/cpp/MamaSource.cpp
	mama/c_cpp/src/examples/cpp/mamasymbollistsubscribercpp.cpp
	common/c_cpp/src/c/properties.l
	mamda/c_cpp/src/cpp/options/MamdaOptionChainView.cpp
	mamda/c_cpp/src/examples/mamdasecstatuslisten.vcxproj
	mamda/c_cpp/src/cpp/MamdaCurrencyFields.cpp
	mama/c_cpp/src/c/payload/qpidmsg/field.h
	mama/c_cpp/src/examples/c/mamapublisherc.vcxproj
	mamda/dotnet/src/cs/MamdaTradeReport.cs
	mama/dotnet/src/examples/MamaIo/MamaIoCS.csproj
	common/c_cpp/src/c/windows/network.c
	mamda/c_cpp/src/examples/mamdaquoteticker.vcxproj
	common/c_cpp/src/c/windows/wombat/wUuid.h
	mama/c_cpp/src/c/bridge/qpid/codec.c
	mamda/c_cpp/src/testtools/tradeselftest.vcxproj
	mamda/dotnet/src/examples/MamdaFundamentalTicker/MamdaFundamentalTickerCS.csproj
	mama/c_cpp/src/gunittest/c/UnitTestMamaMsgC.vcxproj
	common/c_cpp/src/c/property.c
	mama/dotnet/src/testtools/load/MamaChurn/MamaChurnCS.csproj
	mama/c_cpp/src/c/transport.c
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookBasicDeltaList.cpp
	mamda/c_cpp/src/examples/optionchainer.cpp
	mamda/c_cpp/src/testtools/quoteselftest.vcxproj
	mama/c_cpp/src/cpp/MamaStatus.cpp
	mamda/dotnet/src/examples/MamdaQuoteTicker/MamdaQuoteTickerCS.csproj
	mama/dotnet/src/cs/mamadotnet.csproj
	mamda/c_cpp/src/cpp/MamdaAuctionFields.cpp
	mama/c_cpp/src/gunittest/c/UnitTestMamaMiddlewareC.vcxproj
	mama/dotnet/src/examples/MamaMultiSubscriber/MamaMultiSubscriberCS.csproj
	common/c_cpp/src/c/linux/port.h
	mamda/c_cpp/src/cpp/MamdaSecStatusListener.cpp
	mama/c_cpp/src/gunittest/c/mamaprice/pricerangetests.cpp
	mamda/c_cpp/src/examples/parsecmd.cpp
	common/c_cpp/src/c/windows/wombat/port.h
	mamda/c_cpp/src/cpp/MamdaCommonFields.cpp
	mama/c_cpp/src/c/bridge/qpid/SConscript.win
	mamda/c_cpp/src/cpp/MamdaUtils.h
	mamda/c_cpp/src/cpp/MamdaQuery.cpp
	mama/c_cpp/src/c/msgfield.c
	mama/c_cpp/src/cpp/MamaMsgQual.cpp
	mama/c_cpp/src/cpp/fieldcache/MamaFieldCacheFieldTypes.cpp
	mama/dotnet/src/examples/MamaListen/MamaListenCS.csproj
	mamda/c_cpp/src/examples/orderbooks/mamdabookticker.vcxproj
	mama/c_cpp/src/cpp/MamaSymbolListMember.cpp
	mamda/dotnet/src/examples/MamdaBookTicker/MamdaBookTickerCS.csproj
	mama/c_cpp/src/testtools/load/c/mamachurnc.vcxproj
	mama/c_cpp/src/cpp/datetime.cpp
	mamda/dotnet/src/cs/OrderBook/MamdaBookAtomicBookHandler.cs
	mamda/dotnet/src/examples/MamdaSecStatusTicker/MamdaSecStatusTicker.cs
	mama/c_cpp/src/cpp/MamaDQPublisher.cpp
	mama/c_cpp/src/c/payload/qpidmsg/SConscript.win
	mama/c_cpp/src/examples/cpp/mamaproxycpp.vcxproj
	mama/c_cpp/src/testtools/capturereplay/c/capturec.vcxproj
	mama/c_cpp/src/testtools/capturereplay/c/captureconvert.vcxproj
	common/c_cpp/src/c/wMessageStats.c
	mama/c_cpp/src/cpp/SConscript.win
	mama/c_cpp/src/examples/cpp/mamaproxycpp.cpp
	mamda/c_cpp/src/cpp/SConscript.win
	mama/c_cpp/src/c/bridge/qpid/publisher.c
	mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.vcxproj
	mamda/c_cpp/src/cpp/mamdacpp.vcxproj
	mamda/c_cpp/src/cpp/options/SConscript.win
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookEntry.cpp
	mama/c_cpp/src/c/entitlement/noop/SConscript
	mamda/c_cpp/src/examples/mamdalisten.vcxproj
	mama/c_cpp/src/examples/c/mamalistenc.vcxproj
	mamda/dotnet/src/cs/Options/MamdaOptionChainListener.cs
	mamda/c_cpp/src/cpp/MamdaOrderImbalanceFields.cpp
	mamda/dotnet/src/cs/Options/SimpleDateFormat.cs
	mama/c_cpp/src/examples/cpp/mamainboxcpp.vcxproj
	mama/c_cpp/src/cpp/MamaDictionary.cpp
	mamda/c_cpp/src/examples/secstatuslisten.cpp
	mamda/c_cpp/src/cpp/MamdaOrderImbalanceSide.cpp
	mama/c_cpp/src/cpp/MamaMsg.cpp
	mama/c_cpp/src/gunittest/c/mamamsg/msgfieldatomictests.cpp
	mama/c_cpp/src/gunittest/c/UnitTestMamaPriceC.vcxproj
	mamda/dotnet/src/cs/MamdaTradeCorrection.cs
	mama/c_cpp/src/cpp/MamaFieldDescriptor.cpp
	mamda/dotnet/src/examples/MamdaComboTicker/MamdaComboTickerCS.csproj
	mamda/c_cpp/src/examples/mamdatradeticker.vcxproj
	common/c_cpp/src/c/linux/wUuid.h
	mama/c_cpp/src/testtools/performance/c/mamaconsumerc.vcxproj
	mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookPriceLevel.cpp
	mama/c_cpp/src/c/payload/qpidmsg/qpidcommon.h
	mamda/c_cpp/src/cpp/news/mamdanews.vcxproj
	mama/jni/src/junittests/MamaPublisherTest.java
	mama/c_cpp/src/cpp/MamaBasicWildCardSubscription.cpp
	mamda/dotnet/src/cs/MamdaConcreteSecurityStatusRecap.cs
	common/c_cpp/src/c/windows/strpcasecmp.c
	mama/c_cpp/src/c/mamac.vcxproj
	mama/c_cpp/src/cpp/MamaSubscription.cpp
	mama/c_cpp/src/c/payload/qpidmsg/payload.h
	mama/c_cpp/src/examples/cpp/mamalistencachedcpp.cpp
	mama/c_cpp/src/testtools/load/c/mamachurnc.c
	mamda/c_cpp/src/examples/multipartticker.cpp
	mama/dotnet/src/cs/MamaMsg.cs


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #183
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Re: Documentation question on middleware bridge development

Keith Rudd
 

Classification: Public

Thanks Frank – very useful links.

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: 13 September 2017 09:26
To: Keith Rudd <keith.rudd@...>
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Documentation question on middleware bridge development

 

Hi Keith,

 

Yeah there are some docs though I'm sure they could use a refresh:

 

 

Cheers,

Frank

 

On Wed, Sep 13, 2017 at 8:53 AM, Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Does anyone know if there exists, where I could find, a general guide to OpenMAMA middleware bridge development?

 

I  know there are the examples provided to copy (which is how we’ve got started on this before), but some high-level general notes would be a useful introduction.

 

Regards,
Keith

____________________________________________________



Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
10 Upper Bank Street, E14 5GW London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Re: Documentation question on middleware bridge development

Frank Quinn <fquinn.ni@...>
 

Hi Keith,

Yeah there are some docs though I'm sure they could use a refresh:


Cheers,
Frank

On Wed, Sep 13, 2017 at 8:53 AM, Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Does anyone know if there exists, where I could find, a general guide to OpenMAMA middleware bridge development?

 

I  know there are the examples provided to copy (which is how we’ve got started on this before), but some high-level general notes would be a useful introduction.

 

Regards,
Keith

____________________________________________________



Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
10 Upper Bank Street, E14 5GW London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev



Documentation question on middleware bridge development

Keith Rudd
 

Classification: Public

Does anyone know if there exists, where I could find, a general guide to OpenMAMA middleware bridge development?

 

I  know there are the examples provided to copy (which is how we’ve got started on this before), but some high-level general notes would be a useful introduction.

 

Regards,
Keith

____________________________________________________



Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
10 Upper Bank Street, E14 5GW London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Fixed crash with entitlement subscription (#327)
	mama/c_cpp/src/c/subscription.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #182
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Modified MAMA default log level to NORMAL (#329)
	mama/c_cpp/src/c/log.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #181
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] MAMA: Moved background thread destroy to stop (#326)
	mama/c_cpp/src/c/mama.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #180
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Reset plugins to null to avoid double free (#328)
	mama/c_cpp/src/c/plugin.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #179
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Still Failing)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] Fix leak in mamaMsg_detach (#309)
	mama/c_cpp/src/c/queue.c


Results for OpenMAMA_Snapshot_Windows CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Windows
  • Build Number: #173
  • Build Status: Still Failing
  • Build Warnings:
  • Total Amount of Tests: 34
  • Passed: 34
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] Fix leak in mamaMsg_detach (#309)
	mama/c_cpp/src/c/queue.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #178
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.

221 - 240 of 2311