New FB release coming up

For other topics related to the FreeBASIC project or its community.
gothon
Posts: 224
Joined: Apr 11, 2011 22:22

Re: New FB release coming up

Postby gothon » May 04, 2013 19:56

dkl wrote:Seeing how the changes to lbound/ubound on uninitialized arrays could break a lot of code doing @array(lbound(array)) <> NULL to check whether the array is "uninitialized", perhaps they should be reverted. Then we'd have to declare @array(lbound(array)) <> NULL as the way to check for uninitialized arrays though, instead of a check like ubound() < lbound(). An alternative is to use lbound=0 ubound=-1 instead of lbound=1 ubound=0. That can also break code, though I'd expect it to break less code.


Personally I'm in favor of lbound=0 ubound=-1, because of my desire to write loops that work with empty arrays of the form:

Code: Select all

ReDim Array(N - 1)
' Iterate over all elements
For I As Integer = 0 To UBound(Array)
    'Do something with Array(I)
Next I

However, I understand if there is concern over breaking code. Presently, I often use a dummy element at position 0 so that I can use ubound = 0 to represent an empty state even though its not really empty.

Code: Select all

ReDim Array(N) 'Array(0) is an unused dummy element
For I As Integer = 1 To UBound(Array)
    'Do something with Array(I)
Next I
Last edited by gothon on May 04, 2013 20:31, edited 1 time in total.
fxm
Posts: 9309
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: New FB release coming up

Postby fxm » May 04, 2013 20:30

About uninitialized arrays:

IMHO, while Ubound = Lbound - 1, the exact values are indifferent to me because I often use a principle as following:

Code: Select all

Dim As String array()

Do
  Dim As String s
  Input s
  If s = "" Then
    Exit Do
  End If
  Redim Preserve array(Lbound(array) To Ubound(array) + 1)
  array(Ubound(array)) = s
Loop

Print
For I As Integer = Lbound(array) To Ubound(array)
  Print "'" & array(I) & "'"
Next I

Sleep

Code: Select all

? item 1
? item 2
? item 3
? item 4
?

'item 1'
'item 2'
'item 3'
'item 4'
TJF
Posts: 3486
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: New FB release coming up

Postby TJF » May 05, 2013 8:30

dkl wrote:Seeing how the changes to lbound/ubound on uninitialized arrays could break a lot of code doing @array(lbound(array)) <> NULL to check whether the array is "uninitialized", perhaps they should be reverted. Then we'd have to declare @array(lbound(array)) <> NULL as the way to check for uninitialized arrays though, instead of a check like ubound() < lbound(). An alternative is to use lbound=0 ubound=-1 instead of lbound=1 ubound=0. That can also break code, though I'd expect it to break less code.

I prefer lbound=0 ubound=-1

dkl wrote:I can understand the wish for having external libraries in separate download packages. Maybe it's time we develop a downloader app for that. I can work on that, and we can use fbc's Sourceforge download area to host the downloads, and fbc's Git repo as version control system for the headers and build scripts (if any). If someone is ready to make a website for external libraries, I could live with that too.

I think using fbc's Sourceforge download area is a good idea. Or creating a new area for extensions, separated from the compiler. Sorry, I'm not keen on creating such an area, but I'm ready to maintain some libraries.

On the German webside there's the FBCC (FreeBasic Coding Competition). Why not making the downloader app the target of FBCC#6?
lassar
Posts: 300
Joined: Jan 17, 2006 1:35
Contact:

Re: Will the dos getkey be fixed ?

Postby lassar » May 06, 2013 20:13

Will the dos getkey be fixed ?
counting_pine
Site Admin
Posts: 6174
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: New FB release coming up

Postby counting_pine » May 07, 2013 2:54

According to viewtopic.php?f=4&t=21115&p=186571#p186571, yes.

(PS. I like 0/-1 for lbound/ubound as well.)
jdebord
Posts: 521
Joined: May 27, 2005 6:20
Location: Limoges, France
Contact:

Re: New FB release coming up

Postby jdebord » May 07, 2013 15:14

frisian wrote:When trying to compile Fbmath 0.60 by using compil.bat,
with the new FB 0.90 it gives a error messages generated by ar.exe.

A problem with the new version (0.90) that more people have is this.
Mandel.bas (Fbmath 0.60).


It seems that the new ar.exe does not accept *.o

So, I modified the file compil.bat as follows:

Code: Select all

:: Compilation of the library

:: Set path to the FreeBasic compiler:
set Fbas=c:\FreeBASIC-0.90
:: Set path to the library manager:
set Mlib=%Fbas%\bin\win32
:: without closing backslashes.

:: Set commandline:
set Cmdlin=%Fbas%\fbc.exe -c -w pedantic %%a
set Arclin=%Mlib%\ar.exe r libfbmath.a %%a

echo Compiling all FBMath library modules...

for %%a in (complex\*.bas) do %Cmdlin%
for %%a in (complex\*.o) do %Arclin%
del complex\*.o > nul

for %%a in (curfit\*.bas) do %Cmdlin%
for %%a in (curfit\*.o) do %Arclin%
del curfit\*.o > nul

for %%a in (equation\*.bas) do %Cmdlin%
for %%a in (equation\*.o) do %Arclin%
del equation\*.o > nul

for %%a in (eval\*.bas) do %Cmdlin%
for %%a in (eval\*.o) do %Arclin%
del eval\*.o > nul

for %%a in (fmath\*.bas) do %Cmdlin%
for %%a in (fmath\*.o) do %Arclin%
del fmath\*.o > nul

for %%a in (fourier\*.bas) do %Cmdlin%
for %%a in (fourier\*.o) do %Arclin%
del fourier\*.o > nul

for %%a in (integral\*.bas) do %Cmdlin%
for %%a in (integral\*.o) do %Arclin%
del integral\*.o > nul

for %%a in (largeint\*.bas) do %Cmdlin%
for %%a in (largeint\*.o) do %Arclin%
del largeint\*.o > nul

for %%a in (matrices\*.bas) do %Cmdlin%
for %%a in (matrices\*.o) do %Arclin%
del matrices\*.o > nul

for %%a in (optim\*.bas) do %Cmdlin%
for %%a in (optim\*.o) do %Arclin%
del optim\*.o > nul

for %%a in (plot\*.bas) do %Cmdlin%
for %%a in (plot\*.o) do %Arclin%
del plot\*.o > nul

for %%a in (polynom\*.bas) do %Cmdlin%
for %%a in (polynom\*.o) do %Arclin%
del polynom\*.o > nul

for %%a in (proba\*.bas) do %Cmdlin%
for %%a in (proba\*.o) do %Arclin%
del proba\*.o > nul

for %%a in (random\*.bas) do %Cmdlin%
for %%a in (random\*.o) do %Arclin%
del random\*.o > nul

for %%a in (stat\*.bas) do %Cmdlin%
for %%a in (stat\*.o) do %Arclin%
del stat\*.o > nul

for %%a in (strings\*.bas) do %Cmdlin%
for %%a in (strings\*.o) do %Arclin%
del strings\*.o > nul

move libfbmath.a ..\

cd ..

dir *.a


You will have also to modify the file modules\polynom\polyutil.bas by replacing the two lines:

Code: Select all

  IF Nr > 0 THEN REDIM R(1 TO Nr) AS DOUBLE
  IF Nc > 0 THEN REDIM C(1 TO Nc) AS Complex


with:

Code: Select all

  DIM R(1 TO Nr) AS DOUBLE
  DIM C(1 TO Nc) AS Complex


Now all demo programs (including mandel.bas) compile well.
Pritchard
Posts: 5492
Joined: Sep 12, 2005 20:06
Location: Ohio, USA

Re: New FB release coming up

Postby Pritchard » May 07, 2013 15:34

My vote is for 0/-1 for lbound/ubound. It's consistent with BASIC conventions.
Amundo
Posts: 57
Joined: Feb 26, 2007 0:25

Re: New FB release coming up

Postby Amundo » May 08, 2013 1:21

Hi dkl,

Just wanted to say thanks to you and all others concerned, for continuing to develop FB.
pestery
Posts: 493
Joined: Jun 16, 2007 2:00
Location: Australia

Re: New FB release coming up

Postby pestery » May 08, 2013 10:03

Just found a change that I'm not sure if its a change, a fix or a bug. You used to be able to check for the keyword 'This' in macros but it seems you can't any more. I'm just wondering if I have been doing it wrong until now, or if this is a bug (or a change) in the new compiler. Anyway, a quick example of what I mean.

Code: Select all

Type datatype
   As Integer value
   Declare Sub func()
End Type
#Macro a_macro(invalue)
   #If invalue = This ' Used to work but not anymore (Type mismatch error)
   '#If #invalue = "This" ' Works but is now case sensitive
   '#If LCase(#invalue) = "this" ' This just doesn't work but I expected as much
      #Print "invalue = This"
      invalue.value = 1
   #Else ' invalue assumed to be a pointer if not 'This'
      #Print "invalue <> This"
      invalue->value = 1
   #EndIf
#EndMacro

' Previously the macro would recognise 'This' but now it fails
Sub datatype.func()
   a_macro(This)
End Sub

' Just an example of the #Else side of the macro
Dim As datatype Ptr dt = New datatype
a_macro(dt)
dkl
Site Admin
Posts: 3210
Joined: Jul 28, 2005 14:45
Location: Germany

Re: New FB release coming up

Postby dkl » May 08, 2013 19:47

It's a change in what kind of expressions are allowed in #if. Previously it allowed some basic math, string literal comparisons, and in fact any a-zA-z0-9_ literal word (any declared or undeclared identifiers, including any keywords except probably DEFINED and operators since those were used in PP expressions already).

