Tcl

On 19/05/2009 10:55 AM, Larry McVoy wrote:
> BTW, the distribution of our customer's usage of macos is:
> 
> MacOS/X 10.5  26%
> MacOS/X 10.4  66%
> MacOS/X 10.3   2%
> MacOS/X 10.2   5%
> 
> I'm surprised to see the 10.[23] holdouts, but not at all surprised at the
> 10.4 vs 10.5 distribution.

A comparative number based on recent visits to a typical section of the 
ActiveState website (from gAnalytics):

1. Intel 10.5  14,169 79.06% 	
2. Intel 10.4   1,042  5.81% 	
3. PPC 10.4       836  4.66% 	
4. Intel          797  4.45% 	
5. PPC 10.5       729  4.07% 	
6. PPC            330  1.84% 	
7. Intel 10.6      17  0.09% 	
8. 68K              1  0.01%

Go Mac Classic!

On Tue, May 19, 2009 at 11:09:03AM -0700, Jeff Hobbs wrote:
> On 19/05/2009 10:55 AM, Larry McVoy wrote:
> >BTW, the distribution of our customer's usage of macos is:
> >
> >MacOS/X 10.5  26%
> >MacOS/X 10.4  66%
> >MacOS/X 10.3   2%
> >MacOS/X 10.2   5%
> >
> >I'm surprised to see the 10.[23] holdouts, but not at all surprised at the
> >10.4 vs 10.5 distribution.
> 
> A comparative number based on recent visits to a typical section of the 
> ActiveState website (from gAnalytics):
> 
> 1. Intel 10.5  14,169 79.06% 	
> 2. Intel 10.4   1,042  5.81% 	
> 3. PPC 10.4       836  4.66% 	
> 4. Intel          797  4.45% 	
> 5. PPC 10.5       729  4.07% 	
> 6. PPC            330  1.84% 	
> 7. Intel 10.6      17  0.09% 	
> 8. 68K              1  0.01%
> 
> Go Mac Classic!

Those are pretty different numbers, you are counting web surfers.  I'm
counting people who actually have installed our product.  Doesn't 
activestate have those sorts of numbers?  There is a big difference 
between looky loos and real customers.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

On 19/05/2009 11:14 AM, Larry McVoy wrote:
> On Tue, May 19, 2009 at 11:09:03AM -0700, Jeff Hobbs wrote:
>> On 19/05/2009 10:55 AM, Larry McVoy wrote:
>>> BTW, the distribution of our customer's usage of macos is:
>>>
>>> MacOS/X 10.5  26%
>>> MacOS/X 10.4  66%
>>> MacOS/X 10.3   2%
>>> MacOS/X 10.2   5%
>>>
>>> I'm surprised to see the 10.[23] holdouts, but not at all surprised at the
>>> 10.4 vs 10.5 distribution.
>> A comparative number based on recent visits to a typical section of the 
>> ActiveState website (from gAnalytics):
>>
>> 1. Intel 10.5  14,169 79.06% 	
>> 2. Intel 10.4   1,042  5.81% 	
>> 3. PPC 10.4       836  4.66% 	
>> 4. Intel          797  4.45% 	
>> 5. PPC 10.5       729  4.07% 	
>> 6. PPC            330  1.84% 	
>> 7. Intel 10.6      17  0.09% 	
>> 8. 68K              1  0.01%
>>
>> Go Mac Classic!
> 
> Those are pretty different numbers, you are counting web surfers.  I'm
> counting people who actually have installed our product.  Doesn't 
> activestate have those sorts of numbers?  There is a big difference 
> between looky loos and real customers.

You are right that they are web browsing folk.  One point to note is 
that we recently (6 months ago) dropped 10.3 support across the board 
(without a single complaint that I'm aware of), so that will self-select 
to some extent, although they might not know that until they hit the 
sysreqs page.  Our licensing doesn't require server callback, so it's 
hard to separate out exact versions on installs, but if I actually go to 
the analytics directly on our download site, the 10.5 number hits 87%, 
though again that is web hits and not a direct correlation to the 
platform being downloaded (these are just the easiest to browse through).

Jeff

On May 18, 2009, at 8:44 AM, Daniel A. Steffen wrote:
>
> the most serious of these is the unavailability of CoreText on 10.4,
> i.e. the tkMacOSXFont.c errors.
>
> To add support for 10.4 probably the existing ATSUI renderer would
> somehow have to be glued back in and amalgamated with the new font
> handling (native widgets, menus etc also use the NSFont handling so it
> would need to be there even on 10.4)

I'm not sure what all is involved in this but at least getting the  
font ref is not hard

       ATSFontRef atsFont = ATSFontFindFromPostScriptName
         ((CFStringRef)[nsfont fontName], kATSOptionFlagsDefault);

       if (atsFont == kATSFontRefUnspecified)
             {
               /* last resort fallback */
               atsFont = ATSFontFindFromPostScriptName
                 ((CFStringRef)@"Monaco", kATSOptionFlagsDefault);
             }
       font_info->cgfont = CGFontCreateWithPlatformFont ((void*) 
&atsFont);

...

     CGContextRef gcontext =
       [[NSGraphicsContext currentContext] graphicsPort];
     CGContextSetFont (gcontext, font->cgfont);
     CGContextSetFontSize (gcontext, font->size);
     CGContextSetTextPosition (gcontext, r.origin.x, r.origin.y);
     CGContextShowGlyphsWithAdvances (gcontext, s->char2b + s->cmp_from,
                                     advances, len);

Here (from GNU Emacs code) CG functions are used for rendering, but I  
believe ATS ones could also be used, with the ATSFontRef.  Glyph  
generation is likely another area that would need to be worried  
about / integrated, but this can be done with Panther methods, also  
in the Emacs code.

On Tue, May 19, 2009 at 09:51:38AM +0700, Adrian Robert wrote:
> On May 18, 2009, at 8:44 AM, Daniel A. Steffen wrote:
> >
> >the most serious of these is the unavailability of CoreText on 10.4,
> >i.e. the tkMacOSXFont.c errors.
> >
> >To add support for 10.4 probably the existing ATSUI renderer would
> >somehow have to be glued back in and amalgamated with the new font
> >handling (native widgets, menus etc also use the NSFont handling so it
> >would need to be there even on 10.4)
> 
> I'm not sure what all is involved in this but at least getting the  
> font ref is not hard

Very cool if it works (I'm not qualified to judge).  As mentioned 
before, if people want to step up to backport this we can fund
that.  If people don't want to get that officially involved,
what about a BitMover sponsored set of Macbooks running 10.4?
Is that any incentive to anyone?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Hi Daniel,

"Daniel A. Steffen" writes:
> The Cocoa port [...] is now ready to be merged into the Tk mainline.

Thank you for that effort!  It's encouraging to see Tk moving with the
world while it changes.  I very much appreciate your work here.

> The principal new constraint of the TkAqua Cocoa port is that it
> requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X
> 10.3).

Than I guess I will have to upgrade my system to 10.5 sometime soon
;-).  Not your fault of course, I can see why this is a reasonable
decision.

benny

Hi Kristoffer,

On Tue, May 19, 2009 at 15:35, Kristoffer Lawson <setok@...> wrote:
> It is using the system's own Tk with just a WiSH shell embedded in
> the .app package. However, some people are reporting the following
> error on the console:
>
> "TKMacOSXDoHLEvent failed : cppe 1 ,kHighlevelEvent 616567674 0000
> tvea,-1708"

this just means that AEProcessAppleEvent() in TKMacOSXDoHLEvent()
returned error -1708, which is according to MacErrors.h
  errAEEventNotHandled          = -1708, /* the AppleEvent was not
handled by any handler */
i.e. your application got sent an apple event that you did not install
a handler for (an 'tvea' apple event...)

this error is completely unrelated to Tk and not caused by anything Tk
is doing, the internals of our apple event handling are really very
simple, all we do is pass off any apple events we receive to
AEProcessAppleEvent(), c.f. the code (8.4.7 versions):
http://fisheye.categorifiedcoder.info/browse/Tk/tk/macosx/tkMacOSXHLEvents.c?r=1.5.2.4
http://fisheye.categorifiedcoder.info/browse/Tk/tk/macosx/tkMacOSXEvent.c?r=1.3.2.1
http://fisheye.categorifiedcoder.info/browse/Tk/tk/macosx/tkMacOSXDebug.c?r=1.2.2.1

