Re: Git repo for the proton Go binding.
I don't really know much about Go, so I mainly have questions rather than answers. - What would actually be included in this 'qpid-proton-go' repo vs the existing qpid-proton repo? - Have you looked into how other Apache projects are supporting go get, if there are any, to see what do they do? I'm not sure how well it would go down with infra to be routinely 'distributing' things directly out of the repo. Might be worth discussing with infra. Perhaps we could point folks at the GitHub mirror to alleviate that? Not sure if there are path issues involved with that though. Somewhat looping back to 'what do other projects do?' again. Robbie On 10 July 2015 at 16:34, aconway acon...@redhat.com wrote: I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based on cloning repos. The go tools assume that each go project has its own repo. I have tried to make this work directly from the proton repo but it is a mess and doesn't work properly. Any objections or suggestions? Anyone got pointers to speed me thru the apache infra process? Cheers, Alan.
Re: Git repo for the proton Go binding.
On 13 July 2015 at 16:23, aconway acon...@redhat.com wrote: On Mon, 2015-07-13 at 13:03 +0100, Robbie Gemmell wrote: I don't really know much about Go, so I mainly have questions rather than answers. - What would actually be included in this 'qpid-proton-go' repo vs the existing qpid-proton repo? The contents of proton-c/bindings/go on branch go1. Basically the Go binding source code. - Have you looked into how other Apache projects are supporting go get, if there are any, to see what do they do? Nope, good point. I've looked at a bunch of google and github projects, but all pure Go so the tools Just Work. Anyone know of other mixed -language projects with a go component? I'm not sure how well it would go down with infra to be routinely 'distributing' things directly out of the repo. I'm pretty sure they're OK with distributing source code out of the repo :) Go distributes everything as pure source, so no unusual use of the repo is implied. I mainly meant that developers and interested folks using the repo to get at the source for inspection and modification isn't necessarily considered the same as using it as a regular entry point for most users. For example, we use the mirror system for our actual [source] releases. That said, if we are discussing a fairly small binding that probably isn't much of an issue, and as I wondered, perhaps the github mirror of the repo might be a useful tool there. I have go get *almost* working directly out of the ASF repo now, but I can't work around all the glitches - in particular the documentation browser is a mess. If I could I would rather keep it all in the same repo. Might be worth discussing with infra. Perhaps we could point folks at the GitHub mirror to alleviate that? Not sure if there are path issues involved with that though. Somewhat looping back to 'what do other projects do?' again. Good point, I'll ask around and on infra, I may be missing something. If anyone's interested in brainstorming about the proper way to do this (esp. anyone who's done Go work) I'd be happy to go over the issues in painful detail. On 10 July 2015 at 16:34, aconway acon...@redhat.com wrote: I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based on cloning repos. The go tools assume that each go project has its own repo. I have tried to make this work directly from the proton repo but it is a mess and doesn't work properly. Any objections or suggestions? Anyone got pointers to speed me thru the apache infra process? Cheers, Alan.
[jira] [Resolved] (PROTON-944) add ability to set a default state for settling received deliveries
[ https://issues.apache.org/jira/browse/PROTON-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-944. --- Resolution: Fixed add ability to set a default state for settling received deliveries --- Key: PROTON-944 URL: https://issues.apache.org/jira/browse/PROTON-944 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 When the link object is free'd it also free's the deliveries, which settles them. If they haven't previously had a state disposition frame sent for them, then the null state is set in the resulting settled disposition, which indicates the default-outcome of the source should be applied. There can however be cases where we may wish a different outcome to apply for a delivery in the case that we haven't explicitly set one before it was settled. It would be helpful in these cases to be able to set a 'default' state that should be applied in the event that no other state has been set/sent before they are settled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Git repo for the proton Go binding.
On Mon, 2015-07-13 at 18:28 +0100, Robbie Gemmell wrote: On 13 July 2015 at 16:23, aconway acon...@redhat.com wrote: On Mon, 2015-07-13 at 13:03 +0100, Robbie Gemmell wrote: I don't really know much about Go, so I mainly have questions rather than answers. - What would actually be included in this 'qpid-proton-go' repo vs the existing qpid-proton repo? The contents of proton-c/bindings/go on branch go1. Basically the Go binding source code. - Have you looked into how other Apache projects are supporting go get, if there are any, to see what do they do? Nope, good point. I've looked at a bunch of google and github projects, but all pure Go so the tools Just Work. Anyone know of other mixed -language projects with a go component? I'm not sure how well it would go down with infra to be routinely 'distributing' things directly out of the repo. I'm pretty sure they're OK with distributing source code out of the repo :) Go distributes everything as pure source, so no unusual use of the repo is implied. I mainly meant that developers and interested folks using the repo to get at the source for inspection and modification isn't necessarily considered the same as using it as a regular entry point for most users. For example, we use the mirror system for our actual [source] releases. That said, if we are discussing a fairly small binding that probably isn't much of an issue, and as I wondered, perhaps the github mirror of the repo might be a useful tool there. +1, we could certainly do that. That doesn't solve the structural problems but I'll keep digging and head scratching. I have go get *almost* working directly out of the ASF repo now, but I can't work around all the glitches - in particular the documentation browser is a mess. If I could I would rather keep it all in the same repo. Might be worth discussing with infra. Perhaps we could point folks at the GitHub mirror to alleviate that? Not sure if there are path issues involved with that though. Somewhat looping back to 'what do other projects do?' again. Good point, I'll ask around and on infra, I may be missing something. If anyone's interested in brainstorming about the proper way to do this (esp. anyone who's done Go work) I'd be happy to go over the issues in painful detail. On 10 July 2015 at 16:34, aconway acon...@redhat.com wrote: I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based on cloning repos. The go tools assume that each go project has its own repo. I have tried to make this work directly from the proton repo but it is a mess and doesn't work properly. Any objections or suggestions? Anyone got pointers to speed me thru the apache infra process? Cheers, Alan.
[jira] [Updated] (PROTON-946) remove generated data structure definitions from protocol.h
[ https://issues.apache.org/jira/browse/PROTON-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael goulish updated PROTON-946: --- Description: Currently protocol.h.py reads the AMQP 1.0 spec xml files and generates all of its output into protocol.h -- even the data structure definitions. Those definitions are currently protected by #ifdef DEFINE_FIELDS , which is defined only in codec.c -- so the definitions only show up in that file, while other .c files only see the declarations. If DEFINE_FIELDS is #defined in any other file, compilation will fail with multiple definition errors. The structure declarations should remain in the .h file , but the actual definitions should be moved into a generated .c file. was: Currently protocol.h.py reads the AMQP 1.0 spec xml files and generates all of its output into protocol.h -- evel the data structure definitions. Those definitions are currently protected by #ifdef DEFINE_FIELDS , which is defined only in codec.c -- so the definitions only show up in that file, while other .c files only see the declarations. If DEFINE_FIELDS is #defined in any other file, compilation will fail with multiple definition errors. The structure declarations should remain in the .h file , but the actual definitions should be moved into a generated .c file. Summary: remove generated data structure definitions from protocol.h (was: remove generated data structure definitions from .protocol.h) remove generated data structure definitions from protocol.h --- Key: PROTON-946 URL: https://issues.apache.org/jira/browse/PROTON-946 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.10 Reporter: michael goulish Assignee: michael goulish Currently protocol.h.py reads the AMQP 1.0 spec xml files and generates all of its output into protocol.h -- even the data structure definitions. Those definitions are currently protected by #ifdef DEFINE_FIELDS , which is defined only in codec.c -- so the definitions only show up in that file, while other .c files only see the declarations. If DEFINE_FIELDS is #defined in any other file, compilation will fail with multiple definition errors. The structure declarations should remain in the .h file , but the actual definitions should be moved into a generated .c file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-945) add ability to set a default state for settling received deliveries
[ https://issues.apache.org/jira/browse/PROTON-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-945: -- Component/s: (was: proton-j) proton-c add ability to set a default state for settling received deliveries --- Key: PROTON-945 URL: https://issues.apache.org/jira/browse/PROTON-945 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Robbie Gemmell Fix For: 0.10 When the link object is free'd it also free's the deliveries, which settles them. If they haven't previously had a state disposition frame sent for them, then the null state is set in the resulting settled disposition, which indicates the default-outcome of the source should be applied. There can however be cases where we may wish a different outcome to apply for a delivery in the case that we haven't explicitly set one before it was settled. It would be helpful in these cases to be able to set a 'default' state that should be applied in the event that no other state has been set/sent before they are settled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-944) add ability to set a default state for settling received deliveries
[ https://issues.apache.org/jira/browse/PROTON-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned PROTON-944: - Assignee: Robbie Gemmell add ability to set a default state for settling received deliveries --- Key: PROTON-944 URL: https://issues.apache.org/jira/browse/PROTON-944 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 When the link object is free'd it also free's the deliveries, which settles them. If they haven't previously had a state disposition frame sent for them, then the null state is set in the resulting settled disposition, which indicates the default-outcome of the source should be applied. There can however be cases where we may wish a different outcome to apply for a delivery in the case that we haven't explicitly set one before it was settled. It would be helpful in these cases to be able to set a 'default' state that should be applied in the event that no other state has been set/sent before they are settled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-944) add ability to set a default state for settling received deliveries
[ https://issues.apache.org/jira/browse/PROTON-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14624945#comment-14624945 ] ASF subversion and git services commented on PROTON-944: Commit b67a2a943017910bcf8bf67a05aafed93ab7b8b1 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=b67a2a9 ] PROTON-944: add ability to set a default state for use when settling/freeing received deliveries without having previously set/sent dispositon state for them add ability to set a default state for settling received deliveries --- Key: PROTON-944 URL: https://issues.apache.org/jira/browse/PROTON-944 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 When the link object is free'd it also free's the deliveries, which settles them. If they haven't previously had a state disposition frame sent for them, then the null state is set in the resulting settled disposition, which indicates the default-outcome of the source should be applied. There can however be cases where we may wish a different outcome to apply for a delivery in the case that we haven't explicitly set one before it was settled. It would be helpful in these cases to be able to set a 'default' state that should be applied in the event that no other state has been set/sent before they are settled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-945) add ability to set a default state for settling received deliveries
Robbie Gemmell created PROTON-945: - Summary: add ability to set a default state for settling received deliveries Key: PROTON-945 URL: https://issues.apache.org/jira/browse/PROTON-945 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Robbie Gemmell Fix For: 0.10 When the link object is free'd it also free's the deliveries, which settles them. If they haven't previously had a state disposition frame sent for them, then the null state is set in the resulting settled disposition, which indicates the default-outcome of the source should be applied. There can however be cases where we may wish a different outcome to apply for a delivery in the case that we haven't explicitly set one before it was settled. It would be helpful in these cases to be able to set a 'default' state that should be applied in the event that no other state has been set/sent before they are settled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-945) add ability to set a default state for settling received deliveries
[ https://issues.apache.org/jira/browse/PROTON-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-945: -- Fix Version/s: (was: 0.10) Description: When the link object is free'd it also free's the deliveries, which settles them. If they haven't previously had a state disposition frame sent for them, then the null state is set in the resulting settled disposition, which indicates the default-outcome of the source should be applied. There can however be cases where we may wish a different outcome to apply for a delivery in the case that we haven't explicitly set one before it was settled. It would be helpful in these cases to be able to set a 'default' state that should be applied in the event that no other state has been set/sent before they are settled. Clone of PROTON-944 for proton-j, as the change seems more involved for proton-c and may be risky this close to release. was:When the link object is free'd it also free's the deliveries, which settles them. If they haven't previously had a state disposition frame sent for them, then the null state is set in the resulting settled disposition, which indicates the default-outcome of the source should be applied. There can however be cases where we may wish a different outcome to apply for a delivery in the case that we haven't explicitly set one before it was settled. It would be helpful in these cases to be able to set a 'default' state that should be applied in the event that no other state has been set/sent before they are settled. add ability to set a default state for settling received deliveries --- Key: PROTON-945 URL: https://issues.apache.org/jira/browse/PROTON-945 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Robbie Gemmell When the link object is free'd it also free's the deliveries, which settles them. If they haven't previously had a state disposition frame sent for them, then the null state is set in the resulting settled disposition, which indicates the default-outcome of the source should be applied. There can however be cases where we may wish a different outcome to apply for a delivery in the case that we haven't explicitly set one before it was settled. It would be helpful in these cases to be able to set a 'default' state that should be applied in the event that no other state has been set/sent before they are settled. Clone of PROTON-944 for proton-j, as the change seems more involved for proton-c and may be risky this close to release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-946) remove generated data structure definitions from .protocol.h
michael goulish created PROTON-946: -- Summary: remove generated data structure definitions from .protocol.h Key: PROTON-946 URL: https://issues.apache.org/jira/browse/PROTON-946 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.10 Reporter: michael goulish Assignee: michael goulish Currently protocol.h.py reads the AMQP 1.0 spec xml files and generates all of its output into protocol.h -- evel the data structure definitions. Those definitions are currently protected by #ifdef DEFINE_FIELDS , which is defined only in codec.c -- so the definitions only show up in that file, while other .c files only see the declarations. If DEFINE_FIELDS is #defined in any other file, compilation will fail with multiple definition errors. The structure declarations should remain in the .h file , but the actual definitions should be moved into a generated .c file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Git repo for the proton Go binding.
On Mon, 2015-07-13 at 13:03 +0100, Robbie Gemmell wrote: I don't really know much about Go, so I mainly have questions rather than answers. - What would actually be included in this 'qpid-proton-go' repo vs the existing qpid-proton repo? The contents of proton-c/bindings/go on branch go1. Basically the Go binding source code. - Have you looked into how other Apache projects are supporting go get, if there are any, to see what do they do? Nope, good point. I've looked at a bunch of google and github projects, but all pure Go so the tools Just Work. Anyone know of other mixed -language projects with a go component? I'm not sure how well it would go down with infra to be routinely 'distributing' things directly out of the repo. I'm pretty sure they're OK with distributing source code out of the repo :) Go distributes everything as pure source, so no unusual use of the repo is implied. I have go get *almost* working directly out of the ASF repo now, but I can't work around all the glitches - in particular the documentation browser is a mess. If I could I would rather keep it all in the same repo. Might be worth discussing with infra. Perhaps we could point folks at the GitHub mirror to alleviate that? Not sure if there are path issues involved with that though. Somewhat looping back to 'what do other projects do?' again. Good point, I'll ask around and on infra, I may be missing something. If anyone's interested in brainstorming about the proper way to do this (esp. anyone who's done Go work) I'd be happy to go over the issues in painful detail. On 10 July 2015 at 16:34, aconway acon...@redhat.com wrote: I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based on cloning repos. The go tools assume that each go project has its own repo. I have tried to make this work directly from the proton repo but it is a mess and doesn't work properly. Any objections or suggestions? Anyone got pointers to speed me thru the apache infra process? Cheers, Alan.
[jira] [Created] (PROTON-943) Bump library (.so) major version for proton-c libraries
Ted Ross created PROTON-943: --- Summary: Bump library (.so) major version for proton-c libraries Key: PROTON-943 URL: https://issues.apache.org/jira/browse/PROTON-943 Project: Qpid Proton Issue Type: Task Components: proton-c Reporter: Ted Ross Priority: Blocker Fix For: 0.10 0.10 contains incompatible API changes. The library major versions need to be incremented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Git repo for the proton Go binding.
On 13 July 2015 at 19:04, aconway acon...@redhat.com wrote: On Mon, 2015-07-13 at 18:28 +0100, Robbie Gemmell wrote: On 13 July 2015 at 16:23, aconway acon...@redhat.com wrote: On Mon, 2015-07-13 at 13:03 +0100, Robbie Gemmell wrote: I don't really know much about Go, so I mainly have questions rather than answers. - What would actually be included in this 'qpid-proton-go' repo vs the existing qpid-proton repo? The contents of proton-c/bindings/go on branch go1. Basically the Go binding source code. - Have you looked into how other Apache projects are supporting go get, if there are any, to see what do they do? Nope, good point. I've looked at a bunch of google and github projects, but all pure Go so the tools Just Work. Anyone know of other mixed -language projects with a go component? I'm not sure how well it would go down with infra to be routinely 'distributing' things directly out of the repo. I'm pretty sure they're OK with distributing source code out of the repo :) Go distributes everything as pure source, so no unusual use of the repo is implied. I mainly meant that developers and interested folks using the repo to get at the source for inspection and modification isn't necessarily considered the same as using it as a regular entry point for most users. For example, we use the mirror system for our actual [source] releases. That said, if we are discussing a fairly small binding that probably isn't much of an issue, and as I wondered, perhaps the github mirror of the repo might be a useful tool there. +1, we could certainly do that. That doesn't solve the structural problems but I'll keep digging and head scratching. I meant the mirror of any new repo needed as well, in case that wasn't clear. I have go get *almost* working directly out of the ASF repo now, but I can't work around all the glitches - in particular the documentation browser is a mess. If I could I would rather keep it all in the same repo. Might be worth discussing with infra. Perhaps we could point folks at the GitHub mirror to alleviate that? Not sure if there are path issues involved with that though. Somewhat looping back to 'what do other projects do?' again. Good point, I'll ask around and on infra, I may be missing something. If anyone's interested in brainstorming about the proper way to do this (esp. anyone who's done Go work) I'd be happy to go over the issues in painful detail. On 10 July 2015 at 16:34, aconway acon...@redhat.com wrote: I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based on cloning repos. The go tools assume that each go project has its own repo. I have tried to make this work directly from the proton repo but it is a mess and doesn't work properly. Any objections or suggestions? Anyone got pointers to speed me thru the apache infra process? Cheers, Alan.
Tutorial for C++ binding
I've got a (very rough, very incomplete) draft of the tutorial for the C++ binding up on http://people.apache.org/~aconway/proton/ I'm interested in feedback on whether this is going in the right direction. Hope to have this complete in a day or two, along with more substantial API doc for the C++ API. Gory details: The site is doxygen. I used pandoc to convert gsim's rst tutorial to markdown (which doxygen understands) and just started hacking. I was hoping to find ways we could re-use tutorial text automatically but so far the tutorial discussion is too closely intertwined with language specifics for me to see how that could reasonably work so although the text is mostly the same its all manual editing. Cheers, Alan.
Re: Git repo for the proton Go binding.
-aconway acon...@redhat.com wrote: - I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based on cloning repos. The go tools assume that each go project has its own repo. I have tried to make this work directly from the proton repo but it is a mess and doesn't work properly. Is this just because the go code isn't at the top-level? Can't you just rename your current branch out of the way and then subtree the binding and push it to the go1 branch? e.g., something like... # rename old full tree branch and push it to a new location git checkout -b proton-go origin/go1 git push origin --set-upstream proton-go # split out just the go binding and push it git subtree split --prefix=proton-c/bindings/go -b go1 git checkout go1 git push -f origin go1 `go get` will look for the go1 branch by default, so it should just work (tm) ? Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
