Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error in Lwt_stream.​bounded_push documentation #25

Open
Khady opened this issue Sep 9, 2016 · 4 comments
Open

Error in Lwt_stream.​bounded_push documentation #25

Khady opened this issue Sep 9, 2016 · 4 comments

Comments

@Khady
Copy link

Khady commented Sep 9, 2016

In multiple function description the string Error a_api: "bounded_push" is not a valid module name is used instead of a correct type/value.

https://ocsigen.org/lwt/2.5.2/api/Lwt_stream.bounded_push-c

@aantron
Copy link
Contributor

aantron commented Oct 4, 2016

Ok, while debugging this, I found:

  • This occurs on references to methods (obviously).
  • ocsigen.org's a_api wiki extension expects method references to have the syntax method Path.class#method (note the #) [1], [2].
  • wikidoc generates syntax method Path.class.method (note the .) [3].
  • ocsigen.org therefore treats the class part as an attempt at a module name, resulting in the observed messages.

I can submit a PR, but to which project? IMO since wikidoc simply outputs the path that ocamldoc provides, we should change ocsigen.org to accept that syntax.

@Drup
Copy link
Member

Drup commented Oct 4, 2016

@aantron I would say it's better to fix wikidoc here, but honestly, do what is the easiest. ;)

@aantron
Copy link
Contributor

aantron commented Oct 4, 2016

Why?

It's easiest for me to fix wikidoc, because I can run it locally to test my work. But the fix would be replacing the last . by #, which IMO is the wrong thing to do for the long term. It's better to just be consistent about format. Since this error has not been reported before (apparently), I don't think I'll break anything by messing with ocsigen.org. So, as long as it's possible to deploy the fix with relative ease, I prefer to fix here. I'll submit a PR.

@Drup
Copy link
Member

Drup commented Oct 4, 2016

So, as long as it's possible to deploy the fix with relative ease

Yes, that's precisely what I'm worried about ... @vasilisp, @balat ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants