OpenEuphoria

1. 4.0 Beta 2 Due Out on Tuesday, got your bug reports in?

• Posted by jeremy (admin) Aug 22, 2009
• 1544 views

Just a reminder, 4.0 beta 2 is due out on Tuesday, 8/25/2009.

Have you submitted any bugs to the Bug Tracker that you may know of?

Jeremy

3. Re: 4.0 Beta 2 Due Out on Tuesday, got your bug reports in?

• Posted by DerekParnell (admin) Aug 22, 2009
• 1440 views

Yeah, I realized that too. I'll tidy up the bug report to clarify it.

However, have we really got a bug here?

The not-used checking is done at the end of each block using whatever warning settings are prevailing at the time. In other words, the warning settings are linked to a block of code and not individual declarations.

In this case, the variable is scoped to the file, and the file's block is checked after the all the file has been parsed. The problem with this particular file is not that the without warning is failing, but that the last line in the module is with warning. Meaning that when the not-used checking is being performed for this file's block, the warnings have been explicitly set to check for unused variables. Now, if that last line is removed, you won't get the message.

5. Re: 4.0 Beta 2 Due Out on Tuesday, got your bug reports in?

• Posted by DerekParnell (admin) Aug 22, 2009
• 1329 views
• Last edited Aug 23, 2009

Yes, and does that surprise you? The reverse is also true - without warning overrides with warning

That is exactly what is happening already. The usage checking occurs whenever a block of code ends - such as the end of a routine, a 'switch', a loop, a source file, ... When a block ends, usage of variables declared in that block is checked using whatever the warning setting is at that time.

In this specific instance, just before the end of the file, the warnings are turned on. So when the end of file is reached, Euphoria checks the usage of variables declared at the file level, based on that with warnings statement. Thus we get the message. This is not a bug in the warning reporting system. If anything is a bug it is that final line of code. It should be removed.

But that begs the question, "why is check_calls declared at all and why is it assigned anything?" Both the declaration and the assignment are redundant and could be seen as a coding mistake - thus the warning.

Now consider what you seem to be asking for - that declarations occuring whilst a without warning is active should be immune from usage checking.

---- file begins ---- 
without warning 
integer foo 
procA() 
with warning 
procB() 
---- file ends ---- 

When this file ends, foo is still not used and warnings are on. So should a message be issued or not? Remember, usage checking occurs at the end of a block, which is when variables go out of scope. (Of course none of this applies to exposed variables - global, public, or export ones.) If we didn't do usage checking at the end of a block, when else could be do it? It doesn't make sense to do it while a variable is still in scope because it cound have been used after the usage check.

It is hard to see the intention of the author of v3 machine.e, but I think what was being attempted by the final with warning was to restore the warnings to whatever they were when the file began. But as you can see, this is not the way that usage checking works. Now, in OpenEuphoria v4 we have better ways to do that sort of thing.

---- file begins ---- 
with warning save -- Save whatever warnings are active 
without warning 
integer foo 
procA() 
with warning restore -- Restore from the last save point. 
procB() 
---- file ends ---- 

-- variables and routines used in safe.e 
without warning 
integer check_calls 
check_calls = 1 

What do you mean by "Yes it does though"? The example code you supplied does not issue any warning message.

By the way, OpenEuphoria now issues differently worded messages now ...

-- variables and routines used in safe.e 
with warning 
integer check_calls 
check_calls = 1 

Warning ( not_used ): 
    <0320>:: testw.ex - module variable 'check_calls' is assigned but never used 

-- variables and routines used in safe.e 
with warning 
integer check_calls 

Warning ( not_used ): 
    <0229>:: testw.ex - module variable 'check_calls' is not used 

7. Re: 4.0 Beta 2 Due Out on Tuesday, got your bug reports in?

• Posted by mattlewis (admin) Aug 23, 2009
• 1274 views

But it really isn't. If you assign it and never use it, then what was the point of assigning it? It didn't really do anything (in most cases, at least). This is a pretty standard sort of warning, which lets you know that you can probably remove the referenced variable from your code altogether.

Matt

9. Re: 4.0 Beta 2 Due Out on Tuesday, got your bug reports in?

• Posted by kenneth Aug 23, 2009
• 1219 views

someone saidThe warning is properly triggered since the declared variable never appears to the right of an equals sign.

Chris saidYes it does though

someone repliesYou seem to be confusing left vs. right. I could have said the variable check_calls is never assigned to anything or used in any calculation or that it is never an rvalue. So 'unused' is a proper warning. At any rate, Jeremy points out that the problem is not the 'without warning' implementation, but rather the lack of documentation regarding its scope and its subsequent misuse in the two mentioned include files.

11. Re: 4.0 Beta 2 Due Out on Tuesday, got your bug reports in?

• Posted by jeremy (admin) Aug 25, 2009
• 1147 views

We have a show stopping bug that we are trying to work through. With the latest information that we were able to gather, it seems to be affecting Windows Vista and Windows 7 users. So, if we do not get it solved by tomorrow, I *think* we will probably release beta 2 with that warning.

Jeremy

13. Re: 4.0 Beta 2 Due Out on Tuesday, got your bug reports in?

• Posted by alanjohnoxley Aug 26, 2009
• 1099 views

Hi, This may be a bug in v4.0b1.. On my CentOS 5.3 x32, with Gnome desktop, the screen display gets altered. When trace(1) is invoked, the screen changes to the usual trace, no problem. But if I "q" to get out of the trace, my screen which was black chars on white background is now black with grey chars. If I then do a "ls", the ls results are back to black on white, while the rest of the screen is grey on black. Or is this some sort of display setting I need to sort out?

Regards Alan