HDTenEightyP/NetNews huggingface dataset:
From: vganesan@reed.edu (The Phoenix)
Newsgroups: comp.sys.mac.programmer
Subject: Need Mac Software to play a programmed series of tones
Date: 22 Nov 92 23:47:57 GMT
Article-I.D.: reed.1992Nov22.234757.8571
Followup-To: comp.sys.mac.programmer, vganesan@reed.edu
Organization: Reed College, Portland OR


I apologize if this isn't the optimum group for this question.

I am looking for some kind of mac-software, shareware or commercial
which would enable me to play a series of musical tones with a 
preprogrammed time interval. 

Any pointers to sound programs or ftp sites that carry them would
be deeply appreciated.

with kind regards

Venky
-- 
******************************************************************
Nondum amabam, et amare amabam quaerebam quid amarem, amans amare.
I loved not yet, yet I loved to love I sought what I might love,
in love with loving.                     
Newsgroups: comp.sys.mac.programmer,comp.sys.mac.system,comp.sys.mac.misc
From: stevej@ais.org (Steve Jovanovic)
Subject: TopSoft, Inc. Seeking Developers!
Followup-To: stevej@ais.org
Keywords: TopSoft, FilterTop
Organization: UMCC
Date: Tue, 17 Nov 1992 20:56:38 GMT

Dear Netters,

I'd like to update you on the status of the FilterTop
project, and invite new programmers to join the final
leg of the 1.0 development effort!

TopSoft, Inc. is a non-profit company formed to produce
free software, sample source code, libraries, etc. for
the Mac community.  We started off as a loose group of
programmers in 1991, and incorporated half a year ago,
adding several new projects to the fold (to be announced
in later postings).

Our main product currently is FilterTop, an intelligent
file "filtration" utility based loosely on UNIX pipelines,
multi-threading, graphical "superfilter" creation and
configuration, etc.  It's a bit hard to describe without
seeing...for more info, if you are seriously interested 
in helping with development, please contact me and we'll
get you set up on our mailing lists, etc.  

We are also looking for developers interested in creating
filters for FilterTop.  Examples (which we have) are:
Binhex, Debinhex, Mac->UNIX Text, Macify, etc.  In short,
a filter can do virtually anything, from various types
of file conversion (graphics formats, sound formats,
word processor formats) to filtration, such as UNIX's
"sed," "wc," "grep," etc.  We are trying to establish the
FilterTop filter format as an open standard, so that all 
developers will be able to make use of FilterTop filters
in their applications.  These filters are similar to the
idea behind XTND, but much more flexible, and can run 
concurrently via threads in the FilterTop environment :-)

We're anxious to release FilterTop 1.0, with LOTS of 
filters, and are very eager to find other programmers
who would like to take on the challenge of a complex 
project, and help us put out a great piece of software
available freely to all Mac users.

Thanks, and I look forward to hearing from you!

steve jovanovic

President, TopSoft, Inc.          FilterTop Project Manager
Newsgroups: comp.sys.mac.programmer
From: jpugh@apple.com (Jon Pugh)
Subject: Re: Claris Apple Events
Date: Sat, 21 Nov 1992 06:30:25 GMT
Organization: Apple Computer, Inc.
Followup-To: comp.sys.mac.programmer

In article <1992Nov19.030657.9662@cs.cornell.edu>, dawson@cs.cornell.edu
(Dawson Dean) wrote:
> 
>    I want to send an apple event to several third party programs,
> particularly some of Claris' programs (MacWrite, FileMaker, etc.).
> I looked through the Apple Events Doirectory on ftp.apple.com,
> but all that lists is the core events and the QuickDraw events.
> 
> Does Claris publicize these things? I`ve seen demos where their
> programs work closely together, so there is an extensive set of
> Apple Events, but do they tell developers about these?

FileMaker Pro is the only Claris app that supports the object model and
Apple Events.  Hypercard supports only a few Apple Events.

Jon
Newsgroups: comp.sys.mac.programmer
From: pchang@Xenon.Stanford.EDU (The Weasel)
Subject: Re: Q: ThinkC5.0.3 and Apple Sys7.1 Incompatibility?
Organization: CS Department, Stanford University, California, USA
Distribution: no
Date: 16 Nov 92 19:31:30 GMT

Hi There,

I have not had any problems with 7.1 and Think C. I think I am
running 5.0.3, but since I'm at school I don't know for sure.

Peter
From: hurtz@mcl.ucsb.edu (Gary Hurtz)
Newsgroups: comp.sys.mac.programmer
Subject: Where is the TCL 1.12 (or so) upgrade??
Summary: Im trying to find a the new upgrade to the TCL
Keywords: TCL thinkc
Date: 17 Nov 92 19:32:21 GMT
Article-I.D.: mcl.hurtz.722028741


 have recently downloaded the thinkc 5.03 upgrade, and in the documentation
 it said that there is an upgrade to TCL (something like 1.12, i think).
 Anyways, I havent been able to find it anywhere.  Does anyone know any
 site I can ftp it from??

 send to hurtz@mcl.mcl.ucsb.edu

 thanks.
From: bowman@reed.edu (BoBoRamDos)
Newsgroups: comp.sys.mac.programmer
Subject: Command-Option-Down Arrow broken! (MPW)
Date: 17 Nov 92 20:14:30 GMT
Article-I.D.: reed.1992Nov17.201430.27220
Organization: Reed College, Portland, OR

A couple of weeks ago (right after I installed Now Utilities 4), command-option
down arrow (go to end of file) stopped working in MPW.  It still works fine
in SADE.  I've since upgraded from 3.3a14 to 3.3a16, and it still doesn't work.
I've removed Now, and *that* didn't fix it.  As anyone who is used to using
that particular key sequence, having it go away is a major pain.  Anyone have
any ideas?

Tanks,
bobo
bowman@reed.edu
"It's almost an unwritten law that computer programs should be easy to read and
as self-explanatory as possible." - John Clark Craig (free beer if you know him)
From: rgoldstone@OAVAX.CSUCHICO.EDU (Robin, Girl Wonder)
Newsgroups: comp.sys.mac.programmer
Subject: Think Reference - feedback wanted
Date: 19 Nov 92 21:16:14 GMT
Reply-To: rgoldstone@OAVAX.CSUCHICO.EDU
Organization: California State University, Chico
NNTP-Posting-Host: oavax.csuchico.edu

My sister is a product manager at Symantec and she is looking for feedback
from programmers who are using the Think Reference software.  If you are 
using Think Reference and would care to make comments about its usefulness
to you and/or any problems you have encountered, she would appreciate hearing
from you. (You might even get a free gift *hint hint*).

Her name Lisa Vermont and she can be reached on Applelink: 
D7202@applelink.apple.com
or by phone: (408)446-8958 (she'd call you back).

***********************************************************************
Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu
Newsgroups: comp.sys.mac.programmer
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Blat
Date: Sun, 22 Nov 1992 07:43:14 GMT
Organization: Apple
Followup-To: comp.sys.mac.programmer

In article <1992Nov21.171242.24384@hobbes.kzoo.edu>,
k044477@hobbes.kzoo.edu (Jamie R. McCarthy) wrote:
> Bo3b writes:  "If the incompatibility problems make it useless for you, I
> would be interested to know that as well.  Given the difficulty of writing
> code of this form, we have judged it to not be worth the time to make it
> work in every situation."
> 
> I, for one, would love to use this tool on my IIci.  Imagine an EBBE
> that traps not only _reads_ from 0, but _writes_ to them--on the very
> instruction where the offense occurs!  And not only location 0, but the
> next 255 bytes as well.  This would be quite nice.

FYI, the New SADE 1.4 will support MMU protection on both 030 and 040
machines. Alphas are available on ETOs. That would be one reason
to use SADE :-). We at DTS have the sources to Blat, and I guess
one nice night-time hack would be to roll in 040 MMU support
into the Blat tool.

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
Newsgroups: comp.sys.mac.programmer
From: reuber@world.std.com (kent b reuber)
Subject: Re: THINK Pascal- program crashes only when stand-alone
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 17 Nov 1992 20:49:59 GMT

kurisuto@chopin.udel.edu (Sean J. Crist) writes:

>Without going into the specifics, here's my general problem.  I have a
>program which functions fine when running within the THINK Pascal
>development environment, but which crashes when compiled as a stand-alone
>application.

>What could be causing this?  How can I even attack the problem when I
>don't have THINK Pascal's programming tools to see why this stand-alone
>program is crashing?  I can't imagine that this is a bug in THINK Pascal,
>but it seems that the simulated run environment ought to be realistic
>enough that any problems which a stand-along application is going to
>have will be apparent in the simulated environment as well.

>--Kurisuto

It's hard to say without knowing what your code does. However, I had a
similar experience several years ago with Turbo Pascal for the Mac, where
I would get different answers to a matrix problem depending on whether I
was running under Turbo or in a stand-alone application. I found out that
I hadn't locked a Handle properly--in the stand-alone version a memory
block was being moved unexpectedly and my handle was pointing to garbage.
You might look into this.
-- 
Kent Reuber                   | Schepens Eye Research Institute
Computer Operations Manager   | 20 Staniford St.
reuber@world.std.com          | Boston, MA 02174
reuber@cdv.eri.harvard.edu    |
From: werner@soe.berkeley.edu (John Werner)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Pointers to function and UnloadSeg
Followup-To: comp.sys.mac.programmer
Date: 24 Nov 1992 03:48:28 GMT
Organization: UC Berkeley School of Education
Distribution: world
NNTP-Posting-Host: 128.32.157.31

In article <1992Nov24.011014.9522@alw.nih.gov>, Chris Spiral Catfish Tate
wrote:
> 
> In a related vein, what about calling UnloadSeg() on code segments that are
> in your function's calling chain, but not in the same segment?  Are all
> those code segments locked reliably?

I think you're asking whether it's safe to call UnloadSeg on segments that
are in the current call tree/stack, but that don't contain the function
currently executing.  If so, don't; this is a recipe for disaster.  Imagine
that a funciton calls UnloadSeg on its caller's segment, then does
something that purges memory.  When it returns, its caller won't be there,
and there will be a spectacular (and probably hard to debug) crash.

>Might this sort of thing interact oddly with setjmp() and longjmp() in
>THINK C 5?

It would interact oddly with just about _anything_, including setjmp and
longjmp.

--
John Werner                         werner@soe.berkeley.edu
UC Berkeley School of Education     510-642-9651
Newsgroups: comp.sys.mac.programmer
From: ralex@tigger.cs.Colorado.EDU (Repenning Alexander)
Subject: what is the iconData field in the CIcon record?
Organization: University of Colorado, Boulder
Distribution: na
Date: Sun, 15 Nov 1992 23:52:01 GMT


I have to create new color icons in my application on the fly, i.e, I
cannot use ResEdit to create a resource and then load the resource. I
have created PixMap and BitMaps before -> no problem. However, there
is one field in the CIcon record that I don't quite understand: iconData

The field description explains that the iconData field contains a
handle to the icon's pixel image. What does that mean; is this just a
handle pointing to the same thing as the baseAddr pointer in the
iconPMap field of the CIcon? If so, why?

I'd really appreciate any email replies..

  Heeelp,  Alex


Newsgroups: comp.sys.mac.programmer
From: Ed Rotberg <gonzo@ntb.apple.com>
Subject: Re: date on the mac
X-Useragent: Nuntius v1.1
Date: Thu, 19 Nov 1992 21:27:48 GMT
Organization: Apple Computer

larsel@ifi.uio.no (Lars Yngvar Ellingsen)


In article <1992Nov19.014824.4747@ifi.uio.no> Lars Yngvar Ellingsen,
larsel@ifi.uio.no writes:
>(The routine is supposed to write a row of pixels from position x,y with 
>one specific value on the screen in 8-bits color.)
>(I'm extremely inexperienced with both C and asm so forgive my stupid 
>blunders :)
>
>main()
>{
>  GDHandle	theDevice;
>  unsigned char *color;
>  long          *address; 
>  short         x,y,*width;
>  unsigned int  color;
>   
>  theDevice = GetMainDevice();
>
>  // do stuff; assign values to x, y, color and width
>  
>  &address = &(*(**(**theDevice).gdPMap).baseAddr)+
>             (long)y*SCREENWIDTH+(long)x;
>  asm {
>    @Main:   move.b    color,d1
>             move.w    width,d2
>             movea.l   address,a1
>    @Loop:   move.b    d1,(a1)+
>             dbra      d2,@Loop
>             rts         
>  }
>}
>
>What am I doing wrong?


Notice how you are using the pointer variable "address"?  You are moving
it
into an address register and writing indirect through it.  Also note that
both color and width are also pointer variables, but you are accessing
them
as though they are not!  The simplest fix to the above code would be:

@Main:  movea.l    color,a1               ; pick up pointer to desired
fill color
            move.b     (a1),d1                 ; pick up desired fill
color
					  movea.l    width,a1              ; pick up pointer to line width
            move.w     (a1),d2                ; pick up line width

instead of:
 
>    @Main:   move.b    color,d1
>             move.w    width,d2


This of course assumes that color and width should INDEED be pointer
variables.

Ed Rotberg                 "Just remember...
Professor of Gonzo          a waist is a terrible
Apple Computer, Inc.        thing to mind"
Newsgroups: comp.sys.mac.programmer
From: cpastore@unity.ncsu.edu (Chris Pastore)
Subject: Access directory contents
Organization: North Carolina State University Computing Center
Distribution: comp.sys.mac.programmer
Date: Mon, 16 Nov 1992 13:16:17 GMT

Apologies for ignorance.

I would like to open all of the files within a given folder.  I use
CustomGetFile to identify the folder in question, but where is the 
list of file names inside this folder?

Is there some easy way to get the listing of file names once a
directory is identified?

Thanks in advance.

c. pastore

-- 
Chris Pastore, Asst Prof.      |When space doesn't exist, having somebody
NC State Univ., TECS           |unpleasant like Mr. Pber^t Pber^d underfoot all
919 515 6572                   |the time is the most irritating thing.
chris_pastore@ncsu.edu         |  -- Italo Calvino
Newsgroups: comp.sys.mac.programmer
From: mcmath@csb1.nlm.nih.gov (Chuck Expansion Draft Fodder McMath)
Subject: PostHighLevelEvent buffer limit?
Followup-To: comp.sys.mac.programmer
Organization: MSD
Date: Thu, 19 Nov 92 20:25:57 GMT

I'm having a small problem which surfaced just recently.  I have two Mac
applications (both of which I wrote) which pass data back and forth using
high level events.  The code was written a few months ago and tested out
ok.

The problem is that I just changed the initial write to send out a rather
large bufferful of data (actually only about 4K).  Here are the two calls:

Exhibit A:
	  err = PostHighLevelEvent(theMsgEvent, (unsigned long)&itsPSN, 0,
				   (Ptr)&buffer, bufSize, theOptions);

Exhibit B:
   err = PostHighLevelEvent(theMsgEvent, (unsigned long)&itsPSN, 0,
				   nil, 0, theOptions);
	

Exhibit B works fine.  The recipient does get the event, and all is well. 
Exhibit A, however, is another story.  The recipient NEVER GETS the event,
and the error returned from this call is zero.  Both bufSize and theOptions
are declared as longs.

I decided to try something different:

Exhibit C:
				err = PostHighLevelEvent(theMsgEvent, (unsigned long)&itsPSN, 0,
							(Ptr)&buffer, 1L, theOptions);

This one works also.  So far, values of 0, 1, and 512 have worked, and a
value of 1024 did not.  Note that the bufSize sent in Exhibit A was
determined by the statement:
      bufSize = sizeof(buffer);

I don't know what to do.  IM6 does not reveal any light on this problem I'm
having.  Is there some inherent (unknown to me) buffer size limit on Post
HL Event?  Why would a big buffer size cause the target app to never
receive the event?

Running on a IIfx with 32 MB of RAM, MPW 3.2.3, C++ 3.2.4, MacApp 3.0.1

chuck

|- chuck mcmath - mcmath@csb1.nlm.nih.gov - MSD, Inc. ------------|
|- National Library of Medicine - National Institutes of Health --|
|- Bethesda, MD 20894 - Volunteers to be next baseball commish -- |
|- "Hey batter, hey batter, hey batter, swing" - Anon. -----------|
Newsgroups: comp.sys.mac.programmer
From: fixer@faxcsl.dcrt.nih.gov (Chris Spiral Catfish Tate)
Subject: Re: Large multidimensional arrays in C (THINK/MPW)???
Reply-To: fixer@faxcsl.dcrt.nih.gov
Organization: Computer Systems Laboratory, DCRT, NIH
Date: Tue, 24 Nov 1992 01:01:06 GMT

In article <1992Nov23.203639.7607@newssun.med.miami.edu>, jack@umbio.med.miami.edu (Jack Herrington) writes:
>
>newHand = NewHandle(sizeof(theStruct)*4000);
>
>But that will fail because Think is going to think of both of those as shorts
>even though the product will be more than a short.

At least in THINK C 5, this will *not* fail; sizeof(theStruct) is treated
as an unsigned long.  What *will* fail is something along these lines:

     short  size;

     size = sizeof(theStruct);
     newHand = NewHandle(size * 4000);     // use 4000L to force a long mult.

Getting back to the original poster's question (how to dynamically allocate
two-dimensional arrays), another approach I haven't seen is to use intermediate
typedefs to set up the desired references:

     typedef short short_array[100];
     typedef short_array big_array[100];

     for (i=100; i--; ) big_array[i] = (short_array *)
          NewPtr(sizeof(short_array));  // is this the right cast?

     (*bigArray[x])[y] = someValue;

The drawback is that it takes an additional dereference to access a location.
I myself would probably do this:

     short *short_array;      // simulate 100x100 array...
     long  x, y;              // note that these are long!
     
     short_array = (short *) NewPtr((long) num_elements * sizeof(short));
     *(short_array + x + 100*y) = someValue;

The only drawback is that here, you need to make sure the factor within the
address calculation is correct (which presumably you *do* know... :-).  Also,
it's important that the multiplications and additions in the address
calculation be done as long arithmetic, to avoid generating negative offsets
off of short_array.

------------------------------------------------------------------------------
Christopher Tate             | The Leadfoot Collection, Continued:
Management System Designers  |     * Heavy Fuel (Dire Straits)
                             |     * Last Scene in September (Preston Reed)
fixer@faxcsl.dcrt.nih.gov    | Because driving fast is a cathartic experience.
Newsgroups: comp.sys.mac.programmer
From: thomp@netcom.com (Thom Philabaum)
Subject: Need help writing RDEV
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 20 Nov 1992 22:05:59 GMT

I'm busy writing an RDEV (chooser device) but am having some troubles.
The device icon shows up in the chooser but when you click on it
it doesn't call my PACK resource.  The PACK resource is formatted
correctly and even if I paste a PACK in from another device the
code isn't called.

I assume this means either something in the file (other than the PACK)
is missing or wrong.  Anyone ever seen anything similar?

Please respond via e-mail.... thanks

thom phillabaum (thomp@netcom.com)
Newsgroups: comp.sys.mac.programmer
From: shoemake@apple.com (Mike Shoemaker)
Subject: Re: AppleTalk packets OR ATP and DDP, oh how they echo
Date: Sat, 21 Nov 1992 21:52:37 GMT
Organization: Apple Computer, Inc.
Followup-To: comp.sys.mac.programmer

In article <1992Nov18.004651.6480@bilby.cs.uwa.edu.au>, Quinn
<quinn@cs.uwa.edu.au> wrote:
> 
> Johnathon Suker, jsuker@orion.oac.uci.edu (incorrectly) writes:
> >	I have come screaming to a halt in front of a brick wall known as
> >AppleTalk ATP and DDP packets.  I have this program I am trying to write
> >(dont we all) which will utilize the ECHO PROTOCAL.  Unfotunately,
> everything
> >I have read (Inside Mac, Inside AppleTalk, Programming with AppleTalk)
> merely
> >state that EP is implemented throught DDP.
> >And DDP is not directly accessible to the programmer.
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Damn!  I'll just go and tell my co-programmer that the DDP network
> program we spent the last few month writing is impossible (-;
> 
> But seriously check out Inside Mac II-308..312 (OpenSkt, CloseSkt
> and WriteDDP), II-329..330 (writing a socket listener (yuk!)) and
> V-510..515 (the 'Preferred' AppleTalk interface).  Oh, and be
> prepared for some assembly (yum!).
> 
> Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"

When reading Inside Mac, you'll be tempted to use the "DDPRead" to
read the response to your Echo packet. Don't. You'll never get
any incoming packets. DDPRead was written before MultiFinder came
along.

You have to write a socket listener (in assembly). See the latest
Macintosh Technical Notes from Developer Technical Support -- I'm
pretty sure I saw a complete socket listener sample source code you
can steal.

---
Mike Shoemaker
Apple Computer, Inc.
shoemake@apple.com
Newsgroups: comp.sys.mac.programmer
From: jmunkki@vipunen.hut.fi (Juri Munkki)
Subject: Funny thing...
Reply-To: jmunkki@vipunen.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology
Date: Sun, 15 Nov 1992 21:19:18 GMT

Today, I programmed SANE and floating point support into my program. I then
moved on to writing an entry about it into my log (I'm paid by the hour) when
suddenly I started laughing out loud...

Maybe it's the programming that's making me crazy or the lack of sunshine,
but when I saw that "floating point support" is "liukulukutuki" it was
quite impossible not to be amused...

That was the content of this article.

-- 
  Juri Munkki					       Windsurf: fast sailing
 jmunkki@hut.fi					      Macintosh: fast software
Newsgroups: comp.sys.mac.programmer
From: Jim Cook <J.Cook@ENS.Prime.COM>
Subject: Invalidating the Entire Screen?
Reply-To: <J.Cook@ENS.Prime.COM>
Organization: Prime Computer, Inc.
Date: Thu, 19 Nov 1992 22:04:47 GMT

Seem like an easy enough, innocent question:

I have a RasterOps 24STV Frame Grabber which both acts as a frame grabber and
a video board for my Apple 13" monitor.  When I grab a frame, it scribbles over
the entire screen because it uses the refresh memory for the screen as the
buffer to grab the picture into.  Fair enough - a quick, cheap solution.

Alright, how do I invalidate the entire screen so it all gets redrawn?
Obviously, I can invalidate my own window, but what about the windows belonging
to other active applications or the desktop background or the menu bar?

Is there an easy one call should do it all?  

Attempting to post an invalidate to my window large enough to cover the entire
desktop/screen doesn't cut it - it only gets my window (the invalidate is
obviously clipped to my window).

I could open a window as large as the screen and immediately close it, but 
that's kind of a hack and I don't know that it will take care of the menu bar.

There is the possibility of walking the list of open windows (assuming I can
get to it in a documented manner), but I don't know the structure and that
doesn't seem to cover the desktop background.

I've tried posting an invalidate to the window manager port, but that just
caused a crash.

What's a poor image processing student to do?

Newsgroups: comp.sys.mac.programmer