benja a écrit 1211 commentaires

Au lieu de troller, lire http://wiki.openstreetmap.org/wiki/FR:Tile_usage_policy qui explique les raisons du pourquoi.

Les bons langages, ils voient un problème et ils le solutionnent. Un mauvais, il voit un problème, et il le solutionne…

Blague dans le coin, tu peux à priori tout faire avec n'importe quel language. Une liste exhaustive serait impossible à te donner. Je te conseillerais python ou ocaml si tu n'as jamais programmé avant, sinon d'approfondir le language que tu connais en testant un framework qui répond à ta problématique (interface desktop, serveur web). Aussi je te déconseille fortement de toucher que ce soit à Javascript, PHP ou à quelconque solution propriétaire.

Après ça dépend aussi l'usage que tu veux en faire: développer des trucs pour toi, pour le plaisir d'apprendre et de construire est souvent différent que de s'inscrire dans une optique professionnelle où l'on privilègie certains critères tel que la popularité et la compatibilité avec l'existant.

Ok merci pour cette réponse et ton lien factuel.

Donc à l'ère du 64 bits, tu préfères revenir à l'âge de pierre et avoir une limitation forte sur la taille des arguments ?

Oui car je ne suis pas d'accord avec ta proposition suivante. Au passage, 4MO=22bits d'adressage, ça reste rien du tout hein ;-) Si tu passes 4MO, ben pourquoi pas à 8 et pourquoi pas à 16, etc. ?

Cela ne veut pas dire qu'on fait forcément n'importe quoi. Il y a toujours une limite, mais cette fois beaucoup plus grande.

Si car en ce faisant 1) tu deviens de-facto non portable (cf ton lien!) 2) l'argv n'a jamais été prévu pour transmettre plus que le stricte minimum entre les processus. Un exemple de déficience: il n'y a pas moyen libérer cette mémoire. Corolaire du 2) unix propose d'autres moyens—portables, optimaux et efficaces—pour transmettre de l'information entre processus. Pourquoi le faire alors si ce n'est par fainéantise ?

(Je me permets de dire fainéantise car j'ai déjà "pêché" moi aussi… rétrospectivement j'aurais du mettre en place un meilleur design tout de suite, 'fin bon j'étais jeune et sous pression. tant pis pour mon employeur qui finalement a perdu plus que moi dans l'histoire: moi j'ai gardé la leçon, lui le code pourri :p).

ça fait bien longtemps que cette limitation n'existe plus….

Primo: c'est faux, tu l'écris toi-même .

Deuxio: si IBM a augmenté le défaut, je parie que c'est pour éviter de "casser" des scripts qui "fonctionnent" sous linux. J'imagine du coups qu'ils ont aussi augmenté la taille de la stack par défaut, ai-je bon ? Pour la même raison qu'il y a des buffers alloués plus grands, histoire d'éviter de "casser" tous ces programmes qui font des "petis" buffer-overflow. De là à considérer que ces programmes soient techniquement corrects, voire se comportent correctement, il y a un pas que je ne franchis pas. Autant ne pas emprunter cette route du "si c'est pas assez, on augmente puis on croise les doigts".

Tersio: Pourquoi cette limitation existe en premier lieu, i.e. pourquoi ça n'est pas complètement dynamique ? Par ce que cela a un cout, non ? À toi de me montrer qu'augmenter le défaut n'engendre pas un coût supplémentaire… (avec un peu de chance, c'est documenté par IBM). En d'autres mots, en augmentant le défaut, tout le monde paye pour les quelques utilisateurs qui programment n'importe comment… C'est pour ça que je préfère avoir un défaut plus petit, et en bonus on se rend plus vite compte que l'on fait n'importe quoi.

BTW: AIX c'est pas aussi l'OS qui mappe qq chose à l'adresse NULL ?

De plus je ne comprends pas « dans un argument de commande ». J’ai mis l’aide dans une variable, cette variable est "lue" si l’argument de la commande est "-h"… Tu peux m’expliquer ?

Argument de la commande "echo" bien sûr. Qui se retrouve dans la sortie de debug quand tu actives set -x, sortie qui deviendrait largement moins lisible pour le coups.

avec ta méthode ça devrait marcher

<Mode jaloux> méthode mentionnée dans mon premier commentaire :p </>

ça évite de coller explicitement des "\n\" à toutes les fins de ligne

Cela n'était pas nécessaire avec ta méthode non plus (aussi dans mon premier commentaire… :p).

Ton shell fais l'expansion de variables sur la commande afin de construire un ARGV. Je ne crois pas que même pour une builtin (echo/printf), il fonctionne de manière différente, ça ne serait plus posix pour le coût je suppose. Bref, le contenu de ta variable se retrouve expansé dans un buffer qui sert de ARGV, buffer qui est limité. Autant utiliser la sortie de cat directement, éventuellement à travers un autre programme en utilisant un pipe ("|") si tu dois réellement faire un traitement dessus avant de l'afficher.
Essaye avec "set -x" dans ton script, tu vas vite voir la différence.

PS2:Surtout si on l'"export"e après… que je sache le coût de stocker ces variables sera payé par tous les programmes jamais lancés par le script et leurs descendants… Bon après on va encore me dire "mais si ça marche, etc…" mais bon avec une mentalité pareille, on fini vite par construire des usines à gaz.

À noter que les variables sont remplacées comme avec les ""

Note pour la complétude: cela dépend en fait, il y a moyen de désactiver l'interpolation de variables tout comme il y a aussi moyen de supprimer une indentation.

PS: Je ne suis toujours pas convaincu que mettre tout dans une variable soit une si bonne idée. Cf mes remarques ci-dessus.

Il y a une différence entre ne plus exister et devrait être suffisante. Le jour où il lancera son script avec set -x, il va bien rigoler aussi d'avoir mis toute son aide dans un argument de commande… 'fin bon je dis ça…

PS4: pourquoi faire un "export" de la variable ? pourquoi printf ne marcherait pas ? Attention aussi à longueur maximale d'une ligne de commande qui est plus restreinte sur AIX que sur linux, un HEREDOC serait vraiment plus approprié en fait. Le ';' n'a rien à faire là non plus.

En fait c'était plus une provocation qu'une réelle suggestion :p
(Je me disais bien que le principe de voter marchait mieux quand il était secret. Mais je n'étais pas/plus au courant que ça avait été testé. Merci pour l'info !)

PS3: Si on veut vraiment utiliser uname (mais pourquoi?) alors au moins ne matcher que sur le "-s". "-a" inclue le hostname et plein d'infos superflues, ton code risque ne marchera plus si ton hostname contient "linux" (les gens qui mandatent d'utiliser AIX suivent souvent d'autres conventions étranges).

Encore mieux que de déduire à partir du nom du système, c'est de tester la feature directement. Genre

[ "x`echo -e`" = "x-e" ]
# ou encore
NL="
"
[ "x$NL" = "x`echo \n`"]

PS: au lieu de terminer les lignes avec \n\, il suffit de ne rien mettre, faire du POSIX c'est aussi apprendre à ne pas se compliquer la vie ;-)
PS2: Un cat <<HEREDOC marcherait très bien aussi…

Comment arrives-tu à la conclusion que CAP_SYSADMIN ou 4-5 autres CAP_ réduisent cette bonne idée (je suppose que tu le justifie par le fait qu'elles sont sur-représentées par rapport aux autres et donc qu'elles seraient des capabilities "fourre-tout", c'est bien cela que tu voulais dire ?) alors qu'en même temps tu dis avoir ignoré un nombre important (combien?) qui ne le sont pas ? Par exemple, si mon programme n'aurait besoin que comme seul privilège la possibilité de binder un port <1024, ne serait pas CAP_NET_BIND_SERVICE un substitut efficace à un suid root ? Idem pour tout autre privilège accordé par un "capability" autre que CAP_SYS_ADMIN… Donc bref, j'ai l'impression que tu contredis, ou alors sois plus explicite stp :)

J'ai vu que tu as posté la même question sur un autre forum (developpez.com) et que, ensuite, tu y as écris avoir trouvé une solution. Pourrait-on (au moins sur ce site…) connaître cette solution ?

Je dis ça histoire d'apprendre moi aussi quelque chose car lire la doc d'oracle/pg, ça je savais déja faire… Pour preuve: je n'ai rien vu d'étrange dans ton utilisation de decode (mis à part le fait que tu ne sais pas faire un test ">366 ou <1"). Quel est ce paramètre en plus dont tu fais mention ?

Deuxièmement, ta fameuse "user::jdatetimeToCalendar" ne devrait pas te rendre une date (ou null) directement ? Je veux dire, faire une validation de date avec des expression conditionnelles en SQL c'est un peu WTF, non ? Je vais peut-être t'apprende un truc, mais il parraitrait que certaines années il n'y a que 365 jours, c'est dingue non ?

Quid de rendre les données des plussages-moinssages publiques ?

Ensuite, le comptage devait commencer au premier janvier 2008, toutefois il a été décalé au premier février. Pourquoi ? Parce qu'aucun suicide n'a été enregistré en janvier. La rigueur, tout ça, c'est trop compliqué.

Je cite encore ta source (qui se contredirait pour le coup ?) : « L'entreprise a enregistré 28 suicides (soit un taux de 21 pour 100.000) en 2000, 23 en 2001 (18/100.000), 29 en 2002 (24/100.000), 22 en 2003 (19/100.000). Après, la série s'arrête sans explication. Compte tenu de la structure d'âge, du sexe (63% d'hommes, 37% de femmes), du fait que par définition les salariés de France Télécom ont un travail, le taux de suicide devrait se situer autour de 37 pour 100.000, selon une étude de l'Ined. »

Après, la "vraie rigueur" serait de comparer les taux parmi les sous-populations en fonction de la position hiérarchique et/ou des (changements de) conditions de travail. C'est-à-dire avoir une piste pour répondre aux questions suivantes :
- y-a-t'il eu une augmentation des suicides dans la population des cadres ?
- le cas échéant, pouvons-nous la corréler à un changement dans la manière de les diriger ou à des décisions du CA impactant leur conditions de travail ?

Même en accordant les meilleures intentions à ta source, force est de constater qu'elle n'essaye pas de répondre à ces questions. Alors: info ou intox ?

Car j'ai un problème avec SQL qui me sort l'erreur suivante: ORA-01848: day of year must be between 1 and 365 (366 for leap year)

Peut-on voir le code en question ou l'endroit qui génère l'erreure ?

DECODE(DATASTREAM.P1EFTJ,0,0,to_number(to_char(user::jdatetimeToCalendar(DATASTREAM.P1EFTJ),'YYYYMMDD')))

Je te suggère d'utiliser les conversions standards, i.e. CAST AS, ça te fera déjà un oracle-isme de moins… Btw, je reste dubitatif quant à la pertinence de faire une conversion to_char -> to number. Ne serait-il pas mieux d'utiliser TRUNC(date) voir, mieux, EXTRACT qui est standardisé SQL ?

Ce que je souhaiterai c'est dire à cette fonction que lorsque le jour n'est pas compris entre 1 et 366

Utilise CASE WHEN cond THEN … [WHEN cond2 THEN …] END à la place de ton DECODE, cf.
http://docs.oracle.com/cd/B19306_01/server.102/b14200/expressions004.htm .

PS: J'essayerais d'éviter un maximum les oracle-ismes. Là pluspart du temps il existe un fonction SQL équivalente: genre NVL -> COALESCE, TRUNC -> EXTRACT, CAST, etc. La doc de postgresql est très pratique pour cela :p

Fais-toi confiance ;-) Si tu ne sais pas, c'est simplemenent parce que ça n'a pas de sens…

Si tu enlèves tout ces détours "poétiques" et ces concepts vaseux, il ne reste pas grand chose à part un semblant d'interprèteur aux fonctionnalités un peu limitées. En survolant un peu le github, on se rend vite compte que la pluspart du code est assez répétitif, ce qui est n'est pas un gage de qualité.

C'est probablement sympa d'appeller un entier de 128 bits un ship, d'inventer (enfin ça ça reste à démontrer, laissons le bénéfice du doute) une notation "phonétique" pour les entiers mais bon ça casse pas trois pattes à un cannard. Pire ils compliquent tellement des concepts qui sont simples reconnus par tous, sans réelle justification. La seule justification que je vois c'est de rendre leur technologie délibérémment obscure afin de retarder au plus possible la révélation de l'arnaque. 200k$ pour un délire, ça fait cher quand même…

J'ai parcourus très rapidement la documentation et dans l'ensemble cela me semble plutôt cohérent ; très loin des délires de Jayce.

Idem et j'en retire la conclusion opposée, comme quoi… :D Quelques petites perles pour la route:

Especially when Urbit is young, the level of trust that a child places in its parent is high. The trust implied by automatic kernel updates is almost infinite. You can disable updates, but that's nowhere near practical yet. (Ideally we will be able to freeze the Arvo kernel, like Nock, and turn off kernel updates; but this will take years at least.) [1]

Atoms of the odor @f represent loobeans, where 0 is yes and 1 is no. Loobeans are often represented in their cubic and runic forms shown below. [2]

One truism of CS is Knuth's observation that "premature optimization is the root of all evil." Yes, but premature documentation is at least the trunk of all evil. "Documenting into existence" -- making something that doesn't exist exist, by describing it -- is the trap of all vaporware projects.

On the other hand, Urbit does exist. It doesn't need to be documented into existence. It does needs to be documented into completion. This doesn't mean simply describing the codebase. [3]

C'est pas un vaporware, c'est une arnaque-ware.

1:http://urbit.org/posts/address-space
2:https://github.com/urbit/old-doc/blob/master/doc/hoon/reference/odors.md
3: http://urbit.org/posts/roadmap

