Diverses propositions

Bonjour, je propose ici beaucoup de nouvelles propositions de commandes.

Ligne de commande pour exécuter
Ça serait pratique d'avoir une ligne de commande pour démarrer l'exécution du code d'un fichier du disque. Il suffirait de faire Execute_wait Panoramic_Editor.exe /run code.txt. Cela permettrais de faire son propre éditeur personalisé très facilement.

Memo qui gère la mise en forme
Bon, cette demande a déjà été faite beaucoup de fois, mais je le réécrit, ça serait vraiment bien d'avoir une sorte de Memo qui gère la mise en forme. Par exemple un Memorich, avec des commandes pour mettre un certain texte en gras ou en couleur. Même peut-être des commandes pour rechercher ou remplacer un ou plusieurs caractères dans un texte.

Scene2d
En ce moment, je suis en train de faire un nouveau jeu en 2d qui utilisateur une centaine de sprites. Le problème: je fais un écran de configuration mais sans utiliser de nouveau form. Mais quand je place un Picture ou n'importe quel autre objet sur la Scene2d existante, l'objet apparaît derrière ou lieu de devant la Scene2d. Ce que je voudrais c'est qu'on puisse mettre d'autres objets devant la Scene2d.

Commande pour changer le caractère de mot de passe
Les fonctions Secret_on et Secret_off sont bien pratiquent mais il manque quand même quelque chose. Habituellement, les mots de passe on un caractère rond et noir. Je demanderais si possible d'avoir une commande comme par exemple Secret_Char pour chosir le caractère utilisé.

Titre des dialogues
Je sais que j'en demande beaucoup en même temps, mais je continue quand même. Cette fois-ci je demande quelque chose qui serait pratique et éviterait même d'avoir à utiliser un Save_dialog. Je demande un fonction pour changer le titre d'un dialogue. Par exemple quand j'ajoute un fichier au texte de mon Memo je mets 'Ajouter un fichier' au lieu de mettre systèmatiquement 'Ouvrir un fichier'.

Menu check
Une autre éventuelle priorité serait de pouvoir cocher un menu pour marquer un choix. Pour l'instant le seule manière de le montrer et de modifier le texte du menu lui-même en mettant par exemple un étoile à la fin.

Je fini ici. Merci!
Nicolas

On dirai qu'il n'a a pas grand monde d’intéressé par ce sondage, pourtant il y a des propositions sympa...

Puisqu'on me demande mon avis, j'avoue qu'il n'y a rien là-dedans qui me manque vraiment, et qu'à priori je n'en ai pas encore ressenti le besoin.
Mais ça n'engage évidemment que moi, c'est sûr que d'autres vont être intéressés.

Pour ce qui est de la ligne de commande, je l'avais demandé il y a longtemps, mais ici on m'a répondu que c'était pas utile, on ne comprenait pas l'utilité. Par contre si c'est pour un éditeur, il y a ce qu'il faut.
J'en ai fait un éditeur bidon en 10 mn:

Code:

' editeur bidon
dim a$,f$  :label ouvrir,sauve,run

open_dialog 1
save_dialog 2
button 3:left 3,20 :caption 3,"ouvrir"  :on_click 3,ouvrir
button 4:left 4,200:caption 4,"sauver"  :on_click 4,sauve
button 5:left 5,380:caption 5,"run"    :on_click 5,run
memo  10:full_space 10: top 10,30:font_size 10,10
width 0,width(0)+20:height 0,height(0)+50

end
ouvrir:
filter 1,"ouvrir un fichier|*.bas;*.txt"
f$=file_name$(1)
if f$<>"_" then file_load 10,f$
return
sauve:
filter 1,"sauvegarder le programme|*.bas;*.txt"
f$=file_name$(1)
if f$<>"_" then file_save 10,f$
return
run:
if f$<>"" then file_save 10,f$:else:gosub sauve
chain f$
return

Pour le reste il n'y a que le memo gérant la mise en forme d'intéressant
Pour ce qui est de 2d, voir avec les spécialistes.

Ce qui serait bien c'est d'avoir une variable objet donnant la version de Panoramic. Avec les amélioration constantes, un programme ne fonctionne si on a choisi le bon éditeur.
Pour des raisons de bug, j'ai pris la version précédente, et régulièrement je me fais avoir avec ce problème.
EDIT: j'ai oublié de dire que même si c'est juste un exemple, on part avec l'idée d'un programme exécutable pour l'éditeur. Cela me paraissait éviedent.

Citation :

Ce qui serait bien c'est d'avoir une variable objet donnant la version de Panoramic

Ça m'est venu ce matin, il n'y a pas besoin de variable. Il suffit de faire au départ:

Code:

message caption$(0)

Je ne sais pas si cela a déjà été dit.

perso , je nai pas répondu car j'attends les sub et fonctions .

Moi, je n'ai pas fait de post sur ce sujet, mais j'ai duû être le 2ème ou 3eme à voter.
Il y a des idées interessante (dont le mémo gérant les formats, etc ...) mais pour moi comme le disait jpcr, ce ne sont que de "petits plus".

Là, le gros changement, c'est sûr ça va être les fonctions et procédures (les variables locales seraient un gros boulverssement selon moi, voir les objets locaux à une procédure...)

L'autre grosse attente serait la compilation ou l'execution de programme par une ligne de commande

Enfin selon moi, la troisième amélioration la plus importante serait l'optimisation du code généré (taille principalement)

Après, il y a de petites modifs que certains atttendent sur lesquelles Jack c'est déjà engagé pour les version à venir (suppression de certaines limitations arbitraires, ...) qui seront les bienvenues et si Jack a envie ou besoin pour une raison quelconque d'ajouter d'autres fonctionnalités, elles sont toujours les bienvenues aussi...

Bonjour,

Citation :

Enfin selon moi, la troisième amélioration la plus importante serait l'optimisation du code généré (taille principalement)

Malheureusement, la taille dépend de celle du noyau Panoramic : Il n'y a pas de véritable compilation lors de la génération d'un exécutable...

Voir la brillante démonstration de d.j Peters : ICI !

La seule chose que tu peux éventuellement faire c'est d'utiliser UPX pour diminuer la taille... (je n'ai pas encore fait de tests sous Win7 64bits pour voir si cela marche encore...)

Je sais mais dans un de ses posts, si ma mémoire ne me joue pas de tour, il me semble que Jack avait indiqué qu'il travaillait sur un vrai compilation du code. Je ne sais pas si cela est toujours d'actualité mais ça doit être un boulot assez costaud...

Jack, est-ce que ce serait une bonne idée d'avoir un post avec ta to do list en consultation ?
Genre:

A faire dans la prochaine version:
Tâche Avancement
... 100%
... 20% problème de compatibilité avec ...
... 50% la procédure est codé, tesst en cours

...

A faire dans les versions à venir
...
...
...


Idées à étudier:
...
...
...
...

Idées rejetées:
... Ne correspond pas à l'esprit de Panoramic
... Difficile à mettre en place dans la version actuelle
... Impossibilité technique...

Enfin c'est un exemple, mais je pense que ça permettrait à tout le monde de savoir ce qui est en cours et ce qui pourrait être demandé.

Moi, c'est vrai que j'attend le :
Memo qui gère la mise en forme
car ça permettrait de faire de superbes logiciels
de type traitement de textes, mais spécialisés
(pas pour essayer de concurrencer Word)

Citation :

Jack, est-ce que ce serait une bonne idée d'avoir un post avec ta to do list en consultation ?
Genre:

A faire dans la prochaine version:
Tâche Avancement
... 100%
... 20% problème de compatibilité avec ...
... 50% la procédure est codé, tesst en cours

...

A faire dans les versions à venir
...
...
...


Idées à étudier:
...
...
...
...

Idées rejetées:
... Ne correspond pas à l'esprit de Panoramic
... Difficile à mettre en place dans la version actuelle
... Impossibilité technique...

Ben, je préfère utiliser mon temps libre à coder, à débuger, bref à avancer, plutôt qu'à le passer à dire ce que je vais faire et à quel pourcentage de réalisation j'en suis sur telle ou telle action ...
Ca me rappelle trop le boulot où je passe beaucoup de temps à faire des rapports d'avancement sous PowerPoint et à mettre à jour des indicateurs, au détriment du temps passé à l'action.

PANORAMIC est un loisir, même si je constate (avec plaisir) que vous le prenez tous au sérieux.
Il y a certes des rapports d'avancements, des plans d'action, des indicateurs, mais ils sont enfouis dans les quelques neurones qui me restent et je n'ai pas envie d'avoir l'impression de "rendre des comptes" à un client.

"Au commencement était l'action"

Certes, ce n'est pas faux Mais peut être juste les idées en cours de dev / celles retenues et les rejetées ?

Il n'y a pratiquement aucune proposition rejetée, mais elles sont priorisées.

Je classe en priorité 1 les corrections de bug,

en priorité 2 les idées qui ne me demandent pas beaucoup de temps à être réalisée (exemple: lever la limite de 30 pour la taille des polices ou créer une fonction qui retourne 1 quand un SPRITE ou un OBJET 3D existe),

en priorité 3 ce qui me parait important pour la crédibilité du langage, même si cela va être long à réaliser (exemple: les fonctions et les sous-programmes avec paramètres, des instructions FREE ou REDIM)

en dernière position, ce qui est monstrueux à faire et pas vraiment utile:
- réduire la taille de l'exécutable. Quel utilisateur de vos exécutables va se soucier que la taille est de 500Ko au lieu de 3Mo pour la même fonctionnalité réalisée ?
- ou produire un véritable compilateur afin d'améliorer la vitesse d'exécution. Je pense que 6 mois de travail à plein temps seraient nécessaires, pour une augmentation en vitesse d'exécution peu perceptible. L'augmentation continue de la vitesse des cartes mères compense cela. Les PC vont de plus en plus vite. Pourquoi s'épuiser à créer un compilateur qui génère du code assembleur alors que la vitesse d'exécution d'une interprétation suit la vitesse des microprocesseurs et rattrape au bout de quelques années la vitesse qu'aurait eu une compilation et que en définitive, personne n'ira regarder en détail le code généré ?
Mais ces 2 idées ne sont pas rejetées pour autant.
Si un jour je ne suis plus seul à coder, on se lance dans l'écriture d'un compilateur qui pourrait aussi optimiser le code ...
Mais il faudrait une personne pour coder ce compilateur (moi), une autre personne pour le tester et décrire les bugs et aussi pour écrire la documentation en anglais et en français, une troisième pour gérer les forums et les sites et peut-être aussi pour écrire des tutoriels (comprenez bien que pendant que je tape ces lignes sur le forum, je ne code pas et je n'écris pas de documentation ...), etc, etc.

Jack,

j'ai un doute tout d'un coup, les fonction et sub en 3 , ça veut dire quand? dans 3 mois ? 6?

bon courage!!

jp

La taille des exécutables n'est pas vraiment un problème : on peut toujours les compacter avec UPX, comme cela a souvent été signalé.

Quant à la vitesse d'exécution, on peut mettre les parties les plus lentes dans des DLL compilées avec un compilateur optimiseur.

Donc ces deux objectifs ne sont pas vraiment prioritaires. Il vaut mieux se concentrer sur les SUB et FUNCTION

Tout à fait d'accord avec jean_debord,

La taille n'a pas vraiment d'importance...

Je suppose que Jack travaille en arrière plan sur la possibilité des SUB() en FCT(), vu l'apparition de la fonction VARIABLE() et de la future FREE var%...

J’attends vivement cette fameuse version 1.0i1 car je suis en train de m'amuser à faire une bibliothèque de fonctions pour gérer des Arbres binaire de recherche auto-équilibrés (AVL) . J'ai mis en place une gestion de pile pour les passage de paramètres et les appels récursifs (ça marche bien pour l'instant, j'ai "presque" tout codé) mais je dois avouer que c'est galère à écrire en Panoramic !!!

Personnellement, je n'ai pas non plus l'usage de la compilation en ligne de commande et j'avoue que la taille des exécutables n'est pas dans mes priorités non plus, mais je pense que ta réponse sur ces points est importantes, car ce sont des demandes récurrentes sur le forum. Ton point de vue sur ses demandes évite que certains pensent que leurs demandes ne sont jamais prises en compte comme on peut le lire de temps à autre.
Elles sont prises en comptes, pour celles là par exemple, elles ne sont pas refusées mais ne seront pas dans les versions à venir dans un futur proche.
En plus, ton public aime bien avoir régulièrement de tes nouvelles (Tu sais bien que la nature à horreur du vide ^^)

D'accord également pour la taille, (et la vitesse d'exécution) aucun problème avec les volumes dont nous disposons à l'heure actuelle (j'ai commencé avec 4K de mémoire vive et un magnéto cassettes, maintenant c'est le grand luxe).

Je sais que Jack est très occupé en ce moment, mais j'ai rajouté une nouvelle propositions de menu que l'on peut cocher. Cependant, j'ai ne pouvais pas modifier le sondage alors j'ai laissé faire pour celle-là.

Aqui esta em Português:

Olá amigos.
Não sei se é uma coisa necessária para o momento, mas eu gostaria que o editor panorâmica pudesse abrir outros tipos de arquivo como *. txt. Ou em outro caso de mudar a extensão do arquivo para algo como *.pbas, *.bpan ou *.pan.

Eu tenho uma outra linguagem BASIC instalada no PC e sempre tenho que abrir primeiro o editor e escolha o arquivo a ser aberto. Se a extensão do arquivo mudar, eu acho que não haveria conflito. E, quanto ao editor abrir arquivos em outras extensões, é porque muitas vezes eu prefiro usar outro editor de código e salvá-lo em *. txt.

Bem, isso é tudo .... Um abraço a todos.

PS: Acho a PANORANIC uma linguagem em todo o caso muito original e é bem merecida uma troca de extensão.
Mas isso cabe ao seu criador decidir. Obrigado JACK.


PS:Isso tudo foi traduzido pelo Google, se houver erros vocês já sabem a quem devem culpar!

==============================================================================

Voici en Français:

Bonjour les amis.
Je ne sais pas si c'est une chose nécessaire pour le moment, mais je voudrais l'éditeur d'image pourrait ouvrir d'autres types de fichiers comme *. txt. Ou dans un autre cas de changer l'extension du fichier à quelque chose comme *.pbas, *.bpan ou *.pan.

J'ai un langage BASIC installé sur un autre PC et je dois toujours d'abord ouvrir l'éditeur et choisissez le fichier à ouvrir. Si le changement extension de fichier, je pense qu'il n'y aurait pas de conflit. Et quant à l'éditeur pour les fichiers ouverts dans d'autres extensions, c'est parce que je préfère souvent utiliser un autre éditeur de code source et de l'enregistrer au format *. txt.

Eh bien, c'est tout .... Une accolade à tout le monde.

PS: Je pense que le PANORANIC une langue dans tous les cas est unique et bien méritée de retour pour une extension.
Mais c'est au créateur de décider. JACK Je vous remercie.

PS: Tout cela a été traduit par google, s'il ya des erreurs que vous savez qui blâmer!

Je suis content de constater que dans le sondage, ce qui prime avant tout, c'est :
Memo qui gère la mise en forme.
(ça fait longtemps que j'attends ce progrès-là)

Mais là, c'est quelque chose de monstrueux ou de facile à faire ???????
On a des chances de le voir un jour, ou même peut-être bientôt ?

Bonjour Jack

Citation :

en priorité 2 les idées qui ne me demandent pas beaucoup de temps à être réalisée

Il y a une chose qui ne serait pas long à réaliser:
c'est RINSTR(), le instr commençant par la droite. Le travail est à moitié fait:

Code:

dim a,f$
f$="je suis ici\pour le plaisir\et salut"
message file_extract_name$(f$)
f$=f$="je suis ici\pour le plaisir|et salut"
message file_extract_name$(f$)

qui sait ce que tu en penses?. désolé si je suis dans l'erreur. mais enfin pour ceux qui ont besoin de cette instruction et que "\" n'est pas un problème comme séparateur dans leur chaine, c'est une solution.

C'est sûr, ce n'est pas la fonction la plus difficile à coder pour Jack et c'est pratique...

désolé mais je ne suis pas forcement d'accord avec vous, ce genre de fonction étant facile a coder , c'est au programmeur d'en faire une fonction dans son programme et non a Jack d'ajouter une commande a Pano, sinon on va finir avec 10000 commandes et ce sera inutilisable.

c'est la tout l’intérêt des fonctions (et sub) et si je me souviens bien , on était d'accord pour essayer de faire une bibliothèque de fonctions partagée entre tous ( ou RINSTR() irait parfaitement, par exemple...)

loin de moi l'intention de polémiquer mais la, pour le coup, je trouve que l'on pourrait soulager un peu Jack....

jp

Je ne partage pas ton point de vue jpcr
La commande RINSTR n'est pas vitale, certe, mais c'est une fonction très utilisée pour les personnes qui traitent des chaines (pour les chemins par exemples) Voir pour dépiler des choses concaténées.
Bien sûr, on peut faire des fonctions, des scripts, des appels a des DLL externes, mais cela n'est qu'une étape intermédiaire. Le but étant d'obtenir à terme des fonctions communes et documentées intégrées à Panoramic pour en standardiser l'usage.
Après, il est certains que tu peux ne pas en voir l'interet tout comme à ce jour je ne vois pas mon interet à l'instruction LPRINT, mais quelqu'un qui ne fait pas certains type de programme ne verra aucun interet à toutes les instructions traitant des sprites et pourrait trouver Panoramic beaucoup plus simple sans...
Faut-il comme dans certains langage charger systèmatiquement des librairies spécialisées dans tel ou tel domaine, c'est une opinion qui se défend et de nombreux basic et autre langage ont opté pour cette façon de travailler. A ce jour, ce n'est pas celui de Jack si je ne me trompe pas.