New FB release soon

General discussion for topics related to the FreeBASIC project or its community.
fxm
Moderator
Posts: 12577
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release soon

Post by fxm »

dkl wrote:Does this code use bitfields? That's the only remaining issue regarding structure layout that I know of.
See at topic:
http://www.freebasic.net/forum/viewtopi ... =3&t=21772

I don't find any bug report!
fxm
Moderator
Posts: 12577
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release soon

Post by fxm »

Following this change (2014-05-04) in fbc 1.00.0 (former 0.91.0):
changelog.txt in § [changed] wrote:- The implicitly generated copy constructors and LET overloads will now have "BYREF AS CONST MyUdt" parameters (previously they didn't use CONST), to allow copying from CONST objects to work at least for the built-in data types or with nested UDTs. For backwards compatibility, if there is a user-defined "UDT.let(byref as UDT)" LET overload, FB will still add the non-const "UDT.constructor(byref as UDT)" copy-constructor. It's still the programmer's responsibility to write proper "byref as const UDT" versions of the copy-constructor or LET overload if the UDT needs deep-copying and CONST instances of the UDT are being used.

(Also generate BYREF AS CONST versions of implicit LET overload/copyctor)
One example in the built documentation no longer works with fbc 1.00.0 or former fbc 0.91.0 since 2014-05-04 (the second example of Base (Initializer) before the modification done now), and perhaps some user code:

Code: Select all

Type ComplexParent
    As Integer i
    Declare Constructor( ByVal As Integer )
End Type

Constructor ComplexParent( ByVal i As Integer )
    this.i = i
End Constructor

Type Child extends ComplexParent
    Declare Constructor( )
    Declare Constructor( ByRef As Child )
End Type

Constructor Child( )
    '' Base UDT constructor call
    Base( 1 )
End Constructor

Constructor Child( ByRef rhs As Child )
    '' Base UDT constructor call
    Base( rhs.i )
End Constructor
Compiler output:
.....\FBIde0.4.6r4_fbc1.00.0\FBIDETEMP.bas(13) error 187: Missing UDT.constructor(byref as const UDT) implementation (base UDT without default constructor requires manual initialization), found 'End' in 'End Type'

- The problem origin is the same than this simpler code failing since fbc version 0.90.0:

Code: Select all

Type ComplexParent
    As Integer i
    Declare Constructor( ByVal As Integer )
End Type

Constructor ComplexParent( ByVal i As Integer )
    this.i = i
End Constructor

Type Child extends ComplexParent
End Type
Compiler output:
.....\FBIde0.4.6r4_fbc1.00.0\FBIDETEMP.bas(11) error 185: Missing default constructor implementation (base UDT without default constructor requires manual initialization), found 'End' in 'End Type'

- Among the different solutions to solve the problem of documentation example (as declare the copy-constructor as passing parameter as const in the documentation example), the simpler is always to also define a default Base constructor when another explicit Base constructor is defined:

Code: Select all

Type ComplexParent
    As Integer i
    Declare Constructor( ByVal As Integer = 0 )
End Type

Constructor ComplexParent( ByVal i As Integer = 0 )
    this.i = i
End Constructor

Type Child extends ComplexParent
End Type

Code: Select all

Type ComplexParent
    As Integer i
    Declare Constructor( ByVal As Integer = 0 )
End Type

Constructor ComplexParent( ByVal i As Integer = 0 )
    this.i = i
End Constructor

Type Child extends ComplexParent
    Declare Constructor( )
    Declare Constructor( ByRef As Child )
End Type

Constructor Child( )
    '' Base UDT constructor call
    Base( 1 )
End Constructor

Constructor Child( ByRef rhs As Child )
    '' Base UDT constructor call
    Base( rhs.i )
End Constructor
Updating the second example of documentation:
KeyPgBaseInit ⇒ FxMwikki [Compile error with second example since fbc version 1.00.0 (former 0.91.0)]
Last edited by fxm on Sep 13, 2014 21:28, edited 9 times in total.
D.J.Peters
Posts: 8642
Joined: May 28, 2005 3:28
Contact:

Re: New FB release soon

Post by D.J.Peters »

TJF wrote:...But when I try to compile the fb-doc code I get a similar error as we had with the ARM version...
Do you build a new fbc ARM version ?

Joshy
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: New FB release soon

Post by TJF »

D.J.Peters wrote:Do you build a new fbc ARM version ?
... made one some weeks ago. dkl fixed the sources. It's easy now.
D.J.Peters
Posts: 8642
Joined: May 28, 2005 3:28
Contact:

Re: New FB release soon

Post by D.J.Peters »

TJF wrote:... made one some weeks ago. dkl fixed the sources. It's easy now.
why do not share it for the community is in the linux section ?

Joshy
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: New FB release soon

Post by TJF »

It was just a short test for libpruio compatibility. And I wanted to wait for the official new fbc release.

I'll serve an update before my next libpruio release.

@dkl:

Is there any summary how to make headers 64 bit compatible? You need help converting them! Currently there are less than 100 files in the 64 bit release (GTK+ and dependencies have more than 400).
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: New FB release soon

Post by dkl »

How about we add some information to the FB documentation? I think data types are the main (only?) issue.

By the way, could you send me your fb-doc code (or a reduced example) which triggers the -gen gcc issue? I haven't been able to reproduce it with fb-doc-0.2, but I'd like to debug and fix it.
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: New FB release soon

Post by TJF »

dkl wrote:How about we add some information to the FB documentation? I think data types are the main (only?) issue.
Any place is OK, IMHO. Just share your experience, so others can quickly start to help out.
dkl wrote:By the way, could you send me your fb-doc code (or a reduced example) which triggers the -gen gcc issue? I haven't been able to reproduce it with fb-doc-0.2, but I'd like to debug and fix it.
You can use the code form my above post. Here's the same code, but lines with undeclared types are commented out

Code: Select all

TYPE Highlighter
  '* \brief The high-lighting categories
  ENUM WordTypes
    FB_CODE  '*< Normal code, no high-lighting
    FB_KEYW  '*< A keyword
    FB_KWTP  '*< A keyword type
    FB_KWFL  '*< A flow keyword (currently not used)
    FB_PREP  '*< A preprocessor statement
    FB_SYMB  '*< A linked Symbol
  END ENUM

  AS STRING _
      FbPath _   '*< The path to read FB code files from
    , FbFiles _  '*< A list of all FB file names
    , InPath _   '*< The path to read Doxygen files from
    , DoxyFiles _'*< A list of all Doxygen file names
    , HtmlPath _ '*< The path for html files
    , HtmlSuff _ '*< The filename suffix for html files
    , TexPath _  '*< The path for LaTeX files
    , XmlPath _  '*< The path for XML files
    , LastLine   '*< The last line red from the input file
  'AS RepData PTR Symbols '*< The list of linked symbols
  'AS Parser PTR Pars '*< The parser to operate with
  AS ZSTRING PTR _
      FBDOC_MARK = @"<!-- Syntax-highlighting by fb-doc -->" _ '*< Text to mark the output
    , KEYW_A = @"<span class=""keyword"">"             _ '*< Code to start highlighting a keyword
    , KWTP_A = @"<span class=""keywordtype"">"         _ '*< Code to start highlighting a keywordtype
    , KWFL_A = @"<span class=""keywordflow"">"         _ '*< Code to start highlighting a flow keyword (not used yet)
    , PREP_A = @"<span class=""preprocessor"">"        _ '*< Code to start highlighting a preprocessor statement
    , CMNT_A = @"<span class=""comment"">"             _ '*< Code to start highlighting a comment
    , SPAN_E = @"</span>"                              _ '*< Code to end highlighting
    , QUOT_A = @"<span class=""stringliteral"">"" _ '*< Code to start highlighting a string literal
    , QUOT_E = @""</span>"                          '*< Code to end highlighting a string literal
  AS INTEGER _
      Ifnr _  '*< The file number for input
    , LineNo  '*< The current line number

  UNION
    TYPE
      AS INTEGER _
        GenHtml : 1 _ '*< Flag for html output
       , GenTex : 1 _ '*< Flag for LaTeX output
       , GenXml : 1   '*< Flag for XML output
    END TYPE
    AS INTEGER GenAny '*< All output flags
  END UNION

  DECLARE CONSTRUCTOR()
  'DECLARE CONSTRUCTOR(BYVAL AS Parser PTR)
  DECLARE SUB doDoxy(BYREF AS STRING)
  DECLARE SUB do_files()
  DECLARE STATIC FUNCTION prepare_tex(BYVAL AS Highlighter PTR) AS STRING
  DECLARE STATIC FUNCTION prepare_xml(BYVAL AS Highlighter PTR) AS STRING
  DECLARE STATIC FUNCTION prepare_html(BYVAL AS Highlighter PTR) AS STRING
  DECLARE SUB generate_all(BYVAL AS ZSTRING PTR, BYVAL AS INTEGER)
  DECLARE FUNCTION generate_code(BYVAL AS ZSTRING PTR, BYVAL AS INTEGER, BYVAL AS INTEGER) AS STRING
  DECLARE FUNCTION word_type(BYREF AS STRING) AS ZSTRING PTR

  '* \brief the function called to end a line and start a new one
  'eol AS FUNCTION(BYVAL AS RepData PTR, BYref AS INTEGER) AS STRING _
    '= @html_eol()
  '* \brief the function called to extract links from original files
  prepare AS FUNCTION(BYVAL AS Highlighter PTR) AS STRING _
    = @prepare_html()
  '* \brief the function called for normal code to replace special characters
  'special_chars AS FUNCTION(BYVAL AS UBYTE PTR, BYVAL AS INTEGER, BYVAL AS INTEGER) AS STRING _
    '= @html_specials()
END TYPE
PM me if you like/need a complete source tree of my development version. (The docu isn't ready yet, so I don't want to publish ATM.)

BTW:
My current workarround is

Code: Select all

...
  UNION
    TYPE
      AS UBYTE _
        GenHtml     _ '*< Flag for html output
       , GenTex     _ '*< Flag for LaTeX output
       , GenXml       '*< Flag for XML output
    END TYPE
    AS INTEGER GenAny '*< All output flags
  END UNION
...
This works OK. But your effort is highly appreciated, since we need bitfields to bind libraries.
fxm
Moderator
Posts: 12577
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release soon

Post by fxm »

fxm wrote:
dkl wrote:The FB-win32-gcc-4.7.3 package was for FB 0.90, and I do not intend to update it. It's possible that it still works even with the gcc 4.9 libraries, I didn't test it though. Same goes for the external library builds - it's too much work for me.
Why not do this following for the new add-on?
Self build the [FB-win32-gcc-4.9.1] package from i686-4.9.1-release-win32-sjlj-rt_v3-rev0.7z :

Code: Select all

[FB-win32-gcc-4.9.1] package:
    \bin
        \libexec
            \gcc
                \i686-w64-mingw32
                    \4.9.1
                        cc1.exe    <- from: [i686-4.9.1-release-win32-sjlj-rt_v3-rev0]
                                             \mingw32\libexec\gcc\i686-w64-mingw32\4.9.1
        \win32
            gcc.exe                <- from: [i686-4.9.1-release-win32-sjlj-rt_v3-rev0.7z]
                                             \mingw32\bin
Version 1.00.0 released:
The add-on for gcc (as above) is well integrated in the "FB for Windows 64bit (x64)", but not in the "FB for Windows 32bit (x86)".
Why?
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: New FB release soon

Post by dkl »

gcc is required for the 64bit version but not the 32bit version, because the 64bit version is based on -gen gcc (because -gen gas does not support 64bit), while the 32bit version defaults to -gen gas (no gcc needed).
fxm
Moderator
Posts: 12577
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release soon

Post by fxm »

Yes, I know!
So user who want to use gcc on FB win32 must do this by making his own "FB-win32-gcc-4.9.1" add-on as explained above?
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: New FB release soon

Post by dkl »

Ok, fine, I've extracted gcc.exe/cc1.exe from the MinGW-w64 toolchain package and uploaded them as gcc-4.9.1-for-FB-win32-gengcc.zip for user's convenience.
fxm
Moderator
Posts: 12577
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release soon

Post by fxm »

Thank you very much for all those who want, for example compile with -gen gcc -O 3.
To finish off, a link at http://www.freebasic.net/get and also at http://www.freebasic.net/forum/viewtopi ... =1&t=22858 would be perfect!
fxm
Moderator
Posts: 12577
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release soon

Post by fxm »

OK, thanks.
dodicat
Posts: 8270
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: New FB release soon

Post by dodicat »

There seems to be a difference (BUG??) between fb .90 and fb.91/fb1.0.

The routine is Draw.

Example:

Code: Select all


'fb < .91 -- OK
'> .91 ???
Screen 13
dim as string fill
fill="P 1,2"
dim as  string s="BM 50,50" &"C2" &"R50 D30 L50 U30" &"BM +1,1" &("X" & varptr(fill))

draw s
sleep 
Post Reply