hypothèse 3

L'auteur de la question nous fait part d'un extrait de l'énoncé de son TP. Encore une fois, cet extrait est malheureux car il manque les informations nécessaires pour désambiguïser la question. N'ayant pas non plus le contexte de son cours vu que notre ami ne nous l'expose pas et que nous n'avons de toute évidence pas assisté à son cours (probablement que lui non plus finalement vu les lacunes systématiques de ses questions), il nous demande de deviner quel est le problème qui lui est demandé d'être résolu et ensuite de lui donner des solutions.

En ce qui me concerne, tant que tu ne changeras pas ta manière de faire, je laisse tomber avec toi, roger91. Parce que :

1) il serait plus honnête de ta part de nous donner toutes les informations qui sont en ta possession afin de nous éviter un travail inutile de devinette;

2) vu la constance dans ton comportement, je m'explique plus simplement ce "flou" par le fait que tu manques d'assiduité dans tes études plus que par le fait que tout tes profs soient très mauvais : je peux imaginer qu'il soit possible qu'il y aie des ambiguïtés ou des imprécisions dans un énoncé mais à la lumière tu cours que tu as du avoir, il n'est franchement pas possible qu'il demeure à chaque fois autant d'inconnues (ou bien si tu es vraiment tombé dans une mauvaise école, je te suggèrerais alors d'en changer si tu souhaites que tes études te servent à quelque chose).

Ceci n'engage que moi bien sûr, bravo à tous les autres qui ne sont pas encore découragés ;-)

J'ai eu le même message avec qupzilla puis en fait ça a quand même fonctionné. Du coup j'ai assisté un peu par inadvertance à cet évènement — que dis-je ? — cette révélation. Comme quoi, faire partie de l'élite ça ne tient pas à grand chose finalement.

Je te trouve bien sévère dans ton jugement de La Pomme. On parle quand même d'une entreprise qui vient d'annoncer qu'elle met à disposition gratuitement — gratuitement, j'insiste bien — un logiciel d'éducation à la programmation swift avec — deuxième coups de tonnerre — un clavier virtuel optimisé ! Le tout à destination des enfants du monde entier qui se formeront gratuitement — bien que l'argent ne soit pas un tabou, il ne coûte rien (hihi) de le répéter — pour devenir les futurs entrepreneurs de demain; après avoir reçu un iPad tout neuf évidemment ! Je dois dire que j'en ai presque eu la larme à l'oeil devant tant de philanthropie.

Je n'ai toujours pas saisi la finalité de la méthode décrite dans le journal

Cette méthode utilise un encoding qui permet de se passer de la récursion.

let rec fold f g e =

raté :p

ce qui s'appelle du higher-kinded polymorphism

Apparemment le higher-kinded polymorphisme serait un autre nom de "type constructor polymorphism". Dans notre cas, on peut parler simplement de higher-order polymorphisme, non ?

OCaml on a tendance à utiliser le système des modules pour cela.

Je ne vois pas en quoi le répèter le rend plus vrai… Avec Obj.magic nous sommes même maintenant à une 4e technique ;-)

D'un autre côte, il semblerait que l'objectif soit aussi d'éviter de construire explicitement l'AST du langage cible pour éviter de l'allocation.

Remarques qu'il semblerait que le language cible soit le language hôte (E-DSL). Aussi que nous construisons un AST directement, ou que nous passions par des constructeurs—sans (val op : expr -> expr -> expr) ou avec (val op : 'a. 'a expr -> 'a expr -> 'a algebre -> 'a) l'encoding illustré dans ce journal --,dans tous les cas nous avons des allocations (en tout cas en ocaml), je ne vois pas comment on pourrait s'en passer ??

(* oh le joli type de fold ;-) *)
val fold : (int -> 'a) -> ('a -> 'a -> 'a) -> expr -> 'a =

C'est simplement du first-order polymorphism, d'une fonction sur un type monomorphique. Le but du journal c'est de se passer de la récursion et utiliser le fameux encoding, et donc passer par un polymorphisme d'un plus grand genre (sic).

Maintenant que tout ça a été re-dit, la question—que nous semblons tous aussi déjà avoir soulevée—c'est de montrer quels sont les avantages une fois qu'on a passé cette étape. Là je botte en touche… (Sans doute faudrait-il partir d'un exemple qui ne soit pas un jouet.)

La meilleure… c'est discutable, non ? Pourquoi pas avec des objets ou avec la méthode ci-dessus utilisée ? Il me semble qu'avec les first class modules tu payes un certain overhead aussi, donc j'imagine aussi avec les "implicit module" (qui ne font pas encore partie du lanague iianm) ?