Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000283OCamlOCaml generalpublic2001-02-09 14:322001-02-12 15:37
Reporteradministrator 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000283: #trace ne marche pas sur les fonctions de bibliotheque
DescriptionFull_Name: Jacques Garrigue
Version: 3.00+22
OS: FreeBSD
Submission from: isdnppp2.kurims.kyoto-u.ac.jp (130.54.16.103)
Submitted by: garrigue


#trace ne marche toujours pas sur les fonctions de bibliotheque.
Par contre ca a l'air de marcher pour les fonctions recursives definies au
toplevel.

# #trace List.map;;
List.map is now traced.
# List.map succ [1;2;3];;
List.map <--
  f:List.map <--
      f:List.map <--
          f:List.map <--
              f:List.map <--
....

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000497)
administrator (administrator)
2001-02-12 10:56

> #trace ne marche toujours pas sur les fonctions de bibliotheque.

Mais si, mais si. Le problème est que si l'on trace une fonction de
bibliothèque comme List.map qui est elle-même appelée par le code de trace
(e.g. indirectement via le formatteur), alors ça boucle, bien sûr...

(Gag récurrent qui était déjà là en Caml V2.6 je crois... Les joies
du partage de code entre système et utilisateur...)

Amicalement,

- Xavier

(0000498)
administrator (administrator)
2001-02-12 15:37

Problem specific to functions called by the compiler.
Corrected by Jacques on 2000-02-12.
(0000499)
administrator (administrator)
2001-02-12 23:35

> > #trace ne marche toujours pas sur les fonctions de bibliotheque.
>
> Mais si, mais si. Le problème est que si l'on trace une fonction de
> bibliothèque comme List.map qui est elle-même appelée par le code de trace
> (e.g. indirectement via le formatteur), alors ça boucle, bien sûr...

Ah, je n'y avais pas pense'.
 
> (Gag récurrent qui était déjà là en Caml V2.6 je crois... Les joies
> du partage de code entre système et utilisateur...)

Mouais, le fait que c'etait deja` comme ca en 2.6 ne me parait pas un
argument. Il n'est jamais agreable de se faire mettre a` la porte du
toplevel de facon aussi incivique.

Une fois compris le probleme, la correction est relativement simple:
j'ai ajoute' un lock "may_trace" dans toploop, qui n'est valide que
quand on execute du code utilisateur.
En passant je n'ai pas completement compris pourquoi le (fun v -> v)
est obligatoire dans
        if not !may_trace then
          (fun v -> v) (invoke_traced_function actual_code closure arg)
Tout ca doit dependre horriblement du bytecode, mais comme je suppose
que c'est le cas de tout trace.ml...

Voici le log de mon commit, si tu veux verifier qu'il n'y a pas de
gaffe.

Checking in toplevel/topdirs.ml;
/net/pauillac/caml/repository/csl/toplevel/topdirs.ml,v <-- topdirs.ml
new revision: 1.50; previous revision: 1.49
done
Checking in toplevel/toploop.ml;
/net/pauillac/caml/repository/csl/toplevel/toploop.ml,v <-- toploop.ml
new revision: 1.54; previous revision: 1.53
done
Checking in toplevel/toploop.mli;
/net/pauillac/caml/repository/csl/toplevel/toploop.mli,v <-- toploop.mli
new revision: 1.14; previous revision: 1.13
done
Checking in toplevel/trace.ml;
/net/pauillac/caml/repository/csl/toplevel/trace.ml,v <-- trace.ml
new revision: 1.18; previous revision: 1.17
done

Amicalement,

Jacques

(0000500)
administrator (administrator)
2001-02-13 09:51

> Une fois compris le probleme, la correction est relativement simple:
> j'ai ajoute' un lock "may_trace" dans toploop, qui n'est valide que
> quand on execute du code utilisateur.

Jacques, ton souci du détail t'honore! Merci d'avoir rebidouillé ce
code, je ne m'en sentais plus le courage :-) (C'est vraiment une
super grosse bidouille.)

> En passant je n'ai pas completement compris pourquoi le (fun v -> v)
> est obligatoire dans
> if not !may_trace then
> (fun v -> v) (invoke_traced_function actual_code closure arg)
> Tout ca doit dependre horriblement du bytecode, mais comme je suppose
> que c'est le cas de tout trace.ml...

"invoke_traced_function" ne doit pas être appelée en position tail-call,
afin d'avoir sur la pile exactement le nombre d'arguments attendu par
le code dans meta.c. J'ai simplifié ton code en

         if not !may_trace then begin
           let res = invoke_traced_function actual_code closure arg
           in res
         end

avec un petit commentaire pour dire de ne pas enlever le "let"!

> Voici le log de mon commit, si tu veux verifier qu'il n'y a pas de
> gaffe.

Ça a l'air très bien.

Amicalement,

- Xavier


- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker