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

[MACTCL] [Q] TclShell 8.3.2

[Eric G. <er...@co...>]

I downloaded the TCL/TK 8.3.2 release and saw the HTTP package. 
However, when I go to run the shell and try to type in http::geturl 
it tells me:

   invalid command name "http::geturl"

So, I'm assuming that either (1) it's not installed properly or (2) 
I'm calling it incorrectly.

What do I need to do?

Also, when I try to run TclBOAShell 8.3.2, it tells me that I am 
missing the bgscript.tcl file. Where can I find one or how do I make 
one of these?

Thanks.

-- 
== Eric Gorr ===== http://home.cox.rr.com/ericgorr ===== ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

[MACTCL] general question: MacTCL, Tix

[Jason A.P. de K. <ap...@al...>]

Hello MacTCLers,  Can anyone provide some general insight into the =
maturity of the MacTCL project?  I'd like to embark on a multiplatform =
development project using Tix/TclTk for GUI, and C/C++ for core coding.  =
Has anyone built Tix (or some other widget library) on the Mac?  Are =
standard Tcl/Tk projects typically directly portable to MacTcl?  Can =
compact executables (sensu embedded Tcl/Tk) be built for the Mac?

Any opinions or information would be greatly appreciated.  Thanks,
- Jason


_________________________________________________________________________=
_
 A.P. Jason de Koning, Doctoral student        Email: =
ap...@cs...
   Department of Biological Sciences             Lab:  (518) 442-4347
   University at Albany, SUNY                    FAX:  (518) 442-4767
   1400 Washington Ave., Albany NY 12222, USA   Home:  (518) 445-6309
_________________________________________________________________________=
_

[MACTCL] RE: [TCLCORE] Re: [TCT] Call for maintainers

[Jeff H. <je...@Ac...>]

> As a busy mac-centric person I'm not that interested in maintaining 
> anything besides the mac code anyway, so I'm not terribly happy with 
> the distribution of mac code among so many functional areas in TIP 
> 16, when it's quite likely that a lot of the maintainers are not 
> going to have a mac with the latest compilers and are not going to be 
> able to build and test the mac sources they are maintaining.

Nothing is ever set in stone.  If somehow the maintenance of areas
along the lines in TIP 16 becomes burdensome for one or more reasons,
we can always adjust them then.

> Is there some concept of platform release managers planned? is there 
> somebody among the maintainers or the TCT who will be responsible for 
> building binary distributions? (I suppose I could volunteer for 
> building the mac distribution if needed)

I'll consider you volunteered then.  I'm the release manager for
8.3/4 (no other versions have yet been planned for enough for a
release manager).  I of course don't have a mac, but nor do I have
as many platforms available to me as it would be nice to have
binaries for.  Part of the RMs responsibility will be to work with
others who have those platforms to get a concerted, correct release
out in a timely manner.

BTW, think 8.3.3 for the short term (like within a month).

Jeff

[MACTCL] Re: [TCLCORE] Re: [TCT] Call for maintainers

[Jim I. <ji...@ap...>]

Yeah, this is going to take a little creative work to allow us to work 
on the Mac, and not get even more buried than we are already.  I have on 
my slate to rework the Tk arrangements to allow this to go a little more 
straightforwardly.  I will try to get this done this week, and update 
the TIP 23 to reflect this.  Sorry for the delay, but I am kind of 
swamped with stuff related to Mac OS X right now...

Anyway, I am volunteering to work with Daniel on the Mac code for Tcl.  
It would be really great if Daniel will take over doing the releases!  
We do need to work out how to distribute responsibility for builds too, 
though this will get more interesting as the BI distro process gets 
further along...

Jim


On Wednesday, February 14, 2001, at 08:56 PM, Daniel A. Steffen wrote:

> Finally getting to this, sorry for the delay.
>
> I'm volunteering for the two 'Macintosh Stuff' areas and generally as a 
> helping hand for any file in the mac/ subdirectory.
>
> The plan is to co-maintain the mac sources with Jim Ingham, I had 
> informally agreed with him a while back to help out with mac code in 
> Tcl and Tk and to officially volunteer once the call comes. I've been 
> looking into mac specific issues in tcl and tk for some time now while 
> working on Alpha and have recently done the mac 8.3.2 binary release 
> with Jim's ok.
>
> While a number of other functional areas in TIP 16 (I count 12) contain 
> mac code, I don't feel I have the know-how or the time to take on the 
> other platform's code that come alongside with it.
>
> As a busy mac-centric person I'm not that interested in maintaining 
> anything besides the mac code anyway, so I'm not terribly happy with 
> the distribution of mac code among so many functional areas in TIP 16, 
> when it's quite likely that a lot of the maintainers are not going to 
> have a mac with the latest compilers and are not going to be able to 
> build and test the mac sources they are maintaining.
>
> I think Jim made a similar point a while back already about Tk and TIP 
> 23.
> Anyway it's probably too late for me to complain about TIP 16 now, and 
> TIP 23 looks a bit better in that respect, but I fear the whole mac 
> sources situation is going to be somewhat of an organizational 
> challenge.
>
> Is there some concept of platform release managers planned? is there 
> somebody among the maintainers or the TCT who will be responsible for 
> building binary distributions? (I suppose I could volunteer for 
> building the mac distribution if needed)
>
> Cheers,
>
> Daniel
>
> da...@us...
>
> ---------------------------------------------------------------------------
>
>
> I'm still working (slowly) on a precise writeup of my changes to 8.3.2 
> and 8.4, but just to illustrate my point, my current patch for Tcl 8.4 
> TOT for the mac touches the following files:
>
> generic/tcl.h
> generic/tclInt.decls
> generic/tclMain.c
> generic/tclStubInit.c
> mac/MW_TclAppleScriptHeader.pch
> mac/MW_TclHeader.pch
> mac/MW_TclTestHeader.pch
> mac/tclMac.h
> mac/tclMacAppInit.c
> mac/tclMacApplication.r
> mac/tclMacChan.c
> mac/tclMacCommonPch.h
> mac/tclMacFCmd.c
> mac/tclMacInt.h
> mac/tclMacLibrary.c
> mac/tclMacLibrary.r
> mac/tclMacMath.h
> mac/tclMacNotify.c
> mac/tclMacOSA.c
> mac/tclMacOSA.r
> mac/tclMacPanic.c
> mac/tclMacPort.h
> mac/tclMacProjects.sea.hqx
> mac/tclMacResource.r
> mac/tclMacSock.c
> mac/tclMacThrd.c
> mac/tclMacUnix.c
> mac/tclMacUtil.c
>
> see http://www.maths.mq.edu.au/~steffen/tcltk/ for the diffs and new 
> files in a preliminary state (not 100% fresh anymore but they should 
> give you an idea if you're interested).
>
> while most of the changes are in tcl/mac, these files actually affect 
> all of the following functional units:
>
> Events:			_Notifier_
> Channels:		_Built-in Channel Types_
> Threads:
> File System:		_File System Access_
> Embedding Support:
> Release Engineering:	_Portability Support_
> Macintosh Stuff:	_[resource]_
> Macintosh Stuff:	_Mac-Specific Files_
> SHARED FILES
>
> this is certainly not a typical patch, as I have changed a fair number 
> of things in the mac build support that affect a lot of files (e.g. new 
> compiler, shared runtime libraries, removed the need for 
> OLDROUTINENAMES for Apple's headers, DLLEXPORT & DLLIMPORT now work as 
> on Win32, fix for encoding problem due to bug in MacCVS Pro and more) 
> which explains partially why so many files are involved but even so, 
> too many generic functional areas are touched for mac only changes IMHO.
>
> same analysis for my tk patches:
>
> generic/tkInt.decls
> generic/tkIntPlatDecls.h
> generic/tkPointer.c
> mac/MW_TkHeader.pch
> mac/MW_TkOldImgHeader.h
> mac/MW_TkTestHeader.pch
> mac/tclets.r
> mac/tkMac.h
> mac/tkMacAppearanceStubs.c
> mac/tkMacApplication.r
> mac/tkMacButton.c
> mac/tkMacFont.c
> mac/tkMacInt.h
> mac/tkMacLibrary.r
> mac/tkMacMDEF.r
> mac/tkMacMenu.c
> mac/tkMacMenus.c
> mac/tkMacPort.h
> mac/tkMacProjects.sea.hqx
> mac/tkMacResource.r
> mac/tkMacScrlbr.c
> mac/tkMacWindowMgr.c
> mac/tkMacWm.c
>
> which touch the following TIP 23 areas:
>
> Low-level Tk functions: _Basic window manipulations_
> Low-level Tk functions: _Macintosh window operations_
> Widgets: _button, checkbutton, radiobutton, label_
> Widgets: _menu, etc. (Macintosh)_
> Widgets: _scrollbar_
> Release Engineering:_Macintosh Configuration and Build Tools_
> Shells:_Drag and Drop Tclets (Macintosh)_
> Fonts:_Macintosh font support_
> SHARED FILES
>
> so things are a fair bit better for Tk, most heavily affected areas are 
> mac specific.
>
> -- ** 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/>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> http://lists.sourceforge.net/lists/listinfo/tcl-core

[MACTCL] Re: [TCT] Call for maintainers

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

Finally getting to this, sorry for the delay.

I'm volunteering for the two 'Macintosh Stuff' areas and generally as 
a helping hand for any file in the mac/ subdirectory.

The plan is to co-maintain the mac sources with Jim Ingham, I had 
informally agreed with him a while back to help out with mac code in 
Tcl and Tk and to officially volunteer once the call comes. I've been 
looking into mac specific issues in tcl and tk for some time now 
while working on Alpha and have recently done the mac 8.3.2 binary 
release with Jim's ok.

While a number of other functional areas in TIP 16 (I count 12) 
contain mac code, I don't feel I have the know-how or the time to 
take on the other platform's code that come alongside with it.

As a busy mac-centric person I'm not that interested in maintaining 
anything besides the mac code anyway, so I'm not terribly happy with 
the distribution of mac code among so many functional areas in TIP 
16, when it's quite likely that a lot of the maintainers are not 
going to have a mac with the latest compilers and are not going to be 
able to build and test the mac sources they are maintaining.

I think Jim made a similar point a while back already about Tk and TIP 23.
Anyway it's probably too late for me to complain about TIP 16 now, 
and TIP 23 looks a bit better in that respect, but I fear the whole 
mac sources situation is going to be somewhat of an organizational 
challenge.

Is there some concept of platform release managers planned? is there 
somebody among the maintainers or the TCT who will be responsible for 
building binary distributions? (I suppose I could volunteer for 
building the mac distribution if needed)

Cheers,

Daniel

da...@us...

---------------------------------------------------------------------------


I'm still working (slowly) on a precise writeup of my changes to 
8.3.2 and 8.4, but just to illustrate my point, my current patch for 
Tcl 8.4 TOT for the mac touches the following files:

generic/tcl.h
generic/tclInt.decls
generic/tclMain.c
generic/tclStubInit.c
mac/MW_TclAppleScriptHeader.pch
mac/MW_TclHeader.pch
mac/MW_TclTestHeader.pch
mac/tclMac.h
mac/tclMacAppInit.c
mac/tclMacApplication.r
mac/tclMacChan.c
mac/tclMacCommonPch.h
mac/tclMacFCmd.c
mac/tclMacInt.h
mac/tclMacLibrary.c
mac/tclMacLibrary.r
mac/tclMacMath.h
mac/tclMacNotify.c
mac/tclMacOSA.c
mac/tclMacOSA.r
mac/tclMacPanic.c
mac/tclMacPort.h
mac/tclMacProjects.sea.hqx
mac/tclMacResource.r
mac/tclMacSock.c
mac/tclMacThrd.c
mac/tclMacUnix.c
mac/tclMacUtil.c

see http://www.maths.mq.edu.au/~steffen/tcltk/ for the diffs and new 
files in a preliminary state (not 100% fresh anymore but they should 
give you an idea if you're interested).

while most of the changes are in tcl/mac, these files actually affect 
all of the following functional units:

Events:			_Notifier_
Channels:		_Built-in Channel Types_
Threads:
File System:		_File System Access_
Embedding Support:
Release Engineering:	_Portability Support_
Macintosh Stuff:	_[resource]_
Macintosh Stuff:	_Mac-Specific Files_
SHARED FILES

this is certainly not a typical patch, as I have changed a fair 
number of things in the mac build support that affect a lot of files 
(e.g. new compiler, shared runtime libraries, removed the need for 
OLDROUTINENAMES for Apple's headers, DLLEXPORT & DLLIMPORT now work 
as on Win32, fix for encoding problem due to bug in MacCVS Pro and 
more) which explains partially why so many files are involved but 
even so, too many generic functional areas are touched for mac only 
changes IMHO.

same analysis for my tk patches:

generic/tkInt.decls
generic/tkIntPlatDecls.h
generic/tkPointer.c
mac/MW_TkHeader.pch
mac/MW_TkOldImgHeader.h
mac/MW_TkTestHeader.pch
mac/tclets.r
mac/tkMac.h
mac/tkMacAppearanceStubs.c
mac/tkMacApplication.r
mac/tkMacButton.c
mac/tkMacFont.c
mac/tkMacInt.h
mac/tkMacLibrary.r
mac/tkMacMDEF.r
mac/tkMacMenu.c
mac/tkMacMenus.c
mac/tkMacPort.h
mac/tkMacProjects.sea.hqx
mac/tkMacResource.r
mac/tkMacScrlbr.c
mac/tkMacWindowMgr.c
mac/tkMacWm.c

which touch the following TIP 23 areas:

Low-level Tk functions: _Basic window manipulations_
Low-level Tk functions: _Macintosh window operations_
Widgets: _button, checkbutton, radiobutton, label_
Widgets: _menu, etc. (Macintosh)_
Widgets: _scrollbar_
Release Engineering:_Macintosh Configuration and Build Tools_
Shells:_Drag and Drop Tclets (Macintosh)_
Fonts:_Macintosh font support_
SHARED FILES

so things are a fair bit better for Tk, most heavily affected areas 
are mac specific.

-- 
** 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] Re. info script bug

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

At 17:47 +0200 on 10/2/01, Mats Bengtsson wrote:

>Since I posted the bug, I can fill in some more. Actually, I tried
>to dig into it a few days ago:
>
>[info script] just returns the value in 'interp->scriptFile'.
>scriptFile is initially set to NULL, but in Tcl_EvalFile(..., fileName),
>scriptFile = fileName, and then the fileName is sourced in and evaluated.
>When finished, scriptFile is set to the value it had before.
>The source command actually calls Tcl_EvalFile(..., fileName).
>(in tclCmdMZ.c file)
>When doing source from the console, everything seems to work alright.
>
>However, the source from the menu command calls the 'SourceDialog()'
>function in tk/mac/tkMacMenus.c file, and the SourceDialog() function first
>calls Tcl_Eval("tk_getOpenFile") then Tcl_EvalFile(..., fileName).
>
>Note that the script based console in tk/library/console.tcl seems to
>work Ok,
>at least if you just evaluate the script associated with the source menu.
>This method is not used in the current version of MacTk.
>
>I don't understand what is going wrong here, but this is the flow of calls.

I had a look today and couldn' figure it out either from looking at 
the code, the only thing I could think of is that somehow the second 
Tcl_Eval* in SourceDialog ends up not setting scriptFile correctly. 
(why?)
I'll try stepping through the code with the debugger next week when I 
find some time.

-- 
** 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. info script bug

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

Since I posted the bug, I can fill in some more. Actually, I tried
to dig into it a few days ago:

[info script] just returns the value in 'interp->scriptFile'.
scriptFile is initially set to NULL, but in Tcl_EvalFile(..., fileName),
scriptFile = fileName, and then the fileName is sourced in and evaluated.
When finished, scriptFile is set to the value it had before.
The source command actually calls Tcl_EvalFile(..., fileName).
(in tclCmdMZ.c file)
When doing source from the console, everything seems to work alright.

However, the source from the menu command calls the 'SourceDialog()'
function in tk/mac/tkMacMenus.c file, and the SourceDialog() function first
calls Tcl_Eval("tk_getOpenFile") then Tcl_EvalFile(..., fileName).

Note that the script based console in tk/library/console.tcl seems to
work Ok,
at least if you just evaluate the script associated with the source menu.
This method is not used in the current version of MacTk.

I don't understand what is going wrong here, but this is the flow of calls.

Mats

Re: [MACTCL] info script question

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

At 15:36 +0100 on 9/2/01, Gert Kok wrote:

>When sourceing a file into wish (8.3.2p1), sometimes [info script] returns
>the pathname of the script, sometimes only a colon :
>Should it be my mistake, or maybe
>system info that gets corrupted (after one of my mistakes)
>or a problem with wish?
>
>As far as I tested, I see at succes after a fresh reboot, after a first
>start of wish. After one or more times getting a colon, I may get the valid
>pathname.
>Doing nothing special inbetween the attempts.

this is a known bug, see:

https://sourceforge.net/bugs/?func=detailbug&bug_id=122990&group_id=10894

you should add your observations there

At 21:13 +0100 9/2/01, Gert Kok wrote:
>[info script] does not always return the requested path.
>
>It depends on which window is active, when 'source' frome the file-menu is
>selected.
>
>When 'Wish' is active, [info script] returns nothing, maybe a colon
>
>When 'Console' is active, [info script] returns the name of the sourced
>script.

does this correspond with what's already listed on the bug page above?

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] Wish 8.3.2 [info script] Found out when it goes wrong

[Gert K. <qa...@ch...>]

[info script] does not always return the requested path.

It depends on which window is active, when 'source' frome the file-menu is 
selected.

When 'Wish' is active, [info script] returns nothing, maybe a colon

When 'Console' is active, [info script] returns the name of the sourced 
script.


BTW what is the simplest way to have the 'Wish' window opened besides the 
Console, not on top of it?


Gert Kok

[MACTCL] <Correction!> [TCT] Call for maintainers

[Andreas K. <a.k...@we...>]

> People who are interested in taking up maintainership should send an
> email to Tclcore <tcl...@li...> until the end of
> February.

The correct email address of tclcore is, of course,

	<tcl...@li...>
                                    ~~~
-- 
With sincerest apologies,
	Andreas Kupries <a.k...@we...>
		<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: [MACTCL] [file join] newbie question

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

At 2:06 PM +0100 2/9/01, Gert Kok wrote:
>Is it normal that ":a:b:c" is the result of
>file join a b c
>?
>So if a is the name of the disk, the first ':' has to be removed in an
>extra step?

Yes it's normal and no that's not how you do it. If the first element 
is a volume name, it must end with ':'

file join a: b c

-- 

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

[MACTCL] info script question

[Gert K. <qa...@ch...>]

When sourceing a file into wish (8.3.2p1), sometimes [info script] returns 
the pathname of the script, sometimes only a colon :
Should it be my mistake, or maybe 
system info that gets corrupted (after one of my mistakes)
or a problem with wish?

As far as I tested, I see at succes after a fresh reboot, after a first 
start of wish. After one or more times getting a colon, I may get the valid 
pathname.
Doing nothing special inbetween the attempts.

Gert Kok

[MACTCL] [file join] newbie question

[Gert K. <qa...@ch...>]

Is it normal that ":a:b:c" is the result of
file join a b c 
?
So if a is the name of the disk, the first ':' has to be removed in an 
extra step?

Gert Kok

[MACTCL] [TCT] Call for maintainers

[Andreas K. <a.k...@we...>]

Hello and welcome.

One of the things the TCT recently discussed was the division of the
core into functional areas (-> TIP 16 [x]). As this task is completed
we are now in search of people who are willing to maintain / take
responsibility for (at least) one of these functional areas. People
with an interest in Tk should note that an analogous TIP is in
preparation and discussion (TIP 23 [%]). Their feedback is welcome.

Knowledge of the core in the chosen area is a bonus but not required.
A willingness to aquire such knowledge is required, as is enough
volunteer time, i.e. at least a few hours per week.

The tasks of a maintainer include:

*	Tracking, evaluation and fixing bugs [/] falling into the
	chosen functional area.

*	Tracking, evaluation and application of patches [*] falling
	into the chosen functional area.

When bugs and patches touch upon more than one functional area, the
maintainers for all affected areas coordinate their activities. The
same holds true if we get more than one maintainer for a functional
area. If maintainers get deadlocked about an issue the TCT will step
in and break the deadlock.

Maintainers are also responsible for insuring that contributions can
be included into the Tcl sources under the current Tcl license. This
mostly means that if the contributor works on Tcl on his employer's
time, you should make sure that releasing the contribution under the
Tcl license is all right with the employer.

People who are interested in taking up maintainership should send an
email to Tclcore <tcl...@li...> until the end of
February.

~~~
[x] -- http://www.scriptics.com:8080/cgi-bin/tct/tip/16.html --
[%] -- http://www.scriptics.com:8080/cgi-bin/tct/tip/23.html --
[/] -- http://sourceforge.net/bugs/?group_id=10894 --
[*] -- http://sourceforge.net/patch/?group_id=10894 --

-- 
Sincerely,
	Andreas Kupries <a.k...@we...>
	(for the TCT)
-------------------------------------------------------------------------------