Loading ...
Sorry, an error occurred while loading the content.
 

Re: Does viminfo store nested lists?

Expand Messages
  • Christian Brabandt
    ... Oh wow, simply sourcing that in my Windows gvim (7.4.0) crashes it. (don t have a Windows development system here to analyze it or even create a patch.
    Message 1 of 9 , Dec 10, 2013
      On Tue, December 10, 2013 13:24, Marc Weber wrote:
      > Have you tried cyclic linked lists/ dictionaries like these samples ?
      >
      > fun! CyclicDictionary(count)
      > let start = {}
      > let prev = start
      > for i in range(1, a:count)
      > let new_ = {'prev': prev}
      > endfor
      > let start.prev = new_
      >
      > return start
      > endf
      >
      >
      > fun! CyclicList(count)
      > let lists = map(range(0,a:count-1), '[]')
      >
      > for i in range(0, a:count-1)
      > call add(lists[i], lists[(i+1) % a:count])
      > call add(lists[i], lists[(i-1+a:count) % a:count])
      > endfor
      > return lists[0]
      > endf
      >
      > let dict = CyclicDictionary(100000)
      > let list = CyclicList(100000)
      >
      > if dict and list are both read back correctly neither size nor cycles
      > seem to be a problem ..

      Oh wow, simply sourcing that in my Windows gvim (7.4.0) crashes it.

      (don't have a Windows development system here to analyze it or even
      create a patch. Perhaps someone else can find the problem).

      Best,
      Christian

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Ben Fritz
      ... I can reproduce on a self-compiled 7.4.113 (HUGE features with dynamic python and perl). But it is strange. I source the script and everything seems fine.
      Message 2 of 9 , Dec 10, 2013
        On Tuesday, December 10, 2013 6:55:53 AM UTC-6, Christian Brabandt wrote:
        > On Tue, December 10, 2013 13:24, Marc Weber wrote:
        > > Have you tried cyclic linked lists/ dictionaries like these samples ?
        > >
        > > fun! CyclicDictionary(count)
        > > let start = {}
        > > let prev = start
        > > for i in range(1, a:count)
        > > let new_ = {'prev': prev}
        > > endfor
        > > let start.prev = new_
        > >
        > > return start
        > > endf
        > >
        > >
        > > fun! CyclicList(count)
        > > let lists = map(range(0,a:count-1), '[]')
        > >
        > > for i in range(0, a:count-1)
        > > call add(lists[i], lists[(i+1) % a:count])
        > > call add(lists[i], lists[(i-1+a:count) % a:count])
        > > endfor
        > > return lists[0]
        > > endf
        > >
        > > let dict = CyclicDictionary(100000)
        > > let list = CyclicList(100000)
        > >
        > > if dict and list are both read back correctly neither size nor cycles
        > > seem to be a problem ..
        >
        > Oh wow, simply sourcing that in my Windows gvim (7.4.0) crashes it.
        >

        I can reproduce on a self-compiled 7.4.113 (HUGE features with dynamic
        python and perl). But it is strange. I source the script and everything
        seems fine. I can enter and exit insert mode without problem. About 30
        seconds later, Vim crashes (when I'm not actually doing anything in
        Vim).

        This is gvim 32-bit running on 64-bit Windows 7.

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Nikolay Pavlov
        ... Does :call garbagecollect(1) trigger the crash? ... vim_dev group. ... email to vim_dev+unsubscribe@googlegroups.com. ... -- -- You received this message
        Message 3 of 9 , Dec 10, 2013


          On Dec 10, 2013 7:57 PM, "Ben Fritz" <fritzophrenic@...> wrote:
          >
          > On Tuesday, December 10, 2013 6:55:53 AM UTC-6, Christian Brabandt wrote:
          > > On Tue, December 10, 2013 13:24, Marc Weber wrote:
          > > > Have you tried cyclic linked lists/ dictionaries like these samples ?
          > > >
          > > > fun! CyclicDictionary(count)
          > > >   let start = {}
          > > >   let prev = start
          > > >   for i in range(1, a:count)
          > > >     let new_ = {'prev': prev}
          > > >   endfor
          > > >   let start.prev = new_
          > > >
          > > >   return start
          > > > endf
          > > >
          > > >
          > > > fun! CyclicList(count)
          > > >   let lists = map(range(0,a:count-1), '[]')
          > > >
          > > >   for i in range(0, a:count-1)
          > > >     call add(lists[i], lists[(i+1) % a:count])
          > > >     call add(lists[i], lists[(i-1+a:count) % a:count])
          > > >   endfor
          > > >   return lists[0]
          > > > endf
          > > >
          > > > let dict = CyclicDictionary(100000)
          > > > let list = CyclicList(100000)
          > > >
          > > > if dict and list are both read back correctly neither size nor cycles
          > > > seem to be a problem ..
          > >
          > > Oh wow, simply sourcing that in my Windows gvim (7.4.0) crashes it.
          > >
          >
          > I can reproduce on a self-compiled 7.4.113 (HUGE features with dynamic
          > python and perl). But it is strange. I source the script and everything
          > seems fine. I can enter and exit insert mode without problem. About 30
          > seconds later, Vim crashes (when I'm not actually doing anything in
          > Vim).

          Does :call garbagecollect(1) trigger the crash?

          >
          > This is gvim 32-bit running on 64-bit Windows 7.
          >
          > --
          > --
          > You received this message from the "vim_dev" maillist.
          > Do not top-post! Type your reply below the text you are replying to.
          > For more information, visit http://www.vim.org/maillist.php
          >
          > ---
          > You received this message because you are subscribed to the Google Groups "vim_dev" group.
          > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          > For more options, visit https://groups.google.com/groups/opt_out.

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
           
          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Ben Fritz
          ... Yes. Adding call garbagecollect() to the end of the script makes Vim crash immediately instead of after a long delay, when sourcing. -- -- You received
          Message 4 of 9 , Dec 10, 2013
            On Tuesday, December 10, 2013 11:22:53 AM UTC-6, ZyX wrote:
            > On Dec 10, 2013 7:57 PM, "Ben Fritz" <fritzo...@...> wrote:
            > >
            > > On Tuesday, December 10, 2013 6:55:53 AM UTC-6, Christian Brabandt wrote:
            > > > On Tue, December 10, 2013 13:24, Marc Weber wrote:
            > > > > Have you tried cyclic linked lists/ dictionaries like these samples ?
            > > > >
            > > > > fun! CyclicDictionary(count)
            > > > >   let start = {}
            > > > >   let prev = start
            > > > >   for i in range(1, a:count)
            > > > >     let new_ = {'prev': prev}
            > > > >   endfor
            > > > >   let start.prev = new_
            > > > >
            > > > >   return start
            > > > > endf
            > > > >
            > > > >
            > > > > fun! CyclicList(count)
            > > > >   let lists = map(range(0,a:count-1), '[]')
            > > > >
            > > > >   for i in range(0, a:count-1)
            > > > >     call add(lists[i], lists[(i+1) % a:count])
            > > > >     call add(lists[i], lists[(i-1+a:count) % a:count])
            > > > >   endfor
            > > > >   return lists[0]
            > > > > endf
            > > > >
            > > > > let dict = CyclicDictionary(100000)
            > > > > let list = CyclicList(100000)
            > > > >
            > > > > if dict and list are both read back correctly neither size nor cycles
            > > > > seem to be a problem ..
            > > >
            > > > Oh wow, simply sourcing that in my Windows gvim (7.4.0) crashes it.
            > > >
            > >
            > > I can reproduce on a self-compiled 7.4.113 (HUGE features with dynamic
            > > python and perl). But it is strange. I source the script and everything
            > > seems fine. I can enter and exit insert mode without problem. About 30
            > > seconds later, Vim crashes (when I'm not actually doing anything in
            > > Vim).
            >
            > Does :call garbagecollect(1) trigger the crash?

            Yes. Adding "call garbagecollect()" to the end of the script makes Vim crash
            immediately instead of after a long delay, when sourcing.

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • John Little
            My vim 7.4.113 on linux (Kubuntu 13.10) crashes too, no caught deadly signal , just Segmentation fault (core dumped) if run in a terminal. vim 7.4 from the
            Message 5 of 9 , Dec 10, 2013
              My vim 7.4.113 on linux (Kubuntu 13.10) crashes too, no 'caught deadly signal', just "Segmentation fault (core dumped)" if run in a terminal.

              vim 7.4 from the Kubuntu repository does not, even with :call garbagecollect()

              I'll make a debug build...

              Regards, John Little

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • John Little
              ... Here s the last 12 lines of the backtrace: #174623 0x0000000000461591 in set_ref_in_item (tv=0x3945220, copyID=2) at eval.c:6974 #174624 0x00000000004614d9
              Message 6 of 9 , Dec 10, 2013
                On Wednesday, December 11, 2013 11:37:55 AM UTC+13, John Little wrote:

                > I'll make a debug build...

                Here's the last 12 lines of the backtrace:

                #174623 0x0000000000461591 in set_ref_in_item (tv=0x3945220, copyID=2)
                at eval.c:6974
                #174624 0x00000000004614d9 in set_ref_in_list (l=0x2b89410, copyID=2)
                at eval.c:6942
                #174625 0x0000000000461591 in set_ref_in_item (tv=0x2b9f040, copyID=2)
                at eval.c:6974
                #174626 0x00000000004614d9 in set_ref_in_list (l=0x2b893b0, copyID=2)
                at eval.c:6942
                #174627 0x0000000000461591 in set_ref_in_item (tv=0x26adc00, copyID=2)
                at eval.c:6974
                #174628 0x000000000046149b in set_ref_in_ht (ht=0x8bb470 <globvardict+16>,
                copyID=2) at eval.c:6927
                #174629 0x000000000046126a in garbage_collect () at eval.c:6805
                #174630 0x00000000004cb51f in vgetc () at getchar.c:1562
                #174631 0x00000000004cbaf6 in safe_vgetc () at getchar.c:1795
                #174632 0x000000000051bb67 in normal_cmd (oap=0x7fff19a758c0, toplevel=1)
                at normal.c:666
                #174633 0x0000000000620b5c in main_loop (cmdwin=0, noexmode=0) at main.c:1329
                #174634 0x0000000000620468 in main (argc=1, argv=0x7fff19a75bc8) at main.c:1020

                Never had a backtrace 174,634 levels deep before.

                HTH, and regards, John Little

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Bram Moolenaar
                ... It appears to run out of stack space. Not strange when going 100000 levels deep. Yep, valgrind confirms: ==20355== Stack overflow in thread 1: can t grow
                Message 7 of 9 , Dec 11, 2013
                  John Little wrote:

                  > On Wednesday, December 11, 2013 11:37:55 AM UTC+13, John Little wrote:
                  >
                  > > I'll make a debug build...
                  >
                  > Here's the last 12 lines of the backtrace:
                  >
                  > #174623 0x0000000000461591 in set_ref_in_item (tv=0x3945220, copyID=2)
                  > at eval.c:6974
                  > #174624 0x00000000004614d9 in set_ref_in_list (l=0x2b89410, copyID=2)
                  > at eval.c:6942
                  > #174625 0x0000000000461591 in set_ref_in_item (tv=0x2b9f040, copyID=2)
                  > at eval.c:6974
                  > #174626 0x00000000004614d9 in set_ref_in_list (l=0x2b893b0, copyID=2)
                  > at eval.c:6942
                  > #174627 0x0000000000461591 in set_ref_in_item (tv=0x26adc00, copyID=2)
                  > at eval.c:6974
                  > #174628 0x000000000046149b in set_ref_in_ht (ht=0x8bb470 <globvardict+16>,
                  > copyID=2) at eval.c:6927
                  > #174629 0x000000000046126a in garbage_collect () at eval.c:6805
                  > #174630 0x00000000004cb51f in vgetc () at getchar.c:1562
                  > #174631 0x00000000004cbaf6 in safe_vgetc () at getchar.c:1795
                  > #174632 0x000000000051bb67 in normal_cmd (oap=0x7fff19a758c0, toplevel=1)
                  > at normal.c:666
                  > #174633 0x0000000000620b5c in main_loop (cmdwin=0, noexmode=0) at main.c:1329
                  > #174634 0x0000000000620468 in main (argc=1, argv=0x7fff19a75bc8) at main.c:1020
                  >
                  > Never had a backtrace 174,634 levels deep before.

                  It appears to run out of stack space. Not strange when going 100000
                  levels deep. Yep, valgrind confirms:

                  ==20355== Stack overflow in thread 1: can't grow stack to 0xbe387fec


                  The solution would be to make this iterative instead of recursive.
                  Not so easy to do.

                  --
                  The users that I support would double-click on a landmine to find out
                  what happens. -- A system administrator

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ an exciting new programming language -- http://www.Zimbu.org ///
                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Adrien Piérard
                  Well, I don t know what s currently recursive and problematic, but before making it iterative, one can try to make use of tail call optimisation (using GOTO
                  Message 8 of 9 , Dec 11, 2013
                    Well, I don't know what's currently recursive and problematic, but
                    before making it iterative, one can try to make use of tail call
                    optimisation (using GOTO for loops if need be), or trampolines so as
                    to keep a constant stack.

                    P!

                    On 11 December 2013 04:22, Bram Moolenaar <Bram@...> wrote:
                    >
                    > John Little wrote:
                    >
                    >> On Wednesday, December 11, 2013 11:37:55 AM UTC+13, John Little wrote:
                    >>
                    >> > I'll make a debug build...
                    >>
                    >> Here's the last 12 lines of the backtrace:
                    >>
                    >> #174623 0x0000000000461591 in set_ref_in_item (tv=0x3945220, copyID=2)
                    >> at eval.c:6974
                    >> #174624 0x00000000004614d9 in set_ref_in_list (l=0x2b89410, copyID=2)
                    >> at eval.c:6942
                    >> #174625 0x0000000000461591 in set_ref_in_item (tv=0x2b9f040, copyID=2)
                    >> at eval.c:6974
                    >> #174626 0x00000000004614d9 in set_ref_in_list (l=0x2b893b0, copyID=2)
                    >> at eval.c:6942
                    >> #174627 0x0000000000461591 in set_ref_in_item (tv=0x26adc00, copyID=2)
                    >> at eval.c:6974
                    >> #174628 0x000000000046149b in set_ref_in_ht (ht=0x8bb470 <globvardict+16>,
                    >> copyID=2) at eval.c:6927
                    >> #174629 0x000000000046126a in garbage_collect () at eval.c:6805
                    >> #174630 0x00000000004cb51f in vgetc () at getchar.c:1562
                    >> #174631 0x00000000004cbaf6 in safe_vgetc () at getchar.c:1795
                    >> #174632 0x000000000051bb67 in normal_cmd (oap=0x7fff19a758c0, toplevel=1)
                    >> at normal.c:666
                    >> #174633 0x0000000000620b5c in main_loop (cmdwin=0, noexmode=0) at main.c:1329
                    >> #174634 0x0000000000620468 in main (argc=1, argv=0x7fff19a75bc8) at main.c:1020
                    >>
                    >> Never had a backtrace 174,634 levels deep before.
                    >
                    > It appears to run out of stack space. Not strange when going 100000
                    > levels deep. Yep, valgrind confirms:
                    >
                    > ==20355== Stack overflow in thread 1: can't grow stack to 0xbe387fec
                    >
                    >
                    > The solution would be to make this iterative instead of recursive.
                    > Not so easy to do.
                    >
                    > --
                    > The users that I support would double-click on a landmine to find out
                    > what happens. -- A system administrator
                    >
                    > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                    > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                    > \\\ an exciting new programming language -- http://www.Zimbu.org ///
                    > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
                    >
                    > --
                    > --
                    > You received this message from the "vim_dev" maillist.
                    > Do not top-post! Type your reply below the text you are replying to.
                    > For more information, visit http://www.vim.org/maillist.php
                    >
                    > ---
                    > You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    > For more options, visit https://groups.google.com/groups/opt_out.



                    --
                    Français, English, 日本語, 한국어

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • John Little
                    ... Indeed. ... Indeed, I wasn t game to try. Be nice if it failed more gracefully, but other than imposing an arbitrary limit on the depth of a structure I
                    Message 9 of 9 , Dec 11, 2013
                      On Thursday, December 12, 2013 1:22:06 AM UTC+13, Bram Moolenaar wrote:
                      > It appears to run out of stack space. Not strange when going 100000
                      > levels deep.

                      Indeed.

                      >The solution would be to make this iterative instead of recursive.
                      >Not so easy to do.

                      Indeed, I wasn't game to try. Be nice if it failed more gracefully, but other than imposing an arbitrary limit on the depth of a structure I can't think how. Even that would not be simple.

                      Regards, John

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    Your message has been successfully submitted and would be delivered to recipients shortly.