FreeBASIC 1.09.0 Release
-
- Posts: 4281
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: FreeBASIC 1.08.1 and 1.09.0 Development
My German friend sent me a fbc 1.08.1/gcc 9.3.
In particular, UEZ's Fireworks worked with fbc 1.07.3 but not 1.08.0. Not being in UEZ's class when it comes to graphics coding, I wouldn't even hazard a guess what the issue was, but it seems to have been resolved with the latest fbc 1.08.1 build.
Added: Looking at the changelog.txt perhaps correcting ScreenControl did the trick.
Well done, coderJeff, yet again.
In particular, UEZ's Fireworks worked with fbc 1.07.3 but not 1.08.0. Not being in UEZ's class when it comes to graphics coding, I wouldn't even hazard a guess what the issue was, but it seems to have been resolved with the latest fbc 1.08.1 build.
Added: Looking at the changelog.txt perhaps correcting ScreenControl did the trick.
Well done, coderJeff, yet again.
Re: FreeBASIC 1.08.1 and 1.09.0 Development
Hi deltarho,deltarho[1859] wrote:My German friend sent me a fbc 1.08.1/gcc 9.3.
In particular, UEZ's Fireworks worked with fbc 1.07.3 but not 1.08.0. Not being in UEZ's class when it comes to graphics coding, I wouldn't even hazard a guess what the issue was, but it seems to have been resolved with the latest fbc 1.08.1 build.
Added: Looking at the changelog.txt perhaps correcting ScreenControl did the trick.
Well done, coderJeff, yet again.
What is the problem with 1.08.0? I tested it and it seems work properly except that the GUI is off the monitor and I have to move it to the visible area to see something?
99,99% I'm using my company's notebook to code but McAfee doesn't like the graphical stuff and classify it as malware (trojan). Most of the gfx compiled stuff were moved to quarantine and reported to security. Currently I'm very tentative in compiling especially for gfx stuff. With 1.08.0 it seems a little bit better (this as a side note).
I can only agree, great work coderJeff.
-
- Posts: 4281
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: FreeBASIC 1.08.1 and 1.09.0 Development
Nothing happens. It shows as suspended in Process Explorer, and I'm unable to kill it, requiring a system restart.UEZ wrote:What is the problem with 1.08.0?
That is with both fbc 1.08.0 gcc 5.2/gcc 9.3 SJLJ
With 1.07.3 and 1.08.1 it is perfectly centred.except that the GUI is off the monitor and I have to move it to the visible area to see something?
Perhaps with differing graphics subsystems, we get different misbehaving?
Re: FreeBASIC 1.08.1 and 1.09.0 Development
Version 1.09.0
.....
[fixed]
- github #315: set parameters when calling SCREENCONTROL (was broken in fbc 1.08.0 due to new LONG/LONGINT SCREENCONTROL API's)
.....
-
- Posts: 4281
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: FreeBASIC 1.08.1 and 1.09.0 Development
From WinFBE:
FreeBASIC Compiler - Version 1.08.1 (2021-06-30), built for win32 (32bit)
Or
FreeBASIC Compiler - Version 1.08.1 (2021-06-30), built for win64 (64bit)
FreeBASIC Compiler - Version 1.08.1 (2021-06-30), built for win32 (32bit)
Or
FreeBASIC Compiler - Version 1.08.1 (2021-06-30), built for win64 (64bit)
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: FreeBASIC 1.08.1 and 1.09.0 Development
Hi. Just to say, I’ve split the Asm keyword discussion into its own thread: viewtopic.php?f=17&t=29480
Re: FreeBASIC 1.08.1 and 1.09.0 Development
I've made some recent updates to the inc/crt header files to add the constant qualifiers for some crt prototypes. Just by hand editing, which is not ideal but works for me so I'm not side tracked updating crt headers for weeks. Should not cause issues for users. Adding the const qualifier to the crt headers is long over due.
This was needed for: fbrtLib - by Imortis
fbc's makefile has been updated so that 'make fbrt' will build the fbrtLib project when it is cloned into src/fbrt under the fbc development tree. This will build ./lib/<target>/libfbrt.a and libfbrtmt.a. If the fbrt library is missing and object modules, the makefile with grab the missing files from libfb and libfbmt respectively.
Also added to fbc is '-z fbrt' command line switch. This simply tells fbc to link with the libfbrt[mt].a library instead of the libfb[mt].a library rather than having to copy or move files around or have multiple development directories.
Anyway it worked for me to get fbrtLib up and running and it almost passed the test suite. (standalone win32 -gen gas only so far for me).
This was needed for: fbrtLib - by Imortis
fbc's makefile has been updated so that 'make fbrt' will build the fbrtLib project when it is cloned into src/fbrt under the fbc development tree. This will build ./lib/<target>/libfbrt.a and libfbrtmt.a. If the fbrt library is missing and object modules, the makefile with grab the missing files from libfb and libfbmt respectively.
Also added to fbc is '-z fbrt' command line switch. This simply tells fbc to link with the libfbrt[mt].a library instead of the libfb[mt].a library rather than having to copy or move files around or have multiple development directories.
Anyway it worked for me to get fbrtLib up and running and it almost passed the test suite. (standalone win32 -gen gas only so far for me).
Re: FreeBASIC 1.08.1 and 1.09.0 Development
To invoke a method pointer, why not use a syntax similar to the one used to call a method on instance?todo.txt wrote:
[ ] method pointers / delegates
- - extend PROCPTR( id, type ) to allow pointers to methods
- fbc handles method pointers fairly well but the syntax is not symmetrical with invoking a method on a TYPE (class)
- var x = procptr( T.method ) could return a method pointer but must currently be invoked with x( instance, [params]... ). This is a different syntax from other languages that support method pointers.
- delegates would need to aggregate the instance and method pointer which will likely requre a new built-in type to handle by the compile.
- Dim As UDT u
' classic call of method on instance:
u.method( parameters... )
Var pm = Procptr( UDT.method )
' future call of method pointer (with instance):
u.pm( parameters... ) '' why not ?
' rather than:
pm( u, parameters... )
Re: FreeBASIC 1.08.1 and 1.09.0 Development
'pm( u, parameters... )'fxm wrote: u.pm( parameters... ) '' why not ?
' rather than:
pm( u, parameters... )[/tt]
[/list]
- is easy to enable in the compiler - the functionality is like 95% there.
- there is no association between 'pm' and 'u' - but maybe that's ok, this is a low-level construct
- exposes typeof(pm) at a low level - under the hood, non-static member procedures have an instance/this argument.
- typeof(pm) == procptr( u.method )
- But, I'm reluctant to jam it in without thinking it through a little bit. Other languages tend to have special syntax and wrap the construct in something like a delegate.
- This seems like the straight forward thing to do, but I'm not not an expert language designer.
'u.pm( parameters... )'
- is hard to do in the parser, 'pm' is not a member of 'u' so special syntax / parsing rules are needed
- also no association between 'pm' and 'u' - so seems few advantages over 'pm( u, parameters... )'
- what is typeof( u.pm ) ?
- visibility (acces to) u.pm? But may have same oddity in above.
I don't know. I could enable 'pm( u, parameters... )' it if there is some understanding from users: 1) it has not been well thought out, 2) however is easy to enable and 3) seems like it would work well with fbc compiler internals at a low level.
Re: FreeBASIC 1.08.1 and 1.09.0 Development
This is the natural syntax that can be used now when hacking under the hood the vtable as an array of pointers to the virtual methods.coderJeff wrote:'pm( u, parameters... )'
-
- Posts: 532
- Joined: Dec 02, 2011 22:51
- Location: France
Re: FreeBASIC 1.08.1 and 1.09.0 Development
Just to point out : when one write :
var pm = procptr( udt.method) followed by pm( u, parameters )
then from user point of view, pm is used as a function, althought it was a variable !
then, ones can think, ok then, procptr does not actually return a pointer, it returns a directly usable procptr, meaning a function .. trigger or call entry point (cae ?)
This would require some documentation,…
According to that logic, pm shall not be seen as 'var' by user but rather something else, otherwise strong typing breach ? (readability). Perhaps a special type required :
trig pm =procptr( udt.method ) ? trig or anything else ?
Let's try to think about / imagine enduser / newcomer's point of view.
var pm = procptr( udt.method) followed by pm( u, parameters )
then from user point of view, pm is used as a function, althought it was a variable !
then, ones can think, ok then, procptr does not actually return a pointer, it returns a directly usable procptr, meaning a function .. trigger or call entry point (cae ?)
This would require some documentation,…
According to that logic, pm shall not be seen as 'var' by user but rather something else, otherwise strong typing breach ? (readability). Perhaps a special type required :
trig pm =procptr( udt.method ) ? trig or anything else ?
Let's try to think about / imagine enduser / newcomer's point of view.
Re: FreeBASIC 1.08.1 and 1.09.0 Development
It already works like this for static function pointers:
PROCPTR (or operator '@') returns a typed pointer value:
- The type is the one of a generic procedure (sub or fct) of the same signature than the referenced procedure.
- The value is the address of the referenced procedure.
- So VAR creates a procedure pointer of the same type and value.
Procedure pointer usage:
- Without parentheses, we only access the value of the pointer (the address of the procedure).
- With parentheses surrounding the argument list (even empty), we call the procedure (parentheses usage behind a procedure pointer name implies a kind of pointer dereferencing command).
Documentation updated:
- KeyPgSubPtr → fxm [added precision on the syntax for using the sub pointer]
- KeyPgFunctionPtr → fxm [added precision on the syntax for using the function pointer]
Code: Select all
Function sum (Byval x As Integer, Byval y As Integer) As Integer
Return x + y
End function
Var fctptr = Procptr(sum)
#print typeof(fctptr)
Print fctptr
Print fctptr(3, 2)
Sleep
Compiler output:
FUNCTION(AS INTEGER, AS INTEGER) AS INTEGER
[edit]4199712
5
PROCPTR (or operator '@') returns a typed pointer value:
- The type is the one of a generic procedure (sub or fct) of the same signature than the referenced procedure.
- The value is the address of the referenced procedure.
- So VAR creates a procedure pointer of the same type and value.
Procedure pointer usage:
- Without parentheses, we only access the value of the pointer (the address of the procedure).
- With parentheses surrounding the argument list (even empty), we call the procedure (parentheses usage behind a procedure pointer name implies a kind of pointer dereferencing command).
Documentation updated:
- KeyPgSubPtr → fxm [added precision on the syntax for using the sub pointer]
- KeyPgFunctionPtr → fxm [added precision on the syntax for using the function pointer]
Re: FreeBASIC 1.08.1 and 1.09.0 Development
Here is a hacked method pointer.
Here is a function to get the proper name for the mangled string "_ZN3UDT4PLUSEd"
Edited and simplified.
But the proper name doesn't revert to the mangled name under extern "c++" in the first code?
Code: Select all
type udt
as double x,y
declare function plus(as double) as double
end type
function udt.plus(a as double) as double
return a+x+y
end function
declare function f alias "_ZN3UDT4PLUSEd"(as udt,as double) as double
var x=procptr(f)
dim as udt u
u.x=10
u.y=20
print x(u,5.5)
sleep
Code: Select all
#inclib "stdc++"
declare function demangle cdecl alias "__cxa_demangle"(as zstring ptr,as zstring ptr=0,as long=0,byref as long=0) as zstring ptr
dim as long k
print *demangle("_ZN3UDT4PLUSEd",0,0,k)
print
print k
'values for k
'0: The demangling operation succeeded.
'-1: A memory allocation failiure occurred.
'-2: mangled_name is not a valid name under the C++ ABI mangling rules.
'-3: One of the arguments is invalid.
'see https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a01696.html
sleep
But the proper name doesn't revert to the mangled name under extern "c++" in the first code?
-
- Posts: 25
- Joined: Dec 11, 2019 15:14
- Contact:
Re: FreeBASIC 1.08.1 and 1.09.0 Development
Please add "split" and "join"
VisualBasic6
These two functions are very common
VisualBasic6
These two functions are very common
Re: FreeBASIC 1.08.1 and 1.09.0 Development
On windows I get troubles with leading underscores in the name. I'm not sure the leading underscore rules are 100% consistent. And it's different rules windows versus other targets. Typically though,dodicat wrote:But the proper name doesn't revert to the mangled name under extern "c++" in the first code?
For the basic source:
> fbc a.bas -r
> grep a.asm -i -e 'udt'
.globl __ZN3UDT4PLUSEd@12
__ZN3UDT4PLUSEd@12:
mov eax, offset __ZN3UDT4PLUSEd@12
The @N should indicate stdcall calling convention on windows.
Feed this back in to c++filt with 2 leading underscores instead of one:
>c++filt
__ZN3UDT4PLUSEd
UDT::PLUS(double)
__ZN3UDT4PLUSEd@12
UDT::PLUS(double)@12
In theory, should not have to deal with the mangled name directly if using fbc together with g++. dkl and myself have worked on the name mangling quite a bit over the years to try and use g++ name mangling rules as the standard for mixed language programming.