Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
FreeBASIC v0.18.1b released
#1
Hello, this is stylin. Just posting to say that version v0.18.1b of the FreeBASIC project is out ! For those still using v0.17b, here is an excerpt from changelog.txt (included in every official distribution) with the recent modifications:

Version 0.18.1 Beta:

[changed]
- the default calling convention of variables has changed in -lang FB. UDT's (including strings) will default to BYREF, all else will default to BYVAL (cha0s)
- TYPEs with default constructor/destructors or methods had to be allowed on the module level. This affects you if you define a TYPE inside a function with any functions inside the TYPE, or any child objects that have constructors or destructors. This includes elements 'as string', since they need constructors and destructors to initialize and clean up memory (cha0s)
- ODE 0.8 headers, import library, and examples, thanks D.J.Peters, (jeffm)

[added]
- configure option for --disable-objinfo to allow building and using fbc with a broader range of binutils (jeffm)
- A third parameter to ThreadCreate, you can specify the size of the thread's stack, in bytes (cha0s)
- inc/image_compat.bi, to abstract some of the issues between new/old image formats (cha0s)

[fixed]
- #1735413 - UDT initialization would fail if the initialization expression was surrounded in parenthesis, due to the udt = (elm, elm) syntax. it will now fallback to check if the first expression encountered matches the udt type, if so, it will attempt a ctor call/assign. (cha0s)
- #1734192 - UDT initialization with unions should have been checking the first union element against the given expresssion. (cha0s)
- Mangling params taking FB arrays wasn't unique from params as the array's datatype. Recompile any libraries/linked objects taking arrays as parameters.
- ThreadCreate was accepting literally "any" pointer at its first parameter. Added a mechanism for building function pointer symbols (to check against, say the first arg passed to ThreadCreate) at the rtl symbol initializer. (cha0s)
- #1713886 - symbols in FOR had the temp bit stripped out to make scope jumping work, but it can be added in later, otherwise the branch checker will get confused (cha0s)
- #1696229(part one!) - constant symbols in TYPEs could be modified with disastrous results. (cha0s)

Version 0.18.0 Beta:

[changed]
- include file and import library for libcurl 7.15.4 (jeffm)
- #1723533 - MK* had to be reverted, it will not evaluate constant numeric expressions to constant literal expressions anymore (it will behave like it used to), because of the NULL-terminated nature of literal strings, sorry (CV* still evaluates to constants(arguably much more important ) (cha0s)
- the overload resolution wasn't normalizing the total sum of its matching args (cha0s)
- gfxlib creates its windows with THREAD_PRIORITY_ABOVE_NORMAL again, without it was jerky (cha0s)

[added]
- include file and import library for LZO 2.02 (DrV)
- literal conversion overflow warnings (cha0s)
- SETMOUSE now has a 4th parameter, clip, which allows restricting the mouse pointer to the graphics window; GETMOUSE now has a 5th parameter, clip, to retrieve the current mouse clipping status
IMPORTANT: this is a binary incompatible change - you must recompile any code that uses SETMOUSE or GETMOUSE (DrV)
- a vararg procedure can now be defined in a TYPE, it has to be unique (cha0s)
- a second STEP in PUT, see the wiki for details (cha0s)

[fixed]
- the #include once and #pragma once PP directives weren't fully solving the paths of their include files (cha0s)
- overloaded property resolution was failing (cha0s)
- nehe/data/font.tga was missing half the characters (jeffm)
- #1716570 - bit positions of bitfields shouldn't advance in a UNION (jeffm)
- PUT would crash with a null pointer for a source (cha0s)
- TYPEOF would crash when handling an array with an index expression (cha0s)
- #1696394 - default colors for GFX primitives were being set using the wrong target bpp (jeffm)
- #1711210 - there was a deadlock when an app ended when the screen was locked (cha0s)
- #1726019 - converting a constant floating-point to an unsigned integer was incorrect (cha0s)
- #1680718 - local variables were being allowed with static and shared initializers (jeffm)
- the 'elements' arg on get/put wasn't being checked for validity, causing internal width multiplication to fail on all but numeric types(cha0s)
- "as ANY" as being allowed on TYPE members(cha0s)
- bogus field accesses should have been creating a fake symbol (cha0s)
- gfxlib wasn't waiting long enough when preventing a potential deadlock, causing deinitialization to fail (and crappy graphics consequences) (cha0s)

Testers are always welcome, particularly those interested in QuickBASIC/QBasic code-compatibility using the "QB" language dialect (enabled with the "-lang qb" compiler switch, introduced in v0.17b). Here are some links in the FBWiki that describe the differences between the "QB" and "FB" (default) language dialects:

FreeBASIC language dialects:
http://www.freebasic.net/wiki/wikka.php?...erDialects
FreeBASIC and QuickBASIC/QBasic differences:
http://www.freebasic.net/wiki/wikka.php?wakka=LangQB

If you are testing the "QB" language dialect, perhaps by trying to compile existing QuickBASIC/QBasic sources, find problems and would like to help, please read this FBWiki page:
http://www.freebasic.net/wiki/wikka.php?...ortingBugs
If a specific problem or bug isn't already addressed in the FBWiki pages, official forums, or on the sourceforge trackers, please submit a bug report, feature request or patch. For bug reports or feature requests, be sure to narrow the problem, bug or feature down in as few lines as possible to reproduce it, including the expected and actual results.

Search the official FreeBASIC forums here:
http://www.freebasic.net/forum/

Search for and/or post a bug report, feature request or patch here:
http://sourceforge.net/tracker/?group_id=122342

Remember that only a handful of developers make up the FreeBASIC development team, and they can only fix or add things that they know about. So if you're interested in helping out with QuickBASIC/QBasic code-compatibility or anything else, your contributions are appreciated and help immensely. Thanks, and happy hacking!
stylin:
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)