Re: converting v3 to v4: traps

new topic     » goto parent     » topic index » view thread      » older message » newer message
AndySerpa said...

And that "works" in v4 (gives no error), but doesn't work the same way because any call to "task_schedule" (which is global) outside this file will still call the built-in, unless I declare this version "override" instead of global. (If called from a later point within the same file, it works as before.) Since no error is given and no crash is guaranteed, this could lead to some nasty bugs with converted programs.

It probably makes sense to throw a warning when something with the same name as a built-in is declared not as override.

AndySerpa said...

Anyway, I know I've got a few of these around in my libraries, and I can think of some others in 3rd party libraries (i.e. Method Euphoria). But there may be some I don't remember. Any easy and foolproof way to find them? I think there are a few programs around that will list all your declarations, or is there a tool somewhere I don't know about? (I normally don't use IDEs or anything, just pure TextPad w/ syntax highlighting.)

Also, a related question that also could cause some weird problems with converted programs in rare cases:

In v4 you are allowed to call a function that is declared later in the file, but if it is a built-in it will prefer the built-in. If it is a user-declared function, it will prefer the local version (declared below) even if there is a global version declared in another file (which is included "above"). This seems a bit inconsistent, but whatever, do I have this right?

In other words:

puts(1,"Hello") 
 
override puts(integer i, sequence s) 
   eu:puts(i,s) 
   eu:puts(i,"\nOVERRIDDEN PUTS!\n") 
end procedure 

The above will just output "Hello" since it prefers the built-in. (Works the same as v3.1 if "override" is changed to "global".)

I think this should be considered a bug, since it works differently than the way other scopes are resolved.

AndySerpa said...

Also, I didn't test it, but I assume if I do a routine_id("myputs") in that same spot I'm going to get the routine number for the same version as it is calling in that spot? (It is likely that any such problems caused by these new scoping rules with old code will involve a routine_id.)

Yes, you should get the same thing either via a direct call or routine_id.

AndySerpa said...

Any good way to track these traps down so I can run my old programs safely? (And yes, what may be "rare" might not be so rare with me because I do all kinds of crazy stuff with routine_ids and overriding of built-ins.)

First, start with the -strict command line switch, which turns on all warnings. This might be pretty large, especially for big GUI programs (the extra parameters in event handlers that are often not used). There is a way to fine tune this, though I'm not particularly familiar with how to do this.

You might also take a look at eudis, a new tool that comes with euphoria. It can produce disassembled version of the IL code that allows you to see very low level details, which can be very useful for debugging or tuning performance. However, it can also produce some html documentation, including call graphs for your program. These might be very useful to examine what's going on with your overrides.

Basically,

$ eudis --html myapp.ex 
...will get you the html output. In order to get the call graphs, you'll need to have Graphviz installed.

Matt

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu