Diverses propositions

Je pense également que le jour où Panoramic offrira la possibilité de créer les fonctions, ce genre de proposition (RINSTR) n'aura plus lieu d'être...

Ce que l'on pourrait très bien envisager: Une rubrique "librairies officielles" regroupant des fonctions de base écrites en Panoramic. (reste à savoir qui veut bien se coller à la partie admin... Jack ?)

Je suis d'accord sur ce point avec jpcr, quand les fct seront possibles cela enlèvera du boulot à Jack mais pas tout...
des objets/fonctions comme RICH_EDIT ou LPRINT, ne sont pas encore réalisables en Panoramic (en encore, pour LPRINT, avec la DLL de Klaus, en grattant un peu, on doit pouvoir faire quelque chose...)

D'un autre côté, des fonctions comme BIN$()/ BIN() peuvent être très facilement réalisées en Panoramic...

@Jecehel : Je pense que ce que voulait dire jpcr ce n'est pas que telles ou telles fonctions soient inutiles mais plutôt qu'il n'est pas forcement nécessaire de les coder "en dur"... surtout que plus on rajoute des fonctions natives, plus Panoramic risque d'être lent, plus il risque d'y avoir des bugs...

oui Nardo , tu as parfaitement compris mon propos.

Jicehel, désolé si je n'ai pas été clair mais je maintiens qu'ajouter sans cesse des fonctions a Pano ne va pas forcement dans le bon sens, c'est un langage de programmation (en admettant que nous ayons les sub/fonctions) il revient aussi aux utilisateurs/programmeurs(nous ) de l'étendre sans alourdir son noyau et de diffuser leur ajout dans ces librairies proposées par Nardo.

les deux solutions sont bonnes(dans Pano ou a l’extérieur) , je pense surtout a Jack qui doit s'arracher les cheveux tellement on lui en rajoute toutes les semaines.

jp

La dessus, je n'intervient plus, c'est vraiment un choix qui revient à Jack, il nous dira dans quel sens il veut aller à ce moment là.

J'avais pas envie de répondre à tout cela, et il y a du vrai dans les deux cas.
C'est vrai que RINSTR() n'est pas indispensable. Au contraire de vous, je ne parle pas d'instruction pour soulager le programmeur, mais d'instruction qui évite du temps perdu par des lignes de codage. Lorsqu'il faut plusieurs instructions pour en faire une, cela ralenti l'exécution. Si une instruction est visitée dans un programme, ça ne me dérange pas de faire quelles lignes de plus pour qu'elle se réalise. Mais lorsqu'on est dans une boucle, et quelle est longue, là ça ralenti sec. L'instruction RINSTR est une instruction de base en basic, et il est même dommage qu'on n'ait pas la syntaxe complète avec le déplacement possible par rapport au marqueur précédent, je veux dire par là: INSTR(chaine,marqueur,saut).
Coder ne me gène pas, d'ailleurs avec tous les trucs que j'ai trouvé pour compenser les manques (et je crois en avoir trouvé quelque'uns) le prouve. Seul pour moi compte l'exécution. Si faire d'avantage d'instruction dans le module basic perd un peu en rapidité, le basic étant de haut niveau, compenser par une tonne de code de remplacement, le temps d'exécution n'a plus rien à voir.
J'essaye de faire des programmes qui tiennent la route dans l'exécution. Lorsque je constate, qu'il y a un temps de traitement trop long, je me dis que ce n'est pas valable. Pour avoir utilisé mon mon mode trace (qui d'ailleurs à une erreur à l'intérieur) avec le compteur qui s'incrémente chaque fois qu'il lit une ligne, je peux vous dire que j'ai bien changé ma façon de coder, justement pour diminuer le nombre de passe pour l'exécution d'une ligne. Un exemple, je crois que j'ai été l'un des premiers à faire du texte dans un picture, et j'avais mis une copie d'écran sur ce site (il y en a qui se souvienne puisse qu'on m'avais dis que mes carottes étaient bien chère), j'en étais arrivé à un compte de 75000lignes de lu pour afficher cette page, et mettais plus de 30 secondes pour qu'elle s'affiche. A la fin, lecture d'environ 1500 lignes, et l'affichage je crois 7 secondes.

Alors réfléchissez! Il y a la programmation, et il y a le temps.

A un moment donné, si je ne me trompe pas, Jack avait fais une version "light" de Panoramic qui ne contenait pas de module 3D...
il doit bien y avoir une raison...

Une chose serait bien,c'est de pouvoir créer des plugin en langage Panoramic dans un répertoir a part
que Panoramic relirait a chaque lancement.
Ces plugins serait considérés comme des instructions natives de panoramic.

Autant faire un include dans tes sources... ce qui reviendrai au même....

Pas du tout car l'include tu es obligé de l'écrire dans ton programme et si tu as plusieurs include de plusieurs sources ?

Je saisi pas la différence , pour moi :

"créer des plugins en langage Panoramic dans un répertoire a part que Panoramic relirait a chaque lancement."
=
"créer des plugins en langage Panoramic dans un répertoire a part que mon programme inclurai a chaque lancement."

un programme avec un #include est un programme au format text ok.
Un plug-in c'est un programme compilé a la lecture ( c'est pas tout a fais exact mais faisons court ).
L'orsque je vais utiliser une des fonctions du plugin c'est comme-ci j'utilisait une fonction de panoramic.
l'avantage ce sont les bibliotheques de différentes source que tu peu mettre dans le répertoire ( ex GIMP, BLENDER pour ne citer qu'eux.)

Un plugin en ou pour le langage panoramic ?
car j'avais cru comprendre que tu parlais de sources Panoramic mis dans un répertoire spécifique qui seraient considérés comme des plugins...

Si c'est le cas, il n'y a pas de compilation et apparemment faire de véritables exécutables, compilé et tout et tout, ce n'est pas pour tout de suite...


Quand la version de Panoramic avec possibilité d'écriture de fonctions sera sortie, tu pourras utiliser tes fonctions (qui sont dans les fichiers inclus) comme les autres fonctions natives de Panoramic...

Je pense qu'il fait allusion à des bibliothèques précompilées.

Actuellement, Panoramic ne peut utiliser que des bibiothèques partagées (DLL) et avec des restrictions sur le types des variables que l'on peut passer aux fonctions.

Donc utiliser directement les bibiothèques de GIMP ou de BLENDER semble difficile. Il faudrait créer des DLL intermédiaires et trouver des astuces pour faire correspondre les types de variables autorisés par Panoramic avec ceux définis dans la DLL d'origine.

Bon, peut-être voir ça dans un second temps, testons d'abord les procédures que jack est en train de coder ...