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

[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)
-------------------------------------------------------------------------------