Oxygen Basic

Information => Open Forum => Topic started by: kryton9 on October 09, 2011, 08:41:03 PM

Title: a case for architectural change in oxygen?
Post by: kryton9 on October 09, 2011, 08:41:03 PM
I am going to make a case for a change in the architecture of Oxygen. Right now Charles has picked the C design, small core and everything else libraries. This sounds good at first, but then you end up with what we have in the c/c++ world. Everyone writing their own library to fit their coding style, each with their own dependencies. You can look at source code on google code search and see code styles that are light years apart in look and readability. You can see a zillion examples of people rewriting the same code over and over again rather than looking and settling on a proven library. Even in proven community based libraries, like Boost, you have people that absolutely will not use them for whatever reason, so they write their own.

I say that Oxygen should be a giant core that is ever growing. The core is only added to by Charles and others he might add to his core team. Any new code would be submitted as a library to the core team and then they would make it fit the Oxygen way. This also means developing a rigid set of rules for the look and feel for Oxygen. Right now it is too flexible if you ask me. Then when the program is compiled, Oxygen would remove any unused code from the giant core to make the executable small.

For tinkering and getting things going, I think Charles took the right approach. But when you look at how powerful Oxygen already is. I can also see how the current way will lead to chaos in the future as we add more complex systems. I see Peter's libraries and some of Charles that do the same thing as well as some of my own. And we are just in Oxygen's infancy.

Here I submit a very nice well thought out schematic for a game engine. Now imagine all of these components written by various authors in various styles with redundant code and crazy dependencies, as it will be, if we continue on the current path. The only way I see a clean elegant solution is to have a master plan. Not only for a game engine, but for other areas of development. I just present a game engine as that is my current passion.

My initial suggestions for style would be based on C, since Oxygen can read C header files.
1. Case is Sensitive
2. Parenthesis are required for functions, subs, methods
3. Use == instead of := for conditional equality checks

If oxygen is to keep Basic as part of its name. I think then the extension .o2bas should just be .bas and the include files .inc  Right now we have a mixture of many extensions in the examples I download. Again flexibility was nice, but now I think it is detrimental.

Also, I think Oxygen would be in two main prongs. Procedural and Object Oriented Programming. A user could mix and match according to their needs. But basically, for almost all commands there would be 2 of them. One in the Procedural Prong and the other in the OOP Prong. The help would be a clean split of these two prongs.

It is alright if you want to take me out to a wall and shoot me if you disagree, what do you guys think?
Title: Re: a case for architectural change in oxygen?
Post by: jcfuller on October 10, 2011, 01:43:48 AM
Sorry Kent I am opposed.
I have not been coding with O2 lately but I have been following it's progression and I like what I see,even if I don't understand a lot of it.
I think with a comprehensive help file and MANY,MANY examples (with extensive comments) one will be able to pursue their own preferred manner of coding.

James
Title: Re: a case for architectural change in oxygen?
Post by: Peter on October 10, 2011, 01:58:37 AM
Hi Kent,

What I think:

Case sensitive ,  no  :P
Brackets,           no  :P
:=,  will  never used by me.  May go to the Moon..  :D
 
Title: Re: a case for architectural change in oxygen?
Post by: Aurel on October 10, 2011, 04:00:47 AM
Don't worry Kent nobody kill you... ;D
I understand that you want something like have PureBasic,EBasic etc...etc...
but this aproach is unique ,right?
Title: Re: a case for architectural change in oxygen?
Post by: Peter on October 10, 2011, 04:41:26 AM
Hi Kent,

After this defeat, you could feel the desire to build a plane and just fly away.
for this airplane  could you  already get a propeller here.  :D
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on October 10, 2011, 06:21:04 AM
Thanks for the input guys. I will head South to the Border to go hide deep in the jungles with my crazy ideas, using Peters Propeller :)
Title: Re: a case for architectural change in oxygen?
Post by: efgee on October 10, 2011, 01:16:35 PM
@kryton9

Case sensitivity -> no
Parenthesis -> yes
C-style equal sign (==) -> yes

In the end Charles has to decide what he wants in his language.

But before these kinds of things are evaluated/discussed the error reporting "mechanics" inside Oxygen need to be fixed.
Title: Re: a case for architectural change in oxygen?
Post by: Peter on October 10, 2011, 02:35:20 PM
What is so exciting of  " ()" and " ==" ? 
I think that Kent and efgee won't Basic,  rather an Oxy C, C++.  :D
Title: Re: a case for architectural change in oxygen?
Post by: efgee on October 10, 2011, 03:39:09 PM
What is so exciting of  " ()" and " ==" ?  

Peter,
when looking at old code of mine that I wrote 10 years ago and I see:

Code: [Select]
fruit = Banana()

Even after 10 years I know Banana is a procedure.

If I would have written:

Code: [Select]
fruit = Banana

after 10 years I don't know what Banana is; is it a variable or procedure?
Have to look at the code and find the declaration of it.

Also as you know from experience Oxygen's error report differs if you use parenthesis or not...
This said, the syntax check inside the compiler gets more complicated and error prone.

---

A big flaw of BASIC is that the assignment of a value "=" and the check of equality "=" is the same.
Examples:

Code: [Select]
fruit = Banana ...
Code: [Select]
if fruit = Banana then ...

Sure the code surrounding the "=" tells me if it's an assignment of a value or the check of equality.

But with other languages that have the "==" to check for equality you can do:

Code: [Select]
function Banana( dword a, dword b)
   ... do some things with a and b
   ... and then do:
   result a == b
end function

The function above returns "true" or "false" depending if a equals b.
In Basic you need more code to do the same...

Don't fall into the trap and think that the BASIC syntax (as it was invented decades ago) is the best thing after sliced bread...  

Be open minded, but please not too open... otherwise your brain could fall out :D

Title: Re: a case for architectural change in oxygen?
Post by: Peter on October 10, 2011, 04:36:46 PM
Quote
otherwise your brain could fall out
this happens often.   :D
Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on October 10, 2011, 10:25:15 PM
I find standing on one's head is a good way of pushing the brain back into its proper position  :D

You can use "==" if you prefer it but I think it would be undesirable to enforce this.

The C use of "=" in conditional statement is a continual source of confusion for inexperienced programmers. So I felt the best compromise was to use ":=" to denote an unambiguous assignment.

There is a reason for not enforcing brackets and perhaps blurring the distinction between variables and procedures. It is part of the OOP philosophy of separating implementation specifics from the user.

This is a trivial example of using pseuodovariables:

Code: OxygenBasic
  1.   class fruit
  2.   '==========
  3.  
  4.   string itype
  5.  
  6.   method type(string s)
  7.   itype=lcase s
  8.   end method
  9.  
  10.   method type() as string
  11.   return itype
  12.   end method
  13.  
  14.   end class
  15.  
  16.  
  17.   '======
  18.  
  19.   fruit fr
  20.  
  21.   'overloading pseudovariables
  22.  
  23.   fr.type="Banana"
  24.   print fr.type 'prints: "banana"
  25.  
  26.  

Charles

more thoughts to follow..





Title: Re: a case for architectural change in oxygen?
Post by: Aurel on October 10, 2011, 11:13:30 PM
All basic like languages have '=' not '==' and if currently work OK i
see that work ,why insist on unbasic syntax?
Title: Re: a case for architectural change in oxygen?
Post by: JRS on October 11, 2011, 07:43:13 AM
Quote
There is a reason for not enforcing brackets and perhaps blurring the distinction between variables and procedures.

ScriptBasic doesn't require parentheses for functions or subs if they don't return anything.

SUB Dummy(arg1,arg2)
  'do something but don't return anything
END SUB

Dummy "String comand", 0

I have to use parentheses in this case.

FUNCTION Dummy(arg1,arg2)
  'do something
  Dummy = 1
END FUNCTION

okay = Dummy("String comand", 0)

Title: Found this plan for a game engine. Much to do...
Post by: kryton9 on July 24, 2012, 05:58:20 PM
Oxygen has come along way, but many times I see reinvention of the wheel over and over again in the code examples. I found this image to show the complexity of what it takes to make a proper game engine and this could also reflect the amount of work for any huge project. I hope this great schematic can give direction and organization as Oxygen development moves forward.

I wish I had the low level skills that Charles and Peter have, but I don't. I have tried to work in an organized manner, but keep hitting walls that I find frustrating. So for now, I will move onto another language or framework and see if I can get anywhere. If I ever get an engine together as I wish, I will definitely look forward to porting it to Oxygen in the future and carrying on work in it. Oxygen is very sweet to work in and it makes it hard to go to any other language, but my muddled mind needs to focus on one language at a time anymore.

With a working engine and code to port, I think I can contribute more in the future than I currently can.

I hope the Rosetta Code site brings more low level developers to this site so they can help take oxygen to the next level. It is a language that needs recognition and support!
Title: Re: a case for architectural change in oxygen?
Post by: JRS on July 24, 2012, 09:21:59 PM
I think it would be great if Charles explained his vision for OxygenBasic. Where he is now, next major milestone and the end goal.

Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on July 25, 2012, 02:13:20 AM
OxygenBasic itself is only a programming language, and this will continue to be my main focus. But here, Kent is referring to a major work of literature, so to speak.

We have created quite a comprehensive collection of examples already, encompassing maths, data-processing, multi-threading, audio and graphics, which I hope will encourage further development, by extending and combining these elements.

With some of the features, I've included in Oxygen, it should be possible to push through the scale-barrier, often encountered with other Basics.

Charles

PS: I'm in favour of re-inventing the wheel :)
Some of us have seen this video before:

http://www.youtube.com/watch?v=JVB1ayT6Fdc
Title: Re: a case for architectural change in oxygen?
Post by: Aurel on July 25, 2012, 02:48:15 AM
Kent...
With full respect to you i think that you are not sure what you wish and what
kind of shape this your game engine will look like.
I am also not sure how i would like to see GUI part of my coding in oxygen.
Some points i have found in AutoIt code and some in Gui4Cli because sources for
both are open.
Level of prototyping in oxygen is excellent if you ask me and i don't know what would be
next level....
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on July 25, 2012, 09:09:56 AM
No doubt OxygenBasic is very exciting and it has come a long way. But as John said, it would be neat to have some sort of roadmap.

@Charles, yes I am also for reinventing the wheel and my post was wrong in using that phrasing. Maybe it should be re-gathering the same parts and putting the same thing together over and over again.

@Aurel, you are also right. It is very hard to plan for something so complex while still developing the other parts.

As I said, I will eventually come back to oxygen once I figure my engine out and get it working and have some code that can be studied and ported over. Things are changing in many fronts.
SDL 2.0 Beta which I think is SDLHG now, supports multiple monitors and windows now. There is Nokia's QT which is quite interesting as it compiles to Native Windows, Linux and Mac. Oxygen written in QT would be interesting as it has a great framework from which to launch from and QT does not have a BASIC version, so that is a good fit. I don't know how all that works, my guess is Oxygen would tap into QT's parser and add BASIC syntax?

Of course there has always been free pascal and a new compiler called clang. 2 to 3 times faster in compiling than gcc and captures many errors that other compilers miss. In fact, many major projects are advertising passed through clang. For example, in one of the videos I watched, they said code that came out squeaky clean no errors in gcc, had around 150 errors in clang identified. clang is now becoming the Mac compiler of choice. clang is also connected to LLVM in ways I don't understand at the moment.

Anyways just some thoughts while I search for my engine development path.



Title: Re: a case for architectural change in oxygen?
Post by: efgee on July 25, 2012, 10:07:46 AM
Quote from: kryton9
There is Nokia's QT which is quite interesting as it compiles to Native Windows, Linux and Mac. Oxygen written in QT would be interesting as it has a great framework from which to launch from and QT does not have a BASIC version, so that is a good fit.

There is the KBasic compiler that uses QT (from the same developer that started work on Objective-Basic for iMacs).

Quote from: kryton9
... and a new compiler called clang. 2 to 3 times faster in compiling than gcc and captures many errors that other compilers miss. In fact, many major projects are advertising passed through clang. For example, in one of the videos I watched, they said code that came out squeaky clean no errors in gcc, had around 150 errors in clang identified. clang is now becoming the Mac compiler of choice. clang is also connected to LLVM in ways I don't understand at the moment.

With LLVM came new/very good competition for GCC and the GCC folks finally woke-up and started adding better optimization to GCC - which is a good thing IMHO.

LLVM is the core and back-end of a compiler infrastructure. Apple helped/pushed LLVM because they didn't want to rely solely on GCC.
Clang is the C front-end of LLVM and there are other front-ends for C++ and Object-C.

Actually LLVM is the core of Apples XCode: https://developer.apple.com/technologies/tools/

LLVM is available for many different operating systems.

Title: Re: a case for architectural change in oxygen?
Post by: efgee on July 25, 2012, 10:32:57 AM
Where does Oxygen fit in all of this?

Don't know.

My safest bet is that there is only one steering wheel and Charles has it in his hands.
Wherever he wants to go Oxygen will go.


A lot of you stick to Win32 and reinvent the wheel, but I stopped working on the GUI library I was working on (in Oxygen) because Win32 is dieing.
Working on GUI stuff for a new compiler utilizing old Win32 interfaces with all it's quirks/unpleasant surprises is not something I can afford doing in my spare time.
If I would be retired it would be different (more time...) but I have still many years to work, so time is precious.

Rather spend my time on things I can envision they are still around in 10 years or so and is not a dieing mule like Win32.
And no I will not start doing Metro programming because I think it's the wrong way to go for PC-workstations.
I'm not interested in gaming and for pure consumption (not creation) I have an Android tablet.

From a programming perspective it will be OSX or Linux for me - didn't make up my mind yet.
(still looking at available programming tools and technology)

The only place I will touch Windows in the future is my HTPC (because of Blu-Ray) and at work - where we still use WinXP  :P

Edit: typos...
Title: Re: a case for architectural change in oxygen?
Post by: Peter on July 25, 2012, 11:15:49 AM
Hi efgee,

Quote
because Win32 is dying.
do not fall into panic now.  :D
Title: Re: a case for architectural change in oxygen?
Post by: efgee on July 25, 2012, 12:02:18 PM
I'm not panicking, I'm just saying how it is.
Win32 is a dieing mule.

If you want to use your time to work on Win32 stuff - it's fine - have fun.
There are still people that program with QuickBasic on FreeDos on a regular basis and are happy.
Null problemo.

I just said that in my case I will not use my time for a dieing mule.

Title: Re: a case for architectural change in oxygen?
Post by: Peter on July 25, 2012, 12:13:37 PM
I think that you are right.
The whole windows is dieing, starts with Window8.  I say RIP and drive bicycle.
Title: Re: a case for architectural change in oxygen?
Post by: Aurel on July 25, 2012, 12:25:48 PM
Then... efgee Oxygen basic is not for you.
Windows dying ...yes because MacOS & Linux use only cca 5% people on planet :P
Title: Re: a case for architectural change in oxygen?
Post by: efgee on July 25, 2012, 04:00:00 PM
Then... efgee Oxygen basic is not for you.

Well don't say that - it hurts my feelings  >:(

No seriously:
If Charles creates a C emitter OxygenBasic could be used for other OS as well.

Windows dying ...yes because MacOS & Linux use only cca 5% people on planet :P

Aurel,
sorry mate but you misunderstood:

I said Win32 is a dieing mule not Windows.
Windows and Win32 are not the same!

Win32 is an API - Windows is a OS.

Windows will be pretty much alive even after Windows 8.
(WindowsME anyone?)

But as I said before I'm not interested in METRO the new Windows 8 "holy grail".


You are right about Linux and OSX in that they have only a small userbase, but I don't care about that.
From a programming point of view I look at technology and programming tools.

Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on July 26, 2012, 12:37:52 AM

A C emitter is certainly the next milestone for Oxygen, but in terms of library development it's more of an organic process.

I am not overly concerned about repetition. If a repeating code pattern becomes evident, it will be assimilated into a library at some point.

I think Win32 will always be present, even if most programs do not use it directly - much of Win32 forms the base of the pyramid.

Charles
Title: Re: a case for architectural change in oxygen?
Post by: Aurel on July 26, 2012, 04:40:56 AM
efgee
In your observation there are to many contra-points and sounds like i don't
know about what i talk...man...
maybe you think that i'm stupid or something... >:(
your feelings are not my theritory
and from your post i see that you don't know many things
Metro style is HTML5 style of programming if you don't know that... ::)
And you say win32 api is not of my interest ...man ...gee
do you know where you living... ???
Title: Re: a case for architectural change in oxygen?
Post by: Peter on July 26, 2012, 04:56:19 AM
Quote
do you know where you living...

LOL  :D
Title: Re: a case for architectural change in oxygen?
Post by: efgee on July 26, 2012, 08:47:21 AM
efgee
In your observation there are to many contra-points and sounds like i don't
know about what i talk...man...
maybe you think that i'm stupid or something... >:(
your feelings are not my theritory
and from your post i see that you don't know many things
Metro style is HTML5 style of programming if you don't know that... ::)
And you say win32 api is not of my interest ...man ...gee
do you know where you living... ???

@Aurel
I just tried to emphasize the fact that I never said Windows is dieing.
Sorry for not being clear enough and because of that you misunderstood many things I said.
Maybe the language barrier adds to the misunderstandings.

In any case: There is no reason for you to get personal.

Title: Re: a case for architectural change in oxygen?
Post by: efgee on July 26, 2012, 09:01:10 AM

A C emitter is certainly the next milestone for Oxygen, but in terms of library development it's more of an organic process.

I am not overly concerned about repetition. If a repeating code pattern becomes evident, it will be assimilated into a library at some point.

I think Win32 will always be present, even if most programs do not use it directly - much of Win32 forms the base of the pyramid.

Charles

You might be right in regards to Win32.
It is my understanding though that Win32 applications will be treated and look like an alien on Windows 8.

Take care
Title: Re: a case for architectural change in oxygen?
Post by: JRS on July 26, 2012, 09:48:25 AM
At least on the bright side, Microsoft will support Windows 7 until 2020.
Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on July 26, 2012, 10:02:11 AM
What is the GUI model in OSX, Frank? Does it use anything like the MS messaging system, with message loop and Wndproc callbacks?

Charles
Title: Re: a case for architectural change in oxygen?
Post by: efgee on July 26, 2012, 10:45:16 AM
At least on the bright side, Microsoft will support Windows 7 until 2020.

Sweet.
Depending on Win8's reception they might have to prolong it like they did with WinXP.
Title: Re: a case for architectural change in oxygen?
Post by: efgee on July 26, 2012, 11:08:56 AM
What is the GUI model in OSX, Frank? Does it use anything like the MS messaging system, with message loop and Wndproc callbacks?

Charles

Well, the old GUI stuff (Carbon) on OSX is phased-out.
The current API is utilizing Cocoa and it's object oriented.
(see http://en.wikipedia.org/wiki/Cocoa_(API) (http://en.wikipedia.org/wiki/Cocoa_(API)))

Apple gives the programming tools (XCode) away for free.
(like what Microsoft does with Visual Studio Express with the exception that there is only one XCode version...)
XCode comes with a GUI builder where you drag-n-drop your GUI elements and you only have to write some glue code to make it work.
The task to create your GUI is seen as a design work not a programming one.

But if you want to do it the hard/manual way it would look like this:

Code: [Select]
int main(int argc, char *argv[]) {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    [NSApplication sharedApplication];

    int style = NSClosableWindowMask | NSResizableWindowMask | NSTexturedBackgroundWindowMask |
                     NSTitledWindowMask | NSMiniaturizableWindowMask;

    NSWindow *win = [[NSWindow alloc] initWithContentRect:NSMakeRect(50, 50, 600, 400)
                                    styleMask:style
                                    backing:NSBackingStoreBuffered
                                    defer:NO];

    [win makeKeyAndOrderFront:win];
    [NSApp run];

    [pool release];
}

I'm still contemplating to even not start with Objective-C because the brackets just look horrible to me.
But there are more language front-ends (C/C++) that can be used with XCode though - which is nice.
(or even totally different programming toolsets/languages like QT, wxWidgets and others...)


Anyhow, here:
http://www.cocoalab.com/?q=node/14 (http://www.cocoalab.com/?q=node/14)

and here:
http://www.cocoatraces.com (http://www.cocoatraces.com)

you can find more information about Cocoa.

Take care.

Edit: typos...
Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on July 26, 2012, 04:16:50 PM

Very interesting, Frank.

I don't see any dark technologies like COM or .NET :) and the literature is significantly less opaque than MS, who want to bamboozle you with their latest APIs.

2 concepts used by Cocoa I would like to explore:

MVC Model-View-Controller

Building of classes at runtime: dynamically allocating methods to a class that uses standard interfaces.


I think we already have all the necessary components.

Charles
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on July 26, 2012, 09:41:41 PM
In studying QT today, I see some really neat stuff. As one of the videos I saw pointed out, everything major in the world is written in C or C++. It is not going away anytime soon. QT just brings c++ to the most modern ways of programming and supporting so many platforms natively not in a virtual machine.

I was jumping over many videos and saw some advanced one on QML, it is very clean and powerful and interfaces with c++.

Every widget in QT supports HTML. So a string variable supports html. Very powerful things that alone brings.

Not to bore you guys with QT talk, here is an incredible video of what can be done relatively easily in QT. Also I saw video of how one developer in one year ported QT for android development. That just shows how powerful QT is that one person could do that if you ask me.

3D Car Animation: http://www.youtube.com/watch?v=VvQ_NHKtHwE&feature=player_embedded

Android QT: Jump to 3:22 time to see an app being created and deployed. This first 3 minutes is setting up android, qt and the android emulator device.
http://www.youtube.com/watch?v=suPeZ7XC1xk&feature=player_embedded

Title: Nothing is for free
Post by: kryton9 on July 27, 2012, 03:54:44 PM
Here is the big downside to QT that I found. Just to show I am not a blind fan boy now.
This is a biggie and one of the downsides to having so much power and flexibility, file sizes soar.

QTSDK with examples, the IDE, demos, compiler, documentation... the works comes in at 7GB installed.

A simple app I wrote to test just a simple window, 2 buttons and a label:
To send for the first time the app to someone. 12.5MB uncompressed.
Compressed to 7zip 3.8MB

To be fair, you would send the required dlls just once and those are 12.4MB of the initial 12.5MB file size.

Like I said, Oxygen spoils one in being small and elegant at the same time.

One thing I need to figure out in QT that if we could bring to oxygen would be cool.
QT doesn't use garbage collection, but the way they create new instances from the heap memory they delete by themselves.
This happens with them somehow using new in the constructor. Then the destructor automatically deletes the object. This all happens without it being a singleton.
It is a mystery how this works, so I am trying to figure it out.
Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on July 28, 2012, 03:07:55 PM
Hi Kent

There are plenty of tricks for deleting or recycling objects efficiently. Particles, for instance can be held in one block of memory, and each tagged as being either active within a scene, or recyclable. All of them could be deleted in a single operation when no longer needed.

I love putting objects inside strings. Then the whole collection can be chopped, extended, nullfied or even dunked onto disk in one go.
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on July 28, 2012, 07:07:35 PM
If you could wrap code into a class or library to do such things it would be great. I have looked at some of your tree structure works and stuff and it got confusing really fast to me.
Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on July 30, 2012, 12:36:35 AM
Hi Kent,

This a set of macros that use the string/dynamic object duality to good effect

Code: OxygenBasic
  1.  
  2.  
  3. 'For flat objects
  4. '================
  5.  
  6. macro UseObjectArrayStrings
  7.  
  8.   macro ExtendObjectArray(v,n)
  9.   cast bstring @v += nuls n * sizeof v
  10.   end macro
  11.  
  12.   macro ClipObjectArray(v,n)
  13.   cast bstring @v = left(cast bstring @v,n * sizeof v)
  14.   end macro
  15.  
  16.   macro CopyObjectArray(w,v)
  17.   cast bstring @w = cast bstring @v
  18.   end macro
  19.  
  20.   macro EmptyObjectArray(v)
  21.   cast bstring @v=""
  22.   end macro
  23.  
  24.   macro PutFileObject(f,v)
  25.   putfile f,cast bstring @v
  26.   end macro
  27.  
  28.   macro GetFileObject(f,v)
  29.   getfile f,cast bstring @v
  30.   end macro
  31.  
  32.   macro ObjectArraySize(v)
  33.   len(cast bstring @v) / sizeof(v)
  34.   end macro
  35.  
  36. end macro
  37.  
  38. 'TESTS
  39. '=====
  40. #recordof UseObjectArrayStrings
  41. UseObjectArrayStrings
  42.  
  43. class vector
  44. float x,y,z
  45. '...
  46. end class
  47.  
  48. vector *v,*w
  49. ExtendObjectArray v,100
  50. v[100]<=1,2,3
  51. ExtendObjectArray v,100
  52. PutFileObject "t.bin",v
  53. GetFileObject "t.bin",v
  54. ClipObjectArray v,150
  55. CopyObjectArray w,v
  56. print w[100].z
  57.  
  58. print objectArraySize v
  59.  
  60. EmptyObjectArray v
  61.  

There's more to be discovered :)

Charles
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on July 30, 2012, 10:20:43 AM
That is nice Charles. Is cast acting like a template in other languages here?

It would be nice if you could just put to the array and let it extend and clip in the background automatically.
But come nice code to study.

I guess using macros this way is like using the inline command in c++?
Title: Re: a case for architectural change in oxygen?
Post by: Aurel on July 30, 2012, 01:13:50 PM
I am just looking in this macro-s ...
Charles you say that macro-s can be used in my GUI stuff...how?
Title: new foundation
Post by: kryton9 on August 04, 2012, 10:09:17 PM
Charles and others,

I have been watching a series of videos about c++11 that I linked to on the coding monkeys forum. http://www.codingmonkeys.com/index.php?topic=2382.msg13545;topicseen#new

I really do think that the future is multi-platform and that c++ has to be the foundation for any new language. The changes coming with c++11 are amazing.
No more new and delete or manual memory allocation needed. There is no need for a garbage collection system either. Iterations are as I had asked for with my scan command and what I implemented in the sqlite class.  There is a major effort to bring uniformity to code and use with algorithms and containers. The next push is for the set of consistent libraries that other languages have.

Eros has committed too many lines in PowerBasic to make a change to another foundation language. I would hate to see that happen to Oxygen.
I think while Oxygen is in Alpha, a serious reanalysis has to be taken before too many lines are committed for any changes to be dauntingly difficult.

Not having the roots based on a language as powerful as c++ shows its ugly head with all the macro magic you need to do in Oxygen.
In watching those videos, macros are powerful but evil in the long run. Also using the winapi is talking to code written over 20 years ago.
It is really outdated and a waste of time building a language based on it. That really is my humble opinion.

I really think you should look at QT or GTK+, as those two seem to be the main leaders in the use of good design and what they bring.
It will allow oxygen to be on all major platforms with a language and library set that is practically all a language needs.

What oxygen could do is bring even cleaner syntax with Basic.  KBasic is now opensource, but buggy I read. It has also moved to a new version that is commercial, Basic for QT. So an opensource stable actively developed compileable cross platform BASIC is needed.

What is interesting is that c++11 is going to be cross platform, it is just a matter of time till all the compiler makers catch up.


Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on August 05, 2012, 08:04:23 AM

Excellent material, Kent. I've just been watching the first Bjarne Stroustrup lecture, and I totally concur with the points he makes.

We are not too far engrossed in WinApi. OxyyenBasic core depends on a tiny handful of Api calls. And Peter's graphics Windows is small and conceptually very easy to follow.

Macros deployed as typeless in-line procedures work well, in my view - but I anticipate these are discussed in later lectures. It is of course, all too easy to create evil mind-destroying code with macros, but several other constructs will do that just as well.

QT is Nokia property, I fear, but I would like to learn about GTK+

Charles
Title: Re: a case for architectural change in oxygen?
Post by: Aurel on August 05, 2012, 10:23:47 AM
Quote
It is of course, all too easy to create evil mind-destroying code with macros

I would like to see this ' evil mind-destroying code ' - how look this anyway...?
Of course Peter's functions present great small and simple way to do graphics.
I don't get it Kent why you are so facinating with all this c++11...etc stuf.
All this will be implemented or based on already used things in win api for
which you say that is outdated.
Documentation for oxygen is on very poor level and not provide crucial things on simple way.
Hovewer if Oxygen really goes to only C++ OOP direction i will give up.
Another point Kent...
in one of your previous post you say QT build to big output exe then now you say that is great.
QT if you don't know (development ) is stoped and Nokia sold QT to Microsoft.
GTK ...heh this is for linux ...just look vindows GIMP version, never can reach quality like PAINT.net.
And at last i want only use win api nothing else on Windows.
Or if new WinRT will cover the best of old api -this would be fine for me.
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on August 05, 2012, 11:10:13 AM
Aurel, yes it all works as you say. But it is old stuff. Not set for the future or a foundation for complex projects.

What I am saying is use c++11 for foundation of Oxygen. And actually to use a cross platform api instead of windows outdated 1980's c code. You can't believe how much nicer life is in this new world. You as an end user will not see C++, I understand you don't like it. But Charles and others who might then work in c++ can give you a BASIC set for the future. Write your code in the new Oxygen Basic, compile the same code in Windows, Linux, Mac or other devices that come up.

We can name this new BASIC, SuperBasic, or better yet superB. Superb means http://www.merriam-webster.com/dictionary/superb
: marked to the highest degree by grandeur, excellence, brilliance, or competence

Or O2superB  :)
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on August 05, 2012, 11:20:23 AM
Charles, Nokia sold off the commercial version of QT to another company. As you know Microsoft bailed out Nokia and I am sure they did not want a company they invested in writing a cross platform api that was a commercial product. The one at Nokia now is OpenSource. If they no longer can keep the OpenSource QT, then it goes by default to KDE which has made and contributed a lot to this opensource Qt.

You can read more here. I did and felt comfortable then in working in QT and not being left out in the cold.
http://www.kde.org/community/history/qtissue.php
Title: Re: a case for architectural change in oxygen?
Post by: Peter on August 05, 2012, 11:33:51 AM
Quote
However if Oxygen really goes to only C++ OOP direction i will give up.
 

Me too, too much c++ crap isn't good for our nerves. We want BASIC & API.
C++ and Linux are the evil.   :D
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on August 05, 2012, 11:58:15 AM
Peter, c++ is not OOP only, it supports both flat and oop. So Oxygen built on it would be the same way. You not have to deal with winapi old c code anymore. You will have nice basic syntax to a cross platform api that can run on all major platforms.
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on August 05, 2012, 11:59:45 AM
Here is a series of nice results gtk+ vs qt 2012. I am going to read through them. I did not play with gtk+, and just a little with qt. So reading these few top posts should be enlightening.
https://www.google.com/#hl=en&safe=off&sclient=psy-ab&q=gtk%2B+vs+QT+2012&oq=gtk%2B+vs+QT+2012&gs_l=hp.3..0i30l2j0i22.3034.9077.2.9227.11.11.0.0.0.0.206.1283.2j6j2.10.0...0.0...1c.kKm8JXx0oxI&pbx=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&fp=3caf70095441cb5a&biw=1920&bih=947
Title: Re: a case for architectural change in oxygen?
Post by: kryton9 on August 05, 2012, 12:08:24 PM
http://www.wikivs.com/wiki/GTK_vs_Qt

This along with many others say QT. I saw one for GTK, mostly because of gnome on linux and lighter download time for GTK apps in these distros, this is not important for cross platform.
Title: Re: a case for architectural change in oxygen?
Post by: jcfuller on August 05, 2012, 12:54:25 PM
Personally I prefer native windows on windows not Gtk.
I vote for wxWidgets or IUP

James
Title: Re: a case for architectural change in oxygen?
Post by: Aurel on August 05, 2012, 01:20:37 PM
I agree with James,native api for windows
and yes wxWidget looks far ative and better on windows.
Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on August 05, 2012, 02:09:07 PM

I am not evil enough tonight to dream up a really bad macro, Aurel. :)

You can use a macro as an alternative to a callback function.

macro keyboard()
case wm_keydown
   ...
case wm_char
  ...
end macro


This can be used to expose part of wndproc to the user, up-front. A large WndProc can thus be split into manageable sections: keyboard, mouse, timed-events, resize etc.

Charles
Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on August 05, 2012, 02:46:34 PM

I get the impression, Peter that like you, B Stroustrup is rather horrified at much of the code written with his language. His presentation is all about efficiency, safety and clarity - code that can be easily read and modified. He is by no means an idealog for OOP, and discusses the inappropriate use of Inheritance, protected members, getters and setters. (Perhaps he had Java in mind :) )

