🚀 go-pugleaf

    Soenke, I tried out your new 'cc' on the agrep (approximate grep) source
files I downloaded from comp.sources.unix.  Just as an exercise, I unpacked
all the files and then did 'cc -O -v *.c'.  To my surprise, all the source
files (about a dozen of them) compiled without a single error under GNO/
ORCA 1.2, but that's it.  Nothing was linked so I didn't get an 'agrep'
executable.  I tried 'cc *.o' afterwards (which started to link them),
but it gave an error about a code segment being larger than a bank.  It
gave me a 1.2-meg (!) binary anyway.  I can run it, but nothing happens 
(doesn't crash the machine either).  I should also point out the resulting
binary is very sparse (only takes up about 80K or so of disk space).

    Is there some flag I should be setting?  Or maybe just get a newer version
of ORCA?  :)
-- 
-- Real name: Brian Tao (Dept. of Exobiology, University of Toronto)
-- Preferred: 90taobri@chasm.scar.utoronto.ca (checked daily)
-- Alternate: taob@r-node.pci.on.ca (no mail over 15K, please!)
--                                   """""""""""""""""""""""""

taob@r-node.gts.org (Brian Tao) writes:

>    Soenke, I tried out your new 'cc' on the agrep (approximate grep) source
>files I downloaded from comp.sources.unix.  Just as an exercise, I unpacked
>all the files and then did 'cc -O -v *.c'.  To my surprise, all the source
>files (about a dozen of them) compiled without a single error under GNO/
>ORCA 1.2, but that's it.  Nothing was linked so I didn't get an 'agrep'
>executable.  I tried 'cc *.o' afterwards (which started to link them),
>but it gave an error about a code segment being larger than a bank.  It
>gave me a 1.2-meg (!) binary anyway.  I can run it, but nothing happens 
>(doesn't crash the machine either).  I should also point out the resulting
>binary is very sparse (only takes up about 80K or so of disk space).

  It sounds like there is a very large global array (hash table?) in
the agrep source- that's what usually creates sparse executables.
In that case, you'll need to use ORCA's large memory model.

>    Is there some flag I should be setting?  Or maybe just get a newer version
>of ORCA?  :)

  Well, you definitely should get ORCA/C 2.0 when it comes out; C 1.2
had some nasty problems.

-- 
 Jawaid Bazyar              |   Ask me about the GNO Multitasking Environment
 Procyon, Inc.              |   for the Apple IIgs!   
 bazyar@cs.uiuc.edu         |   P.O Box 620334
 --Apple II Forever!--      |   Littleton, CO 80162-0334   (303) 933-4649

In article <1992Dec21.160930.1472@r-node.gts.org> taob@r-node.gts.org
(Brian Tao) writes:

>    Soenke, I tried out your new 'cc' on the agrep (approximate grep) source
>files I downloaded from comp.sources.unix.  Just as an exercise, I unpacked
>all the files and then did 'cc -O -v *.c'.  To my surprise, all the source
>files (about a dozen of them) compiled without a single error under GNO/
>ORCA 1.2, but that's it.  Nothing was linked so I didn't get an 'agrep'
>executable.  I tried 'cc *.o' afterwards (which started to link them),
>but it gave an error about a code segment being larger than a bank.  It
>gave me a 1.2-meg (!) binary anyway.  I can run it, but nothing happens 
>(doesn't crash the machine either).  I should also point out the resulting
>binary is very sparse (only takes up about 80K or so of disk space).
>
>    Is there some flag I should be setting?  Or maybe just get a newer version
>of ORCA?  :)

Brian, your problem actually has nothing to do with cc, it's the fault of
Orca/C.  With the current (1.2/1.3) Orca/C, if code size will exceed one
bank (64k) you have to segment the code into managable chunks yourself.
This means inserting a 'segment "BLAH      ";' (always good to pad
the segments to a full 10 chars, makes 'em look more readable on a dump)
at the beginning of the source file.  The code in that source file will
now be placed in a seperate load segment.

You also seem to have anther problem, which is a LOT of static space
allocated by agrep.  If you have a 1.2mb binary of which 1.1mb or so
is empty, that means you have a LOT of static space being allocated.
What that means is you need to use the large memory model (#pragma 
memorymodel 1) so you can have arrays and such that are greater than 64k.

Hope this helps.

>-- Real name: Brian Tao (Dept. of Exobiology, University of Toronto)
>-- Preferred: 90taobri@chasm.scar.utoronto.ca (checked daily)

As soon as I finish dmake, porting stuff should be quite a bit easier,
what with dmake and cc ... 
-- 
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
|          James Brookes            | Inet: bb252@cleveland.freenet.edu |
|``What, me worry?'' - A. E. Neuman |   jamesb@cscihp.ecst.csuchico.edu |
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

In article <1h5c80INN9ba@charnel.ecst.csuchico.edu> jamesb@ecst.csuchico.edu (James L. Brookes) writes:
>
>As soon as I finish dmake, porting stuff should be quite a bit easier,
>what with dmake and cc ... 

Hey, now were talking, a real make for gno, when this is ready then porting
other un*x stuff will be easy...

Please let me know when it's ready, if you're looking for testers then let
me know.

The new version of gsh will support if/then/else etc... is it compatible
enough to unpack un*x shar files or to run un*x sh scripts.

>:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>|          James Brookes            | Inet: bb252@cleveland.freenet.edu |
>|``What, me worry?'' - A. E. Neuman |   jamesb@cscihp.ecst.csuchico.edu |
>:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::


-- 
 Kevin Henigan. UUCP:     {backbone}!unido!quando!henigan OR henigan@quando.uucp
  Quantum GmbH  Bitnet:   henigan%quando@UNIDO(.bitnet)
    Dortmund    internet: henigan@quantum.de, or henigan@quando.quantum.de
    Germany     advert  : PEDIGREE - the only genealogy IIGS prog with a GUI

In article <1h5c80INN9ba@charnel.ecst.csuchico.edu> jamesb@ecst.csuchico.edu (James L. Brookes) writes:
>
>With the current (1.2/1.3) Orca/C, if code size will exceed one
>bank (64k) you have to segment the code into managable chunks yourself.

    There's one object file (main.o) that seems to fluctuate between 50
and 62K, probably because I was playing around with different flags.  I
followed your advice last night (IRC) but I still get "Code exceeds code
bank size" and a bunch of "Unresolved reference labels".  Ah well...

    For those who don't know what agrep is, it's an extension of the 'grep'
family which allows approximate matches (i.e., matches with insertions,
deletions or substitutions).  According to the docs, agrep is quite fast,
but I haven't tried it out on the GS yet (obviously).
-- 
-- Real name: Brian Tao (Dept. of Exobiology, University of Toronto)
-- Preferred: 90taobri@chasm.scar.utoronto.ca (checked daily)
-- Alternate: taob@r-node.pci.on.ca (no mail over 15K, please!)
--                                   """""""""""""""""""""""""

henigan@quando.quantum.de (Kevin Henigan) writes:

>In article <1h5c80INN9ba@charnel.ecst.csuchico.edu> jamesb@ecst.csuchico.edu (James L. Brookes) writes:
>>As soon as I finish dmake, porting stuff should be quite a bit easier,
>>what with dmake and cc ... 
>Hey, now were talking, a real make for gno, when this is ready then porting
>other un*x stuff will be easy...

Not quite. While a real make will be very helpful, it does not make porting
easier. Or not a lot easier. A decent lib, on the other hand :)

Soenke
-- 
===========================================================================
More than silver, more than gold, I need   !    behrenss@informatik.
electricity. I need it for my dreams.      !    tu-muenchen.de
(RACTER)                                   !  FIDO: 2:246/13 Soenke Behrens

henigan@quando.quantum.de (Kevin Henigan) writes:

>Hey, now were talking, a real make for gno, when this is ready then porting
>other un*x stuff will be easy...

  Well, easi_er.  :-)

>The new version of gsh will support if/then/else etc... is it compatible
>enough to unpack un*x shar files or to run un*x sh scripts.

  No; gsh is based on csh, and always will be.  All Hail the High Grandeur
of Bill Joy!

  But seriously, I've got code for an sh clone, and will finish a port
as soon as I add more robust UNIX-style fork() support to GNO.  I'll
actually be adding vfork(), which the sh clone can be modified to use
instead of regular UNIX fork.

  I believe, however, that there is an unshar program somewhere
that doesn't require sh to work.  I had an unshar.c on my hard drive,
but it just fires up /bin/sh automatically; kinda not what I'd
hoped for :)

  If anyone can find the sh-less unshar, I'd be happy to port it.

-- 
 Jawaid Bazyar              |   Ask me about the GNO Multitasking Environment
 Procyon, Inc.              |   for the Apple IIgs!   
 bazyar@cs.uiuc.edu         |   P.O Box 620334
 --Apple II Forever!--      |   Littleton, CO 80162-0334   (303) 933-4649

bazyar@teal.csn.org (Jawaid Bazyar) writes:

>  If anyone can find the sh-less unshar, I'd be happy to port it.

You don't need to, it's already been ported. As a matter of fact,
both shar and unshar work fine on my GS.

Soenke
-- 
===========================================================================
More than silver, more than gold, I need   !    behrenss@informatik.
electricity. I need it for my dreams.      !    tu-muenchen.de
(RACTER)                                   !  FIDO: 2:246/13 Soenke Behrens

bazyar@teal.csn.org (Jawaid Bazyar) writes:

>henigan@quando.quantum.de (Kevin Henigan) writes:
>>The new version of gsh will support if/then/else etc... is it compatible
>>enough to unpack un*x shar files or to run un*x sh scripts.

>  No; gsh is based on csh, and always will be.  All Hail the High Grandeur
>of Bill Joy!

Just a question (as the subject line says), why did you go with 'csh'
compatibility in the first place?  Unix csh is broken (as far as
programming the thing goes.  Its command line interface works fine,
except that it lacks command line editing and most versions I've
played with don't have filename completion working).  The other
shells like ksh, bash, etc are better...  Of course, this is just an
interest-based question since you're obviously not going to change it
now.

I don't own GNO so I'm also wondering how tightly coupled is the GNO
kernel to the 'gsh' shell?  Can it be replaced with something else or
would you have to start up another shell from inside it.  It would be
cool to have 'chsh /bin/ksh' work in GNO.

>  But seriously, I've got code for an sh clone, and will finish a port
>as soon as I add more robust UNIX-style fork() support to GNO.  I'll
>actually be adding vfork(), which the sh clone can be modified to use
>instead of regular UNIX fork.

Sounds good.
-- 
Jerry Penner   jpenne@ee.ualberta.ca   Try a 1-line .sig today.

jpenne@ee.ualberta.ca (Jerry Penner) writes:

>Just a question (as the subject line says), why did you go with 'csh'
>compatibility in the first place?  Unix csh is broken (as far as
>programming the thing goes.  Its command line interface works fine,
>except that it lacks command line editing and most versions I've
>played with don't have filename completion working).  The other
>shells like ksh, bash, etc are better...  Of course, this is just an
>interest-based question since you're obviously not going to change it
>now.

  gsh takes a lot of inspiration from tcsh, the modern derivative of
csh, which provides command-line editing, smarter path handling,
and filename and command completion.
  We never studied a whole lot on any aspect of why csh's script
language might be considered 'broken'.  Can you provide some examples?

>I don't own GNO so I'm also wondering how tightly coupled is the GNO
>kernel to the 'gsh' shell?  Can it be replaced with something else or
>would you have to start up another shell from inside it.  It would be
>cool to have 'chsh /bin/ksh' work in GNO.

  gsh is completely (100%) decoupled from the kernel.  We did it just
like Unix because, well, Unix did it right :)  chsh .. is trivial,
but right now gsh is the only shell we've got.  I expect this to
change in the future.  gsh also provides some IIgs-specific
support that the Unix based shells cannot (like AppleWorks _and_ emacs
style command line editing).

-- 
 Jawaid Bazyar              |   Ask me about the GNO Multitasking Environment
 Procyon, Inc.              |   for the Apple IIgs!   
 bazyar@cs.uiuc.edu         |   P.O Box 620334
 --Apple II Forever!--      |   Littleton, CO 80162-0334   (303) 933-4649

bazyar@teal.csn.org (Jawaid Bazyar) writes:

>  gsh takes a lot of inspiration from tcsh, the modern derivative of
>csh, which provides command-line editing, smarter path handling,
>and filename and command completion.

Good.

>  We never studied a whole lot on any aspect of why csh's script
>language might be considered 'broken'.  Can you provide some examples?

I can only think of one off the top of my head, but csh has a bug when
you type 'if ( expression...' and you forget the spaces around the (.
There are others.  I basically quit using 'csh' when I ran into stuff
like this and forgot about its problems.  Since you guys didn't port
csh you won't have run into these types of problems.

>  gsh is completely (100%) decoupled from the kernel.  We did it just
>like Unix because, well, Unix did it right :)  chsh .. is trivial,
>but right now gsh is the only shell we've got.  I expect this to
>change in the future.  gsh also provides some IIgs-specific
>support that the Unix based shells cannot (like AppleWorks _and_ emacs
>style command line editing).

Sounds good.
-- 
Jerry Penner   jpenne@ee.ualberta.ca   Try a 1-line .sig today.