Dreams for freebasic's future...

[xiNoNix]

So I do also have dreams and wishes what FreeBASIC should be like.

And you're applying the actions to see those dreams realised. Props to you.


Just a thought - and not necessarily a deep one - brainstorming (or brainpharting) a bit ...

Both MS and Mozilla provide a means for embedding their browsers in an application. It should be possible, via javascript and/or natively, to expose FB objects to the browser and vice-versa. This could be used to provide a cheap method of interfacing FB with, for eg, Java and other web-oriented scripting engines.

If GCC is implemented as front/back end for FB, inline C/C++ is possible?

Maybe a large chunk of your dreams are already within grasp, thriller, albeit perhaps, for the purists, in a rough and an inelegant way.

With OOP (and perhaps even now, with a stretch) Macromedia Flash can be embedded in an app. Imagine a flash front end and FB backend. :)

Not sure how Delphi componentry works, or if Kylix is still alive for the *nix side, but if Newton can be grasped, why not a delphi component.

The vision you have is quite exciting. The work, though .. ah, I am a lazy person and the work does not seem as exciting. :)

[jofers]

Javascript is an interpreted scripting language. You could already script javascript in your program if you use Mozilla's Spidermonkey engine. If there's a C interpreter library out there (there's one mentioned in the libraries forum), you could use that, but it would be much slower than regular compiled code.

Inline support for other languages would require writing a new compiler frontend for each little tiny segment of code, which would suck to code and bloat the compiler for a little feature.

But yeah, integrating FB with other scripting languages is already a possibility.

[xiNoNix]

Has anyone played with the mozilla or ie ocx with FB?

I'm thinking that if a browser capability was embedded, then things like php can be run and either via an interface or through a tweak with js, the FB prog and the "web page" could communicate.

You could roll your own browser, just like all the other "myBrowsers" out there written in VB and using the IE control. :) But you could also get access to all those web-oriented scripting languages on the cheap.

[v1ctor]

The problem with inline anything-else-but-ASM is: how to access symbols? Variables, constants, functions..

If you take for example C, it would have to be done like:

Code: Select all

foo = 1
inline "C"
 ++*foo; /* only indirectly, see below */
end inline
print foo

What would be translated to:

Code: Select all

/*_fb_SourceName_InlineC_SomeTempName.c*/
_FB_SOURCENAME_INLINEC_SOMETEMPNAME_PROC( int *foo )
{
   ++*foo; /* only indirectly, see below */
}

gcc -c {path/}_fb_SourceName_InlineC_SomeTempName.c -o {path/}_fb_SourceName_InlineC_SomeTempName.o

Code: Select all

foo = 1
declare sub _fb_SourceName_InlineC_SomeTempName_Proc( byval as integer ptr)
_fb_SourceName_InlineC_SomeTempName_Proc( @foo )
print foo

And the temporary object file would have to be added to the LD list.

Not impossible, just way too clumsy, just writing it in C instead would be much simpler. With scripting languages or anything that depends on other runtime libraries, forget.

[VirusScanner]

It would be better to write code in C if you really want to, and compile it with GCC. FB is compatible with GCC compiled objects at the current time, so you can link with any language that uses ld really.

[thriller]

OK, there seems to be some misunderstanding. I didn't mention to implement inline feature by freebasic herself. It's really stupid for me to say that if you think so. I said 'allow', which is misspelt :b, that is, to allow other compiler like gcc to proceed the c, etc. so as to reduce the hard and unnecessary work to translate the unfamiliar language to basic. As it has been decided to port freebasic to gcc (or even mono, who knows) it'll be really an exciting dream of doing so. If successful, plus powerful user-friendly IDE, FreeBASIC will be the first class of BASIC for all.
I love BASIC, that's why I love FB. I love you, that's why I post it here.
Keep up with our creative work, we will be happily successful.
Let FB live everywhere in our life.

[tunginobi]

You could have inline C, but then you have the context problem outlined by v1c. But what about inside subs or functions? That'd work out fine, except it'd be no different than making a separate C source file, compiling that to an object file, including the definitions in a FB source file, and compiling and linking that.

I remember QB being able to link with object files from Pascal and C, though I've never tried my hand at it myself.

[rfc1394]

Hello there.
This is the first post of me, sorry for my bad English.
I almost lose my interest in basic until my first eye on freebasic.
That's the basic we ought to have, I think. Thanks v1ctor for the creative work!
I believe FB can do most program things even now at it early age.
Some dreams of me as flws:
1. A powerful FB IDE like VB 6.0. Maybe we can even try to program FB in VB6 IDE with some add-ins. An xml format of project file is also very good idea besides makefiles. RadAsm is good, but open source ide in freebasic itself will be better.

The IDE that works with Freebasic does a nice job. It's not as "smooth" as Visual Basic but at least it doesn't have that nasty feature of immediately banging back at you with a messagebox when you type in something that contains a syntax error. It makes it irritating when I'm doing a manual translation of something I know has errors and I'm fixing it.

