Some general remarks on FreeBasic

[Galeon]

Why don't we create groups that could update each headers? We could divide the headers that is to be updated to those that are interested, I already updated some headers of GTK+.

[AGS]

Why don't we create groups that could update each headers? We could divide the headers that is to be updated to those that are interested, I already updated some headers of GTK+.

Updates to external libraries are bound to occur much more often than updates to the compiler. To me it would make sense to split the two. Just let the bindings be a separate, if needed 'non - official' part of the FB package. A bit like FBEdit: a lot of people use it but it's not part of the official release.

I've personally done sqlite3 bindings, IUP3 bindings and other bindings I never posted on this forum. I'm pretty sure I've seen more bindings out there.

A place for Bindings -> Work In Progress on the forum (don't know what the exact format should be) would be nice to have so programmers creating bindings would not have to do things twice. I've read some reactions on the forum where one person was busy doing bindings while another already had them somewhere on his PC or somewhere on the forum.

Apart from the need for new bindings there is the need to dump bindings to packages that are not being maintained any more. Currently the official FB release contains bindings to several libraries that are no longer being maintained (I've checked) and even a static library that contains a serious bug.

As far as creating bindings is concerned: it can be done semi - automated. Type definitions, function declarations, enumeration declarations etc... It can be done without having to type all that much.

As proof that it can be done: the FreePASCAL project uses a C recognizer to translate header files. I believe it keeps comments (it's
a lex/yacc kind of recognizer).

Those nasty function - like C macros will remain a problem. If a library contains a lot of them then it's going to take time to translate the macros. Overall I think it's a matter of good maintenance as application interfaces tend to be quite stable.

Then there is the matter of choice. Creating bindings for an enormous amount of libraries comes with a maintenance problem.

The bindings that are in the official FB package (the core bindings?) should be maintained while other bindings should be made available in the same place as the core bindings but without the promise of maintenance. And all bindings should be shipped with some examples.
No example = no binding.

I don't know how many people it would take to maintain the bindings.
For now it's a matter of updating the bindings and putting them somewhere FB programmers can easily find them.

As to the frequency of updating: you could do an update once every six months where a group of people check the bindings for updates. If someone wants to get his bindings in with the core bindings (in between the two update moments) then one person should take care of adding those bindings to the rest (make them available on line). Updates in between the two update moments should be rare.

Is there a standard for creating bindings? If not there should be one.
Something like this
http://www.debian.org/doc/maint-guide/

but shorter.

[stylin]

Check out this Google Code project:

http://code.google.com/p/freebasic-headers/

The bindings that are in the official FB package (the core bindings?) should be maintained while other bindings should be made available in the same place as the core bindings but without the promise of maintenance.

Eventually, a site like the above could provide that, with official distributions taking headers from there. One other possible use is to make bindings for previous versions easily available as well.

Those nasty function - like C macros will remain a problem.

Macros in general are the biggest problem, not just ones that take arguments. Commonly, those ones that are used as "aliases" for type/procedure/whatever names. But yeah, in the end, a bit of hand-translation is inevitable.

[marcov]

Is there a standard for creating bindings? If not there should be one.
Something like this
http://www.debian.org/doc/maint-guide/

but shorter.

For Delphi/Pascal there are some styleguides from Borland/Codegear. They are generally followed, though not too strict (or enforced)

[marcov]

Macros in general are the biggest problem, not just ones that take arguments. Commonly, those ones that are used as "aliases" for type/procedure/whatever names. But yeah, in the end, a bit of hand-translation is inevitable.

yes. Moreover C is simply context sensitive.

If you decide to make a translator I would advise to allow to specify that a certain identifier is a macro pertaining to calling conventions.

This will allow large bodies of functions to convert without manual intervention.

iow

Code: Select all

WINAPI int something;

//will translated to

function something:cint; WINAPI;

(something like WINAPI is typically a macro that specifies the default calling convention on a platform stdcall on Windows, cdecl on *nix, selected with an IF).

But that requires a small internal macro ability, despite the horror of the macros. (FPC has one, but afaik the FB one is already more advanced than the FB one, so I guess no problem)

[stylin]

(FPC has one, but afaik the FB one is already more advanced than the [FPC ?] one, so I guess no problem)

(If I understand what you mean) afaict, SWIG -- and thus v1ctor's or anyone's language module -- only "parses" variable-like macro definitions, and even then only if their value is a number or quoted text. Otherwise, you don't even get the opportunity to handle them. Conditionals (#IF, etc.) aren't placed in the parse tree either.

Moreover C is simply context sensitive.

Yeah, using CPP on the headers before translation isn't really an option either. However, my love of the preprocessor hasn't diminished because of its abuse by others. :)

[AGS]

@marcov
I take it the FreePASCAL developers would not mind if I kind of 'borrow' part of their C parser? I've got a FB version of YACC and a FB version of FLEX is in the making. And as I read Pascal syntax (who doesn't :) ) I think I can come up with something usable.

@everyone else
How about a call - out to all FB programmers that have bindings for an external library package just waiting to be put in the (soon to be formed) FreeBASIC external bindings central repository? Something like:
'Now hear this. Any FB developer that has bindings to some library that's newer then the ones in the current, official FB release...' etc.....

(pardon the English, I am obviously not the one to write such a call out).

Since it's the start of this repository (or whatever we choose to call it).

@stylin
I checked out the site( http://code.google.com/p/freebasic-headers/ ).

It should be made clear that new versions of import libraries are available from http://code.google.com/p/freebasic-headers/ as well. And if not it should be clear where to get new import libraries.

@people that want to contribute
So..... where shall we begin? What do we know about the state of the current bindings? These are the bindings I know to be outdated:

Bindings for gdsl are broken (it's a static library) and outdated.
Bindings for GTK+ are outdated.
Bindings for sqlite3 are outdated.
Bindings for IUP are outdated (import libraries might be broken).
Bindings for pdflib are outdated (I should know since I've used them myself).
Bindings for PCRE are outdated (7.6 in repository -> 8.1 is current version).
Bindings for GSL are outdated (1.6 in repository -> 1.13 is current)
Bindings for libxml are outdated (2.6.17 in repository -> 2.7.6 is current)
Bindings for Allegro are outdated (don't know what's in the repository but Allegro gets updated a lot).

The status of some packages should be reconsidered. I'm thinking of (not 100% sure of state of maintenance so if anyone has got better info on these package then please react):

GD and GRX
These are graphics packages that appear to be unmaintained since 2007 or earlier. There are other packages out there that deliver the same functionality but are being maintained.

WX-C and JAPI

These are 2 GUI packages and neither of them is being maintained.

WX-C is still being using by Haskell developers so they must be doing some updating (since WxWidgets is alive and well) but I'm not sure. And the WX-C bindings are big (151 include files).

Japi gives you an interface to the JAVA gui classes (Swing). It's unmaintained.

DISHELPER
Nope, this package should not be dropped but it is no longer being maintained.

DISHELPER gives FB programmers the possibility to use the COM interface so ActiveX components can be used (like you do with VBscript)
in an easy way.

Since .NET components can also be used by using the COM interface this looks like a package well worth keeping. I'd even consider translating it in full to FB or maintaining it ourselves.

I could go on and on and on so I'll end this by some questions to all involved (or wanting to be involved) in updating bindings:
1. What bindings need to be dropped (and for what reason) from the FB 'core' bindings (=the bindings that are in the official fb release now)?
2. What bindings need to be added (and for what reason) to the FB core bindings?
3. What should someone that creates a binding create (only .bi files, .bi files and import libraries, .bi, .dll.a and a static library (if possible)?
4. What should be at the start of a .bi file?

I raise the last point since the current .bi files start with something like this:
''
''
'' bfd -- header translated with help of SWIG FB wrapper
''
'' NOTICE: This file is part of the FreeBASIC Compiler package and can't
'' be included in other distributions without authorization.
''
''

I think the NOTICE should not be added to bindings that are not in the official release. That way it's clear that after installing FB the non - official headers will not be available (but can be downloaded from the packages repository).

And last but not least: what about cross - platform issues? Should the bindings created be cross - platform (by use of preprocessor directives or some other means) or would it be good enough if one can tell by looking at the start of a header file that it's part of a 'win32 bindings only' package (could be Linux only as well)?

It goes without saying that bindings that are in the official FreeBASIC compiler package will be maintained at the bindings repository.

And when it's time for an official release of the FreeBASIC compiler those bindings can be included in the official release.

Almost done with the talking (I think) so it's time to start updating some bindings.

I'm going to do sqlite3, iup3, gdsl1.4 and send them to a place we can all agree on. If no agreement can be reached on that place I'll start a thread in the "External Libraries" part of the forum and place links to the packages there. The link will lead to the place where I put all my FB stuff like, for example, this def file:
http://www.sarmardar.nl/FreeBASIC/sqlite3.def

(The URL www.sarmardar.nl/FreeBASIC will get you nowhere though)

Let the updating commence!

[stylin]

It should be made clear that new versions of import libraries are available from http://code.google.com/p/freebasic-headers/ as well. And if not it should be clear where to get new import libraries.

Yeah, I agree that import libraries should be built and kept there as well. I'm sure sir_mud (the project admin) would appreciate your input on the matter.

1. What bindings need to be dropped (and for what reason) from the FB 'core' bindings (=the bindings that are in the official fb release now)?
2. What bindings need to be added (and for what reason) to the FB core bindings?

I don't see a problem with a site like the above becoming an official source for external lib bindings.. I think cha0s may have some ideas on how to modify the site and/or WIndows installer in order to download/install whatever bindings the user wants. If getting these bindings is made super easy, then distributing any with the compiler makes less sense, IMO.

3. What should someone that creates a binding create (only .bi files, .bi files and import libraries, .bi, .dll.a and a static library (if possible)?

You'll have to find some other host than Google/Sourceforge if you want to store binaries.

[marcov]

@marcov
I take it the FreePASCAL developers would not mind if I kind of 'borrow' part of their C parser? I've got a FB version of YACC and a FB version of FLEX is in the making. And as I read Pascal syntax (who doesn't :) ) I think I can come up with something usable.

It's under the library license (LGPL with static linking exception)

Though I still think trying to convert FPC bindings will be faster. They can probably be automatically converted, and kept in sync.

[marcov]

(FPC has one, but afaik the FB one is already more advanced than the [FPC ?] one, so I guess no problem)

(With that I mean the macro support in the compiler, not the translator)

(If I understand what you mean) afaict, SWIG -- and thus v1ctor's or anyone's language module -- only "parses" variable-like macro definitions, and even then only if their value is a number or quoted text. Otherwise, you don't even get the opportunity to handle them. Conditionals (#IF, etc.) aren't placed in the parse tree either.

It was more a remark to allow an user to decree a certain identifier a "calling convention related macro". It thus simply moved from before the function declaration in C) to after the declaration of the function (in Pascal)

It is simply a common usecase, often hitting every function in an header.

Yeah, using CPP on the headers before translation isn't really an option either. However, my love of the preprocessor hasn't diminished because of its abuse by others. :)

Give it time :-) There was a time that I thought that self modifying POKE statements were cool too, and fit for normal day-to-day practice.