I have no idea what that 'tvea' apple event is, or who is sending it
to you, you may need to do some apple event logging to figure that out
(there is a technote on what env vars to set to do that IIRC).
you may want to look at using TclAE in addition to tclapplescript for
more flexible apple event handling, e.g. to install a handler for the
'tvea' apple event...

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **

On Tue, May 19, 2009 at 19:24, Daniel A. Steffen
<das@...> wrote:
> I have no idea what that 'tvea' apple event is, or who is sending it
> to you

a quick grep through EyeTV.app shows that only the EyeTV and EyeTV
Helper binaries contain that string, so this is probably an apple
event EyeTV is sending to back to you...
It isn't something listed in EyeTV's 'aete' resource, so it may be
hard to know what to do with this exactly...

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **

Quoting "Daniel A. Steffen" <das@...>:

> On Tue, May 19, 2009 at 15:35, Kristoffer Lawson <setok@...> wrote:
>>
>> "TKMacOSXDoHLEvent failed : cppe 1 ,kHighlevelEvent 616567674 0000
>> tvea,-1708"
:
:
> I have no idea what that 'tvea' apple event is, or who is sending it
> to you, you may need to do some apple event logging to figure that out
> (there is a technote on what env vars to set to do that IIRC).
> you may want to look at using TclAE in addition to tclapplescript for
> more flexible apple event handling, e.g. to install a handler for the
> 'tvea' apple event...

Actually, I wonder if there really is a 'tvea' AppleEvent. Both 'cppe'  
and 'tvea' seem like backwards (not byte-swapped) renditions of the  
more expected 'eppc' (kEventClassAppleEvent) and 'aevt'  
(kCoreEventClass).

I note that 61657674 (not 616567674, which has a spurious 6 in the  
middle) is hex for 'aevt', an event class, which begs the question of  
what the event ID is. I wonder if "kHighlevelEvent 616567674 0000"  
means that a nonsensical 'aevt' '\0\0\0\0' event is being sent? Still  
leaves you wondering by who...

On 19 May 2009, at 20:24, Daniel A. Steffen wrote:

> I have no idea what that 'tvea' apple event is, or who is sending it
> to you, you may need to do some apple event logging to figure that out
> (there is a technote on what env vars to set to do that IIRC).
> you may want to look at using TclAE in addition to tclapplescript for
> more flexible apple event handling, e.g. to install a handler for the
> 'tvea' apple event...

I would prefer to avoid using TclAE as, to be honest, it seemed a bit  
deep for my purposes. The whole area of apple events is one where I'd  
like a high level approach.

Are there people on this mailing list with EyeTV and an iPhone or iPod  
Touch? I would really appreciate help in debugging this (as this does  
not seem to be occurring in my own systems).

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

Quoting Kristoffer Lawson <setok@...>:

> The whole area of apple events is one where I'd
> like a high level approach.

Good luck with that!

On 19 May 2009, at 22:34, jguyer@... wrote:

> Quoting Kristoffer Lawson <setok@...>:
>
>> The whole area of apple events is one where I'd
>> like a high level approach.
>
> Good luck with that!

Well, up until now it seemed Tclapplescript would do the job  
nicely :-) As mentioned, it does work for me, at least most of the  
time (I have had the occasional odd crash). I think it's worth trying  
to figure out why it might be having a problem.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

On 19 May 2009, at 20:43, jguyer@... wrote:

> Quoting "Daniel A. Steffen" <das@...>:
>
>> On Tue, May 19, 2009 at 15:35, Kristoffer Lawson  
>> <setok@...> wrote:
>>>
>>> "TKMacOSXDoHLEvent failed : cppe 1 ,kHighlevelEvent 616567674 0000
>>> tvea,-1708"
> :
> :
>> I have no idea what that 'tvea' apple event is, or who is sending it
>> to you, you may need to do some apple event logging to figure that  
>> out
>> (there is a technote on what env vars to set to do that IIRC).
>> you may want to look at using TclAE in addition to tclapplescript for
>> more flexible apple event handling, e.g. to install a handler for the
>> 'tvea' apple event...
>
> Actually, I wonder if there really is a 'tvea' AppleEvent. Both 'cppe'
> and 'tvea' seem like backwards (not byte-swapped) renditions of the
> more expected 'eppc' (kEventClassAppleEvent) and 'aevt'
> (kCoreEventClass).

Could this then be related to some problem with the various extensions  
working with each other?  As far as I can tell, everything is  
Universal on my machine. But the byte swap theory is interesting. I  
just am not sure why it would happen on one machine, but not on another.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

Hi Jon,

On Tue, May 19, 2009 at 19:43,  <jguyer@...> wrote:
> Actually, I wonder if there really is a 'tvea' AppleEvent. Both 'cppe'
> and 'tvea' seem like backwards (not byte-swapped) renditions of the
> more expected 'eppc' (kEventClassAppleEvent) and 'aevt'
> (kCoreEventClass).
>
> I note that 61657674 (not 616567674, which has a spurious 6 in the
> middle) is hex for 'aevt', an event class, which begs the question of
> what the event ID is. I wonder if "kHighlevelEvent 616567674 0000"
> means that a nonsensical 'aevt' '\0\0\0\0' event is being sent? Still
> leaves you wondering by who...

duh, of course, that makes more sense, thanks ;-), that old debug code
is all pre-intel transition (long gone by now FWIW, 8.4.7 is really
ancient for TkAqua).

the 61657674 is indeed just the same data (the EventRecord message) as
the 4-char code (just the message long cast to a string, hence the
endianness bug), and the 0000 is the event modifiers  field: c.f. line
333ff of my tkMacOSXDebug.c link above
sprintf(buf, "%-16s %08x %04x %s", names->name, (int)
eventPtr->message, eventPtr->modifiers, cBuf);

i.e. no way to tell anything about the apple event causing the problem
from that debug message...

Kristoffer, as mentioned, you might want to ask the customers that see
this problem to turn on apple event logging... (ISTR there is a GUI
app for apple event logging around as well)

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **

On Tue, May 19, 2009 at 21:08, Kristoffer Lawson <setok@...> wrote:
> Could this then be related to some problem with the various extensions
> working with each other?  As far as I can tell, everything is
> Universal on my machine. But the byte swap theory is interesting. I
> just am not sure why it would happen on one machine, but not on another.

are you developing on a ppc machine? that would explain that you are
not seeing endianness-related problems...

there were various endian-related bugs in TclAE and very likely also
Tclapplescript (fixed in the former for sure by now, not so sure about
the latter...).
Leopard shipped with the Tiger versions of Tcl/Tk and the bundled
extensions, which are all very old by now, it would be a very good
idea IMO to bundle current versions of the extensions you use inside
your app (trivial, just put them e.g. in Resources in your .app bundle
and amend the auto_path)

All I know is that Tk is almost certainly not involved, the endian
problem in Tk 8.4.7 is just in the printing out of that debug
message...

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **

On 19 May 2009, at 22:54, Daniel A. Steffen wrote:

> duh, of course, that makes more sense, thanks ;-), that old debug code
> is all pre-intel transition (long gone by now FWIW, 8.4.7 is really
> ancient for TkAqua).

Is there any chance that an update to 8.5.* would fix this issue, as  
suggested on #tcl/tkchat? I'd prefer to keep with what comes with OS  
X, but if I can sort this by bundling 8.5 along, then I could consider  
that.

> i.e. no way to tell anything about the apple event causing the problem
> from that debug message...

FWIW the application at that point is asking EyeTV for a list of  
channels, plus the details of the channels. I have seen one or two  
problems there, but then I was getting an ERR from AppleScript,  
instead of this.

> Kristoffer, as mentioned, you might want to ask the customers that see
> this problem to turn on apple event logging... (ISTR there is a GUI
> app for apple event logging around as well)

I'll look into this.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

On Tue, May 19, 2009 at 22:19, Kristoffer Lawson <setok@...> wrote:
>
> On 19 May 2009, at 22:54, Daniel A. Steffen wrote:
>
>> duh, of course, that makes more sense, thanks ;-), that old debug code
>> is all pre-intel transition (long gone by now FWIW, 8.4.7 is really
>> ancient for TkAqua).
>
> Is there any chance that an update to 8.5.* would fix this issue, as
> suggested on #tcl/tkchat? I'd prefer to keep with what comes with OS X, but
> if I can sort this by bundling 8.5 along, then I could consider that.

I don't see why it would, it has nothing to do with any code in Tcl/Tk AFAICT...

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **

On 19 May 2009, at 23:06, Daniel A. Steffen wrote:

> On Tue, May 19, 2009 at 21:08, Kristoffer Lawson <setok@...>  
> wrote:
>> Could this then be related to some problem with the various  
>> extensions
>> working with each other?  As far as I can tell, everything is
>> Universal on my machine. But the byte swap theory is interesting. I
>> just am not sure why it would happen on one machine, but not on  
>> another.
>
> are you developing on a ppc machine? that would explain that you are
> not seeing endianness-related problems...

Nope, I'm developing on an Intel machine. In fact, the current version  
out there doesn't even work with PPC (because of endian issues with  
the pre-release of the Tcl Bonjour package). This has been fixed, but  
the client side is waiting for approval from Apple.

> there were various endian-related bugs in TclAE and very likely also
> Tclapplescript (fixed in the former for sure by now, not so sure about
> the latter...).

It's not quite clear if Tclapplescript uses TclAE underneath? Just  
again wondering if an update would help. After all, it's the  
Tclapplescript that comes with OS X.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

> It's not quite clear if Tclapplescript uses TclAE underneath?

it doesn't, c.f. the source ;-)

http://tclapplescript.svn.sourceforge.net/viewvc/tclapplescript/trunk/Source/

tclapplescript is really just a quick port of the old mac classic
tclMacOSA.c code, which is 1997 vintage...

> Just again wondering if an update would help. After all, it's the Tclapplescript that
> comes with OS X.

nothing appears to have changed in the Tclapplescript sources for five
years, other than me fixing some minor compilation warnings... in
particular I just verified that tclMacOSA_OSX.c is the same as what
shipped with Tiger and Leopard (except for those warning fixes)

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **

On 2009-05-19, at 13:30:41, Kristoffer Lawson wrote:

> On 19 May 2009, at 23:06, Daniel A. Steffen wrote:
>
>> On Tue, May 19, 2009 at 21:08, Kristoffer Lawson <setok@...>
>> wrote:

>>> Could this then be related to some problem with the various
>>> extensions
>>> working with each other?  As far as I can tell, everything is
>>> Universal on my machine. But the byte swap theory is interesting. I
>>> just am not sure why it would happen on one machine, but not on
>>> another.
>>

>> are you developing on a ppc machine? that would explain that you are
>> not seeing endianness-related problems...

> Nope, I'm developing on an Intel machine. In fact, the current version
> out there doesn't even work with PPC (because of endian issues with
> the pre-release of the Tcl Bonjour package). This has been fixed, but
> the client side is waiting for approval from Apple.

>> there were various endian-related bugs in TclAE and very likely also
>> Tclapplescript (fixed in the former for sure by now, not so sure  
>> about
>> the latter...).

> It's not quite clear if Tclapplescript uses TclAE underneath? Just
> again wondering if an update would help. After all, it's the
> Tclapplescript that comes with OS X.


Tclapplescript doesn't use TclAE. It's centered around the APIs  
available OpenScripting.framework (mostly calls in OSA.h).

I just looked at: <http://tclapplescript.svn.sourceforge.net/viewvc/tclapplescript/trunk/Source/tclMacOSA_OSX.c?view=log 
 > (#7).

That whole file is really out of date. AEDesc is semi-opaque and  
accessing the dataHandle struct member directly was deprecated before  
2002 I think. One good reason to turn on "warnings are errors" in gcc.

Two important calls that should be branched for Leopard and later are:
	
	OSAGetSource() -> OSACopySourceString()
	
	OSADisplay() -> OSACopyDisplayString()

And also change every use of typeChar to either typeUTF8Text (a really  
good fit for Tcl_ByteArray) or typeUnicode for text coercions.


For Carbon event handling, AEProcessAppleEvent() -> AEProcessEvent().

One thing to note is that AppleEvents are 64-bit compatible and so are  
components (i.e. OSA components have only a few unimportant items  
deprecated for 64-bit).


To view AppleEvents in Terminal you can set the following in .profile:

export AEDebugSends=1
#export AEDebugReceives=1

I don't use AEDebugReceives much because it's a huge amount of spew.


Regarding the 'cppe' problem some considerations are that:

1. Rosetta may be involved at some point (AppleScript still supports  
non-bundled applets).

2. There was a very bad bug on 10.4 with the call  
OSARemoveStorageType() on Intel (which was a byte order problem (but  
not your reported problem)).

HTH,

Philip Aker
echo astwta@... | tr a-z@. p-za-o.@

Democracy: Two wolves and a sheep voting on lunch.