Open quicklisp opened 3 years ago
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane notifications@github.com wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q .
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown notifications@github.com wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane notifications@github.com wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696972059, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q .
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane zach@quicklisp.org wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown notifications@github.com wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane notifications@github.com wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696972059, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q .
The gtirb project appears OK at HEAD. The version you are compiling seems to be from March, 2020.
The ryeboy package is broken. It has checked in generated protobuf code.
I can provide a function for compatibility, but other changes I've made may cause breakage at run time. The ryeboy folks need to modify their asdf file so they depend on a protobuf source file, not checked in generated Lisp code.
On Tue, Sep 22, 2020 at 5:01 PM Zach Beane notifications@github.com wrote:
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane zach@quicklisp.org wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown notifications@github.com wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane notifications@github.com wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696972059, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696978418, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGVMMEG6D32SZFW6UNGQLSHEGCJANCNFSM4RWFO67Q .
By request, I'm not using the head of gtirb, I'm using a branch, which lags behind.
On Tue, Sep 22, 2020 at 5:12 PM Robert Brown notifications@github.com wrote:
The gtirb project appears OK at HEAD. The version you are compiling seems to be from March, 2020.
The ryeboy package is broken. It has checked in generated protobuf code.
I can provide a function for compatibility, but other changes I've made may cause breakage at run time. The ryeboy folks need to modify their asdf file so they depend on a protobuf source file, not checked in generated Lisp code.
On Tue, Sep 22, 2020 at 5:01 PM Zach Beane notifications@github.com wrote:
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane zach@quicklisp.org wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown <notifications@github.com
wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane notifications@github.com wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696972059, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696978418, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAAGVMMEG6D32SZFW6UNGQLSHEGCJANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696984749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPNLP44CEJMOC2LZR5RS3SHEHMLANCNFSM4RWFO67Q .
I added back two functions that I renamed. No promises that other changes since March have not caused other breakage.
On Tue, Sep 22, 2020 at 5:24 PM Zach Beane notifications@github.com wrote:
By request, I'm not using the head of gtirb, I'm using a branch, which lags behind.
On Tue, Sep 22, 2020 at 5:12 PM Robert Brown notifications@github.com wrote:
The gtirb project appears OK at HEAD. The version you are compiling seems to be from March, 2020.
The ryeboy package is broken. It has checked in generated protobuf code.
I can provide a function for compatibility, but other changes I've made may cause breakage at run time. The ryeboy folks need to modify their asdf file so they depend on a protobuf source file, not checked in generated Lisp code.
On Tue, Sep 22, 2020 at 5:01 PM Zach Beane notifications@github.com wrote:
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane zach@quicklisp.org wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy
http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown < notifications@github.com
wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane < notifications@github.com> wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/brown/protobuf/issues/20#issuecomment-696972059 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696978418, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMEG6D32SZFW6UNGQLSHEGCJANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696984749, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AACPNLP44CEJMOC2LZR5RS3SHEHMLANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696990461, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGVMMFU47ZH7KTMVZKORDSHEIZNANCNFSM4RWFO67Q .
The ryeboy project should be fixed. I sent in a pull request.
On Tue, Sep 22, 2020 at 5:30 PM Robert Brown robert.brown@gmail.com wrote:
I added back two functions that I renamed. No promises that other changes since March have not caused other breakage.
On Tue, Sep 22, 2020 at 5:24 PM Zach Beane notifications@github.com wrote:
By request, I'm not using the head of gtirb, I'm using a branch, which lags behind.
On Tue, Sep 22, 2020 at 5:12 PM Robert Brown notifications@github.com wrote:
The gtirb project appears OK at HEAD. The version you are compiling seems to be from March, 2020.
The ryeboy package is broken. It has checked in generated protobuf code.
I can provide a function for compatibility, but other changes I've made may cause breakage at run time. The ryeboy folks need to modify their asdf file so they depend on a protobuf source file, not checked in generated Lisp code.
On Tue, Sep 22, 2020 at 5:01 PM Zach Beane notifications@github.com wrote:
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane zach@quicklisp.org wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy
http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown < notifications@github.com
wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane < notifications@github.com> wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696972059>, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696978418, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMEG6D32SZFW6UNGQLSHEGCJANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696984749, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AACPNLP44CEJMOC2LZR5RS3SHEHMLANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696990461, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGVMMFU47ZH7KTMVZKORDSHEIZNANCNFSM4RWFO67Q .
Also, the gtirb / grammatech folks say that have updated the branch that Quicklisp uses. If you can verify this, I'll remove LENGTH64 again.
Thanks!
On Tue, Sep 22, 2020 at 9:06 PM Robert Brown robert.brown@gmail.com wrote:
The ryeboy project should be fixed. I sent in a pull request.
On Tue, Sep 22, 2020 at 5:30 PM Robert Brown robert.brown@gmail.com wrote:
I added back two functions that I renamed. No promises that other changes since March have not caused other breakage.
On Tue, Sep 22, 2020 at 5:24 PM Zach Beane notifications@github.com wrote:
By request, I'm not using the head of gtirb, I'm using a branch, which lags behind.
On Tue, Sep 22, 2020 at 5:12 PM Robert Brown notifications@github.com wrote:
The gtirb project appears OK at HEAD. The version you are compiling seems to be from March, 2020.
The ryeboy package is broken. It has checked in generated protobuf code.
I can provide a function for compatibility, but other changes I've made may cause breakage at run time. The ryeboy folks need to modify their asdf file so they depend on a protobuf source file, not checked in generated Lisp code.
On Tue, Sep 22, 2020 at 5:01 PM Zach Beane notifications@github.com wrote:
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane zach@quicklisp.org wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy
http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown < notifications@github.com
wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane < notifications@github.com> wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696972059>, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696978418, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMEG6D32SZFW6UNGQLSHEGCJANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696984749, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AACPNLP44CEJMOC2LZR5RS3SHEHMLANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696990461, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGVMMFU47ZH7KTMVZKORDSHEIZNANCNFSM4RWFO67Q .
So the problem I have for Quicklisp is that installing multiple things with manual make and shell commands is generally a no-go for Quicklisp-provided libraries. That's one reason to include generated protobuf code - to avoid having all users install protoc-gen-lisp.
But I installed protoc-gen-lisp, to try to build in some way, and now ryeboy fails with: First file chunk returned by plugin did not specify a file name.
Do you know what that means and how it might be fixed?
On Wed, Sep 23, 2020 at 8:03 PM Robert Brown notifications@github.com wrote:
Also, the gtirb / grammatech folks say that have updated the branch that Quicklisp uses. If you can verify this, I'll remove LENGTH64 again.
Thanks!
On Tue, Sep 22, 2020 at 9:06 PM Robert Brown robert.brown@gmail.com wrote:
The ryeboy project should be fixed. I sent in a pull request.
On Tue, Sep 22, 2020 at 5:30 PM Robert Brown robert.brown@gmail.com wrote:
I added back two functions that I renamed. No promises that other changes since March have not caused other breakage.
On Tue, Sep 22, 2020 at 5:24 PM Zach Beane notifications@github.com wrote:
By request, I'm not using the head of gtirb, I'm using a branch, which lags behind.
On Tue, Sep 22, 2020 at 5:12 PM Robert Brown <notifications@github.com
wrote:
The gtirb project appears OK at HEAD. The version you are compiling seems to be from March, 2020.
The ryeboy package is broken. It has checked in generated protobuf code.
I can provide a function for compatibility, but other changes I've made may cause breakage at run time. The ryeboy folks need to modify their asdf file so they depend on a protobuf source file, not checked in generated Lisp code.
On Tue, Sep 22, 2020 at 5:01 PM Zach Beane <notifications@github.com
wrote:
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane zach@quicklisp.org wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy
http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown < notifications@github.com
wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane < notifications@github.com> wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696972059>, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696978418>, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMEG6D32SZFW6UNGQLSHEGCJANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/brown/protobuf/issues/20#issuecomment-696984749 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLP44CEJMOC2LZR5RS3SHEHMLANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-696990461, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAAGVMMFU47ZH7KTMVZKORDSHEIZNANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-698034142, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPNLJLIF4I3POPS6VLKPTSHKEELANCNFSM4RWFO67Q .
I guess the protocol buffer should be built using ASDF, but that might be tricky. I don't know what the error means. Did you follow the instructions in the protobuf README.md file? Perhaps you are using a newer version of Google's protoc code than the one I've last tested with.
On Fri, Sep 25, 2020 at 2:53 PM Zach Beane notifications@github.com wrote:
So the problem I have for Quicklisp is that installing multiple things with manual make and shell commands is generally a no-go for Quicklisp-provided libraries. That's one reason to include generated protobuf code - to avoid having all users install protoc-gen-lisp.
But I installed protoc-gen-lisp, to try to build in some way, and now ryeboy fails with: First file chunk returned by plugin did not specify a file name.
Do you know what that means and how it might be fixed?
On Wed, Sep 23, 2020 at 8:03 PM Robert Brown notifications@github.com wrote:
Also, the gtirb / grammatech folks say that have updated the branch that Quicklisp uses. If you can verify this, I'll remove LENGTH64 again.
Thanks!
On Tue, Sep 22, 2020 at 9:06 PM Robert Brown robert.brown@gmail.com wrote:
The ryeboy project should be fixed. I sent in a pull request.
On Tue, Sep 22, 2020 at 5:30 PM Robert Brown robert.brown@gmail.com wrote:
I added back two functions that I renamed. No promises that other changes since March have not caused other breakage.
On Tue, Sep 22, 2020 at 5:24 PM Zach Beane notifications@github.com wrote:
By request, I'm not using the head of gtirb, I'm using a branch, which lags behind.
On Tue, Sep 22, 2020 at 5:12 PM Robert Brown < notifications@github.com
wrote:
The gtirb project appears OK at HEAD. The version you are compiling seems to be from March, 2020.
The ryeboy package is broken. It has checked in generated protobuf code.
I can provide a function for compatibility, but other changes I've made may cause breakage at run time. The ryeboy folks need to modify their asdf file so they depend on a protobuf source file, not checked in generated Lisp code.
On Tue, Sep 22, 2020 at 5:01 PM Zach Beane < notifications@github.com
wrote:
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane zach@quicklisp.org wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy
http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown < notifications@github.com
wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane < notifications@github.com> wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696972059>, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696978418>, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMEG6D32SZFW6UNGQLSHEGCJANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696984749 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLP44CEJMOC2LZR5RS3SHEHMLANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/brown/protobuf/issues/20#issuecomment-696990461 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMFU47ZH7KTMVZKORDSHEIZNANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-698034142, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AACPNLJLIF4I3POPS6VLKPTSHKEELANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-699096430, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGVMLVKCGSJ27IAOMF5TDSHTRI3ANCNFSM4RWFO67Q .
There are two (competing?) protobuf efforts - protobufs (yours) and cl-protobufs (from "qitab"). I installed protoc-gen-lisp from qitab. I don't know if that's what generates the error or not.
Are the projects fundamentally incompatible on a single system?
On Fri, Sep 25, 2020 at 3:11 PM Robert Brown notifications@github.com wrote:
I guess the protocol buffer should be built using ASDF, but that might be tricky. I don't know what the error means. Did you follow the instructions in the protobuf README.md file? Perhaps you are using a newer version of Google's protoc code than the one I've last tested with.
On Fri, Sep 25, 2020 at 2:53 PM Zach Beane notifications@github.com wrote:
So the problem I have for Quicklisp is that installing multiple things with manual make and shell commands is generally a no-go for Quicklisp-provided libraries. That's one reason to include generated protobuf code - to avoid having all users install protoc-gen-lisp.
But I installed protoc-gen-lisp, to try to build in some way, and now ryeboy fails with: First file chunk returned by plugin did not specify a file name.
Do you know what that means and how it might be fixed?
On Wed, Sep 23, 2020 at 8:03 PM Robert Brown notifications@github.com wrote:
Also, the gtirb / grammatech folks say that have updated the branch that Quicklisp uses. If you can verify this, I'll remove LENGTH64 again.
Thanks!
On Tue, Sep 22, 2020 at 9:06 PM Robert Brown robert.brown@gmail.com wrote:
The ryeboy project should be fixed. I sent in a pull request.
On Tue, Sep 22, 2020 at 5:30 PM Robert Brown <robert.brown@gmail.com
wrote:
I added back two functions that I renamed. No promises that other changes since March have not caused other breakage.
On Tue, Sep 22, 2020 at 5:24 PM Zach Beane < notifications@github.com> wrote:
By request, I'm not using the head of gtirb, I'm using a branch, which lags behind.
On Tue, Sep 22, 2020 at 5:12 PM Robert Brown < notifications@github.com
wrote:
The gtirb project appears OK at HEAD. The version you are compiling seems to be from March, 2020.
The ryeboy package is broken. It has checked in generated protobuf code.
I can provide a function for compatibility, but other changes I've made may cause breakage at run time. The ryeboy folks need to modify their asdf file so they depend on a protobuf source file, not checked in generated Lisp code.
On Tue, Sep 22, 2020 at 5:01 PM Zach Beane < notifications@github.com
wrote:
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane <zach@quicklisp.org
wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy
http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown < notifications@github.com
wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane < notifications@github.com> wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696972059 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696978418>, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMEG6D32SZFW6UNGQLSHEGCJANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696984749 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLP44CEJMOC2LZR5RS3SHEHMLANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696990461 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMFU47ZH7KTMVZKORDSHEIZNANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-698034142, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLJLIF4I3POPS6VLKPTSHKEELANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-699096430, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAAGVMLVKCGSJ27IAOMF5TDSHTRI3ANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-699105470, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPNLMMLJNMCW557HTRI2TSHTTOTANCNFSM4RWFO67Q .
I don't know. I've not tried the cl-protobuf package recently. They use my ASDF code, so in principle they should be compatible at build time. The programmer APIs may not be compatible.
On Fri, Sep 25, 2020 at 3:15 PM Zach Beane notifications@github.com wrote:
There are two (competing?) protobuf efforts - protobufs (yours) and cl-protobufs (from "qitab"). I installed protoc-gen-lisp from qitab. I don't know if that's what generates the error or not.
Are the projects fundamentally incompatible on a single system?
On Fri, Sep 25, 2020 at 3:11 PM Robert Brown notifications@github.com wrote:
I guess the protocol buffer should be built using ASDF, but that might be tricky. I don't know what the error means. Did you follow the instructions in the protobuf README.md file? Perhaps you are using a newer version of Google's protoc code than the one I've last tested with.
On Fri, Sep 25, 2020 at 2:53 PM Zach Beane notifications@github.com wrote:
So the problem I have for Quicklisp is that installing multiple things with manual make and shell commands is generally a no-go for Quicklisp-provided libraries. That's one reason to include generated protobuf code - to avoid having all users install protoc-gen-lisp.
But I installed protoc-gen-lisp, to try to build in some way, and now ryeboy fails with: First file chunk returned by plugin did not specify a file name.
Do you know what that means and how it might be fixed?
On Wed, Sep 23, 2020 at 8:03 PM Robert Brown notifications@github.com wrote:
Also, the gtirb / grammatech folks say that have updated the branch that Quicklisp uses. If you can verify this, I'll remove LENGTH64 again.
Thanks!
On Tue, Sep 22, 2020 at 9:06 PM Robert Brown robert.brown@gmail.com wrote:
The ryeboy project should be fixed. I sent in a pull request.
On Tue, Sep 22, 2020 at 5:30 PM Robert Brown <robert.brown@gmail.com
wrote:
I added back two functions that I renamed. No promises that other changes since March have not caused other breakage.
On Tue, Sep 22, 2020 at 5:24 PM Zach Beane < notifications@github.com> wrote:
By request, I'm not using the head of gtirb, I'm using a branch, which lags behind.
On Tue, Sep 22, 2020 at 5:12 PM Robert Brown < notifications@github.com
wrote:
The gtirb project appears OK at HEAD. The version you are compiling seems to be from March, 2020.
The ryeboy package is broken. It has checked in generated protobuf code.
I can provide a function for compatibility, but other changes I've made may cause breakage at run time. The ryeboy folks need to modify their asdf file so they depend on a protobuf source file, not checked in generated Lisp code.
On Tue, Sep 22, 2020 at 5:01 PM Zach Beane < notifications@github.com
wrote:
For me, it would be helpful if you could provide the old name for compatibility. I filed bug reports with the projects but they have not been updated yet.
On Tue, Sep 22, 2020 at 4:52 PM Zach Beane <zach@quicklisp.org
wrote:
Some grammatech projects (gtirb-related) and a project called "ryeboy" have broken:
http://report.quicklisp.org/2020-09-22/failure-report/ryeboy.html#ryeboy
http://report.quicklisp.org/2020-09-22/failure-report/gtirb.html#proto
On Tue, Sep 22, 2020 at 4:49 PM Robert Brown < notifications@github.com
wrote:
I renamed the function length-uint64. I could provide the old name for compatibility. What exactly has broken? I'm surprised that code outside of my protobuf package uses the varint package. Perhaps Lisp code generated from a protobuf definition is looking for length64? In that case, ideally the code would be regenerated, since I've made bug fixes recently to protobuf. How can I see what has broken? For the future is there an easy way for me to know what packages depend on protobuf?
Sorry for the breakage and thanks for the alert.
On Tue, Sep 22, 2020 at 3:43 PM Zach Beane < notifications@github.com> wrote:
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMNL2FGRA2QQFWDNRR3SHD46DANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696972059 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLISQ4UZLLAJCT5TJIDSHEEVDANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696978418>, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMEG6D32SZFW6UNGQLSHEGCJANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696984749 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLP44CEJMOC2LZR5RS3SHEHMLANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/brown/protobuf/issues/20#issuecomment-696990461 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAAGVMMFU47ZH7KTMVZKORDSHEIZNANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-698034142, or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AACPNLJLIF4I3POPS6VLKPTSHKEELANCNFSM4RWFO67Q
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-699096430, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAAGVMLVKCGSJ27IAOMF5TDSHTRI3ANCNFSM4RWFO67Q
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/20#issuecomment-699105470, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPNLMMLJNMCW557HTRI2TSHTTOTANCNFSM4RWFO67Q .
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Some projects have started to fail due to the error message in the issue title.
Is this a mistake in protobuf, or in the newly-failing projects?
What's the best way forward?