enumerated list type inference doesn't work

[GoogleCodeExporter]

class A(object):
        status_positions = ["C", "Z", "I", "D", "B", "5", "V", "N"]

        def pop_status(self):
                flags_bin = 42
                flags = set([(flag_name if (flags_bin & (1 << flag_bit)) != 0 else None) for flag_bit, flag_name in enumerate(self.__class__.status_positions)])
                print(flags)                                                                                                               

a = A()
a.pop_status()

*** SHED SKIN Python-to-C++ Compiler 0.5 ***
Copyright 2005-2010 Mark Dufour; License GNU GPL version 3 (See LICENSE)

[iterative type analysis..]
**
iterations: 2 templates: 75
[generating c++ code..]
*WARNING* a.py:8: variable 'flag_bit' has no type
*WARNING* a.py:8: variable 'flag_name' has no type

Original issue reported on code.google.com by danny.m...@gmail.com on 15 Oct 2010 at 9:34

Attachments:

• a.py

[GoogleCodeExporter]

Just

for flag_bit in range(len(self.__class__.status_positions)):
  print(flag_bit)

doesn't work either... Weird...

Original comment by danny.m...@gmail.com on 15 Oct 2010 at 9:40

[GoogleCodeExporter]

thanks danny! changing 'self.__class__' into 'A' makes it work. passing around 
classes is not supported by shedskin. please see the tutorial for these and 
other limitations of using shedskin. it's true shedskin should probably put in 
more effort to display clear error messages.. for 0.6 (to be released today), I 
improved several other warnings and errors, but there's clearly more 
improvement possible in this area.. 

Original comment by mark.duf...@gmail.com on 16 Oct 2010 at 9:01

• Changed state: Done

[GoogleCodeExporter]

Yeah, thanks, it works now. 

Makes sense since C++ doesn't support metaclasses, so how would one map 
"self.__class__" to "the current class" as opposed to "just A"...

In this case the reason I wrote it that way wasn't to make it pick up derived 
classes but to make maintainance easier (if I change the class name, don't have 
to change class code).

Well, thanks again. I just compiled and ran my C64 emulator in ShedSkin (and 
C++) and the Basic is sitting there with the usual greeting screen on blue 
background ;-) yay

Original comment by danny.m...@gmail.com on 16 Oct 2010 at 11:59

[GoogleCodeExporter]

woah! :) could I see the source code..?

Original comment by mark.duf...@gmail.com on 16 Oct 2010 at 12:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sure.
http://svn.nomike.com/playground/trunk/emu/C64/
The main file is "c64.py".
This directory contains all the things that are translated by shedskin (i.e. 
"shedskin c64.py"). 
After that, I manually change the Makefile to prefer "lib" to ".". Not sure 
what the official way is...
"lib" contains the native C++ stuff (i.e. graphics).
"pygtk_s" is the same in pure Python (no chance ShedSkin can translate that ;-) 
)
(It works if you use the usual VICE ROM TAR)

Ah, btw, I also have to change all the hpp files and remove the "#include" from 
them and replace them by forward declarations. i.e. like

NO #include "timer.hpp"
namespace __timer__ {  <--- added
  class Timer;  <--- added
};  <--- added

namespace __vic_ii__ {
  class VIC_II {
    __timer__::Timer* timer;
  };
}

Otherwhise it will have problems with cross includes (a includes b, b includes 
a), a problem which doesn't exist in the original Python.

Original comment by danny.m...@gmail.com on 16 Oct 2010 at 4:57

[GoogleCodeExporter]

wow, cool :) thanks for putting this in the public domain! I will have a look 
tomorrow to see if I can still add it to the example set for 0.6 (released 
today)..

Original comment by mark.duf...@gmail.com on 16 Oct 2010 at 5:50

[GoogleCodeExporter]

okay, I spent a few hours wrestling the code into something that works 
out-of-the-box with 0.6, and added the result to the examples tarball for 0.6! 
the front-end also works, by compiling c64.py as an extension module.. :D it's 
wonderful to be able to type commands into the c64 screen! unfortunately it 
always seems to bail out after 10 characters or so, and it gives errors when 
you press space or enter, for example (unimplemented instructions ANC, RRA?) 
but I guess you will fix this soon. please keep me posted on your progress!

I worked around the following problems, and will fix them for 0.7:

-inheritance across modules (Memory) apparently doesn't work with shedskin -e. 
so I had to put everything into a single module, ugh. should be easy to fix, 
but I don't want to change 0.6 anymore.
-I changed the "AND" method into "ANDX", because of a conflict with some C 
macro. also easy to fix.
-there was some dynamic mixing of strings and keycodes. I removed the keycode 
stuff.
-properties are not exported yet, so I had to make border_color into a normal 
attribute. 
-I ran into a problem when updating 'pressed_keys' across from CPython. so I 
changed the check against pressed_keys not to use __contains__, and that works 
better. I reproduced this with a 3-line program, so it should also be easy to 
fix.

thanks again for releasing your program in the public domain! it's truly a 
worthy 50th example.. ;-) hopefully you will keep improving it, so we can see 
how far along shedskin 0.6 is able to go..

Original comment by mark.duf...@gmail.com on 17 Oct 2010 at 4:18

[GoogleCodeExporter]

Just tried it from the examples tarball, very nice... you got it to work much 
better than I did... Typing stuff in the running emulator is fluid now... yay 
:-)

> it always seems to bail out after 10 characters or so

Yeah, I didn't get that far before ;-) So bugs could hide there...

You should have seen how slow it was to pick up keypresses in CPython (before 
ShedSkin)... like *holds keeeeeeey down* ... *wonders* *hooooooolds keeeey 
down* *finger is starting to become sore* ... Like that :-)

It's fluid now... so fluid... cool :D

> and it gives errors when you press space or enter, for example (unimplemented 
instructions ANC, RRA?) 

Sorry, I forgot the addressing modes for the DEC instruction so the program 
counter went out of sync after the first multi-byte DEC instruction, my bad... 
Should work with the change:

--- o/shedskin-examples-0.6/c64.py  2010-10-17 17:57:15.000000000 +0200
+++ shedskin-examples-0.6/c64.py    2010-10-17 23:13:45.000000000 +0200
@@ -285,6 +285,7 @@ class CPU(object):
            CPU.EOR_addressing_modes if mnem == "EOR" else \
            CPU.ORA_addressing_modes if mnem == "ORA" else \
            CPU.INC_addressing_modes if mnem == "INC" else \
+           CPU.DEC_addressing_modes if mnem == "DEC" else \
            CPU.ASL_addressing_modes if mnem == "ASL" else \
            CPU.LSR_addressing_modes if mnem == "LSR" else \
            CPU.ROL_addressing_modes if mnem == "ROL" else \
@@ -1257,9 +1258,17 @@ class CPU(object):
        self.write_register("Y", result)
        self.update_flags_by_number(result)

+   DEC_addressing_modes = {
+       0xC6: "Z",
+       0xD6: "Z+X",
+       0xCE: "ABS",
+       0xDE: "ABS+X",
+        }
    def DEC(self, opcode = 0xC6):
