LLVM

[Thorium]

For the true development platform, it would be possible to rely on QT (http://qt.nokia.com/) that exists on (linux, mac osx, Windows Mobile, Windows CE, Symbian, maemo, Meego)

Relying on 3rd party libs is allways bad in my opinion. PB does allready use some 3rd party libs but only for secondary stuff. If you use them for primary stuff there are to much problems than can turn up and you just cant do anything against it because it's not your code.

Actualy some projects moving away from Qt, like BSNES (a SNES emulator) because of some bugs.

[Coolman]

For the true development platform, it would be possible to rely on QT (http://qt.nokia.com/) that exists on (linux, mac osx, Windows Mobile, Windows CE, Symbian, maemo, Meego)

Relying on 3rd party libs is allways bad in my opinion. PB does allready use some 3rd party libs but only for secondary stuff. If you use them for primary stuff there are to much problems than can turn up and you just cant do anything against it because it's not your code.

Actualy some projects moving away from Qt, like BSNES (a SNES emulator) because of some bugs.

QT est utilisés dans de nombreux projets majeurs dont KDE l'interface graphique pour linux, il n'y a qu'a lire la newletters (voir ici : http://doc.trolltech.com/qq/) pour comprendre que nokia veut a long terme en faire une solution multiplateforme majeure et stable, pour le reste le choix est simple a mon avis :

1/ faire evoluer purebasic dans ce sens, c'est faciliter le developpement multiplateforme puisque le code sera le meme, et c'est l'assurance d'avoir une communauté de developpeurs tres importante et rentabiliser largement le travail de l'auteur..

2/ ou continuer comme maintenant et dans ce cas je doutes que l'auteur puisse a long terme maintenir une telle cadence en gerant un code different pour trois plateformes (windows, mac et linux) avec une diffusion limité et surement pas satisfaisante niveau financier...


***********************************

QT is used in many major projects including KDE GUI for linux, there's newletters read (see here: http://doc.trolltech.com/qq/) to understand that Nokia wants long-term solution to a major and stable platform for the rest the choice is simple in my opinion:

1 / purebasic to evolve in this direction is to facilitate the development platform since the code will be the same, and is the assurance of having a community of developers very important and profitable largely the work of the author ..

2 / or continue as now and in this case I doubt that the author could maintain a long-term rate in such a code manager for three different platforms (windows, mac and linux) with a diffusion limited and certainly not satisfactory financial. ..

[the.weavster]

For the true development platform, it would be possible to rely on QT (http://qt.nokia.com/) that exists on (linux, mac osx, Windows Mobile, Windows CE, Symbian, maemo, Meego)

On top of this a developer named BogDan Vatra has ported Qt to Android and is now working on a port to Samsung's Bada.

But Qt now has Qt Quick which enables you to utilise the Qt framework using JavaScript, you just create a stub application in C++. If you encounter a bottleneck you can also mix and match with C++ too.

Here's a simple 'hello world':

Code: Select all

import QtQuick 1.0

 Rectangle {
     id: myRectangle
     width: 500
     height: 400

     Text {
         text: "Hello world!"
         color: "#002288"
         x: 100; y: 100
     }

     Image {
         source: "images/qt-logo.svg"
         x: 100; y: 150
         width: 150; height: 150
     }

     color: "lightgray"
 }

I don't know how much work it would be for Fred / Freak to adapt PB to target Qt but I do wonder how much benefit they'd get from that time when cross-platform programming with Qt is already so easy.

[Trond]

Every PB developer who wanted to develop commercial applications would have to pay royalties to QT, then. And it's expensive (nearly 3000 euros for a single developer on a single OS).

[the.weavster]

Every PB developer who wanted to develop commercial applications would have to pay royalties to QT, then.

From 4.5 onwards Qt has been available under the LGPL.

[idle]

I'm currently trying to come to grips with llvm c interface, though I'm stumped
at the moment trying to work out why this code isn't working.
Being Dyslexic I often can't see the wood from the trees, so does anything in this llvm code strike you as being wrong?

Regardless of what Argx is the output from the function always returns two
which suggests that the loop is only executing once.

Code: Select all

define fastcc i32 @fib2(i32 %ArgX) {
EntryBlock:
  %A = alloca i32
  %B = alloca i32
  %C = alloca i32
  %D = alloca i32
  store i32 1, i32* %A
  store i32 1, i32* %B
  store i32 0, i32* %C
  store i32 %ArgX, i32* %D                      ;save argX into D
  %cond = icmp sle i32 %ArgX, 2              ; argx <= 2
  br i1 %cond, label %IF, label %Else         ; branch IF otherwise Else  

IF:                                               
  ret i32 1

Else:                                             
  %PD = load i32* %D                     ;load D into register PD 
  %cond1 = icmp sgt i32 %PD, 2       ;register PD > 2 
  br i1 %cond1, label %while, label %ewhile    ;Branch while otherwise Ewhile

while:                                            
  %pA = load i32* %A
  %pB = load i32* %B
  %addab = add i32 %pA, %pB
  store i32 %addab, i32* %C
  store i32 %pA, i32* %B
  store i32 %addab, i32* %A
  %sub = sub i32 %PD, 1                   ;PD -1 
  store i32 %sub, i32* %D                  ;save Sub result into D
  br label %Else                                ;branch Else 

ewhile:                                           
  %CR = load i32* %C      ;load C into register CR 
  ret i32 %CR                  ;Procedure return CR
}

PB function

Code: Select all

Procedure fibPB2(argx.i)
  Protected a,b,c
  If argx <= 2
    ProcedureReturn 1
  Else 
    a = 1
    b = 1
    While argx > 2
      c = a + b;
      b = a;
      a = c;
      argx-1;
    Wend
    ProcedureReturn c
 EndIf    
EndProcedure

[idle]

Turns out the was nothing wrong with the IR, just some odd bug in LLVM itself.