Mon premier LISP (sniff!)

[nG! Hebus]

Bon alors c'est qu'un début mais je sais dessiner un cylindre en 3D :)

 

(defun c:cylindretest_SDU ()
(setq a (getpoint "\nSpécifier le centre : "))
(setq b (getpoint "\nDimension du rayon : "))
(setq c (getpoint "\nLongueur du tube : "))
(command "cylindre" a b c "")
(princ)
)
(princ)

 

je viens plus voir si vous avez des choses à dire niveau "grammaire", histoire que j'aille dans le bon sens :)

[Aleck_Ultimate]

Salut.

 

En tant que trés débutant moi même, je me permet cette remarque : on peut tout condenser dans un seul setq.

 

 

(setq a (getpoint "\nSpécifier le centre : ")
       b (getpoint "\nDimension du rayon : ")
       c (getpoint "\nLongueur du tube : ")
) ;Fin de setq

[nG! Hebus]

Salut Aleck,

 

Merci pour la remarque ;)

 

(Dommage j'aime bien la façon dont c'est rangé actuellement avec les "setq")

 

Du coup est ce que quelqu'un sais si ça "réduit" la taille ou vitesse d'éxécution du programme de le mettre comme Aleck le propose par rapport à ma version?

 

Cordialement

[(gile)]

Salut,

 

Première chose, bravo.

Tu l'as fait tout seul et ça marche (quand c'est toi qui teste).

 

Maintenant il faut envisager si l'utilisateur ne fait pas exactement que tu (la routine) attends de lui.

Aux invites : "Dimension du rayon" et "Longueur du tube", on a envie de répondre en entrant directement une valeur numérique au clavier, or la fonction getpoint attends un point. Si j'entre 5, par exemple, getpoint va prendre le point à 5 unités dans la direction du curseur par rapport au dernier point (celui stocké dans la variable LASTPOINT, pas le dernier spécifié dans ce LISP) ce qui, fort probablement, va donner un résultat imprévu.

 

Le rayon et la longueur du tube sont des distance, il est donc naturel d'utiliser plutôt la fonction getdist prévue à cet effet. De plus getdist prend optionnellement comme premier argument, un point de base pour, justement spécifier un point à l'écran avec une ligne élastique et interprète correctement une entrée au clavier (getdist attend un nombre).

 

Donc, tu peux essayer :

[...]
(setq a (getpoint "\nSpécifier le centre : "))
(setq b (getdist a "\nDimension du rayon : "))
[...]

 

Étape suivante, et si l'utilisateur faisait Entrée au lieu de spécifier le centre...

Peut-on l'éviter ou y remédier ?

(à suivre...)

[Aleck_Ultimate]

J'ignore si ça influence la vitesse d’exécution (quoique je le présume fortement), mai c'est plus rapide à taper, tu t'épargne la tape d'un dizaine de caractère, et de ce que j'ais déjà vue, plus les LISP sont gros plus on tend à la concision ne serai-ce que par souci de clarté.

 

Et puis là c'est mal aligné parce que j'ais retapé derrière, mais si tu avait fait un retour à la ligne dans VLISP tes lettres et la parenthèse fermante seraient alignés bien proprement.

 

EDIT : Les cours de Maître (gile) sont toujours aussi passionnant, merci.

[nG! Hebus]

La c'est surement mieux comme ça :)

 

(defun c:cylindretest_SDU ()
(setq a (getpoint "\nSpécifier le centre : "))
(initget (+ 1 2 4)
	(setq b (getdist a "\nDimension du rayon : "))
	(setq c (getdist a "\nLongueur du tube : "))
)
(command "cylindre" a b c "")
(princ)
)
(princ)

 

Par contre du coup si je tape "entrée", j'aimerais qu'il me retourne la dernière valeur entrée pour cette même commande/pareil pour la longueur et non pas l'erreur actuelle...( Erreur : nombre d'arguements trop important )

 

 

EDIT : HAAAAAAAAAAAA, il veut plus fonctionner qu'est ce que j'ai fait... Non mon

beau LISP...

________________________________________________________________________________________

 

EDIT 2 : FIND THEM

 

(defun c:cylindretest_SDU ()
(setq a (getpoint "\nSpécifier le centre : "))
(initget 7)
	(setq b (getdist a "\nDimension du rayon : "))
(initget 3)
	(setq c (getdist a "\nLongueur du tube : "))
	(command "cylindre" a b c "")
(princ)
)
(princ)

 

Bon par contre j'aurais aimer ne pas avoir à remettre initget à chaque ligne... Je suis preneur d'un conseil la dessus :)

PS je potasse ce week-end ;) et Lundi ça va coder sec !

[bonuscad]

Attention:

 

Tu as besoin "d'armer" (initget) avant chaque fonction (get"xxx")

Dans ton code (initget (+ 1 2 4) ne sert qu'à (setq b (getdist a "\nDimension du rayon : ")),

tu doit le réarmer avant (setq c (getdist a "\nLongueur du tube : "))

 

Autre chose, tu fais des appel à (command) et quand tu utilise des fonction de dessin, il faut penser à la valeur de (getvar/setvar "OSMODE") car les accroches objets peuvent te donner des résultats imprévus.

[(gile)]

C'est super, tu avances.

 

Mais j'avais dit : "Étape suivante, et si l'utilisateur faisait Entrée au lieu de spécifier le centre... ", essaye, juste pour voir...

[philsogood]

tu codes au lieu de bosser??

branleur!! :P

tu fais ça après tes 41 heures j'espère!!

Phil

[nG! Hebus]

C'est super, tu avances.

 

Mais j'avais dit : "Étape suivante, et si l'utilisateur faisait Entrée au lieu de spécifier le centre... ", essaye, juste pour voir...

 

----**FAIL!**----

 

__________________

*****END GAME*****

__________________

 

*****CREDITS******

 

***Gile CHANTEAU***

***********as**********

***MASTER (Gile)***

__________________

 

 

 

J'ai oublié le "if" , merci ;)

 

Allez bon week-end, Lundi je reviens et j'aurais

(defun hardmode ()
(if
(initget 1 "Oui Non")
 (setq del (getkword "\nEst ce que Gile est un bon maitre? [Oui/Non] : "))
 (princ)
(initget 1 "Oui oui")
 (setq del (getkword "\nSon eleve par contre est mauvais? [Oui/Oui] : "))
)
)
(princ)

[nG! Hebus]

tu codes au lieu de bosser??

branleur!! :P

tu fais ça après tes 41 heures j'espère!!

Phil

 

D'ailleurs je vais pas tarder tu viens en fumer une en speed ? porte de d'hab?

 

PS : pas ma faute j'ai pas les infos de mes fournisseurs pour avancer...

[(gile)]

tu codes au lieu de bosser??

branleur!! :P

tu fais ça après tes 41 heures j'espère!!

Phil

 

Pourquoi? coder c'est pas bosser ?

[Aleck_Ultimate]

Non ! Coder c'est du loisir !

 

Enfin presque...

[didier]

Coucou

 

Je me permets d'intervenir,

Un : parce que j'aime les gens qui s'y mettent et qui s'y collent, il y en a tellement qui aimeraient savoir courir avant de savoir marcher.

Je ne connais pas la portée de mon site mais j'aimerais contribuer à votre apprentissage.

Deux : coder c'est bosser car si tu trouves une solution qui te fait gagner du temps (de travail), chaque fois que tu lanceras la routine et que le dessin (le calcul) se fera en une seconde et qu'à la main tu aurais mis une minute (avec des risques d'erreurs) tu gagneras une minute de travail, si tu as mis un quart d'heure à écrire ta routine, dès la seizième fois tu vas aller plus vite que celui qui n'a pas codé.

mon exemple en minute et en secondes n'est qu'un exemple mais c'est l'esprit.

sache que dans certains cas c'est des heures de gagnées à la fin de la journée...

Certes aujourd'hui tu mets deux heures à écrire un code, rapidement tu vas accélérer en mémorisant les actions.

Trois : je rajoute mes BRAVOS à ton travail

 

Amicalement

 

 

 

[Invité Patrick]

Félicitations pour t'être lancé. Un des avantages du LISP, c'est l'immédiateté (pas de compilation), essentiel quand on débute pour ne pas se sentir écrasé par l'environnement .NET qui est un peu plus intimidant.

 

Ce sentiment d'avoir écrit quelques lignes qui marchent et qui produisent un résultat, d'être aux commandes du logiciel et plus seulement passif, et surtout d'avoir devant soit une porte ouverte vers... l'infini? Ben oui, quand on programme on peut faire à peu près n'importe quoi.

[nG! Hebus]

Merci à tous pour vos messages d'encouragements !

 

Je reviens poser des questions dès que je bloc et pour me faire corriger :) (prépare le fouet Gile ! **OWI le fouet !!!**)

 

@Didier : je savais pas que t'était fan de BD :)

[didier]

Coucou

 

Je ne suis "fan" de personne, j'aime pas les gens (hihi)