Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001687OCamlOCaml generalpublic2003-05-12 20:002013-08-31 12:46
Reporteradministrator 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001687: load_path
DescriptionEst-il bien nécessaire de mettre implicitement le directory courant dans
load_path ? Dans toploop.ml, il y a
   let set_paths () =
     (* Add whatever -I options have been specified on the command line,
    but keep the directories that user code linked in with ocamlmktop
    may have added to load_path. *)
     load_path := !load_path @ [Filename.concat Config.standard_library "camlp4"];
     load_path := "" :: (List.rev !Clflags.include_dirs @ !load_path);

Voici ce qui m'arrive: j'ai un script, exécuté par un top-level a été fait
avec une 3.06. qui commence par:
   #load "cstr.cma";
Et ce script ne fonctionne pas dans un directory qui contient un cstr.cma
dont je ne veux pas (compilé avec une version CVS de Caml...).

S'il y a un contre-exemple qui justifie . dans load_path, je suppose que je
n'ai plus qu'à l'enlever à la main en m'initialisant ? Ou alors le top-level
n'ajoute . que s'il est interactif ?

Bruno.

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000154)
administrator (administrator)
2003-05-12 20:10

En fait, je me demande si j'ai bien localisé l'origine du problème, parce
que dans un directory ne contenant pas mon .cma, les syscalls sont les
suivants:
   stat64("cstr.cma", 0xbfffed58) = -1 ENOENT (No such file or directory)
   stat64("/usr/local/lib/ocaml-3.06/contrib/cstr.cma", {st_mode=S_IFREG|0644, st_size=309344, ...}) = 0
   open("/usr/local/lib/ocaml-3.06/contrib/cstr.cma", O_RDONLY|O_LARGEFILE) = 5

Or contrib est ajouté par -I, et se trouve donc avant "" dans le load_path.
Donc le choix d'essayer . est peut-être ailleurs.

Bruno.

(0000155)
administrator (administrator)
2003-05-14 18:21

From: Bruno.Verlyck@inria.fr

> En fait, je me demande si j'ai bien localisé l'origine du problème, parce
> que dans un directory ne contenant pas mon .cma, les syscalls sont les
> suivants:
> stat64("cstr.cma", 0xbfffed58) = -1 ENOENT (No such file or directory)
> stat64("/usr/local/lib/ocaml-3.06/contrib/cstr.cma", {st_mode=S_IFREG|0644, st_size=309344, ...}) = 0
> open("/usr/local/lib/ocaml-3.06/contrib/cstr.cma", O_RDONLY|O_LARGEFILE) = 5
>
> Or contrib est ajouté par -I, et se trouve donc avant "" dans le load_path.
> Donc le choix d'essayer . est peut-être ailleurs.

Non, c'est bien le comportement normal d'ocaml: "." est toujours mis
en tete du load-path, meme en presence de -I, parce que c'est un
comportement souhaitable lors de la compilation.

Ce probleme me semble specifique aux scripts. Peut-etre faut-il un
flag special pour vider le path. Il me semble avoir vu -I- suggere'
quelque part. Ca serait plutot rigolo:

        ocaml -I- -I + -I +contrib

le "-I +" etant pour la librairie standard...

   Jacques

(0000156)
administrator (administrator)
2003-05-15 15:13

   From: Pierre Weis <pierre.weis@inria.fr>
   Date: Thu, 15 May 2003 12:39:33 +0200 (MET DST)

   > Ce qui est fait actuellement: dans le toplevel comme dans les compilos, le
   > load path contient:
   > - le répertoire courant (toujours présent, toujours en tête)
   > - les répertoires donnés par -I
   > - la librarie standard.
   > Maintenant, on peut discuter de plein de choses, e.g.
Ok, discutons.
   > - le répertoire courant doit-il toujours être en tête dans le path?
   > - faut-il une option pour l'enlever? (cf. l'option -I- de gcc)
   > - etc.
   > J'avoue ne pas avoir d'idées arrêtées, sauf que il vaudrait beaucoup mieux
   > rester compatible par défaut avec le comportement actuel.

   L'option -I- me semble respecter toutes les contraintes et devrait donc
   satisfaire tout le monde sans poser de problème à quiconque.
Pour mon usage personnel, ça suffit en effet. Pour Cash, comme il est
possible de passer des options au toplevel, je peux documenter. Mais pour
ceux qui font des scripts avec un toplevel standard, on retombe sur le
problème de troncature de la ligne #! : s'il faut passer
 -I- -I + -I +contrib
après #!path en 32 caractères, ça marche moins bien. En fait ça n'a pas
d'importance; il suffit d'utiliser #directory à la place de -I, si ça fait
bien la même chose. -I appelle Dll.add_path comme #directory ? Ah, par
contre, il faudrait une directive pour faire -I- interactivement (pas
#directory seul, svp).

Je ne vois pas dans quelle circonstance on voudrait supprimer la librairie
standard; ça ne peut être que pour la remplacer par une autre pour faire bus
error, non ? Alors -I- devrait laisser -I + ?

Pourquoi laisser le directory courant ? Je pensais que c'était pour le bus
error aussi :-), mais c'est incompatible avec un toplevel interactif; je
suis bien d'accord de ne pas changer le comportement de ce dernier, mais
dans un script, ça devient franchement douteux. Bref, pas d'idée.

Tout ceci concernait les scripts, mais dans un toplevel interactif, on ne
sait pas toujours où on en est. 2 feature wishes: ce serait bien que
#directory sans argument donne la liste courante. #undirectory (:-), i.e.
un moyen d'enlever quelque chose de load_path, ça pourrait être utile aussi.

Bruno.

(0000157)
administrator (administrator)
2003-07-07 11:31

Bruno's problem was solved in another way. What to do with -I- remains unclear.
(0006814)
doligez (administrator)
2012-01-26 23:07

We are not working on this feature, but if someone comes up with a patch to implement -I-, we will consider applying it.

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue
2012-01-26 23:07 doligez Note Added: 0006814
2012-01-26 23:07 doligez Status acknowledged => resolved
2012-01-26 23:07 doligez Resolution open => suspended
2012-01-26 23:07 doligez Description Updated View Revisions
2013-08-31 12:46 xleroy Status resolved => closed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker