Support ARM

[G-Rom]

PureBasic etant basé sur FASM , il est donc possible d'adapté le langage pour un support sur les processeurs de type ARM
http://arm.flatassembler.net/
Cela permettrais à PureBasic de tourné nativement sur une plateforme de type Raspeberry PI.
http://fr.wikipedia.org/wiki/Raspberry_Pi
https://www.youtube.com/watch?v=znuUm5vbSpI
https://www.youtube.com/watch?v=e_mDuJuvZjI
Si Fred est ok , je lui offre un raspberry PI.

[blendman]

Et sur les ecafe hercules (http://www.hercules.com/fr/ecafe/bdd/p/ ... tech_carac )?
Car j'en ai un et faire du purebasic sur cet ordinateur (ou les netbook de ce genre) ce serait bien classe ^^

Bon, j'imagine que ce ne sera pas possible, car c'est un linux adapté de toutes façons et c'est l'équipe qui modifie les logiciels pour qu'ils fonctionnent sur leur machine ^^.

[graph100]

juste dans la suite de G-Rom :

C'est pas possible de faire nous même un interfaçage vers le compilo fasm arm ?
du même genre que doudouvs avait fait pour compiler de linux vers windows et mac ?

[G-Rom]

Et sur les ecafe hercules (http://www.hercules.com/fr/ecafe/bdd/p/ ... tech_carac )?
Car j'en ai un et faire du purebasic sur cet ordinateur (ou les netbook de ce genre) ce serait bien classe ^^

Bon, j'imagine que ce ne sera pas possible, car c'est un linux adapté de toutes façons et c'est l'équipe qui modifie les logiciels pour qu'ils fonctionnent sur leur machine ^^.

le linux est natif , les appli aussi , ils sont juste compilé pour l'ARM tout comme le raspberry PI qui a la même architecture.
Les appli du r.PI toune sous ton eCafe. , c'est pas du x86/64 mais de l'ARM.

[Fred]

Meme si FASM supporte l'arm, il faut quand meme tout refaire pour supporter ce processeur, donc c'est un travail titanesque pour tres peu de cibles potentielles.

[Kwai chang caine]

Ce qui est sur c'est que pas mal doivent se casser le nez sur JAVA.
Ce qui est sur aussi c'est que des centaines d'applis sortent quand même chaque jours (C'est la que je me dit que y'a un paquet de tronche dans le monde )
A part quelques langages de prog qui se sont lancé (On en a parlé sur un autre post) y'a pas encore beaucoup de monde sur les starting block.

Pour ce qui est du travail gigantesque je te crois sur parole, et tu es deja bien occupé pour te lancer encore dans une aventure comme celle la

Mais pour ce qui est des cibles...si on offrait un basic comme PB à android, j'suis pas sur que y'aurait pas de clients....
Moi je pense qu'il faudrait en créer un nouveau avec une nouvelle license, ce qui permettrait de payer les personnes qui le programmeraient.

Et je pense aussi que tu aurait deja une bonne partie de ta communauté qui par solidarité ou besoin se feraient un plaisir de te la payer, ça fait deja un certain nombre de cibles ça !!!
Car elles ont bien suffit pour l'instant à faire devenir PB ce qu'il est devenu non ??.
Et puis tu as maintenant l'experience de PB, plein de choses qui pourraient peut etre te servir de l'un à l'autre, donc à ne pas coder du debut (Enfin j'y connais pas grand chose, mais je suppose)

Faut se rendre à l'evidence, qui n'a pas un smartphone maintenant ??
Meme un ringard comme moi s'y est mis, et dans 10 ans y'aura plus que ça...
Et je trouve android trop minimaliste, y'a tellement de fonctions qu'on pourrait lui ajouter si on pouvait coder en PB dessus

Et peut etre que y'aurait un gestionnaire d'images mobiles en natif, cette fois, dans cette version

[blendman]

Je ne sais pas ce que signifie Titanesque pour Fred, mais si ça signifie au moins 2 à 4 ans, je pense que ça ne vaut pas le coup.
Car il est fort possible que d'ici là, la technologie des smartphones ait évoluée vers encore autre chose et qu'il doive tout refaire.

Il vaut mieux qu'il se concentre sur le purebasic pour PC .
un exemple récents : avec les consoles, beaucoup de petits studios s'y étaient engouffrés (surtout sur la Xbox grâce au XNA/C#) et beaucoup sont revenu au PC (win, linux, mac), où les gamers restent.
Avec XNA, y'a eu beaucoup de jeux pourris qui sont sortis, c'était une bonne idée, mais beaucoup d'amateurs ont exploités le filon et du coup, la qualité des jeux s'en est ressentie.

[Backup]

Faut se rendre à l'evidence, qui n'a pas un smartphone maintenant ??

moi ! (il en fallait un )
toujours pas de telephone portable ... (et cela ne m’intéresse meme pas)

[G-Rom]

Meme si FASM supporte l'arm, il faut quand meme tout refaire pour supporter ce processeur, donc c'est un travail titanesque pour tres peu de cibles potentielles.

Si ton compilateur est bien pensé , il n'y a que la partie arrière à faire, la partie avant ne bouge pas. mais comme tu le dis , c'est du boulot ^^

Il vaut mieux qu'il se concentre sur le purebasic pour PC

Et qu'il abandonne toutes les libs externe , sprite , window , gadget , etc... , il passe tout en opensource ( uniquement les lib externe )
Trop de maintenance pour une si petite équipe, et il se recentre uniquement sur le compilateur
L'arm est en plein boom , les hoobystes comme moi cherche des solutions pour programmé leurs puces électronique.
des solutions existe déjà , j'ai même écrit un compilateur qui fonctionne en ASM pour les puces à base de PIC de microchip.
Le faire en PB serait le must , et les cibles , y 'en a un paquet , c'est une erreur de les marginaliser.
Imaginé un R2D2 codé en purebasic , une tondeuze automatique en PB , domotique de la maison, etc...
bref , tout un tas d'application possible

[stombretrooper]

C'est vraiment une chose qui serait géniale, mais je comprends pourquoi Fred ne veut pas le faire, le problème vient des librairies à re-coder / re-adapter pour ARM (d'ailleurs à mon avis certaines librairies sont très dur à adapter). La solution la plus simple, mais faut du temps, serait de nous lancer nous même dans l'écriture d'un compilateur purebasic dédié à ARM (Si Fred nous autorise à garder la même syntaxe / liste de librairie).

[G-Rom]

C'est vraiment une chose qui serait géniale, mais je comprends pourquoi Fred ne veut pas le faire, le problème vient des librairies à re-coder / re-adapter pour ARM (d'ailleurs à mon avis certaines librairies sont très dur à adapter). La solution la plus simple, mais faut du temps, serait de nous lancer nous même dans l'écriture d'un compilateur purebasic dédié à ARM (Si Fred nous autorise à garder la même syntaxe / liste de librairie).

d'ou mon idée d'abandonner dans l'opensource toutes les librairies externe , et ce centré sur le compilateur. facilité l’intégration de librairie externe codé en C
suffirait à voir des wrapp poussé , c'est pas les lib en C qui manque & un wrapp est facile à mettre en place.

[Micoute]

Faut se rendre à l'evidence, qui n'a pas un smartphone maintenant ??

moi ! (il en fallait un )
toujours pas de telephone portable ... (et cela ne m’intéresse meme pas)

et avec moi, ça fait au moins deux

[blendman]

et avec moi, ça fait au moins deux

Moi non plus, j'ai pas de smartphone, ça fait trois !

En plus, quand on voit que le ministère de l'intérieur et de l'armée a conseillé à ses employés de ne plus utiliser de smartphone, à cause de l'espionnage, moi, ça ne me donne pas trop envie ^^.

d'ou mon idée d'abandonner dans l'opensource toutes les librairies externe , et se centrer sur le compilateur. faciliter l’intégration de librairie externe codé en C suffirait à voir des wrapp poussé , c'est pas les lib en C qui manque & un wrapp est facile à mettre en place.

ça pourrait être une idée effectivement.
Peut être en commençant par mettre à disposition de certains devs une lib ou deux (les plus petites ou les plus simples), pour voir ce que ça donnerait ^^.

[SPH]

Faut se rendre à l'evidence, qui n'a pas un smartphone maintenant ??

moi ! (il en fallait un )
toujours pas de telephone portable ... (et cela ne m’intéresse meme pas)

+1

[stombretrooper]

Pour ceux qui ont pas de smartphone, je tiens quand même à vous dire :
1) 40% des français ont un smartphone, augmentation de 27% en 6 mois (Source: internet marketing 2013).
2) ARM c'est smartphone, mais c'est aussi les tablettes, c'est aussi des cartes électroniques. Des cartes utilisés à pas mal d'endroit, et qu'on peut utiliser pour faire de la robotique, ou autre...

d'ou mon idée d'abandonner dans l'opensource toutes les librairies externe , et ce centré sur le compilateur. facilité l’intégration de librairie externe codé en C
suffirait à voir des wrapp poussé , c'est pas les lib en C qui manque & un wrapp est facile à mettre en place.

On risque de voir apparaître des codes marchant sur une certaines versions de certaines libs, un des avantages de purebasic se sont ces libs pré installé, sans compter qu'on risque d'avoir des procédures apparaître ne respectant pas la même convention de nommage, ect...

Puis, je penses que le gros du taff de Fred (et de l'équipe purebasic), c'est le développement des libs. Et donc, sa m'étonnerait que Fred abandonne dans l'opensource les librairies de purebasic.