[Caml-list] Problem with ocamlc and recursive and parametrized classes

[Caml-list] Problem with ocamlc and recursive and parametrized classes

[Frederic Tronel]

Hi,

I'm using ocaml version 3.06 for a industrial project.
I'm facing a well-known problem I think, that is related to
the use of recursive and parametrized classes.
Actually, adding a single line of code in one of my class generates
a hang up in the compilation process. The incriminated code is much too 
long to be posted on the list, and I'm not able to reproduce the 
phenomenon on smallest examples. But basically ocamlc seems to run in an 
long loop consuming more and more memory. After two or three minutes and 
more than 150Mo consumed, I stop the process.
Should I try to insist (is there any warranty on the finiteness of the 
compilation ?), should I try to simplify my code (not really possible at 
this point of the project). Is there any undocumented option of the 
compiler that could help track the problem ?

Thanks for any clue to solve this "embarassing" problem.

Best regards,


Frederic.



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Problem with ocamlc and recursive and parametrized classes

[Frederic Tronel]

Frederic Tronel wrote:
 > Hi,
 >
 > I'm using ocaml version 3.06 for a industrial project.
 > I'm facing a well-known problem I think, that is related to
 > the use of recursive and parametrized classes.
 > Actually, adding a single line of code in one of my class generates
 > a hang up in the compilation process. The incriminated code is much too
 > long to be posted on the list, and I'm not able to reproduce the
 > phenomenon on smallest examples. But basically ocamlc seems to run in an
 > long loop consuming more and more memory. After two or three minutes and
 > more than 150Mo consumed, I stop the process.
 > Should I try to insist (is there any warranty on the finiteness of the
 > compilation ?), should I try to simplify my code (not really possible at
 > this point of the project). Is there any undocumented option of the
 > compiler that could help track the problem ?
 >
 > Thanks for any clue to solve this "embarassing" problem.
 >
 > Best regards,
 >
 >
 > Frederic.
 >


I reply to myself, since it seems I was too prompt to post on the list. 
In fact after an ultimate try and few hundred megabytes of memory later,
ocamlc.opt was able to produce the code.
Sorry for the previous post. Is there any plan to improve the behaviour
of the compiler in the future ? (if possible of course).


Frederic.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Problem with ocamlc and recursive and parametrized classes

[Alessandro Baretta]

Frederic Tronel wrote:
> Frederic Tronel wrote:
>  > Hi,
>  >
>  > I'm using ocaml version 3.06 for a industrial project.
>  > I'm facing a well-known problem I think, that is related to
>  > the use of recursive and parametrized classes.
>  > Actually, adding a single line of code in one of my class generates
>  > a hang up in the compilation process. The incriminated code is much too
>  > long to be posted on the list, and I'm not able to reproduce the
>  > phenomenon on smallest examples. But basically ocamlc seems to run in an
>  > long loop consuming more and more memory. After two or three minutes and
>  > more than 150Mo consumed, I stop the process.
>  > Should I try to insist (is there any warranty on the finiteness of the
>  > compilation ?),

Yes and no. Yes if the compiler is correct, but occasionally 
a bug might slip in, and cause the compiler to loop endlessly.

> Sorry for the previous post. Is there any plan to improve the behaviour
> of the compiler in the future ? (if possible of course).

I don't want to sound flamish, but I really don't think this 
question is appropriate on this mailing list.

Best wishes for your O'Caml project.


Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Problem with ocamlc and recursive and parametrized classes

[Frederic Tronel]

To close the thread, I should mention that the compilation eventually 
ends up in almost an hour. So the compiler was not locked in an endless 
loop. I had this feeling.

> 
> Yes and no. Yes if the compiler is correct, but occasionally a bug might 
> slip in, and cause the compiler to loop endlessly.

> 
>> Sorry for the previous post. Is there any plan to improve the behaviour
>> of the compiler in the future ? (if possible of course).
> 
> 
> I don't want to sound flamish, but I really don't think this question is 
> appropriate on this mailing list.

In fact, my question was rather is there any improvements about this 
"problem" integrated in the CVS for example.

> Best wishes for your O'Caml project.

Thanks a lot.


Frederic.




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Problem with ocamlc and recursive and parametrized classes

[Yang Shouxun]

Frederic Tronel wrote:
 >To close the thread, I should mention that the compilation eventually 
 >ends up in almost an hour. So the compiler was not locked in an 
 >endless loop. I had this feeling.

According to my experience, if your OCaml program runs too slow, that's 
an indicator of bad algorithm or implementation (for instance, you 
intend to use a good-enough algorithm, but your implementation is faulty 
due to oversight), rather than bad compiler implementation, unless you 
can narrow the problem down and provide a reproducible case for the rest 
of list to review.


 >In fact, my question was rather is there any improvements about this > 
 >"problem" integrated in the CVS for example.

As said above.

Best!
shouxun



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Problem with ocamlc and recursive and parametrized classes

[Stefano Lanzavecchia]

> Frederic Tronel wrote:
>  >To close the thread, I should mention that the compilation 
> eventually  >ends up in almost an hour. So the compiler was not locked

> in an  >endless loop. I had this feeling.
> 
> According to my experience, if your OCaml program runs too slow, 
> that's an indicator of bad algorithm or implementation (for instance, 
> you intend to use a good-enough algorithm, but your
> implementation is faulty 
> due to oversight), rather than bad compiler implementation, 
> unless you 
> can narrow the problem down and provide a reproducible case 
> for the rest 
> of list to review.

As Frederic said in its original message, it's not his programs that
takes one hour to run. It's the compiler that needs one hour to compile
his program...
-- 
WildHeart'2k2 - mailto:stf@apl.it
Homepage: currently offline

[[All I Ever Learned, I Learned From Anime: //
  Love knows no race, species, or logic.]]

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Problem with ocamlc and recursive and parametrized classes

[Jacques Garrigue]

From: Frederic Tronel <Frederic.Tronel@inrialpes.fr>

> I reply to myself, since it seems I was too prompt to post on the list. 
> In fact after an ultimate try and few hundred megabytes of memory later,
> ocamlc.opt was able to produce the code.
> Sorry for the previous post. Is there any plan to improve the behaviour
> of the compiler in the future ? (if possible of course).

Any "unexpected" behaviour of the compiler can be seen as a bug, so
yes, if we understand what the problem is, it should be solved. Or at
least we could define workarounds to avoid stretching the compiler's
ability too much.

I believed that most problems with efficiency were already solved in
3.06, but you might have found a new one. Please write a bug report.

By the way several infinite loops were solved since 3.06, but this
doesn't seem to be your problem.

        Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners