Section 4 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4

	in particular that I should do?

A#11.8:	Here's a checklist:

	- Any symbols which should not be available to the user should
	  have their private flag set.  In C, this corresponds to using
	  the "static" storage class specifier whenever possible.

	- Ensure your library is compatible with ORCA/C's large memory
	  model.

	- Write documentation, preferably one or more manual pages, for
	  any exported symbols.  If your library uses configuration files,
	  write manual pages for those too (they belong in chapter 5).

	- Specify in the manual pages any dependency on non-standard
	  libraries.  Specify dependencies for all header files, whether
	  standard or not.

	- Consider including your source code with your library.  This
	  allows your contribution to survive even if your hard drive
	  crashes, your backups are destroyed, or you leave the GNO
	  community.

Q#11.9:	How do I get the file descriptor from a stdio FILE pointer?

A#11.9:	Use the fileno() macro.

	This is defined in  as of GNO v2.0.6.  For earlier
	versions you will have to add it in yourself.  The proper
	macro definition for the ORCA/C headers is:

		#define fileno(p) ((p)->_file)

Q#11.10:	My (ported) source requires .  Why isn't it there?

A#11.10:	 has been superceded by .  Update your
	sources.

Q#11.11:	Why, when I '#include ' (or some other file), does the
	compiler take it out of my current directory instead of out of
	the system header directories?

A#11.11:	This is an unfortunate side-effect of using the ORCA/C "path"
	pragma to avoid duplication of system header files between your
	GNO and ORCA installations.  (See Q#5.1, Q#6.1, Q#6.4, and
	Q#6.5.)

	The reason for the problem is that when the file is included
	with the angle bracket syntax (vice double quotes), ORCA/C 
	will still search the current directory before those specified
	by the "path" pragma.

	At this time, the only known work-around is to avoid, in your
	own sources, using file names used by the system header files.

Q#11.12:	When using the December 1997 libraries (or later version), why are
	my programs larger than they used to be?

A#11.12:	There are a few reasons for this.

	The first one is that when the libraries (which are mostly written
	in C) are compiled, aggressive optimizations are not currently used.
	This is because certain optimizations in ORCA/C are known to be
	broken.  This, combined with the fact that we are missing a lot
	of automated test suites for the GNO (non-ORCA/C) additions to the
	libraries, indicated that it would be best to ship the libraries
	without much in the way of optimizations.

	The second reason is probably more significant.  When Jawaid provided
	a libc and ORCALib for GNO v2.0.4, he made significant changes to
	the stdio portion of ORCALib so that it would work with pipes and
	sockets.  Unfortunately, for whatever reason, the two versions of
	ORCALib (the original version from Byte Works, and the modified 
	version from Procyon) were never merged.  Therefore, when ORCALib
	was updated for ORCA/C v2.1.x, the GNO-specific changes were 
	effectively lost.

	When Devin took over maintenance of the GNO libraries in the spring
	of 1997, he was (in order to get a stdio package that worked with
	pipes) faced with the choice of either reimplementing Jawaid's
	changes to stdio, or to use another implementation of stdio that
	was written with pipes in mind.

	The tradeoff is one of development time versus code size (and probably
	speed).  The ORCA stdio implementation is in assembly, so it is
	small and fast.  On the other hand, GNO v2.0.6 had been in the
	"it's not ready yet" stage for quite a while.  The choice was made
	to use the 4.4BSD stdio implementation.  This is the primary reason
	why programs which use stdio are now larger than they were.

	If your program does not use stdio, but is still significantly 
	larger, then it may be due to dependancies in libc; there are
	some routines which currently depend on stdio but which need not.
	These dependancies will be removed as time is available to do so.

Kernel Internals
----------------

Q#12.1:	Can task-switching occur during an interrupt?

A#12.1:	No.

Q#12.2:	Can I tell GNO/ME to not task switch during a short (like a couple
	of ASM instructions) sequence?

A#12.2:	Turn off interrupts, or increment the busy flag around the code.

Debugging (During Program Development)
--------------------------------------

Q#13.1:	What debuggers are available for GNO?

A#13.1:	There are no GNO-specific debuggers, however there are at least two 
	popular ones that are compatible with GNO.

	If you are programming in C, it is highly recommended that you
	purchase "Splat!", written by Michael Hackett of Some Assembly
	Required.  This is also available from Procyon.  See also Q#13.2.

	If you are programming in assembly, it is recommended that you
	install GSBug.  This comes bundled with ORCA/M and is also available
	for download from the Apple Inc dts ftp site.  GSBug has many
	add-on packages used to increase its functionality.  Two of these
	are Niftylist and Nexus.

