| Re: VISualize 2009 summary [message #66197] |
Wed, 22 April 2009 03:17 |
T.H.
Messages: 13
Registered: December 2008
|
Junior Member |
|
|
On Apr 21, 4:07 pm, Bob <bobnnamt...@gmail.com> wrote:
> On Apr 20, 12:01 pm, mgalloy <mgal...@gmail.com> wrote:
>
>> I'm going to write a few posts about the contents of last week's
>> VISualize 2009 seminar in Washington, DC, starting off with ITT VIS'
>> presentation about the roadmap for IDL 7.1 and beyond:
>
>> http://michaelgalloy.com/2009/04/20/idl-roadmap.html
>
>> Hopefully these will be useful for those unable to attend. I know I had
>> a great time, especially meeting face to face those of you I had only
>> communicated with online previously.
>
>> Mike
>> --www.michaelgalloy.com
>> Associate Research Scientist
>> Tech-X Corporation
>
> Out of the list of 13 items, I see 3 that interest me (to say that the
> development of IDL is going in the wrong direction is an
> understatement):
>
> 24-bit color PostScript in direct graphics
> modern language features (associative arrays, lists, operator
> overloading)
> modern UI toolkit
>
> The hashes and lists are especially promising, but where is the
> garbage collector? Certainly most people would take a garbage
> collector before most items on the list. Since a garbage collector
> seems unthinkable for ITT (and RSI before them), they should consider
> a reference type. This would be like a pointer to heap variable
> except that it would be guaranteed that only one variable would be
> pointing to it (sort of like an allocatable in Fortran). Since only
> one variable would be pointing to it, the heap variable could be
> garbage collected whenever the reference variable went out of scope or
> a new variable was assigned to it (this is exactly the same as a
> "normal" IDL variable so all the code is there to do it). As a
> further benefit the need to de-reference the variable to get at what
> it was pointing to would not be necessary which would clean up code
> using reference variables in structures or arrays. Here is an example
> how it could be used:
>
> ; define a structure with two reference variables (one defined and one
> not)
> struct = {a:ref_new(fltarr(10)), b:ref_new()}
>
> ; assign the 2nd one (note that ref_new is need to assign a new
> reference)
> struct.b = ref_new(fltarr(20))
>
> ; re-assign tag a of the structure
> ; (the heap variable containing fltarr(10) is garbage collected)
> struct.a = ref_new(fltarr(15))
>
> ; note that no "*" is need to de-reference struct.a
> print, struct.a[2:5]
>
> ; if struct.a was a pointer than this would be print, (*struct.a)
> [2:5], yuk
>
> For me at least, 95% of my usage of pointers in IDL is for use in
> structures or ptrarr's and reference variables could eliminate this
> need. These could be easily garbage collected and provide the added
> benefit of eliminating the (*ptr)[] syntax which is hard to read and
> error prone.
>
> What do you think?
I think that IDL has a lot of needs but a garbage collector is pretty
low on the list since with proper programming all of your pointers
will be tracked and handled anyway. I've very excited to see plans
that they have for modernizing the language and interactive graphics.
Mike, Thanks for the post!
|
|
|
|
| Re: VISualize 2009 summary [message #66204 is a reply to message #66197] |
Tue, 21 April 2009 13:07  |
Bob[4]
Messages: 24
Registered: April 2009
|
Junior Member |
|
|
On Apr 20, 12:01 pm, mgalloy <mgal...@gmail.com> wrote:
> I'm going to write a few posts about the contents of last week's
> VISualize 2009 seminar in Washington, DC, starting off with ITT VIS'
> presentation about the roadmap for IDL 7.1 and beyond:
>
> http://michaelgalloy.com/2009/04/20/idl-roadmap.html
>
> Hopefully these will be useful for those unable to attend. I know I had
> a great time, especially meeting face to face those of you I had only
> communicated with online previously.
>
> Mike
> --www.michaelgalloy.com
> Associate Research Scientist
> Tech-X Corporation
Out of the list of 13 items, I see 3 that interest me (to say that the
development of IDL is going in the wrong direction is an
understatement):
24-bit color PostScript in direct graphics
modern language features (associative arrays, lists, operator
overloading)
modern UI toolkit
The hashes and lists are especially promising, but where is the
garbage collector? Certainly most people would take a garbage
collector before most items on the list. Since a garbage collector
seems unthinkable for ITT (and RSI before them), they should consider
a reference type. This would be like a pointer to heap variable
except that it would be guaranteed that only one variable would be
pointing to it (sort of like an allocatable in Fortran). Since only
one variable would be pointing to it, the heap variable could be
garbage collected whenever the reference variable went out of scope or
a new variable was assigned to it (this is exactly the same as a
"normal" IDL variable so all the code is there to do it). As a
further benefit the need to de-reference the variable to get at what
it was pointing to would not be necessary which would clean up code
using reference variables in structures or arrays. Here is an example
how it could be used:
; define a structure with two reference variables (one defined and one
not)
struct = {a:ref_new(fltarr(10)), b:ref_new()}
; assign the 2nd one (note that ref_new is need to assign a new
reference)
struct.b = ref_new(fltarr(20))
; re-assign tag a of the structure
; (the heap variable containing fltarr(10) is garbage collected)
struct.a = ref_new(fltarr(15))
; note that no "*" is need to de-reference struct.a
print, struct.a[2:5]
; if struct.a was a pointer than this would be print, (*struct.a)
[2:5], yuk
For me at least, 95% of my usage of pointers in IDL is for use in
structures or ptrarr's and reference variables could eliminate this
need. These could be easily garbage collected and provide the added
benefit of eliminating the (*ptr)[] syntax which is hard to read and
error prone.
What do you think?
|
|
|
|
| Re: VISualize 2009 summary [message #66212 is a reply to message #66204] |
Mon, 20 April 2009 22:33 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
"Jeff N." <jeffnettles4870@gmail.com> wrote:
> Excellent! I wanted to attend,but had another meeting that week so i'm
> looking forward to your posts. I'm also crossing my fingers that when
> i read about the roadmap for improving IDL i see the word "postscript"
> mentioned prominently!
Then you should be happy since the #1 item (at least the way that I
ordered them) is 24-bit color for PostScript.
Mike
--
www michaelgalloy.com
Associate Research Scientist
Tech-X Corporation
|
|
|
|
| Re: VISualize 2009 summary [message #66213 is a reply to message #66212] |
Mon, 20 April 2009 17:48 |
jeffnettles4870
Messages: 111
Registered: October 2006
|
Senior Member |
|
|
On Apr 20, 2:01 pm, mgalloy <mgal...@gmail.com> wrote:
> I'm going to write a few posts about the contents of last week's
> VISualize 2009 seminar in Washington, DC, starting off with ITT VIS'
> presentation about the roadmap for IDL 7.1 and beyond:
>
> http://michaelgalloy.com/2009/04/20/idl-roadmap.html
>
> Hopefully these will be useful for those unable to attend. I know I had
> a great time, especially meeting face to face those of you I had only
> communicated with online previously.
>
> Mike
> --www.michaelgalloy.com
> Associate Research Scientist
> Tech-X Corporation
Excellent! I wanted to attend,but had another meeting that week so i'm
looking forward to your posts. I'm also crossing my fingers that when
i read about the roadmap for improving IDL i see the word "postscript"
mentioned prominently!
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