My initial aim is to make a C back-end available. The output does not have to be friendly to programmers.

Still a big headache developing for Android and other mobile devices. These systems are tightly stitched up with an IDE, a large SDK and an emulation system, which I think would be hard to penetrate to gain any advantage using Basic or other foreign language. All I see at present is system lock-in. Maybe this will change eventually.

Charles
Title: Re: a case for architectural change in oxygen?
Post by: Aurel on August 05, 2012, 09:30:01 PM
Quote
I am not evil enough tonight to dream up a really bad macro, Aurel. Smiley

You can use a macro as an alternative to a callback function.

macro keyboard()
case wm_keydown
   ...
case wm_char
  ...
end macro


This can be used to expose part of wndproc to the user, up-front. A large WndProc can thus be split into manageable sections: keyboard, mouse, timed-events, resize etc.

Charles

Thanks Charles ...
belive me i really don't know what is purpose of macro...
If this can be used like you say,this is very good option for me.. :)
I will try make some tests....
Title: Re: a case for architectural change in oxygen?
Post by: Aurel on August 06, 2012, 07:30:03 AM
Is macro a set of functions or something else?
I haave search trough all examples and cannot find any good example
about how create macro and how to use it?
Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on August 07, 2012, 12:12:33 PM
A macro is any construct that performs symbol substitution.

There are actually 4 varieties in OxygenBasic

%
#define
def
macro

macro()..end macro is probably the easiest to use, closely resembling a normal procedure (with params) in definition and invoking.

Unlike in many languages, they can be nested anywhere for local scope.

I don't have much on macros in one place but I will probably use the examples/MetaProg folder

Charles
Title: Aurel, Peter you guys need to watch this when you have time
Post by: kryton9 on August 07, 2012, 05:16:39 PM
Here is another reason for Qt as the foundation. Here is an awesome presentation running on a Raspberry Pi Arm computer, 40 Euros in cost.
Look at what can be done with modern apis in real time. We will never progress if we stick to what feels comfortable and not forge ahead.

I hope this video gives you guys some encouragement.
http://www.youtube.com/watch?v=0j-Wakm5B84
Title: Re: a case for architectural change in oxygen?
Post by: efgee on August 07, 2012, 10:12:49 PM
What a coincidence:
I've ordered my RaspberryPi last week  ;D

Thanks for the video, impressive stuff  8)
Title: Re: a case for architectural change in oxygen?
Post by: Charles Pegge on August 07, 2012, 10:59:48 PM

My concern is that QT is rather large for a dependency. I would like to have some controls and dialogs written in Oxygen, and encourage users to develop their own from source. If the controls  use OpenGl, they will not be MS dependent, but keeping the low-level graphics in a distinct layer will also help.

QML looks interesting.

http://en.wikipedia.org/wiki/QML

Charles

Title: Re: a case for architectural change in oxygen?
Post by: Aurel on August 07, 2012, 11:35:54 PM
Heh...
QML is sort of JavaScript layered with QT framework which is massive.
I will bet that Peter can make some sort of presentation like this with hes win.inc.
But he need one more GUI transparent window as editor .
I am not interested in Rpi at all ,i will rather digg my old ZXSpectrum ;D