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

Re: [MACTCL] OS X tcl/tk installation

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

Sean,

I agree, packages are definitely the way to go.  I haven't played around
with PackageMaker yet, but it does look pretty straightforward.  One really
convenient way to set this up would be to add a shell script build phase to
the Tk makefile that takes the Tcl & Tk frameworks, and the Wish App that
have just been built, and makes up a package out of them.  Even though Tcl
is a separate project, I think it is okay to assume it is built the same
buildroot as Tk, since otherwise the debugger won't work, etc...

We could have the shell script only trigger when some environment variable
is set, and set that only in the Development build style.  The other way to
do this is to do it on install only, but that means you have to run
pbxbuild, right now, which is kind of hacky...  This is a known PB bug,
BTW...

This would be quite convenient.  If you already know how to do this, and are
interested, I would happily take a patch or two :-)  Otherwise, I will get
to it sometime - but probably later...

Jim

> 
> 
> The basics of getting a .pkg set up is quite simple and I'd highly
> recommend it.  You can easily set up the installation script that was
> given to be auto-executed on installation.  I'll see if I can find my
> notes on the subject, but it goes something like this:
> 
> 1) Create a README* file (* can be txt, rtf, rtfd, etc)
> 2) Create a LICENSE* file
> 3) Put the readme, license, and optional install scripts into a directory
> by themselves (This is the Resource directory)
> 4) Create an install tree that has what you want where you want it to go
> (This is the PackageRoot -- this may be empty, though not recommended)
> 5) Run PackageMaker (in the devTools) and point the PackageRoot and
> Resource directory to where they need to be, and build the package
> 
> There is a checkmark for whether admin access is required and whether
> there to require affirmation of the license, among a few other options.
> 
> Once done, PackageMaker will automagically generate the .pkg installer for
> you.
> 
> Throw that .pkg into a read-only .dmg with the readme and you are set to
> deliver a thoughtless/full install.
> 
> As a side note, as I mentioned, you don't have to give the PackageRoot.
> The tar.gz could be a resource that is installed by a hook script.  There
> are four scripts that are optionally run, if they exist, on upgrade and/or
> install.  You can have a script that runs before installation, and one
> that runs after.
> 
> Like I said, I'll see if I can get my notes on this.  It really is pretty
> simple, and elegant, but a concrete example would get the idea across much
> better. 
> 
> Cheers!
> 
> Sean
> 

-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb

Re: [MACTCL] tk/OS X event handling?

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

On 3/4/02 7:44 AM, "Jack Jansen" <Jac...@or...> wrote:

> 
> On Monday, March 4, 2002, at 03:41 , Joe Laszlo wrote:
> 
>> I had the same problems ((Tcl/Tk and GLUT event loops colliding) with
>> Mac OS 9 when I tried porting the same app. there and eventually gave
>> up.  I'm sure it could have been done by modifying both Tcl/Tk and
>> GLUT, but it was just too much effort.
> 
> On Mac OS 9 (with the Classic event manager) it is pretty much
> impossible without the cooperation of the various packages: one of the
> packages will be running ther current event loop with WaitNextEvent and
> it will get all events. If it gets events for windows it doesn't know
> about it has little option but dropping them on the floor.
> 
> With the new Carbon Events things are much brighter. The event loop is
> out of your own control (probably in CarbonLib in OS9 and maybe even
> deeper down in the system on OSX, but this is guesswork) and you
> subscribe to specific events on specific objects. So, all should have
> been hunky dory.
> 
> But (and I'm paraphrasing Jim here, or actually my memory of what he
> said) while this routing all works fine for system generated events it
> breaks down if you want to modify events on the fly. Theoretically you
> can subscribe to a lowlevel event (say, "mouse button 3 press"), convert
> that to something else (say, "mouse button 1 double click") and
> re-insert that in the flow of things. But this apparently doesn't work,
> and Tk needs it. So, Tk has an "old-fashioned" event loop where it
> simply grabs all events and does the dispatching itself. So, foreign
> windows break:-(

There are a couple of different problems here.  One is how to farm some
events off to foreign windows, while retaining all the ones Tk cares about
for itself.  The other is how to give another part of the App control of the
event loop itself some or all of the time.

First, if all we needed to do was send events that belong to a non-Tk window
in the app, that is pretty easy.  We CAN use the Carbon Event system and
just forward events on whatever Carbon Event handler is registered with the
other windows.  That part is fine - and in fact we already do this for the
Nav Services windows that you create with tk_getOpenFile, etc.

As an aside, the problem with Carbon Events was when we tried to use the
Carbon event default handlers to get some behaviors (like generic Window
level behaviors - the title buttons, titlebar dragging, etc).  The problem
with this was that these behaviors are implemented by converting a low-level
event to a synthetic event.  But the synthetic event behavior was odd.
First off, the synthetic events were never posted to the event queue, they
were directly handled.  This really messes Tk up, because Tk's model is that
all native events are converted to Tk events, put on Tk's queue, and then
multiplexed with all the other events that Tk wants to handle back at the
event loop level.  Having 3 or 4 events generated and handled on the stack
sequentially - before we could get back to the Tk event dispatcher -  got
really nasty.  The other problem was that some of the window behaviors were
implemented by NOT handling an event, but by just modifying the event
parameters and sending it on.  This didn't fit the Tk model at all...

So we use don't use any of the standard Carbon Event handlers.  But that
doesn't mean that we can't dispatch events as Carbon events to other
handlers.

The part that I am unsure about is what to do with extensions or other apps
that want to run the event loop themselves.  One solution here is to not use
the Tk notifier, but let the App feed events to Tcl.  This means the app
would have to spin the Tcl part of the notifier (which happens on a separate
thread) and then use the lower level primitives - Tcl_DoOneEvent without
allowing it to wait - every so often to handle events.  I think that we
would have to make some private API's public so you could tell whether Tcl
had handled an event at all.

This would work, and I think the code is pretty well set up to allow you to
do this, though there are some necessary API's that are now private that we
would have to make public...  This is actually the way that sharing the
event loop worked in the Xt case, IIRC.  But this means that

But if you want to use the standard Wish, but need to modally spin the event
loop yourself sometimes, we will have to do some more work to allow this.  I
think this is what Mats' QuickTimeTcl extension needs.  I am less certain
how to do this.  This is an area where somebody just needs to play around a
bit with a concrete example and see what works.

> 
> But please note that all this explaining is based on memory of a
> conversation, not on actual experiments yet, so take it with a grain of
> salt.

Pretty good for a 4 or 5 month old email exchange!

Jim
-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb

RE: [MACTCL] tk/OS X event handling?

[macnerd <ma...@re...>]

Perhaps we can make a main event dispather that can handle all of this,
and perhaps chuck it into a library.  Maybe like a mini-kernel, like the
Opera folks do.  We can then chuck this into a library and run off of
that.  Thus, wheter classic, cfm68k, mix-mode nightmare, carbon, the 
library does its thing and gives us the control we need.

 - Joaquin

-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...]On Behalf Of Jack Jansen
Sent: Monday, March 04, 2002 7:45 AM
To: Joe Laszlo
Cc: tc...@li...
Subject: Re: [MACTCL] tk/OS X event handling?



On Monday, March 4, 2002, at 03:41 , Joe Laszlo wrote:

> I had the same problems ((Tcl/Tk and GLUT event loops colliding) with 
> Mac OS 9 when I tried porting the same app. there and eventually gave 
> up.  I'm sure it could have been done by modifying both Tcl/Tk and 
> GLUT, but it was just too much effort.

On Mac OS 9 (with the Classic event manager) it is pretty much 
impossible without the cooperation of the various packages: one of the 
packages will be running ther current event loop with WaitNextEvent and 
it will get all events. If it gets events for windows it doesn't know 
about it has little option but dropping them on the floor.

With the new Carbon Events things are much brighter. The event loop is 
out of your own control (probably in CarbonLib in OS9 and maybe even 
deeper down in the system on OSX, but this is guesswork) and you 
subscribe to specific events on specific objects. So, all should have 
been hunky dory.

But (and I'm paraphrasing Jim here, or actually my memory of what he 
said) while this routing all works fine for system generated events it 
breaks down if you want to modify events on the fly. Theoretically you 
can subscribe to a lowlevel event (say, "mouse button 3 press"), convert 
that to something else (say, "mouse button 1 double click") and 
re-insert that in the flow of things. But this apparently doesn't work, 
and Tk needs it. So, Tk has an "old-fashioned" event loop where it 
simply grabs all events and does the dispatching itself. So, foreign 
windows break:-(

But please note that all this explaining is based on memory of a 
conversation, not on actual experiments yet, so take it with a grain of 
salt.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -
>>
>


_______________________________________________
Tcl-mac mailing list
Tc...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] tk/OS X event handling?

[Jack J. <Jac...@or...>]

On Monday, March 4, 2002, at 03:41 , Joe Laszlo wrote:

> I had the same problems ((Tcl/Tk and GLUT event loops colliding) with 
> Mac OS 9 when I tried porting the same app. there and eventually gave 
> up.  I'm sure it could have been done by modifying both Tcl/Tk and 
> GLUT, but it was just too much effort.

On Mac OS 9 (with the Classic event manager) it is pretty much 
impossible without the cooperation of the various packages: one of the 
packages will be running ther current event loop with WaitNextEvent and 
it will get all events. If it gets events for windows it doesn't know 
about it has little option but dropping them on the floor.

With the new Carbon Events things are much brighter. The event loop is 
out of your own control (probably in CarbonLib in OS9 and maybe even 
deeper down in the system on OSX, but this is guesswork) and you 
subscribe to specific events on specific objects. So, all should have 
been hunky dory.

But (and I'm paraphrasing Jim here, or actually my memory of what he 
said) while this routing all works fine for system generated events it 
breaks down if you want to modify events on the fly. Theoretically you 
can subscribe to a lowlevel event (say, "mouse button 3 press"), convert 
that to something else (say, "mouse button 1 double click") and 
re-insert that in the flow of things. But this apparently doesn't work, 
and Tk needs it. So, Tk has an "old-fashioned" event loop where it 
simply grabs all events and does the dispatching itself. So, foreign 
windows break:-(

But please note that all this explaining is based on memory of a 
conversation, not on actual experiments yet, so take it with a grain of 
salt.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -
>>
>

Re: [MACTCL] tk/OS X event handling?

[Joe L. <jfl...@dg...>]

Thanks for the response.

I thought I'd seen some discussion like this on the tcl-mac list 
recently but was unable to find it when I looked.  I'll check again.

I had the same problems ((Tcl/Tk and GLUT event loops colliding) with 
Mac OS 9 when I tried porting the same app. there and eventually gave 
up.  I'm sure it could have been done by modifying both Tcl/Tk and GLUT, 
but it was just too much effort.

It's frustrating that it seems to be pretty straightforward on other 
platforms.  I was hoping that Mac OS X would be better in this regard.

Any additional thoughts on how to do "the right thing" and/or possible 
work-arounds by someone who understands Tcl/Tk's event handling details 
would be welcome.

Does anyone know if it's even possible to design a framework that has 
this non-interference property on Mac OS X (with all the various 
possible framework types - Cocoa, Carbon, etc.)?

Joe.


On Monday, March 4, 2002, at 06:53  AM, Jack Jansen wrote:

>
> On Sunday, March 3, 2002, at 07:00 , Joe Laszlo wrote:
>
>>
>> Is there a way to get Tk on Mac OS X to handle only its own events
>> and leave other events to whoever else might handle them?
>
> I second this request. Jim explained to me (or to the list?) in the 
> past that there were problems with this due to the way Carbon Events 
> does the forwarding of events, but for the Tkinter/Python combination 
> it is also going to be of prime importance once the Python IDE is up 
> and running. On MacOS9 the Python IDE and Tkinter have never been able 
> to work together due to event loop entanglement, it would be sad if the 
> same were true on OSX, where Carbon Events do most of the work for us 
> already.
> --
> - Jack Jansen        <Jac...@or...>        
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma 
> Goldman -
>

Re: [MACTCL] Setting environment vars from tcl

[James B. <jk...@mr...>]

On Fri, Mar 01, 2002 at 11:03:37AM -0800, Jim Ingham wrote:
> Something else must be going on here.  I wrote this simple program:
> 
> #include <unistd.h>
> 
> int main (int argc, char **argv, char **envp)
> {
> 
>    char * elem;
> 
>    for (elem = *envp; elem != NULL; (elem = *(++envp))) {
>      printf ("%s\n", elem);
>    }
> }
> 
> compiled it as /tmp/envprint

I can repeat this experiment and it works for me too, so it's clearly just
something odd with zsh. So this isn't a tcl issue and we can ignore it :-)

> Right, dyld doesn't reread the environment every time it goes to do a 
> load.  It reads it once at startup and then uses the cached copy.  So 
> this is perhaps a dyld bug (but dyld does do some work on the path, and 
> library loading needs to be pretty fast so maybe not).  But it is not a 
> Tcl bug.

Indeed - I've now downloaded the source (thanks for the pointers to those) and 
can see what you mean. It would be useful if there was a function to
reinitialise the cached dyld_library_path (and co.) variables, but there
isn't. For now I've worked around this with an ultra-hacky second program
which sets the environment variable, forks and execs, leaving the parent to
exit naturally (to avoid an extra dock icon). This seems unnecessarily
complex, but it does at least work.

How do system apps get around this? Do they simply assume that their libraries 
are going to be in the default search path? What about other apps? Do people
normally require the user to manually set the DYLD_LIBRARY_PATH before running 
the applications? I guess it's only normally a problem if you're loading with
explicit dyld calls rather than letting the runtime linker do the stuff for
you, so most programs never have to worry about such things.

> with your own environment is not an everyday task, gets done first.  Not 
> a great answer, but Apple has limited resources, we aren't MS after all, 
> so some things come more slowly...

Well I for one are pleased that Apple isn't MS! You've been a great help in
pointing the way forward. Cheers.

James

-- 
James Bonfield (jk...@mr...)   Fax: (+44) 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/

Re: [MACTCL] tk/OS X event handling?

[Jack J. <Jac...@or...>]

On Sunday, March 3, 2002, at 07:00 , Joe Laszlo wrote:

>
> Is there a way to get Tk on Mac OS X to handle only its own events
> and leave other events to whoever else might handle them?

I second this request. Jim explained to me (or to the list?) in the past 
that there were problems with this due to the way Carbon Events does the 
forwarding of events, but for the Tkinter/Python combination it is also 
going to be of prime importance once the Python IDE is up and running. 
On MacOS9 the Python IDE and Tkinter have never been able to work 
together due to event loop entanglement, it would be sad if the same 
were true on OSX, where Carbon Events do most of the work for us already.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [MACTCL] OS X tcl/tk crashes

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

Jason

I haven't tried the latest Tk build on 10.0.4, I may indeed have broken
something.  You really ought to get your hands on 10.1.  It is SO much nicer
than 10.0.x, I can't think of any reasons not to upgrade...

If Wish itself is crashing you can enable the "CrashReporter" - I don't
remember how this works on 10.0.x.  On 10.1 you open the Preferences of the
Console app, and choose the Crashes tab and click on logging crashes.  When
the app crashes, then, it will dump a stack backtrace in ~/Library/Logs.

You can also just run Wish under gdb (if you have installed the developer
tools) and get a backtrace when it crashes.

Jim

> Hi all,
> 
> I have a program that runs under Mac Classic, Linux, Solaris, and Windows
> tcl/tk.  When I try to run it via the mac OS X  tcl/tk (either by sourcing
> from
> the menu, or via #!... in the script, the program fails.  When I do the #!
> thing from the command-line, I get "Abort"... that's it... when sourcing from
> the menu, I get even less...  tcl/tk just silently quits.
> 
> How do I go about finding the problem?   If I remember right cmdtrace is just
> a
> tclx/wishx thing.  I'm trying this out on OS X v 10.0.4 Build 4Q12.  Is tcl/tk
> for OS X incompatible with this OS version?  Any other ideas?
> 
> Thanks,
> 
> Jason
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - sign up for Fantasy Baseball
> http://sports.yahoo.com
> 
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb

[MACTCL] tk/OS X event handling?

[Joe L. <jfl...@dg...>]

Is there a way to get Tk on Mac OS X to handle only its own events
and leave other events to whoever else might handle them?

I'm poking at trying to port an app. to OS X that has both Tcl/Tk and
GLUT event loops working together and I'd like to have it so Tk
handle's only Tk/Wish windows, events, etc. and GLUT handles only
events related to the GLUT window(s) but they seem to steal each
other's events even though the associated windows etc. are entirely
unrelated.  I'm pretty sure both event loops are getting called
sufficiently and this works fine without collisions on Windows and
Linux.


Is it possible to to write libraries/frameworks on MacOS X such
that they "play nicely" and handle only their own events without
interfering with other libraries' UI that might have their own
windows etc?


Joe.

[MACTCL] OS X tcl/tk crashes

[Jason S. <je...@ya...>]

Hi all,

I have a program that runs under Mac Classic, Linux, Solaris, and Windows
tcl/tk.  When I try to run it via the mac OS X  tcl/tk (either by sourcing from
the menu, or via #!... in the script, the program fails.  When I do the #!
thing from the command-line, I get "Abort"... that's it... when sourcing from
the menu, I get even less...  tcl/tk just silently quits.

How do I go about finding the problem?   If I remember right cmdtrace is just a
tclx/wishx thing.  I'm trying this out on OS X v 10.0.4 Build 4Q12.  Is tcl/tk
for OS X incompatible with this OS version?  Any other ideas?

Thanks,

Jason

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

RE: [MACTCL] OS X tcl/tk installation

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

The basics of getting a .pkg set up is quite simple and I'd highly
recommend it.  You can easily set up the installation script that was
given to be auto-executed on installation.  I'll see if I can find my
notes on the subject, but it goes something like this: 

1) Create a README* file (* can be txt, rtf, rtfd, etc)
2) Create a LICENSE* file
3) Put the readme, license, and optional install scripts into a directory
by themselves (This is the Resource directory)
4) Create an install tree that has what you want where you want it to go
(This is the PackageRoot -- this may be empty, though not recommended)
5) Run PackageMaker (in the devTools) and point the PackageRoot and
Resource directory to where they need to be, and build the package

There is a checkmark for whether admin access is required and whether
there to require affirmation of the license, among a few other options.

Once done, PackageMaker will automagically generate the .pkg installer for
you.

Throw that .pkg into a read-only .dmg with the readme and you are set to
deliver a thoughtless/full install.

As a side note, as I mentioned, you don't have to give the PackageRoot.
The tar.gz could be a resource that is installed by a hook script.  There
are four scripts that are optionally run, if they exist, on upgrade and/or
install.  You can have a script that runs before installation, and one
that runs after.

Like I said, I'll see if I can get my notes on this.  It really is pretty
simple, and elegant, but a concrete example would get the idea across much
better. 

Cheers!

Sean



On Fri, 1 Mar 2002, macnerd wrote:

> I wanted to research for to use a NeXTSTEP .pkg format, so
> that things are auto-install and more transparent.  Though,
> we could do the .dmg tarball for now and slide into the .pkg
> later.
> 
> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Jason
> Sonnenschein
> Sent: Friday, March 01, 2002 7:20 AM
> To: tc...@li...
> Subject: [MACTCL] OS X tcl/tk installation
> 
> 
> Hi all,
> 
> I was thinking about how to make the installation a bit easier for the end
> user.
> Would the maintainers consider making a dmg file with the tarball and an
> installation shell script?  Off the top of my head... something like:
> 
> 
> 
> #!/bin/sh
> 
> touch /.can_i_write > /dev/null 2>&1
> 
> if [ $? -eq 0 ] ; then
>     /bin/rm -f /.can_i_write
>     echo "Installing for all users..."
>     INSTALL_DIR="/"
>     SYMLINK_DIR="/usr/bin"
> else
>     echo Installing for `whoami`...
>     INSTALL_DIR=$HOME
>     SYMLINK_DIR=${HOME}/bin
> fi
> 
> TARBALL=`pwd`/MacOSXTk8.4a4-2.tar.gz
> cd $INSTALL_DIR
> tar -xzf $TARBALL
> ln -s ${INSTALL_DIR}/Applications/Wish\ Shell.app/Contents/MacOS/Wish\ Shell
> ${S
> YMLINK_DIR}/wish
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Greetings - Send FREE e-cards for every occasion!
> http://greetings.yahoo.com
> 
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 
> 
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

Re: [MACTCL] mini.net gone yet again

[Jean-Claude W. <jc...@eq...>]

Ge...@Or... <Ge...@Or...> wrote:

>Mini.net's DNS is dead.

Aha... got it.  The primary server was down, the secondary was ok.  I've
restarted it - should be ok now.  Thanks!

-jcw, with apologies for polluting this mailing list

Re: [MACTCL] mini.net gone yet again

[<Ge...@Or...>]

JCW wrote:
I can't reproduce the connectivity problems you report for MINI.NET: 

% ping mini.net
PING mini.net (216.110.35.177) from 80.126.24.9 : 56(84) bytes of data.
64 bytes from mini.net (216.110.35.177): icmp_seq=1 ttl=237 

 ---- 

Now that you show the IP address, I can ping it too. 

That means you are using a DNS server that still has
it cached. If you follow the same "nslookup" input as
I showed, does it hang? I started [not shown] with one
of the root servers, F.root-servers.net . 

For everyone who isn't using a DNS server that happens
to have it cached (because you've been accessing it),
the web pages can't be accessed. 

Mini.net's DNS is dead.

Re: [MACTCL] Building Aqua Tk on MacOS X

[Jean-Claude W. <jc...@eq...>]

Robert Ramsay <moc...@ro...> wrote:

>If you hi lite the TkLibrary in Targets and go into the Files and Build 
>Phases menu you can set it so the shell script will only run when
>installing. It should compile then.

That did the trick, thank you.  I've updated the mini.net/tcl/mactcl page.

Cool.  Next stop: loading extensions dynamically.

-jcw

Re: [MACTCL] mini.net gone yet again

[Jean-Claude W. <jc...@eq...>]

Ge...@Or... <Ge...@Or...> wrote:

>Someone who doesn't know Unix wrote:
># Actually, I just extended one of the
># existing pages: <http://mini.net/tcl/mactcl> 
>
>It's not responding, as of now. 

Well (the "who doesn't know Unix" puzzles me), but I can't reproduce the
connectivity problems you report for MINI.NET:

% ping mini.net
PING mini.net (216.110.35.177) from 80.126.24.9 : 56(84) bytes of data.
64 bytes from mini.net (216.110.35.177): icmp_seq=1 ttl=237 time=148.569 msec
64 bytes from mini.net (216.110.35.177): icmp_seq=2 ttl=237 time=146.259 msec

--- mini.net ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 1009ms
rtt min/avg/max/mdev = 146.259/147.414/148.569/1.155 ms
% ping trixie.triqs.com
PING trixie (216.110.36.111) from 80.126.24.9 : 56(84) bytes of data.
64 bytes from trixie (216.110.36.111): icmp_seq=1 ttl=237 time=146.432 msec
64 bytes from trixie (216.110.36.111): icmp_seq=2 ttl=237 time=146.655 msec

--- trixie ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 1015ms
rtt min/avg/max/mdev = 146.432/146.543/146.655/0.398 ms
% ping triqs.com
PING triqs.com (216.110.35.176) from 80.126.24.9 : 56(84) bytes of data.
64 bytes from triqs.com (216.110.35.176): icmp_seq=1 ttl=237 time=146.586 msec
64 bytes from triqs.com (216.110.35.176): icmp_seq=2 ttl=237 time=147.011 msec

--- triqs.com ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 1013ms
rtt min/avg/max/mdev = 146.586/146.798/147.011/0.438 ms
%

I could send you a traceroute by email if you like (this is not related
to Tcl or Mac).

-jcw

[MACTCL] mini.net gone yet again

[<Ge...@Or...>]

Someone who doesn't know Unix wrote:
# Actually, I just extended one of the
# existing pages: <http://mini.net/tcl/mactcl> 

It's not responding, as of now. 

 ---- 

> server A.GTLD-SERVERS.net
Default Server:  A.GTLD-SERVERS.net
Address:  192.5.6.30 

> mini.net
Server:  A.GTLD-SERVERS.net
Address:  192.5.6.30 

Non-authoritative answer:
mini.net        nameserver = TRIXIE.TRIQS.COM
mini.net        nameserver = TRIQS.COM 

Authoritative answers can be found from:
mini.net        nameserver = TRIXIE.TRIQS.COM
mini.net        nameserver = TRIQS.COM
TRIXIE.TRIQS.COM        internet address = 216.110.36.111
TRIQS.COM       internet address = 216.110.35.176
> server TRIXIE.TRIQS.COM
Default Server:  TRIXIE.TRIQS.COM
Address:  216.110.36.111 

> mini.net
Server:  TRIXIE.TRIQS.COM
Address:  216.110.36.111 

^C [hung]
> server TRIQS.COM
*** Can't find address for server TRIQS.COM: No response from server
> server 216.110.35.176
[hung]

Re: [MACTCL] Building Aqua Tk on MacOS X

[Robert R. <moc...@ro...>]

  Hi
If you hi lite the TkLibrary in Targets and go into the Files and Build 
Phases menu
you can set it so the shell script will only run when installing. It 
should compile
then.
rob

Jean-Claude Wippler wrote:

>James Bonfield <jk...@mr...> wrote:
>
>>On Fri, Mar 01, 2002 at 04:15:23PM +0100, Jean-Claude Wippler wrote:
>>
>>>Is it a good idea to get the macosx branches of tcl/tk from CVS, HEAD
>>>revision and follow instructions (which?) from there on?
>>>
>>You want the macosx-8-4-branch.
>>
>[...]
>
>>>From there it's quite easy - just run the Project Builder on the
>>macosx/*.pbproj files.
>>
>
>There must be some small tweak I am missing.  I've followed all steps and
>described them on http://mini.net/tcl/mactcl - but run into an error
>after the compiles:
>
>  PhaseScriptExecution <Execution>/Users/jcw/pbtmp/Wish.build/
>TkLibrary.build/BPTag008-script.sh
>  === Script ===
>  #!/bin/sh
>  source buildConfig
>  --- Output ---
>  /Users/jcw/pbtmp/Wish.build/TkLibrary.build/BPTag008-script.sh: source:
>no such file or directory: buildConfig [2]
>
>Note that this is a clean install of the system, i.e.:
>    install OS 10.1 CD on PB/300, sharing 9.2.2 partition
>    online updates to 10.1.3
>    install developer CD tools Dec 2001
>    cvs tcl and tktoolkit, hours ago
>
>This error appears to be the same as what Steve Landers reported a few
>days ago.
>
>-jcw
>
>
>_______________________________________________
>Tcl-mac mailing list
>Tc...@li...
>https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] Building Aqua Tk on MacOS X

[Jean-Claude W. <jc...@eq...>]

James Bonfield <jk...@mr...> wrote:

>On Fri, Mar 01, 2002 at 04:15:23PM +0100, Jean-Claude Wippler wrote:
>> Is it a good idea to get the macosx branches of tcl/tk from CVS, HEAD
>> revision and follow instructions (which?) from there on?
>
>You want the macosx-8-4-branch.
[...]
>>From there it's quite easy - just run the Project Builder on the
>macosx/*.pbproj files.

There must be some small tweak I am missing.  I've followed all steps and
described them on http://mini.net/tcl/mactcl - but run into an error
after the compiles:

  PhaseScriptExecution <Execution>/Users/jcw/pbtmp/Wish.build/
TkLibrary.build/BPTag008-script.sh
  === Script ===
  #!/bin/sh
  source buildConfig
  --- Output ---
  /Users/jcw/pbtmp/Wish.build/TkLibrary.build/BPTag008-script.sh: source:
no such file or directory: buildConfig [2]

Note that this is a clean install of the system, i.e.:
    install OS 10.1 CD on PB/300, sharing 9.2.2 partition
    online updates to 10.1.3
    install developer CD tools Dec 2001
    cvs tcl and tktoolkit, hours ago

This error appears to be the same as what Steve Landers reported a few
days ago.

-jcw

[MACTCL] Coming from Unix it looks like Mars

[Jean-Claude W. <jc...@eq...>]

In preparation of my first Tcl build on MacOS X ever, I <blush> went
through the mailing list archives a bit more (RTFMailinglist-archives).
The thread on incr-tcl is illuminating - though geocrawler is a bit
tedious to browse or search IMO.

It feels strange to be on this end of the table but I'll say it anyway:
    Yes, macosx looks great, but everything is different.
    I would like someone to hold my hand and present it all
    to me on a silver platter.
No offense intended.  But it sums up my current feelings.

The point of the subject of this message is that macosx so far looks -
for 99% of all developers - strange, weird, or more accurately: unknown.
 Just like Unix must look at first to Windows developers, no doubt.

Let's try to ease the entry into macosx for Tcl developers.  I've set up
a page on the Tcl'ers Wiki with pointers to as many starting points for
Tcl *and* Mac as I could find.  Actually, I just extended one of the
existing pages: <http://mini.net/tcl/mactcl>

Please feel free to add and adjust the information on that page.  You can
edit it with a web-browser and add "[http://...]" as appropriate to
insert more links for example.

-jcw

RE: [MACTCL] OS X tcl/tk installation

[macnerd <ma...@re...>]

I wanted to research for to use a NeXTSTEP .pkg format, so
that things are auto-install and more transparent.  Though,
we could do the .dmg tarball for now and slide into the .pkg
later.

-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...]On Behalf Of Jason
Sonnenschein
Sent: Friday, March 01, 2002 7:20 AM
To: tc...@li...
Subject: [MACTCL] OS X tcl/tk installation


Hi all,

I was thinking about how to make the installation a bit easier for the end
user.
Would the maintainers consider making a dmg file with the tarball and an
installation shell script?  Off the top of my head... something like:



#!/bin/sh

touch /.can_i_write > /dev/null 2>&1

if [ $? -eq 0 ] ; then
    /bin/rm -f /.can_i_write
    echo "Installing for all users..."
    INSTALL_DIR="/"
    SYMLINK_DIR="/usr/bin"
else
    echo Installing for `whoami`...
    INSTALL_DIR=$HOME
    SYMLINK_DIR=${HOME}/bin
fi

TARBALL=`pwd`/MacOSXTk8.4a4-2.tar.gz
cd $INSTALL_DIR
tar -xzf $TARBALL
ln -s ${INSTALL_DIR}/Applications/Wish\ Shell.app/Contents/MacOS/Wish\ Shell
${S
YMLINK_DIR}/wish


__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

_______________________________________________
Tcl-mac mailing list
Tc...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

RE: [MACTCL] Building Aqua Tk on MacOS X

[macnerd <ma...@re...>]

Oooh, Oooh, OOooh.

I am an amateur web designer wannabe.  Perhaps this is something I can help
out with: docs and tutorials.

Apple just sent my titanium back, broken again with debris in the monitor,
but still viable to OS9.x testing and OSX testing.

When in this the "tcltk conference submission deadline"?!?!?

These are things I am interested in doing:

  (1) make tutorial/install docs
  (2) package native installer (perhaps native Mac installer)
  (3) get popular packages to work like tclODBC and tclSOAP. (need much
help)
      (3a) Document popular tools as Tcl/Tk Cookbook with help of course.
  (4) make everything compilable from the command line (MPW, Darwin).
      move away from CodeWarior project files, more DeRez resources.

I have a website at http://www.realmspace.com which is in
prototype/content-development stage, so don't laugh.  I want to add a
Scripting area to my site.

 - Joaquin

-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...]On Behalf Of Franc Brglez
Sent: Friday, March 01, 2002 9:08 AM
To: Jean-Claude Wippler; tc...@li...
Cc: hl...@ci...
Subject: Re: [MACTCL] Building Aqua Tk on MacOS X


Dear Jean-Claude,

I'll be eternally grateful if you can document and post an "OS X
tcltk install process for the dummies" that is transparently as
simple as one under OS9.x now, so that I end up with an environment
where I can just copy most existing OS9.x tcltk programs to OS X
partition and invoke them readily with tclsh or wish under OS X (as I
do now under OS 9.2). Making a "drag & drop tclet" would be nice but
is not an essential priority (for me at least).

I didn't get too far in October -- the version was buggy, and despite
kind help from Jim, it was way too early for someone with my limited
experience to continue -- I'll get back to OS X once I am confident
that our OS9.2 tcktk programs will "just work as is" under OS X as
well as they do currently under unix, linux, and windows.

We have by now developed, UNDER macOS9.2, a very comfortable
cross-platform "8.3.4 ticklish environment" that will address and
resolve a number of questions from less experienced tcltk
mac-programmers on this forum -- including platform independent
self-installation of paths for each and every program and library
package we develop. We hope to have this environment documented and
ready for release by the tcltk conference submission deadline. It
will be a tribute to all tcltk mac-developers who made this
mac-platform development possible for us -- in particular if we can
port it cleanly also to macOS X and report on it.

Many thansk to Jim, you, and others "in the know".

Franc

PS -- once you made a posting, pls send mail under a new header, eg.
      "OS X tcltk installation, testing, and verification notes"

At 4:15 PM +0100 3/1/02, Jean-Claude Wippler wrote:
>Steve Landers <st...@di...> wrote:
>
>>I'm trying to build Aqua Tk on MacOS X, using Jim's instructions posted
>>back in October. I'm doing this in the hope of getting TclKit working on
>>Aqua Tk supporting dynamic loading.
>[...]
>>BTW, the machine is an iBook running MacOS X 10.1.3 using the December
>>2001 developer tools.
>
>I'd like to help.  I have just configured the same setup from scratch,
>and am about to grab Tcl/Tk etc sources (also incrtcl).  Given that my
>setup is clean, this will make a good test case for working through the
>entire build process.
>
>Is it a good idea to get the macosx branches of tcl/tk from CVS, HEAD
>revision and follow instructions (which?) from there on?
>
>If someone can point me to the proper spot(s), I'll report my progress.
>Steve: the least that ought to come out is finding out whether/how your
>setup differs from mine in any way.
>
>-jcw
>
>
>_______________________________________________
>Tcl-mac mailing list
>Tc...@li...
>https://lists.sourceforge.net/lists/listinfo/tcl-mac


_______________________________________________
Tcl-mac mailing list
Tc...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Setting environment vars from tcl

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

On Friday, March 1, 2002, at 10:11  AM, James Bonfield wrote:

> OK, in a follow up to my own findings, I now see that there's still a 
> few
> other tcl problems (and perhaps system problems) involving environment
> variables.
>
> The first is that exec seems to clear all of them. Eg try "exec zsh" 
> and then
> printenv. I can get this to work in a test C application using 
> NSGetEnviron
> and execl, so it looks like it's a tcl specific bug.

Something else must be going on here.  I wrote this simple program:

#include <unistd.h>

int main (int argc, char **argv, char **envp)
{

   char * elem;

   for (elem = *envp; elem != NULL; (elem = *(++envp))) {
     printf ("%s\n", elem);
   }
}

compiled it as /tmp/envprint

then did:

inghji:/tmp > tclsh
% exec /tmp/envprint
HOME=/Network/Servers/cauchy/homes/thorin/jingham
SHELL=/bin/tcsh
USER=jingham
% parray env
env(HOME)                    = 
/Network/Servers/cauchy/homes/thorin/jingham
env(SHELL)                   = /bin/tcsh
env(USER)                    = jingham
% set env(FOO) BAR
BAR
% set env(FOO) BAR
BAR
% parray env
env(FOO)                     = BAR
env(HOME)                    = 
/Network/Servers/cauchy/homes/thorin/jingham
env(SHELL)                   = /bin/tcsh
env(USER)                    = jingham
% exec /tmp/envprint
HOME=/Network/Servers/cauchy/homes/thorin/jingham
SHELL=/bin/tcsh
USER=jingham
FOO=BAR
% exit

This is before your applying your patch, which is why I had to set it 
twice...  I also trimmed the output of the env commands for clarity.  
But this worked fine.  Maybe something in zsh is clearing the 
environment????  Not sure here.

>
> The second is that although setting environment variables does appear 
> to work
> correctly changing the value of DYLD_LIBRARY_PATH appears to have no
> effect. I've tried changing PATH by using "exec prog", set env(PATH), 
> and then
> exec prog once more. This demonstrates that the environment really is 
> being
> set correctly. However I can't get "load" to work by changing
> DYLD_LIBRARY_PATH within wish.
>
> If I change it outside of wish (in zsh say) then load within subsequent 
> wishes
> works fine (thus demonstrating that the recent patch to fix this works 
> fine -
> cheers). I can't see any mention of DYLD_LIBRARY_PATH in tcl, so does 
> this
> imply that the NSAddImage function uses a copy of DYLD_LIBRARY_PATH 
> inherited
> at application startup and not the copy found in the current environment
> variable?
>


Right, dyld doesn't reread the environment every time it goes to do a 
load.  It reads it once at startup and then uses the cached copy.  So 
this is perhaps a dyld bug (but dyld does do some work on the path, and 
library loading needs to be pretty fast so maybe not).  But it is not a 
Tcl bug.

If you really really care about this sort of thing, the dyld source is 
part of the Darwin sources - in the cctools project.  So you could go 
get it from opensource.apple.com and confirm this yourself.  But I just 
looked and it does just what you suspected...


> I'm not sure how much further I can go with my changes to this code as 
> I'm a
> complete Mac newbie really. I'm still finding it virtually impossible to
> find documentation. Anyone know where _NSGetEnviron is documented? I 
> did a
> systemwide grep and failed to find it. Google finds little else other 
> than the
> tcl source itself. Come on Apple! Either gives us docs or the source 
> for the
> libraries themselves. Please?

In this case, the source libraries ARE part of the Darwin repository.  
_NSGetEnviron is in crt_externs.c in the Libc project on 
opensource.apple.com, though it is a bunch of gnarly macros.  You will 
have to do more detective work than I have time for right now to figure 
out what it really means.  Remember, ALL the Kernel and BSD level stuff 
and most of Core Foundation is available in source form.

On the Docs side, the Developer docs team is working their little tails 
off but there is a lot to do.  NeXT badly neglected all the BSD 
manpages, so they all have to be fixed, the AppKit & Carbon folks are 
busily adding stuff to their API's, etc, etc...  So they have to 
prioritize, and stuff that is more common, and you must admit mucking 
with your own environment is not an everyday task, gets done first.  Not 
a great answer, but Apple has limited resources, we aren't MS after all, 
so some things come more slowly...

>
> (This is no reflection on you Jim - you've done a stirling job and I 
> thank
> both you and Apple for allowing you the time and resources. Thanks.)
>

No prob, it is frustrating at times, I know.

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer

Re: [MACTCL] Building Aqua Tk on MacOS X

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

On Friday, March 1, 2002, at 09:05  AM, macnerd wrote:

> Does AguaTK use Cocoa/OPENSTEP or is it a Carbon thing?

Carbon, both because I wanted to use as much of the already working 
Classic MacOS code as possible, and because building one high level 
toolkit on top of another just seemed like asking for trouble.  Carbon 
is a much lower level toolkit, though there are still areas where we 
can't do some of the fancy things Tk allows because it would require 
going under the toolkit level, which in the long run just causes more 
pain...

Jim

>
> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Jean-Claude
> Wippler
> Sent: Friday, March 01, 2002 7:15 AM
> To: tc...@li...
> Subject: Re: [MACTCL] Building Aqua Tk on MacOS X
>
>
> Steve Landers <st...@di...> wrote:
>
>> I'm trying to build Aqua Tk on MacOS X, using Jim's instructions posted
>> back in October. I'm doing this in the hope of getting TclKit working 
>> on
>> Aqua Tk supporting dynamic loading.
> [...]
>> BTW, the machine is an iBook running MacOS X 10.1.3 using the December
>> 2001 developer tools.
>
> I'd like to help.  I have just configured the same setup from scratch,
> and am about to grab Tcl/Tk etc sources (also incrtcl).  Given that my
> setup is clean, this will make a good test case for working through the
> entire build process.
>
> Is it a good idea to get the macosx branches of tcl/tk from CVS, HEAD
> revision and follow instructions (which?) from there on?
>
> If someone can point me to the proper spot(s), I'll report my progress.
> Steve: the least that ought to come out is finding out whether/how your
> setup differs from mine in any way.
>
> -jcw
>
>
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
>
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer

Re: [MACTCL] Setting environment vars from tcl

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

James,

Thanks for tracking this down!  I bet nobody ever really tested changing 
the environment on Classic MacOS very thoroughly, since it really didn't 
have all that much use.  The main use of the environment is either to 
get stuff passed in to you from your parent which doesn't require 
changing the environment, or to affect the state of any child processes, 
which you couldn't have on classic MacOS.

When you send the patch, I'll get it right in.

Jim

On Friday, March 1, 2002, at 06:44  AM, James Bonfield wrote:

> On Thu, Feb 28, 2002 at 11:33:08AM -0800, Jim Ingham wrote:
>> James,
>>
>> I did notice this when I was playing around just yesterday.  It is odd,
>> because it mostly works just fine, and then every so often you will get
>> the "can't read..." error, or it will just silently fail to set the
>> environment.  Then one or two commands later it will work again.  
>> Please
>> file a bug on this, and if you want to have a whack at it, that would 
>> be
>> great.  It is a pretty annoying bug.
>
> I've tracked down the cause of the bug and a possible solution, 
> although I
> need to experiment further.
>
> TclSetupEnv has:
>
>     environ = *_NSGetEnviron();
>
> When adding an environment variable we need to extend environ, which is 
> done
> using ckalloc and memcpy. However an array names or similar function 
> will
> recall TclSetupEnv and so throws away our extended copy. Even if it 
> didn't
> call TclSetupEnv we'd still have problems for subprocesses as we haven't
> actually changed the environment, we've just made a copy.
>
> So just after the reallocate I added:
>
> char ***e = _NSGetEnviron();
> *e = environ;
>
> and lo the problem has vanished! I'm guessing that this has nothing at 
> all to
> do with MacOS X, but to do with the earlier mac versions too. I admit 
> that I
> was a little suprised I could change the environment just like that, 
> but I'm
> happy I can.
>
> I'll produce a patch and submit this to sourceforge.
>
> James
>
> --
> James Bonfield (jk...@mr...)   Fax: (+44) 01223 213556
> Medical Research Council - Laboratory of Molecular Biology,
> Hills Road, Cambridge, CB2 2QH, England.
> Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/
>
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer

Re: [MACTCL] Setting environment vars from tcl

[James B. <jk...@mr...>]

OK, in a follow up to my own findings, I now see that there's still a few
other tcl problems (and perhaps system problems) involving environment
variables.

The first is that exec seems to clear all of them. Eg try "exec zsh" and then
printenv. I can get this to work in a test C application using NSGetEnviron
and execl, so it looks like it's a tcl specific bug.

The second is that although setting environment variables does appear to work
correctly changing the value of DYLD_LIBRARY_PATH appears to have no
effect. I've tried changing PATH by using "exec prog", set env(PATH), and then 
exec prog once more. This demonstrates that the environment really is being
set correctly. However I can't get "load" to work by changing
DYLD_LIBRARY_PATH within wish.

If I change it outside of wish (in zsh say) then load within subsequent wishes
works fine (thus demonstrating that the recent patch to fix this works fine -
cheers). I can't see any mention of DYLD_LIBRARY_PATH in tcl, so does this
imply that the NSAddImage function uses a copy of DYLD_LIBRARY_PATH inherited
at application startup and not the copy found in the current environment
variable?

I'm not sure how much further I can go with my changes to this code as I'm a
complete Mac newbie really. I'm still finding it virtually impossible to
find documentation. Anyone know where _NSGetEnviron is documented? I did a
systemwide grep and failed to find it. Google finds little else other than the 
tcl source itself. Come on Apple! Either gives us docs or the source for the
libraries themselves. Please?

(This is no reflection on you Jim - you've done a stirling job and I thank
both you and Apple for allowing you the time and resources. Thanks.)

James

-- 
James Bonfield (jk...@mr...)   Fax: (+44) 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/