New FB release coming up

For other topics related to the FreeBASIC project or its community.
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: New FB release coming up

Postby AGS » May 20, 2013 22:02

ike wrote:Here is code in IUP that is doing folding in FREEBASIC
http://iup.cvs.sourceforge.net/viewvc/iup/iup/srcscintilla/lexers/LexBasic.cxx?view=markup

This module is for PureBasic, BlitzBasic and FreeBasic

line 126 is freebasic

IUP developer is nice guy, so if we find what is wrong he will fix it for sure!

That is for folding, and coloring,

but for code completion is different. That part should be done in FREEBASIC and it is not difficult because it is not full parsing BUT some kind of LINE SCANING


I looked at the folding a bit and folding is set to fold on indentation regardless of the text typed.
As an example I used the following text in the demo I posted in the tips&tricks section

Code: Select all

this is not freebasic
  it is just text
    and some more indentation
  but if folds
end the outer block of non-freebasic


I get a folding sign at 'this is not freebasic' and at 'it is just text'. This works for any type of text entered.
Which is kind of interesting as it encourages a programmer to use lots of indentation (makes code look prettier).

As to the IUP developer and fixing things: I don't think he will fix problems with scintilla. He
is using scintilla 'as is' (of course there is some iup wrapper code so scintilla can be accessed
from IUP). Having to update the scintilla code at every new release of iup is something the iup developer will not do.
No doubt the iup developer will update the scintilla version used by iup as new releases of scintilla become
available. But you can't expect him to apply changes to every new release of scintilla just to correct
freebasic lexing.

I am unsure as to what should be changed and where. Syntax colouring and folding are one thing but I'd say
code completion etc... are even more important.

And for code completion etc... you need a symbol table. Generating that symbol table is not that easy.
FreeBASIC and C share a problem that makes symbol table generation a bit involved: the possible use
of macros. An identifier can be any of a number of things: the name of a macro, the name of a type or the
name of a variable (or a keyword or....).

After macro expansion it is possible to get symbolic information (needed for code completion etc...)
but not before. Anything less than a fairly full blown FreeBASIC parser simply will not do when it comes to
symbol table generation.

Which is where the fbc comes into play. When it comes to extracting symbolic information from source code
the fbc is or should be a very usable tool. It is better to reuse an existing parser than to try and write your own
from scratch.
petan
Posts: 683
Joined: Feb 16, 2010 15:34
Location: Europe
Contact:

bug in FB 0.24 +?

Postby petan » May 24, 2013 0:23

Just compiling "lesson18.bas" from FB/examples/graphics/OpenGL/NeHe (in fb 0.24)
on line 56 got error 'Duplicated definition...'

Code: Select all

dim object as uinteger                         '' Which Object To Draw (NEW)

,as founded on wiki this is new reserved word in FB.Seems some examples are not corrected by this word.
What is situation in new FB release ?
Pete
petan
Posts: 683
Joined: Feb 16, 2010 15:34
Location: Europe
Contact:

Situation in new FB release 0.9 ?

Postby petan » May 24, 2013 12:20

Checked all examples for OpenGL NeHe (FB/examples/graphics/OpenGL/NeHe) in FB 024 package.
Bugs 'object - reserved FB keyword' are in files :
- "lesson18.bas" from line 56

Code: Select all

dim object as uinteger                         '' Which Object To Draw (NEW)

- "lesson21.bas" from line 29

Code: Select all

type OBJECT           '' Create A Structure For Our Player

- "lesson23.bas" from line 53

Code: Select all

dim object as uinteger = 1                             '' Which Object To Draw

- "lesson25.bas" from line 44

Code: Select all

type OBJECT                                '' Structure Called OBJECT For An Object

When renamed all wrong object to object7 ( in commands), examples works normally.

Pete
counting_pine
Site Admin
Posts: 6169
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: New FB release coming up

Postby counting_pine » May 24, 2013 20:22

Thanks for the NeHe object report. I've committed fixes here:
http://sf.net/p/fbc/code/ci/ace892a
Jonge
Posts: 129
Joined: Jul 17, 2012 17:51
Location: Norway
Contact:

Re: New FB release coming up

Postby Jonge » Jun 03, 2013 16:00

Have GoRC.exe been updated in the next release? I downloaded v0.90.5 today(from godevtool.com/) and it fixed some Icon trouble I had with FireFly(Win32 visual designer)
fxm
Posts: 9013
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release coming up

Postby fxm » Jun 03, 2013 16:36

dkl wrote:Hello everyone,

we're now closing in on the new FB release. It's 1 month overdue as far as I'm concerned, but in exchange it will contain lots of prebuilt external libraries. And besides that, it contains new features that caused the version 0.9 to be mentioned -- so now, I have started calling it FB 0.90 instead of FB 0.25. May 1.0 follow eventually.

I have prepared some preview packages for testing, and I'd appreciate if some of you could check them out and see whether they can actually compile stuff:

http://sourceforge.net/projects/fbc/files/Preview%20Builds/

In the preview packages (http://sourceforge.net/projects/fbc/files/Preview%20Builds/), it is already:
GoRC.Exe Version 0.90.5 - Copyright Jeremy Gordon 1998/2009 - JG@JGnet.co.uk
Jonge
Posts: 129
Joined: Jul 17, 2012 17:51
Location: Norway
Contact:

Re: New FB release coming up

Postby Jonge » Jun 03, 2013 16:40

Ok, didn't know about the preview packages. Thanks
dkl
Site Admin
Posts: 3207
Joined: Jul 28, 2005 14:45
Location: Germany

Re: New FB release coming up

Postby dkl » Jun 13, 2013 14:18

Hello,

0.90.0rc2 packages are available now for testing at the same location:

http://sourceforge.net/projects/fbc/files/Preview%20Builds/

The external libraries are now separate packages again, and I think this way could work quite well.
fxm
Posts: 9013
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release coming up

Postby fxm » Jun 13, 2013 16:40

Why the file 'gcc.exe' + the directory 'libexec' (together required for the option '-gen gcc') are no more included in the win32.zip as this was for the 0.90.0rc1 package?
dkl
Site Admin
Posts: 3207
Joined: Jul 28, 2005 14:45
Location: Germany

Re: New FB release coming up

Postby dkl » Jun 13, 2013 17:07

I have put them into separate "add-on" packages to reduce download size of the main package for users that don't use -gen gcc.
VANYA
Posts: 1311
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: New FB release coming up

Postby VANYA » Jun 14, 2013 2:42

Hi dkl!

I look forward to the final version will have at least one packet, which will include all the libraries? Or at least one archive library. And then download individually - not the most convenient option ...
pestery
Posts: 493
Joined: Jun 16, 2007 2:00
Location: Australia

Re: New FB release coming up

Postby pestery » Jun 14, 2013 10:25

Just an observation and a couple of questions.There are quite a lot of library files (the .a files) that are no longer included in the main FB download. I quickly found them off in the 'Library' folder but I was wondering if they are going to be separate from now on? Also, by having the libraries as separate downloads would that allow the .dll files to be included in the bundle for each library, I mean from a licensing point of view?

Another observation and question. In the GCC zip file there is a folder called i686-w64-mingw32. Does this mean FB is a step closer to being able to compile 64bit programs on Windows?

Final question. I've ask this before in another thread but I was wondering if there is any news. When porting a library from C, what is the new replacement for C's long datatype?

Code: Select all

char      -> Byte
short     -> Short
int       -> Long
long      -> ???
long long -> LongInt
bool      -> Long?
float     -> Single
double    -> Double

Also, I just noticed that VANYA asked a similar question about the libraries. Perhaps we could have them separate, but also have an all-in-one download option. Just a thought.
fxm
Posts: 9013
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release coming up

Postby fxm » Jun 14, 2013 13:12

fxm wrote:Why the file 'gcc.exe' + the directory 'libexec' (together required for the option '-gen gcc') are no more included in the win32.zip as this was for the 0.90.0rc1 package?
dkl wrote:I have put them into separate "add-on" packages to reduce download size of the main package for users that don't use -gen gcc.

Yes, but 4 DLLs are missing in '4.7.3' of 'FB-win32-gcc-4.7.3.zip' (that I use) :
libgmp-10.dll
libmpc-3.dll
libmpfr-4.dll
zlib1.dll
(the previous 0.90.0rc1 package rightly contained these DLLs)
dkl
Site Admin
Posts: 3207
Joined: Jul 28, 2005 14:45
Location: Germany

Re: New FB release coming up

Postby dkl » Jun 14, 2013 16:56

Well, I think having the external software in separate package is best, because the all-in-one package was too big and incomplete anyways. Currently I don't have a compiled version of every single library that FB includes headers for. Also, this way it's possible to add more or updated libraries later without repackaging the whole FB release.

I can package the external library DLLs that I have for FB-win32, should be no problem. Just keep in mind that for some libraries (e.g. PDCurses), the static lib isn't compatible to the DLL and it's necessary to use a #define when compiling the FB code to allow the FB header to select the right interface (in case of PDCurses it's the PDC_DLL_BUILD #define that enables Extern Import instead of just Extern). And of course in some cases like BASS, we cannot redistribute their DLL because of the license (the current FB-win32-bass package only contains the import library we made).

The packaged gcc uses the i686-w64-mingw32 triplet because I'm used the 32bit compiler from the MinGW-w64 project to build the FB-win32 binaries. That allowed me to cross-compile from Linux too, because I have a i686-w64-mingw32 cross-compiler on Xubuntu, which greatly helped the process of building the win32 binutils/gcc. It would have taken ages to do natively in a Windows XP VM. Other than that I wanted to give the MinGW-w64 toolchains a try, since I had started porting FB to 64bit before worrying about this release, and I want to continue with this now. Thus it's good to gather some experience with MinGW-w64 which I'll probably be using more in the future, at least as long as MinGW.org doesn't have a 64bit port.

I haven't made progress on the issue with C's long since this post. I don't know how big of a problem it is anyways... surely any library that wants to work on 64bit Linux aswell as Windows will avoid using long and use long long instead.

I have rebuilt the win32 gccs using static linking, so the cc1.exes don't depend on the gmp/mpc/mpfr/zlib DLLs anymore. It seems to work fine here. Did you get errors because of this?
fxm
Posts: 9013
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release coming up

Postby fxm » Jun 14, 2013 17:55

dkl wrote:I have rebuilt the win32 gccs using static linking, so the cc1.exes don't depend on the gmp/mpc/mpfr/zlib DLLs anymore. It seems to work fine here. Did you get errors because of this?

Yes you are right, this is working (I had not tested it with the new 'cc1.exe'!).

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 4 guests