Author Topic: Bug with classes  (Read 6147 times)

0 Members and 1 Guest are viewing this topic.

efgee

  • Guest
Bug with classes
« on: October 03, 2011, 08:00:38 PM »
Just wanted to mention that there is a bug with class members.
Had several vars using the same class but their members had always the same value even when "protected" was used.

Had to change how the class is written:
Previously I had it that way:
(with a constructor to fill the class member with different values)

Code: [Select]

class banana
  protected tree as long

  method get_banana as long

  /\
end class

methods of banana
  method get_banana as long
    method = tree
  end method
end methods


and had to change it to the normal way:

Code: [Select]

class banana
  protected tree as long

  method get_banana as long
    method = tree
  end method
end class


Then it works... well it did :(

Now are there other problems:
Oxygen allows different semantics without reporting errors; but only one syntax is correct :'(
And sometimes the error message is wrong (wrong line or wrong culprit mentioned)
No fun!
« Last Edit: October 03, 2011, 08:03:27 PM by efgee »

Charles Pegge

  • Guest
Re: Bug with classes
« Reply #1 on: October 04, 2011, 03:51:07 AM »
Hi Frank,

There is a difference between the first and second examples.

in the first you have put tree into the class static (upper) section, and therefore it is shared by all the objects of the class.

In the second, tree automatically goes into the  object body section so that each object has it's own tree unless it is marked static

Using the first format:
Code: OxygenBasic
  1. class banana
  2.   method get_banana as long
  3.   /\
  4.   protected tree as long
  5. end class
  6.  
  7. methods of banana
  8.   method get_banana as long
  9.     method = tree
  10.   end method
  11. end methods
  12.  


But I would avoid using the first format since you have the burden of keeping the class header and the methods in sync during development. Let the compiler do this for you by using the second.

There is a useful diagnostic for checking the internals of classes and other entities:

#recordof of banana

This command will display the class record during compile-time.

You can also use recordof banana which returns the record as a string at runtime.


Charles


« Last Edit: October 04, 2011, 03:55:05 AM by Charles Pegge »

efgee

  • Guest
Re: Bug with classes
« Reply #2 on: October 04, 2011, 08:11:19 AM »
It looks like I have to put more info on the wiki.

Thank you

Charles Pegge

  • Guest
Re: Bug with classes
« Reply #3 on: October 04, 2011, 10:19:47 AM »
Thanks for taking care of the Wiki Frank.

JRS

  • Guest
Re: Bug with classes
« Reply #4 on: October 04, 2011, 10:30:28 AM »
I'm also thankful for all contributions to the OxygenBasic open source project. The wiki is a great tool to document a project like this. If you're able to contribute a little or a lot, your efforts are greatly appreciated and will be for some time.


efgee

  • Guest
Re: Bug with classes
« Reply #5 on: October 04, 2011, 10:45:17 AM »
Reread my first post:
Sorry if I sounded a bit too harsh in the latter part in regards to error messages.
From an outsider it looks to me that the Oxygen parser is more trimmed at speed and not so at accurate error reports.
Maybe because different syntax are allowed (c and basic) more trouble is to be expected.
(I prefer accurate error reports over speed - computers are so fast now)

In any case: Oxygen is an interesting project - that's for sure.

 8)

Charles Pegge

  • Guest
Re: Bug with classes
« Reply #6 on: October 04, 2011, 11:48:29 AM »

No problem. The syntax is a lot more flexible than C or Basic and this makes error detection more of a challenge. You will be glad to hear I am not going to stretch it any further, if I can possibly avoid doing so :)

Charles

Peter

  • Guest
Re: Bug with classes
« Reply #7 on: October 04, 2011, 12:10:05 PM »
Hi,

I do not know, but the error message of oxygenBasic are very easy to understand.
this image what I have posted shows an easy explicable message.

it means: you forgot  "TO"  in a " FOR  LOOP". Question: what is difficult ?

[attachment deleted by admin]

efgee

  • Guest
Re: Bug with classes
« Reply #8 on: October 04, 2011, 02:30:41 PM »

There is a useful diagnostic for checking the internals of classes and other entities:

#recordof of banana

This command will display the class record during compile-time.

You can also use recordof banana which returns the record as a string at runtime.


I suppose

Code: [Select]

#recordof of banana


should be

Code: [Select]

#recordof banana


and this is the output (classname = app):

Code: [Select]
---------------------------
202
---------------------------
#recordof app
ú1301ù
28ù
4780ù


1813ù
appù
[ebx+4780]ù
ù
oapp ù
ú
---------------------------
OK  
---------------------------

Which tells me a lot  ;D
« Last Edit: October 04, 2011, 02:37:12 PM by efgee »

Charles Pegge

  • Guest
Re: Bug with classes
« Reply #9 on: October 04, 2011, 08:20:28 PM »

Recordof shows the raw internal structure. I have not attempted to beautify it so far.

To take a meaningful example:

Code: OxygenBasic
  1.  
  2.   class banana
  3.   '===========
  4.  '
  5.  private
  6.   '
  7.  static long countA,countB
  8.   '
  9.  protected
  10.   '
  11.  string tree,plantation,country
  12.  
  13.   '
  14.  public
  15.   '
  16.  long stored
  17.   '
  18.  method get(long n) as long
  19.     long s=stored-n
  20.     if s<0 then n+=s
  21.     stored-=n
  22.     return n
  23.   end method
  24.   '
  25.  method put(long n)
  26.     stored+=n
  27.   end method
  28.   '
  29.  end class
  30.  
  31.  
  32.   putfile "t.txt", recordof banana
  33.  
  34.   banana ba
  35.   ba.put 30
  36.   print ba.get 15
  37.   print ba.get 20
  38.  
  39.  

Code: [Select]

ú-3ù
16ù




bananaù
counta 0 2 9 A , long
countb 4 2 9 A , long
get 8 9 9 A #long@a0 long
put 12 9 9 A #long@a0 sys
/\
       
     
                               
               
     
tree 0 1 1 A , string
plantation 4 1 1 A , string
country 8 1 1 A , string
     
     
stored 12 1 9 A , long
ù
ù
push ecx : lea ecx,[ebx+4096]
o2 e8 00 00 00 00 58 05 gl get#long 83 c0 06
mov [ecx+8],eax ; METHOD PTR
o2 e8 00 00 00 00 58 05 gl put#long 83 c0 06
mov [ecx+12],eax ; METHOD PTR
pop ecx
ù
ú

You can begin to see how the class is encoded.

Charles

Charles Pegge

  • Guest
Re: Bug with classes
« Reply #10 on: October 04, 2011, 08:54:09 PM »
Peter,

Yes I agree there is a lot more error trapping to do.

In the case of the for statement. It will accept both C and Basic syntax.

Code: OxygenBasic
  1. '----------
  2. 'ITERATION:
  3. '==========
  4.  
  5.  
  6.   s=""
  7.  
  8.   'basic style
  9.  '===========
  10.  
  11.   for i=1 to 10
  12.     s+=str(i)+" "
  13.   next
  14.  
  15.  
  16.   'intermediate style
  17.  '==================
  18.  
  19.   for i=1 : i<=10 : i++
  20.     s+=str(i)+" "
  21.   next
  22.  
  23.   'C style
  24.  '==================
  25.  
  26.   #semicolon separator
  27.  
  28.   for (i=1 ; i<=10 ; i++)
  29.   {
  30.     s+=str(i)+" ";
  31.   }
  32.  
  33.  
  34.   print s
  35.  

I now have to fit first-pass error traps around these formats. Any suggestions how to do this efficiently? :)

Charles
« Last Edit: October 04, 2011, 08:56:54 PM by Charles Pegge »

efgee

  • Guest
Re: Bug with classes
« Reply #11 on: October 28, 2011, 10:18:04 AM »
Charles,
just tested the current in progress version and the compiled classes look OK.

nice  8)

Peter

  • Guest
Re: Bug with classes
« Reply #12 on: October 28, 2011, 10:42:59 AM »
I dislike "GOASM ". is ancient Assembler from 1777.
Better is MASM,  comes from MicroSoft, the world best software smithy.

Aurel

  • Guest
Re: Bug with classes
« Reply #13 on: October 29, 2011, 07:51:48 AM »
FASM is the faster.

jcfuller

  • Guest
Re: Bug with classes
« Reply #14 on: October 29, 2011, 08:00:29 AM »
I prefer JWasm

James