HDTenEightyP/NetNews huggingface dataset:
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Removing MacsBug symbols (was Re: how to put indelible...)
Date: 24 Jul 92 18:57:13 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <14nlugINN2qs@agate.berkeley.edu>, ewylie@ocf.berkeley.edu (Elizabeth Wylie) writes:
> In article <D88-JWA.92Jul24000856@dront.nada.kth.se> d88-jwa@dront.nada.kth.se (Jon W{tte) writes:
>>   (You *DO* write betas, don't you? And you *DO* have more than one person (your kid sister doesn't count) test for you?)
>
>>Yes of course. A few Ks don't matter much, and I like getting
>>mail from people who fix my bugs :-) I want others to feel the
>>same way since there STILL is bugs in released software.
>
> When writing INITs, etc.  I always make sure to keep the names off for the
> "final" release.  I'm really obsessive about system heap size.  Mine is 4
> meg on an 8 meg machine.
>
> It also gives me that "polishedd" feeling when I'm finally done with it.

I used to turn off MacsBug symbols on the final build, too. Then I got to
the stage that Steve Jasik aptly summed up as "so much code, so little time".
In other words, with a lot of the stuff I'm doing these days, there's no
such thing as a final build...

Another appropriate saying that comes to mind is "No work of art is ever
finished; it is only abandoned."

Lawrence D'Oliveiro                       fone: +64-7-856-2889
Computer Services Dept                     fax: +64-7-838-4066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Newsgroups: comp.sys.mac.programmer
From: obi@gumby.ocs.com (Kuryan "Obi" Thomas)
Subject: Problem with MPW 32-bit code?
Reply-To: obi@gumby.ocs.com
Organization: Online Computer Systems, Inc.
Date: Wed, 29 Jul 1992 05:01:55 GMT

I seem to be having a problem with MPW's "32-bit everything" code. Version
numbers are: MPW Shell and C 3.2; C++ 3.1.

It looks as though when a CODE segment is unloaded and then loaded later
at a different address, the PC addresses are all screwed up. For example:

#pragma segment FooSeg
void Foo::Bar()
{
    AnotherFooProc();   /* this method is also in the FooSeg segment */
}

Let's say that a routine in the Main segment unloads the FooSeg segment.
Later, another routine in Main makes an (intersegment) call to Foo::Bar().
This works fine; I end up in the function above. But now comes an
intrasegment call to Foo::AnotherFooProc(), which is also in the FooSeg
segment. The PC skids off into the weeds and I get an illegal instruction
fault. I've traced through this with MacsBug and observed it happen.

I'm quite positive that I'm calling UnloadSeg() on the FooSeg segment only
at approved times -- all UnloadSeg()s are in my main event loop, which is
in the Main segment.

Absolutely everything in the entire application is compiled with -model
far. (Everything except the MPW libraries, that is.) I am not using
MacApp.

Has anyone else succeeded in using UnloadSeg() with the new 32-bit model
in MPW C? Am I doing something wrong here?

Please reply by email if you can help. Thank you all in advance.

	obi@gumby.ocs.com
	ocsmd!gumby!obi@uunet.uu.net
	...!uunet!ocsmd!gumby!obi
Newsgroups: comp.sys.mac.programmer
From: Quinn <quinn@cs.uwa.edu.au>
Subject: Re: Writing an external file system
Organization: The University of Western Australia
X-Useragent: Nuntius v1.1
Date: Wed, 22 Jul 1992 01:45:40 GMT

David S.A. Stine talks about the easiest way to figure out external
file systems on the Mac:

>As a pointer to find your own way, I would recommend that you break out
your
>copy of MacNosy (if you want to do this level of programming, you MUST
have
>Nosy) and disassemble the AppleShare client.

