ConfigParser items("symbols") not iterable in ShedSkin

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create file "a.py":

---
#!/usr/bin/env python

import ConfigParser

#input_file = open("C64_known_addresses.INI")
p = ConfigParser.ConfigParser()
p.read("../../symbols.INI")
#for address, name in p.items("symbols"):
#    print(address)
#    print(name)

for entry in p.items("symbols"):
    print(entry)

---
2. run "shedskin a.py" (from GIT yesterday or so)
3. run "make"
a.cpp:30:5: error: cannot convert 
‘__shedskin__::list<__shedskin__::tuple2<__shedskin__::str*, 
__shedskin__::str*>*>*’ to ‘__shedskin__::dict<__shedskin__::str*, 
__shedskin__::str*>*’ in assignment

Original issue reported on code.google.com by danny.m...@gmail.com on 9 Oct 2011 at 11:05

[GoogleCodeExporter]

thanks danny :-)) I haven't checked recently, but how is your project going..? 
are you using this for your emu? 

I fixed this and another problem it uncovered in GIT. thanks again!!

Original comment by mark.duf...@gmail.com on 11 Oct 2011 at 4:09

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

You're welcome :-)

By now, I implemented IEC bus support and a very simple 1541 D64 loader (as an 
external process, so the "cable" is the two pipes between the emu and the d1541 
process, hehe) in the emu, but so far it gets stuck somewhere in the loader 
(after it has loaded almost the entire thing, bah). I think it has something to 
do with file bufferring on the host, I'm not sure...

Oh well, in order to be able to debug this well I added a symbol table to the 
emu, so when you enable disassembly, you now get the symbol names instead of 
addresses, if known.

Also, if it is a JSR and the symbol is known, it will not print disasm until it 
returned from the subroutine. This makes disasm a lot less noisy.

Oh well, off to debugging signalling again... I feel like a medieval semaphore 
flag wielder for some reason. rise red flag, wait, lower blue flag, wait, rise 
blue flag, ...

Original comment by danny.m...@gmail.com on 11 Oct 2011 at 4:42