tcl-mac — Q&A for Tcl on the Macintosh platform

[MACTCL] ANNOUNCE: QuickTimeTcl version 3.0a3

[Mats B. <ma...@pr...>]

ANNOUNCE: QuickTimeTcl version 3.0a3
------------------------------------

This is mainly a small "maintenance release", that besides some
bugfixes, also contains a significantly extended still image
export features.  It has also been tested with QuickTime 5
on both Macintosh and Windows.  Se the changes file in the
distribution for detailed info.
Both Mac and Windows are supported, of course. 

The supported still image export formats are:

	- BMP
	- JFIF
	- JPEG
	- MacPaint
	- PhotoShop
	- PNG
	- QuickDraw PICT
	- QuickTime image format 
	- Silicon Graphics format
	- Targa
	- TIFF

It is also possible to specify a dialog, which gives a "Save As..."
type of dialog where additional options for each format, such as
compressions settings etc., can be set.

Visit "http://hem.fyristorg.com/matben/qt/" for additional
info and download.

The new QuickTime 5 supports MPEG-1 and Flash 4 among other things.

Enjoy,     Mats
ma...@pr...

[MACTCL] Useless project template

[Steve C. <ste...@mq...>]

I've put together the simplest possible Macintosh tcl extension and written a 
script to change it's name. The idea is that it serve as a template for new 
projects on the mac or for porting existing extensions.  

One of the problems I had with Code Warrior was finding all the changes that 
needed to be made to the sampleextension project in order to convert it for 
use in my project. This project contains a tcl script which automates that.

More info and download is at:

http://www.shlrc.mq.edu.au/~steve/tcl

Any feedback, esp. from Mac folks about how this should be done would be 
appreciated.

Steve

[MACTCL] Tcl Core Team: Call for Tk maintainers

[Donald G P. <dg...@em...>]

=09*=09*=09*=09*=09*=09*=09*

In February, the Tcl Core Team (TCT) called on members of the community
to volunteer as maintainers of the Tcl source code.  We are pleased to
note that many prominent members of the Tcl community have answered that
call, including Daniel Steffen, Kevin Kenny, Miguel Sofer, Rolf
Schroedter, and Vincent Darley.  Several TCT members are also performing
maintainer duty.  Thanks to all these people [*] who keep high quality
in the Tcl source code!

In recent days, the TCT has quietly been collecting volunteers to serve
as maintainers of the Tk toolkit source code.  Already on board are
Allen Flick, Fr=E9d=E9ric Bonnet, and Miguel Ba=F1=F3n in addition to TCT
members [+].  Now the TCT would like to issue a more public invitation
to others who may be interested in working on the Tk source code.

We have divided Tk into 86 parts, each covering one functional area [#].
We are looking for people who are willing to maintain / take
responsibility for (at least) one of these functional areas.  Each area
can have many maintainers, so feel free to join forces with others. =20
Prior knowledge of the Tk source code in the chosen area is useful but
not required.  A willingness to acquire such knowledge is required, as
is enough volunteer time, i.e. at least a few hours per week.

The basic tasks a maintainer performs are the review and integration of
patches to his or her functional area of Tk.  For a more detailed
description of how maintainers work on Tcl/Tk, see TIP 28 [$].

People who are interested in becoming a Tk maintainer (or a Tcl
maintainer -- there's still room for more!) should send an email to the
TCLCORE mailing list <tcl...@li...>.  Let us know your
SourceForge [@] account name, so we can empower you as a Tcl/Tk
Developer.

~~~
[*] -- http://dev.scriptics.com:8080/cgi-bin/tct/tip/24.html --
[+] -- http://dev.scriptics.com:8080/cgi-bin/tct/tip/30.html --
[#] -- http://dev.scriptics.com:8080/cgi-bin/tct/tip/23.html --
[$] -- http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html --
[@] -- http://sourceforge.net/ --



| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[MACTCL] Tcl Core Team: Call for Tk maintainers

[Donald G P. <dg...@em...>]

=09*=09*=09*=09*=09*=09*=09*
=09
In February, the Tcl Core Team (TCT) called on members of the community
to volunteer as maintainers of the Tcl source code.  We are pleased to
note that many prominent members of the Tcl community have answered that
call, including Daniel Steffen, Kevin Kenny, Miguel Sofer, Rolf
Schroedter, and Vincent Darley.  Several TCT members are also performing
maintainer duty.  Thanks to all these people [*] who keep high quality
in the Tcl source code!

In recent days, the TCT has quietly been collecting volunteers to serve
as maintainers of the Tk toolkit source code.  Already on board are
Allen Flick, Fr=E9d=E9ric Bonnet, and Miguel Ba=F1=F3n in addition to TCT
members [+].  Now the TCT would like to issue a more public invitation
to others who may be interested in working on the Tk source code.

We have divided Tk into 86 parts, each covering one functional area [#].
We are looking for people who are willing to maintain / take
responsibility for (at least) one of these functional areas.  Each area
can have many maintainers, so feel free to join forces with others. =20
Prior knowledge of the Tk source code in the chosen area is useful but
not required.  A willingness to acquire such knowledge is required, as
is enough volunteer time, i.e. at least a few hours per week.

The basic tasks a maintainer performs are the review and integration of
patches to his or her functional area of Tk.  For a more detailed
description of how maintainers work on Tcl/Tk, see TIP 28 [$].

People who are interested in becoming a Tk maintainer (or a Tcl
maintainer -- there's still room for more!) should send an email to the
TCLCORE mailing list <tcl...@li...>.  Let us know your
SourceForge [@] account name, so we can empower you as a Tcl/Tk
Developer.

~~~
[*] -- http://dev.scriptics.com:8080/cgi-bin/tct/tip/24.html --
[+] -- http://dev.scriptics.com:8080/cgi-bin/tct/tip/30.html --
[#] -- http://dev.scriptics.com:8080/cgi-bin/tct/tip/23.html --
[$] -- http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html --
[@] -- http://sourceforge.net/ --

| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [MACTCL] apple button

[Mads L. <ma...@el...>]

ok, i found it myself

but now i learned that the Alt, Alt_L and Alt_R does not work.

has anybody managed to bind the alt button on mac

Cheers

Mads

----- Original Message ----- 
From: "Mads Linden" <ma...@el...>
To: <Tc...@li...>
Sent: Thursday, April 05, 2001 10:15 PM
Subject: [MACTCL] apple button


> is there any way to bind the apple button
> 
> bind . <key-Apple> {puts "hi mac"}
> etc...
> 
> ?????
> 
> Cheers
> 
> Mads
> 
> 
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> http://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Problems with stat on Mac

[Daniel A. S. <st...@ic...>]

Steve,

sorry for the delay,  maybe you've solved this problem already?

At 11:38 +1000 on 30/3/01, Steve Cassidy wrote:

>Note that originally this was a call to stat() but I replaced it 
>with Tcl_Stat for the mac.
>I've been through various troubles with stat eventually finding out 
>that you can't include
><fcntl.h> anywhere as it gives a duplicate definition of stat.

I don't understand this, Tcl already includes the MSL fcntl.h, so 
including it again should not cause a problem. are you sure you're 
including the correct fcntl.h (and/or stat.h)? there are probably 
several around, e.g. the MPW folder has a different one, so if your 
access paths are setup to loosely, you may get that one by mistake.
IIRC some beta versions of Apple's Universal Interfaces also had some 
standard headers in them that conflicted with MSL's.

also, you should be able to use MSL's stat, there is in principle no 
need to use Tcl_Stat, although it's probably a good idea. If that 
doesn't work already, it may help to pinpoint the problem.

>When compiling this I get:
>
>Error   : illegal use of incomplete struct/union/class 'struct stat'
>trackdata_ssff.cpp line 84   stat *statbuff =3D new stat;
>Project: emu.=B9, Target: Emu Shared Lib, Source File: trackdata_ssff.cpp
>
>Error   : illegal use of incomplete struct/union/class 'struct stat'
>trackdata_ssff.cpp line 91   track->file_num_rec =3D (statbuff->st_size
>- In->Data_Seek_Pos)/In->One_Rec_Size;
>Project: emu.=B9, Target: Emu Shared Lib, Source File: trackdata_ssff.cpp
>
>I've no idea what this means or how to get rid of it.  My next step 
>is to try to use stat
>in a small program but I wondered if anyone else had any insight 
>that might help.

this looks like a consequence of a header conflict and of struct stat 
not being defined identically everywhere. do you know what file the 
definition of struct stat you use here comes from?

Sorry to not be more helpful...

Cheers,

Daniel
-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

[MACTCL] Re: Mac Tcl_CreateInterp() unmapped memory exception

[Daniel A. S. <da...@us...>]

Charlie,

sorry for the delay in answering.

There are several errors in your project that cause it to fail.

On the mac when building an application, you cannot link against the 
stub libraries, at least not for Tcl, maybe Tk works, but I doubt it 
(I must admit I don't know how this works on Windows)
the function pointers needed to initialize the tcl stub tables when 
calling Tcl_InitStubs() can't come out of thin air, they are imported 
from Tcl.shlb
i.e. in an application, you MUST link against Tcl.shlb, otherwise any 
call to a tcl routine will jump into the void... (does linking 
against stubs only really work on windows in application code??)

the second reason for your crash (even when you link with Tcl.shlb) 
is that you are not calling Tcl_FindExecutable() before calling 
Tcl_CreateInterp()

this happened to you because your tcl startup is so non-standard, is 
there a reason you're not calling Tcl_Main? it would do all this work 
for you, and correctly...

it also looks like you're not linking with the correct runtime 
libraries, you need to link with the MSL shared libraries and 
MoreFiles.shlb, you also will need to merge these in with the 
executable.

Please have a look at how SimpleTcl or Wish are built on the mac, 
that will tell you how to link&merge properly, and consider adapting 
their startup code, see e.g. tclMacAppInit.c

you should also check out an updated version of the scriptics 
sampleextension I put together recently, the projects in there will 
tell you how to link an extension on the mac

http://www.maths.mq.edu.au/~steffen/tcltk/Mac_sampleextension-0.2.1.bin

you also might want to consult the tcl-mac list archives, I've posted 
a number of times recently on build issues
http://www.geocrawler.com/redir-sf.php3?list=tcl-mac

Hope this helps

Cheers,

Daniel


At 15:10 -0700 on 3/4/01, Charlie Fenton wrote:

>Dear Mr. Steffen,
>
>I apologize for bothering you with this.  If you can refer me to a 
>more appropriate source of information, that would be great.
>
>I am the programmer who did the Mac port of the SETI@home client / 
>screensaver, and am now working with United Devices to develop a 
>distributed computing client for cancer research and other 
>applications.
>
>We are using Tcl/Tk to provide a cross-platform GUI.  I have been 
>having some problems porting code which runs fine on Windows to the 
>Mac.
>
>In particular, I have 2 problems:
>
>(1) linking with the stub libraries TclStub.lib and TkStub.lib does 
>not satisfy the CW Pro 6 linker.  It only links if I include the 
>Tcl8.3.shlb and Tk8.3.shlb in the project.
>
>(2) The call to Tcl_CreateInterp() gets an unmapped memory 
>exception, apparently in MW_MSL.PPC.Shlb.
>
>I have created a minimal CW Pro6 project to demonstrate this, and 
>included it, along with my stub libraries.  (I have the link problem 
>both with the original stub libraries included with the full install 
>and with ones I built using the TclLibraries project).
>
>I got the Tcl/Tk package using the "TclTk 8.3.2p1 Full Installer" 
>dated 12/15/00.
>
>I would be very grateful for any advice you can offer.  Thank you 
>for taking the time to look at this.
>
>Cheers,
>--Charlie
>Attachment converted: Classic:Tcl/Tk Test.sit (SIT5/SIT!) (00042AF6)
>--
>Charlie Fenton                        cf...@cf...

-- 
** Daniel A. Steffen                  **
** <mailto:da...@us...> **

[MACTCL] apple button

[Mads L. <ma...@el...>]

is there any way to bind the apple button

bind . <key-Apple> {puts "hi mac"}
etc...

?????

Cheers

Mads

[MACTCL] Mac look-alike widgets

[Mats B. <ma...@pr...>]

Hi all,

If you thought that Tcl/Tk on the Mac was pretty far from the 
"real thing" you have to rethink.

I've written two look-alikes. The first is a tabbed notebook
widget based on the code examples in the book by McLennan et al.
Not many pixels differ from the real thing, with just a few
lines in canvas. On other platforms it doesn't look that good
since the one pixel offset for vertical lines on the Mac.
("http://hem.fyristorg.com/matben/MacTabnotebook.tar.gz")

The second one is a tree widget based on Richard Hipps
tree widget. It is an almost complete rewrite that is configurable
enough to look like windows or mac, your choice. The mac "version"
has some differencies compared to the original, but this can
be easy to fix for "fundamentalists".
("http://hem.fyristorg.com/matben/Tree.tar.gz")

Not that useful, but shows some interesting techniques is the
movie controller. ("http://hem.fyristorg.com/matben/mc/mc.html")

All widgets are script based and run on a standard installation.

Enjoy,    Mats

Re: [MACTCL] applescript and my app

[Jon G. <jg...@hi...>]

At 12:25 AM +0200 4/2/01, Mads Linden wrote:

>but now i am wondering how to NOT to allow interaction from applescript in
>my app.

Stripping the 'aete' resource would be a start, although it won't 
deter a knowledgeable AppleScripter. Beyond that, you'd need to 
remove the "do script" handler in the source code and recompile Tcl.

I'm curious why?

-- 

   Jonathan E. Guyer
   <http://www.his.com/jguyer/>

[MACTCL] applescript and my app

[Mads L. <ma...@el...>]

bosse at my work now manage to build latest for the mac )| great!

but now i am wondering how to NOT to allow interaction from applescript in
my app.

Cheers

Mads

[MACTCL] Re: Tcl/Tk on MacOS X

[Jim I. <wol...@mi...>]

in article bob...@va...,
Robert Hicks at bob...@no... wrote on 3/28/01 8:07 AM:

>> Native OSX Tk isn't there yet, but there have been several posts
>> of how to use the Tk via the (Unix) X libraries for OSX, if you
>> want to go that way.  Look in groups.google.com for the refs.
> 
> I am just happy knowing it is in the works...

Some people have already built a version of Tk with the Xfree libraries from
the Darwin repository.  This is a second-class solution, since it doesn't
use the Mac OS X L&F, puts the menus in the wrong place, etc...  But it will
get you started. 

Last I heard XWindows on Aqua didn't build in GM.  It also runs only in
Rooted mode, which is a bummer...  But I am sure someone in the Darwin
community will fix these things, it seems to be a fairly active area of
development.  And if you install the Darwin versions of XWindows, you can
boot Mac OS X into the console (just use >Console as the user name) and then
type startx, and you have XWindows.  I haven't tried this myself (I am happy
with Aqua for now) but I've seen it done...

I am slowly working on a real (Carbonized) version, but I can't tell yet
when I will get something alive enough to share.

Jim

[MACTCL] Problems with stat on Mac

[Steve C. <ste...@mq...>]

The only thing stopping my application compiling now is a problem with stat in one file:

    // find out the number of records in the file by stat'ing it and
    // subtracting the size of the header
    struct stat statbuff;
    
    if( Tcl_Stat( filename, &statbuff ) != 0 ) {
      free( In->File_Data );
      SSFF_Close( In );
      return 0;
    }
    track->file_num_rec = (statbuff.st_size In->Data_Seek_Pos)/In->One_Rec_Size;
    track->file_end_time = track->file_start_time + track->file_num_rec*track->rate;

Note that originally this was a call to stat() but I replaced it with Tcl_Stat for the mac.
I've been through various troubles with stat eventually finding out that you can't include 
<fcntl.h> anywhere as it gives a duplicate definition of stat.

When compiling this I get:

Error   : illegal use of incomplete struct/union/class 'struct stat'
trackdata_ssff.cpp line 84   stat *statbuff = new stat;
Project: emu.¼, Target: Emu Shared Lib, Source File: trackdata_ssff.cpp

Error   : illegal use of incomplete struct/union/class 'struct stat'
trackdata_ssff.cpp line 91   track->file_num_rec = (statbuff->st_size 
- In->Data_Seek_Pos)/In->One_Rec_Size;
Project: emu.¼, Target: Emu Shared Lib, Source File: trackdata_ssff.cpp

I've no idea what this means or how to get rid of it.  My next step is to try to use stat
in a small program but I wondered if anyone else had any insight that might help.

Steve

[MACTCL] Tk on OS X.

[Christopher S. M. <mor...@AR...>]

Hello all,

If there is an archived thread that already addresses this question,
please feel free to let me know.  I wanted to find out about the
status/plans of a port of tk to OS X using Aqua.  Is there an effort
underway already?  If so, how might someone such as myself get more info
about contributing.

I do already know about X on X, but that is not an "elegant" solution, in
my opinion.  I personally don't want to run X, and I'd never be able to
make "install XFree86 before you run this software" a requirement for the
software I work with. 

I am in the midst of porting a CSG CAD package to OSX that is rather
integrated with Tcl/Tk.  Tk, though, being X-bound is causing my build
havoc. 

I am in the midst of uncoupling tk out of the source. Tcl, of course,
builds and runs just fine (using either Apple's libs or from source
scratch).  But in the long run, I'd like to be able to have the slew of tk
code work unscathed under aqua. 

Any comments and/or suggestions are welcome.  Cheers!

Christopher Sean Morrison
mor...@ar...

Re: [MACTCL] Compiling extensions

[Daniel A. S. <st...@ic...>]

At 13:19 +1000 on 26/3/01, Steve Cassidy wrote:

>No, it's for MathLib, which is why I thought the problem was with my rebuild
>of the 68K libraries.  Maybe this is still related to the problem you report
>though?

in that case, I'm not sure.
what is the exact error you're seeing (activate full error messages 
in CW's error window), and when does it happen, I presume at link 
time? of what target of what project?

>A related question: how much of a requirement is the provision of 68K
>libraries and executables these days in the Mac world? Aren't the 68K
>machines going back to the mid 90s with the equivalent of 486 processors? How
>much does providing these add to the size of distributed executables?

that's a good point, if you don't need the CFM68k executables, and 
can't test them on a 68k mac (CFM68k executables don't run on PPCs 
!), there is probably no point in spending time on a 68k version. 
however, in university environments, there are still a resonable 
number of 68k macs around... (steve, if you're interested, come by my 
office, I have a 68k mac here for testing purposes)

Cheers,

Daniel
-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

Re: [MACTCL] Compiling extensions

[Steve C. <ste...@mq...>]

On Monday 26 March 2001 11:16, Daniel A. Steffen wrote:
> At 0:38 +1100 on 26/3/01, Steve Cassidy wrote:
> >I followed your instructions for rebuilding the CW library but it doesn't
> >seem to have worked, now I get: Invalid PEF shared library for the 68K
> > build of my project. 
>
> I think that's a different problem, what library do you get the error
> for? I suspect ThreadsLib?
> I didn't realize that would come up, c.f. an earlier post:

No, it's for MathLib, which is why I thought the problem was with my rebuild 
of the 68K libraries.  Maybe this is still related to the problem you report 
though?

A related question: how much of a requirement is the provision of 68K 
libraries and executables these days in the Mac world? Aren't the 68K 
machines going back to the mid 90s with the equivalent of 486 processors? How 
much does providing these add to the size of distributed executables?  

Steve

Re: [MACTCL] Compiling extensions

[Daniel A. S. <st...@ic...>]

At 0:38 +1100 on 26/3/01, Steve Cassidy wrote:

>I followed your instructions for rebuilding the CW library but it doesn't
>seem to have worked, now I get: Invalid PEF shared library for the 68K build
>of my project. Maybe it would have worked if I hadn't changed MathLib since
>building your sampleextension worked fine first time -- now it gets the
>Invalid PEF too.  Do I need to reinstall CW or something?

Steve,

I think that's a different problem, what library do you get the error 
for? I suspect ThreadsLib?
I didn't realize that would come up, c.f. an earlier post:

At 23:09 +1100 8/3/01, Daniel A. Steffen wrote:
>there was an issue where Apple stub libraries that were shipped with 
>CodeWarrior Pro6 were missing CFM68k fragments, this sounds like it. 
>Is the error message referring to ThreadsLib? then that's definitely 
>the issue you're seeing.
>
>I have reported that problem to Apple and it is fixed in the latest 
>UniversalHeaders, the solution is thus to upgrade your 
>UniversalHeaders,
>you can get recent ones from e.g.
>ftp://ftp.apple.com/developer/Development_Kits/CarbonLib_1.2.5GM_SDK.img.bin
>or from http://connect.apple.com if you are an ADC member (free BTW)
>


note that in your case I wouldn't recommend replacing the full 
universal headers with the new ones, a lot of things have changed and 
you might need to fix a number of issues with CW. See the list 
archives if you want to do this, an earlier message of mine details 
the steps needed.

I would just replace the libraries that give you trouble by the newer 
ones from the CarbonSDK

Cheers,

Daniel
-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

Re: [MACTCL] Compiling extensions

[Steve C. <ste...@mq...>]

Almost there! 

 Thanks for the pointers Daniel. I realised a few things I'd done wrong 
mostly to do with not understanding the different columns in the project 
display (ie. that the column with the red circle indicated which files were 
part of that target -- now I understand why it says n/a on some lines).  I 
had in fact removed MathLib from the 68K target.

I had padgraph.r in the overall target which was probably why it had trouble 
finding Types.r. Removing it got rid of that problem.

I followed your instructions for rebuilding the CW library but it doesn't 
seem to have worked, now I get: Invalid PEF shared library for the 68K build 
of my project. Maybe it would have worked if I hadn't changed MathLib since 
building your sampleextension worked fine first time -- now it gets the 
Invalid PEF too.  Do I need to reinstall CW or something? 

On the good side, removing the 68K library from the final target gives me a 
library which works -- loads into wish first go and draws beautiful graph 
axes, plots data, draws a cursor. So, progress has been made.

Steve

Re: [MACTCL] Compiling extensions

[Daniel A. S. <st...@ic...>]

At 12:01 +1100 on 23/3/01, Steve Cassidy wrote:
>- remove the entries under sources and add in your own source files
>(*.c), say yes to all projects [[ I get a warning that at least one
>file couldn't be added here, but they look like they were??]]

note that you probably don't want to add your source files to the 
"merge" target, i.e. the target w/o  PPC or C68k in the name

>- add TkStub.lib and TkStubCFM68K.lib from Tcl/Tk:Build to the Tcl
>Library section

watch out to add these only to the appropriate targets i.e. 
TkStub.lib to PPC, TkStubCFM68K.lib to C68k

>- remove shlb files from Objects (is this right??)

no, these entries are generated automatically to match the object 
files produced by the PPC and C68k targets, to change their names, 
change names in options "PPC Target" resp "68k Target"

>- remove TkStubCFM68K.lib from the PPC project by looking under
>"Link Order" and similarly remove the TkStub.lib from the C68K project. I
>guess I shouldn't have added them to these projects in the first place.

yep, see above

>. Warning "ignored: 'exit' in MSL MWRuntimeLibCFM68K
>previously defined in MSL C.CFM68K.DLL"
>. ditto for 'abort'

normal, harmless, due to bad library design on MW's part

>. a few undefined references 'floord' 'powd' 'log10d' 'fabsd'

see below

>. Can't find system include file <Types.r> in padgraph.r
>

strange, shouldn't happen if you CW is setup properly

are you sure you have:

* system access paths include {Compiler}:MacOS Support
* your MacOS Support folder setup as follows: (the .r files are in RIncludes)
MacOS Support:
	Universal:
		Interfaces:
			AIncludes:
			CIncludes:
			ComponentIncludes:
			PInterfaces:
			RIncludes:
		Libraries:
			Classic68kLibraries:
			PPCLibraries:
			StubLibraries:


>- in the project settings for the PPC target, modify:
>  - the ppc target to padgraphPPC.shlb
>  - the prefix file under C/C++ Language to MW_padgraphHeaderPPC
>  - in the PPC PEF section, chagen the fragment name to padgraph
>

yep, see above

>- do the same for the 68K target and for the overall target (which
>merges the two libraries into a FAT one).

but given that you removed the object entries in the project, it 
probably doesn't anymore... to fix this, go into the targets panel, 
click on the disclosure triangle for your merge target and click in 
the column below the chain-link icon for both of the italicized lines 
for the PPC and 68k targets

>- added an explicit reference to the directory containing Types.r and
>SysTypes.r in the "System Paths" of both PPC and 68K projects. Gets rid
>of that error.

see above, shouldn't need to do that, but it will do the trick

>- all errors seem to be in the 68K version, do I need to explicitly
>include the 68K math library in the project (ie. more than just
>MathLib?)

no, this is due to another screwup on MW's part, I've explained the 
fix in my Tcl/Tk 8.3.2p1 distro, in the file (Pro6 Build Support):CW 
Pro6 changes, I've reproduced the relevant instructions for your 
problem below...

- in
	MacOS Support:Libraries:MacOS 
68K:MathLib68K:(Projects):MathLibCFM68K.MTarg.mcp
enable
	CFM68k->ForceIndirectAccess
for both targets and rebuild



That should do it, hope everything works now

Cheers,

Daniel
-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

Re: [MACTCL] Compiling extensions

[Steve C. <ste...@mq...>]

I've been working on moving some of my own code to the mac with partial 
success. I seem to have most things going for the PPC target but have a few 
remaining errors on the 68K target which block the build.  

Here's my log of what I did to port the code using Daniel's sample extension 
as an example.  It finishes off with the remaining error messages I'm 
getting. Any help in diagnosing this would be appreciated.  When it works 
I'll try to turn this into a readable HOWTO document. 

Steve


Attempt 2: based on Daniel's Sample Extension

- modified sample extension by moving project files into a subfolder of
the sampelextension folder, changed access paths in _all_ projects to
match

- unpack padgraph in the tcl/tk folder

- copy macprojects folder into padgraph, rename project to padgraph.pi

- copy MW_ExampleA.pch into MW_padgraph.pch, modify this to uncomment
#include <tk.h> and add any defines needed for the build (Codewarrior
doesn't support defines in the project/command line). Modify the names
of precompile_target near the top to reflect your project name.

- copy over exampleA.r which is the resource definition file to
padgraph.r and edit to fit your project

- copy over exampleA.exp to padgraph.expl, this defines exported
symbols, edit to fit your project

- open the project file (macprojects/padgraph.pi)

- remove the entries under Docs and replace with your own doc files 
(optional?)

- remove the entries under sources and add in your own source files
(*.c), say yes to all projects [[ I get a warning that at least one
file couldn't be added here, but they look like they were??]]

- remove the entries under headers and replace with your own

- replace MW_ExampleA.pch, exampleA.r and exampleA.exp with your new
versions in "Mac Specific Files"

- add TkStub.lib and TkStubCFM68K.lib from Tcl/Tk:Build to the Tcl
Library section

- remove shlb files from Objects (is this right??)

- click build 

- remove TkStubCFM68K.lib from the PPC project by looking under
"Link Order" and similarly remove the TkStub.lib from the C68K project. I
guess I shouldn't have added them to these projects in the first place.

- click build again

- I get:

. Warning "ignored: 'exit' in MSL MWRuntimeLibCFM68K
previously defined in MSL C.CFM68K.DLL" 
. ditto for 'abort'
. a few undefined references 'floord' 'powd' 'log10d' 'fabsd' 
. Can't find system include file <Types.r> in padgraph.r


- in the project settings for the PPC target, modify:
 - the ppc target to padgraphPPC.shlb
 - the prefix file under C/C++ Language to MW_padgraphHeaderPPC
 - in the PPC PEF section, chagen the fragment name to padgraph
 
- do the same for the 68K target and for the overall target (which
merges the two libraries into a FAT one).  

- build again, same errors

- added an explicit reference to the directory containing Types.r and
SysTypes.r in the "System Paths" of both PPC and 68K projects. Gets rid
of that error.

- all errors seem to be in the 68K version, do I need to explicitly
include the 68K math library in the project (ie. more than just
MathLib?)

here's the remaining errors:
--------------------------------
Link Warning : ignored: 'exit' in MSL MWRuntimeLibCFM68K
Previously defined in MSL C.CFM68K.DLL

Link Warning : ignored: 'abort' in MSL MWRuntimeLibCFM68K
Previously defined in MSL C.CFM68K.DLL

Link Error   : padgraph.c: 'fabsd' [XPointer] referenced from
'padgraph_modify' is undefined.

Link Error   : padgraph.c: 'log10d' [XPointer] referenced from
'padgraph_nicenum' is undefined.

Link Error   : padgraph.c: 'floord' [XPointer] referenced from
'padgraph_nicenum' is undefined.

Link Error   : padgraph.c: 'powd' [XPointer] referenced from
'padgraph_nicenum' is undefined.

Link Error   : padgraph.c: 'floord' [XPointer] referenced from
'padgraph_instancecmd' is undefined.
-----------------------------------------------

Re: [MACTCL] Evaluate Tcl commands from C/C++

[Jon G. <jg...@hi...>]

At 11:59 AM +0000 3/21/01, Bo Rasmusson wrote:
>Do anyone know how to evaluate a Tcl command (such as 'source') from C
>or C++?

Tcl_Eval() and its kin

-- 

   Jonathan E. Guyer
   <http://www.his.com/jguyer/>

[MACTCL] Evaluate Tcl commands from C/C++

[Bo R. <bo...@el...>]

Do anyone know how to evaluate a Tcl command (such as 'source') from C
or C++?

Thanks

Bosse

Re: [MACTCL] Compiling extensions

[Daniel A. S. <da...@us...>]

Steve,

At 10:11 +1100 on 21/3/01, Steve Cassidy wrote:

>   I've succeeded in building your example extension, thanks for putting it
>together.  I've played around a little with the origanisation of it just to
>put everything in a single directory to make it easier to move to new
>extensions. I moved the project files from the Tcl build directory to a
>subdirectory of sampleextension and modified the access paths to suit.

that's cool,  for your own extensions modifying the access paths from 
what's suggested is obviously ok.
the build directory structure as it is now was setup by jim ingham at 
some point, it's what is suggested for widely distributed extensions 
such as tclx or itcl, to make it easy for other people to use your 
projects on a different machine (i.e. access paths to tcl and tk 
include files are relative to the project, all binaries go into build 
etc...)

>In the end it would seem to be best if we could distribute just the xml
>project file in the source distribution for the extension; everything can be
>recreated from this can't it?

hopefully, although it all depends on what MW come up with in the 
next version... there have been problems before, e.g. project files 
converted properly to a new version but not the xml etc...

it doesn't cost a lot to also include the project for the 
sampleextension, so it's maybe good to leave it there just as 
insurance...

at some point in the past I proposed to move to xml files for the Tcl 
& Tk projects in the cvs server and was met with some resistance... 
for one, the xml files sure are big...

>My next step is to try to move some of my code into here! Wish me luck.

good luck indeed! hope it works out

Cheers,

Daniel
-- 
** Daniel A. Steffen                  **
** <mailto:da...@us...> **

Re: [MACTCL] Compiling extensions

[Steve C. <ste...@mq...>]

Daniel,
  I've succeeded in building your example extension, thanks for putting it 
together.  I've played around a little with the origanisation of it just to 
put everything in a single directory to make it easier to move to new 
extensions. I moved the project files from the Tcl build directory to a 
subdirectory of sampleextension and modified the access paths to suit. 

In the end it would seem to be best if we could distribute just the xml 
project file in the source distribution for the extension; everything can be 
recreated from this can't it? 

My next step is to try to move some of my code into here! Wish me luck.

Steve

[MACTCL] Re: Compiling Tcl/Tk 8.3.2p1

[Daniel A. S. <st...@ic...>]

[[ This message was both posted and mailed: see
   the "To," "Cc," and "Newsgroups" headers for details. ]]

Bo,

sorry for the delay in answering.

At 13:11 +0000 on 14/3/01, Bo Rasmusson wrote:

> I have sent this message to both the comp.lang.tcl newsgroup and to the
> sourceforge mailing list but have not received any answers yet, so I am
> sad to say that I need to bother you again thou I know you have a lot
> of work since your new assignment regarding Tcl/Tk on Mac.
> Before I ask the question I would like to point out that you are more
> than welcome to ask me any questions about UNIX systems and/or C/C++
> coding if there is anything you need to know since that is what
> I normally work with for a living.
> 
> 
> Still two compiling errors remain (the second is only due to the first)
> when I try to compile the 8.3.2p1 version of Tcl/Tk:
> 
> 1. Link Error: tclMacAppInit.c: 'InstallConsole' [Xpointer] referenced
> from 'main' is undefined.
> 
> 2. Build of target "TclShell" in project "TclShells.pi" failed because 
> a subtarget or subproject build failed.
> 
> So I looked at the tclMacAppInit.c file and came to the conclusion that
> the error reside from the SIOUX.c file I changed as requested in the
> README file. I then tried to recompile the shlib's by compiling the
> target "Build All" of the project "Build.MacOS.mcp" in CW Pro 6 and I
> managed to get 3644 errors.
> 3600 of these errors where in the "fp68k_glue.c" file, 6 errors in the
> "CFString.h" file, 1 error in the "CGlue.c" file, 16 errors in the
> "SIOUX.c" file, 4 errors in the "SIOUXWindows.c" file and finally 17
> errors in the "UTBAccessors.h" file.
> 
> Since I have not changed anything in CW Pro 6 except what is said in the
> README file about changes to CW, I am starting to wounder if there is
> something wrong with my installed CW. Any suggestions?
> 

These are really all Metrowerks specific issues you are seeing, you
should try also raising similar problems on
comp.sys.mac.programmer.codewarrior in the future, Metrowerks is
monitoring that forum and may get prompted to update/fix their #%@*
code if enough people are complaining.

Your "InstallConsole" related link error is due to a Metrowerks bug
introduced with Pro6 that necessitates rebuilding the MSL libraries.
(as detailed in the "CW Pro6 changes" document from the MacTcl/Tk
8.3.2p1 distribution)
The "subproject build failed" error is a direct consequence of this
first problem.

Now, all the build errors you get from Build.MacOS.mcp are due to
slight changes that Apple made to the universal interfaces 3.4 series
that cause trouble with CodeWarrior library sources. If you had rebuilt
the libraries before updating your universal interfaces to 3.4 to build
Tcl/Tk 8.3.2p1, you would not have seen any of these problems.

When using the latest UniversalInterfaces3.4b5.img available from
Apple, in addition to what is mentioned in "CW Pro6 changes", I had to
change the following to get "Build All"  of Build.MacOS.mcp to build
without errors:

CGlue.c:

   * change the line

   Boolean lclick(Point *pt, short modifiers, ListHandle lHandle)
   
   to

   Boolean lclick(Point *pt, EventModifiers modifiers, ListHandle
lHandle)

PLStringFuncsGlue.mcp:

   * add {Compiler}:MSL to AccessPaths->SystemPaths in all targets

fp68k_glue.c:

   * Add the following lines to the top of this file:

   #include <ConditionalMacros.h>
   #undef TYPE_LONGDOUBLE_IS_DOUBLE
   #define TYPE_LONGDOUBLE_IS_DOUBLE 0

SIOUX.c:

   * change all occurrences of

   NewAEEventHandlerProc

   to

   NewAEEventHandlerUPP

   * change all occurrences of

   UInt32 refCon

   to

   long refCon

SIOUXWindows.c:

   * change all occurrences of

   NewControlActionProc
   
   to

   NewControlActionUPP

UTBAccessors.h:

   * comment out the lines defining

   GetWindowPortBounds
   GetWindowList
   GetWindowFromPor


With these changes applied, Build.MacOS.mcp builds without errors here.

If Apple make more changes to the 3.4 UniversalInterfaces in the future
(they are close to releasing a final 3.4 though), similar problems may
crop up, but they are generally not hard to fix if you read the
compiler error messages carefully.

> By the way. The reason I am trying to compile the source version of
> Tcl/Tk is because one of our Tcl/Tk programmer want me to help him to
> patch his software to the Mac (he is single handidly doing a smaller
> software for the IRIX, Windows and Mac platforms). He wants to have
> more or less a single executable and his source code hidden (for ex.
> encrypted or equal), so he told me that I needed to compile the source
> version of Tcl/Tk for Mac and then wrap up his code. Since neither I or
> he have any experiance with the Mac do you think this is the right way
> of doing it?

it depends highly on how he plans to wrap his code. if he uses some
custom method of encrypting in c or tcl, it may work on the mac, I
don't quite see why you would need to recompile Tcl/Tk for that though.

you should know that tclpro is not available on the mac at this time,
and other code wrapping/VFS type solutions are not as far along as on
the other platforms.
tclkit IS available for the mac, although I have no experience using it
on the mac myself.

certainly one solution I can imagine would be to include  a tcl
encryption script in the Wish resources (a la what drag & drop tclet
does) and get that script to read & decrypt your encrypted code from
the resources as well.
see the docs for the  -rsrc option to source and the mac specific
resource command for more on that.

you might want to consult the c.l.t archives and the MACTCL archives
for more on these subjects, they have come up in the past.

Hope this helps

Cheers,

Daniel