FORUM DE DISCUSSION SUR LE LANGAGE PANORAMIC

Développement d'applications avec le langage Panoramic
 
AccueilAccueil  FAQFAQ  RechercherRechercher  S'enregistrerS'enregistrer  MembresMembres  GroupesGroupes  Connexion  
Derniers sujets
» API Windows
par Klaus Aujourd'hui à 3:21

» KGF.dll - demandes ou suggestions de modifications ou ajouts
par pascal10000 Hier à 17:49

» Cartes de voeux, menus, etc.
par JL35 Hier à 17:48

» Mah-Jong européen new-look
par jjn4 Hier à 15:48

» a l'aide klaus
par Minibug Hier à 11:42

» KGF_dll - nouvelles versions
par Minibug Hier à 1:48

» bug SYNEDIT_TARGET_IS_OBJECT
par Jack Hier à 0:16

» Jukebox : Serge Reggiani
par papydall Sam 9 Déc 2017 - 5:58

» Ecouter la radio fm sur votre pc
par pascal10000 Sam 9 Déc 2017 - 3:42

» anomalie
par Klaus Sam 9 Déc 2017 - 3:21

» hommage
par Jicehel Ven 8 Déc 2017 - 11:29

» Logiciel de soutien scolaire en langues.
par Pedro Alvarez Ven 8 Déc 2017 - 10:43

» carte son
par Klaus Ven 8 Déc 2017 - 2:37

» mise a jour calculatrice
par joeeee2017 Mer 6 Déc 2017 - 22:19

» j'ai un petit problème
par JL35 Mer 6 Déc 2017 - 21:58

Navigation
 Portail
 Index
 Membres
 Profil
 FAQ
 Rechercher
Rechercher
 
 

Résultats par :
 
Rechercher Recherche avancée
Décembre 2017
LunMarMerJeuVenSamDim
    123
45678910
11121314151617
18192021222324
25262728293031
CalendrierCalendrier

Partagez | 
 

 Prochaine version

Voir le sujet précédent Voir le sujet suivant Aller en bas 
AuteurMessage
Jack
Admin
avatar

Nombre de messages : 1771
Date d'inscription : 28/05/2007

MessageSujet: Prochaine version   Sam 8 Mai 2010 - 9:52

La prochaine version aura les fonctionnalités suivantes.

1 - 2 nouvelles fonctions:
SPRITE_X_POSITION(N) : retourne la position en X du SPRITE numéro n
SPRITE_Y_POSITION(N) : retourne la position en Y du SPRITE numéro n

2 - 4 nouvelles variables système:
NUMBER_CLICKED dont la valeur est le numéro d'objet cliqué
NUMBER_CHANGED dont la valeur est le numéro d'objet changé
NUMBER_KEY_DOWN dont la valeur est le numéro d'objet sur lequel une touche a été enfoncée
NUMBER_KEY_UP dont la valeur est le numéro d'objet sur lequel une touche a été relachée

3 - la commande SPRITE_TARGET_IS N conformément à la documentation

4 - le bug corrigé sur SELECT / CASE / END_SELECT

5 - un objet TIMER et ses commandes associées:
TIMER N
ON_TIMER N,LABEL
TIMER_INTERVAL T
TIMER_ON N
TIMER_OFF N


6 - Pour éviter un mélange incompatible de programmation procédurale et de programmation événementielle:
les commandes INPUT, WAIT et EXECUTE_WAIT seront interdites (leur exécution provoquera une erreur) à partir du moment où une déclaration d'événement aura été exécutée: ON_TIMER, ON_CLICK, ON_CHANGE, ON_KEY_DOWN, ON_KEY_UP

7 - inversement, les déclarations d'événement ON_TIMER, ON_CLICK, ON_CHANGE, ON_KEY_DOWN, ON_KEY_UP seront interdites (leur exécution provoquera une erreur) à partir du moment où une commande INPUT, WAIT ou EXECUTE_WAIT aura été exécutée

8 - pour éviter une "programmation spaghetti", je prévois l'interdiction d'un GOTO dans les 3 cas suivants:
- GOTO du programme principal (le programme qui est exécuté au démarrage et qui se termine par END) vers un sous-programme
- GOTO d'un sous-programme vers le programme principal
- GOTO d'un sous-programme vers un autre sous-programme

9 - de même, il y aura 3 types de LABELs:
- le type LABEL_GOTO servant aux commandes GOTO,
- le type LABEL_GOSUB servant aux commandes GOSUB,
- le type LABEL_EVENT servant aux traitements d'événements ON_TIMER, ON_CLICK, ON_CHANGE, ON_KEY_DOWN, ON_KEY_UP

10 - les 3 utilisations suivantes seront interdites (leur exécution provoquera une erreur):
- GOTO vers un LABEL qui n'est pas déclaré comme LABEL_GOTO
- GOSUB vers un LABEL qui n'est pas déclaré comme LABEL_GOSUB
- ON_TIMER, ON_CLICK, ON_CHANGE, ON_KEY_DOWN, ON_KEY_UP
contenant un LABEL qui n'est pas déclaré comme LABEL_EVENT

Longue vie à PANORAMIC.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://panoramic.free-boards.net
vincelt



Nombre de messages : 24
Age : 41
Localisation : France 41,45
Date d'inscription : 06/12/2008

MessageSujet: Re: Prochaine version   Sam 8 Mai 2010 - 12:45

moi je dit juste bravo !!!!

Vince
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://vincelt2.free.fr
jjn4

avatar

Nombre de messages : 1625
Date d'inscription : 13/09/2009

MessageSujet: +++   Sam 8 Mai 2010 - 13:30

Citation :
Longue vie à PANORAMIC

Exactement, Jack a tout dit !

cheers
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://jjn4.e-monsite.com
659_minifly



Nombre de messages : 590
Age : 69
Localisation : Valenciennes Nord
Date d'inscription : 29/04/2010

MessageSujet: Re: Prochaine version   Sam 8 Mai 2010 - 15:06

Encore...... encore ......encore..... plus s.v.p
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Jean Claude

avatar

Nombre de messages : 5086
Age : 63
Localisation : 83 Var
Date d'inscription : 07/05/2009

MessageSujet: Re: Prochaine version   Sam 8 Mai 2010 - 16:50

N'étant pas chez moi pour 8 jours et pour ne pas sqwatter l'ordi de ma fille, je ne répondrais qu'a ce sujet.

Je dis bravo à Jack pour la solution qu'il apporte, au sujet du mélange de méthode de programmation, car çà façon de gérer le problème (j'ai failli dire contourner) est on ne peut plus démocratique. En effet, la facilité était de supprimer tout simplement la façon (nonmée procédurale), mais en fait il fait controler par Panoramic l'utilisation des 2 façons (procédurale et événementiel). Ce qui permettra à tous le monde d'y trouver son compte.

Bravo pour les fonctions TIMER qui manquait vraiment.
Et pour finir, j'ajoute que les 4 variables systèmes, concernant les N° d'objet, (NUMBER_....) vont nous donner la possibilité de concevoir nos codes de manière différente et plus facile.

Merci et Bravo pour ces nouveautés.

A+

PS: cela fait "pile poil" un an que je suis arrivé sur ce Forum et j'en suis satisfait. sunny
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Klaus

avatar

Nombre de messages : 10245
Age : 68
Localisation : Ile de France
Date d'inscription : 29/12/2009

MessageSujet: Re: Prochaine version   Sam 8 Mai 2010 - 23:20

J'aime bien la façon dont la situation de clarifie, avec cette façon de séparer clairement la partie "procédurale" de la partie "évènementielle", et de distinguer de façon tout aussi rigoureuse les sous-prgrammes "normaux" des sous-programmes "évènements". La conception d'un programme ensera simplifié, et il sera plus clair et lisible pour un tiers. Bravo !

L'apparition du timer, c'est super. Un vrai plus.

@ Jack: as-tu eu l'occasion de regarder le problème avec handle_canvas() que j'ai signalé, et est-ce que l'idée d'une fonction adr(x%()) pour passer l'adresse de la partie data d'un array de entiers est recevable ?
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://klauspanoramic.comxa.com/index.html
Yannick

avatar

Nombre de messages : 8002
Age : 46
Localisation : Bretagne
Date d'inscription : 15/02/2010

MessageSujet: Re: Prochaine version   Dim 9 Mai 2010 - 12:26

Vraiment génial cheers cheers cheers cheers

Je profite de cet emplacement recent pour demander à Jack de regarder dans
la dernière version les "mouse_x...... tout ce qui est mouse qui chez moi en tout cas ne font pas ce qu'ils sont sense faire.

je voulais palier au prochaine sortie par la recup de la position de la souris sur le scene2d mais impossible.

a moins que ce soit moi qui bug....
....ca c'est encore possible
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Jack
Admin
avatar

Nombre de messages : 1771
Date d'inscription : 28/05/2007

MessageSujet: Re: Prochaine version   Dim 9 Mai 2010 - 18:37

Je lis ce forum après une journée d'absence et je ne m'attendais pas à des réponses aussi positives.
Je m'attendais au contraire à une levée de boucliers sur la proposition de créer 3 types de LABELS. En effet, cela provoquerait, le jour où ce serait appliqué, une chose qui n'est jamais arrivée: la non-compatibilité ascendante des sources.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://panoramic.free-boards.net
jjn4

avatar

Nombre de messages : 1625
Date d'inscription : 13/09/2009

MessageSujet: +++   Dim 9 Mai 2010 - 18:53

Il n'y aura pas que cela qui provoquera la "non compatibilité ascendante des sources"
il y a aussi le fait qu'on mélange tous un peu d'événementiel et de programmation linéaire, histoire de compléter ce qui n'est pas encore possible en événementiel pur,
Et ça va tout changer pour les vieux programmes qu'on a.

Bon, mais si il n'y a pas moyen de faire autrement pour avoir des timer
ce qui sera une avancée considérable qui évitera d'avoir à risquer des cycles goto de type scabreux,
tant pis, on modifiera tous nos vieux programmes
un peu de travail, mais bon...
j'ai compté, j'en ai environ 300,
mais ça donnera l'occasion de faire du nettoyage,
j'ai plein de vieux essais qui sont bon pour la poubelle et qui restent là...
geek
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://jjn4.e-monsite.com
Jack
Admin
avatar

Nombre de messages : 1771
Date d'inscription : 28/05/2007

MessageSujet: Re: Prochaine version   Dim 9 Mai 2010 - 19:08

Merci pour la compréhension de tous.
Mais je ne pouvais pas sortir un TIMER qui exécute un sous-programme à intervalle régulier (c'est le principe d'un timer) dans un programme qui permettrait une suspension totale par un INPUT.

Ou encore, il est facile de comprendre qu'un TIMER se déclenchant par exemple 5 fois par seconde ne puisse pas contenir dans son traitement périodique une commande WAIT 20000 qui ferait à chaque fois une suspension de 20 secondes!
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://panoramic.free-boards.net
jjn4

avatar

Nombre de messages : 1625
Date d'inscription : 13/09/2009

MessageSujet: +++   Dim 9 Mai 2010 - 19:12

Et les message_input$(...
ça ne gênera pas ?
scratch
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://jjn4.e-monsite.com
Invité
Invité



MessageSujet: Re: Prochaine version   Mar 11 Mai 2010 - 0:13

Cela fait deux jours que je recule mon intervention. Contrairement à la majorité, je n'applaudis pas à 100 pour 100 sur l'ensemble de ce qui se dit.
En ce qui concerne les fonctions timer; rien à dire sinon quelles sont la bien venue, et j'en remercie Jack.

En revanche concernant mes label_goto ou gosub, en réservant une place particulière à label_event qui peut-être à ses raisons, je ne suis pas d'accord. Si Jack a des problèmes pour avancer dans les commandes à venir, j'approuve sans restrictions sa volonté.

Dans le cas où le but est d'éviter une programmation spaghetti comme on le faisait à une certaine époque, je suis plus rétrissant. Je ne dis pas qu'il faut le faire, parce que cela est un foutu bordel (et je sais ce que je dis). Mais qu'appelle-t-on programme spaghetti ici?

Un exemple: dans mon programme d'éditeur de cellule, j'ai un sous-programme qui était terminé. En faisant un ou deux jours plus tard, à un moment j'ai eu besoin de faire une partie du programme précédent. J'aurai pu à ce moment là, dire je vais rajouter un autre sous programme, reprendre la partie du code qu'on veut en double, et faire un gosub; et aussi faire un gosub dans mon autre sous-programme. La solution plus simple que j'ai trouvé à été de faire (oh mon dieu! ) un goto à un label qui se branche directement à ce qui était déjà fait. Jusqu'à présent cela marchait merveilleusement bien et ne semblait pas poser de problème au basic (un simple jump). Là 3ème solution est de remplacer le goto par un gosub au label supplémentaire dans le premier sous-prog, qui fait qu'au retour, j'aurai du rajouter un autre label pour me brancher à la fin de la procédure et éviter les lignes qui suivait. Ce qui fait 1) gosub partie faite. 2) retour à la suite du gosub, 3)goto au return de la procédure en cour. Résultat: des allées et venues du "yoyo". Pour moi la solution que j'ai choisi est la plus élégante, j'ai simplement changé de return, et je ne pense pas que cela ait posé de problème pour dépiler la pile (si c'est bien comme cela ça se passe).

La question est: Pourquoi faire simple quand on peut faire compliqué?
Si le basic a bien fonctionné jusqu'à présent, et semble pas un handicap au basic, pourquoi vouloir mettre un blocage supplémentaire? Panoramic est bien codé mais j'avoue que souvent le contrôle est vraiment pointilleux. Un mid$() n'a aucune souplesse, tout comme right$, il faut à chaque fois la juste longueur de chaine pour ne pas faire de dépassement. Si vous programmez comme moi, vous savez que tout le long du programme, il faut tout contrôler. Je ne fais pas de reproche mais une constatation. Et maintenant on en rajoute. Si c'est utile: d'accord, dans le cas contraire, pourquoi? pour une logique brute en se disant que cela doit être comme cela et pas autrement! Je ne suis pas maso, et pourquoi me faire mal?

Maintenant parlons des label_goto et label_gosub. Déjà cela a pour but de m'interdire de faire à partir d'une procédure un goto à des lignes de programmes et sortir sur un autre return. Ok on vient de voir.

j'ai un programme (c'est du n'importe quoi, je montre un principe)
Code:

etiquette_1:
  suite%=suite%+1:if suite%=10 then goto etiquette 2
  variable=1
etiquette_2:
  variable=variable+1
  etc...
  etc...
return

Je veux initialiser la variable_1 à 1, donc je vais faire un gosub etiquette_1
Pourquoi vouloir m'interdire de faire goto etiquette_2? Je vais devoir rajouter une 3ème étiquette qui sera une étiquette de goto. Si c'est pour le fun, je trouve cela absurde. Dans le cas contraire et qu'il ait une bonne raison, là je m'incline. Après tout je ne sais pas comment est fait Panoramic?
si je ne veux pas initialiser variable et sauter "suite%", je vais faire un gosub etiquette_2. Il faut encore espérer qu'on a le droit d'avoir deux ou plus étiquette_label dans la même procédure, autrement où on va?

Si c'est pour éviter des erreurs de programmation, je pense que ce serait plus judicieux d'avoir un bon mode d'emploi au départ pour savoir ce qui est permis ou pas pour qu'il n'y ait pas de perturbation dans le programme.

Je vais faire la demande suivante, qui évidemment ne sera pas repris, et certainement pas commenté: ne serait-il pas possible d'avoir une instruction qui permettrait de stopper le programme pendant la phase de teste lorsqu'il y a blocage suite à une erreur,puis ensuite lorsque tout est ok, on rajouterai (je ne sais pas si event est le bon terme?) off_event_stop en début de programme pour stopper cette intrusion. Cela aurait pour fonction d'arrêter le programme lorsqu'il y a blocage avec par exemple Ctrl pause ou autre (qui a pour conséquence de ralentir le basic obligatoirement puisque cela oblige de faire un détour pour tester la volonté de sortir) encore que cette instruction n'est certainement nécessaire que lorsqu'il y a une boucle!. Une fois le programme au point, on rajoute l'instruction qui évite ce détour.

Cosmos passe son temps à critiquer, et je me fais une réputation qui ne me plait pas. Mais si personne ne pose les problèmes, il faut bien que je le fasse. C'est d'ailleurs une des raisons qui me dit que je dois restreindre ma présence ici.

Un dernière chose: Si le basic doit changer, peut-être devra t-on laisser en présence sur le forum les deux versions de basics, afin que les anciens programmes qui n'ont pas besoin de commandes supplémentaires et ne seront pas intégrés au basic, fonctionnent! Si ce cas de figure est envisagé, ne serait-il pas judicieux de faire une différence de couleur de forme par exemple pour savoir sur quel système on est?

Je ne doute pas un seul instant que toutes mes remarques comme d'habitude vont être retenues, vu que tout le monde ou presque approuve les nouveaux principes. Je me demande juste si toutes les transformations sont nécessaire. On avait un basic simple, il se complique!

Pour ce qui concerne le mélange de codage événementiel ou non, de toute façon je crois que j'ai maintenant une solution pour moi.

152Maintenant je vais essayer de faire voeux d'abstinence. Ne m'en veux pas Jack, je sais que tu fais pour le mieux.
Revenir en haut Aller en bas
Jack
Admin
avatar

Nombre de messages : 1771
Date d'inscription : 28/05/2007

MessageSujet: Re: Prochaine version   Mar 11 Mai 2010 - 9:00

@ cosmos70:
Cela fait plusieurs jours que je regarde comment coder les 3 types de labels (label_goto, label_gosub et label_event) de manière à minimiser le travail important que cela représente pour moi. Et je me passerai bien volontiers de ce surcroit de travail.

Cette modification va à l'encontre de l'un de mes principes: la compatibilité ascendante.
De plus, cela ne représente pas une faible partie des sources qui ne fonctionneront plus, mais presque la totalité des sources déjà écrits.
Chacun va devoir réécrire voire repenser la structure de ses sources. Moi-même, je vais devoir retoucher les centaines et les centaines de programmes de test de Panoramic: chaque mot clé est testé dans un source et dans toutes les conditions (par exemple, il y a autant de programmes de test de la commande TOP qu'il y a d'objets visibles).

Et pourquoi?
Pour faire en sorte que les gens qui ne programment pas de façon réfléchie et structurée aient moins de problèmes.

Comme tu le fais remarquer, la complexité va augmenter et on va perdre en simplicité d'utilisation. Ta remarque me touche beaucoup. La simplicité d'utilisation est un autre de mes grands principes dans la réalisation de ce logiciel.
Il vaut mieux un bon tutoriel plutôt que de perdre en souplesse et en simplicité.

Comme toi, je pense que j'interviens trop sur le forum et que je propose trop. J'écoute trop souvent tous les sons de cloche et cela donne l'impression qu'il n'y a pas de ligne directrice dans le développement puisque je réalise des demandes récentes alors que des demandes anciennes et fondées sont retardées.

Pour le moment, je ne ferai pas de bouleversement.
Je continue le codage de fonctionnalités manquantes et le débugage.
Cela ne va pas plaire, mais je vais laisser faire des GOTO là où il faudrait un GOSUB et tant pis.

Les 3 types de labels sont reportés aux calendes grecques à cause de tout cela: compatibilité ascendante profondément touchée, surcroit de travail de codage, complexité d'utilisation, faible impact.

Je vais aussi me faire plus rare sur le forum et je n'interviendrai que "dans les cas graves". Je vais regarder ta proposition d'instructions pour la mise au point.
Autrefois, il y avait TRACE_ON et TRACE_OFF. Ces instructions pourraient écrire le cheminement du programme dans un fichier texte (date, heure, numéro de ligne). Il pourrait y avoir une commande PAUSE qui afficherait le contenu d'une variable dans ne fenêtre et une touche RESUME sur la fenêtre pour reprendre l'exécution.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://panoramic.free-boards.net
Invité
Invité



MessageSujet: Re: Prochaine version   Mar 11 Mai 2010 - 11:11

Merci pour ta réponse.
A mon touche celle-ci me touche beaucoup.

Il n'y a pas mieux pour programmer que de connaitre la ligne directrice du fondateur et suivre celle-ci pour que le résultat final aille avec le codage final du programme.

Si tu me dis que faire "ceci comme cela" gène le développement de mon logiciel, mon pose des problèmes pour coder, dit toi bien que je ne ferais pas. Si je connais à l'avance les problèmes que tu dois surmonter pour améliorer Panoramic, j'en tiendrais compte dans mon codage.

Ce qui est nécessaire de savoir, c'est de bien connaitre ce que tu veux à l'avance qui ne complique pas la tâche.