With the change, it allows any constant FB expression that is also allowed in other places plus some PP-specifics such as DEFINED(). This fixed two bugs with math expressions (the preprocessor previously used a separate and buggy expression parser and evaluator that didn't handle unsigned integer math, and float math could produce different results than in normal FB expressions). Also, it allows for constants (declared via const FOO = 123 and things like len/lbound/ubound to be used in #if expressions, as long as they can be evaluated as compile-time constants.

This means that where previously "len" was only recognized as literal word, it will now be parsed as the len() function. Where "FOO" was previouls treated as literal word, now its value will be inserted (assuming FOO was declared as a constant previously). Of course many other functions or variables cannot be accessed if they're not compile-time constants.

Even though undeclared identifiers are still treated as literal words, the behaviour for declared identifiers changed, which can clearly break code. However I think the new behaviour is much more useful and sane, and I'd like to keep it.

Edit: I think we can implement compile-time evaluation for Lcase/Ucase (and also Left/Right/Mid/String/Space perhaps) which would allow it to be used in the new #if.
pestery
Posts: 493
Joined: Jun 16, 2007 2:00
Location: Australia

Re: New FB release coming up

Postby pestery » May 09, 2013 3:43

Thanks dkl for the explanation. It sounds like the new pre-processor will be really useful and will now allow stuff that I have actually tried in the past, particularly the support for Len() considering the move toward 64bit support. Personally I'd be also very happy to have UCase()/LCase() support :-)
petan
Posts: 683
Joined: Feb 16, 2010 15:34
Location: Europe
Contact:

Re: New FB release coming up

Postby petan » May 12, 2013 10:49

Maybe more examples could to be updated due old videocard using.
For now I found+fix only one "fbgfx_opengl.bas"
Full code here http://www.freebasic.net/forum/viewtopic.php?f=3&t=21172&p=187128#p187128

Who of you guys, is remembering which FB examples needs modern HW accelerated cards, pls give me some names etc; I'll try it on my machine and fix the code for old cards.
Thx,

Pete
ike
Posts: 383
Joined: Jan 17, 2011 18:59

Re: New FB release coming up

Postby ike » May 14, 2013 23:15

new IUP version - just released with SCINTILLA edit component included!

LEXERLANGUAGE can be set to FREEBASIC

but I guess it is to late to include it?

http://www.tecgraf.puc-rio.br/iup/en/ctrl/iup_scintilla.html

It has support for annotations, and it would be quite easy to create FB editor with

code completion

http://www.scintilla.org/annotations.png
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: New FB release coming up

Postby AGS » May 15, 2013 1:34

ike wrote:new IUP version - just released with SCINTILLA edit component included!

LEXERLANGUAGE can be set to FREEBASIC

but I guess it is to late to include it?

http://www.tecgraf.puc-rio.br/iup/en/ctrl/iup_scintilla.html

It has support for annotations, and it would be quite easy to create FB editor with

code completion

http://www.scintilla.org/annotations.png


I've already posted an example in the tips and tricks section. It changes very little
to iup. There is one more .bi file with only two statements in it:

Code: Select all

/'* \file
 * \brief Scintilla control.
 *
 * See Copyright Notice in "iup.h"
 '/
 
#ifndef __IUP_SCINTILLA_H
#define __IUP_SCINTILLA_H

extern "C"

  declare sub IupScintillaOpen()
  declare function IupScintilla() as Ihandle ptr

end extern

#endif


Setting lexerlanguage to vb actually works better (in terms of folding etc...).

If you want to have the 'real' thing (a solid fb lexer) you have to write your own
lexer and add it to iupscintilla. Which would be hard to do using iup as the iup
binaries come with a pre-built version of scintilla. You'd have to recompile
the whole thing yourself (which could prove to be hard).

An idea would be is to write a fb lexer and use that. The lexer used
by Geany is a good one (it leaves something to be desired but it is scintilla based).
It just comes down to how hard it would be to add this lexer without
having to rebuild iup_scintilla.dll. Most fb editors come with a fb lexer.
I'd say pick the best one and use that.

There is, however, the issue of cross platform development.
On win32 iup works just fine. On linux.... there is the dll - hell thing (iup needs
a certain version of gtk2.x to be installed for it to work and there are other
dependencies).

Still, nice initiative by the iup developer. It's a good thing to be able to use scintilla
without having to resort to win32 api code or some wrapper around wxwidgets.
ike
Posts: 383
Joined: Jan 17, 2011 18:59

Re: New FB release coming up

Postby ike » May 15, 2013 3:25

Here is code in IUP that is doing folding in FREEBASIC
http://iup.cvs.sourceforge.net/viewvc/iup/iup/srcscintilla/lexers/LexBasic.cxx?view=markup

This module is for PureBasic, BlitzBasic and FreeBasic

line 126 is freebasic

IUP developer is nice guy, so if we find what is wrong he will fix it for sure!

That is for folding, and coloring,

but for code completion is different. That part should be done in FREEBASIC and it is not difficult because it is not full parsing BUT some kind of LINE SCANING

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest