Checking some demos?

[Charles Pegge]

Hi Roland,

from and of  (equivalent) are for single line inheritance, and has is used for inheriting from several classes.

COM and Java uses single-line inheritance only, and C++ is capable of both.

I am afraid many of these examples make OOP look complicated and obscure, because they are dealing with special cases.


Yet Another fix! (they are all related to the same problem)

Oxygen DLL Update (200k)
http://www.oxygenbasic.org/o2zips/Oxygen.zip

OxyMin Update (800k)
http://www.oxygenbasic.org/o2zips/OxyMin.zip

OxygenBasic Full Update (4700k)
http://www.oxygenbasic.org/o2zips/OxygenBasic.zip

[Arnold]

Hi Charles,

I was curious about the example DemoTheo.o2bas in the Powerbasic folder. It turned out that only few changes were necessary to run it with the latest build of Oxygen. I modified:

DemoTheo.o2bas
Line 92 (in WndProc)
  Select Case wMsg

and in
PbLib.inc
Line 46 (in macro varptr)
strptr v

"generate" in PbLib.inc only includes RTL64.inc. Is conditional include possible with OxygenBasic? If I comment out the generate in line 14 of the inc file, DemoTheo runs fine in Oxide.

Roland

[Charles Pegge]

Thanks Roland,

I fixed a flaw in #if
this enables the RTL conditional includes

Yes, case syntax change was required.

but the varptr macro was okay (@v)


Oxygen DLL Update (200k)
http://www.oxygenbasic.org/o2zips/Oxygen.zip

[Arnold]

Hi Charles,

yes, this works with me too. I compared with HelloWin1.o2bas and thought I had to use strptr. But in DemoTheo there is a local szClassName as asciiz which changes everything.

There are only a few messages left now. Two programs which do not work are in examples\DimFeatures: AddressRes.o2bas and InlineTypes.o2bas (Unknown type pixel4f). Is the purpose of these demos to create a variable of a type with values in one go? I think I did not see this construction in one of the remaining examples.

Roland

[Charles Pegge]

Hi Roland,

I think we can forget about those examples. The dim/type combined syntax was dropped some time ago.

  dim as pixel4f {single r,g,b,a} pixel

should now read:

  type pixel4f {single r,g,b,a}  : dim as pixel4f pixel

or more simply:

  type pixel4f single r,g,b,a  : pixel4f pixel

Thanks again! 

[Arnold]

Hi Charles,

using your example above I changed:
  '
  'dim as pixel4f {single r,g,b,a} pixel
  type pixel4f {single r,g,b,a} : pixel4f pixel

  'dim as materialf {pixel4f ambient,diffuse, specular, single shininess} material[16]
  type materialf {pixel4f ambient,diffuse, specular, single shininess} : materialf material[16]

this works and I think it is easier to understand.

Roland

[Arnold]

Hi Charles,

is this correct what I am doing?

\examples\Constructs\StackFrame.o2bas, line 5:
! funA cdecl (sys a,b,c,d) as sys at @_funA

TempProto.o2bas, line 6:
! g (double a,b,c,d) at @f

\examples\OpenGl\PentFractal.o2bas, line 62:
! Vertex3fv(vector*v) at @glVertex3dv

When I use these changes the demos run. (hopefully ok).

There is examples\Constructs\TypeDefProcC.o2bas which I cannot solve although I tried all kinds of @ and *. The expected result should be 6?

Roland

[Charles Pegge]

Hi Roland,

Yes, that is correct for StackFrame:

! funA cdecl (sys a,b,c,d) as sys at @_funA

and TempProto:

! g (double a,b,c,d) at @f

and also Fractal, but I recently relaxed type checking so that functions like glVertex3dv, will accept (byref) vectors containing doubles, as well as doubles. So the overlay is no longer necessary:

Code: OxygenBasic

1.   function RenderPent(vector *p0,*p1,*p2,*p3,*p4,*p5,sys m)
2.   =========================================================
3.   glBegin GL_TRIANGLE_FAN
4.   glNormal3f 0.,0.,1.
5.   glTexCoord2f 0.5,0.5 : glVertex3dv p0
6.   glTexCoord2f 0.0,0.0 : glVertex3dv p1
7.   glTexCoord2f 1.0,0.0 : glVertex3dv p2
8.   glTexCoord2f 1.0,1.0 : glVertex3dv p3
9.   glTexCoord2f 0.5,1.0 : glVertex3dv p4
10.   glTexCoord2f 0.0,1.0 : glVertex3dv p5
11.   glTexCoord2f 0.0,0.0 : glVertex3dv p1
12.   glend
13.   if m=1
14.     glTranslatef 0.,0.,.001
15.     glDisable GL_LIGHTING
16.     glDisable GL_TEXTURE_2D
17.     glColor4f 1.,1.,1.,1.
18.     glBegin GL_LINE_STRIP
19.     glVertex3dv p1
20.     glVertex3dv p2
21.     glVertex3dv p3
22.     glVertex3dv p4
23.     glVertex3dv p5
24.     glVertex3dv p1
25.     glEnd
26.     glEnable GL_LIGHTING
27.     glEnable GL_TEXTURE_2D
28.     glTranslatef 0.,0.,-.001
29.   end if
30.   end function
31.  

The final example required a fix, as well as @foo

Code: OxygenBasic

1. float foo(int a) label {return a*2}
2. typedef float (*g)(int a)
3. g f = @foo
4. print f 3
5.  

Oxygen DLL Update (200k)
http://www.oxygenbasic.org/o2zips/Oxygen.zip

Thanks

[JRS]

Roland,

I just wanted to say thanks as well for rehashing all the demos and making sure they are up to current O2 standards. Your efforts are what makes open source projects work. (and helps reduce author burnout)

John

[Arnold]

Hi Charles,

I must thank you because of your patience. For me it is like a tour of OxygensBasic's development in the last few years.

Unfortunately there has slipped in a small side effect with the latest build using Oxygen.dll version A40 22:34 13/03/2015: I can run the files using Scite or my editor but I cannot compile them neither with gxo2.exe nor co2.exe. (Linker found unidentified names). With the version before A40 12:56 11/03/2015 there was no problem at all.

Roland

[Arnold]

Hi John,

I wished I could be of some more help, but at the moment I am still exploring the versatile capabilities of OxygenBasic. When I started last year I was not completely aware of this flexibility.

Roland

[Charles Pegge]

Oops sorry!
I was working on the linker.

Oxygen DLL Update (200k)
http://www.oxygenbasic.org/o2zips/Oxygen.zip

[Arnold]

Hi Charles,

with the latest update everything works as expected.

There is an error message which has been all the time before and I am not sure if this is an error at all? In projectsA\LeanLisp\ I can run all the examples (In ListManip.o2bas and in t.o2bas I had to use include "$\inc\console.inc"), but only lispish1 and lispish3usedll can be compiled to an .exe file. Creating LeanLisp.dll does also work. Compiling the other files gives this message:

ERROR:   Macro recursion suspected:
WORD:    wr
LINE:    782
FILE:    LispishUtil.inc
PASS:    1

This error message only occurs with the LeanLisp demos. Usually if I can run a progrom I can also compile it. When running the demos I cannot see an abnormal behaviour. But maybe there is a special reason why you prevent these examples from getting compiled?

Roland

[Charles Pegge]

Hi Roland,

Part of LispishUtil invokes oxygen dynamic compiling, which is not supported by the RTLs. Only dependent compiling + oxygen.dll will support dynamic compiling.

To make a dependent binary work, Oxygen.dll must be present in the same folder, or a small textfile, oxygen.cfg must be present, giving the filepath to Oxygen.dll.

oxygen.cfg

Code: [Select]

..\..\oxygen.dll

Alternatively:

For LispishUtil, this switch excludes operators using dynamic compiling, and independent compiling will be possible.

% NoOxygenCompile

Lispish2.o2bas

Code: OxygenBasic

1. % UseSystemConsole
2. % NoOxygenCompile
3. '#file "t.exe" 'for dependent compiling only
4. '% filename "t.exe"
5. includepath "$/inc/"
6. include "rtl32.inc"
7. include console.inc
8. includepath ""
9. include LispishUtil.inc
10. printl lisp getfile "LispishTest2.txt"
11. waitkey
12.  

[Arnold]

Hi Charles,

% NoOxygenCompile in the second line was sufficient to compile the examples succesfully.

Regarding oxygen.cfg I would like to mention that the file must contain more than one line. When I copied the text above into my config.cfg and saved without using the carriage return, the compiled files did not find oxygen.dll. This is no problem at all, only something to keep in mind.

Roland