Damn the licencing agreement, full speed ahead!  (-:

Quinn "The Eskimo!"   <quinn@cs.uwa.edu.au>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Who was going to quote chapter and verse but can't *actually*
     find a copy of Apple's system software licencing agreement |-:
From: mmigdol@ccwf.cc.utexas.edu (michael a migdol)
Newsgroups: comp.sys.mac.programmer
Subject: Using PostHighLevelEvents to send low level (KeyPressed) events
Date: 24 Jul 92 14:31:06 GMT
Reply-To: mmigdol@ccwf.cc.utexas.edu (michael a migdol)
Distribution: na
Organization: The University of Texas at Austin, Austin TX
Originator: mmigdol@grumpy.cc.utexas.edu

According to IM VI, p. 5-18, "Your application can both send and receive high-
level events, but it generally only receives low-level events and should not
send them."

So, this implies that I *can* send KeyPressed events to other applications. 
(Even though I "shouldn't", I want to. I really do! :) )

Anyways, Apple certainly doesn't seem to encourage this, and I'm about to try
this out myself, but am I supposed to use PostHighLevelEvents with theEvent.what
set to Keypressed (or whatever) to do this? Am I going to hit any problems 
later on? Does the application I'm sending to have to "AcceptHighLevelEvents"
to receive low level events sent this way?

Thanks in advance, and smile - it's FRIDAY!
-Michael

Newsgroups: comp.sys.mac.programmer
From: johns@uuisis.isis.org (john smith)
Subject: Getting String
Organization: International Shared Information Service (Ottawa)
Date: Wed, 22 Jul 92 13:39:16 GMT

Hi.. I'm currently trying to write a small program for my office (i'll get 
paid for it). I've gotten up to a point where i can get a window (created 
from resesit) and wait for a click on an OK button.. What I need now is to 
create a user item that gets a numerical string and return the string to a 
mathematical equation and then give the answer to another window.. 
        I'm even ready to correspond by snail mail with someone who could 
help me real good.. Time is a factor here..And I'm not someone who doesn't 
keep his promises..
        BTW, i'm using Think C 5.0 and ResEdit 2.1
        Thanks a bunch...JOhn@UUISIS
Newsgroups: comp.sys.mac.programmer
From: robert@metropolis.com (Robert Munyer)
Subject: Re: MacScheme
Organization: Metropolis Software, Inc.
Date: Wed, 22 Jul 1992 08:01:19 GMT


In article <zkessin.711469078@chaos.cs.brandeis.edu>
zkessin@chaos.cs.brandeis.edu (Zach, the Lego Maniac) writes:

> mhurst@hns.com (Mark Hurst) writes:
>
> > One notable application that was written in Lisp is the popular UNIX-based
> > text editor Emacs.  Granted, that is not MacScheme, but it shows what can
> > be done with a language without semicolons.
>
> Not quite true, Emacs was writen in C, but it includes a lisp
> interpreter which is how most of the functions and modes etc. were
> writen.

Actually, you are both right.

EMACS was originally written in TECO, which was an early line-oriented text
editor (probably one of the first interactive editors period).  TECO had a
macro facility, and EMACS was just a big, powerful macro package.  In fact,
that's what EMACS stands for -- "Editor MACros".

It soon became clear that EMACS was an "insanely great" concept that deserved
to be a real program instead of just a macro package, so it was completely
rewritten in Lisp (MACLisp, I think).

Eventually, with the ascendancy of Unix, C became a nearly universal
programming language, and a Lisp interpreter that could support EMACS was
written in C.  This made it possible to port EMACS to nearly any machine that
had a C compiler.  The Lisp interpreter is included with EMACS, so in effect,
EMACS is written half in C and half in Lisp.

______________________________________________________________________
Robert Munyer            |   "I may be synthetic, but I'm not stupid."
robert@metropolis.com    |      -- Bishop, _Aliens_

Newsgroups: comp.sys.mac.programmer
From: joshr@kronos.arc.nasa.gov (Joshua Rabinowitz-Summer-91)
Subject: Re: THINK C 5.0 Code overflow
Keywords: error,C programming, THINK C 5.0, Mac
Organization: NASA/ARC Information Sciences Division
Date: Mon, 27 Jul 1992 18:28:27 GMT

In article <1992Jul27.172249.17584@news.iastate.edu> niko@iastate.edu (Nikolaus E Schuessler) writes:
>In article <1992Jul27.160800.18222@cs.few.eur.nl> christ@cs.few.eur.nl (Christ Leijtens) writes:
>
>>         Question: Is there *any* way to get around this  bound  for
>>   the  code and data, so we can continue porting the program to the
>>   Macintosh? We would like any information on porting programs from
>>   other implementation of the C-language to Macintosh THINK C 5.0.
>>
>
>Yes, there is... You have to declare all arrays as pointers to arrays
>and malloc them in a routine at the start of your program... A * real *
>pain ...
>
>char x[1000];
>
>to char *x;
>
>...
>
>x = (char *) malloc(1000 * sizeof(char))


Ummm, are you sure this is what you mean?  it gets an array of 1000 chars
from local memory, then again from malloc.  In addition, isn't x, as declared,
a constant pointer (my language may be incorrect, but i STRONGLY suspect
		       the above code of being not what you meant).

What I think you menat was

{
 ...
 char *x;
 x = (char *) malloc(1000 * sizeof(char));

}

right?
>


-- 
----------------------------------
#include <std/disclaimer.h>     Josh Rabinowitz, Mac TCL programmer
joshr@kronos.arc.nasa.gov
"'I see', said the blind carpenter, as he picked up his hammer and saw".
From: greeny@top.cis.syr.edu (J. S. Greenfield)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Moving to the foreground after receiving an 'odoc' from the Finder
Date: 22 Jul 92 04:34:51 GMT
Organization: Syracuse University, CIS Dept.

In article <1992Jul21.161251.7693@midway.uchicago.edu> jcav@midway.uchicago.edu writes:
>>
>>What is the standard technique to insure that your application is in the
>>foreground after receiving an 'odoc' event from the finder?
>>
>>I have an application (which does not recieve suspend/resume events) which
>                        ^^^^^ ^^^^ ^^^ ^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^
>This is the root of your problem.  If you accept high-level events, you also
>_must_ accept OS events (suspend/resume, etc).

But this is not correct.  The SIZE resource has a bit to indicate whether
the application receives suspend/resume events.  Since this application
does not manipulate any scrap or manipulate any windows (other than modal
dialogs), it has no need for suspend/resume events.

Anyway, even if they were sent, I don't mask them out.  They just would not
produce any response from my application.


>>brings up a custom get file after receiving an 'odoc' event.  If there are
>>some finder windows open, the get file dialog will occasionally appear
>>*behind* the finder windows, initially.  It then moves to the front, but
>>the dialog window is left empty.
>
>If you want to be absolutely sure you're in front, you can call
>_SetFrontProcess (I think that's the name) with your own process serial #.
>However, I suspect that if you handle your suspend/resume events by the
>book, the other problems should "factor out".

Actually, several individuals pointed me to the proper technique when handling
apple events, which is to call AEInteractWithUser.  This routine checks both
the server's and client's specification for allowed interaction in processing
the event, and will call the notification manager, if necessary, in order to
request that the user move the server application to the foreground.

(See IM VI, 6-51 through 6-54.)

In my case, this is not necessary--the call simply holds up my application
until it moves to the foreground, as it will normally do since 'odoc' events
from the Finder allow the server to interact (and the Finder seems to
undertake to move the server to the foreground, itself).


-- 
J. S. Greenfield                                         greeny@top.cis.syr.edu
(I like to put 'greeny' here, 
but my d*mn system wants a 
*real* name!)                        "What's the difference between an orange?"
Newsgroups: comp.sys.mac.programmer
From: joshr@kronos.arc.nasa.gov (Joshua Rabinowitz-Summer-91)
Subject: Re: How do I sleep w/o using any CPU time
Organization: NASA/ARC Information Sciences Division
Date: Fri, 24 Jul 1992 00:09:28 GMT

In article <28474@goofy.Apple.COM> dwb@apple.com (David W. Berry) writes:
>In article <a684a397@spicewood.uucp>, you write:
>>    I am writing an application to check something every so often.  If
>>  something exists, I will then put up an error window.  Everything is
>Typed in off the type of my head, so this isn't error checked (or really
>even syntax checked) but it will give you the general idea...
>
>pascal void Delay(long ticks)
>{
>        long            wakeTime = TickCount() + ticks;
>        long            delay;
>        EventRecord     event;
>
>        while((delay = (wakeTime - TickCount()) > 0)
>                WaitNextEvent(0, &event, delay, 0);
>}

The only problem with this, as I remember it
(and please correct me if I'm wrong),
that apple events cannot be masked.  I looked in inside mac for this, but
could not find a reference to this ?fact?.  (looked at The Event Manager,
IM VI, p. 5-29)  I cannot recall where I got this idea from.

Can anyone refute or back up this belief?
-- 
----------------------------------
#include <std/disclaimer.h>     Josh Rabinowitz, Mac TCL programmer
joshr@kronos.arc.nasa.gov
"'I see', said the blind carpenter, as he picked up his hammer and saw".
From: ewylie@ocf.berkeley.edu (Elizabeth Wylie)
Newsgroups: comp.sys.mac.programmer
Subject: Re: how to put indelible serial# in resource fork of app?
Date: 24 Jul 92 01:21:20 GMT
Organization: U.C. Berkeley Open Computing Facility
NNTP-Posting-Host: tornado.berkeley.edu

In article <D88-JWA.92Jul24000856@dront.nada.kth.se> d88-jwa@dront.nada.kth.se (Jon W{tte) writes:

>But I'm not a beta tester. I still want to know what goes wrong
>and how to fix it !

A good point.  

>
>   (You *DO* write betas, don't you? And you *DO* have more than one person (your kid sister doesn't count) test for you?)

>Yes of course. A few Ks don't matter much, and I like getting
>mail from people who fix my bugs :-) I want others to feel the
>same way since there STILL is bugs in released software.

When writing INITs, etc.  I always make sure to keep the names off for the "final" release.  I'm really obsessive about system heap size.  Mine is 4 meg on an 8 meg machine.

It also gives me that "polishedd" feeling when I'm finally done with it.

-E. Wylie
.
From: rgonzal@gandalf.rutgers.edu (Ralph Gonzalez)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HOW IS QUICKBASIC FOR THE MAC?
Date: 22 Jul 92 19:05:42 GMT
Distribution: usa
Organization: Rutgers Univ., New Brunswick, N.J.

ccmlh@buitc.bu.edu (Mark Hayes) writes:

>For what this is worth, I just received an updated version of
>QuickBasic from Microsoft as a result of having requested that I
>be put on an upgrade-requestors list over a year ago. The new
>version is supposedly System 7 compatible, though it doesn't
>let you do anything particularly "System 7 lustful".

I got my name on this list, too, but despite periodical calls to
Microsoft I haven't gotten any upgrade info.

To the original poster, note that Mac QuickBASIC lacks a few of the
PC versions features, such as data structures(!) -- I wonder if the
update has this?  On the other hand, it offers an easy approach to
writing Mac programs without using the Toolbox directly (though you'll
have to do some tricky and frustrating programming to get all the
details of the Mac interface working properly).  To just port a PC
program should be pretty easy, though.

-Ralph
-- 
Ralph Gonzalez, Computer Science, Rutgers Univ., Camden, NJ
Phone: (609) 757-6122; Internet: rgonzal@elbereth.rutgers.edu
--
Newsgroups: comp.sys.mac.programmer
From: dave@prc.unisys.com (David Lee Matuszek)
Subject: Re: MacOberon
Organization: Paoli Research Center - Paoli, PA
Date: Wed, 29 Jul 1992 15:48:09 GMT

In article <1992Jul28.231712.27337@fcom.cc.utah.edu> kofoid@bioscience.utah.edu (Eric C. Kofoid) writes:
>Several months ago, I downloaded MacOberon, crashed my system several
>times trying to run it, and eventually threw it away.
>
>Recently, a newer port appeared on the archives (2.4(0)). Again, I tried
>it with little success. The expected screen size is a large part of the
>problem. I can't fault anybody who goes to the time and trouble of
>porting something to the Mac for free. However, the installed base of
>Macs with small screens is enormous, and all it takes is a quick look at
>screenBits.bounds to decide where to put your windows and dialogs. 

MacOberon "works" on my Mac (13" monitor).  However, the interface is
a real show stopper.  Even if you assume the author had no particular
reason to follow Apple's interface guidelines, it's still a disaster.
For example, the "scroll bars" work by holding down some modifier key
while you click with the mouse to move the selected line to the top of
the window--but this leaves you with NO WAY to scroll backwards!
Although MacOberon seems to have quite a bit of documentation, you are
on your own when it comes to figuring out what to read first.

I downloaded MacOberon because I wanted to find out something about
the Oberon language, but decided I didn't want to know badly enough to
hassle with the brain-dead interface.  (My interest was only casual;
someone with more motivation could probably succeed.)

I don't know if the interface is incidental or integral to Oberon.  If
incidental, then, as you say, you can't fault somebody for making a
free port, and maybe somebody will someday do a better job.  But it
looked as if the interface was part of the Oberon design, and in that
case you have to wonder if the rest of the language is done as badly
and with as little regard to state-of-the-art techniques.

Comments are welcome.  I'd be especially interested in hearing whether
anyone thinks Oberon itself is neat enough to be worth the trouble of
learning the interface.

  --dave

-- 
 -    -    -    -    -    -    -    -    -    -    -    -    -    -   -    -
I stand by all the misstatements that I've made.
					-- Vice President Dan Quayle
Newsgroups: comp.sys.mac.programmer
From: hass@mprgate.mpr.ca (Calvin Hass (CS Shad Valley Student))
Subject: RE:  Mac programming problem...
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Wed, 29 Jul 92 16:28:01 GMT

Jon W{tte writes:

   My other problem involves printing.  I wold like to bypass messing with the print manager and instead get a "direct connectin".  I want to send it some ESC 
   codes (15cpi, 8lines per inch, ect..).  Then just dump my charecter to it
   instead of the screen.

 You can't. Really. Instead, ask for 72 dpi resolution, and calculate
 your MoveTos and DrawTexts to place stuff where you want it.

Actually, I think one can do something like the following:

Open(f,".printer");

It has been quite some time since I've used it, but I seem to recall that it
will open a text channel to the printer.  From there, one only needs to use
Writeln(f,"Hello there"); commands.

Then again, I'm not absolutely sure of this.

Calvin.
Newsgroups: comp.sys.mac.programmer
From: Tommy.Brown@f204.n2603.z1.ieee.org (Tommy Brown)
Subject: updating finder windows
Organization: FidoNet node 1:2603/204 - Not Even Odd, Forest Hills NY
Date: Mon, 20 Jul 1992 22:05:00 GMT

I don't think that you CAN get the Finder to update the window immediately,

because as far as I know, the Finder just doesn't constantly poll the disk to
see if anything's been changed. The only thing I can think of is if you were

somehow able to get a WindowPtr to the window that the file's in. Then you

could call InvalRect, either over the whole window or just the rectangle of

the icon which you want to change, which I believe you can get by calling

GetFInfo. How to get a WindowPtr to the correct window, though, I don't know. 

--  
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Tommy Brown - Internet: Tommy.Brown@f204.n2603.z1.ieee.org
Newsgroups: comp.sys.mac.programmer
From: tinsel@uiuc.edu (Thomas Aaron Insel)
Subject: Re: Mac programming problem
Originator: tai50080@uxa.cso.uiuc.edu
Reply-To: tinsel@uiuc.edu
Organization: {not speaking for the} University of Illinois at Urbana
Date: Tue, 28 Jul 1992 21:55:38 GMT

d88-jwa@dront.nada.kth.se (Jon W{tte) writes:

> joel@iastate.edu (Joel A Rybolt) writes: [text rewrapped]

> >  My other problem involves printing.  I wold like to bypass messing
> > with the print manager and instead get a "direct connectin".  I want to
> > send it some ESC codes (15cpi, 8lines per inch, ect..).  Then just
> > dump my charecter to it instead of the screen.

> You can't. Really. Instead, ask for 72 dpi resolution, and calculate
> your MoveTos and DrawTexts to place stuff where you want it.

Actually, you can.  You just don't want to, it's easier to use the
Print Manager than to send the commands yourself, but if you don't 
mind sacraficing portability, you can use the serial manager to
write to the printer port.  Some compilers let you address the printer
as a file, also.
-- 
Thomas Aaron Insel (tinsel@uiuc.edu)
  I speak for myself, and not for the State or University of Illinois.
  "We must not confuse dissent with disloyalty." -- Edward R. Murrow
From: mmigdol@ccwf.cc.utexas.edu (michael a migdol)
Newsgroups: comp.sys.mac.programmer
Subject: Posting non-high level events to other applications
Date: 21 Jul 92 13:59:07 GMT
Distribution: na
Organization: The University of Texas at Austin, Austin TX

[I'm clarifying my question a little bit...the one reader who responded didn't
understand what I meant...]

I've got a fortran program which pretty much takes control of the mac until 
it's done executing. (The menus disappear, and the program's IO occurs in a
single window that takes up the whole screen). I'd like to execute this program
from within another program that I'm writing and send it a series of Keypressed
events. This leads to two main questions:

1) After I launch the fortran program (specifying that my program is to continue
running after its' launched), how do I put events in the fortran program's 
queue? 

2) Having done that, is it just a simple matter of using the SetFrontProcess
trap to switch control to the Fortran app?

Thanks in advance!
-Michael
From: ldh@svl.cdc.com (Lawrence D. Hare)
Newsgroups: comp.sys.mac.programmer
Subject: Re: yacc for Mac
Date: 28 Jul 92 22:49:47 GMT
Organization: Control Data Systems
X-UserAgent: Nuntius v1.1.1d1

In article <1992Jul22.192944.22829@mksol.dseg.ti.com> Joel Quejada,
joel@dseg.ti.com writes:
>Is there a yacc-type program for the Mac?

A few years ago I also purchased MacYACC from ABRAXAS. I needed the SQL
grammar. I was very pleased with it. The folks at Abraxas were very
helpful
and the package served me well.

There were a few small errors in the grammar, but easily corrected once
discovered. All in all, I was pleased and the cost was easily recovered
by
the time saved.
--
Lawrence D. Hare       Control Data - Silicon Valley Operations
Consultant             Voice: (408) 496 4339 - C/N [234] 4339
ldh@svl.cdc.com        Mail: SVLa60  FAX: (408) 496-4106You have new mail.
Newsgroups: comp.sys.mac.programmer
Subject: Trap word parameter to Set/GetTrapAddress?
From: russells@ccu1.aukuni.ac.nz (Russell Street)
Date: Fri, 31 Jul 1992 06:11:24 GMT
Organization: University of Auckland, New Zealand.

I am slightly confused about the Trap Word parameter
to Get/SetTrapAddress:
	What should it be? :-)
For instance do I use "0xA9FD" for _ExitToShell or "0xFD"
or NGetTrapAddress or what?

I have always used the straight trap word (0xA9FD) and that
appears to work, but other people strip of high parts or
other strange things (or reasonable depends on which way you
look at it).

I would really like to get this clear (even in my own mind).
Information relevant to modern systems only, PLEASE!

-------------------------------------------------------
And with that remark, folks, the case of the Crown vs
Russell Street (russells@ccu1.aukuni.ac.nz) was proven.






Newsgroups: comp.sys.mac.programmer