Si par contre (pour exemple) mettre un goto dans une autre procédure, qui récupérera le return (et dépilera je crois mais c'est toi qui peut le dire le gosub précédent) et ne gène pas le codage de Panoramic, pourquoi l'interdire (dans mon cas c'est plus direct, cela fait des instructions en moins, donc de la rapidité...).

Si tu pouvais ajouter un mode trace, qui permettent aux gens ne respectant pas la méthode, de comprendre leurs erreurs, peut-être que cela éviterait de faire des labels particuliers (dont tu seras obliger de contrôler à chaque appel si c'est le bon type de label qui correspond).

Je ne sais pas si tu as vu, mais n'ayant pas beaucoup de moyens à ma disposition, j'ai réussi à faire un mode trace avec un logiciel en intégrant des lignes d'appel entre chaque ligne d'un programme. Peut-être tu pourrais faire une chose similaire en mettant un coche à l'éditeur, et constituer un programme intermédiaire qui permettrait de suivre le programme.

Ce n'est que des suggestions, moi j'ai rien à dire ou imposer. Je me sers des outils qu'on me donnes, et tu donnes beaucoup.

Merci à toi.
Revenir en haut Aller en bas
JL35



Nombre de messages : 6018
Localisation : 77
Date d'inscription : 29/11/2007

MessageSujet: Re: Prochaine version   Mar 11 Mai 2010 - 15:16

C'est bien aussi mon avis, que plutôt que de bouleverser la philosophie de Panoramic ça ne serait pas plus mal de consolider l'existant, en particulier résoudre les bugs en attente, et mettre à jour le manuel pour toutes les nouvelles fonctions.
Pour le TRACE_ON/TRACE_OFF, c'est vrai que ça manque beaucoup, il y a parfois des erreurs sans numéro de ligne, ça part dans les décors sans qu'on sache pourquoi.
Quant à PAUSE/RESUME avec affichage de variable(s), c'est facile à faire avec les outils existants: MESSAGE.

Je crois que ce n'est pas plus mal de faire un peu une pause dans les fonctions nouvelles.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
cpc

avatar

Nombre de messages : 2
Date d'inscription : 11/05/2010

MessageSujet: Re: Prochaine version   Mar 11 Mai 2010 - 21:34

Bonjour,

J'interviens pour la première fois sur le forum... je suis un lecteur assidu de vos messages et pourtant, je ne suis pas utilisateur du langage !!!

Et oui... je suis un espion en fait... je suis aussi l'auteur d'un langage de programmation.

J'ai découvert ce langage il y a quelques années au moment je voulais démarrer un projet de création d'un langage : je voulais faire un BASIC des temps modernes... malheureusement pour moi... et heureusement pour vous, il y avait déjà Panoramic, du coup, je suis parti sur une autre voie que le BASIC.

Jack a réussi deux choses : créer un interpréteur puissant et riche, et une bonne communauté autour de lui !

C'est bien pour ça que j'interviens aujourd'hui en lisant ses derniers posts. Il faut continuer à répondre pour aider, donner la bonne parole (la bonne programmation Smile. Car je le rejoins, l’utilisation des GOTO est à proscrire… même si elle est bien utile quand on débute.

Maintenant, pour ma part, la plus grosse évolution que devrait apporter Jack à son langage, c'est le nommage des variables ! Out les nombres ! Mais que l'on puisse les nommer avec du texte ! C'est très important pour comprendre le code des autres et son code : une bonne sémantique est importante pour écrire du code sain !

Bon courage pour la suite et bravo encore !!

Cpc
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Jack
Admin
avatar

Nombre de messages : 1771
Date d'inscription : 28/05/2007

MessageSujet: Re: Prochaine version   Mar 11 Mai 2010 - 22:47

Merci de tes conseils.
Bon courage aussi.
Linotte est un excellent langage pédagogique.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://panoramic.free-boards.net
Invité
Invité



MessageSujet: Re: Prochaine version   Mer 12 Mai 2010 - 1:21

Bienvenue cpc.
ça me rappelle Amstrad, même si j'ai encore le 464 dans le grenier.

Je dis bienvenue, et pourtant si il y a une certaine chose que je n'aime pas, ce sont les idées reçues.
Citation :
Car je le rejoins, l’utilisation des GOTO est à proscrire

Je suis majoritairement contre les goto. Heureusement est apparu (en laissant for/next de côté, que j'ai connu dès 81) repeat/until, while/wend ou end_while, dans d'autre langage do/loop. etc...

Pourtant vouloir systématiquement refuser l'emploi de goto quand cela est utile et pratique est une aberration pour moi. C'est où? à la faculté que les profs vous incultent cela. Lorsque la structure est correct, que le dépilement des gosub est respecté, et que cela ne ressemble à du codage spaghetti pourquoi diante le refuser? "oh non sacrilège, c'est interdit/ c'est pas bien/ c'est interdit/ tu sais pas programmer "ou je ne sais pas quoi. C'est pour faire plaisir à son prof? qui vous observe. Un goto est parfois bien pratique, et de temps en temps fait gagner du temps en codage ou en temps d'exécution.

Je n'aime pas qu'on interdise une chose, parce que quelqu'un a foutu une chose dans la tête d'une autre, que cela ne se fait pas.
Chaque langage a ses conceptions, le basic a les siennes. Normalement ce langage est réputée plus lent que les autres, et aujourd'hui cela reste à voir. J'ai essayé Python et je trouve plus lent que Panoramique. Un goto bien souvent diminue le nombre d'instructions, et chaque instruction en moins est un gain de temps en temps machine (en principe seulement vu, chacune fait des choses plus ou moins complexe).

Je suis certain qu'on va aller à l'encontre de ce que je dis. Si vous voulez plus qu'on se serve du goto, alors supprimez le, et vous verrez que parfois que ça va pas être simple de coder!.

SVP, arrêtez de mettre des choses sur le forum, qui me font interagir. J'ai dit que je voulais diminuer ma présence sur le forum, alors aidez-moi, parce que moi je supporte pas les idées toutes faites.

C'est amicalement que je poste ces propos, et bienvenu CPC. (Au fait si tu n'utilise pas Panoramic, quel langage utilises-tu en dehors de Linotte?)

PS: je tiens à bien faire comprendre que malgrès tout qu'il faut éviter de mettre des goto qui montent et qui descendent pour faire un programme. Mais si vous regardez l'ensemble des programmes, les goto sont rares, donc cela n'a pas de sens.
Revenir en haut Aller en bas
JL35



Nombre de messages : 6018
Localisation : 77
Date d'inscription : 29/11/2007

MessageSujet: Re: Prochaine version   Mer 12 Mai 2010 - 10:16

Sans être aussi virulent (!), je suis un peu d'accord avec toi cosmos, un petit goto au milieu d'un traitement pour sauter quelques lignes en avant ou en arrière simplifie bien la programmation.
Evidemment il n'est pas question de sortir d'un sous-programme ou de se brancher dans un sous-programme avec un goto, il faut l'utiliser intelligemment en respectant la logique du programme.
Mais l'interdire, non.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
cpc

avatar

Nombre de messages : 2
Date d'inscription : 11/05/2010

MessageSujet: Re: Prochaine version   Mer 12 Mai 2010 - 10:46

Oups désolé d’avoir été si extrême avec le GOTO !

En effet, il ne faut pas l’interdire et je pense même qu’il ne faut pas mettre de règle pour le limité dans PANORAMIC comme le souhaitait Jack.

Je l’ai utilisé pendant pas mal d’années aussi… sur mon CPC 6128 !!!

De plus, Cosmos70, recommander d’utilisation le GOSUB est plus de mon expérience personnel que de la lecture de documents ou recommandation. Dans 90% des cas, tu peux arriver à réduire la taille de ton programme et le rendre plus lisible si tu passes par des GOSUB et lieu de GOTO.
Ça peut être un bon exercice de prendre un des programmes et de faire en sorte que tu supprimes tous les GOTO.

Bonne programmation
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Yannick

avatar

Nombre de messages : 8002
Age : 46
Localisation : Bretagne
Date d'inscription : 15/02/2010

MessageSujet: Re: Prochaine version   Mer 12 Mai 2010 - 13:47

je vais me permettre une petite intervention....

je ne suis pas d'accord sur certains points

@ Jack

tes interventions sur le forum ne sont jamais de trop.
comme l'on dit, il vaut mieux un qui sait que dix qui cherchent, et qui en dehors du concepteur sait le mieux ce qu'il est possible de faire.
En plus, il est toujours agréable de voir que le concepteur suit nos évolutions personnelles et s'intéresse au sujet que l'on post même si c'est un petiit message cours pour la todo list du style "Sujet lu par Jack".
que l'on est pas comme sur certain forum l'impression de poster dans le vide.
Et c'est aussi ces interventions qui font que je me suis interessé à Panoramic plutôt qu'un autre.


@ tous

on a avec Panoramic un langage de programmation qui évolue grace à Jack
quasiment en fonction de nos besoins.
(essayer de demander cà à d'autres, une fonction de plus tous les deux jours)
de temps en temps il faut aussi admettre qu'une évolution implique quelques désagréments.

Pour la compatibilité , Perso j'ai stocké les évolutions depuis la 0.9.17
si il y a un souci je compilerai avec et repartirai sur de nouveau prog

mon avis sur les labels : je suis partagé comme beaucoup j'ai envi d'avoir fini avant d'avoir commencé et donc réticent aux complications mais celles ci en ce cas peuvent aussi éclaircir les programmes (une fonction ,un effet)

Donc je ne pense pas que ce soit à abandonner, mais je ne suis venu à la prog qu'il y a quelques semaines. .
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Invité
Invité



MessageSujet: Re: Prochaine version   Mer 12 Mai 2010 - 14:07

Il est certain que le dernier programme que j'ai fait peut largement être repris. J'ai fait des essais au mois de décembre pour afficher une page entière de données en couleurs sur des fonds colorés, le programme mettait presque 30 secondes pour afficher la page entière. Je me suis aperçu alors (mais j'étais en essais, puisqu'à l'époque je crois j'étais le 1er a avoir réussi à afficher un texte coloré sur un fond coloré autre que celui de la forme) alors que mon programme faisait une quantité de boucles et je savais que tout était à revoir.

Mais mon prog. à cellules (si c'est celui-là que tu penses), ça été une découverte parce que je ne pensais pas pouvoir suivre de cellule dans le temps d'une fraction de seconde avec tous les testes qui sont avec. Donc c'était des essais, et d'approche en approche, ce programme c'est fait.

Régulièrement lorsque je programme, il n'y a pas de cahier des charges pour dire que je vais faire comme ceci ou comme cela, ce sont les découvertes qui influent sur le programme. Lorsque celui a avancé, j'évite de trop le bouleverser. Il est évident que si je pars avec une idée précise et que je sais qu'il y aura pas de problème quant au résultat, je m'arrange pour que le programme soit structuré, mais comme beaucoup ici, on est à la découverte de Panoramic qui évolu sans cesse, et on tape sur son clavier au petit bonheur la chance.

Je sais qu'un goto allant directement sur un autre sous programme qui sortira par le return de celui-ci ne pose aucun problème à Panoramic, et lorsqu'on avait pas prévu de se resservir d'un code, comme ça été le cas pour ce programme, un goto me faisait plaisir à utiliser parce dans le cas précis, plus simple pour reprendre le programme.

Moi je pense que bien souvent un programme devrait être fait 2 fois. Une première ébauche suivi du "débogage", et une réécriture de celui-ci après toute les modifications apportées pour le finaliser (et le rendre plus simple). Encore faut-il le temps pour cela.

@+
Je rajoute ceci: Si Jack pour le codage du basic et pour les nouvelles instructions, cela pose un problème, il faut le faire savoir, et nous dire les règles à respecter pour que tu n'ais pas de problème.
Revenir en haut Aller en bas
Jean Claude

avatar

Nombre de messages : 5086
Age : 63
Localisation : 83 Var
Date d'inscription : 07/05/2009

MessageSujet: Re: Prochaine version   Sam 15 Mai 2010 - 19:14

Je suis de retour et je viens de relire tout ce sujet.

Ma première réponse, n'impliquait pas que j'étais ravi de voir la création de 3 types de Labels, mais une approbation sur le fait de pemettre les 2 façons de programmer. Un peu comme JJN4, je me résignait.
L'intervention de Cosmos remet les pendules à l'heure et mets en évidence les inconvénients (qui en l'occurence seraient plus importants que les avantages). Cela va déclencher TRACE_ON et TRACE_OFF et c'est une bonne chose.
Je ne pense pas que Jack intervient trop sur le forum, la preuve cette discussion lui a fait changer d'avis. S'il n'avait pas diffuser ses intentions, il n'y aurait pas eu l'intervention de Cosmos....
De toute façon ce qui importe c'est que l'on avance...

Attendons pour voir,

A+ sunny

PS: Bonjour à CPC. (c'est grace au 6128 que j'ai découvert la programmation).
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Contenu sponsorisé




MessageSujet: Re: Prochaine version   

Revenir en haut Aller en bas
 
Prochaine version
Voir le sujet précédent Voir le sujet suivant Revenir en haut 
Page 1 sur 1
 Sujets similaires
-
» "OK Google" omniprésent dans la prochaine version d'Android
» Vos demandes pour la prochaine version
» Offre promotionnelle : SnagIT 7.25 en version gratuite !
» Comment envoyer une détection chez avira avec Antivir 9 français - Version Classic
» Bye Bye à la semaine prochaine

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
FORUM DE DISCUSSION SUR LE LANGAGE PANORAMIC :: PANORAMIC :: Ce qui est en cours ...-
Sauter vers: