About 1/3 of the way down this file are the
Tcl_LinkVar(interp, bu_vls_addr(&temp), (char *)&glob_compat_mode,
Tcl_LinkVar(interp, bu_vls_addr(&temp), (char *)&output_as_return,
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
Tcl_LinkVar(interp, "glob_compat_mode",(char *)&glob_compat_mode,
Tcl_LinkVar(interp, "output_as_return", (char *)&output_as_return,
Does anyone know of the reasoning behind this
code? Thanks for any info.
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.
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..
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.
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..
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
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.
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.. ;-)
I changed these with no APPARENT ill effects...
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!