Vitesse et Précipitation...

Je lis depuis quelques jours les posts des uns et des autres
et, je vois que tout le monde se projette sur une version 64 bits
dont on a vu qu'un aperçu.

J'ai peur que, pour gagner du temps, cela finisse par être de précipitation...

On ne connait pas grand chose de la version que veut mettre en place Jack.
Si cela se trouve, cette version apportera des solutions à certains problèmes évoqués
voir d' autres qui sont en cours de résolution sur la version 32 bits....

D' autre part j'avoue que je suis un peu perdu.
Entre Panoramic, KGF, 32, 64 bits...et deux mois sans avoir pondu un programme
ni même pu suivre les évolutions....

ygeronimi, ne t'inquiète pas. Klaus se prépare juste par ce que ça lui plait et il pousse même beaucoup plus loin.
Perso, je n'ai pas le temps et je n'ai pas trop l'envi pour les tests des versions 64 et des scripts, mais ça ne retire rien au fait que ce qu'il fait est superbe et qu'il ait le droit de se préparer et de faire ses recherches. C'est beau, je trouve d'avoir envie de faire un truc, de s'en donner les moyens et d'essayer de le faire. Dans son cas, c'est encore plus beau puisqu'il y arrive.
Donc juste ne t'inquiète pas et si ça te dépasse ou si tu n'en n'a pas le temps comme moi, laisse juste passer ce sujet et fait ce qui te plait en Panoramic puis tiens nous au courant de ta propre création en Panoramic standard

Jicehel a écrit:

...fait ce qui te plait en Panoramic ...

Quoi d'autre, hein? , et ben rien, Jicehel résume dans cette phrase ce qu'il faut retenir.

Panoramic nous sert à programmer nos petits délires avec ou sans SUB, en 32 ou 64 bits (bref comme on veut) c'est pas utile de ce prendre la tête pour rien.
Panoramic offre l'avantage de satisfaire à des Pro mais aussi à des novices.
Personnellement je suis super content de voir que Panoramic évolue et prépare son avenir et je ne suis pas inquiet parce ce que je suis libre de rester à n'importe quelle version et de me hâter lentement à des niveaux supérieurs .

Moralité: N'accuse pas Panoramic de ne pas répondre à des problèmes qui ne le concerne pas. Cherche ailleurs les motifs de ton mal être.

A+

Exact, en fait Ygeronimi, tu es juste en panne d'idée
Une petite idée de programme et tu iras mieux en fait

Citation :

ygeronimi, ne t'inquiète pas. Klaus se prépare juste par ce que ça lui plait et il pousse même beaucoup plus loin.

Jicehel a parfaitement raison. Pour l'avoir écrit, je sais quel travail représente KGF.dll (plus de 10.000 lignes de Delphi 6...). Si si demain, Jack sort une vraie version 64 bits, je vais ramer beaucoup pour rester à la page.

C'est pourquoi j'ai chercher en urgence les moyens techniques de pouvoir suivre, je jour J. Et, entre autres grâce à l'aide au diagnostic de Cosmos70, j'ai trouvé l'outil et mis au point les méthodes qui permettent la migration. Et celle-ci se poursuit maintenant serainement, jusqu'à son terme. Et Jack évoque Androïd ? Eh bien, je serai prêt, grâce à ces moyens mis en place.

Je redoutais le passage à 64 bits depuis longtemps. C'est le cours de l'histoire, et je sais bien qu'avec mon XP, je fais figure de dinosaure (bon, de Cro-magnon peut-être). Il y avait déjà un XP 64 bits, puis Vista, W7 et maintenant W8 - la version 64 bits est inévitable. Et je suis heureux de constater que Jack a choisi de prendre le problème à bras le corps. Il est normal que pour le moment, ce ne soit pas encore bien clair et bien défini. Beaucoup de questions se posent à l'occasion de cette migration. Et il convient de faire des essais dans tous les sens pour repérer les possibilités et les contraintes, afin de choisir au final une solution viable. Jack semble le faire, et je ne fais pas autre chose.

Ne crains rien: pour ma part, je garderai toujours une version 32 bits (ne serait-ce que pour moi avec mon XP). Seulement, à terme, ce ne sera plus en Delphi 6, mais entièrement en Lazarus/FreePascal, et je pourrai ainsi assurer la migration vers n'importe quel système. Mais pour celui qui programme en Panoramic, cela restera totalement transparent: il y aura toujours KGF.dll avec exactement les mêmes fonctions, fonctionnalités et syntaxe d'appel.

Voilà. Tu y vois un peu plus clair, maintenant, dans toute cette jungle de versions différentes ?

Salut tout le monde.

La prudence (ou la crainte) des uns et le désir d’aller de l’avant (ou d’explorer l’inconnu) des autres, tout ça c’est beau !
On ne doit pas avoir peur de l’évolution des choses car, à mon sens, l’évolution est une propriété des choses.
Je pense que Klaus éprouve un immense plaisir pour l’inconnu qu’il explore !

Il faut se préparer mentalement et se dire que si quelqu’un a pu inventer une chose, je saurais au moins l’utiliser.
Heureusement, on possède tous la faculté de s’adapter aux différents environnements : le tout c’est de rester optimiste.

Jicehel a écrit:

Exact, en fait Ygeronimi, tu es juste en panne d'idée
Une petite idée de programme et tu iras mieux en fait

Moi aussi je passe par une panne d’idée : la preuve, regardez mes inutilitaires. Je n’ai rien trouvé de mieux à faire !
Ça passera, ça passera !

Salut tout le monde !

Que de touches ai je fait martyriser par vos doigts.....


Je ne critique pas, je ne condamne pas mais je me pose seulement des questions.
Chacun a bien le droit de faire ce qui lui plait ,et bien heureux....
...puisque nous sommes dans le monde "Libre".

LA PANNE d'idée c'est bien mon problème du moment mais
plus que çà encore, je n'arrive plus à mettre en forme le peu d'idée que j'ai.
Pire, la coupure d' un peu plus d'un mois m'a fait perdre la structuration d'un source
que je m'étais imposé....
"...Alzheimer quand tu nous tiens... "


Voilà,voilà, je ne veux surtout pas que l'on pense que c'était une attaque hargneuse de ma part
mais simplement une réflexion personnelle dont je vous faisais part.

Salut Ygeronimi,

Citation :

Voilà,voilà, je ne veux surtout pas que l'on pense que c'était une attaque hargneuse de ma part
mais simplement une réflexion personnelle dont je vous faisais part.

En relisant le sujet, je me rend compte que la moralité que j'ai écrite n'est pas sympa, et je m'en excuse. Seul mon message est valable.

Je vais donc (pas effacer: pour la compréhension) rayé cette connerie.

A+

Si ça peut te rassurer ygeronimi, la future version 64 bits ne me traumatise pas du tout, je suis tout ça d'un oeil distrait dans la mesure où j'ai à peu près tout ce qu'il me faut dans la version 32 bits (qui tourne très bien sur mon pc W7 64 bits), que jusqu'à nouvel ordre je ne suis pas bloqué par manque de possibilités et donc je n'éprouve à présent aucun besoin d'extension, sauf peut-être quelques fonctions nouvelles dans la version actuelle, mais qu'on peut contourner par des artifices qui contribuent au plaisir de la programmation.

J'espère simplement, mais Jack l'a promis, que la version actuelle 32 bits continuera d'évoluer en parallèle avec la future, et a priori ça me suffit largement.

Je ne dis pas qu'un jour il ne faudra pas y passer (pas sûr), mais à mon avis c'est un jour assez lointain et on verra à ce moment-là !
En attendant je continue dans la routine actuelle, où j'ai largement suffisamment de ressources pour faire ce que j'ai envie de faire.

(il est vrai que je ne fais pas de 3d, et c'est peut-être là, et seulement là, que l'évolution devient intéressante)

Tout à fait JL35,
c'est bien ainsi que je vois les choses.
A+

+1, je suis bien content que Jack pense à l'avenir et le prépare et en attendant je continue à suivre la vie de Panoramic et de sa sympathique petite communauté

+1 pour ce que vous venez tous de dire !

Bonsoir,
Ce n'est pas le fait du passage 32 bits en 64 bits qui va être la révolution... (bien que cela ouvre plus de possibilité à Jack en ce qui concerne la 3D)

C'est lorsque Jack aura mis en place les fonctions et une compilation réelle des sources Panoramic. Là, cela sera une réelle révolution.

Pour l'instant, je préfère attendre plutôt que de me lancer la-dedans tête baissé...
on ne sait même pas encore si Jack va créer des types de variables spécifiques au 64 bits...

Wait & See...

C'est la sagesse même !

Je ne suis pas à la place de Jack. Mais je pense que lorsqu'il aura mené sa réflexion à son terme, il y aura deux options:
1. rester avec Panoramic tel qu'il est, en environnement 32 bits.
2. créer une version authentique 64 bits (tout en laissant bien sûr la version 32 bits telle qu'elle est), avec utilisation des données natives en 64 bits.

Le problème est d'ailleurs bien plus vaste que la simple longueur d'une variable. Il faut également considérer le passage en Unicode, et pour le moins en UTF8. Et ce n'est pas une mince affaire. Cela a une énorme incidence pour tout ce qui est traitement de chaînes de caractères, affichage de textes dans les objets, etc.

Il est clair que dès aujourd'hui, W7 est en 64 bits avec un mode d'émulation 32 bits (nommé WOW - Windows on Windows), avec la duplication de quasiment tous les modules Windows puisque le mixage est techniquement impossible.

Et le problème est encore plus actuel avec W8. Il est clair qu'à terme, le 64 bits deviendra la norme, et le 32 bits sera de plus en plus marginalisé, un peu comme les applications 16 bits sous XP, en mode compatible. Cela ne marchera déjà plus sous les systèmes les plus récents. Donc, je pense que si l'on veut assurer un avenir à plus long terme à Panoramic, le vrai 64 bits et l'UTF8 sont les seuls choix assurant une pérennité.

Or, dans ce cas, se pose bien sûr le problème de la compatibilité ascendante. Je sais que c'est important pour Jack, tout comme c'est rassurant pour nous. Et dans cet esprit, pour assurer une portabilité ascendante totale, il n'y a guère d'autres moyens que d'indiquer au compilateur d'une manière ou d'une autre si l'on veut travailler en mode 32 bits (émulé, cette fois) ou en mode 64 bits natif. Il y a plusieurs solutions à ce problème, et sans vouloir être exhaustif, je n'en cite que quelques-unes, à titre de piste de réflexion:

1. si rien n'est spécifié, on est automatiquement en mode 32 bits émulé, et rien ne change dans les sources existants. Conséquence: impossibilité d'utiliser la moindre DLL dont les fonctions s'attendent à des valeurs 64 bits, comme des handle ou adresses.

Mais dans ce cas, on pourrait définit une option de configuration du compilateur qui indiquerait le mode (32 bits émulé par défaut, ou 64 bits natifs). Et dans ce cas, en choisissant le mode 64 bits natif dans les options du compilateur, on traiterait le même source existant avec des types de données natives en 64 bits, et tout redevient possible.

Les fonctions de Panoramic (left(), rnd(), etc) retourneront une valeur flottante dans le format spécifié par la variable de configuration. Seuls les fonctions adr(), handle() et handle_form() doivent impérativement retourner une valeur 64 bits, car ces fonctions n'ont aucun sens en 32 bits ( je rappelle que je parle ici d'une implémentation de Panoramic en mode 64 bits, et non de la version de 2 bits qui doit continuer à exister comme actuellement !).

2. Définir une extension des commandes DIM et DIM_LOCAL, en spécifiant la "taille" après la définition actuelle, un peu de cette manière:

Code:

DIM nombre%, prix : ' créés en mode 32 bits émulés
DIM hnd%, adresse%, prix_total AS WIDE : ' créés en mode 64 bits natifs

On aurait ainsi facilement les deux types de données simultanément dans un programme. Conséquence: les anciens sources tourneront sans problème tels quels, et ceux qui utilisent les DLLs avec passage d'adresses et handles devront être modifiés en ajoutant "AS WIDE" derrière les déclarations de ces variables.

3. définir une directive du genre #BIT_32 et #BIT_64 pour passer globalement le compilateur d'un mode à un autre (#BIT_32 étant le défaut). Mêmes réflexions que pour le point (1).

4. définir de nouvelles commandes WIDE_ON et WIDE_OFF qui basculent le sens des commandes DIM d'un mode à un autre. Ceci est similaire à la proposition (3), mais agit de façon dynamique, comme dans cet exemple:

Code:

DIM i%, prix
WIDE_ON : DIM hnd%, adresse% : WIDE_OFF
DIM N%

Seules les variables hnd% et adresse% seront en 64 bits.

Quoi qu'il en soit, un choix devra être fait. Il n'est pas pensable de laisser cohabiter de façon implicite, des données en 32 bits et des données en 64 bits J'ai personnellement un penchant pour la proposition (1) car elle ne change strictement rien au niveau des sources existants et donne toute latitude pour les développements futurs.

Et, bien sûr, il faudrait aussi que cette façon de spécifier la version "large" s'applique également qu codage des chaînes de caractères: ancienne version (par défaut) en codage 8 bits par caractère, et nouvelle version (large, AS WIDE) en codage UTF8. dans ce codage, il n'y a plus de correspondance directe entre nombre d'octets et nombre de caractères, car un caractère peut être codé sur 1, 2, 3 ou 4 octets ! C'est un virage important à prendre, et il devrait être mené en même temps que le passage en 64 bits.

Juste pour info: Lazarus et FreePascal ont pris ce chemin et peuvent générer du code nativement en 64 bits avec des textes en UTF8. C'est pourquoi j'ai choisi Lazarus pour transposer mes DLLs réalisés en Delphi 6 qui lui, ne pourra pas suivre cette évolution, et qui sera donc abandonné.

Amen !