-       result = (self.read_register("A") - 1) & 0xFF
-       self.write_register("A", result)
+       addressing_mode = CPU.DEC_addressing_modes[opcode]
+       value = self.load_value_unadvancing(addressing_mode)
+       result = (value - 1) & 0xFF
+       self.store_value(addressing_mode, result)
        self.update_flags_by_number(result)

    INC_addressing_modes = {

>-there was some dynamic mixing of strings and keycodes. I removed the keycode 
stuff.

Yeah, I changed a lot of things in the Gtk part when trying to get the native 
C++ gdisplay to work, so it probably was half-broken anyway :P Thanks.

Still not sure how to handle keycodes. Native keycodes would be in pygtk's 
module "gtk.keysyms" and then the "cia.py" wouldn't be able to find out which 
key is which (since it can't import "gtk.keysyms" in the ShedSkin version).
On the other hand, using (non-interned?) strings means a lot of overhead for no 
good reason.
I really wish Python had a Symbol datatype...

>-I ran into a problem when updating 'pressed_keys' across from CPython. so I 
changed the check against pressed_keys not to use __contains__, and that works 
better. I reproduced this with a 3-line program, so it should also be easy to 
fix.

That's strange.
Note that key-press-event will be called repeatedly by Gtk when you keep the 
key down on your keyboard. For this reason, one of the next changes I'll commit 
(already did the change locally) is that it checks whether the key was already 
in the pressed_keys set and only if it wasn't, cause an interrupt. Otherwise it 
will cause a lot of needless work for the emulator.

So if __contains__ doesn't work, baad :)

>thanks again for releasing your program in the public domain! it's truly a 
worthy 50th example.. ;-) hopefully you will keep improving it, so we can see 
how far along shedskin 0.6 is able to go..

You're welcome :-)

Original comment by danny.m...@gmail.com on 17 Oct 2010 at 9:26

[GoogleCodeExporter]

I guess part of the speedup is from doing multiple fetch-executes per timer 
interval, but the raw performance is a lot better after compilation in any 
case, about 25 times faster here. I can't test with psyco at the moment, 
because it doesn't work on 64 bit..

anyway, thanks for the quick patch! I will test it and update the example 
tarball if it works significantly better..

Original comment by mark.duf...@gmail.com on 18 Oct 2010 at 12:12

[GoogleCodeExporter]

on second thought, it looks like you are quickly improving things, so it's 
probably better to wait a few days to see what else you improve.. :-)

Original comment by mark.duf...@gmail.com on 18 Oct 2010 at 12:24

[GoogleCodeExporter]

hi danny,

I made some improvements in GIT, so I was able to split things up in separate 
files again. see examples/c64_main and examples/c64/.. here:

http://gitorious.org/shedskin

if you'd like to adopt this or a similar setup for your project, I guess it 
would make it easy for us to sync the code.. :) (there should be no real 
difference now other than pulling the gtk stuff to c64_main.py, and moving some 
non-gtk stuff into c64.py)

Original comment by mark.duf...@gmail.com on 25 Oct 2010 at 1:42

[GoogleCodeExporter]

hi danny,

I was wondering if you have been working on your emu lately, because I don't 
see any updates in SVN. please let me know if you have a further improved 
version that I could try with shedskin! ;)

Original comment by mark.duf...@gmail.com on 30 Oct 2010 at 5:33

[GoogleCodeExporter]

Hi Mark,

yeah, I wondered why it said "0 BYTES FREE" and checked which code was causing 
it and turns out I has a mistake updating the flags in ADD and SBC (and CMP). 

So I "fixed" it and now I have an endless loop in the printer in the ROM. :-)
What it does is: it checks how many memory cells there are until it encounters 
the first ROM byte (i.e. the first byte it cannot change) and stores that count 
(eventually in registers A and X).
Then, for some reason, it calls the BASIC convert-to-float routine, then 
outputs that float. The convert-to-float routine never returns. 

(342.43 BYTES FREE ? :-) )

I tried to find why for days now but no go...

Sigh, why can't I write bug-free code ;-)

cheers,
   Danny

Original comment by danny.m...@gmail.com on 31 Oct 2010 at 7:29

[GoogleCodeExporter]

oh, I've been working on shedskin for 5 years now, and most of the time I'm 
chasing silly bugs as well.. it comes with the job I guess :-)

have you thought about running existing 6502 unit or other tests? a quick 
googling leads here: 
http://github.com/mnaberez/py65/blob/master/src/py65/tests/devices/test_mpu6502.
py. or perhaps to use a 6502 C compiler (http://www.cc65.org/?) to compile and 
run something simpler than the whole boot process..? for difficult to debug 
code, it often pays to invest some time improving your testing strategy..

Original comment by mark.duf...@gmail.com on 31 Oct 2010 at 10:00

[GoogleCodeExporter]

yeah :-)

Tried that unit test and indeed it failed 173 tests.
Fixed cpu.py (and committed it) so that it only fails 6 now, most of them 
questionable tests to begin with ;-)

Original comment by danny.m...@gmail.com on 31 Oct 2010 at 8:25

[GoogleCodeExporter]

Aaaand booting works again now :)

Thanks for the tips, it was a lot easier to find the bugs that way.

So you can try it with Shedskin now :-)

Original comment by danny.m...@gmail.com on 1 Nov 2010 at 8:58

[GoogleCodeExporter]

hehe, I've had my share of pulling my hair out over difficult to locate bugs.. 
:P glad the tips were of use.

are you planning on modifying your version so it's more similar to the current 
version in GIT..? that would make it a lot easier to sync our versions.. 

Original comment by mark.duf...@gmail.com on 1 Nov 2010 at 10:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Found it from one our your posts to the group, but it's not that discoverable 
:-)

I called diff to find out the changes you made:
- removed gdisplay.py, moving TextView class into c64.py
- changed CIA1 key scanning in cia.py to use strings
- renamed "AND" method in cpu.py
- removed (bad) "unit test" from cpu.py
- removed repaint() call from vic_ii.py (2 calls)

Should I do these as well?

Original comment by danny.m...@gmail.com on 6 Nov 2010 at 8:03

[GoogleCodeExporter]

ah, sorry, yes. I should automatically sync SVN from GIT. perhaps I can look at 
that later this week.

I think the first difference you mention would be useful to sync, because that 
probably gives the largest diffs, and something like it is probably needed to 
be able to compile your project. please let me know if you have another 
solution..

iirc, the key scanning code mixed ints and strings, which is not supported by 
shedskin. if you want to be able to directly compile your code, this needs to 
be changed. I didn't fix the AND problem yet either, so it's currently needed 
to rename it to compile as well.

the other points I don't remember changing. 

in any case, if you have a version there that compiles out-of-the-box, I'd be 
glad to just copy it, so I won't have to maintain my own version.. :-)

Original comment by mark.duf...@gmail.com on 7 Nov 2010 at 9:52

[GoogleCodeExporter]

hm, apparently a recent change broke the c64 example. I just fixed the problem 
in GIT, and also the problem that CPU_AND is an included C MACRO.. so CPU.ANDX 
can become CPU.AND again.

again, it would be great if your version works out-of-the-box with shedskin 
GIT, so I can drop mine.. 

btw, does your version work well enough yet to type in and run little BASIC 
programs..? thinking about that gives me some warm memories from my childhood.. 
;-)

Original comment by mark.duf...@gmail.com on 16 Nov 2010 at 4:07

[GoogleCodeExporter]

Hi,

I moved TextView to "c64.py" now, so it should work out of the box.

Good to know that the "AND" works now, I don't have to put (more, yes yes) 
weird special cases into the cpu emulator that way ;-)

So far I tested "POKE646,15" which works and a small program:

64INPUTA
99GOTO64

Which works, too.
Unfortunately the space and backspace key don't work right now, still searching 
why. The 1 key does work somewhat flaky. Other keys seem to work fine.
Hardware emulation is hard ;-)

CPU-wise, it should work, so normal BASIC programs should be okay.
Sound and floppy are not implemented yet...

Graphics support is err... minimal (text-only right now).
Sigh, I should at least implement sprites, but first have to decide how to do 
caching (after all, don't want to generate new pixbufs every time I redraw the 
screen  :) )

Anyway, I "git pull"ed your shedskin updates and installed it via setup.py, 
then tried
shedskin -e c64.py

and I get 
  in shared.py line 44
IOError: [Errno 2] No such file or directory 
'/usr/lib/python2.6/site-packages/shedskin/illegal'

Which doesn't exist. Hmm...

Original comment by danny.m...@gmail.com on 16 Nov 2010 at 9:35

[GoogleCodeExporter]

ah, I added a new file 'illegal', with illegal output names (such as CPU_AND.. 
:-)), but forgot to add it to setup.py.. could you please try to pull again?

will reply to the rest of your comments tomorrow, falling asleep on my 
keyboard.. :-)

Original comment by mark.duf...@gmail.com on 16 Nov 2010 at 9:59

[GoogleCodeExporter]

hrm, just a silly suggestion perhaps, but have you tried comparing what happens 
after pressing such a key on an actual C64 (powercartridge?) or using another 
emulator? I can imagine doing a memory dump or tracing the program counter 
could really help in tracking down the problem..

Original comment by mark.duf...@gmail.com on 17 Nov 2010 at 11:35

[GoogleCodeExporter]

Thanks, I pulled again and it works now.

About the actual C64 and other emulators, good idea, I'll try that later this 
week :)

Original comment by danny.m...@gmail.com on 17 Nov 2010 at 5:36

[GoogleCodeExporter]

I fixed the darn keyboard bug, seems to work fine now :-)

Original comment by danny.m...@gmail.com on 7 Jan 2011 at 6:11

[GoogleCodeExporter]

that's great to hear! 

I will have a look at your SVN repo to see if I can easily sync with your 
current version.

what are your plans for the emu in the near future..?

Original comment by mark.duf...@gmail.com on 7 Jan 2011 at 6:30

[GoogleCodeExporter]

To add sprite support... definitely :-)

I even dug out an old quad-ruled paper booklet a few days ago where I drew some 
sprites and converted them to bytes and wrote down a Basic prog to display them 
some 15 years ago ;-)

Then I guess disk (and tape <- probably easier) support.

btw: Happy new year ^^

Original comment by danny.m...@gmail.com on 7 Jan 2011 at 7:14

[GoogleCodeExporter]

sounds good, keep me updated! :)

I synced the git version with your svn repository, and tested a little basic 
program.. works great! :D 

I also fixed some issues so all three control buttons are now working correctly 
in the git version. 

see c64_main.py and c64/* here:

http://gitorious.org/shedskin/mainline/trees/master/examples

c64/* is practically unchanged from SVN. c64_main.py was mostly updated with 
your gmonitor.py and gdisplay.py, iirc.

I measured the speedup from using shedskin again (shedskin c64 && make && time 
./c64), still around 20 times.

Original comment by mark.duf...@gmail.com on 7 Jan 2011 at 9:33

[GoogleCodeExporter]

Thanks :-)
Yeah, didn't use the control buttons in a long long time. Thanks for fixing 
them.

Btw I fixed the cursor problem, much easier to see where one is now - committed 
to SVN, but also commited a lot of spritey things to SVN but those are still 
mostly unused. If you just want the cursor to work, remove all the special 
cases "< 128" from TextView.repaint_pixmap . They were left over from when I 
didn't have inverse pixmaps of all the characters. 
So instead of "color if code < 128 else background_color" put just "color" 
etcetc.

Next up: getting my hands on the sprite data in memory from within the VIC :-)

Original comment by danny.m...@gmail.com on 8 Jan 2011 at 1:08

[GoogleCodeExporter]

thanks for the update! I will try to get the cursor working later today! :D

Original comment by mark.duf...@gmail.com on 8 Jan 2011 at 1:14

[GoogleCodeExporter]

alright, that looks better! 

I also did some profiling, and was able to more than double the performance 
with a very minor change (avoid calling overlays.values() all the time). it 
goes from 6.5 to 2.5 seconds here to execute 8 million instructions.

Original comment by mark.duf...@gmail.com on 9 Jan 2011 at 4:31

[GoogleCodeExporter]

I think changing some common string constants (such as "PC" or addressing 
modes) to integer constants (such as PC or ZPLUSX) would also help a lot after 
compilation. 

Original comment by mark.duf...@gmail.com on 9 Jan 2011 at 4:46

[GoogleCodeExporter]

Aha? What did you do instead of calling overlays.values ? Note that it's 
possible to enable/disable parts of the RAM pages on the C64, so it's not 
static.

I thought about the string constants and I think you are right, it would be 
faster to replace them by integers. I didn't do it before because it would have 
introduced strange numbers when debugging. But I think it's ok, I can use the 
ASCII code or something.

Original comment by danny.m...@gmail.com on 16 Jan 2011 at 10:16

[GoogleCodeExporter]

I don't remember exactly, but I think in GIT it's now calculated once, and only 
updated when it is changed. at least for the current version, it is only 
changed in a few specific places.

I didn't think about debugging, but it's probably a good option if you need the 
speed. not sure how much more intense things are going to be when you add lots 
of graphics stuff, or sound.. :-) 

Original comment by mark.duf...@gmail.com on 16 Jan 2011 at 10:22

[GoogleCodeExporter]

Ahh! You mean just the call to values() is slow and so you cache the result and 
update it whenever the original "overlays" is modified - you still do the 
traversal across the cache on read_memory, right?

I found your commit
http://gitorious.org/shedskin/mainline/commit/3ffb8ed669f701b1cc58127b19691dcdf7
48f470

and copied it over to my emu/C64 trunk. Thanks :-)

Yeah, I'm adding numeric constants right now, let's see.

Original comment by danny.m...@gmail.com on 16 Jan 2011 at 7:54

[GoogleCodeExporter]

For reference, 8mil instructions at 2.5s means ~3MHz. The original C64 was 
~1MHz, so the emulator is now 3 times as fast as the original.

Original comment by cala...@gmail.com on 22 Jan 2011 at 8:24

[GoogleCodeExporter]

..on a 3 Ghz PC :P

any updates, danny, or new performance measurements..? :) I'm releasing 0.7.1 
today, but perhaps for 0.8, I can sync things again?

Original comment by mark.duf...@gmail.com on 19 Feb 2011 at 11:42

[GoogleCodeExporter]

Sprites should be OK now.

As for loading actual programs, I've added a C64S T64 format loader, however it 
seems that isn't really just a tape format at all but rather like the disk 
drive format and also has been used in order to dump and load memory images 
(i.e. paging ;-) ). 
So there are three ways to support it: 
1) emulate a 1541 drive with the "files" on it
2) emulate a real tape using the T64 file (not sure whether that even works)
3) find out when the C64 has been booted into BASIC and then automagically 
sneakishly replace the RAM content in the emulator.

Still not sure which it will be in the end. I think in order to find out 
whether I got the format parser right, I'll do 3) at first...

Original comment by danny.m...@gmail.com on 26 Feb 2011 at 5:10

[GoogleCodeExporter]

Added T64 tape, D64(unfinished) and PRG loader now. However...

Is it possible to have "the mmu in the shedskin -e extension module" reference 
"a tape loader in the main python"?

Tried the obvious:
extensionmodule.py:
tape_loader = None
tape_loader.load(...)

shedskin -e extensionmodule.py

main.py: # not in the extension module, not compiled with shedskin
import extensionmodule
class TapeLoader(object):
  def load(self):
     ...
extensionmodule.tape_loader = TapeLoader()
extensionmodule.run()

It then compiles to:
 void *tape_loader;
Which I can't call any methods on, obviously :-(

Or is what I'm trying to do strange anyway?

I could always put the entire tape loader into the extension module as well, 
however in the (very) long term I wanted to use external loaders like 
git://github.com/adamv/c64-utils.git ... hmm...

So basically I'm just checking whether it would be possible, no harm done 
putting my 3 loaders inside the extension module for now...

Original comment by danny.m...@gmail.com on 25 Apr 2011 at 3:19

[GoogleCodeExporter]

Huh, I could have sworn there was a struct module in shedskin O_o
Tried to move the T64 loader into the shedskin extension module:
http://svn.nomike.com/playground/trunk/emu/C64/loaders/t64.py
However, shedskin -e says it can't find "struct"...

Original comment by danny.m...@gmail.com on 27 Apr 2011 at 9:28

[GoogleCodeExporter]

hah, no, there is only a partially functioning struct implementation, see 
examples/lib/struct*. type inference is currently a problem, because types 
depend on format strings, which don't have to be constant, and unpacking uses 
tuples, which we don't analyze internally for lengths > 2 at the moment.

we could relatively easily add some hacks so the basic patterns would work 
though. usually the format string is constant, and values are 'unpacked' right 
away, as in "a,b,c.. = struct.unpack('heu', data)". since I get requests for 
struct more often, perhaps it's time to sit down and just make this work.. :-) 

there are some simple workarounds that might allow you to easily 'call' 
arbitrary python code though. the main program could perhaps feed data into the 
mmu each time it asks the cpu to perform N cycles? I'm not sure about the 
details, but I imagine the c64 setting some IO registers to indicate it wants 
to load something, and the main python program could respond to that. 

if the interface to the loader is really simple, you could also open a pipe to 
any external program (e.g. t64.py), and just get the data through there. or 
even call an external program (os.system) to dump things in a file, and just 
read the file afterwards. both 'os' calls should work at this point already 
(under unix at least).

yeah, I guess in the long term you don't want to compile the whole program, 
just the core stuff that needs to be fast. 

another solution that might be considered more elegant (but that very probably 
won't work at the moment) is to define a minimal Tapeloader class in the 
extension module, with just enough content so type inference works, and pass 
python objects to shedskin that 'implement' this 'interface'. in fact I think I 
will try this to see what happens..

Original comment by mark.duf...@gmail.com on 27 Apr 2011 at 2:33

[GoogleCodeExporter]

btw, have you tried pypy on your code yet? it looks like their JIT is finally 
getting up to speed.. not sure if there's any real use for shedskin longterm 
once there's a really good JIT.

Original comment by mark.duf...@gmail.com on 27 Apr 2011 at 2:34

[GoogleCodeExporter]

okay, so this tape loader was the perfect trigger.. I just implemented basic 
struct support in GIT, so that this at least works (on my system):

header_format = "<32s2BHHH24s"
s1, b1, b2, h1, h2, h3, s2 = struct.unpack(header_format, 64*'0')
struct.calcsize(header_format)

the first arg to 'unpack' doesn't have to be constant, because shedskin sees 
the constant assignment above, but it does trigger a warning ('assuming 
constant format string'), at least for now.

I will ask in the newsgroup in anyone is interested in finishing the C++ side. 
the nasty type-inference stuff I just had to do myself, but it should be fun to 
fill in the rest.

Original comment by mark.duf...@gmail.com on 1 May 2011 at 1:13

[GoogleCodeExporter]

I also just added basic 'array' support, which turned out to be much easier 
than 'struct' support. probably not useful for your project though, but I 
thought I'd mention.

Original comment by mark.duf...@gmail.com on 5 May 2011 at 9:20

[GoogleCodeExporter]

Very nice :-)

My T64 loader seems to load stuff now within shedskin (see svn repo) - however 
I found a simple problem with the PRG loader which I isolated to the following:

#!/usr/bin/env python

import struct

a, = struct.unpack("<H", "aa")
print(a)
#error: invalid conversion from '__shedskin__::__ss_int' to 
'__shedskin__::tuple2<int, int>*'

Works fine for more than 1 argument to unpack.

Bah, I found The Hitchhikers Guide to the Galaxy for C64, but it's a D64 disk 
image.
Oh well, I have to get the tape version of Giana Sisters to work first, then :D
(Or implement a disk drive ^^)

Original comment by danny.m...@gmail.com on 15 May 2011 at 1:35

[GoogleCodeExporter]

Ah, as for pypy, no, I didn't try yet :-)
I shall try eventually, but first have to get Giana to work and a disk drive 
and... ^^

Original comment by danny.m...@gmail.com on 15 May 2011 at 2:13

[GoogleCodeExporter]

autsch, how embarrassing, the following doesn't work either:

a, = (1,)

I will try to fix this shortly. it has nothing to do with the struct module..

note that the struct module is really quite unfinished, it barely supports what 
was in the tape loader you showed me. the array module is fully implemented as 
of today, and I'm hoping struct will be within one or two weeks..

giana sisters, must be one of the best games ever ^^

Original comment by mark.duf...@gmail.com on 15 May 2011 at 2:31

[GoogleCodeExporter]

so are you really this far that you can realistically already have games like 
this work?? :D

if I can make a request, I'd love to have international karate 2 running! :D

Original comment by mark.duf...@gmail.com on 15 May 2011 at 2:33