h_2_bi.bas, a tool for translating .h files into .bi

User projects written in or related to FreeBASIC.
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby TJF » Mar 12, 2012 13:48

dkl wrote:... especially the behaviour with statement separators is confusing to me everytime...

I like statement separators. Artful usage helps to make the code more readable. My code normaly goes from top to bottom without separators. But in case of an exeption (like in the example above) it goes sidewards. This helps to get more lines on the screen and that means less code jumping and better overview.
MOD
Posts: 555
Joined: Jun 11, 2009 20:15

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby MOD » Jul 24, 2013 19:19

Hi TJF, I have some issues.

I tried to write a h_2_bi plugin for wxFBE. My idea was based on "-g", but sadly it doesn't work as I wish:

1.
Da keine Dateinamen spezifiziert werden, liest h_2_bi die Spezifikationen
für die Überseztung aus einer standard Steuer-Datei 'Geany.h2bi' im
Verzeichnis des h_2_bi Programmes. Falls die Datei nicht vorhanden ist,
werden die Standardeinstellungen verwendet.

This quote is from the LiesMich.txt (the ReadMe doesn't contain the second sentence), but if this file does not exist, it simply stops working.

2.
Bidirectional pipes are not supported by FB and must be implemented using the OS' API functions.

This quote is from the OpenPipe wiki page. As "-g" uses stdin and stdout, 'Open Pipe' is no option. I can call h_2_bi and write the code to it but the output will end in my console.
Is there any other way how I could pass code directly without using temporary files?
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby TJF » Jul 25, 2013 7:16

Hi MOD!

First let thank you for your interest on h_2_bi and your effort to integrate it in wxFBE.

Please consider: when you fork h_2_bi.bas in to a plugin, your users want adaptions for each h_2_bi update. When you implement a 'custom command' (as in Geany, Remember this posts?) the users of wxFBE can use h_2_bi out-of-the-box and all further updates will work as well. And similar tools like fb-doc or FBeauty will work.

h_2_bi itself doesn't need bidirectional pipes. It uses one pipe for input and another for output (and may use a third for error messages in future).

But the calling program needs a bidirectional pipe to get input from and send output to the same channel. Geany uses GLib for that purpose (g_spawn_...). You may #INCLUDE ONCE "glib.bi" for that feature. (I'm not sure: there may be similar features in CRT.)

A workaround is (as you mentioned) to write the h_2_bi output to a temporary file.


MOD wrote:... but if this file does not exist, it simply stops working.

I cannot reproduce this behaviour. Ie (LINUX example, executed in an empty folder-- no file Geany.h2bi, system wide h_2_bi install)

Code: Select all

$ echo "#include <stdio.h>" | h_2_bi -g
' 001 start from: Geany.h2bi ==> GeanyBlock

' #include <stdio.h>
#INCLUDE ONCE "crt/stdio.bi" '__HEADERS__: stdio.h

' 001 back from GeanyBlock ==> Geany.h2bi
MOD
Posts: 555
Joined: Jun 11, 2009 20:15

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby MOD » Jul 25, 2013 8:21

the users of wxFBE can use h_2_bi out-of-the-box and all further updates will work

That was my plan. The plugin just provides a menu and then call the h_2_bi binary.

Remember this posts?

I remember it but the possibility of using plugins is new to wxFBE. So I don't need to integrate it completely into the editor. In a plugin it's perfect.

All you need in wxFBE is to call h_2_bi in a bidirectional pipe

This is the bottleneck at the moment, as FB doesn't allow such pipes at the moment (maybe in future). I think I'll have to use a temporary file. :\

fb-doc or FBeauty

I thought about fb-doc, maybe we could create a plugin for it, too. As far as I read, everything FBeauty does, is to format FB keywords. That's something wxFBE does automatically. It also provides some settings. Furthermore, I checked the latest code and the registered keywords. A lot of new keywords are missing.

I cannot reproduce this behaviour.

I've tested it on Windows7 x64 with the latest download at the project page at FreeBASIC-Portal.de.
If this file exists I see the correct translated code in the console, but if it's missing it just writes, that it's missing and no more code appears (I'm currently not at home, I could post the exact error message later).
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby TJF » Jul 25, 2013 14:19

OK, I understand: a plugin calls the original h_2_bi binary. The user is free to install that plugin or not. What about using GLib just for that plugin? (Or replacing wxWidgets by GTK+ ?-)

MOD wrote:I thought about fb-doc, maybe we could create a plugin for it, too.

It could be the same plugin as for h_2_bi. You'll need just an other command line.


Regarding FBeauty:
MOD wrote:A lot of new keywords are missing.

I don't think so. All keywords from fbc-0.90 are included. (AFAIR. Anyway, FBeauty may be no help for an FB specific editor like wxFBE. I just mentioned it as an example.)

MOD wrote:
TJF wrote:I cannot reproduce this behaviour.

I've tested it on Windows7 x64 with the latest download at the project page at FreeBASIC-Portal.de.
If this file exists I see the correct translated code in the console, but if it's missing it just writes, that it's missing and no more code appears (I'm currently not at home, I could post the exact error message later).

Yes, please send more information.

Since version 0.2.2 the name of the config file can be specified. h_2_bi writes an error message to the output, if the specified file name doesn't exist (but never should stop):

Code: Select all

$ echo "#include <stdio.h>" | h2bi ddd -g

  Unable to read: ddd.h2bi
' 001 start from: Geany.h2bi ==> GeanyBlock

' #include <stdio.h>
#INCLUDE ONCE "crt/stdio.bi" '__HEADERS__: stdio.h

' 001 back from GeanyBlock ==> Geany.h2bi

(OK, this example shows that I should adapt the messages.)
MOD
Posts: 555
Joined: Jun 11, 2009 20:15

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby MOD » Jul 25, 2013 15:59

What about using GLib just for that plugin?

Possible, but this would mean, that one had to deliver all the Gtk DLLs on Windows, just to make one single plugin work. I'll better stick to a temporary file.

Or replacing wxWidgets by GTK+

Never.^^

All keywords from fbc-0.90 are included

Missing keywords (maybe I missed some others - based on the latest download at FreeBASIC-Portal.de):
__DATE_ISO__, __FB_64BIT__, __FB_BACKEND__, #ASSERT, ABSTRACT, OVERRIDE, THREADCALL, VIRTUAL

Yes, please send more information.

The exact message is "Cannot Open: Geany.h2bi", nothing more.
If I create an empty file with this name I'm getting the correct output.
h_2_bi version: 0.2.2
I'm calling this: "h_2_bi.exe -g"
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby TJF » Jul 25, 2013 21:34

MOD wrote:Possible, but this would mean, that one had to deliver all the Gtk DLLs on Windows, just to make one single plugin work.

Not all GTK+ DLLs. Just libglib-2.0.dll. (GLib is the basis.)

MOD wrote:Missing keywords (maybe I missed some others - based on the latest download at FreeBASIC-Portal.de):
__DATE_ISO__, __FB_64BIT__, __FB_BACKEND__, #ASSERT, ABSTRACT, OVERRIDE, THREADCALL, VIRTUAL

Indeed some of them are missing (in my development version 0.2.3). Thanks!

MOD wrote:The exact message is "Cannot Open: Geany.h2bi"

I just uploaded an update (version 0.2.4). It should be fixed now.
MOD
Posts: 555
Joined: Jun 11, 2009 20:15

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby MOD » Jul 27, 2013 8:43

It should be fixed now.

Confirm. :)
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby AGS » Jan 14, 2014 8:24

In 2011 a new version of the C standard, C11, was released. And
gcc has implemented most of the changes from C11.

As h2bi translates C header files to fb header files the new
standard could have an impact on h2bi. I've looked at the
new standard to see whether it contains things h2bi should be
able to deal with.

C11 added some new keywords which should get incorporated into
h2bi.

First up is a new storage class specifier (used like you'd use static, extern, register or auto).
_Thread_local
_Thread_local is just here so you know it's out there. According to the standard _Thread_local
cannot be used in the declaration specifiers of a function declaration.
Which means h2bi only has to deal with _Thread_local as it appears in combination with variables
declared as extern or static. Translating _Thread_local is not possible (no fb equivalent)
and dropping it during translation is the right course of action. _Thread_local is more of
a hint to the C compiler than anything else (not something h2bi should be too concerned with).


The following are two new type qualifiers
(used like you'd use const or volatile)

restrict
According to the C11 standard restrict can be dropped from source
code without impacting the correct functioning of a program.
Hence h2bi can simply drop restrict from C declarations (eg drop
restrict during translation).

Restrict is the one keyword I think will pop up in the wild
soon. It's related to pointer aliasing (code optimization) and
because a compiler can simply ignore it and still be standard compliant
I can see how restrict could see some use from C programmers.

Standard header files found in the standard already use the restrict
keyword which is telling (I think).

Moving on to the next keyword.

_Atomic
_Atomic should be recognized by h2bi. And subsequently dropped.
There is no fb equivalent for _Atomic and _Atomic is more of a hint
for the C compiler on how to deal with a variable. An example.

Code: Select all

_Atomic int a(int b);


a returns an integer with an _Atomic qualifer. But an int is an int is an int
regardless of the addition of the qualifier _Atomic.

That's it as far as qualifiers are concerned. Next is a new type specifier.
(used like you'd use be int, void, struct etc...)

_Atomic(type-name)
Yes, that's the same keyword used in a different context. If _Atomic is immediately
followed by ( it's a type specifier. Otherwise it's a type qualifier.
Confusing, isn't it? Same deal as using _Atomic as a type qualifier with one difference.
According to the C standard a declaration HAS to contain a type-specifier.

_Atomic used as a qualifier can be dropped as it only adds something to a type-specifier.
The type-specifier cannot be dropped as that will render the declaration useless.
So dropping _Atomic(type-name) completely is not an option.

_Atom(type-name) could be translated as if it read type-name. And then h2bi can translate
type-name in the usual manner.
An example to clarify.

Code: Select all

extern _Atomic(int) a;

The size of an _Atomic(int) can differ from the size of an ordinary int. It can but it
doesn't (at least it doesn't in gcc).

_Atomic (along with most of the other changes) have been added to the C standard to keep
up with the C++ standard. C++11 and C11 are kept in-sync with regards to certain parts of
the syntax.

Enough about _Atomic. Onward to a function specifier (used like you'd use inline)

_Noreturn
Functions declared inline do not necessarily turn up in the binaries of a library.
As h2bi creates header files that are going to be used with binaries
inline functions are of little interest to h2bi..

_Noreturn is a different story. _Noreturn means 'there is
no return statement in this function'. The function therefore will not
return to it's caller. Functions like abort() are functions that do not return.
Like restrict it's more of a hint for the compiler so it knows a function does not return.
A compiler could use this information to optimize a call to a function with a _Noreturn
function specifier.
A function declared using _Noreturn should be declared as void. h2bi would translate such
a function as a sub. Dropping _Noreturn seems like the right way to deal with _Noreturn.

Aside: C11 adds a standard header file for using _Atomic called <stdatomic.h>. Other
header files added to the standard library are <stdalign.h>, <stdnoreturn.h>, <threads.h>
and <uchar.h>. Most of these standard header files contain a macro that expands to a keyword.
For example <stdnoreturn.h> has a macro, noreturn, that expands to _Noreturn.
Same for thread_local in <threads.h> (expands to _Thread_local) and alignas in <stdalign.h>
(expands to _Alignas).
It could be an idea to watch out for inclusion of these standard header files so h2bi
knows that noreturn is actually _Noreturn,

Moving on to some nastiness: a complete new type of specifier called the alignment-specifier.
_Alignas(type-name)
_Alignas(constant-expression)

_Alignas cannot be used in a function declaration. And it can't be used within the context
of a typedef. Which limits it's impact on h2bi somewhat.
An example of _Alignas.

Code: Select all

// every object of type sse_t will be aligned to 16-byte boundary
struct alignas(16) sse_t
{
  float sse_data[4];
};


I am guessing that h2bi will not have to translate _Alignas due to the typedef and
function declaration restriction. I cannot come up with a use for _Alignas that would
affect h2bi (nor can I come up with a proper translation).

What's left in terms of changes to the C standard is an extra unary operator
and changes in unicode string literals.
The unary operator is called
_Alignof(type-name)
I think changes in the C expression syntax have some impact on h2bi as it has to deal with
constant - expressions. An example of constant-expressions h2bi has to deal with are the
constant-expressions found in enumeration members. Operators like <<, >>, +, - etc....
should be translated to their fb equivalent.
_Alignof(type-name) can be used in a constant expression so h2bi might have to translate
_Alignof(type-name) to some fb equivalent. The result of _Alignof(type-name) should be a
number (integer). I don't see how _Alignof and _Alignas can be translated to fb.

Last and least unicode string literals. Unicode support has always come in the form of the
wchar_t type (and a bunch of wchar_t related functions).
You could already use a string prefix (L) to denote that the content of a string literal
should be interpreted as having type wchar_t. C11 adds 3 more string prefixes: u8 u and U.
u8 denotes an UTF8 encoded string (type: char)
u denotes an UTF16 encoded string (type: char16_t)
U denotes an UTF32 encoded string (type: char32_t)
L denotes a wchar_t encoded string (type: wchar_t)

Character constants cannot be prefixed with u8.

In short: C11 still allows you to use L"hello world" but adds the possibility to use
u8"Hello World", u"Hello World" and U"Hello World". And the uchar.h header contains
prototypes for functions to
-- convert from multi byte character to char16_t or char32_t;
-- convert from char16_t to multi bytecharacter/convert from char32_t to multibyte character.

I don't know what to make of these new Unicode related additions. Unicode support in C has always
been lousy. Or to put it in the words of a C programmer:
Well, the support for wide characters in C and C++ has been somewhat erratic and inconsistent.


Which is why you find lots of unicode related code in glib. Relying on the C standard for unicode
support just isn't a good idea.

But string prefixes are part of C11, C programmers can use them (gcc supports use of the new
string prefixes) and h2bi should be able to deal with the new literal prefixes.

I don't think I have been very thorough in dealing with the C11 standard as it impacts h2bi
development. I do think few (if any) changes in the C standard affect h2bi beyond having to
recognize some more keywords that can subsequently be dropped during translation. C11
has only been around for a couple of years now (ever since december 2011) and gcc has only
recently started to implement things like _Generic (see next piece of code).

Which brings me to a new feature that impacts the translation of macros.
It's an addition to the primary expression section of the C syntax definition.
It looks like this (syntax)

generic-selection ::= _Generic(assignment-expression,generic-assoc-list)
generic-assoc-list ::= generic-association
generic-assoc-list ::= generic-assoc-list , generic-association
generic-association ::= type-name : assignment-expression
generic-association ::= default: assignment-expression


An example

Code: Select all

_Generic( 'a', char: 1, int: 2, long: 3, default: 0)


The above code would evaluate to 2 (as character constants are type int in C).
In a macro you could use _Generic like so

Code: Select all

#define type_idx(T) _Generic( (T), char: 1, int: 2, long: 3, default: 0)


type_idx('a') evaluates to 2 and type_idx("a") evaluates to 0.

The above example and more can be found here
http://www.robertgamble.net/2012/01/c11 ... tions.html

Hope this post helps out making h2bi C11 - 'proof'.
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby TJF » Jan 14, 2014 12:53

Wow, thanks for a lot of informations in a long post!

I haven't seen some of these new keywords in any header yet. But it's good to be prepared for the future.

Since most of the constructs have no FB equivalent, h_2_bi must drop them. This can be done by some macro definitions in the configuration file. I've to think about the string literal prefixes u8, u and U, but they also have no FB equivalent and need manual handling -- the compiler finds them during the test phase (syntax error).

I'll have to check your text later in detail. As of now I don't see anything to add in h_2_bi (exept a documentation).

Again, thanks for summarizing this informations.
leodescal
Posts: 165
Joined: Oct 16, 2009 14:44
Location: Jodhpur, Rajputana, Empire of Aryavart
Contact:

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby leodescal » Feb 16, 2014 4:56

Hi, while compiling it under Windows 8 64 bit with FBC 0.90.1 (32 bit), I got following Error:

Code: Select all

C:\Users\Harshvardhan\Desktop\h2bi\src>fbc h_2_bi.bas
h_2_bi warning:
0.90.1 fbc-version in use, code developed and tested with fbc-0.24.0
C:\Users\LinuxRulz\Desktop\h2bi\src\h_2_bi_Main.bas(833) error 41: Variable not declared,
l in 'a = findBlockEnd(In->Tex, l, 0) : IF a < 0 THEN RETURN genKom("#" & In->Tex)'


That's problem in line 833. In line 832 you wrote:

Code: Select all

CASE "include" : SET_CODE(PI) VAR l = LEN(In->Tex) - 1

Probably some error with 0.90.1, it missed that l was declared in above line, rellay don't know why. It don't looks like var keyword specific problem as there are other variables declared with var keyword in your program.

To solve this issue, I declared l as long just as the function H_2_Bi.PreCo() starts. Is it right solution or messed up something pretty badly?
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby TJF » Feb 16, 2014 10:54

Thanks for reporting this problem.

It seems that fbc-0.90.1 doesn't see the variable declaration because it's in the ELSE sector of a single line IF ... THEN ... ELSE statement. I fixed it for next version this way

Code: Select all

  VAR a = 0, l = 0
  SELECT CASE nextWord(In->Tex, a)
  CASE "include" : SET_CODE(PI) l = LEN(In->Tex) - 1
fxm
Posts: 10263
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby fxm » Sep 14, 2014 14:15

TJF wrote:It seems that fbc-0.90.1 doesn't see the variable declaration because it's in the ELSE sector of a single line IF ... THEN ... ELSE statement.

It is the opposite!
Before fbc version 0.90.0 (for example in fbc version 0.24.0), this was a bug which is corrected now.
File changelog.txt (fbc 0.90, § [fixed])
- Single-line IF statements were not opening a scope, exposing potentially uninitialised variables declared within to outside code, e.g. "IF 0 THEN DIM s AS STRING ENDIF: PRINT s"
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

h_2_bi-0.2.6 released

Postby TJF » Sep 30, 2014 17:35

New version, changelog:

  • new: source compatible with fbc-1.00 (32 and 64 bit)
  • bugfix: in --geany mode no more overriding of .h2bi file parameters
  • bugfix: No more segfault when #define line starts with an operaror like '!’ or '~'
  • bugfix: replaced: 'BYVAL ... AS STRING' by 'BYREF ... AS STRING'

Download (as in first post)

AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: h_2_bi.bas, a tool for translating .h files into .bi

Postby AGS » Oct 02, 2014 5:09

I could not find code in the h2bi package that shows how to deal with platform dependent differences (64bit).
On a 64bit version of windows an integer is 32 bits, a long is 32 bits and a long long is 64 bits.
On a 64bit version of linux an integer is 32 bits, a long is 64 bits and a long long is 64 bits as well.

Notice the difference: long is 64 bits on linux and 32 bits on windows. Meaning that translation of
long depends upon the platform used. The table h2bi uses to translate standard C types to standard
fb types does not contain platform dependent definitions.
This means that translation of long might not always turn out the way it should?

I like the header at the German fb site
h_2_bi.bas (SWIG-Alternative, Version 0.2.4)


( Especially the SWIG-Alternative part :) ;) )

And last but not least: how about a Geany-lua port of your tool? Using Geany-lua a program has access to the content
of a document while editing using Geany. You use Geany, other fb users use Geany... what do you think?

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 10 guests