I think the answer would be to tie in to the IDE some form editor similar to the one in Glade (I think that's the name) that is used to write GUIs for GTK or KDE so the system would be portable. I have an Open Source program called Inkscape that makes SVG files which I believe uses that toolset or something like it and it also runs on Windows.

2. Realtime interpreting like vb6 debug window.

In theory you could do something like this, problem being that Visual Basic is to a large degree an interpreter, not a compiler. Check out a program called XBasic which is another open-source Basic but is more of an interpreter I do believe. (I soured on it because it was much too slow for my taste). It may be more helpful to you.

3. Option to be compatible with visual basic, power basic, realbasic, full basic, etc.

There is an issue that sometimes confuses users of Windows from users of Linux is that the GUI shell is strongly bonded to the operating system on Windows 95 and above, but X-Windows on Linux is not part of the OS and is totally optional or can be replaced. The same conditions apply to FreeBasic in that the code compiler - Freebasic itself - is separate from and generally is not connected to the program development environment (such as FBIDE) used to write code. This would require putting hooks in the system to allow such features and would require considerable work. The system wasn't designed to allow interpretive execution and thus adding it would be a lot of trouble.

4. Alow inline c/c++, pascal, java, php, perl, python and/or others to reduce the translation work. Many open source projects change their header file when they update. If we can use .h directly, we will have the power to use new header files accordingly i/o new trans works.

This one I happen to agree with. It's one of the things I'm thinking about, the ability to change the target language that FreeBasic generates. But the answer would be to implement something in the Preprocessor to support this, or implement a way to allow the compiler to change the target language it generates in compiling code for the compiler. That requires rewriting the code generator to support a new hosting environment in place of 386 Assembler.

Now, however, PHP, perl and Python are interpreted languages. It would require some means to invoke their interpreters and keep the source code of the included code as part of the generated program, then pass that code onto the interpreter. Since it most likely would run in another memory space, then you have the issue of how to let the interpreter that is called know where the local variables in yout calling program are.

This would be better addressed by calling the interpreter through something like a CHAIN statement and using files (or ramdisk files) or pipes to pass data. It also is something you can do now, you don't have to wait for someone to figure out how to implement it.

5. Cross-platform gui/non-gui controls/component support, better if support for DELPHI component.

This is a big problem because it requires a great deal of intimate support for Windows controls, implementation of the IUNKNOWN interface in order to support controls, access to COM and DCOM and a lot of work. Visual Basic has it because Microsoft wrote it. Delphi has it because Borland has the money to spend tens of thousands of dollars to hire people who know how to use it and buy the complete Microsoft documentation for Windows 95 and the MSDN and Visual C compilers to start development. We don't have that kind of luxury.

6. Ability to create web/internet servers support for FB/FB scripted files. That’ll be cool.

There is an interpreter called ScriptBasic that could be used to create Basic language CGI scripting and might be more appropriate for such a purpose. There are different tools for different purposes and no one language or compiler is good for all of them.

[VirusScanner]

I hear gdb does a great job at debugging, I've never used it though. But once FBIDE is integrated with it and has projects, we'll be doing great.

[counting_pine]

The IDE that works with Freebasic does a nice job. It's not as "smooth" as Visual Basic but at least it doesn't have that nasty feature of immediately banging back at you with a messagebox when you type in something that contains a syntax error. It makes it irritating when I'm doing a manual translation of something I know has errors and I'm fixing it.

You should be able to turn that off. In VB4, you just go to Tools-Options-Environment, and uncheck "Auto Syntax Check". Instead of a dialog box, it will just make the entire line red. Hopefully there'll be similar options in other versions.

[BastetFurry]

Function MakeGame ( number_of_levels, game_type )

Hmm, would be a nice idea, a random game generator *g*
But i would give some more options....

Code: Select all

function MakeGame(NumberOfLevels as unsigned integer, GameType as unsigned short, Difficulty as short, NetworkSupport as unsigned byte, MinimumPlayerAge as unsigned byte)

(MinimumPlayerAge is for all those people who want their stupid hentai games... set GameType to JapanAdventure and Difficulty to -10 and you have it :P ;) )

[BastetFurry]

Borland has the money to spend tens of thousands of dollars to hire people who know how to use it and buy the complete Microsoft documentation for Windows 95 and the MSDN and Visual C compilers to start development. We don't have that kind of luxury.

You are wrong in some points.
We dont have the money to pay some überpros, ok.
But, if we need Win32 documentation or want to know the inner workings we should head to reactos.com.

[Rudiger]

Sometimes this sounds like a C++ forum. mean and nasty.

I dont think there's anything wrong with someone coming here and saying he likes FB and has some dreams.

and I dont think having a powerful IDE and debugger is so far fetched is it?

as for GUIs, I think GTK is the best thing out there for cross platform. My dream (well, one of my dreams that's appropriate for this forum) is that someday the GTK for FB will be more than just a plugin. GTK is already pretty easy to use, but could blow away a lot of commercial products if it were well integrated into FB.

[tunginobi]

I dont think having a powerful IDE and debugger is so far fetched is it?

For people who aren't being paid and are not part of an organised network, you have to admit that it is a little far-fetched. It's a nice idea, but there's a reason it's almost exclusively found in Visual Studio products: it's frickin' hard to do! :P

as for GUIs, I think GTK is the best thing out there for cross platform. My dream (well, one of my dreams that's appropriate for this forum) is that someday the GTK for FB will be more than just a plugin. GTK is already pretty easy to use, but could blow away a lot of commercial products if it were well integrated into FB.

Actually, there was some recent discussion about making a FB-native GUI, which would be both small and cross-platform. I don't know about the current progress.

[Rudiger]

I hope the people who design an FB GUI will make it so that C++ programmers will want to use it. And that if the C++ programmers want to use it, THEY will have to spend hours googling and reading documentation and running swigs and such. Now that would be a nice switch.