Classification: Public Hi team, We found that Java publishing was broken when onSuccess event was introduced. The problem is here - mamapublisherjni.c, function

Hi Folks, As part of the last round of integration testing prior to the last release, we noticed that Java and C# builds were actually broken and had to be fixed fairly last-minute. To prevent this

Some changes have just been added to the origin/next branch! [Frank Quinn] Set build product to mamdaall release_scripts/ci-run.py[Frank Quinn] Fixed bug in java deserialization

Some changes have just been added to the origin/next branch! [noreply] Fixed memory leak in MamaMsgField (#331) mama/c_cpp/src/cpp/mama/MamaMsgField.h mama/c_cpp/src/cpp/MamaMsgField.cpp Results for

Hi Victor, Apologies - yes the website is out of date - I'll update it. We now follow: https://openmama.github.io/openmama_submission_process.html I did raise the PR on your request

Hey Damian, Could you apply the patch? I thought it's official way to contribute changes - it is documented on openmama.org -> Contribute. 08.11.2017, 14:51, "Damian Maguire" <dmaguire@...>:

Hey Victor, In Github projects, forking is generally the best way to work with the project, and is the recommended approach for raising patches for OpenMAMA - you can actually see the forks used by

Hi Frank, I don't know how to make pull requests without forking the project, that's why I sent the patch. Is it possible for you to apply it? Or is it any instruction on how to do pull

Thanks Victor, Yes I can see how that wouldn't have behaved as expected and fix looks sound. Are you going to raise a pull request against the "next" branch for this or do you want me to take it from

Not sure if my previous mail reached the maillist. Adding list admins, sorry if this is inapropriate. --- It is possible to reproduce memory leak using the following: MamaMsgIterator

Classification: Public Thanks for the details guys!

Hi Yury, Yes that method is deprecated because OpenMAMA prefers dynamic loading methods now (so that payloads don't need to be registered in OpenMAMA's core code to load or depend on magic

No problem Yury, Yes, if I remember correctly the problem here was with some compilers which warned about the declaration of a deprecated method, which meant we wanted to both mark it as deprecated

Classification: For internal use only Hey Damian, OK, thank you for clarification. The reason why I thought that deprecation warnings should be deleted automatically (after defining MAMA_DLL and

Hey Yury, I'm not sure the behaviour you're describing is an issue - the purpose of the pragma's is to allow you to use 'deprecated' features of the API without generating warnings, rather than

Classification: Public Hi team, Is MAMAIgnoreDeprecatedOpen supposed to work for Linux with gcc > 4.6? See the following example: // Next 3 lines were copied from wombat/.../linux/port.h _Pragma

Hi All: I’ve completed a draft version of my latest article on static analysis, using clang and cppcheck on the OpenMAMA code. It can be found at: http://btorpey.github.io/lots-o-static/ I’m

Classification:Public My feedback: Why was extending the existing MamaTransport Callback interface not considered as an approach? All sources are available only in the context of a Mama

Some changes have just been added to the origin/next branch! [Frank Quinn] Added C# generated files to gitignore .gitignore[Frank Quinn] Fixed build for C# unit

I have some feedback about the RFC for OpenMAMA Source Discovery page: https://openmama.github.io/openmama_rfc_source_discovery.html# I’m pretty much in agreement with delivering the source