Q#13.2:	Why is the Splat! debugger crashing when my code calls fork(2)?

A#13.2:	Splat was not originally designed for GNO.  When GNO does a fork(2)
	or fork2(2) call, some very non-standard things are happening in
	the IIgs execution environment.  Splat cannot currently handle
	these operations.

	A request has been submitted to the author of Splat! for an upgrade
	to handle this behavior but he has not yet had time to do it; he
	is also busy working on other IIgs projects.

Q#13.3:	Part way through my debugging session, Splat! no longer shows my
	source file.  Why?

A#13.3:	Your program is probably changing its current working directory.

	The C preprocessor inserts tokens that tell the compiler which
	file (and on which line) it is currently processing.  This
	information is eventually passed to the debugger.  Some of the
	pathnames are, in general, relative to the directory from which
	your program was compiled.

	Splat! uses these relative pathnames to locate the source files
	that it is supposed to display.  Unfortunately, the current version
	of Splat! always searches for these files relative to the current
	directory, not relative to the directory that was current at the
	time which Splat! was invoked.  Therefore, if your program changes
	the current directory, the source files can no longer be found.

	This problem can be avoided by inserting following preprocessor
	directive at the top of all your source files:
		#line 1 "/fully/qualified/path/name.c"
	Of course, you should use the real path names to your source files,
	not the one shown above.  Do not use the __FILE__ macro as it
	will be expanded to only a partial pathname under some circumstances,
	such as when using occ(1).

	There is a utility which automates this process, including an
	option to remove the preprocessor directive.  See the splatprep(1)
	manual page for details.

General Problems
----------------

Q#14.1:	Some programs I run have two cursors and sometimes characters I
        type don't get sent to the program. When I quit the program, the
        characters show up on the command line! What's wrong?
 
A#14.1:	You need to set the auxiliary file type of the program in question
	to $DC00.  Use the chtyp command:

	        chtyp -a \$DC00 ProgramName

	Note the '\' character; it must be there to escape the '$' character
	from the shell, otherwise the $DC00 would be treated as a shell
	variable.

	Also note that this fix will not work if the program's file type
	is S16 and the file resides on an HFS volume.  (An EXE file on
	an HFS volume should be fine.)

Q#14.2:	Whenever I try to launch the Finder from GNO, I am told that the 
        Finder needs more memory. I know there is enough memory available.
        What's the deal?

A#14.2:	This was a bug in the GNO 1.0 kernel. Unfortunately, there is no
	workaround.  The only option is to upgrade to a current version
	of GNO.

Q#14.3:	My program is crashing when calling open(2).  Why?

A#14.3:	It may be due to a prototype/library mismatch.  The GNO implementation
	of open(2) is a variadic function.  The third "mode" parameter must
	be provided if and only if the second "oflag" parameter has the
	O_CREAT flag set.

	If calls to open result in a crash or stack error, you may have
	either the wrong definition of open in , or you are not
	getting open from 13/libc.  See also Q#9.2, Q#11.2, Q#11.3, and Q#6.6.

Q#14.4:	What are the known bugs?

A#14.4:	First off, this answer only refers to GNO-specific bugs.  You
	should also consult the ORCA/C bug list (see Q#9.2).

	As of mid-March 1998, there is an online bug tracking system
	for GNO.  You can get to it off of the GNO Documentation Page.
	Its direct URL is:

		http://www.gno.org/~gno/bugs.html

	If you know of specific problems with GNO that are not listed
	in the database, please enter them.  The web interface is the
	preferred method of submitting reports, but if that is not
	feasible you can also send bug reports to the following address:

		gno-bugs@trenco.gno.org

	If you do not have a web browser, you can view current reports
	by obtaining them through anonymous ftp at the following URL:

		ftp://ftp.gno.org/pub/gno-bugs

	You shouldn't archive these reports since they are continually
	being updated; view them and throw them away.

	*** The anon ftp directory has not yet been set up.
-- 
Tomorrow I will seven eagles see, a great comet will appear, and voices will
speak from whirlwinds foretelling monstrous and fearful things -- This 
Universe never did make sense; I suspect that it was built on government
contract.						- Robert Heinlein

Section 4 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4

© allanswers.org | Terms of use