| Re: object argument passing behaviour changed in v8.2.2? [message #84593] |
Mon, 21 October 2013 16:07  |
chris_torrence@NOSPAM
Messages: 528
Registered: March 2007
|
Senior Member |
|
|
Hi Paul,
Nothing has changed with the way IDL passes objects. However, I'm a little confused by your code. When you say that the "compute_interpolation_frequency" procedure "allocates the resulting object", do you really mean that it just fills in some properties on that object? Because it looks like you are doing an obj_new on those objects before passing them in.
It looks like something strange is going on with garbage collection, where it is somehow freeing up your object inside compute_interpolation_frequency. However, I can't imagine why this would be happening. I just create a test program which approximates what you are doing:
pro test_pass_objelement, obj
obj->getproperty, name = name
obj->SetProperty, NAME='NewName'
end
o = objarr(5)
for i=0,4 do begin
o[i] = obj_new('IDLitComponent', NAME=STRTRIM(i,2))
test_pass_objelement, o[i]
print, obj_valid(o[i])
endfor
end
When I run this code (at least in IDL 8.3), the objects are all valid after the procedure call. Can you try running this code to make sure it passes for you? If it does, then maybe you can post the details of your compute_interpolation_frequency procedure, so we can diagnose what is happening inside
|
|
|
|
| Re: object argument passing behaviour changed in v8.2.2? [message #86260 is a reply to message #84593] |
Tue, 22 October 2013 05:16  |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Hi Chris,
Your test code works fine for me. But I changed it to more closely
approximate what I am doing (and added more output of the properties).
The important change is that the procedure in question has been changed
to a method.
-----%<-----
pro IDLitComponent::test_pass_objelement, obj
obj = obj_new('IDLitComponent')
self->GetProperty, name=name
obj->SetProperty, NAME=name ; Set the name...
obj->GetProperty, NAME=name ; ...get it...
print, "In method. Name = ", name ; ...and print
end
pro test_pass
o = objarr(5)
for i=0,4 do begin
scalarobj = obj_new('IDLitComponent',name='scalar work obj')
o[i] = obj_new('IDLitComponent',name='empty rank-1')
scalarobj->test_pass_objelement, o[i]
o[i]->getproperty, name = name ; Get the name...
print, "In caller. Name = ", name ; ...and print
print
endfor
end
-----%<-----
When I run "test_pass" I get the following output:
IDL> test_pass
% Compiled module: TEST_PASS.
In method. Name = scalar work obj
In caller. Name = empty rank-1
In method. Name = scalar work obj
In caller. Name = empty rank-1
In method. Name = scalar work obj
In caller. Name = empty rank-1
In method. Name = scalar work obj
In caller. Name = empty rank-1
In method. Name = scalar work obj
In caller. Name = empty rank-1
So, while the *passed* object is valid upon return, all of the changes
made to it in the method didn't "take".
This is only a problem when the object is an argument to one of its own
methods, but invoked via a different object (in this case "scalarobj").
When the object is passed as an argument to a "regular" procedure (as in
your test case) everything works as expected.
Any ideas? The actual code in question (my operational equivalent of the
main "test_pass") has existed since 2011 - and it's been used to process
data for several satellite sensors.
cheers,
paulv
On 10/21/2013 07:07 PM, Chris Torrence wrote:
> Hi Paul,
>
> Nothing has changed with the way IDL passes objects. However, I'm a
> little confused by your code. When you say that the
> "compute_interpolation_frequency" procedure "allocates the resulting
> object", do you really mean that it just fills in some properties on
> that object? Because it looks like you are doing an obj_new on those
> objects before passing them in.
>
> It looks like something strange is going on with garbage collection,
> where it is somehow freeing up your object inside
> compute_interpolation_frequency. However, I can't imagine why this
> would be happening. I just create a test program which approximates
> what you are doing:
>
> pro test_pass_objelement, obj obj->getproperty, name = name
> obj->SetProperty, NAME='NewName' end o = objarr(5) for i=0,4 do
> begin o[i] = obj_new('IDLitComponent', NAME=STRTRIM(i,2))
> test_pass_objelement, o[i] print, obj_valid(o[i]) endfor end
>
> When I run this code (at least in IDL 8.3), the objects are all valid
> after the procedure call. Can you try running this code to make sure
> it passes for you? If it does, then maybe you can post the details of
> your compute_interpolation_frequency procedure, so we can diagnose
> what is happening inside.
>
> Thanks! -Chris ExelisVIS
>
|
|
|
|
| Re: object argument passing behaviour changed in v8.2.2? [message #86261 is a reply to message #86260] |
Tue, 22 October 2013 06:03 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
O.k. I think I've figured out a workaround -- but I would still like to
know why the test case I posted doesn't work.
I went through our repository logs and saw that I recently added the
creation of a new object in the method.
So, if I remove the line
obj = obj_new('IDLitComponent')
from the IDLitComponent::test_pass_objelement method, everything works
as expected:
IDL> test_pass
% Compiled module: TEST_PASS.
In method. Name = scalar work obj
In caller. Name = scalar work obj
In method. Name = scalar work obj
In caller. Name = scalar work obj
In method. Name = scalar work obj
In caller. Name = scalar work obj
In method. Name = scalar work obj
In caller. Name = scalar work obj
In method. Name = scalar work obj
In caller. Name = scalar work obj
So, are we dealing with pass-by-reference/value confusion on my part here?
That is, the creation of new object in the method doesn't do anything
about the reference to the original object that was passed in, and
eventually returned back to the caller?
cheers,
paulv
On 10/22/2013 08:16 AM, Paul van Delst wrote:
> Hi Chris,
>
> Your test code works fine for me. But I changed it to more closely
> approximate what I am doing (and added more output of the properties).
>
> The important change is that the procedure in question has been changed
> to a method.
>
> -----%<-----
> pro IDLitComponent::test_pass_objelement, obj
> obj = obj_new('IDLitComponent')
> self->GetProperty, name=name
> obj->SetProperty, NAME=name ; Set the name...
> obj->GetProperty, NAME=name ; ...get it...
> print, "In method. Name = ", name ; ...and print
> end
>
> pro test_pass
> o = objarr(5)
> for i=0,4 do begin
> scalarobj = obj_new('IDLitComponent',name='scalar work obj')
> o[i] = obj_new('IDLitComponent',name='empty rank-1')
> scalarobj->test_pass_objelement, o[i]
> o[i]->getproperty, name = name ; Get the name...
> print, "In caller. Name = ", name ; ...and print
> print
> endfor
> end
> -----%<-----
>
> When I run "test_pass" I get the following output:
>
> IDL> test_pass
> % Compiled module: TEST_PASS.
> In method. Name = scalar work obj
> In caller. Name = empty rank-1
>
> In method. Name = scalar work obj
> In caller. Name = empty rank-1
>
> In method. Name = scalar work obj
> In caller. Name = empty rank-1
>
> In method. Name = scalar work obj
> In caller. Name = empty rank-1
>
> In method. Name = scalar work obj
> In caller. Name = empty rank-1
>
>
> So, while the *passed* object is valid upon return, all of the changes
> made to it in the method didn't "take".
>
> This is only a problem when the object is an argument to one of its own
> methods, but invoked via a different object (in this case "scalarobj").
>
> When the object is passed as an argument to a "regular" procedure (as in
> your test case) everything works as expected.
>
> Any ideas? The actual code in question (my operational equivalent of the
> main "test_pass") has existed since 2011 - and it's been used to process
> data for several satellite sensors.
>
> cheers,
>
> paulv
>
>
> On 10/21/2013 07:07 PM, Chris Torrence wrote:
>> Hi Paul,
>>
>> Nothing has changed with the way IDL passes objects. However, I'm a
>> little confused by your code. When you say that the
>> "compute_interpolation_frequency" procedure "allocates the resulting
>> object", do you really mean that it just fills in some properties on
>> that object? Because it looks like you are doing an obj_new on those
>> objects before passing them in.
>>
>> It looks like something strange is going on with garbage collection,
>> where it is somehow freeing up your object inside
>> compute_interpolation_frequency. However, I can't imagine why this
>> would be happening. I just create a test program which approximates
>> what you are doing:
>>
>> pro test_pass_objelement, obj obj->getproperty, name = name
>> obj->SetProperty, NAME='NewName' end o = objarr(5) for i=0,4 do
>> begin o[i] = obj_new('IDLitComponent', NAME=STRTRIM(i,2))
>> test_pass_objelement, o[i] print, obj_valid(o[i]) endfor end
>>
>> When I run this code (at least in IDL 8.3), the objects are all valid
>> after the procedure call. Can you try running this code to make sure
>> it passes for you? If it does, then maybe you can post the details of
>> your compute_interpolation_frequency procedure, so we can diagnose
>> what is happening inside.
>>
>> Thanks! -Chris ExelisVIS
>>
|
|
|
|
|
|
| Re: object argument passing behaviour changed in v8.2.2? [message #86265 is a reply to message #86264] |
Tue, 22 October 2013 07:10 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Ha!
It's probably my advancing age, but these special cases with regards to
argument passing are really starting to annoy me... mostly because I
*still* keep brain-fading about them, but also because these days I
expect my code to do what I want, rather than what I tell it to do - a
definite sign of old-codger-ism[*] :o).
Time to translate the code to Fortran2003 I guess. Urg. (Which we sorta
have to do anyway, I was just hoping not to need to do it for a couple
more years.)
cheers,
paulv
[*] Or, more likely, I think I'm in an "autonomous stage" but I'm really
still in a "cognitive stage" with regards to programming skill.
( http://www.brainpickings.org/index.php/2013/10/17/ok-plateau)
On 10/22/2013 09:39 AM, David Fanning wrote:
> Paul van Delst writes:
>
>> That is, the creation of new object in the method doesn't do anything
>> about the reference to the original object that was passed in, and
>> eventually returned back to the caller?
>
> This appears to be the semi-passed-by-reference condition. ;-)
>
> Cheers,
>
> David
>
>
>
|
|
|
|
| Re: object argument passing behaviour changed in v8.2.2? [message #86266 is a reply to message #86265] |
Tue, 22 October 2013 07:43 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paul van Delst writes:
> It's probably my advancing age
Well, if you are like me, there is no doubt about this. :-)
This situation sorta makes sense to me, though.
I think subscripted arrays are passed by value, not by reference. But,
in the case of an object, the *fields* of the object are often pointers
and other objects (i.e., heap variables) that act like normal variables
and are passed by reference. So, you really do find yourself in this
sort of quantum state where the cat is both alive and dead at the same
time. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
| Re: object argument passing behaviour changed in v8.2.2? [message #86272 is a reply to message #86265] |
Tue, 22 October 2013 08:57 |
chris_torrence@NOSPAM
Messages: 528
Registered: March 2007
|
Senior Member |
|
|
On Tuesday, October 22, 2013 8:10:44 AM UTC-6, Paul van Delst wrote:
> Ha!
>
>
>
> It's probably my advancing age, but these special cases with regards to
>
> argument passing are really starting to annoy me... mostly because I
>
> *still* keep brain-fading about them, but also because these days I
>
> expect my code to do what I want, rather than what I tell it to do - a
>
> definite sign of old-codger-ism[*] :o).
>
>
>
> Time to translate the code to Fortran2003 I guess. Urg. (Which we sorta
>
> have to do anyway, I was just hoping not to need to do it for a couple
>
> more years.)
>
>
>
> cheers,
>
>
>
> paulv
>
>
>
> [*] Or, more likely, I think I'm in an "autonomous stage" but I'm really
>
> still in a "cognitive stage" with regards to programming skill.
>
> ( http://www.brainpickings.org/index.php/2013/10/17/ok-plateau)
>
>
>
> On 10/22/2013 09:39 AM, David Fanning wrote:
>
>> Paul van Delst writes:
>
>>
>
>>> That is, the creation of new object in the method doesn't do anything
>
>>> about the reference to the original object that was passed in, and
>
>>> eventually returned back to the caller?
>
>>
>
>> This appears to be the semi-passed-by-reference condition. ;-)
>
>>
>
>> Cheers,
>
>>
>
>> David
>
>>
>
>>
>
>>
Hi Paul,
I don't think this is a special case. It's also not "semi-passed-by-reference." The code is simply passing an expression into a routine, so IDL cannot store into it.
Cheers,
Chris
|
|
|
|
| Re: object argument passing behaviour changed in v8.2.2? [message #86273 is a reply to message #86272] |
Tue, 22 October 2013 09:47 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Chris Torrence writes:
> I don't think this is a special case. It's also not "semi-passed-by-reference." The code is simply passing an expression into a routine, so IDL cannot store into it.
The point is, it *does* store into it, even though it is being passed by
value!
The object reference is passed by value, but the object itself, as a
heap variable, is more like a variable that is passed by reference. This
gives this situation the semi-passed-by-reference feel.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: object argument passing behaviour changed in v8.2.2? [message #86274 is a reply to message #86272] |
Tue, 22 October 2013 09:59 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
On 10/22/2013 11:57 AM, Chris Torrence wrote:
>
> Hi Paul,
> I don't think this is a special case. It's also not
> "semi-passed-by-reference." The code is simply passing an expression
> into a routine, so IDL cannot store into it.
> Cheers, Chris
Well, that's not the case. Both your, and my corrected, test cases shows
that you *can* store into the array element reference (well, the object
that was referenced in that array element) in the callee.
It was the "redefinition" of the object in the routine (or method) that
was screwing things up.
I know it won't (can't) change anytime soon, but I find the fact that an
array element reference is considered an expression in IDL very
confusing. It just doesn't grok well.
IDL users should be shielded from under-the-hood details like argument
passing mechanisms, IMO (that's my Fortran90/95/2003 side talking).
cheers,
paulv
|
|
|
|
| Re: object argument passing behaviour changed in v8.2.2? [message #86275 is a reply to message #86274] |
Tue, 22 October 2013 10:17 |
chris_torrence@NOSPAM
Messages: 528
Registered: March 2007
|
Senior Member |
|
|
On Tuesday, October 22, 2013 10:59:18 AM UTC-6, Paul van Delst wrote:
> On 10/22/2013 11:57 AM, Chris Torrence wrote:
>
>>
>
>> Hi Paul,
>
>> I don't think this is a special case. It's also not
>
>> "semi-passed-by-reference." The code is simply passing an expression
>
>> into a routine, so IDL cannot store into it.
>
>> Cheers, Chris
>
>
>
> Well, that's not the case. Both your, and my corrected, test cases shows
>
> that you *can* store into the array element reference (well, the object
>
> that was referenced in that array element) in the callee.
>
>
>
> It was the "redefinition" of the object in the routine (or method) that
>
> was screwing things up.
>
>
>
> I know it won't (can't) change anytime soon, but I find the fact that an
>
> array element reference is considered an expression in IDL very
>
> confusing. It just doesn't grok well.
>
>
>
> IDL users should be shielded from under-the-hood details like argument
>
> passing mechanisms, IMO (that's my Fortran90/95/2003 side talking).
>
>
>
> cheers,
>
>
>
> paulv
Yep, I agree that a different decision would have been better. Unfortunately, we would have to travel back 30 years in time to tell David Stern... If I recall, Fortran 77 passed by reference (even for array elements), so David could have gotten it right... Oh well.
-Chris
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
