*better pulling of submodules (TODO: add wiringpi as a submodule) · pd-l2ork/pd@105f71e

agraef · 2016-06-14T04:15:15Z

I don't think that this is a good idea. Just blindly updating to the latest upstream source is hazardous. It makes builds irreproducible and puts you at the mercy of upstream. You can always run git submodule foreach git pull origin master manually beforehand if you really want to build against the latest upstream sources, but the default mode should remain git submodule update --init.

pd-l2ork · 2016-06-14T05:11:34Z

If I don't do this I don't get the latest updates. That said, I'm not entirely clear on what the heck is the difference between the two because the submodule update fails to pull latest additions from the submodules. ## Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 [email protected] www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net

…

On Jun 14, 2016 00:15, "Albert Graef" ***@***.*** wrote: I don't think that this is a good idea. Just blindly updating to the latest upstream source is hazardous. It makes builds irreproducible and puts you at the mercy of upstream. You can always run git submodule foreach git pull origin master manually beforehand if you really want to build against the latest upstream sources, but the default mode should remain git submodule update --init. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub 105f71e#commitcomment-17854824, or mute the thread https://github.com/notifications/unsubscribe/ABBE1QDCSn1GZZ7idqz0gZc5FYRh-A1Rks5qLirTgaJpZM4I08lZ .

agraef · 2016-06-14T05:15:58Z

Case in point: the latest build of pd-l2ork on Manjaro segfaults now. So one of the latest externals doesn't work there.

pd-l2ork · 2016-06-14T05:18:48Z

Can you check which?

…

On Tue, Jun 14, 2016 at 1:15 AM, Albert Graef ***@***.*** wrote: Case in point: the latest build of pd-l2ork on Manjaro segfaults now. So one of the latest externals doesn't work there. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub 105f71e#commitcomment-17855086, or mute the thread https://github.com/notifications/unsubscribe/ABBE1eqSc0WKpEdzRlpm1Ey5NI5wyvEAks5qLjkPgaJpZM4I08lZ .

agraef · 2016-06-14T05:30:01Z

That's not how git submodules work. The idea of git submodules is that you get a well-defined snapshot of each submodule. That snapshot stays the same until you update the submodule. You do this by pulling upstream every once in a while in the submodule directory, and then, if you want, commit the submodule changes in the main repository. Of course you ideally do this only after you tested it and know it works. ;-)

I consider this the only way to work with submodules and stay sane. Blindly following upstream is a sure recipe for disaster. If you absolutely must have the auto-pulling thing, please make it an option. Really.

See https://git-scm.com/book/en/v2/Git-Tools-Submodules for a more detailed explanation of how git submodules work.

agraef · 2016-06-14T05:30:52Z

Can you check which?

Not right now, I just did a quick build to test the waters. Need to get some sleep first. I suspect that it's something with Gem, because it was segfaulting right on startup last time I tried the latest HEAD from it.

agraef · 2016-06-14T05:49:18Z

Yep, it's Gem. At least that's what gdb says:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid

Thread 1 "pd-l2ork" received signal SIGABRT, Aborted.
0x00007ffff63d6295 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff63d6295 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff63d76da in abort () from /usr/lib/libc.so.6
#2  0x00007ffff60ad3dd in __gnu_cxx::__verbose_terminate_handler ()
    at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00007ffff60ab196 in __cxxabiv1::__terminate (handler=<optimized out>)
    at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x00007ffff60ab1e1 in std::terminate ()
    at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x00007ffff60ab3f8 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x3051ff0, 
    tinfo=0x7ffff6395a38 <typeinfo for std::logic_error>, 
    dest=0x7ffff60c0410 <std::logic_error::~logic_error()>)
    at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:87
#6  0x00007ffff60d43ff in std::__throw_logic_error (
    __s=0x7ffff5934c20 "basic_string::_M_construct null not valid")
    at /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/functexcept.cc:74
#7  0x00007ffff58a91bc in ?? () from /usr/lib/pd-l2ork/extra/Gem/Gem.pd_linux
#8  0x00007ffff56e5957 in ?? () from /usr/lib/pd-l2ork/extra/Gem/Gem.pd_linux
#9  0x00000000004abca8 in sys_load_lib ()
#10 0x0000000000498a49 in new_anything ()
#11 0x00000000004986ba in pd_typedmess ()
#12 0x00000000004a137f in binbuf_eval ()
#13 0x000000000043d951 in ?? ()
#14 0x000000000043f6dd in canvas_obj ()
#15 0x0000000000498858 in pd_typedmess ()
#16 0x00000000004a1486 in binbuf_eval ()
#17 0x00000000004a2274 in binbuf_evalfile ()
#18 0x00000000004a2325 in glob_evalfile ()
#19 0x0000000000498984 in pd_typedmess ()
#20 0x00000000004a1486 in binbuf_eval ()
#21 0x00000000004a815c in socketreceiver_read ()
#22 0x00000000004a749b in ?? ()
#23 0x00000000004a45e6 in m_mainloop ()
#24 0x00000000004a6eb8 in sys_main ()
#25 0x00007ffff63c3741 in __libc_start_main () from /usr/lib/libc.so.6
#26 0x0000000000417559 in _start ()

pd-l2ork · 2016-06-14T07:01:30Z

OK, please try the latest version and report any potential problems.

…

On Tue, Jun 14, 2016 at 1:49 AM, Albert Graef ***@***.*** wrote: Yep, it's Gem. At least that's what gdb says: terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_M_construct null not valid Thread 1 "pd-l2ork" received signal SIGABRT, Aborted. 0x00007ffff63d6295 in raise () from /usr/lib/libc.so.6 (gdb) bt # 0 0x00007ffff63d6295 in raise () from /usr/lib/libc.so.6 # 1 0x00007ffff63d76da in abort () from /usr/lib/libc.so.6 # 2 0x00007ffff60ad3dd in __gnu_cxx::__verbose_terminate_handler () ``` at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95 ``` # 3 0x00007ffff60ab196 in __cxxabiv1::__terminate (handler=<optimized out>) ``` at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47 ``` # 4 0x00007ffff60ab1e1 in std::terminate () ``` at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57 ``` # 5 0x00007ffff60ab3f8 in __cxxabiv1::__cxa_throw ***@***.***=0x3051ff0, ``` tinfo=0x7ffff6395a38 <typeinfo for std::logic_error>, dest=0x7ffff60c0410 <std::logic_error::~logic_error()>) at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:87 ``` # 6 0x00007ffff60d43ff in std::__throw_logic_error ( ``` __s=0x7ffff5934c20 "basic_string::_M_construct null not valid") at /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/functexcept.cc:74 ``` # 7 0x00007ffff58a91bc in ?? () from /usr/lib/pd-l2ork/extra/Gem/Gem.pd_linux # 8 0x00007ffff56e5957 in ?? () from /usr/lib/pd-l2ork/extra/Gem/Gem.pd_linux # 9 0x00000000004abca8 in sys_load_lib () # 10 0x0000000000498a49 in new_anything () # 11 0x00000000004986ba in pd_typedmess () # 12 0x00000000004a137f in binbuf_eval () # 13 0x000000000043d951 in ?? () # 14 0x000000000043f6dd in canvas_obj () # 15 0x0000000000498858 in pd_typedmess () # 16 0x00000000004a1486 in binbuf_eval () # 17 0x00000000004a2274 in binbuf_evalfile () # 18 0x00000000004a2325 in glob_evalfile () # 19 0x0000000000498984 in pd_typedmess () # 20 0x00000000004a1486 in binbuf_eval () # 21 0x00000000004a815c in socketreceiver_read () # 22 0x00000000004a749b in ?? () # 23 0x00000000004a45e6 in m_mainloop () # 24 0x00000000004a6eb8 in sys_main () # 25 0x00007ffff63c3741 in __libc_start_main () from /usr/lib/libc.so.6 # 26 0x0000000000417559 in _start () — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub 105f71e#commitcomment-17855241, or mute the thread https://github.com/notifications/unsubscribe/ABBE1aAfhOoF719kI-ji2dSBNsAYSCe_ks5qLkDegaJpZM4I08lZ .

agraef · 2016-06-14T10:15:32Z

There's something wrong with your wiringPi submodule. Are you sure that you created this with git submodule add? There's no l2ork_addons/raspberry_pi/disis_gpio/wiringPi directory in the repository, and the .gitmodules file looks broken, too. There's a spurious line with a lone 'z' on it before the wiringPi submodule. This all looks like the git submodule add went horribly wrong. Consequently, the submodule isn't created either when cloning or updating.

agraef · 2016-06-14T10:45:21Z

Looks like the file got messed up in rev. ec05a90 already. Ok, let me see whether I can get that fixed on my branch and send you a pull request.

Done: Please pull #37

agraef · 2016-06-14T12:11:53Z

Ok, after fixing up the submodule issue pd-l2ork compiles fine again, and the Manjaro build seems to work, no more segfaults any more.

I guess that the main difference is that now Gem is still the old snapshot, while all the other submodules are the latest upstream revision, right?

So then I'll have to figure out where exactly the latest Gem breaks on Manjaro. Will do asap, but I have to teach during the week and this is probably going to take time. Stay tuned.

-Original file line number
+Diff line change
@@ Expand Up / @@ -137,6 +137,7 @@ then @@
     			# init all submodules (only necessary the first time)
     			git submodule init
     			git submodule update
+    			git submodule foreach git pull origin master
     		fi
     	fi
@@ Expand Down @@

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Commit

There are no files selected for viewing

11 comments on commit `105f71e`

agraef commented on `105f71e` Jun 14, 2016

pd-l2ork commented on `105f71e` Jun 14, 2016 via email

agraef commented on `105f71e` Jun 14, 2016

pd-l2ork commented on `105f71e` Jun 14, 2016 via email

agraef commented on `105f71e` Jun 14, 2016

agraef commented on `105f71e` Jun 14, 2016 •

edited

Loading

agraef commented on `105f71e` Jun 14, 2016

pd-l2ork commented on `105f71e` Jun 14, 2016 via email

agraef commented on `105f71e` Jun 14, 2016

agraef commented on `105f71e` Jun 14, 2016 •

edited

Loading

agraef commented on `105f71e` Jun 14, 2016

Commit

There are no files selected for viewing

11 comments on commit 105f71e

agraef commented on 105f71e Jun 14, 2016

Choose a reason for hiding this comment

pd-l2ork commented on 105f71e Jun 14, 2016 via email

Choose a reason for hiding this comment

agraef commented on 105f71e Jun 14, 2016

Choose a reason for hiding this comment

pd-l2ork commented on 105f71e Jun 14, 2016 via email

Choose a reason for hiding this comment

agraef commented on 105f71e Jun 14, 2016

Choose a reason for hiding this comment

agraef commented on 105f71e Jun 14, 2016 • edited Loading

Choose a reason for hiding this comment

agraef commented on 105f71e Jun 14, 2016

Choose a reason for hiding this comment

pd-l2ork commented on 105f71e Jun 14, 2016 via email

Choose a reason for hiding this comment

agraef commented on 105f71e Jun 14, 2016

Choose a reason for hiding this comment

agraef commented on 105f71e Jun 14, 2016 • edited Loading

Choose a reason for hiding this comment

agraef commented on 105f71e Jun 14, 2016

Choose a reason for hiding this comment

11 comments on commit `105f71e`

agraef commented on `105f71e` Jun 14, 2016

pd-l2ork commented on `105f71e` Jun 14, 2016 via email

agraef commented on `105f71e` Jun 14, 2016

pd-l2ork commented on `105f71e` Jun 14, 2016 via email

agraef commented on `105f71e` Jun 14, 2016

agraef commented on `105f71e` Jun 14, 2016 •

edited

Loading

agraef commented on `105f71e` Jun 14, 2016

pd-l2ork commented on `105f71e` Jun 14, 2016 via email

agraef commented on `105f71e` Jun 14, 2016

agraef commented on `105f71e` Jun 14, 2016 •

edited

Loading

agraef commented on `105f71e` Jun 14, 2016