[jira] [Commented] (PROTON-238) Initial CTest support
[ https://issues.apache.org/jira/browse/PROTON-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578572#comment-13578572 ] Mary hinton commented on PROTON-238: This will be a nice feature. Visual Studio doesn't use make. I think we could substitute the devenv (IDE) command line for make. e.g. devenv proton.sln /Build Debug That might help automate it for Visual Studio. Initial CTest support - Key: PROTON-238 URL: https://issues.apache.org/jira/browse/PROTON-238 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.3 Environment: Mainly proton-c and interop testing. Reporter: Cliff Jansen Assignee: Cliff Jansen This is a proposal for starting to use CMake's built in CTest capabilities in order to allow a unified test mechanism on multiple platforms. For the supplied review patch, it assumes that instead of using trunk/config.sh and calling proton-test directly, you do: cd path/to/trunk mkdir build cd build cmake .. make ctest Assuming the make succeeds, this will test two targets for now (proton-c and proton-jni), but the newer proposed tests (i.e. performance) can be added as well. Once the desired work flow is captured, this can be tweaked to run in a platform neutral way. CMake even has the capability to run CTest from inside the Visual Studio IDE. Concepts and strategies are stolen from the qpid/cpp tree. By default, you just get a brief summary of the tests. Also try ctest -V [ to see the full output ] ctest -N [ to list the available tests ] ctest -R proton-c [ just run the one test in this case, or a regexp if supplied ] ctest -E regexp [ run all tests except ones that match regexp ] Fancier tests can use cmake scripts to do things in a platform neutral manner (move files around), run the test from a different directory, etc. Python scripts and Java programs are already platform neutral, so there is no need to make changes for those. Tests can be conditionally configured (in the example proton-jni will not be configured if maven or java aren't found). Note that if you wish to just build and test proton-c, there is no requirement to build from within the specific directory .../trunk/build. This restriction currently exists for testing proton-jni using maven, but perhaps that can be relaxed in future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: (was: getopt.c) Porting Issue -- Visual Studio does not provide a getopt() function --- Key: PROTON-236 URL: https://issues.apache.org/jira/browse/PROTON-236 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Fix For: 0.4 Since Visual Studio 2010 does not provide a getopt(), I used the getopt() function found in the GNU library getopt.h and getopt.c. I made a few minor changes and will attach these files to this JIRA. Besides the proton.c file, the proton project workspace for Visual Studio would need to include getopt() files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: getopt.h Porting Issue -- Visual Studio does not provide a getopt() function --- Key: PROTON-236 URL: https://issues.apache.org/jira/browse/PROTON-236 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Fix For: 0.4 Attachments: getopt.c, getopt.h Since Visual Studio 2010 does not provide a getopt(), I used the getopt() function found in the GNU library getopt.h and getopt.c. I made a few minor changes and will attach these files to this JIRA. Besides the proton.c file, the proton project workspace for Visual Studio would need to include getopt() files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-237) Porting Issue -- basename() not found in Visual Studio 2010
Mary hinton created PROTON-237: -- Summary: Porting Issue -- basename() not found in Visual Studio 2010 Key: PROTON-237 URL: https://issues.apache.org/jira/browse/PROTON-237 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows Visual Studio 2010 Reporter: Mary hinton Fix For: 0.4 The basename() function in proton.c is not found in Visual Studio 2010. It is in Visual Studio 2012 when the filesystem header is included. It is only used in a printf statement and is not needed for porting to Visual Studio 2010: printf(Usage: %s [-h] [-c [user[:password]@]host[:port]] [-a address] [-m sasl-mech]\n, basename(argv[0])); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
Mary hinton created PROTON-236: -- Summary: Porting Issue -- Visual Studio does not provide a getopt() function Key: PROTON-236 URL: https://issues.apache.org/jira/browse/PROTON-236 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Fix For: 0.4 Since Visual Studio 2010 does not provide a getopt(), I used the getopt() function found in the GNU library getopt.h and getopt.c. I made a few minor changes and will attach these files to this JIRA. Besides the proton.c file, the proton project workspace for Visual Studio would need to include getopt() files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: getopt.c Porting Issue -- Visual Studio does not provide a getopt() function --- Key: PROTON-236 URL: https://issues.apache.org/jira/browse/PROTON-236 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Fix For: 0.4 Attachments: getopt.c Since Visual Studio 2010 does not provide a getopt(), I used the getopt() function found in the GNU library getopt.h and getopt.c. I made a few minor changes and will attach these files to this JIRA. Besides the proton.c file, the proton project workspace for Visual Studio would need to include getopt() files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: getopt.h Porting Issue -- Visual Studio does not provide a getopt() function --- Key: PROTON-236 URL: https://issues.apache.org/jira/browse/PROTON-236 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Fix For: 0.4 Attachments: getopt.c, getopt.h Since Visual Studio 2010 does not provide a getopt(), I used the getopt() function found in the GNU library getopt.h and getopt.c. I made a few minor changes and will attach these files to this JIRA. Besides the proton.c file, the proton project workspace for Visual Studio would need to include getopt() files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13576842#comment-13576842 ] Mary hinton commented on PROTON-236: Not sure if the getopt should be included in the proton executable project or in the Visual Studio qpid-proton dll. I made a few changes in the getopt code for Visual Studio. Porting Issue -- Visual Studio does not provide a getopt() function --- Key: PROTON-236 URL: https://issues.apache.org/jira/browse/PROTON-236 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Fix For: 0.4 Attachments: getopt.c, getopt.h Since Visual Studio 2010 does not provide a getopt(), I used the getopt() function found in the GNU library getopt.h and getopt.c. I made a few minor changes and will attach these files to this JIRA. Besides the proton.c file, the proton project workspace for Visual Studio would need to include getopt() files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-226) Porting Issue -- Heap Corruption using Visual Studio when running client/server proton in debug mode.
Mary hinton created PROTON-226: -- Summary: Porting Issue -- Heap Corruption using Visual Studio when running client/server proton in debug mode. Key: PROTON-226 URL: https://issues.apache.org/jira/browse/PROTON-226 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Code changes for windows port were added (MinGW and Visual Studio) to the proton codebase recently. Using the new codebase and some additional changes, I ran the proton executable using the Visual Studio toolset as both a server and client. When the client exits, a Windows popup displays: Windows has triggered a breakpoint in proton.exe. This may be due to a corruption of the heap, which indicates a bug in proton.exe or any of the DLLs it has loaded. Still tracking this problem down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Is Proton a lightweight alternative to Qpid?
For anyone interested in a Windows port of the qpid amqp 1.0, I have Visual Studio 10 snapshots available on my github webpage. (Visual Studio port of proton and a qpid port loading proton) I placed my Visual Studio port of the qpid project on my github website. https://github.com/MaryDHinton/qpid/tree/qpidWinSnap You can download a zip file by selecting the ZIP button on the Webpage. To compile and run this code you will also need to download, compile, and run the Snapshot code of the proton Windows port. It is located at: https://github.com/MaryDHinton/qpid-proton/tree/protonWinSnap Both projects are set up for Visual Studio 10 and debug mode. I don't know any reason why they wouldn't work for Visual Studio 12. == Proton === To compile and run the proton port code, all you should need to do is: Select the zip button on the page above and extract the code. Select the proton.sln file in the proton-c folder and open it in Visual Studio 2010. Compile the qpid-proton and proton projects. Go to the Debug folder and run proton (the debug version is the only mode set up, the release will have to be set up). I set up an environment variable for the proton after building the proton dll, then added this environment variable to the qpid project in the C/C++ properties page (Additional Include Directories). Set the environment variable PROTON_INCLUDE --- to your environment. Mine is set to: C:\proton\protonWinSnap\qpid-proton\proton-c\include;C:\proton\protonWinSnap \qpid-proton\proton-c I also have the path to proton executable set in my environment path c:\qpid\qpid\proton\proton-c\Debug After the proton dll and proton executable are compiled, you can run proton in server and client mode. Server mode: Open up a dialog box and change to the proton path and run proton Client mode: Open up a second dialog box and change to the proton path and run proton -c 127.0.0.1 You should be able to see messages passed between a proton client and server. QPID AMQP 1.0 === For QPID, I used Boost 1.51.0. I have a solution file (qpid-cpp-Snap.sln) for the qpid port that includes only the projects to compile, run, and test the qpid amqp 1.0 for Visual Studio. projects included: amqp amqpc hello_world qpid-client-test qpidbroker qpidclient qpidcommon qpidd qpidmessaqing qpidtypes You may need to check the Visual Studio Properties for the 10 projects in this solution and make sure the paths are correct on your pc. I used the path C:\qpidWin to put the extracted files from the zip. After building both the proton Windows port and the QPID port for the server and client, the amqp 1.0 can be loaded in the server with the following command from the path where your dlls and executables are located. The path setup in this solution is: c:\qpidWin\Debug server c:\qpidWin\qpidWinSnap\qpid\qpid\cpp\output\Debugqpidd --load-module amqpd --auth no clients set the environment variable QPID_LOAD_MODULE to amqpcd hello_world client hello_world qpid-client-test client qpid-client-test --verbose response: Opened connection. Opened session. Declared exchange. Declared queue. Bound queue to exchange. Published message: abcdefghijklmnop... Received the exepected message. Closed session. Closed connection. If you are using Norton's antivirus, you may have to disable checking for the Suspicious.Cloud.7.F signature. Original email on these snapshots was sent as: Windows Snapshot of QPID that loads the AMQP 1.0 module (proton windows port) on 12/18/2012 to d...@qpid.apache.org and Proton Port for Windows on 11/14/2012 proton@qpid.apache.org So both ports need to be rebased. I'm planning to do this soon, since a new release is out for proton Thanks, Mary Hinton -Original Message- From: Eagy, Taylor [mailto:te...@blackbirdtech.com] Sent: Wednesday, January 16, 2013 12:13 PM To: proton
[jira] [Commented] (PROTON-68) Porting Issue -- dll imports and exports on Visual Studio
[ https://issues.apache.org/jira/browse/PROTON-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551777#comment-13551777 ] Mary hinton commented on PROTON-68: --- I haven’t heard anything about adding the macros needed for dll imports and exports for a Visual Studio port. Cliff Jensen mention using the gcc switch –fvisibility=hidden, so I looked up what it does. The online documentation states that this feature “can very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any shared objects you distribute.” Tumentation also points you to other sources 1) Ulrich Drepper’s paper: “A good explanation of the benefits offered by ensuring ELF symbols have the correct visibility is given by “How To Write Shared Libraries” by Ulrich Drepper (which can be found at http://people.redhat.com/~drepper/)—however a superior solution made possible by this option to marking things hidden when the default is public is to make the default hidden and mark things public. This is the norm with DLL's on Windows and with -fvisibility=hidden and __attribute__ ((visibility(default))) instead of __declspec(dllexport) you get almost identical semantics with identical syntax. This is a great boon to those working with cross-platform projects.” “Export Control” starts on p. 17 of this paper by listing the drawbacks when you fail to restrict the set of exported symbols. Not restricting the set of exported symbols is the default for gcc. 2) http://gcc.gnu.org/wiki/Visibility Visual Studio requires you to explicitly set what symbols and functions will be exported. The gcc shared libraries for proton would also be improved if we exported only the necessary functions and symbols, using the visibilty switch and the necessary shared library header file. The wiki pages has a very good example of what is needed in their Step-by-step guide for Windows and GNU. Here is the example listed for the header file needed: // Generic helper definitions for shared library support #if defined _WIN32 || defined __CYGWIN__ #define FOX_HELPER_DLL_IMPORT __declspec(dllimport) #define FOX_HELPER_DLL_EXPORT __declspec(dllexport) #define FOX_HELPER_DLL_LOCAL #else #if __GNUC__ = 4 #define FOX_HELPER_DLL_IMPORT __attribute__ ((visibility (default))) #define FOX_HELPER_DLL_EXPORT __attribute__ ((visibility (default))) #define FOX_HELPER_DLL_LOCAL __attribute__ ((visibility (hidden))) #else #define FOX_HELPER_DLL_IMPORT #define FOX_HELPER_DLL_EXPORT #define FOX_HELPER_DLL_LOCAL #endif #endif // Now we use the generic helper definitions above to define FOX_API and FOX_LOCAL. // FOX_API is used for the public API symbols. It either DLL imports or DLL exports (or does nothing for static build) // FOX_LOCAL is used for non-api symbols. #ifdef FOX_DLL // defined if FOX is compiled as a DLL #ifdef FOX_DLL_EXPORTS // defined if we are building the FOX DLL (instead of using it) #define FOX_API FOX_HELPER_DLL_EXPORT #else #define FOX_API FOX_HELPER_DLL_IMPORT #endif // FOX_DLL_EXPORTS #define FOX_LOCAL FOX_HELPER_DLL_LOCAL #else // FOX_DLL is not defined: this means FOX is a static lib. #define FX_API #define FOX_LOCAL #endif // FOX_DLL Porting Issue -- dll imports and exports on Visual Studio - Key: PROTON-68 URL: https://issues.apache.org/jira/browse/PROTON-68 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Labels: build Visual Studio dlls use a macro to explicitly state which functions will be exported. I don’t have a list of all the functions that will be exported, so I just made the ones used by proton.c to be exportable. That left a lot that would be internal to the dll only. Then when I was working with the python, I realized that python was going to be importing a lot of functions from the dll that should never be exported unless testing, so I defined another macro for the python (ruby, etc) exported functions. Swig also had to be taken into account. This is what I’m using right now and it should work on the Linux/Unix platform: #ifdef SWIGWIN #define QPID_PROTON_API #else #ifdef _WINDOWS #ifdef qpid_proton_EXPORTS #define QPID_PROTON_API __declspec(dllexport) #ifdef qpid_proton_python_EXPORTS #define QPID_PROTON_PY __declspec(dllexport) #else #define QPID_PROTON_PY
RE: Language example apps...
Thanks Henry, I asked my question wrong. I was really wondering if anyone was working on a set of C++ tests, similar to the Python tests. Thanks, Mary -Original Message- From: William Henry [mailto:whe...@redhat.com] Sent: Wednesday, January 02, 2013 12:51 PM To: proton@qpid.apache.org Cc: dpie...@redhat.com Subject: Re: Language example apps... Hi Mary, It is my understanding that the existing C++ examples should work because the proton based C++ API the Qpid proper API with the proton C API under the covers. That said, I'm not sure what testing has been done to make sure this is true. Also it would seem that perhaps there might be two sets of examples (?). i.e. What happens to old style addresses in the new proton enabled C++ API? Do the still just work? Can I mix simple proton addressing with the more complex previous addressing that allowed us to build exchanges and queues? William - Original Message - In terms of depth, I'm concerned that deep examples will be difficult/impossible to maintain well in 5 different languages (6 if we do something with C++). Above you mentioned the possibility of C++ examples. Is anyone currently working on creating C++ examples? Thanks, Mary -Original Message- From: Darryl L. Pierce [mailto:dpie...@redhat.com] Sent: Friday, November 30, 2012 4:05 PM To: proton@qpid.apache.org Subject: Re: Language example apps... On Fri, Nov 30, 2012 at 12:36:34PM -0500, Rafael Schloming wrote: On Tue, Nov 20, 2012 at 2:34 PM, Darryl L. Pierce dpie...@redhat.comwrote: Last week Justin asked me to take a look at the examples for Proton across language bindings. What I found are the following: C Python Ruby Perl Mailbox (Raw API)[ ] [X] [X] [ ] Send/Receive (Messenger classes) [ ] [X] [X] [X] Send/Receive (Non-Messenger) [X] [ ] [ ] [ ] We also have a PHP binding and it has some examples also. Yeah, sorry to forget that. What came out of the discussion was that there's a definite lack of depth with the examples. The Mailbox demo is a nice, specific example of stored messaging. The Send/Receive examples show very simple point-to-point messaging. But what else should be included in examples? The first thing that comes to mind is an example demonstrating subscriptions. Ideas? A couple of random thoughts off the top of my head... I think the focus for the dynamic language bindings should really be messenger based examples. I would say it's really not worth having non messenger examples for the dynamic languages, particularly as those kinds of examples are much more involved and maintaining duplicate examples involves some significant maintenance effort. I would rather see a very well maintained/structured C example for the non messenger stuff. In fact I'd go so far as to say we shouldn't bother exposing the non messenger APIs through the bindings at all, with the exception of python for testing purposes of course. To be clear I'm not opposed to exposing them, I just don't think there is any demand at this point and I think it just creates unnecessary work until there is. In terms of depth, I'm concerned that deep examples will be difficult/impossible to maintain well in 5 different languages (6 if we do something with C++). What I'd suggest we start with is a basic, well thought out, but simple messenger based example geared towards getting people started, and strive to keep that consistent and up to date across all the bindings. I'd keep deep scenarios to one language only (at least at first), choosing whichever seems most appropriate for that particular deep scenario. If we keep the languages as consist as possible across the bindings, then one language doing a deep example and others doing more general examples should be workable. Assuming the one language is as easy to understand for someone not familiar with it to follow. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
RE: [jira] [Commented] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts
It looks like the explicit casts in the attached explicitCasts2.patch in this
Jira never got added to the codebase.
Could I get them added?
Two changes.
It looks like pn_encode_value() was removed from coedc.c
Also pn_queue_init() in messenger.c needs an explicit cast.
void pn_queue_init(pn_queue_t *queue)
{
queue-capacity = 1024;
queue-window = 0;
queue-lwm = 0;
queue-hwm = 0;
queue-deliveries = calloc(queue-capacity, sizeof(pn_delivery_t *));
}
Line 86 should be
queue-deliveries = (pn_delivery_t **) calloc(queue-capacity,
sizeof(pn_delivery_t *));
Thanks,
Mary
-Original Message-
From: Mary hinton (JIRA) [mailto:j...@apache.org]
Sent: Monday, November 19, 2012 10:07 AM
To: proton@qpid.apache.org
Subject: [jira] [Commented] (PROTON-98) Porting Issue -- Visual Studio compiler
requires explicit casts
[
https://issues.apache.org/jira/browse/PROTON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500287#comment-13500287
]
Mary hinton commented on PROTON-98:
---
This patch can also be viewed at github in branch protonWin
explicit casts - Jira Proton-98
https://github.com/MaryDHinton/qpid-proton/commits/protonWin
Porting Issue -- Visual Studio compiler requires explicit casts
---
Key: PROTON-98
URL: https://issues.apache.org/jira/browse/PROTON-98
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
Labels: build
Attachments: explicitCasts2.patch, ExplicitCasts.patch
I would like to get the code changed to add explicit casts where the Visual
Studio compiler requires it.
The GNU compiler isn t so picky, but we need the explicit casts for Visual
Studio tools.
The problem is in many of the files.
C:\qpid\qpid\proton\proton-c\src\proton.c(278): struct client_context *ctx
= (client_context *) pn_connector_context(ctor);// explicit
cast
C:\qpid\qpid\proton\proton-c\src\buffer.c(41): pn_buffer_t *buf =
(pn_buffer_t *) malloc(sizeof(pn_buffer_t)); //
explicit cast
C:\qpid\qpid\proton\proton-c\src\buffer.c(45): buf-bytes = capacity ?
(char *) malloc(capacity) : NULL; //
explicit cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t)
PN_ARG_ERR; //
explicit cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t)
PN_ARG_ERR; //
explicit cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom-u.type =
(pn_type_t) va_arg(*ap, int); //
explicit cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311): char **sptr
= (char **) ptr; // explicit
cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875): pn_data_t *data =
(pn_data_t *) malloc(sizeof(pn_data_t)); //
explicit cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878): data-nodes =
capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL; //
explicit cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931): data-nodes =
(pn_node_t *) realloc(data-nodes, data-capacity * sizeof(pn_node_t));
// explicit cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char
**sptr = (char**) ptr;
// explicit cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t)
-1; //
explicit cast
C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t)
-1; //
explicit cast
C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32):
pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t),
1); // explicit cast
C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47): disp-output
= (char *) malloc(disp-capacity); // explicit
cast
C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248):
disp-output = (char *) realloc(disp-output, disp-capacity);//
explicit cast
C:\qpid\qpid\proton\proton-c\src\driver.c(193): pn_listener_t *l =
(pn_listener_t *) malloc(sizeof(pn_listener_t));//
explicit cast
C:\qpid\qpid\proton\proton-c\src\driver.c(410): pn_connector_t *c =
(pn_connector_t *) malloc(sizeof(pn_connector_t
RE: Some proton portability work.
What is planned for the driver code for Windows? Maybe I could help. I have a Windows port running and could put more patches in Jira for changes to the driver code required by Windows. Thanks, Mary Hinton -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Wednesday, December 05, 2012 5:04 PM To: proton Subject: Some proton portability work. I've committed some portability work on proton today. At this point, proton should configure and compile without error on FreeBSD and MacOS X. I've also done a bit of work which improves compilation under gcc on Solaris too, but this isn't finished (Solaris is missing any functionality to easily ignore SIGPIPE when writing to closed sockets). I've also done a bit of work to get it cross compile under mingw32, but again there are some remaining issues (ignoring the fact that the driver code for Windows isn't finished anyway) Questions, bugs etc. to me Andrew
RE: Some proton portability work.
That sounds good. -Original Message- From: Cliff Jansen [mailto:cliffjan...@gmail.com] Sent: Wednesday, December 05, 2012 6:33 PM To: proton@qpid.apache.org Subject: Re: Some proton portability work. Hi Mary, Unless you have a problem with the driver in https://reviews.apache.org/r/6302/ I was just about to dust that off (update it and/or pull in your github work) and work it in parallel with proton-159. In theory the 2 together should result in proton working with C++ and Windows libraries. The additional steps to get a Visual Studio implementation should be very straight forward after that. As before, the intent is to get a functional driver (without ssl for now) that can get people going on Windows. A high performance driver (with overlapped io presumably) and with ssl integration would follow later. Cliff On Wed, Dec 5, 2012 at 2:45 PM, Mary Hinton m.hin...@nc.rr.com wrote: What is planned for the driver code for Windows? Maybe I could help. I have a Windows port running and could put more patches in Jira for changes to the driver code required by Windows. Thanks, Mary Hinton -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Wednesday, December 05, 2012 5:04 PM To: proton Subject: Some proton portability work. I've committed some portability work on proton today. At this point, proton should configure and compile without error on FreeBSD and MacOS X. I've also done a bit of work which improves compilation under gcc on Solaris too, but this isn't finished (Solaris is missing any functionality to easily ignore SIGPIPE when writing to closed sockets). I've also done a bit of work to get it cross compile under mingw32, but again there are some remaining issues (ignoring the fact that the driver code for Windows isn't finished anyway) Questions, bugs etc. to me Andrew
RE: Proton Port for Windows
I'm glad protonWinSnap worked for you. You're right about protonWin. It is just for patch reviews and will not compile in Windows without all the patches added to the code. I won't be able to keep protonWinSnap as up to date as I would like, but if it gets too far out of date, let me know and I will try to rebase the code with the current proton codebase. Right now, I'm trying to get the amqpd.dll broker plug-in (a project created within QPID) to load. To get the new AMQP 1.0 (includes proton) to compile, I had to change some code and don't have everything resolved yet. Mary Hinton From: Ljupco Taseski [mailto:t...@digiverse.si] Sent: Tuesday, December 04, 2012 11:35 AM To: Mary Hinton Cc: proton@qpid.apache.org Subject: Re: Proton Port for Windows Thanks! protonWinSnap works fine for me, at least from what I have seen so far. If I understood correctly, protonWinSnap will be kept up to date until the merge to the main codebase is done, and that protonWin is meant only for patch reviews? Regards, Ljupco On 30 November 2012 14:27, Mary Hinton m.hin...@nc.rr.com wrote: Sure, it may take a while to get the proton group's approval for a merge. In the meantime, I have a snapshot of the Windows port at github. protonWinSnap is a snapshot of the code and protonWin will be the one used to add patches for the proton community to check out. To see the Windows port running, use this branch https://github.com/MaryDHinton/qpid-proton/tree/protonWinSnap To compile and run this code, all you should need to do is: Select the zip button on the page above and extract the code. Select the proton.sln file in the proton-c folder and open it in Visual Studio 2010. Compile the qpid-proton and proton projects. Go to the Debug folder and run proton (the debug version is the only mode set up, the release will have to be set up). You should be able to see messages passed between a proton client and server. The patches will be added to this branch as they become available: https://github.com/MaryDHinton/qpid-proton/commits/protonWin Let me know how it works for you. Mary Hinton -Original Message- From: Ljupco Taseski [mailto:t...@digiverse.si] Sent: Friday, November 30, 2012 5:45 AM To: proton@qpid.apache.org Cc: m.hin...@nc.rr.com Subject: Re: Proton Port for Windows Is it possible to have a look at the Windows port? I wouldn't mind even if it is a simple tgz/zip snapshot. Thanks, Ljupco
RE: Proton Port for Windows
Sure, it may take a while to get the proton group's approval for a merge. In the meantime, I have a snapshot of the Windows port at github. protonWinSnap is a snapshot of the code and protonWin will be the one used to add patches for the proton community to check out. To see the Windows port running, use this branch https://github.com/MaryDHinton/qpid-proton/tree/protonWinSnap To compile and run this code, all you should need to do is: Select the zip button on the page above and extract the code. Select the proton.sln file in the proton-c folder and open it in Visual Studio 2010. Compile the qpid-proton and proton projects. Go to the Debug folder and run proton (the debug version is the only mode set up, the release will have to be set up). You should be able to see messages passed between a proton client and server. The patches will be added to this branch as they become available: https://github.com/MaryDHinton/qpid-proton/commits/protonWin Let me know how it works for you. Mary Hinton -Original Message- From: Ljupco Taseski [mailto:t...@digiverse.si] Sent: Friday, November 30, 2012 5:45 AM To: proton@qpid.apache.org Cc: m.hin...@nc.rr.com Subject: Re: Proton Port for Windows Is it possible to have a look at the Windows port? I wouldn't mind even if it is a simple tgz/zip snapshot. Thanks, Ljupco On 14 November 2012 15:19, Mary Hinton m.hin...@nc.rr.com wrote: Hi everyone, I'd like to share the status of the Windows port of the proton code. The last rebase of the proton dll codebase was this Saturday, Nov. 10th. I haven't updated to the latest python tests yet, but currently, the port is running and passing most of the python tests. Totals: 119 tests, 105 passed, 6 skipped, 0 ignored, 8 failed I can run proton in both client and server mode and pass the messages between the client/server proton executables. It will be a while for all the Jiras for the port to be discussed and implemented to merge the two ports. I tried to maintain the code to keep the two versions working, but haven't actually tested my version on Linux yet. There are #ifdef's around areas that are specific to each port. A lot of these #ifdef's can be merged when the proton group decides on the best way to handle the specific areas. In the meantime, I would like to have a public place to put the port so that others can join in with the Windows version. What is the best way to do this using git so that I don't interfere with the current codebase? Thanks, Mary Hinton
PROTON - amqp 1.0 support
Hi, I'm trying to use the optional amqp 1.0 support for qpid within cmake, but I get the following message in debug mode: CMake Error at src/amqp.cmake:38 (message): Qpid proton not found, required for amqp 1.0 support. I have the environment system variables - PROTON_HOME and PROJECT_SOURCE_DIR set. Does anyone know what else I might need to set? I'm working in Windows and have a Windows version of proton working. I also had a qpid windows project setup, but I'm trying to setup the latest qpid code with amqp 1.0 support. Thanks, Mary
[jira] [Updated] (PROTON-148) Porting Issue -- Visual Studio requires an explicit cast inside the resize macros
[
https://issues.apache.org/jira/browse/PROTON-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mary hinton updated PROTON-148:
---
Attachment: PN_ENSURE.patch
Porting Issue -- Visual Studio requires an explicit cast inside the resize
macros
-
Key: PROTON-148
URL: https://issues.apache.org/jira/browse/PROTON-148
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: WIndows using Visual Studio 2010
Reporter: Mary hinton
Labels: build
Attachments: PN_ENSURE.patch
The PN_ENSURE and PN_ENSUREZ macros do not compile using Visual Studio
toolset.
Suggest changing the macros to the following for both ports:
#define PN_ENSURE(ARRAY, CAPACITY, COUNT, PNTYPE) \
while ((CAPACITY) (COUNT)) { \
(CAPACITY) = (CAPACITY) ? 2 * (CAPACITY) : 16; \
(ARRAY) = (PNTYPE) realloc((ARRAY), (CAPACITY) * sizeof (*(ARRAY))); \
}
#define PN_ENSUREZ(ARRAY, CAPACITY, COUNT, PNTYPE)\
{\
size_t _old_capacity = (CAPACITY); \
PN_ENSURE((ARRAY), (CAPACITY), (COUNT), PNTYPE); \
memset((ARRAY) + _old_capacity, 0, \
sizeof(*(ARRAY))*((CAPACITY) - _old_capacity)); \
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-124) Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll
[ https://issues.apache.org/jira/browse/PROTON-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-124: --- Attachment: WinSockets.patch Attached file is for initialization and cleanup of the Windows socket dll. It can also be viewed here: https://github.com/MaryDHinton/qpid-proton/compare/protonWin Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll -- Key: PROTON-124 URL: https://issues.apache.org/jira/browse/PROTON-124 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Attachments: WinSockets.patch Put the WSAStartup code in pn_driver() and the WSACleanup() code in pn_driver_free(). Used a _WINDOWS macro around the Windows code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-99) Porting Issue -- pn_dtag macro does not compile with Visual Studio compiler
[
https://issues.apache.org/jira/browse/PROTON-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mary hinton updated PROTON-99:
--
Attachment: pn_dtag.patch
This patch can also be viewed at github in branch protonWin
PROTON-99 changed pn_dtag macro to a function
https://github.com/MaryDHinton/qpid-proton/compare/protonWin
Porting Issue -- pn_dtag macro does not compile with Visual Studio compiler
---
Key: PROTON-99
URL: https://issues.apache.org/jira/browse/PROTON-99
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
Labels: build
Attachments: pn_dtag.patch
I would like to replace the pn_dtag macro with a function that will compile
using either GNU or Visual Studio compilers.
engine.h
Replace:
#define pn_dtag(BYTES, SIZE) ((pn_delivery_tag_t) {(SIZE), (BYTES)}
With:
pn_delivery_tag_t pn_dtag(const char *bytes, size_t size);
engine.c
Add:
pn_delivery_tag_t pn_dtag(const char *bytes, size_t size)
{
pn_delivery_tag_t delivt;
delivt.bytes = bytes;
delivt.size = size;
return delivt;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-124) Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll
[ https://issues.apache.org/jira/browse/PROTON-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500504#comment-13500504 ] Mary hinton commented on PROTON-124: test Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll -- Key: PROTON-124 URL: https://issues.apache.org/jira/browse/PROTON-124 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Attachments: WinSockets.patch Put the WSAStartup code in pn_driver() and the WSACleanup() code in pn_driver_free(). Used a _WINDOWS macro around the Windows code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-123) Porting Issue -- Visual Studio compilers do not support %zu and %zi (C99) in printf statements
Mary hinton created PROTON-123: -- Summary: Porting Issue -- Visual Studio compilers do not support %zu and %zi (C99) in printf statements Key: PROTON-123 URL: https://issues.apache.org/jira/browse/PROTON-123 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Replaced the %zu and %zi with %lu and %li. %li for ssize_t and %lu for size_t -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-124) Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll
Mary hinton created PROTON-124: -- Summary: Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll Key: PROTON-124 URL: https://issues.apache.org/jira/browse/PROTON-124 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Put the WSAStartup code in pn_driver() and the WSACleanup() code in pn_driver_free(). Used a _WINDOWS macro around the Windows code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: review request: patch to cmake for windows builds
of the compiler. If anyone can provide better settings - please let me know. Here's the current settings: CMAKE_C_FLAGS_DEBUG /Wall /Iinclude /MDd /Od /Zi) CMAKE_C_FLAGS_RELEASE/Wall /Iinclude /MD /Ox /D NDEBUG) CMAKE_C_FLAGS_RELWITHDEBINFO /Wall /Iinclude /MD /Ox /Zi) -K - Original Message - Ah, then this patch is for *you*! :) It -should- fix it so you don't have to modify the project files at all, and it should fix those header files too. You should just be able to run cmake, then pull the result into VS and build. It doesn't go so far as to run the tests though - we'll need to get the code ported first. thanks, -K - Original Message - I used cmake to create Visual Studio 10 projects files and solution workspace. Then I modified the project files to add what I needed. I hadn't used cmake before this project. So I'm not an expert. I'll be happy to have your help with creating good support for building proton from cmake. The python support definitely needs to be fixed. And I would be happy to have that part working properly. I've been creating the header files (encodings.h and protocol.h) and setting up the python to run the tests outside of the project files. I'll look at your changes as soon as I can. Mary -Original Message- From: Ken Giusti [mailto:kgiu...@redhat.com] Sent: Wednesday, October 31, 2012 1:47 PM To: cliffjan...@gmail.com; Mary Hinton Cc: proton@qpid.apache.org Subject: review request: patch to cmake for windows builds Hi Cliff/Mary, I'm trying to add support for building proton using Microsoft Visual C++ express. This patch updates cmake to enable generation of the VC++ project files for proton. Can you review and try it out - let me know what you think? Note that the patch only adds build support - the problems with building proton on windows are not addressed. The diff can be viewed here: https://github.com/kgiusti/qpid-proton/compare/win7 And the changes are on the win7 branch of my github proton repo: git://github.com/kgiusti/qpid-proton.git -K
RE: review request: patch to cmake for windows builds
Maybe this will help. In my project file for the dll, the command lines in the debugger are: C/C++ compiler: /Iinclude /IC:/qpid/qpid/proton/proton-c /IC:/qpid/qpid/proton/proton-c/include /Zi /nologo /Wall /WX- /Od /Ob0 /Oy- /D qpid_proton_python_EXPORTS /D WIN32 /D _WINDOWS /D WIN32_LEAN_AND_MEAN /D _WIN32_WINNT=0x0600 /D _DEBUG /D CMAKE_INTDIR=\Debug\ /D qpid_proton_EXPORTS /D _WINDLL /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fpqpid-proton.dir\Debug\qpid-proton.pch /FaDebug /Foqpid-proton.dir\Debug\ /FdC:/qpid/qpid/proton/proton-c/Debug/qpid-proton.pdb /Gd /TP /analyze- /errorReport:queue Linker: /OUT:C:\qpid\qpid\proton\proton-c\Debug\qpid-proton.dll /INCREMENTAL /NOLOGO /DLL ws2_32.lib rpcrt4.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /ManifestFile:qpid-proton.dir\Debug\qpid-proton.dll.intermediate.manifest /ALLOWISOLATION /MANIFESTUAC:level='asInvoker' uiAccess='false' /DEBUG /PDB:C:/qpid/qpid/proton/proton-c/Debug/qpid-proton.pdb /SUBSYSTEM:CONSOLE /STACK:1000 /PGD:C:\qpid\qpid\proton\proton-c\Debug\qpid-proton.pgd /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:C:/qpid/qpid/proton/proton-c/Debug/qpid-proton.lib /MACHINE:X86 /ERRORREPORT:QUEUE Release Version: C/C++ /Iinclude /IC:/qpid/qpid/proton/proton-c /IC:/qpid/qpid/proton/proton-c/include /nologo /Wall /WX- /O2 /Ob2 /Oy- /D WIN32 /D _WINDOWS /D WIN32_LEAN_AND_MEAN /D _WIN32_WINNT=0x0502 /D NDEBUG /D CMAKE_INTDIR=\Release\ /D qpid_proton_EXPORTS /D _WINDLL /D _MBCS /Gm- /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fpqpid-proton.dir\Release\qpid-proton.pch /FaRelease /Foqpid-proton.dir\Release\ /FdC:/qpid/qpid/proton/proton-c/Release/qpid-proton.pdb /Gd /TP /analyze- /errorReport:queue Linker: /OUT:C:\qpid\qpid\proton\proton-c\Release\qpid-proton.dll /INCREMENTAL:NO /NOLOGO /DLL ws2_32.lib rpcrt4.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /ManifestFile:qpid-proton.dir\Release\qpid-proton.dll.intermediate.manifest /ALLOWISOLATION /MANIFESTUAC:level='asInvoker' uiAccess='false' /PDB:C:/qpid/qpid/proton/proton-c/Release/qpid-proton.pdb /SUBSYSTEM:CONSOLE /STACK:1000 /PGD:C:\qpid\qpid\proton\proton-c\Release\qpid-proton.pgd /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:C:/qpid/qpid/proton/proton-c/Release/qpid-proton.lib /MACHINE:X86 /ERRORREPORT:QUEUE Of course some of the above is specific for the paths of the developer and some are default settings that will not need to be added. I added the libraries ws2_32.lib, rpcrt4.lib, and uuid.lib. All the other libraries should be default libraries. -Original Message- From: Ken Giusti [mailto:kgiu...@redhat.com] Sent: Wednesday, October 31, 2012 3:05 PM To: proton@qpid.apache.org Subject: Re: review request: patch to cmake for windows builds Ah, almost forgot: The patch modifies the CMakeLists.txt file by adding compiler flags for the VC++ compiler. The flags differ based on each type of target build (Debug/Release/etc). Now, IANAVCP (I Am Not a VC Programmer), so I have no idea what the appropriate flags should be for the windows build. I've taken a guess at them, based on my limited understanding of the compiler. If anyone can provide better settings - please let me know. Here's the current settings: CMAKE_C_FLAGS_DEBUG /Wall /Iinclude /MDd /Od /Zi) CMAKE_C_FLAGS_RELEASE/Wall /Iinclude /MD /Ox /D NDEBUG) CMAKE_C_FLAGS_RELWITHDEBINFO /Wall /Iinclude /MD /Ox /Zi) -K - Original Message - Ah, then this patch is for *you*! :) It -should- fix it so you don't have to modify the project files at all, and it should fix those header files too. You should just be able to run cmake, then pull the result into VS and build. It doesn't go so far as to run the tests though - we'll need to get the code ported first. thanks, -K - Original Message - I used cmake to create Visual Studio 10 projects files and solution workspace. Then I modified the project files to add what I needed. I hadn't used cmake before this project. So I'm not an expert. I'll be happy to have your help with creating good support for building proton from cmake. The python support definitely needs to be fixed. And I would be happy to have that part working properly. I've been creating the header files (encodings.h and protocol.h) and setting up the python to run the tests outside of the project files. I'll look at your changes as soon as I can. Mary -Original Message- From: Ken Giusti [mailto:kgiu...@redhat.com] Sent: Wednesday, October 31, 2012 1:47 PM To: cliffjan...@gmail.com; Mary Hinton Cc: proton@qpid.apache.org Subject: review request: patch to cmake for windows builds Hi Cliff/Mary, I'm trying to add support for building proton using Microsoft
[jira] [Commented] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts
[ https://issues.apache.org/jira/browse/PROTON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481458#comment-13481458 ] Mary hinton commented on PROTON-98: --- Missed the second one in sasl.c C:\qpid\qpid\proton\proton-c\src\sasl\sasl.c(362): pn_sasl_t *sasl = (pn_sasl_t *) disp-context;// explicit cast Porting Issue -- Visual Studio compiler requires explicit casts --- Key: PROTON-98 URL: https://issues.apache.org/jira/browse/PROTON-98 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Labels: build I would like to get the code changed to add explicit casts where the Visual Studio compiler requires it. The GNU compiler isn’t so picky, but we need the explicit casts for Visual Studio tools. The problem is in many of the files. C:\qpid\qpid\proton\proton-c\src\proton.c(278): struct client_context *ctx = (client_context *) pn_connector_context(ctor);// explicit cast C:\qpid\qpid\proton\proton-c\src\buffer.c(41): pn_buffer_t *buf = (pn_buffer_t *) malloc(sizeof(pn_buffer_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\buffer.c(45): buf-bytes = capacity ? (char *) malloc(capacity) : NULL; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t) PN_ARG_ERR; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t) PN_ARG_ERR; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom-u.type = (pn_type_t) va_arg(*ap, int); // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311): char **sptr = (char **) ptr; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875): pn_data_t *data = (pn_data_t *) malloc(sizeof(pn_data_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878): data-nodes = capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931): data-nodes = (pn_node_t *) realloc(data-nodes, data-capacity * sizeof(pn_node_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char **sptr = (char**) ptr; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t) -1; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t) -1; // explicit cast C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32): pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t), 1); // explicit cast C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47): disp-output = (char *) malloc(disp-capacity); // explicit cast C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248): disp-output = (char *) realloc(disp-output, disp-capacity);// explicit cast C:\qpid\qpid\proton\proton-c\src\driver.c(193): pn_listener_t *l = (pn_listener_t *) malloc(sizeof(pn_listener_t));// explicit cast C:\qpid\qpid\proton\proton-c\src\driver.c(410): pn_connector_t *c = (pn_connector_t *) malloc(sizeof(pn_connector_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\driver.c(656): pn_driver_t *d = (pn_driver_t *) malloc(sizeof(pn_driver_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\driver.c(748):d-fds = (pollfd *) realloc(d-fds, d-capacity*sizeof(struct pollfd)); // explicit cast C:\qpid\qpid\proton\proton-c\src\engine\engine.c(47): db-deliveries = (pn_delivery_state_t *) malloc(sizeof(pn_delivery_state_t) * capacity);// explicit cast C:\qpid\qpid\proton\proton-c\src\engine\engine.c(438): pn_connection_t *conn = (pn_connection_t *)malloc(sizeof(pn_connection_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\engine\engine.c(730): pn_session_t *ssn = (pn_session_t *) malloc(sizeof(pn_session_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\engine
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[ https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13474090#comment-13474090 ] Mary hinton commented on PROTON-57: --- For the ones you want a fixed maximum length, is there a specific size for printing the atoms and data that you want? The same with the maximum length for the addresses, what size would you like to specify? “pn_data_encode/decode(...) For these we should add a dedicated array to pn_data_t and grow the array as needed.” pn_data_encode() used a VLA for allocating atoms on the stack. Did you want me to put in a pointer to atoms in pn_data_t and then allocate it out of heap and if needed realloc() and free it in pn_data_free()? Proton porting problems between current codebase and Visual Studio 2010 toolset --- Key: PROTON-57 URL: https://issues.apache.org/jira/browse/PROTON-57 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Labels: build This thread will be used to discuss the porting problems encountered using Visual Studio 2010 Here’s the first one to discuss: 1. Visual Studio doesn’t support variable length arrays. a. Currently using malloc()/realloc() in my port just to get it to compile and be able to report memory allocation errors. This is not what I want to submit to the proton group for memory allocation. b. Cliff had a good method that included setting up macros and replace the VLAs with alloca() in the Windows version, but it could still cause problems when the stack overflowed. VLAs can also run out of stack space. c. _malloca() should be a better way than _alloca() on Visual Studio. Any messages under 1K would be allocated out of the stack. Over 1K will use heap. If the average messages are under 1K, this may be the most efficient way in Visual Studio. _malloca() also has new security enhancements. 1. Using _malloca() in the Windows version and VLA in Linux would require two macros. The major difference for the Linux version would be to use the new macro for VLA and to include the new free macro even though there is nothing to free using VLA. In Visual Studio, _freea(buf) will not free anything if it is allocating off the stack. Linux can continue to use VLAs. #ifdef C99 #define PN_VLA(TYPE, buf, size) TYPE buf[size] #define PN_VLA_FREE #else #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) _malloca(size) #define PN_VLA_FREE(buf) _freea(buf) #endif d. If the average size messages to allocate out of the stack needs to be increased for performance reasons, we can set up a new memory model. The 1K is not adjustable for _malloca(). We can set up new macros along the lines of Microsoft’s suggestion below. “I would suggest something similar to what ATL does. Use alloca for small (where you define what that is) sizes and use heap allocation for larger ones. You can wrap the logic inside of a class or macros. To work around the fact that alloca isn't cleaned up at block scope, rewrite the block into functions or use lambdas. (I think alloca works inside of lambdas.)” -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-67) Porting Issue -- Initialization with braces is not supported by Visual Studio.
[
https://issues.apache.org/jira/browse/PROTON-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13474125#comment-13474125
]
Mary hinton commented on PROTON-67:
---
Hi Cliff and Andrew,
Whatever you want to use for the #ifdef is fine, as long as it distinguishes
the Visual Studio port. I'll change the #ifdef's accordingly.
I did find this about different compilers:
Notice that not all compliant compilers provides the correct pre-defined
macros. For example, Microsoft Visual C++ does not define __STDC__, or Sun
Workshop 4.2 supports C94 without setting __STDC_VERSION__ to the proper value.
Extra checks for such compilers must be added.
Notice that some compilers, such as the HP aC++, use the value 199707L to
indicate the C++98 standard. This value was used in an earlier proposal of the
C++98 standard.
Porting Issue -- Initialization with braces is not supported by Visual Studio.
--
Key: PROTON-67
URL: https://issues.apache.org/jira/browse/PROTON-67
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
Labels: build
In the Windows port, I used ifdef(s) for the initializations to keep the
current code for Linux, and added code to compile in Visual Studio. If there
is no objection, maybe we could replace the current initialization code with
the Visual Studio code and remove the #ifdef(s).
Here's some examples:
Eample1
ssize_t pn_data_encode(pn_data_t *data, char *bytes, size_t size)
{
#ifndef _WINDOWS
pn_atoms_t latoms = {.size=data-size + data-extras, .start=atoms};
#else
pn_atoms_t latoms;
latoms.size = data-size + data-extras;
latoms.start = atoms;
#endif
Example 2
#ifndef _WINDOWS
return (pn_bytes_t) {size, start};
#else
pn_bytes_t pnBytes;
pnBytes.size = size;
pnBytes.start= start;
return pnBytes;
#endif
Example 3
pn_do_transfer()
#ifndef _WINDOWS
delivery = pn_delivery(link, pn_dtag(tag.start, tag.size));
#else
pn_delivery_tag_t delivt;
delivt.bytes = tag.start;
delivt.size = tag.size;
delivery = pn_delivery(link, delivt);
#endif
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-67) Porting Issue -- Initialization with braces is not supported by Visual Studio.
Mary hinton created PROTON-67:
-
Summary: Porting Issue -- Initialization with braces is not
supported by Visual Studio.
Key: PROTON-67
URL: https://issues.apache.org/jira/browse/PROTON-67
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
In the Windows port, I used ifdef(s) for the initializations to keep the
current code for Linux, and added code to compile in Visual Studio. If there is
no objection, maybe we could replace the current initialization code with the
Visual Studio code and remove the #ifdef(s).
Here's some examples:
Eample1
ssize_t pn_data_encode(pn_data_t *data, char *bytes, size_t size)
{
#ifndef _WINDOWS
pn_atoms_t latoms = {.size=data-size + data-extras, .start=atoms};
#else
pn_atoms_t latoms;
latoms.size = data-size + data-extras;
latoms.start = atoms;
#endif
Example 2
#ifndef _WINDOWS
return (pn_bytes_t) {size, start};
#else
pn_bytes_t pnBytes;
pnBytes.size = size;
pnBytes.start= start;
return pnBytes;
#endif
Example 3
pn_do_transfer()
#ifndef _WINDOWS
delivery = pn_delivery(link, pn_dtag(tag.start, tag.size));
#else
pn_delivery_tag_t delivt;
delivt.bytes = tag.start;
delivt.size = tag.size;
delivery = pn_delivery(link, delivt);
#endif
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-68) Porting Issue -- dll imports and exports on Visual Studio
Mary hinton created PROTON-68: - Summary: Porting Issue -- dll imports and exports on Visual Studio Key: PROTON-68 URL: https://issues.apache.org/jira/browse/PROTON-68 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Visual Studio dlls use a macro to explicitly state which functions will be exported. I don’t have a list of all the functions that will be exported, so I just made the ones used by proton.c to be exportable. That left a lot that would be internal to the dll only. Then when I was working with the python, I realized that python was going to be importing a lot of functions from the dll that should never be exported unless testing, so I defined another macro for the python (ruby, etc) exported functions. Swig also had to be taken into account. This is what I’m using right now and it should work on the Linux/Unix platform: #ifdef SWIGWIN #define QPID_PROTON_API #else #ifdef _WINDOWS #ifdef qpid_proton_EXPORTS #define QPID_PROTON_API __declspec(dllexport) #ifdef qpid_proton_python_EXPORTS #define QPID_PROTON_PY __declspec(dllexport) #else #define QPID_PROTON_PY #endif #else #define QPID_PROTON_API __declspec(dllimport) #ifdef qpid_proton_python_IMPORTS #define QPID_PROTON_PY __declspec(dllimport) #else #define QPID_PROTON_PY #endif #endif #else #define QPID_PROTON_API #endif #endif That means all the headers will need to be changed to include the macros. e.g. QPID_PROTON_API pn_data_t *pn_data(size_t capacity); QPID_PROTON_API void pn_data_free(pn_data_t *data); QPID_PROTON_PY int pn_data_errno(pn_data_t *data); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-67) Porting Issue -- Initialization with braces is not supported by Visual Studio.
[
https://issues.apache.org/jira/browse/PROTON-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13473427#comment-13473427
]
Mary hinton commented on PROTON-67:
---
You're right. I should have said Visual Studio does not support Designated
initializers
Thanks,
Mary
Porting Issue -- Initialization with braces is not supported by Visual Studio.
--
Key: PROTON-67
URL: https://issues.apache.org/jira/browse/PROTON-67
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
Labels: build
In the Windows port, I used ifdef(s) for the initializations to keep the
current code for Linux, and added code to compile in Visual Studio. If there
is no objection, maybe we could replace the current initialization code with
the Visual Studio code and remove the #ifdef(s).
Here's some examples:
Eample1
ssize_t pn_data_encode(pn_data_t *data, char *bytes, size_t size)
{
#ifndef _WINDOWS
pn_atoms_t latoms = {.size=data-size + data-extras, .start=atoms};
#else
pn_atoms_t latoms;
latoms.size = data-size + data-extras;
latoms.start = atoms;
#endif
Example 2
#ifndef _WINDOWS
return (pn_bytes_t) {size, start};
#else
pn_bytes_t pnBytes;
pnBytes.size = size;
pnBytes.start= start;
return pnBytes;
#endif
Example 3
pn_do_transfer()
#ifndef _WINDOWS
delivery = pn_delivery(link, pn_dtag(tag.start, tag.size));
#else
pn_delivery_tag_t delivt;
delivt.bytes = tag.start;
delivt.size = tag.size;
delivery = pn_delivery(link, delivt);
#endif
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[ https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471371#comment-13471371 ] Mary hinton commented on PROTON-57: --- I forgot to put the sizeof(TYPE) for Windows in the Macro for Windows port #ifdef C99 #define PN_VLA(TYPE, buf, size) TYPE buf[size] #define PN_VLA_FREE #else #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) _malloca((size) * sizeof(TYPE)) #define PN_VLA_FREE(buf) _freea(buf) #endif Proton porting problems between current codebase and Visual Studio 2010 toolset --- Key: PROTON-57 URL: https://issues.apache.org/jira/browse/PROTON-57 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Labels: build This thread will be used to discuss the porting problems encountered using Visual Studio 2010 Here’s the first one to discuss: 1. Visual Studio doesn’t support variable length arrays. a. Currently using malloc()/realloc() in my port just to get it to compile and be able to report memory allocation errors. This is not what I want to submit to the proton group for memory allocation. b. Cliff had a good method that included setting up macros and replace the VLAs with alloca() in the Windows version, but it could still cause problems when the stack overflowed. VLAs can also run out of stack space. c. _malloca() should be a better way than _alloca() on Visual Studio. Any messages under 1K would be allocated out of the stack. Over 1K will use heap. If the average messages are under 1K, this may be the most efficient way in Visual Studio. _malloca() also has new security enhancements. 1. Using _malloca() in the Windows version and VLA in Linux would require two macros. The major difference for the Linux version would be to use the new macro for VLA and to include the new free macro even though there is nothing to free using VLA. In Visual Studio, _freea(buf) will not free anything if it is allocating off the stack. Linux can continue to use VLAs. #ifdef C99 #define PN_VLA(TYPE, buf, size) TYPE buf[size] #define PN_VLA_FREE #else #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) _malloca(size) #define PN_VLA_FREE(buf) _freea(buf) #endif d. If the average size messages to allocate out of the stack needs to be increased for performance reasons, we can set up a new memory model. The 1K is not adjustable for _malloca(). We can set up new macros along the lines of Microsoft’s suggestion below. “I would suggest something similar to what ATL does. Use alloca for small (where you define what that is) sizes and use heap allocation for larger ones. You can wrap the logic inside of a class or macros. To work around the fact that alloca isn't cleaned up at block scope, rewrite the block into functions or use lambdas. (I think alloca works inside of lambdas.)” -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[
https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470349#comment-13470349
]
Mary hinton commented on PROTON-57:
---
I’m going to list the problems with the biggest hits on the code first.
2. Initialization with braces is not supported by Visual Studio. I used
ifdef(s) in the codebase to keep the current code working for Linux, but
changed quite a few of these to get it to compile in Visual Studio.
Eample1
ssize_t pn_data_encode(pn_data_t *data, char *bytes, size_t size)
{
#ifndef _WINDOWS
pn_atom_t atoms[data-size + data-extras];
pn_atoms_t latoms = {.size=data-size + data-extras, .start=atoms};
#else
PN_VLA(pn_atom_t, atoms, data-size + data-extras);
pn_atoms_t latoms;
latoms.size = data-size + data-extras;
latoms.start = atoms;
#endif
pn_data_as_atoms(data, latoms);
pn_bytes_t lbytes = pn_bytes(size, bytes);
int err = pn_encode_atoms(lbytes, latoms);
PN_VLA_FREE(atoms);
if (err) return err;
return lbytes.size;
}
Example 2
#ifndef _WINDOWS
return (pn_bytes_t) {size, start};
#else
pn_bytes_t pnBytes;
pnBytes.size = size;
pnBytes.start= start;
return pnBytes;
#endif
Example 3
pn_do_transfer()
#ifndef _WINDOWS
delivery = pn_delivery(link, pn_dtag(tag.start, tag.size));
#else
pn_delivery_tag_t delivt;
delivt.bytes = tag.start;
delivt.size = tag.size;
delivery = pn_delivery(link, delivt);
#endif
Proton porting problems between current codebase and Visual Studio 2010
toolset
---
Key: PROTON-57
URL: https://issues.apache.org/jira/browse/PROTON-57
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
Labels: build
This thread will be used to discuss the porting problems encountered using
Visual Studio 2010
Here’s the first one to discuss:
1. Visual Studio doesn’t support variable length arrays.
a. Currently using malloc()/realloc() in my port just to get it to
compile and be able to report memory allocation errors. This is not what I
want to submit to the proton group for memory allocation.
b. Cliff had a good method that included setting up macros and replace
the VLAs with alloca() in the Windows version, but it could still cause
problems when the stack overflowed. VLAs can also run out of stack space.
c. _malloca() should be a better way than _alloca() on Visual Studio.
Any messages under 1K would be allocated out of the stack. Over 1K will use
heap. If the average messages are under 1K, this may be the most efficient
way in Visual Studio. _malloca() also has new security enhancements.
1. Using _malloca() in the Windows version and VLA in Linux would
require two macros. The major difference for the Linux version would be to
use the new macro for VLA and to include the new free macro even though there
is nothing to free using VLA. In Visual Studio, _freea(buf) will not free
anything if it is allocating off the stack.
Linux can continue to use VLAs.
#ifdef C99
#define PN_VLA(TYPE, buf, size) TYPE buf[size]
#define PN_VLA_FREE
#else
#define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*)
_malloca(size)
#define PN_VLA_FREE(buf) _freea(buf)
#endif
d. If the average size messages to allocate out of the stack needs to be
increased for performance reasons, we can set up a new memory model. The 1K
is not adjustable for _malloca().
We can set up new macros along the lines of Microsoft’s suggestion below.
“I would suggest something similar to what ATL does. Use alloca for small
(where you define what that is) sizes and use heap allocation for larger
ones. You can wrap the logic inside of a class or macros. To work around
the fact that alloca isn't cleaned up at block scope, rewrite the block into
functions or use lambdas. (I think alloca works inside of lambdas.)”
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[
https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13469965#comment-13469965
]
Mary hinton commented on PROTON-57:
---
Thanks for the feedback,
We could substitute the alloca() for memory allocation that is not in a loop as
long as the buffers are reasonable sizes.
Since alloca() acquires new stack space each time it's called without reusing
space from previous calls, it's not a good idea to use it inside a loop.
The problem with anything being allocated out of the stack is the size of the
allocation. Stack space can still run out and alloca() will not warn us of a
problem. Using a loop in Linux containing a VLA to reallocate stack space, you
can still get segmentation failure if the allocation is large enough. Also if
large messages have been allocated on the stack, the memory can be reused, but
my understanding is that the stack doesn't shrink. The only way to recover
stack memory is when the thread exits.
I notice proton is initially set up with a stack space size of 1000, so it
may be expecting lots of large messages. I didn't know how many threads are
being created to handle buffers allocated out of the stack and if the number of
threads could be a problem for stack space usage.
Here's a snippet of code using the macros proposed:
Changed char data[ctx-size + 16];
server_callback()
{
char tagstr[1024];
char msg[10*1024];
PN_VLA(char, data, ctx-size + 16);
...
PN_VLA_FREE(data);
}
I saw various web sites arguing the pros and cons of VLAs, so maybe it is a
good idea to discuss VLAs in their own Jira thread.
Proton porting problems between current codebase and Visual Studio 2010
toolset
---
Key: PROTON-57
URL: https://issues.apache.org/jira/browse/PROTON-57
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
Labels: build
This thread will be used to discuss the porting problems encountered using
Visual Studio 2010
Here’s the first one to discuss:
1. Visual Studio doesn’t support variable length arrays.
a. Currently using malloc()/realloc() in my port just to get it to
compile and be able to report memory allocation errors. This is not what I
want to submit to the proton group for memory allocation.
b. Cliff had a good method that included setting up macros and replace
the VLAs with alloca() in the Windows version, but it could still cause
problems when the stack overflowed. VLAs can also run out of stack space.
c. _malloca() should be a better way than _alloca() on Visual Studio.
Any messages under 1K would be allocated out of the stack. Over 1K will use
heap. If the average messages are under 1K, this may be the most efficient
way in Visual Studio. _malloca() also has new security enhancements.
1. Using _malloca() in the Windows version and VLA in Linux would
require two macros. The major difference for the Linux version would be to
use the new macro for VLA and to include the new free macro even though there
is nothing to free using VLA. In Visual Studio, _freea(buf) will not free
anything if it is allocating off the stack.
Linux can continue to use VLAs.
#ifdef C99
#define PN_VLA(TYPE, buf, size) TYPE buf[size]
#define PN_VLA_FREE
#else
#define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*)
_malloca(size)
#define PN_VLA_FREE(buf) _freea(buf)
#endif
d. If the average size messages to allocate out of the stack needs to be
increased for performance reasons, we can set up a new memory model. The 1K
is not adjustable for _malloca().
We can set up new macros along the lines of Microsoft’s suggestion below.
“I would suggest something similar to what ATL does. Use alloca for small
(where you define what that is) sizes and use heap allocation for larger
ones. You can wrap the logic inside of a class or macros. To work around
the fact that alloca isn't cleaned up at block scope, rewrite the block into
functions or use lambdas. (I think alloca works inside of lambdas.)”
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: proton port to windows using Visual Studio 2010 tools
Thanks, I downloaded the latest code on Saturday and merged what I had. I changed code in 26 files. Some of the changes will be easy to incorporate into the current codebase, others will need decisions from the group as to the best way to add the Windows changes (e.g. #ifdef (s) and/or separate files, etc...). I have a list of most of the changes I made in the code. A major problem is the pipe() and poll() support. I can use the Windows functions, but the windows WSAPoll() works on sockets, not file descriptors. I think the windows version will need to use the Windows IOCompletion ports model for scalability, but I was hoping to substitute the windows functions for poll() and pipe() just to get something up and running. I rebuilt proton and it runs as a server and/or client, but cannot do the poll() correctly. It seems to be getting POLLNVAL using WSAPoll() because the pipe is an invalid socket. The pipe is a file descriptor in Linux, but Windows is expecting a socket in its WSAPOLLFD structure. I was wondering what the pipe() is for? Will this be in the final product or is this a temporary fix for something? Visual Studio doesn't use VLA (variable length arrays), but there are various workarounds for this. I only implemented the simplest change for now, but plan to change it to a better model soon. I am unfamiliar with the apache infrastructure, so I'll need some guidance to present my code for review. There are other incompatibilities with the current codebase and the Visual Studio toolset, since Visual Studio doesn't support C99, but the two above are probably the most serious. Thanks, Mary -Original Message- From: Rafael Schloming [mailto:r...@alum.mit.edu] Sent: Monday, October 01, 2012 12:39 PM To: proton@qpid.apache.org Subject: Re: proton port to windows using Visual Studio 2010 tools Hi Mary, Welcome to the list! I'm looking forward to seeing the issues you've hit. It would be great to have proton working with the Visual Studio toolset. If you have patches ready to go already our main tools for collaboration are JIRA[1] and reviewboard[2]. Please feel free to ask questions about either if you're unfamiliar with apache infrastructure. [1] https://issues.apache.org/jira/browse/PROTON [2] https://reviews.apache.org/groups/qpid/ --Rafael On Fri, Sep 28, 2012 at 1:12 PM, Mary Hinton m.hin...@nc.rr.com wrote: Hi all, I am new to proton and will be helping out with a Windows port of proton-C using the Visual Studio 2010 toolset. With a first pass through the code, I have a list of porting issues that need to be addressed by the proton group. These will be introduced shortly for your review and comments. Thanks, Mary Hinton
