OpenEuphoria

2. Re: ok, tell me THIS isn't a bug!

• Posted by mattlewis (admin) Aug 10, 2010
• 1710 views

Yes, that's a bug. I wasn't able to exactly reproduce this, but I think it's likely the same underlying issue: ticket:178.

Matt

4. Re: ok, tell me THIS isn't a bug!

• Posted by useless Aug 10, 2010
• 1684 views

I already tried that. In the debugger, there is no value to that variable unless i hit a line that assigns it a value.

For another instance, it shows <no value> prior to the trim line, unless i insert line

got_data = got_data 

and then after executing that line, got_data got value. Same as the pics showing it got value upon executing the trim() line.

useless

6. Re: ok, tell me THIS isn't a bug!

• Posted by useless Aug 10, 2010
• 1706 views

Euphoria Interpreter 4.0.0 beta 2 (r2670) for Windows

It's what the demos will run on. Even tho the windows installer was last updated 6 months ago, the demos with it won't run on it.

useless

8. Re: ok, tell me THIS isn't a bug!

• Posted by mattlewis (admin) Aug 10, 2010
• 1699 views

The issue I described in ticket:178 is reproduced for me on Linux, r3340.

Matt

10. Re: ok, tell me THIS isn't a bug!

• Posted by mattlewis (admin) Aug 10, 2010
• 1736 views

Actually, for windows users, the latest available is svn:3221 via the eubins site:

http://jeremy.cowgar.com/eubins

I think the Windows eubins might be a more manual process than the Linux version, which is up to svn:3441. That was just committed a little while ago, and fixed the issue I reported with the debugger, and, unfortunately, was a slightly different issue than what you were reporting. I'm having trouble reproducing your issue. Is there any way you can reduce it to a simple, smaller example?

Matt

12. Re: ok, tell me THIS isn't a bug!

• Posted by useless Aug 10, 2010
• 1636 views

I found the bug, and the fix. It is a combination of bad coding style by whoever wrote chat_server.ew, and the interpreter not catching that each loop thru (essentially) "while 1 do" defined/created a new variable of the same name, which the interpreter should have noticed and chastised the programmer about.

I moved all these:

object got_data
object sock_data
object client

up to under the start of the procedure main() where all good var declarations go, and the bug absolutely disappeared.

I didn't/don't complain about the declaration of vars down in the code, but praps it shouldn't be released like that into the wild, in mature-ish code? And the interpreter should be smart enough to know "hey, we already have this variable".

useless

14. Re: ok, tell me THIS isn't a bug!

• Posted by mattlewis (admin) Aug 10, 2010
• 1642 views

I guess this is more of a style issue, but either way, the debugger should handle it correctly. Some prefer to have variables scoped as minimally as possible, and declared as close to where they are used as possible. Eu4 allows this.

Technically, it doesn't create a new variable each loop iteration. Whenever one iteration is finished, the variable goes out of scope and is garbage collected (sequences and double precision atoms). Each iteration uses the same variable. It's a bit of a change, and I'd be happy to talk about the hows and whys if anyone is interested. :)

Matt

16. Re: ok, tell me THIS isn't a bug!

• Posted by useless Aug 10, 2010
• 1635 views

"without inline" shot cpu use to 100%. Way unacceptable. In fact, i could no longer run tests on it.

But i believe i fixed the problem of redeclaring the variables inside a loop, now may i suggest the interpreter catch that sorta occurance and forbid it in the future?

useless

18. Re: ok, tell me THIS isn't a bug!

• Posted by useless Aug 10, 2010
• 1615 views

Ok, in chat_server, there is this nest (listing only the relavant stuff):

procedure main(sequence args) 
 
  while sock:listen(server, 0) label "MAIN" do 
 
    object sock_data = sock:select({ server } & clients, 0) 
 
    if sock_data[1][SELECT_IS_READABLE] = 1 then 
      object client = sock:accept(server) 
      object got_data = sock:receive(client[1], 0) 
    end if 
 
 
    for i = 2 to length(sock_data) do 
      if sock_data[i][SELECT_IS_READABLE] then 
        object got_data = sock:receive(sock_data[i][SELECT_SOCKET], 0) 
      end if 
    end for 
 
  end while 
 
end procedure 

Are you saying each instance of "object whatever" isn't a problem in that code? Especially the two "object got_data", which is the variable i was having trouble with?

useless

20. Re: ok, tell me THIS isn't a bug!

• Posted by mattlewis (admin) Aug 11, 2010
• 1605 views

See ticket:180. Fixed in svn:3342.

Matt