lbpp-devel Mailing List for GNU/Liberty Basic Compiler Collection

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Greetings,
I am looking for a Basic-to-C-translator for Windows.
Anyone know of such?
Thanks...Vernon

- www.vmars316.com 
"All things in moderation, except for love and forgiveness."

All,

I have just checked in a whole bunch of new code to the
GLBCC CVS repository.  I completed the final rewrite (this would be the
third) and finally have the architecture that is desirable for the next
release of GLBCC.

This next release is going to have the following features:

1) Full grammatical support for LB2.02 (with the exception of some
rather vexing grammatical oddities that are being removed from the
language)
2) Support for code importation via CALLDLL or DECLARE (I've had a
slight change-of-heart with CALLDLL...)
3) User defined functions and sub routines that are C-exportable
(translation: create DLLs in LB)
4) RPM driven Linux release and Ghost Installer driven Windows release
5) Support for all console based statements and functions
6) Support for basic GUI functionality (all GUI controls, window* types,
and maybe text type)
7) Support for stream based I/O

What will be added in the 0.2.x series prior to a 0.3.0 release:
1) Full GUI functionality
2) Wizard-style front end for creating executables or DLLs
3) Random access file I/O
4) Full LB2.02 compatibility with the exception of direct hardware
access and again some of the rather odd grammatical aspects of LB.
5) Native socket support
6) Lots of supporting functions
7) Syntax checking to the point where there is no way GLBCC will
generate bad code.

The 0.2.0 release should be coming within the next week or two.  I
imagine that there might be a 'developer' release prior to the official
release because I want to spend a good amount of time making all the
various installations work correctly.

Regards,
Anthony Liguori
Author - GLBCC (GNU/Liberty Basic Compiler Collection)
http://lbpp.sourceforge.net

Greetings,

I've been struggling hard lately with GLBCC.  I unfortunately don't have
much to show for it because most of it has been based around design
oriented issues.

BASIC is a nasty language to parse.  The roots of the language aren't
necessarily that bad but the modern versions of it are just about as bad
as it gets.  Traditional tools just can not handle the inconsistency
with the grammar.

As many know, I am in the process of a total rewrite.  I have migrated
from a one pass translation to a two pass translation.  This is all well
and good and is coming along fine except for one thing.  In order to
write the grammar using traditional tools (namely, lex/yacc), I was
forced to make the grammar _very_ ambiguous.  Namely, the following
expression:

(30 + 40) = 1

Will pass the grammar checking.  Obviously, this is not a valid
statement.  So, the issue of syntax checking has become a big issue.
I've been torn was again by how much and how thorough syntax checking
should be in GLBCC.  Many have argued that is essential to the project
while others feel it has no place.

I personally am torn because on the one hand, proper syntax checking in
any kind of maintainable fashion is going to require a bit of work.  The
idea would be to create some sort of language to define what is valid in
the syntax tree and what isn't.

This is definitely out of the scope of this project though and to be
quite frank, while I find it definitely tempting to pursue this course,
if/when this course is pursued, I want to do it correctly.

The long and the short of it is, thorough syntax checking is _not_ going
to be a part of this project for the time being.  The only guarantee
that will be made is that GLBCC will not hang.  I will intend on passing
off a lot of the syntax checking on the C compiler though.  It is just
not worth the additional effort.

The goals of this project are to create a compiler to compile LB code.
Not to write a replacement for LB.  There is a problem though since this
project is also geared towards Linux.  To make a usable BASIC compiler
on Linux, syntax checking is a must.  There is a time and a place for
everything though and results often are more important than anything
else.  I would rather have a complete language available on Linux than a
complete development system.

I'll leave that one up to Carl.  So, I just wanted to let everyone know
where things stand.  This decision should mean a release in the
relatively near future.

Regards,
Anthony

GLBCC 0.1.1 is now available at the GLBCC download page:

http://lbpp.sourceforge.net/downloads.html

This release fixes all known installation problems and provides one step
compilation on both Windows and Linux including Linux to Windows cross
compilation.

An patch has also been made available to upgrade from the 0.1.0 version
of GLBCC on Windows to 0.1.1 version without requiring another 5MB
download.

Should I upgrade to GLBCC 0.1.1?

No new functionality has been added to 0.1.1.  This version is merely a
source corrector.  If you have had problems getting GLBCC to work, then
you should either patch the previous version (if you have an unmodified
fully intact version) or download the new version.  If you are running
the Linux version, and have already downloaded the cross compiler
environment, you do not need to download it again.  To upgrade the Linux
version, just download the native Linux package.

Regards,
Anthony Liguori
Author of GLBCC (GNU/Liberty Basic Compiler Collection)
http://lbpp.sourceforge.net

Well, I sort of found out by accident today that GLBCC was added to the
SourceForge Gnome Foundry.  Besides getting another cool graphic on the
project page, it should give GLBCC a great deal of exposure.

The Gnome Foundry has some pretty big time members including Gaim,
AbiWord, and Galeon - just to name a few.

I don't know how GLBCC is getting as much exposure as it is, but it sure
is attracting some attention ;-)

Regards,
Anthony

I have started a Yahoo! group for users of GLBCC.

This group is meant to facilate answering common questions related to
GLBCC and to give an area for users to share their experiences and code
from GLBCC.

A large motivation for my doing this is the fact that SourceForge is
down today so I want to have a backup just in case.

The groups page is located at:

http://groups.yahoo.com/group/glbcc-users

Regards,
Anthony

Greetings,

It's been a while since I've posted status to this list.  I just simply
have been lazy though ;-)

Lots of stuff has happened.  We are starting to get some solid interest
in GLBCC and are getting much closer to working out the Windows issues.

I have successfully built a few versions of GCC (including a Win32 cross
compiler).  I also have set up the latest Cygwin environment on a
Windows machine.  I intend to try my luck at building a native Mingw
version of GCC to better support Windows.

The Win32 cross compiler that I built was under 2MB on Linux which would
make the full cross-compiler distro for Linux knocked down to 2MB!
That's a big improvement over the 6MB it was previously.

I imagine the Win32 package should drop down to a similar size also.
Again, this is a huge savings.

In some unrelated news, GLBCC was added as a Featured Project of the
SourceForge BASIC Foundry.  I was contacted by Dejan Lekic directly to
be informed of this and was also pleased to hear that he rated GLBCC as
a 6 - the highest value possible.  I'm excited about the opportunity to
exchange ideas and code with the other members of the BASIC Foundry.

You can learn more about the SourceForge BASIC Foundry here:

http://SourceForge.net/Foundry/BASIC

I don't think I made an announcement on this list, but I recently a
grammar to describe the Liberty Basic language.  This grammar is a
_huge_ improvement from the previous method in which LBPP parsed Liberty
Basic code.

I am trying to take this grammar and integrate it directly with GCC.
I may release a C translator in the interim though as a teaser and as a
means to start work on the new libLB which will be written in a
combination of C and Liberty Basic.  Liberty Basic can be used mainly
because of the support for FUNCTION and SUB statements in the new
grammar.  I may also add a DECLARE statement so that API calls can be
used.

I also previously released a LB to XML translator that is available from
CVS.  If you search the web page a bit, all the latest goodies can be
found :)

I'd like to see more traffic on this list - and I am actually to blame
for lack of it recently - so I am going to make an effort to post things
as they happen here.

The web page also is started to be in need of some serious help.  I've
had some people express interest in working on the web site so
hopefully, that should be happening relatively soon.

Regards,
Anthony Liguori
Author - GLBCC (GNU/Liberty Basic Compiler Collection)
http://lbpp.sourceforge.net

A new Windows version of GLBCC is now available that should fix the
install problems of the former version.  There is also a patch if you
have previously downloaded GLBCC and do not wish to have to download
another 5MB file ;-)

I want to make sure this version actually works before I make
announcements, so I would appriecate if people downloaded the
patch/release and tested it and posted some feedback.

Thanks,
Anthony

Greetings,

