AGS wrote:I checked out the new lookup function (keyword lookup). Interesting solution. I benchmarked it a bit and it basically performs at a speed comparable to that of a binary search. And no slowdown when feeding it words that are not keywords. Nice.
The code is inspired from FB2HTML.bas
. He has a lot of high quality code at the portal.
I used FBeauty
to test it. I also tested the Geany mode in this little tool.
The code performs a little slower on words starting with characters like 'c' or 's' (due to a large number of FB keywords starting with this characters) and is fast at words starting with charaters like 'k', 'x' or 'y'. After all, it is a fast solution that can be easy maintained further on.
AGS wrote:... And finally: would you mind if I would do a spell check on the h2bi README file (and the comments inside the different parts of h2bi)? I'll post a link to my spell checking results (if any) in this thread.
Any help on improving h_2_bi is wellcome. I concentrate on the source code, so that the compiler understands me. If you can improve the comments and the docu to help new users understanding the tool, it will be a good improvement. You may post the results here or send it as a private mail, so that I can implement it in the next version. Let me know if (and how) I can support you.
AGS wrote:I have decided to drop my iup gui as I am not willing to write one gui for windows and another one for linux. I tried to translate what I had to gtk+ but in the end I decided a bit of glade will get me better results faster.
I'm going to be using GTK+ only (glade) from now on. Great stuff, iup, but writing a nice GUI is difficult enough as it is without having to worry whether or not it will work on Linux.
This meets my experience too: concentrate on one problem to solve.
You'll have to make a decision first: LibGlade or GtkBuilder. LibGlade is easy to code, but needs one more .DLL to install on windows. I switched to GtkBuilder which is more universal, but needs a little more code in FB. The main advantage: all the windows runtime libs can get installed by one prebuild package.
AGS wrote:For a single C header file buffering gets you some (factor 2?) or no speed up. ...
I think your speed test results are typical for windows. On Linux the difference isn't that much.
In h_2_bi version 0.1.9.2 the input is byte-by-byte and in version 0.2 the complete C header file(s) is(/are) buffered. Regarding speed up I get a factor of ~3 for translating GTK-2.22.0 headers (vers. 0.1.9.2: 85 sec, vers. 0.2: 30 sec).
Most of the speed up is due to the parser optimization (OOP, less variables, less function calls, ...). The file buffering is on second place in the speed up ranking. (The speed up is less than factor 1.5.)
AGS wrote:I'm trying to write some sort of c2fb. I'm not writing it in FB yet as I'm using two tools (GPP and dparser) to get C parsing going. And both of these tools have been written in C.
This would be nice to have. Don't mind to code in C. When realized, the tool can translate itself to FB ;-)
AGS wrote:And now I'm wondering if you, me or you and me could put something on paper regarding the translation of C to FB. I know you must have some ideas as to what the problems are when translating C to FreeBASIC. You implemented translation of casting/operators/other things and I think it would be good to have the kind of knowledge needed to do those kind of things on paper.
I'm not sure if I can help here. Before I started h_2_bi, I had no clue of C coding. I learned by trial and error. Up to now, I understand a bit of the header source.
To give advices on translating C source files, I'll have to learn new structures like 'while
' or 'if
' blocks (ins't impossible). But the main problem I see at translating the little expressions like '++i
' or 'a == b == c
'. There are no direct expressions in FB and the code has to get translated into more than one FB code line. This needs clever solution.