BOOTSTRAP toolbox : 5-July-96
kroutines
libraries
scripts
conductor
ghostwriter
kcp
- Short Description:
- Request for kcp to copy *parts* of software objects
Work-Around :
Severity : 10a- enhancement request
Priority : 3 - Medium
Reported By : Danielle Argiro
Date : 24-Apr-96
HW : all
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- It would help in the software process if kcp could have
the capability to copy parts of software objects. For
example, you might do:
% kcp -oname cantata -otb design -ntb guiviz
-src -uis
This would give you source code, uis, and whatever else
was necessary, but not help pages or man pages
Similarly,
% kcp -oname cantata -otb design -ntb guiviz -help
would only give you the help pages of cantata. This
will help us when different people are working on
different parts of a software object. Specifically,
Mark working on code while Kelly is working on doc.
Notes :
Keywords :
kecho
kexec
kgendepend
kgenimake
kgenmake
- Short Description:
- script objects don't have a "Makefiles" target
Work-Around : Don't worry about it
Severity : 4b- Minor inconvenience
Priority : 3 - Medium
Reported By : Neil Bowers
Date : 30-Apr-96
HW : dec alpha (brandy)
OS : osf 3.0
Widget : athena
C : gcc
Fortran :
Perl :
X :
Win Mgr : ctwm
Display :
- Original Rpt:
-
The Makefile generated for script objects
doesn't have a "Makefiles" target.
For example, on brandy:
% make Makefiles
make: *** No rule to make target `Makefiles'. Stop.
Notes :
Keywords :
kgenmanual
kgenobj
kgenstruct
kgentb
kman
krename
krm
kset
phantomd
kclui
kcms
- Short Description:
- Inconsistent support for structures
Work-Around :
Severity : 10a - Enhancement request
Priority : 5 - None
Reported By : Jeremy Worley
Date : 18-Feb-96
HW : Sparc
OS : Solaris 2.4
Widget :
C : gcc
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Support for .x files in the imake system seems to not
be stable. The two things that I've noticed are:
- it would be cool if kgendepend would know to associate
#include "io_foo.h"
with foo.x and build the appropriate dependencies.
- associated with the second point, one should not have
to type 'make struct' to generate the structure
support code.
I assume this is all known. Just getting it out on the
table to be fixed before 2.1 goes out the door.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms
- Short Description:
- code generator error handling of missing tags is not
very nice.
Work-Around : Don't mess up the ghostwriter tags
Severity : 3a - Major inconvenience
Priority : 3 - Medium
Reported By : Jeremy Worley
Date : 18-Feb-96
HW : Sparc
OS : Solaris 2.4
Widget :
C : gcc
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Well, 'bug' is perhaps too strong a term...but a minor
change would make craftsman much more friendly in this
one circumstance (imho, not a bad thing in a commercial
quality product :^)
I did a little cut and paste in my favorite editor
and accidentally closed a -main_after_lib_call with a
-main_before_lib_call_end. When pushing the GenerateCode
button, it pops up the following message, and patiently
waits for me to accept this bad news:
Unable to find end key '^\s*/\* -main_after_lib_call_end \*/\s*$';
marking the ending of the text block for code to go after library call
to go into the main program. This part of the generated code
will be left empty.
I realized immediately what was wrong, but I could
do nothing about it... when I hit 'Ok', it went on
to generate the code, and deleted everything in the
main_after_lib_call section, which I had to reproduce
by hand.
If the message was changed to read:
Unable to find end key '^\s*/\* -main_after_lib_call_end \*/\s*$';
marking the ending of the text block for code to go after library call
to go into the main program.
If you choose to continue, this part of the generated code
will be left empty.
And then I am given the opportunity to bail out
('Continue' and 'Abort' are the two options), then I'd
be much happier.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms
- Short Description:
- copy object not updating -tb foo references to toolbox
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
If you have a command line which includes:
-tb foobar ...
the toolbox reference will not be updated when copying the
object to another toolbox.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms
- Short Description:
- renaming a pane object with executable doesn't result in all renames
Work-Around : change executables references by hand
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : George Ruban
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Anyway, when you change the name of the software object in
craftsman, the name of the executable is only changed some
places, not others. Specifically, the name of the executable
to be generated is changed, while the name of the executable
to be executed from the pane isn't.
It may be this only occurs when the executable name differs
from the object name.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms
- Short Description:
- problem copying/renaming an encapsulated workspace object
Work-Around : none
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Dave Modl
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
I am trying to copy and rename an encapsulated workspace
from one toolbox to another. The copy works fine, but I get
the following message from KCMS library routine when performing
the rename operation on this program object:
_kcms_fobj_set_basename:
676 if (file_object->ftype == KCMS_FOBJ_TYPE_DBM)
677 {
678 kerror(KCMS, routine,
679 "You are not allowed to rename the object database files!");
680 return FALSE;
681 }
When trying to rename the .wksp file. This file
should not be a DBM type, so I think there is some bug
in the classification of the wksp file type.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms
kcodegen
- Short Description:
- inconsistency between command-line usage and man(1) page
Work-Around : To get the labels and thier associated values onto the man
page forces the programmer to put a full description of thom
in with the Description field. While this does get the info
into the man page, it also causes that information to appear
twice on the command line -U information - once for the
stuff that kcodegen writes, and once for the stuff
explicitly added.
Severity : 4b- Minor inconvenience
Priority : 3 - Medium
Reported By : Scott Wilson swilson@khoral.com
Date : 29-Feb-96
HW : zen
OS : Solaris
Widget :
C :
Fortran :
Perl :
X :
Win Mgr : twm
Display :
- Original Rpt:
- There is an inconvenient behavior in the way kcodegen writes
up a kroutine.1 man page. This report documents the problem
using the cycle selection type, but others such as list, etc
will probably also show the same symptoms.
In the UIS file for a cycle, the cycle values/labels are
specified. The labels and thier associated values are
listed when you do a
% kroutine -U
but if you look at the man page, they are absent.
For an example of this, look at irotate for the padding
behavior cycle (-padding).
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcodegen
- Short Description:
- no warning if # subform buttons don't match # subforms
Work-Around :
Severity : 3a- Major inconvenience
Priority : 2 - High
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
If you comment out the -d (subform button) for a subform,
leaving the subform UIS intact, conductor runs without
any complaints, but doesn't generate the form structure(s)
for the subform. Conductor should give a warning that an
orphan subform was found.
- Notes :
- Originally recorded as a conductor bug
Keywords :
TB::oname : BOOTSTRAP::kcodegen
- Short Description:
- generated callbacks not added to comment at head of file
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
When you add new "live" selections or action buttons,
the "do" routines are generated in the appropriate file,
but the header is not updated to include the names of the
new routines.
- Notes :
- This is because, once created, the "do_*.c"
files are not touched - only appended to; this is to make
sure that no modifications made by the developer are
over-written. It would take some planning to think of
a scheme whereby conductor could recognise the header and
re-generate it, but not touch anything else that currently
exists in the file.
Originally recorded as a conductor bug
Keywords :
TB::oname : BOOTSTRAP::kcodegen
- Short Description:
- unnecessary code generated for multiple panes on single subform
Work-Around : Just don't worry about it; it doesn't interfere with
the operation of the xvroutine.
Severity : 10a- enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- xvroutine with multiple panes on single subforms, no
selections: conductor generates un-necessary code
xvroutine with multiple panes on single subforms, no
"live" selections: conductor generates un-necessary code
it would be nice if code generator was smart enough
to only generate necessary code
- Notes :
- Originally recorded as a conductor bug
Keywords :
TB::oname : BOOTSTRAP::kcodegen
- Short Description:
- overwrite prompting not usable when big differences between help and man pages
Work-Around : Always modify man page. Default action is to update
using manpage information.
Severity : 4d- Error message, warning, or prompting is unclear
Priority : 4 - Low
Reported By : Ashish Malhotra
Date : 26-Nov-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
For the case when the man and help pages of an object are
different, Ghostwriter prints out both the man and help pages
and prompts for a selection. If the man & help pages are long
and scroll out of the window, it is difficult to make out
whether a selection number refers to the man or the help page.
It'd be nice to print out the pages followed by a message
saying what each selection refers to.
Thanx, Ashish
- Notes :
- Originally recorded as a ghostwriter bug
Keywords :
TB::oname : BOOTSTRAP::kcodegen
- Short Description:
- overlong short descriptions cause problems in .pane file
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By : Mark Young
Date : 6-May-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
I'm having a problem with descriptions in my pane file that are
too long when printed out with a "dprog -U" command or a
missing/illegal argument.
For example:
[-d] data processing direction (0 = down vectors, 1 = across bands) (boolean) [true]
The solution is probably as simple as writing each line out to
a string first and doing a strlen() on it and formatting it by
inserting carraige reurns at the nearest whitespace before column 80.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcodegen
kexpr
kforms
- Short Description:
- Pane objects can't have arguments with default values
that differ from the kroutine that they get their
functionality from
Work-Around : Use same defaults as kroutine, or turn the pane object
into a script object or a kroutine that forks off the
other kroutine with the desired arguments.
Severity : 3a- Major inconvenience
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Pane objects can't have arguments with default values that
differ from the kroutine that they get their functionality
from. The differing default value is simply ignored,
and the default of the kroutine is what gets used.
- Notes :
- Fixing this is a *very* difficult problem; weigh benefit
of fix against instability of system that will be
introduced as a result of trying to fix the bug.
Keywords : CLUI, clui
TB::oname : BOOTSTRAP::kforms
- Short Description:
- UIS line parser doesn't give error message when there
are too many fields in a UIS line
Work-Around :
Severity : 4d- error message unclear (in this case, lacking)
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- UIS line parser doesn't give error message when there
are too many fields in a UIS line; the additional fields
are simply ignored. It would be nicer for the developer
if an error message was issued. This is not so much of
an issue now that guise is used so heavily.
Notes :
Keywords : CLUI, clui
TB::oname : BOOTSTRAP::kforms
- Short Description:
- It would be nice if the [-R] UIS line provided support
for execution of programs with varying (non-Khoros)
syntax
Work-Around :
Severity : 10a- enhancement request
Priority : 5 - None
Reported By : Danielle Argiro
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- It would be nice if the [-R] UIS line provided support
for execution of programs with varying (non-Khoros)
syntax. This would make K2 even better for use as a
software integration environment
Notes :
Keywords : CLUI, clui
TB::oname : BOOTSTRAP::kforms
klibdb
klibm
- Short Description:
- klibm.h has incorrect prototyping for C++ compilers on
srandom for linux (fix included in report)
Work-Around : Use fix below
Severity : 10a - Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
The definition of srandom in klibm.h conflicts with the
definition in /usr/include/stdlib.h
gcc in C++ mode flags this as an error.
Reproduce By:
-------------
Compile the following C++ file:
#include
extern "C" {
#include
};
Fix:
----
*** /usr/local/khoros/K2/bootstrap/include/klibm/klibm.h.org Sat Apr 8 23:52:28 1995
--- klibm.h Mon Feb 5 10:41:35 1996
***************
*** 1800,1806 ****
#else
# define ksrandom srandom
# if KOPSYS_LOCAL != KOPSYS_OSF
! void srandom PROTO((int));
# endif
#endif
--- 1800,1810 ----
#else
# define ksrandom srandom
# if KOPSYS_LOCAL != KOPSYS_OSF
! # if KOPSYS_LOCAL != KOPSYS_LINUX
! void srandom PROTO((int));
! # else
! void srandom PROTO((unsigned int));
! # endif
# endif
#endif
- Notes :
- The fix above is fine for short term, but this
problem needs to be addressed in general for C++
and that will take considerably more time than
the fix above.
Keywords :
TB::oname : BOOTSTRAP::klibm
ktestutils
kutils
- Short Description:
- Need a function to translate sh wild card syntax to
regular expression syntax.
Work-Around :
Severity : 10a - Enhancement request
Priority : 1 - Mandatory
Reported By : Steven Kubica
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- guiviz group would like a sh to regex wild card
translation routine so that wild cards can be
used by the browser.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils
- Short Description:
- Need a kftruncate function
Work-Around :
Severity : 10a - Enhancement request
Priority : 1 - Mandatory
Reported By : Steven Kubica
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- A ktrunc or ktruncate function which truncated an open
fid is needed to deal with read/write data objects or
programs which use the same file for -i and -o in the
new data services.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils
- Short Description:
- Exit status for remote processes are not correctly
returned after execution
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : Bob Stevens
Date : 31-Mar-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
kexecvp() seems to return (successfully) regardless of the
exit status of the process that it was supposed to execute,
when that process is remote (i.e., on a different machine).
Example (using kexec):
erendis 71% kexec -c spam
sh: spam: not found
erendis 72% echo $status
1
erendis 73% kexec -c spam@surak
erendis 74% echo $status
0
erendis 75% kexec -c date@surak
Wed Mar 31 14:32:50 MST 1993
erendis 76% echo $status
0
NOTE: erendis is the local machine, surak is the remote machine
NOTE: kexecvp() behaves the same way as kexec().
line 71: kexec() tries to execute a non-existant program
A shell error message appears.
line 72: the "status" shell variable is set (indicating
a non-successful exit).
line 73: kexec() tries to run the same process on a
remote machine (surak)
line 74: the exit status is (wrongly) zero (indicating
successful exit).
line 75: when kexec() tries to run a real program on
surak, it works, and
line 76: the exit status is correct (zero).
Hi,
Yes this is a bug. Unfortunately the status is not passed
back from the remote phantomd, which performs the actual
exec. So it simply assumes all is well. A command channel
should be between the phantomd's so that information of this
sort can be passed back and forth. This problem will
definitely be fixed for K2. Thanks for the bug report...
Bob Stevens, MEE-13, Los Alamos National Laboratory,
stevens@lanl.gov, 505-667-2623
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils
- Short Description:
- Our kscanf does not work on the Cray when doing a %p.
Work-Around : don't use %p
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : John Salas
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Our kscanf does not work on the Cray when doing a %p.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils
- Short Description:
- LARGE static buffer always created for regex routines,
whether they are used or not - need to be smarter about
this
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 2 - High
Reported By : Wolfram Gloger (wmglo@dent.med.uni-muenchen.de)
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
currently the regex routines has a large static buffer that is
always created whether the regex routines are called or not.
This needs to be changed so that it is smaller and that it is
malloc'ed at run time on the first call to kre_comp.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils
- Short Description:
- avoiding dependence on *any* environment variables
Work-Around : Require that users source the .khoros_env within
their login for remote command execution (ie.
no prompt defined).
Severity : 3a- Major inconvenience
Priority : 2 - High
Reported By : Mark Young
Date : 02-Apr-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Need to remove the dependence on the KHOROS_TOOLBOX
variable. This makes 2.0 distributed computing less
robust and susceptable to the same 1.0 setup failures.
Most of the infrastructure has been put in place to
do this. It's just a question of finializing the
mods so that if the KHOROS_TOOLBOX variable is not
set then we search the user's home directory for
their .Toolboxes file. Then kconfigure should be
changed to use an include syntax within this file
to reference system include toolboxes.
The problem is that other programs such as kgenmake,
kutils.pl, etc. will have to be modified to understand
this syntax. Last time we did this it took a day
of fixing to get things back online. So it's not
as simple as doing a kcp of kutils.
Also, this also means that toolbox addition will
have to be added not to just append the new toolbox
to the list. Cantata and aliases depend on the
order of toolboxes be user toolboxes followed by
system toolboxes.
- Notes :
- One thing that we have been trying to do is delete
any kind of environment dependence for running Khoros
related programs. This was mainly done for distributed
computing. The biggest single failure in the Khoros 1.0
distributed computing mechanism was the fact that
the user had to setup their environment so that
the Khoros binaries and environment variables were
properly set in their .cshrc. The problem seems
to occur that most people don't want to source have
an environment that it is difficult to enforce.
So for 2.1 if don't make this change we may take
a hit in distributed computing being robust enough
to be useable.
Keywords : KHOROS_TOOLBOX distributed computing
TB::oname : bootstrap::kutils
- Short Description:
- Directories created without warning.
Work-Around :
Severity : 3a- Major inconvenience
Priority : 2 - High
Reported By : Mark Young
Date : 02-Apr-96
HW : mohawk
OS : linux
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- If you open a file which has a leading path that
doesn't exist then the directories are created.
This was done as an ease of convience, but what
happens if you typo in the directory while saving
a workspace then this directory will be created.
It would be better to prompt the user that the
directory doesn't exist and ask if they want it
created. However, this will be a problem for the
existing infrastructure that relies on this feature.
- Notes :
- It seems important to fix this for the final release
as we can really piss off a lot of users. I have
the fix in my work toolbox, but and have added a
KOPEN_CREATEDIR flag that can be specified in order
to avoid the prompting.
Keywords : bogus directories
TB::oname : bootstrap::kutils
- Short Description:
- temporary files not being cleaned up in /var/tmp
Work-Around : use rm to remove them after running testsuites
or cantata.
Severity : 3a- Major inconvenience
Priority : 1 - Mandatory
Reported By : Mark Young
Date : 03-Apr-96
HW : SparcServer 1000
OS : Solaris 2.4
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Cantata, dataservices operators, and data
testsuites are still leaving temporary files
behind. Not sure why, but this really needs
to be fixed. Eventually cantata starts failing
because there is no more temporary space.
- Notes :
- Need to hack kutils after bronze to warn if you
ever exit a program without unlinking a temporary
file. At least this will allow us to track down
which programs under which conditions are leaving
these temporary files around.
Keywords : temporary files
TB::oname : bootstrap::kutils
kbugreport
kbuild
- Short Description:
- kbuild really won't work if it can't find design/lib
Work-Around : mkdir design; mkdir lib in Khoros toplevel
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By : Steve Kubica
Date : 19-Mar-96
HW : intel486
OS : Linux 1.0
Widget : Athena
C : gcc
Fortran :
Perl :
X : XFree86
Win Mgr : ctwm
Display :
- Original Rpt:
-
Can't do anything unless you have the base 3 toolboxes.
I took home just bootstrap and dataserv and tried to
build just bootstrap. It complained about not being able
to find design/lib to check dependencies, and failed to
compile bootstrap.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- kbuild wouldn't let me edit my config file
Work-Around : go edit them outside of kbuild
Severity : 4b- minor inconvenience
Priority : 1 - Mandatory
Reported By : Steve Kubica
Date : 19-Mar-96
HW : intel486
OS : Linux 1.0
Widget : Athena
C : gcc
Fortran :
Perl :
X : XFree86
Win Mgr : ctwm
Display :
- Original Rpt:
-
When prompted to see if I wanted to edit my config files, I
typed 'y' and it ignored me.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- kbuild assumes you are running a csh-like shell
Work-Around :
Severity : 3a - Major inconvenience
Priority : 1 - Mandatory
Reported By : Robert Forsman
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
The kbuild program assumes you are running a shell
derived from csh. I run bash which is derived from sh.
- Notes :
- This is actually a problem with kconfigure, but
it also may be fixed with the last rewrite. (SJ)
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- kbuild assumes the compiler will be in your PATH
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 1 - Mandatory
Reported By : Robert Forsman
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
The kbuild program assumes the C compiler will be in your
PATH. This is wrong. I specified a path beginning
with / and it choked.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- Installit should state version being installed
Work-Around : read the release notes? :-)
Severity : 4d- Error message, warning, or prompting, is unclear
Priority :
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
- Original Rpt:
- Installit just says "Khoros 2 Installation".
It needs to be clear exactly what version is
being installed.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- It'd be nice to say what in environment is checked
Work-Around : read the release notes? :-)
Severity : 5a- Aesthetics (typos, minor UI inconsistencies, etc)
Priority :
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
- Original Rpt:
- Near the start you get a message:
Checking your environment to make sure
it is set up correctly....
It'd be nice if you got something like:
Checking your environment ...
blah blah
blah blah
Looks good!
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- give pointer to definition of `supported' etc
Work-Around : read the installation guide
Severity : 5a- Aesthetics (typos, minor UI inconsistencies, etc)
Priority :
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
- Original Rpt:
- When giving the list of platforms there is
no mention of what supported, development,
and ported mean.
Maybe just a comment in parentheses like
(see Installation Guide for definitions
of `supported', 'development', etc)
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- no section heading for "toolbox selection" step
Work-Around :
Severity : 5a- Aesthetics (typos, minor UI inconsistencies, etc)
Priority :
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
- Original Rpt:
- When you're asked to select the toolboxes
to install, there is no heading, as there is
in all previous steps (or so it seemed).
Just something like:
Toolbox Selection
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- give useful default when selecting toolboxes
Work-Around : type the numbers yourself
Severity : 4b- Minor inconvenience
Priority : 2 - High
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
- Original Rpt:
- When prompting for which toolboxes to install,
the default is "None".
It would be helpful if the default was determined
by looking to see which toolboxes are in the
top directory, and using those as the default.
For example, I am just installing BOOTSTRAP,
DATASERV, DESIGN, and SUPPORT, so would get:
blah blah toolbox(es) [1 2 3 10]:
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- HasGcc stuff
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 2 - High
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
- Original Rpt:
- When selecting the C compiler, it mentioned
that you should set HasGcc and HasGcc2 to
YES if your compiler was cc, but is really gcc.
At that point you could let the user know that
there'll be a chance to edit the file later on.
When that time comes, remind them to check HasGcc.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- auto detection of /usr/X11R6 would be helpful
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 2 - High
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
- Original Rpt:
- kbuild could check for the existence of
/usr/X11R6 on PC unixes and set X11LibDir
and X11IncludeDir
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild
- Short Description:
- cc command not properly updated.
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 2 - High
Reported By : Wes Bethel wes@mh1.lbl.gov
Date : 29-Apr-96
HW : sparc lx
OS : solaris 2.4, older sparcworks, not sure which version
Widget : motif
C : acc
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Reproduce By:
i have an older version of sparcworks on one of my machines.
it's soooo old, i have to specify "acc" rather than cc.
in the appropriate config file, the CcCmd variable remains
set at cc.
Notes :
Keywords :
TB::oname : kbuild
Severity : 10a- Enhancement request
Priority : 2 - High
Reported By : Roberto A. Lotufo lotufo@dca.fee.unicamp.br
Date : 22-Apr-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- we do not use lex/yacc here as there were updated a long timeago for bison/flex
It would be good if you could support those.
below are the result of my compulation using bison/flex and
the changes I did in the Makefile
Notes :
Keywords :
TB::oname :
kconfigure
- Short Description:
- kconfigure says it found binaries, but it didn't!
Work-Around :
Severity : 4d- Error message, warning, or prompting, is unclear
Priority : 2 - High
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
- Original Rpt:
-
When kconfigure is run for you after running
kbuild, it says:
bootstrap binaries located in [...]
dataserv binaries located in [...]
design binaries located in [...]
ok so far . . .
datamanip binaries located in [...]
[similar for all standard toolboxes
I know this is checking where they would be
installed, but I haven't even installed
DATAMANIP et al, so this is a little misleading
perhaps.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kconfigure
kgenglossary
kgenindex
klicense
kversion