[AGS]

@marcov
I take it the FreePASCAL developers would not mind if I kind of 'borrow' part of their C parser? I've got a FB version of YACC and a FB version of FLEX is in the making. And as I read Pascal syntax (who doesn't :) ) I think I can come up with something usable.

It's under the library license (LGPL with static linking exception)

Though I still think trying to convert FPC bindings will be faster. They can probably be automatically converted, and kept in sync.

Interesting option... parsing PASCAL sounds a lot better than parsing C.

And thanks, marcov, for sharing your experience as a FPC developer.

[freeBasir]

Seems like it shouldn't be too hard to write a C header to FB header conversion program. That should solve the problem, shouldn't it? Just run it against the current C headers and you immediately have up-to-date FB headers. It's been awhile (years) since I've looked at FB and used it, and am looking at it again, so I don't know a lot about it right now.

[segin]

@McLovin

That's not true. I've already delivered some contributions to FreeBasic (see some of my previous postings, e.g. bindings & examples for a PDF library, a plotting library and a glade converter for FreeBasic).
What I want to make clear is the following: some people have already done the work, but there is no process in place how to bring these bits and pieces into the end product. So why invent the wheel twice?
I've seen other projects where anybody can put his work into an "incoming" folder. Then a person or a group makes a test and comes up with a decision which contributions should be added to the product.
Just to make clear: I really like FreeBasic and wish that FreeBasic would become the language of choice for many developers all over the world.

//haegar

Well, those updated libs are out there. Are you too lazy to STFF/SWFT (Search The #%$@ Forums/Search The #%$@ Web) for them?

If you want it more Linux-like, then all we should give you is the source code to just the compiler. Force you to download the runtime library, graphics library, includes, etc. each of them from somewhere else and compile all the source yourself. All Linus gives the community is the source code to a kernel. There's no underlying OS guts that come with that.

The FreeBASIC project is here to make a BASIC compiler; ensuring that the included library binding are up-to-date is simply done as a convince to the end-user and is actually outside the scope and goals of the project.

This pure hand-holding that you request is coming out of the woodwork everywhere on the forums and is getting annoying. It's probably what will destroy the FreeBASIC community. Please, learn to think, and then learn to think for yourself. It's not that hard.

[freeBasir]

@McLovin

That's not true. {snip}

Well, {snip}

With an attitude like that, it's no wonder this project is where it's at and basically failing. Especially if more people have it or support it.

[vdecampo]

@Freebasir

Your comments might carry more weight if you didn't just have 18 posts to this forum over the past 4 years. Not enough free code for you? Why not try contributing a little before condemning this project and those who actually care and participate in its ongoing popularity?

Friggin lurkers and freeloaders!!

-Vince