C BASIC

[marcov]

Do you know the GObject Introspection (GI) project?

Yes. But I would put that on the level of COM, not the win32 api.

Moreover, where can I find gobject versions of e.g. database client libraries as mysql, postgresql, pcre, libc etc?

[TJF]

Yes. But I would put that on the level of COM, not the win32 api.

Gtk+ one the level of COM?

Moreover, where can I find gobject versions of e.g. database client libraries as mysql, postgresql, pcre, libc etc?

GNOME-DB (libGda)

[marcov]

Yes. But I would put that on the level of COM, not the win32 api.

Gtk+ one the level of COM?

Why not? GDI+ is COM based, so is DirectX. Maybe more specifically IDispatch even.

The point is that it is an OO interface that allows to wrap native tools for scripting languages and JIT-VMs.

Moreover, where can I find gobject versions of e.g. database client libraries as mysql, postgresql, pcre, libc etc?

GNOME-DB (libGda)[/quote]

I would need access to those for my own abstraction layers, to each call in their libs. That is why I translated their headers. (admitted, for FPC, but the story for FB is the same). I don't need a 3rd party abstraction layer. (and specially not one that misses the more major dbs, like Firebird, SQL Server and Oracle, or their website is outdated)

We were talking about getting access to APIs, and you point me to a totally different api. Apples and oranges.

[TJF]

Apples and oranges.

Yes, often you throw oranges in a apple discussion.

We were talking about getting access to APIs ...

Yes, that's how we started, until you asked

...where can I find gobject versions ...

What's wrong when I answer?

Now you want to put your own abstraction layer on top of an existing one. You're free to do so.

I prefer to use existing software (that's why we initially talked about API access). Sometimes I have to improve a library. When I need a Firebird DB access, I write a prowider adapter for libGda instead of building a further abstaction layer and wait for anybody to write the matching client providers. (Btw: Oracle is included since 4.2, Firebird is under development, SQLserver isn't important (an alternative may be freeTDS). And yes, some parts of the GNOME-DB website are outdated.)

Did you have to much Christmass parties today?

[marcov]

We were talking about getting access to APIs ...

Yes, that's how we started, until you asked

...where can I find gobject versions ...

What's wrong when I answer?

They are not gobject versions of the postgresql APIs. They are database abstraction that happens to be gobject and support postgresql. Something totally different from a postgresql API that is easy to convert to new languages because of gobject.

The core point being postgresql API being asked, not ways to interface any database by other means.

Now you want to put your own abstraction layer on top of an existing one.

No. I gave an example why I wanted access to the postgresql API. I didn't ask for any abstraction, which I merely illustrated by saying that I already had a more established framework for that.

I prefer to use existing software (that's why we initially talked about API access).

Me to, and I use this database abstraction since Delphi2, circa '97 (the interfaces, there are several implementations and major rewrites, proprietary and free ones).

Sometimes I have to improve a library. When I need a Firebird DB access, I write a prowider adapter for libGda instead of building a further abstaction layer and wait for anybody to write the matching client providers

That's what I was doing more or less. Adding apis (or expanding their use) to venerable well known abstraction layers. That was an example.

. (Btw: Oracle is included since 4.2, Firebird is under development, SQLserver isn't important (an alternative may be freeTDS). And yes, some parts of the GNOME-DB website are outdated.)

We use FreeTDS (strictly) too, but Delphi supports it via ADO/dblib. FPC is has had improvements recently, so maybe that route can be reattempted (dblib/ADO is said to be more performant). There are also 3rd party proprietary drivers that speak wire protocol directly, usually from a more performance perspective.

Did you have to much Christmass parties today?

No, of course not. Today is my birthday, so other parties are more important.

P.s. there is no such thing as the abstraction layer to end all abstraction layers. There are choices there (as portable to as many databases as possible, supporting a subset of databases better, performance etc etc).

[TJF]

Today is my birthday

So happy birthday!

Stop discussion, throw a party!

[sean_vn]

I guess this is not the forum to talk about it, but there are very few forums to talk about basic. It could have been a nice discussion.
Maybe people should try to do some hobbies outside programming as well. Programming is very intellectually limited. Even with high level languages it still boils down repetitious reasoning with logic and arithmetic. You should not get so overly caught up with it and go do some other things as well. For example ham radio, hobby electronics, model making or do some evening classes.

[leodescal]

The thousands of embedded controllers running ScriptBASIC in firmware don't post to the forum. It just shows how ignorant some people can be. ScriptBasic is an API and folks here treat it like it's PowerBASIC trying to take it's users away and sell them something. Get a life.

Oh these words are very harsh :(. I read the whole post I advice when you don't like a community and community don't like you the best solution is to not come there back. I have seen you telling many time how bad FreeBASIC really is and great glories of ScriptBASIC. And your claim of 'thousands' of embedded controllers I doubt is true but even then note that FreeBASIC get thousands of downloads EVERY WEEK.

FreeBASIC is very general purpose language which gives most group of programmers happiness. It have a assembler and c emitter... more targets under way. I haven't tested llvm target yet to see if it is stable or not. 62 bit is really in the way- check to do list at git but then like you sing glory of your achievements, the specialized solution of problem you need could be quickly fixed by you. FreeBASIC devs are very helpful and would help you. I wanted native FreeBASIC 0.90.1 on the FreeBSD and gcc emitted code to get automatically compile by -O3 and link against rtlib which is also compiled by -O3 and this all should work on a 64 bit FreeBSD system. It took a day or two with generous help from dkl I was able to solve it and have a working FreeBASIC on 64 bit FreeBSD. And about one good greatness of Oxygen BASIC, ability to include C libraries directly, well it wouldn't be much problematic to solve this problem in FreeBASIC as FreeBASIC ALREADY have a working C emitter.

[TJF]

And about one good greatness of Oxygen BASIC, ability to include C libraries directly, well it wouldn't be much problematic to solve this problem in FreeBASIC as FreeBASIC ALREADY have a working C emitter.

Are you sure? IMHO you'll have to integrate something like fb-frog or h_2_bi into the fbc to make use of the C symbols in FB source. (fb-frog doesn't handle macros yet and h_2_bi macros need adaption for that purpose.)

[marcov]

And about one good greatness of Oxygen BASIC, ability to include C libraries directly, well it wouldn't be much problematic to solve this problem in FreeBASIC as FreeBASIC ALREADY have a working C emitter.

Are you sure? IMHO you'll have to integrate something like fb-frog or h_2_bi into the fbc to make use of the C symbols in FB source. (fb-frog doesn't handle macros yet and h_2_bi macros need adaption for that purpose.)

Indeed, and the macros could contain full inline C programs, so that would more or less implementing a full FB+C hybrid frontend, and to interoperate the FB language must fully map to C on each level.

(and that mapping is not entirely the same as having a C backend. E.g. if you have some automated type, the C code in macros won't respect that, while the FB code compiled to C by the backend will)

[TJF]

(and that mapping is not entirely the same as having a C backend. E.g. if you have some automated type, the C code in macros won't respect that, while the FB code compiled to C by the backend will)

Right. First of all, the symbol names (variables, types, macros, ...) in FB source have to be case-sensitve. It's neccessary to define a new dialect (ie #LANG "polyglot"). What happens when the code is in mixed dialects?

[angros47]

Also, there is no point in making a basic compiler accept c code, or vice-versa. Mixing basic and c code was possible since first version of freebasic: you just have to write a module in c, compile it with gcc -c to produce an object file, and link it to freebasic code: in freebasic you have to declare the c functions... but you'd have to declare these function even if they were written in freebasic, since they are in another module.

Also, with this solution you can also add modules written in freepascal, or assembly, so it's really "polyglot".

About C header files: some of them are just declarations, but other can contain code (i.e. inline functions)... just like FreeBasic include files. So, any solution for including .h files would cause more troubled than help, since some headers will work, other won't... and someone who knows FreeBasic, but not C, would not be able to understand the issue.

The solution is to provide tools for translating c header files to FreeBasic: translation might work or not, but it can be fixed by hand. Such a tool already exist: swig.

[TJF]

The solution is to provide tools for translating c header files to FreeBasic: translation might work or not, but it can be fixed by hand. Such a tool already exist: swig.

I made two of these tools (h_2_bi and GirToBac -- the most advanced, I guess). And I've some experience in translating small and not so small headers. But I'm still searching for a better solution.

About C header files: some of them are just declarations, but other can contain code (i.e. inline functions)... just like FreeBasic include files. So, any solution for including .h files would cause more troubled than help ...

Sorry, that's wrong. Directly including C headers by fbc will solve the inline function problem.

[leodescal]

And about one good greatness of Oxygen BASIC, ability to include C libraries directly, well it wouldn't be much problematic to solve this problem in FreeBASIC as FreeBASIC ALREADY have a working C emitter.

Are you sure? IMHO you'll have to integrate something like fb-frog or h_2_bi into the fbc to make use of the C symbols in FB source. (fb-frog doesn't handle macros yet and h_2_bi macros need adaption for that purpose.)

Not talking about using it directly in FB source, that is theoretically possible because there are C preprocessor modules already in open source compiler, so building on that base ability to 'perfectly' translate is possible but extremely difficult work full of endless cycles of tries to do if my experience with translations between complex programming languages are any true...I did tried basic C -> BASIC translators some time ago in free time for fun, but C have a very liberal syntax, you can theoretically write whole programs in a line!

What I really meant was making FBC to ignore errors and generate c file, then include c library you want to use from there, then manually compile it by GCC. Obviously this isn't a clean solution at all. If you can work harder, then add custom command to consider functions/variables/defines valid at syntax check without actually defining them and then generate c code which emit the c include at top. And then rest is same, include library you want from there. This second solution can be further make more professional looking by creating includes like "abcd.bi" which would contains list of functions/variables/defines valid at syntax check without actually defining them.

[TJF]

@leodescal

... in short, compile by hand :)