GLBCC-0.1.0 is now available.  The LBPP website has been updated and
GLBCC can be downloaded via the download page.

As always, the website is at:

http://lbpp.sourceforge.net

The download page can be gotten to directly at:

http://lbpp.sourceforge.net/downloads.html

I worked very hard to reduce the download size.  Here is what it came
to:

GLBCC for Win32
5MB

GLBCC for Linux with Win32 cross compile support
6MB

GLBCC for Linux with no cross compile support
60K

I'm gonna make a release on Freshmeat, make announcement on lbexp, and
then take a break until after Christmas (I have so much wrapping to
do...).  So, happy holidays everyone.

Regards,
Anthony Liguori

The source code for the GLBCC 0.1.0 release is currently in CVS.  I am
uploading the GLBCC-core package as I write this so as soon as it's
done, I will make the release official.

To start out with, you ca access CVS anonymously by doing the following:

  cvs -d:pserver:ano...@cv...:/cvsroot/lbpp login
  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/lbpp co
glbcc

If you want to have write access to CVS, please email me and I will give
you access (you only need write access if you are contributing large
quanities of source code).

For non-unix users, there are Windows versions of CVS clients available
all over the place.  I have used one called WinCVS that seems to work
well enough.  Just search tucows or something and I'm sure you'll find
dozens.

So, this is what is covered in this release:

1) The introduction of GLBCC, a front end that allows a user to easily
compile a .bas file in both command line and GUI mode.
2) The first release of the full compiler suite
3) Windows support
4) Linux -> Windows cross compiling support

While LBPP still exists, it is now only part of a full compiler suite
which will be referred to as GLBCC.

The new web page is going to go online officially tonight too.

Happy Holidays,
Anthony Liguori

All,

I have something that I'd love to get an opinion on - and a chance for
people to chime in ;-)

I assume everyone is familiar with the DECLARE statement but if not,
here's a basic synopsis:

The DECLARE statement tells the compiler how to interpret a statement or
function call.  Currently, it can take a either a type or literal as
it's arguments and then generates a function called based name mangling
algorithm.

So, the DECLARE statement for the BUTTON command is as follows:

DECLARE STATEMENT BUTTON &handle "," string "," label "," keyword ","
double "," double

' Valid BUTTON call
button #window, "Click Me", [test], UL, 10, 10

There is also one for the specification of width and height, but we'll
ignore that for now.  The & prefix causes a variable to be passed by
reference.  The caller of the statement does not have to do anything
special.

This will get translated to the following C prototype:

void LB_BUTTON_11(LBContext *cxt, Variable *var, LBString str,
Label *label, char *keyword, double x, double y);

FYI:  LBContext contains all the information that lets one be able to
lookup variables by string name and labels by string name.  It also
allows for C functions to access LB variable such as WindowWidth,
WindowHeight, etc.

What I want to be able to do though, is having a USING clause.  This
would allow for a custom name atleast and optionally, reformatting of
parameters.  This way, instead of having to have the ugly name
"LB_BUTTON_11", it could be renamed to something more useful like
"LB_BUTTON_X_Y"

I also want to be able to use this to inline functions.  Take the
LB ABS function.  There already exists a C abs function.  But because we
mange the names and pass a context, a wrapper has to be written.  It
would be nice if the following could be used:

DECLARE FUNCTION ABS double USING "abs" (double)%1

The reason this doesn't work yet, is because I haven't been able to
determine the best syntax for the using clause.  I like the ability to
specify argument order via the %n thing.  %0 would also mean the
LB context so that one could either pass the context or just ignore it.
The cast is very C like but the idea is to support a the C primative
types.  The following types would be supported and should work for
everything that would ever be needed:

 LB TypeC Type
 uchar  unsigned char
 char   char
 ushort unsigned short
 short  short
 uint   unsigned int
 int    int
 ulong  unsigned long
 long   long
 single float
 double double
 void * void *

A & modifier would also be used to specify a reference so that to pass a
reference to a string, one would use (void * &)%n.  The idea too would
be to allow any number of nestings so that a reference to a reference
could also be used such as (int &&)%n.  This is just to be _that_
flexible.

I also am thinking of allowing a {} to be used too to denote straight C
code to be used.  This way, the following could be done:

DECLARE FUNCTION MessageBox string string USING "MessageBoxA" {NULL}
(void *)%1 (void *)%2 {MB_ICONINFORMATION | MB_OK}

It's a mouthful I admit but it would dramatically reduce code size and
also would make adding certain statements a heck of alot easier.

So, is this too much or does it work in a basic language?  I am
seriously considering using ptr to represent (void *) in LB since that
probably makes more sense.  What is everyone's thoughts on the pass by
reference syntax?  Should we use integer instead of int too?

Is the inline C stuff ({}) too much?  Remember, 99% of the
DECLARE statements will occur in the autoinc.bas file which most users
will never see so this statement should be considered an intermediate
statement if that helps any.  This statements needs to be good enough
though to replace CALLDLL's which I know people love alot.  It only
needs to occur once though so I definitely think it has a ton of
advantages to the CALLDLL statement.  My only concern is that I am such
of a C/C++ programmer that I might be introducing something that's a tad
to complex for a BASIC language.

Thanks for your input,
Anthony Liguori

So, I know I said I'd release a version of GLBCC last night but
unfortunately, I got side tracked doing a website which is currently
available for critic at:

http://lbpp.sf.net/beta

So where does GLBCC stand.  It's done believe it or not.  Here is a
listing of the current directory structure:

[anthony@localhost glbcc-0.1.0]$ ll
total 16
drwxrwxr-x    2 anthony  anthony      4096 Dec 19 23:28 glbcc-0.0.1
drwxrwxr-x    7 anthony  anthony      4096 Dec 19 23:26 glbcc-core-0.0.1

drwxrwxr-x    4 anthony  anthony      4096 Dec 19 23:41 lbpp-0.0.7
drwxrwxr-x    5 anthony  anthony      4096 Dec 19 23:53 libLB-0.0.7

glbcc is the front end.  It is written in LB believe it or not (see
attachment).
glbcc-core is the Mingw development environment for that allows Linux
developers to develop on Windows and for Windows developers to develop
natively on Windows.
lbpp is the the Liberty Basic pre-processor
libLB is the runtime library

So far, the install procedure works for Linux.  I don't have a cross
compile procedure yet though.  I do not have a Windows install program
yet either.  I plan to write one up real quick in LB but unfortunately,
I will not be able to access a Windows box until tomorrow so that will
have to wait.

The whole distribution is like 50MB uncompressed so I'm gonna have a
bitch of a time uploading it since I'm on a 56K.  Four types of
downloads will be available:

Source for everything (this will probably be pretty big ~10MB)
Source for Linux only (this will be small ~100K)
Source for Linux + Windows cross-compiler (this will be decent ~5MB?)
Windows binaries + source (this will probably be big ~10MB)

I am not sure if I am going to bother having a compile procedure for
Windows natively since I can always cross compile to Windows to provide
Windows patchs.  Then I don't have to include make and binutils which
will significantly cut down the package size.

So, this week is lots of docs and configuration stuff.  Once this is
settled though, it should be smooth sailing.

Regards,
Anthony

Bah, who needs sleep :)  I made a quick version of what I think the
website layout should look like.  There are some broken links due to
lack of pages but they will all be there in time.  All of the top level
links though.

The plan is to keep most of the development resources based around the
SourceForge project page and to just use the website as a way for people
to download the program.

So, if you have suggestions, please post them to the list.

If anyone knows of any links that pertain to this project, please post
them too with short descriptions.  I want to avoid linking to sites that
are unrelated to this project since that only leads to clutter and there
are already a ton of listings of LB related sites :)

Thanks,
Anthony

Well, today I announced GLBCC.  I've kind of hinted at it before but
I guess I should explain in a little more detail here.

GLBCC stands for GNU/Liberty Basic Compiler Collection.  LBPP is a part
of this suite.  The rest of the suite is composed of the Mingw port of
GCC, some binutils, the Mingw runtime environment, and the GLBCC front
end program.

The GLBCC program will act as the interface for the entire system.  It
will take a .bas file name as input and run the rest of the programs in
order to generate an executable application.  The Mingw library is
actually public domain so there is no licensing issues at all anymore.

I am planning right now for GLBCC to be written in LB.  LBPP is
currently just about strong enough to support this.  In fact, all that
needs to be done is for the CommandLine$ system variable to be populated
at context initialization, and for the RUN statement to be written (I am
planning on just making a system() call and ignoring the keyword).

This is basic outline of the LB program:

1) Examine Platform$ variable to determine if we are running Linux or
Windows
2) Initial the proper pathnames to the various applications for each
operating system
3) Examine the CommandLine$ variable to determine what files to read in
and write to
4) If we are on Linux, then check for a target option too to see if we
are targeting Windows
5) If the CommandLine$ was blank, pop up a file dialog to get a file
name

6) Run LBPP on the bas file to generate a C file
7) Run GCC to generate an object file from the C file
8) Determine what libraries and link the object file to generate an
executable
9) Clean up the C and object file

Throughout steps 6-9, diagnostic advice will pop up depending on when/if
the compile fails at any point.  This is more a future task than
anything else.

The whole system will be distribute in two ways.  There will be a
package that contains all the required tools and libraries for both
Linux and Windows so that the environment will automagically be
configured.  There will also be a seperate GCC + Mingw package and a
standalone LBPP package.  This way, updates can be made to LBPP without
the need to redistribute the entire package.

This should bring the compiler to the entire community.  Right now, my
focus is on providing this package and doing a serious update on the
website to provides tons of info for users since there seems to be quite
a bit of confusion about this project.

If this was a C compiler, I would probably ignore the confusion and just
code, but the a BASIC compiler suite needs to be user-friendly enough so
that it can actually be used by BASIC programmers.

So, if anyone wants to help right now, these are the areas I'm focusing
on.  There is also a great need for future Windows C
programmers/testers.  I can easily compile Windows code but running it
is actually quite a difficult process since I don't have ready access to
a Windows machine.  What would be great is there were people would were
able to test the Windows version of this.

So that's that and I'm terribly tired so I'm gonna hit the hay.  It's
been a long day and I have to get up for work tomorrow.  I am very happy
about the way this project is going and also very happy about the
response it's getting.  I have a feeling that GLBCC is going to be a big
deal once everything comes together.

BTW: I choose to use GNU/Liberty Basic Compiler Collection since a good
deal of the compiler suite comes from GNU.  I divided it with a / to
seperate the two projects as to not infer that this is an offical
GNU project.  I don't think I want to turn the copyright over to GNU so
I don't have any plans of trying to get GNU to accept this as an
official GNU project.  Besides, GNU already has a basic language -
GnomeBasic.  RMS always gets pissed though when Linux is not referred to
as GNU/Linux since it uses so much GNU stuff.  Of course, when doesn't
RMS get pissed :)

Regards,
Anthony

LBPP has been ported to Windows natively.

LBPP is no longer dependent on Cygwin to run.  It produces amazingly
small executables that are totally independent.  I am going to build a
package tonight that will contain a cross-platform LBPP driven gui that
will allow everyone to build executables on Windows.

I am focusing on Win32 porting right now because I think it will help
bring in a larger development and more importantly, testing base.

The real amazing part is that I compiled the windows executables on
Linux via the mingw port of GCC.

The package I'm going to try and release tonight will allow Windows
developers to compile LB programs for Windows, and Linux programs to
compiled LB programs targetted to either Windows or Linux.

I am posting a message onto the LBexp message board along with three
compiled examples.

Did I mention that I added support for FILEDIALOG, CONFIRM,
and NOTICE on Windows ;-)

Regards,
Anthony

This problem was fixed by Michael and will be in the next release :)

Regards,
Anthony

>
> If I start to become a nuisance (if I haven't already), please let me
> know.

By nuisance, you mean big help right :)

Michael Rankin wrote:

