Freebasic 1.20.0 Development

[PaulSquires]

At this point why don't you just audit the language for all the crap, broken and obtuse things, gut them, and rebuild them however you like with no regards for what went before (or leave them out altogether) and call it FreeBasic 2.0.

I had been wanting to suggest this exact same thing for a while but was too afraid thinking that it would be a very unpopular opinion. Drop 32-bit, move to an LLVM backend (might make it easier to implement ARM architecture that will soon dominate all platforms), engage community to create solid cross-platform (including macOS) tooling such as editor, package manager, build system, etc. Basically, create a roadmap that would compete with the mainstream languages otherwise FB will remain just a hobby language like all the other BASIC languages. Gut all the legacy stuff from FB and move forward with a narrower focus, streamlined syntax, and don't be concerned with backward compatibility for FreeBASIC 2.0.

[Lost Zergling]

I have a dilemma: on the one hand completely leaving aside backwards compatibility is really something very problematic, on the other hand moving forward is necessary. On the one hand the argument for standardization with ARM architecture, on the other it seems clear that regressions are inevitable and that they could compromise the success of an entirely new project. On the one hand the prospect of an entirely new reflection on design, on the other what about the essence of basic. On the one hand, imagining new conceptual specifications is exciting, on the other hand, is it already possible to model via pointer implementation as for many projects (including lzle).
Thus, new conceptual designs implementations are already and constantly deployed by Jeff and fxm.
Losing pointer support would be a terrible disaster.
Assuming that we have considerable development resources, which is not the case, my preference would be towards an "upstream extension", that is to say that FB would gradually become the "extended basic" of the new kernel, somewhat as an object or a series of option objects of this new base, in a sort of incremental compiler (perhaps already in guidelines, don't know) (loss of arm support with some objects). In my opinion, only such an approach could guarantee the sustainability of the work.
This is my sensitivity, but this would in no way resolve the immense scale of the new needs in this hypothesis . The loss of 32-bit support is regrettable, but undoubtedly inevitable in the long term. However, functionality will remain imposed by resilience and use cases.

[coderJeff]

adeyblue has the right idea. An audit will be worthwhile to identify all the junk. Some more aggressive concentrated effort than what we've been doing past several years of incremental reviews.

Roadmap: Currently is a union of bug reports + TODO list + needs of developers of large fb projects + requests by respectful users + some loud angry forum posts + my own interests. Maybe for next release I will try to put it all in one place to describe what roadmap I wold have in mind. Then if people don't like it they can volunteer to support whatever is important to them, or fork the project and go their own way, or I can step away and leave it to others.

[marcov]

At this point why don't you just audit the language for all the crap, broken and obtuse things, gut them, and rebuild them however you like with no regards for what went before (or leave them out altogether) and call it FreeBasic 2.0.

I had been wanting to suggest this exact same thing for a while but was too afraid thinking that it would be a very unpopular opinion.

Well of course. The new code also will have to be validated and fixed. All new code contains bugs or oversights. And of course you will frustrate the users with larger codebases that are probably responsible for the bulk of the bugreports and small patches ?

Like with any major project change, such rewrite will usually already be met with requests for the next course change before it is wholly completed.

Drop 32-bit,

... On Linux probably, because the distros will drop x86 32-bit linux anyway. Be careful with arm and mips though since that would make it hard to do embedded work.

On Windows dropping 32-bit, would depend on usage and state of things like the win64 debuggers etc.

Even if you decide to drop them from the native backend, leave them C backend only. Then it doesn't matter that much.

move to an LLVM backend (might make it easier to implement ARM architecture that will soon dominate all platforms),

(I assume you really mean LLVM here, not Clang as C backend)

That is a big move for a "might". LLVM is notoriously versioned and intwined with Clang. Just like the many GCC derivatives before it, very few actually make the cut long term, leaving projects in an infinite state of catch up.

Moreover any ability to distinguish yourself (even only on the ease of distribution, or deployment requirements) disappears. Users are much more tempted to cut out the middle man and go for a major language.

engage community to create solid cross-platform (including macOS) tooling

OS X is the first one that I would drop. Relatively a lot of work to support it (with all its own specific version of tools) and a lot of clueless users, few developers or even just regular bug reporters. Targets that can't up their own belt to provide their own support by its users engaging or at least supporting development are dodos.

The users with the big codebases are more important in getting FB to the next level than masses of newbies, since any new developers usually come from the former, not the latter group.

such as editor, package manager, build system, etc. Basically, create a roadmap that would compete with the mainstream languages otherwise FB will remain just a hobby language like all the other BASIC languages. Gut all the legacy stuff from FB and move forward with a narrower focus, streamlined syntax, and don't be concerned with backward compatibility for FreeBASIC 2.0.

While cleaning out some really old stuff (like the more extreme parts of QB emulation or any low used stuff) might help, I don't expect that the gutting will yield that much. Usually it is the rewrite that saves time (e.g. sharing more code between various backends), not the gutting of minor features. Mostly that only annoys people, and the discussions about what to gut eat more time than it saves.

After the rewrite gutting only saves on some really minor daily maintenance but expects the savings to add up to bring major features, which is not realistic.

Major feature usually only come about when a developer really has a lot of time on his hands. Quite often after people get older they get less time, and a new generation (of students or people in their first jobs) with a lot of time needs to pick up the major features.

So though a rewrite of certain parts to make it more maintainable might help, I would put the rewrite for maintainability central to the effort and not the gutting.

Moreover, any non compiler work should be done by new teams or interested users, not add to tasks for core. And that could already have happened and is not dependent on a compiler rewrite for maintainability.

[PaulSquires]

All great points marcov, thanks.

[Lost Zergling]

@marcov !including("tp") is excellent, as usual

[Xusinboy Bekchanov]

Hello, when compiling this example using compiler 1.20.0 dated 04/01/2024, it gives the error:

Code: Select all

#include once "windows.bi"

Private Function GetRed(FColor As Long) As Integer
	Return CUInt(FColor) And 255
End Function

Private Function GetGreen(FColor As Long) As Integer
	Return CUInt(FColor) Shr 8 And 255
End Function

Private Function GetBlue(FColor As Long) As Integer
	Return CUInt(FColor) Shr 16 And 255
End Function

Type RGB3 Field = 1
	G As Byte
	B As Byte
	R As Byte
End Type
Type BitmapStruct Field = 1
	Identifier      As WORD
	FileSize        As DWORD
	Reserved0       As DWORD
	bmpDataOffset   As DWORD
	bmpHeaderSize   As DWORD
	bmpWidth        As DWORD
	bmpHeight       As DWORD
	Planes          As WORD
	BitsPerPixel    As WORD
	Compression     As DWORD
	bmpDataSize     As DWORD
	HResolution     As DWORD
	VResolution     As DWORD
	Colors          As DWORD
	ImportantColors As DWORD
End Type
Static As BitmapStruct BM
Dim As Integer F, x, y, Clr, Count = 0
Dim As HDC FDevice
Dim As Integer FWidth = 50, FHeight = 50
ReDim PixelData(FWidth * FHeight - 1) As RGB3
For y = FHeight-1 To 0 Step -1
	For x = 0 To FWidth - 1
		Clr = GetPixel(FDevice,x,y)
		PixelData(Count).G = GetGreen(Clr)
		PixelData(Count).R = GetRed(Clr)
		PixelData(Count).B = GetBlue(Clr)
		Count += 1
	Next x
Next y
BM.Identifier      = 66 + 77 * 256
BM.Reserved0       = 0
BM.bmpDataOffset   = 54
BM.bmpHeaderSize   = 40
BM.Planes          = 1
BM.BitsPerPixel    = 24
BM.Compression     = 0
BM.HResolution     = 0
BM.VResolution     = 0
BM.Colors          = 0
BM.ImportantColors = 0
BM.bmpWidth        = FWidth
BM.bmpHeight       = FHeight
BM.bmpDataSize     = FWidth * FHeight * 3
BM.FileSize        = BM.bmpDataOffset + BM.bmpDataSize
F = FreeFile
Open "Test.bmp" For Binary Access Write As #F
Put #F,,BM
Put #F,,PixelData() ' Error in this line - PixelData()
Close #F

Code: Select all

Untitled.bas(69) warning 50(2): Suspicious address expression passed to BYREF parameter, at parameter 3
Aborting due to runtime error 12 ("segmentation violation" signal)

How can I fix this?

[SARG]

Hello Xusinboy,
Compiled with gcc and gas64. No warning and no crash.


edited :
With last daily build 32bit --> warning and crash

[Xusinboy Bekchanov]

Hello Xusinboy,
Compiled with gcc and gas64. No warning and no crash.

It does not compile with 32-bit gas.

[fxm]

@Jeff,

Since fbc version 1.20.0, Put# warns then crashes on compilation with an array as data.
See posts above.
(there are several recent changes regarding the arrays. Maybe : fbc: fix non-index array assignments)

The documentation example also warns then crashes on compilation:

Code: Select all

' Create an integer array
Dim buffer(1 To 10) As Integer
For i As Integer = 1 To 10
    buffer(i) = i
Next

' Find the first free file file number
Dim f As Long
f = FreeFile()

' Open the file "file.ext" for binary usage, using the file number "f"
Open "file.ext" For Binary As #f
' Write the array into the file, using file number "f"
' starting at the beginning of the file (position 1)
Put #f, 1, buffer()

' Close the file
Close #f

warning 50(2): Suspicious address expression passed to BYREF parameter, at parameter 3
Aborting due to runtime error 12 ("segmentation violation" signal)

[fxm]

Hello, when compiling this example using compiler 1.20.0 dated 04/01/2024, it gives the error

Possible workaround for your code above (not tested):
Put #F,,PixelData(Lbound(PixelData)),Ubound(Pixeldata) - Lbound(PixelData) + 1

[Xusinboy Bekchanov]

Hello, when compiling this example using compiler 1.20.0 dated 04/01/2024, it gives the error

Possible workaround for your code above (not tested):
Put #F,,PixelData(Lbound(PixelData)),Ubound(Pixeldata) - Lbound(PixelData) + 1

Thanks for the example fix, I also expect the same behavior on 32 and 64 bit without using LBound, UBound.

[fxm]

I also expect the same behavior on 32 and 64 bit without using LBound, UBound.

Yes all fbc versions 1.20.0 (32 and 64 bit) crashes on compilation.

[Xusinboy Bekchanov]

I also expect the same behavior on 32 and 64 bit without using LBound, UBound.

Yes all fbc versions 1.20.0 (32 and 64 bit) crashes on compilation.

64 bit compiles without problems.

[Xusinboy Bekchanov]

I also expect the same behavior on 32 and 64 bit without using LBound, UBound.

Yes all fbc versions 1.20.0 (32 and 64 bit) crashes on compilation.

64 bit compiles without problems.

You are right, it turns out that the 64-bit version also crashes.