Bizare yaml values

i have tk gui which owns a config object - derived from hash. i have an
options menu configured with a callback that updates this has and another menu
that allows one to view this hash as a ‘to_yaml’ string. after updating it
the values seem correct (inspect) and my code works properly, however the
to_yaml output shows bizarre values where it has been updated such as

*id001
&id001

the code in question is much to long to post, but i’m wondering what the
meaning of such values might mean and what type of situation might create
them. i’m guessing it may have something to do with proc bindings and the
present value of a hash… but i’m pretty much at a loss at where to start
looking even…

-a

···

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
URL :: Solar-Terrestrial Physics Data | NCEI
TRY :: for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done
===============================================================================

Ara.T.Howard wrote:

i have tk gui which owns a config object - derived from hash. i have an
options menu configured with a callback that updates this has and another menu
that allows one to view this hash as a ‘to_yaml’ string. after updating it
the values seem correct (inspect) and my code works properly, however the
to_yaml output shows bizarre values where it has been updated such as

*id001
&id001

the code in question is much to long to post, but i’m wondering what the
meaning of such values might mean and what type of situation might create
them. i’m guessing it may have something to do with proc bindings and the
present value of a hash… but i’m pretty much at a loss at where to start
looking even…

No worries. It’s just references:

irb(main):008:0> x =
=>
irb(main):009:0> y = x
=>
irb(main):010:0> z = [x,y]
=> [, ]
irb(main):011:0> puts z.to_yaml

···
  • &id001
  • *id001
    => nil

Just for fun…

irb(main):012:0> x =
=>
irb(main):013:0> x << x
=> [[…]]
irb(main):014:0> puts x.to_yaml
— &id001

  • *id001
    => nil

Ara.T.Howard wrote:

i have tk gui which owns a config object - derived from hash. i have an
options menu configured with a callback that updates this has and another menu
that allows one to view this hash as a ‘to_yaml’ string. after updating it
the values seem correct (inspect) and my code works properly, however the
to_yaml output shows bizarre values where it has been updated such as

*id001
&id001

the code in question is much to long to post, but i’m wondering what the
meaning of such values might mean and what type of situation might create
them. i’m guessing it may have something to do with proc bindings and the
present value of a hash… but i’m pretty much at a loss at where to start
looking even…

No worries. It’s just references:

ah - should have guessed - but i’m still worried! :wink:

irb(main):008:0> x =
=>
irb(main):009:0> y = x
=>
irb(main):010:0> z = [x,y]
=> [, ]
irb(main):011:0> puts z.to_yaml

  • &id001
  • *id001
    => nil

Just for fun…

irb(main):012:0> x =
=>
irb(main):013:0> x << x
=> [[…]]
irb(main):014:0> puts x.to_yaml
— &id001

  • *id001
    => nil

that’s plain enough. but my situation is a bit different: i have a config
which is read in and YAML::load’d:



gll:
program : gll_16_new
rm_edge : true
limits : [ 36, 68, 8, 97 ]
direction : ascending
dem_path : /dmsp/reference/srtm/
ols_flag_definitions : /dmsp/reference/ref/ols_flags/OLS_flags.txt
path : [ /dmsp/moby-1-1/zwdevel/dmspnl/ ]
verbose : true
use_middle_only : true

and if i display THIS config (Hash) in a TkText using #to_yaml there are NO
references. however, when i update limits from within the callback proc of a
tk button - something like:

limits = [TkVariable.new, TkVariable.new, TkVariable.new, TkVariable.new]

ul_lon = TkEntry.new w, :textvariable => limits[0]
ul_lat = TkEntry.new w, :textvariable => limits[1]
lr_lon = TkEntry.new w, :textvariable => limits[2]
lr_lat = TkEntry.new w, :textvariable => limits[3]

button = TkButton.new w

button.configure :command => lambda {
limits.map!{|limit| limit.to_s.to_f}
@config[‘gll’][‘limits’] = limits
}

and then re0display the config it appears as


gll:

limits: &id001

so, what i am asking is: it was an array before, and it’s an array after,
both arrays contain four floats (i can see this if i use pretty printing or
inspect instead of to_yaml to display the object) - so WHY does it display as
a reference the second time?

-a

···

On Tue, 9 Mar 2004, Joel VanderWerf wrote:

===============================================================================

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
URL :: Solar-Terrestrial Physics Data | NCEI
TRY :: for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done
===============================================================================

[“Ara.T.Howard” ahoward@fattire.ngdc.noaa.gov, 2004-03-09 15.34 CET]

gll:

limits: &id001

This is an anchor (‘limits:’ should have the array description, too,
probably below). A reference to ‘limits’ can be made later with
‘*id001’.

See YAML Reference Card

and

http://yaml4r.sourceforge.net/cookbook/#aliases_and_anchors .

[“Ara.T.Howard” ahoward@fattire.ngdc.noaa.gov, 2004-03-09 15.34 CET]

gll:

limits: &id001

This is an anchor (‘limits:’ should have the array description, too,
probably below). A reference to ‘limits’ can be made later with ‘*id001’.

yes - i see both but never the data. i’ve gotten around it by taking a #dup,
but this sounds like it may be a bug eh?

  • i can print the variable
  • inspect can see it
  • pp can see it
  • marshal can see it
  • yaml can’t

-a

···

On Wed, 10 Mar 2004, Carlos wrote:

See YAML Reference Card

and

http://yaml4r.sourceforge.net/cookbook/#aliases_and_anchors .

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
URL :: Solar-Terrestrial Physics Data | NCEI
TRY :: for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done
===============================================================================