> When I print LOF it shows the byte size as 0.
>
> Open "fialdialog.bas" for input as #test
> Print LOF(#test)
> Close #test
> End

Alas, LOF does not work yet ;-)  This is due to the fact that I have to
see if Windows supports fstat (which I think it doesn't).  The
architecture is there atleast.  basic_io.c has a function called
something like lb_file_lof that actually takes a FILE *f so it would be
ridiculusly easy to support it.

I'm just trying to keep from having to have seperate versions of
basic_io.c for different platforms ;-)

> I don't believe INPUT$ is working either
>
> Open "fialdialog.bas" for input as #test
>
> For x = 1 to 10
>    Print INPUT$(#test, 1);
> Next x
>
> Close #test
> End
>
> It should print out the first 10 characters, but it prints nothing.
> If I remove the ";" it will print 10 blank lines.

Yeah, this function was just stubbed out :(  I actually support it prior
to the device architecture implementation and then never went back and
fixed it :(  It's fixed now though and will be in the next release.

Removing the ; will print newlines because the absence of a ; will send
a new line to the file.  This should be similiar to how LB works.

Regards,
Anthony

MID$ starts at 0 instead of 1.

Print MID$("Test",1,1)
The above prints out an "e" instead of "T".
In Liberty Basic the bove line prints out a "T"

Print MID$("Test",0,1)
The above will print out an "T".

If I start to become a nuisance (if I haven't already), please let me
know.

When I print LOF it shows the byte size as 0.

Open "fialdialog.bas" for input as #test
Print LOF(#test)
Close #test
End
---------------------------------------------

I don't believe INPUT$ is working either

Open "fialdialog.bas" for input as #test

For x = 1 to 10
   Print INPUT$(#test, 1);
Next x

Close #test
End

It should print out the first 10 characters, but it prints nothing.
If I remove the ";" it will print 10 blank lines.

Two big announcements for this evening:

The program that John Jacques just published (Prepcode) runs absolutely
perfectly on Linux with no modifications at all!  This is the first
program I tried to compile since the last release and it worked with no
modifications at all.  If you download the source, stick it in the
examples directory, and just add prepcode to the PROGS line in the
Makefile, it works beautifully.

Second, and hugest of all, announcement is that tonight I successful
compiled LBPP and an example program on Windows!  I had to remove the
GUI stuff obviously but that was just a matter of removing the libGUI
dependency and then removing some #includes that shouldn't of been there
in the first place.  I compiled it using cygwin just about accidently.
The archive of it is on SourceForge (precompiled and source).

I am going to make an announcement on LBNews so check that out for more
details.

This begins the Windows port of LBPP :)

Regards,
Anthony

The official 0.0.6b release has been submitted to SourceForge.  The
ChangeLog is huge for this version due to the huge amount of new
features added.  GUI support is now a reality.  As always, the latest
version can be downloaded from the SourceForge project page.

http://sourceforge.net/projects/lbpp

Regards,
Anthony Liguori

There is a new release on SourceForge.  The new features are not
complete so it is a hidden release and is marked as development.

There are so many new features.  GUI support is there now.  So far, the
open command works with type window, text, and text_nsb.  Some commands
work for the windows including one's that register labels such as
trapclose.  The button command is also now supported which is really
cool :)

The nest release may get bumped up a couple versions because I'm going
to try to support all the widgets expect for groupbox plus also try to
atleast support the graphics type even though some of the commands may
not work yet.

Right now, polling does not work because I haven't put that architecture
in yet.  That will be done for the next release though.  We're getting
very close to fully supporting LB1.4 syntax!  I can't believe it's going
this fast.

Regards,
Anthony

This is the first message for this list.

I made this list for a few reasons:

1) To make discussion of new features and bugs available publicly
2) To encourage greater participation
3) To bounce ideas around for overall better design
4) To answer questions to regarding this list

Thanks,
Anthony Liguori

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (16)
2002	Jan (5)	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2012	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

lbpp-devel Mailing List for GNU/Liberty Basic Compiler Collection

lbpp-devel — LBPP Development Mailing List