Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

question about src/mged/cmd.c

Developers
jim_monte
2006-05-12
2013-04-22
  • jim_monte
    jim_monte
    2006-05-12

    Hi,

    About 1/3 of the way down this file are the
    following lines:

        bu_vls_strcpy(&temp, "glob_compat_mode");
        Tcl_LinkVar(interp, bu_vls_addr(&temp), (char *)&glob_compat_mode,
                TCL_LINK_BOOLEAN);
        bu_vls_strcpy(&temp, "output_as_return");
        Tcl_LinkVar(interp, bu_vls_addr(&temp), (char *)&output_as_return,
                TCL_LINK_BOOLEAN);

    The bu_vls_strcpy() seems to be useless since
    Tcl_LinkVar() has a const char * for the argument.
    But it also seems like someone made a special
    effor to avoid something much more direct
    like

        Tcl_LinkVar(interp, "glob_compat_mode",(char *)&glob_compat_mode,
                TCL_LINK_BOOLEAN);
        Tcl_LinkVar(interp, "output_as_return", (char *)&output_as_return,
                TCL_LINK_BOOLEAN);

    Does anyone know of the reasoning behind this
    code?  Thanks for any info.

    Jim Monte

     
    • jim_monte
      jim_monte
      2006-05-12

      This is also done several times in
      mged_global_variable_setup() at about the middle
      of the file.  In that case, it results in a
      memory leak since the string is not freed.

      Jim

       
      • Sean Morrison
        Sean Morrison
        2006-05-15

        Ugh, I have no idea why that function was written that way.  Even better catch than the other given that one does indeed leak memory.  Fixed in CVS.  Thanks again, Jim..

        Cheers!
        Sean

         
        • jim_monte
          jim_monte
          2006-05-15

          Sean,

          Great.  I have made literally many hundreds of
          changes to get the windows version to compile
          cleanly and run from what was I downloaded as
          the zip file of 7.8.0 source code.  Many of these
          relate to the const char **argv used in TCL,
          but a few were more serious problems or
          enhancements such as improved timing facilities.
          If there is interest incorporating these into
          CVS, let me know how they should be submitted.
          I have tried to conform with format conventions.
          Conveniently, they are almost all my preferences
          anyhow, with the exception of the tabs.  I
          normally would expand them to spaces to prevent
          various editors from displaying the code too
          differently.  It is a little more disk space,
          but a lot less frustration.  The strings of
          blanks compress well for archiving too.

          Jim

           
          • Sean Morrison
            Sean Morrison
            2006-05-16

            Jim,

            That sounds excellent, astoundingly so.  There is definitely interest to get your changes incorporated into CVS.  The HACKING file in the source distribution talks about how to best go about providing contributions in considerable detail.  The short summary for this situation, though, is to basically create a unified diff patch based off of an unmodified 7.8.0 and to provide that patch to the BRL-CAD patches tracker at http://sourceforge.net/tracker/?group_id=105292&atid=640804

            You could also post a URL or e-mail it, but the patches tracker allows for some contained discussion if there's any problems.  If creating a unified diff isn't evidently easy (I've never done that myself on Windows), even a tarball of the modified files will work but just makes it more difficult to merge.
             
            As for the format conventions, I'm generally more concerned with having per-file consistency since that is generally where problems can aries due to formatting inconsistencies or misinterpretations.  That said, there is a formatting convention defined (also outlined in the  HACKING file), as well as a vi/emacs variables block at the end of every file to encourage consistency.

            We do have an automation process to ensure that all the source files are consistently formatted, but it has not been run on all the sources yet.  Mainly not run yet so as to ease the burden of merging the extensive Windows branch modifications that Bob worked on, to minimize CVS conflicts.  Now that the branch is merged, I'll be running the scripts sometime here in the near future.

            Speaking of that file.. the HACKING file also speaks about how to become even more directly involved in the project if you're interested.  In particular, several folks interested in the project hang out on the BRL-CAD IRC channel on the Freenode network.   Thanks again for your efforts..

            Cheers!
            Sean

             
            • jim_monte
              jim_monte
              2006-05-17

              Sean,

              Thanks for the reply.  At this time I wanted
              to know more whether there was interest in
              the contributions than the specifics of how
              to submit them.  I had seen the HACKING file,
              but sometimes the information in a file is
              outdated.  Compared to other discussion lists
              I have seen, these had been rather inactive.
              I have access to Unix systems, so using diff
              should not be any problem.  I will look into
              the details when it seems to be a good time to
              submit the changes.  Before that, I would want
              to compile and run everything on at least one
              other OS to make sure that I did not break
              anything elsewhere.  I have had a lot of
              experience with common source code between
              Windows and a few Unix platforms, so this should
              not be much of a problem.

              I had discovered BRL-CAD just before 7.8.0 was
              released, so I am still new to the whole package.
              One reason why I obtained the source code was
              to use it as documentation, since I still have
              only found some basic tutorials that barely
              touch on all of the available features.  When it
              would not build for me, well, one thing lead to
              another.  Unfortunately, while source code is
              the almost definitive documentation (object code
              is), reading it is not usually the fastest way
              to learn about something.  So it still will be
              a while before I can do that much in the way of
              significant contributions.

              Looking forward a bit, I am curious how attached
              the developers are to keeping Tk in the Windows
              version of mged.  I like the Tcl interpreter
              because Window's cmd.exe is not known for its
              scripting abilities.  Hopefully I am not ruffling
              any feathers (couldn't resist), but Tk looks
              ugly compared to native Windows graphics, and
              the startup is painfully slow.  A lower-level
              graphics interface using Tcl behind the scenes
              to offer a command-line control interface
              would probably resolve these problems without
              giving up the scripting capabilities while
              performing substantially better.  Again I am not
              looking to start OS wars, but graphics on Windows
              look and perform a lot better than on the Unix
              systems I used, so it would seem that for
              programs that present visual content, this should
              be used to advantage.  If graphics did not matter,
              I still would be extolling the virtues of MVS.

              Jim

               
              • Sean Morrison
                Sean Morrison
                2006-05-17

                Jim,

                Not a problem, I completely understand and appreciate your motivations/hesitations.  Using the source as the documentation has been a long-standing BRL-CAD mantra for some.. :)  Fortunately, the HACKING file is one of the documents that is pretty much completely up to date as developer interest is actually needed most right now.

                There's enough ideas and work to keep a massive team busy for decades so the battles have to be chosen carefully as we're not to that point (yet..).  Sometimes discussion on the forums/trackers/mailing lists suffer as a result as was the case here; IRC is generally preferred for its efficiency.  The Windows release and moreover the preparations that preceded it caused a massive backlog that is only starting to get chipped away at now (hence all the sudden replies).

                As for the "Tk looks ugly", I personally agree :-) .. though it's not 'quite' a fair statement to make unequivocally.  You can make Tk look a lot better than MGED lets on -- Archer is an example of this -- it just takes a lot more effort than anyone was willing to put into MGED.  The decision to go with Tk for MGED's interface goes back more than a decade now and also related to choosing battles carefully at a time where Tk actually looked like the fastest way to improve MGED's appearance (over the custom classic interface that MGED still provides using the -c option).

                I'm not highly opposed to using platform-specific interfaces where there is a clear and maintainable benefit.  There are however several concerns that would have to be considered and accounted for.  Making those modifications in a maintainable manner -- long after the developer that wrote them is no longer involved -- can be rather complicated.  Ideally, there would be a library/layer/interface where Tk is one of several available implementations; Cocoa could be another, and something Windows-specific yet another, etc.  Assuming there was sufficiently motivated and involved developers to sustain that design, the interface used by MGED would simply be the library, not a string of spagetti #ifdef sections throughout the code.  When you start going that route, it also begs consideration of projects that already attempt to do just that too, each with their good and bad points.  MGED's old design and concept of run-time selectable display managers would be such a library as well, though it never involved complex graphical user interface elements -- that was ultimately delegated to Tk, which brings us to today.

                Making sure the package on the whole still behaves the same across platforms is of paramount importance for consistency.  We don't even have that yet as the unix design philosophy of BRL-CAD's plethora of smaller commands don't translate well to the Windows environment with the default command shell.  This is another deficiency I'd like to work on fixing, through the provision of a BRL-CAD terminal i.e. a command shell, that would function identically cross-platforms so that even if you were on Windows and you wanted to run pix-png and pipe the output to png-fb using posix semantics, you could.

                I've been working on a new geometry interface as an eventual long-term replacement for BRL-CAD's geometric modeling needs (or better put, a massive evolution of them) that attempts to address all of these problems.  It's something that I'd like to bring to reality solely through open source involvement (i.e. sans our supporters that hold a financial interest) so I suspect it will be slow going until the prototype is functional.  It is, however, a design that leverages the existing massive code investment, is flexible enough to absorb a variety of concepts and needs, and should scale spectacularly to a full production system as it matures.  Yes, lots of hand-waving at this point -- more details on those plans and progress already made later.  This message is long enough already.. ;-)

                Cheers!
                Sean

                 
    • jim_monte
      jim_monte
      2006-05-15

      I changed these with no APPARENT ill effects...

       
    • Sean Morrison
      Sean Morrison
      2006-05-15

      Jim,

      I don't think there was any particular reasoning behind why it was done that way other than that it matched the preceeding code where the vls was needed to append a value after the command name.  Probably just an oversight from a long time ago.  Your fix is good stuff -- I've applied it to CVS, thanks!

      Cheers!
      Sean