FreeBASIC 1.09.0 Release

[Xusinboy Bekchanov]

@coderjeff, is it possible to make Left, Right, Point, Rect the main, and the rest are secondary as before?

I don't know. Can you make a *small* example that shows what you want to change?

Could it be related to https://sourceforge.net/p/fbc/bugs/948/ ?

Might be related to this?

viewtopic.php?f=17&t=29792

Yes. I wanted to create a simple example, but it worked:

Code: Select all

Type Rect
	Left As Integer
	Top As Integer
	Right As Integer
	Bottom As Integer
End Type

Type Point
	X As Integer
	Y As Integer
End Type

Namespace gdiplus
	Type Rect
		X As Integer
		Y As Integer
		Width As Integer
		Height As Integer
	End Type
	
	Type Point
		X As Integer
		Y As Integer
	End Type
End Namespace

Using gdiplus

Dim r As Rect
r.Left = 10 ' Works

Also this:

Code: Select all

Enum Keys
	Left
	Right
End Enum

Type Component
	Private:
		FLeft As Integer
	Public:
		Declare Property Left As Integer
		Declare Property Left(Value As Integer)
End Type

Property Component.Left As Integer
	Return FLeft
End Property

Property Component.Left(Value As Integer)
	FLeft = Value
End Property

Type Control Extends Component
	Declare Sub ClickEvent
End Type

Sub Control.ClickEvent
	Dim a As String = "test"
	a = Left(a, 2) 'Not works
	a = Right(a, 1) 'Now works with Windows, I need to check in Linux.
End Sub

[coderJeff]

Yes. I wanted to create a simple example, but it worked:

I will try to explain why it works. From your example I can see how I can modify so it "not works" in your actual usage.
The symbol lookups in 1.08.1 and earlier are a mess. A good set of rules to follow is missing. There are multiple bugs. My opinion is code "works" or "not works" often without any logical explanation other than that's the way it's always been, but IMHO doesn't make what the compiler was doing correct.

The general problem comes from: when a 'symbol' name is just by itself without any qualification of which namespace it belongs to AND there are multiple definitions of that 'symbol' reachable from the specific scope in the code where the 'symbol' is given, what it is the rule to follow? Choose one symbol over another? Or show and ambiguous access error?

Give me a bit of time to expand on this ...

[Xusinboy Bekchanov]

Yes. I wanted to create a simple example, but it worked:

I will try to explain why it works. From your example I can see how I can modify so it "not works" in your actual usage.

I would like it to be without the "..":

@coderjeff, можно ли сделать Left, Right, Point, Rect основным, а остальные как раньше второстепенными? Потому что мы можем получить к ним доступ через gdiplus.Rect, gdiplus.Point, This.Left, Keys.Left, Keys.Right. Выглядит лучше, чем ..Left, ..Right, ..Point, ..Rect.

[Xusinboy Bekchanov]

Code: Select all

	a = Right(a, 1) 'Now works with Windows, I need to check in Linux.

I also checked it in Linux, it works, so we can delete ..Right from the request. I removed the ".." in front of Right from my program.

[coderJeff]

There will always be some kind of issue if there is going to more than one thing that has the same name. I think it's worth exploring so I will continue you it Study of symbol lookups in namespaces and types.

I feel like some bugs have been fixed. And there is still more to do.

[Xusinboy Bekchanov]

It turns out that inside the Namespace doesn't work:

Code: Select all

Type Rect
   Left As Integer
   Top As Integer
   Right As Integer
   Bottom As Integer
End Type

Type Point
   X As Integer
   Y As Integer
End Type

Namespace gdiplus
   Type Rect
      X As Integer
      Y As Integer
      Width As Integer
      Height As Integer
   End Type
   
   Type Point
      X As Integer
      Y As Integer
   End Type
End Namespace

Using gdiplus

Namespace P
	Sub Test
		Dim r As Rect
		r.Left = 10 ' Not works
	End Sub
End Namespace

[coderJeff]

I had made all the packages for a 1.09.0 release and was intending to upload today.

But because some changes will break user code, I need either a really strong reason to go along with the news, or fix the problems. So no release yet. I really want to get the release done so can move to next changes. The changes for var len strings (as discussed with adeyblue) are going to require changes in both compiler and rtlib, so it could get messy and seems like a good idea to put out a release first. Besides, we have new features and bug fixes I'd like to share in an official release.

When it's ready, here are the targets planned for 1.09.0:

Code: Select all

BUILD HOST               TARGET
ubuntu-14.04-x86         linux-x86
ubuntu-14.04-x86_64      linux-x86_64
ubuntu-16.04-x86         linux-x86
ubuntu-16.04-x86_64      linux-x86_64
ubuntu-18.04-x86         linux-x86
ubuntu-18.04-x86_64      linux-x86_64
ubuntu-20.04-x86_64      linux-x86_64
winnt-6.1                manual
winnt-6.1                win32
winnt-6.1                win64
winnt-6.1                win32-mingworg
winnt-6.1                win32-gcc-5.2.0
winnt-6.1                win64-gcc-5.2.0
winnt-6.1                win32-gcc-7.1.0
winnt-6.1                win64-gcc-7.1.0
winnt-6.1                win32-gcc-8.1.0
winnt-6.1                win64-gcc-8.1.0
winnt-6.1                win32-winlibs-gcc-9.3.0
winnt-6.1                win64-winlibs-gcc-9.3.0
winxp                    dos
winxp                    win32-mingworg
ubuntu-21.10-aarch64     linux-aarch64
raspbian9-arm            linux-arm
freebsd-13.0-x86         freebsd-x86
freebsd-13.0-x86_64      freebsd-x86_64

I'm not using any cross compilers. I've built the packages on actual OS (Win, Rpi), or in a VM (ubuntu's, freebsd, and winxp). Except for DOS which is built in the winxp VM. Some winnt-6.1 packages are built on win7, some on win10.
In all cases, once the packages are made:
- extract the new 1.09.0 package
- extract the new 1.09.0 source code
- build a new 1.09.0 compiler with the source
- test the newly built compiler with the test suite
- if that all passes then I consider it valid for distribution

[speedfixer]

Perhaps, then, a list of breaking changes?

You could get a feel for how many people would be bent out of shape, and where to spend time or publish an "I will ignore ...' note.
Sort out the real issues from just discontent.

david

[coderJeff]

Perhaps, then, a list of breaking changes?

There is a discussion about the most significant change in Study of symbol lookups in namespaces and types

For simple programs, even ones that use namespaces and extended types, many users won't notice any difference. However, confirmed is that it will break WinFBX which is used by many users.

All these issues are related to naming of things:

Bugs fixed in fbc 1.09.0
sf.net #645: don't access locals if explicit namespace is given on identifier
sf.net #645: don't access locals if explicit global namespace '.' and '..' prefixes are given on identifier
sf.net #645: throw compile time error if scoped REDIM variable shadows a variable of the same name
sf.net #581: Locals break/override THIS access to inherited members
sf.net #871: Inherited methods without this shadowed by global functions
sf.net #730: Using quirk keywords as identifier leads to parsing problems later
sf.net #515: fbc: show a warning if a public sub or a shared variable have the same name as global asm keywords (x86 and x86_64 only)
sf.net #944: Array descriptors are defined more than once (gcc backend)
sf.net #947: enum declaration in a namespace incorrectly checks for parent
sf.net #945: regression: Scoping rules have changed inside methods - allow globals to shadow non-explicit enums implicitly imported in to the current namespace


Bugs still to fix in the future:
#948 Overriding class members doesn't work inside methods of further-extended subclasses
#903 Operator cannot be a member function (TODO)
#902 Overloaded operators do not respect namespace
#895 Different namespace scoping rules apply in type and class declarations
#831 enumconsts become unaccessible if name reused by type
#804 anon namespaces allow Extern variables
#803 anon namespaces can collide
#781 Typedef identifier inconsistencies
#711 A derived type does not inherit any non-static member operators from its base
#583 UDTs/typedefs shadowed by fields using same id

[j8w344c6]

@coderJeff Could you provide the UCRT64 version of FB 1.09? I have successful building a version of FBC which links with UCRT64 instead of MSVCRT using MSYS2: https://www.msys2.org/docs/environments/ No need to change anything in code. Just build FBC with the UCRT64 GCC and that's it. Hope you could provide a standalone version of this UCRT64 FBC, too. Thank you.

I have tested my UCRT64 FBC for a while. It's very stable. It's rock solid.

On UCRT64 MSYS2, it uses libmsvcrt.a to link with the new ucrtbase. The old system msvcrt is libmsvcrt-os.a. So it's no need to change anything in code for this to be possible. On MINGW64 MSYS2, libmsvcrt.a and libmsvcrt-os.a are identical. It's a very clever way of doing thing the less breakage possible of the MSYS2 people. Wanted to link with the new ucrtbase? Just build it with UCRT64 MSYS2. No need to change in code. No need to change configure script. Very elegant.

[coderJeff]

@coderJeff Could you provide the UCRT64 version of FB 1.09? I have successful building a version of FBC which links with UCRT64 instead of MSVCRT using MSYS2: https://www.msys2.org/docs/environments/ No need to change anything in code. Just build FBC with the UCRT64 GCC and that's it. Hope you could provide a standalone version of this UCRT64 FBC, too. Thank you.

Can you help? You are almost there. I don't really have time right now to try a new package.

Build the compiler as a stand-alone (plus add whatever other options you use):
'make ENABLE_STANDALONE=1 clean-compiler'
'make ENABLE_STANDALONE=1'
'make ENABLE_STANDALONE=1 bindist'

Take the newly made 'FreeBASIC-1.09.0-win32.zip' | '.7z' and try it out. Take care not to have any MSYS2 tools in your path. What are the dependencies?

[miilvyxg]

@coderJeff: the winlibs GCC you use is also have UCRT version, no need to use MSYS2 to get UCRT GCC.

https://winlibs.com/

This time please ship with the latest GCC (11.2.0).

[coderJeff]

This time please ship with the latest GCC (11.2.0).

Not this time.

[coderJeff]

FreeBASIC 1.09.0 is released.

For links to download packages see the Announcement

Perhaps in the near future can adjust the download link on www.freebasic.net or write a README for sourceforge.net that explains the packages. Volunteers to write content welcome.

One major change users may find is the change of the linker script. Be sure to match the linker script with the version of the compiler. The change was needed to allow new and old versions of binutils to be used - without actually knowing the version of the binutils installed on the host system.

In the past I have created a separate Release Discussion topic, but users post here anyway, so here we are.

Some things I didn't do, Sorry.
- some packages are missing zlib1.dll because they always did. I don't use any package other than winlibs-9.3 on windows.
- still no 64-bit gdb for windows included.
- a member emailed my about updating DisLin headers. I never did, sorry.

There has been much discussion recently about 'symbol lookups' and breaking user code. Yes, it's possible that something may break. This is what active development discussed out in the open looks like. It's probably not as bad as you may think.

[TJF]

- a member emailed my about updating DisLin headers. I never did, sorry.

The DisLin guys integrated my header in their distributions and maintain it further. It's shipped in the win-fb packages (should work on LINUX too):

• win32: https://www.dislin.de/win32.html
• win64: https://www.dislin.de/win64.html