Re: Puzzle Of the Day
Re: Puzzle Of the Day
- Subject: Re: Puzzle Of the Day
- From: Axel Luttgens <email@hidden>
- Date: Sat, 21 Aug 2010 10:19:18 +0200
Le 20 août 2010 à 23:15:10, R. Nelson Byrne a écrit :
> [...]
>
> One odd thing is that I didn't use an explicit tell block for Finder; I just wrote "tell application "Finder" to get ..." and yet the log output looks like it comes from within a Finder tell block.
Hello Nelson,
I tried this one here on 10.6.4:
tell application "Finder" to set MyPODtxts to (every file of desktop whose name ends with ".txt") as alias list
repeat with atxt in MyPODtxts
log atxt
end repeat
and the output of the log commands clearly appears outside of the trace of the tell block.
Then tried the same code on a 10.5.8 box, and got the same mess as the one you've described.
So, yes, as Ed suggested, this must be a slight bug in the way Script Editor reports events.
> Another odd thing is that ajpg and bjpg look the same to me - BUT ARE NOT THE SAME! (that's the *false* in the log).
>
> Perhaps it means that ajpg is a item in a repeat loop, or a reference to such a thing, whereas bjpg is ???? But they sure look the same according to the log.
Exactly: upon each iteration, the loop variable is set to a reference to an item of the list, not to the value of that item.
Because of the nature of AppleScript, this isn't obvious to track: each time such a reference appears in an expression, it is usually de-referenced and evaluated on the fly.
Here is one way to make the fact explicit:
tell application "Finder" to set MyPODtxts to (every file of desktop whose name ends with ".txt") as alias list
set MyPODtxts1 to {}
repeat with atxt in MyPODtxts
copy atxt to the end of MyPODtxts1
end repeat
MyPODtxts1
--> {item 1 of {alias... }, item 2 of {alias... }, ...}
Then comes the behavior of the equality operator ("is" and its siblings): it is the only one to consider its operands before their evaluation.
For non scalar operands, if the classes of the unevaluated operands differ, they are considered to be unequal.
Hence:
tell application "Finder" to set MyPODtxts to (every file of desktop whose name ends with ".txt") as alias list
set atxt1 to item 1 of MyPODtxts
repeat with atxt in MyPODtxts
log atxt is atxt1
end repeat
(* false *)
(* false *)
(* false *)
...
Variable atxt1 is set to an alias (because of immediate evaluation); and atxt is set to a reference upon each iteration. A reference isn't an AppleScript alias.
Let's now force atxt to be de-referenced (and evaluated):
tell application "Finder" to set MyPODtxts to (every file of desktop whose name ends with ".txt") as alias list
set atxt1 to item 1 of MyPODtxts
repeat with atxt in MyPODtxts
log contents of atxt is atxt1
end repeat
(* true *)
(* false *)
(* false *)
...
Alternatively, let's explicitly set atxt1 to a reference:
tell application "Finder" to set MyPODtxts to (every file of desktop whose name ends with ".txt") as alias list
set atxt1 to a reference to item 1 of MyPODtxts
repeat with atxt in MyPODtxts
log atxt is atxt1
end repeat
(* true *)
(* false *)
(* false *)
...
> Even if I get past this, I still have to find out why GC tries to open the entire list (how would it know there was a list anyway?) instead of the item selected for it by the repeat loop.
Well, I guess you met the other way to show that the loop variable in fact is set to a reference of the form:
item i of {alias... }
That way is to provoke the right kind of error at the right moment, so that the error message shows the full reference. ;-)
What's the error message from GC?
HTH,
Axel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden