[Revvy]

In the spirit of release early, release often, here's the inaugural release of my experimental robotic debugger. Things to know:

• Press ctr+f6 to toggle the debugger while testing a world from the editor.
  
• The first robot in the "Watch robot" list is always the global robot
  
• The debugger opens in a separate application, so you're going to have to pay attention to which window is receiving input when pressing keys

In the debugger:

• F6 toggles following the active line
  
• F7 toggles a breakpoint for the current line
  
• F8 pauses execution
  
• F9 single steps a single command for the watched robot, or executes the rest of a cycle for the board if the robot's finished
  
• F10 continues normal execution
  
• F11 triggers the "Watch robot" menu in the main Megazeux window
  
• Up/down/page up/page down work like usual - the active robotic line is highlighted in green in case you get lost
  
• Escape closes the debugger

Known bugs:

• Everything crashes if a robot stops existing for any reason
  
• Don't even try to leave the current board while debugging right now
  
• While Megazeux pauses immediately when pressing F8 in the debugger, the robotic editor takes a bit to catch up
  
• Closing the debugger via ESC can cause Megazeux to crash on occasion
  
• The debugger doesn't give good feedback when stepping through 'end' and end of program
  
• Stepping through dialog boxes causes execution to continue afterwards
  
• Updating the watched robot's program via LOAD_BC or LOAD_ROBOT will not be reflected in the debugger

I'm expecting there to be about 1 million more bugs, so have at it. Feature requests, comments, patches, all good as well. Obtain the source tarball for this release at http://www.joshmatth...xdbgsrc.tar.bz2; I'm still working on getting a repo set up but I'm having some problems. The debugger should build by default with the normal configuration. Also, feedback on whether this works on MacOS or Windows would be rad.

[Wervyn]

Won't compile on mingw, which doesn't have sys/wait.h or a good way to include it. Although if someone who actually uses mingw on a regular basis can tell me I'm wrong, I'd be pleased. This is a shame, I would like to try this out.

"Still stuck in dependency hell."

[ajs]

He's using fork() which isn't portable. That's the only major issue, most of the other non-portable things are easily fixable.

EDIT: Also because this is fork() and exec() it can be reworked to use CreateProcess() on win32.

--ajs.

[Revvy]

I'm trying to set up a mingw32 cross-compile on Fedora right now, so hopefully I'll be addressing these issues in the near future.

[Dr Lancer-X]

I'd like a profiler!

[Revvy]

I figured out how to set up the Fedora MinGW cross-compile package, so I've now got a working (to a point) win32 build under wine. If you grab the source from the link above, it should have all of the newest changes. It seems to work, but there are some oddities, like how stepping seems to randomly not work. It would be nice to know if that's just a wine peculiarity or something I need to investigate on a windows box.

Also ajs, I had to make a few changes to some Makefiles to get the cross compile working. The MINGWBASE was incorrect (should be i686-pc-mingw32), and I'm not sure how to make mingw32-make pick up /usr/i686-pc-mingw32/sys-root/mingw/bin/sdl-config instead of the normal one, so I did some hardcoding. I also added a network_ldflags which links ws2_32.

There's a proper repository coming, I swear. Source tarballs just feel so opaque.

[Wervyn]

Quote

Also ajs, I had to make a few changes to some Makefiles to get the cross compile working. The MINGWBASE was incorrect (should be i686-pc-mingw32), and I'm not sure how to make mingw32-make pick up /usr/i686-pc-mingw32/sys-root/mingw/bin/sdl-config instead of the normal one, so I did some hardcoding. I also added a network_ldflags which links ws2_32.

Thanks a bunch, now it just fails outright:

$ make
  CC	   src/configure.c
/bin/sh: /usr/i686-pc-mingw32/sys-root/mingw/bin/sdl-config: No such file or directory
In file included from src/platform.h:27,
				 from src/event.h:27,
				 from src/configure.c:30:
src/platform_endian.h:33:17: error: SDL.h: No such file or directory
src/platform_endian.h:35:5: warning: "SDL_BYTEORDER" is not defined
...etc...

Quick way for me to remove this hardcoding so that it uses my install of SDL instead of trying to find one that doesn't exist?

"What do you mean it isn't the same thing?"

[Revvy]

Whoops, my bad. Go clear the SDLCONFIGBASE line in arch/mingw/Makefile.in

[ajs]

Revvy, on Feb 2 2010, 01:10 PM, said:

The MINGWBASE was incorrect (should be i686-pc-mingw32), and I'm not sure how to make mingw32-make pick up /usr/i686-pc-mingw32/sys-root/mingw/bin/sdl-config instead of the normal one, so I did some hardcoding. I also added a network_ldflags which links ws2_32.

MINGWBASE isn't incorrect, it's just your distro's cross compiler chose a different one to the one used by Debian. If such a fundamental thing was broken, my nightly build process would not work correctly.

Hardcoding sdl-config is broken, you should add it to your PATH before invoking make, like all the other cross builds do (see ../scripts/build.sh from MegaZeux SVN).

Adding ws2_32 to ldflags is not a correct fix, because MegaZeux's network layer dynamically opens winsock or ws2_32 depending on Windows version; they are never linked directly. I suggest you look at the indirection layer that already exists and fix whatever you've added to use it, otherwise you will break compatibility. There's plenty of commenting for this stuff in host.c, describing how the libraries are loaded and why they're not linked directly.

EDIT: This change is the problem. Why was it necessary?

-#undef  FD_ISSET
-#define FD_ISSET(fd,set) socksyms.__WSAFDIsSet((SOCKET)(fd),(fd_set *)(set))
+//#undef  FD_ISSET
+//#define FD_ISSET(fd,set) socksyms.__WSAFDIsSet((SOCKET)(fd),(fd_set *)(set))

--ajs.

[Revvy]

All good and valid points, ajs, thanks. I've undone all of my spur-of-the-moment hacks to the build system, and hidden the FD_ISSET bit behind a __WIN32__ define, because it breaks the build under Fedora. I think the extra check that MINGWBASE="" in config.sh is worth leaving in, however. New source bundle uploaded with all changes made.

[ajs]

I'll add some logic to detect one of these two variants. As for the FD_ISSET thing I think it should work on Linux too so I'll need to investigate why it doesn't on Fedora.

--ajs.

[Revvy]

Isn't the socksyms structure being referenced by the #define a windows-only thing?

[ajs]

Yes, quite right. I had another look at this and I can see now why it won't build. It's because you're defining NETWORK_DEADCODE which normally isn't defined. This FD_ISSET hack definitely is a win32 thing, and should be moved inside the WIN32 section where the socksyms/platform_XXX stuff is done. The reason it hasn't been on mainline is because it then produces an unused define warning.

So your compile error is understandable, the original fix wasn't correct, but the new one sounds like it would be.

If you can spare the time I'd like it if you could deprecate NETWORK_DEADCODE or at least move functions you ARE using outside of the define. Then you can move this FD_ISSET hack back into the WIN32 section, without adding another WIN32 section.

--ajs.

[Revvy]

ajs, on Feb 3 2010, 06:10 AM, said:

If you can spare the time I'd like it if you could deprecate NETWORK_DEADCODE or at least move functions you ARE using outside of the define. Then you can move this FD_ISSET hack back into the WIN32 section, without adding another WIN32 section.

Done, uploaded. Also, new known bug: I apparently broke single stepping shortly before release. Megazeux seems to get stuck in a loop of only ever updating the watched robot when stepping, so that's something I'll have to look into.

[Revvy]

Official repository is now at github.

[Revvy]

Boom! I'm travelling through Norway right now with a really underpowered netbook, so this is the only code I can work on at the moment. The source on github is rebased to head, single stepping now actually works (whether it's "correct" or not is still unsure), and the debugger won't hang if you are watching a robot when another one hits a breakpoint. It's still pretty untested in most situations, so see if you can break it please?

[Revvy]

Actually I pushed some fixes today which do solve a significant number of expected crashes. Also, the X/Y values for the robot being watched now update in real time, which is pretty cool.