Your opinion does have a strong point.
Implemented/unimplemented were useful in the early stages, I think. Right now, for both Wine and ReactOS, the quality of implementation matters, not quantity.
How is Wine's system done, about documenting functions - where is it done? Source code comments? Can it be adjusted to fit ReactOS coding style?
WBR, Aleksey Bragin.
On Nov 10, 2007, at 10:16 PM, Steven Edwards wrote:
On Nov 10, 2007 4:00 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hi, no, I was speaking about something different. Take a look - http://www.reactos.org/wiki/index.php/Coding_Style there I mean this:
The implemented/unimplemented tags are really worthless because what if the API takes 20 params and 18 of them are implemented and nothing known uses the other 2 params? Do you call it implemented or unimplemented? Its better to autogenerate the docs from the function comment headers. See here, I think this is a MUCH better system and it already works. No point in developing another.
http://source.winehq.org/WineAPI/
If the API does not show up in the documented API then it should be safe to assume its not implemented. If it is implemented and not documented then its a Janitorial project.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
WineHQ's API-docu-system consists of static pages that are generated by using a single perl script. The c2man.pl script uses regex expressions to parse the source code and generate static html files. An introduction and more in-deep information about the Wine API documentation can be found on their website: http://www.winehq.org/site/docs/winedev-guide/api-docs
In my opinion, we should try to optimize the c2man.pl for our purpose.
An alternative would be to update or even rewrite the rgenstat tool. Maybe by using the pcre3 regex library, or by writing a lexer+parser+generator. The lexer and parser code could be generated by using tools like bison, yacc or lemon. The later one even supports EBNF and multi-threading.
The benefit of a tool written C or C++ would be that it would be faster and it can be used with RosBE without additional third party packages (like perl). By using regex, especially the pcre3 library which is compatible with perl-regex (the defacto standard) we could refactor the perl-script to C code.
On the otherside, for the meantime it sounds more reasonable to go with an slightly optimized wine perl script.
Perl is not a standard compiler in windows. it req active perl being install and around 56MB extra (compress form) how much it take uncompress I do not known
----- Original Message ----- From: "Klemens Friedl" frik85@gmail.com To: "ReactOS Development List" ros-dev@reactos.org Sent: Sunday, November 11, 2007 11:53 AM Subject: Re: [ros-dev] Tracking implementation API status
WineHQ's API-docu-system consists of static pages that are generated by using a single perl script. The c2man.pl script uses regex expressions to parse the source code and generate static html files. An introduction and more in-deep information about the Wine API documentation can be found on their website: http://www.winehq.org/site/docs/winedev-guide/api-docs
In my opinion, we should try to optimize the c2man.pl for our purpose.
An alternative would be to update or even rewrite the rgenstat tool. Maybe by using the pcre3 regex library, or by writing a lexer+parser+generator. The lexer and parser code could be generated by using tools like bison, yacc or lemon. The later one even supports EBNF and multi-threading.
The benefit of a tool written C or C++ would be that it would be faster and it can be used with RosBE without additional third party packages (like perl). By using regex, especially the pcre3 library which is compatible with perl-regex (the defacto standard) we could refactor the perl-script to C code.
On the otherside, for the meantime it sounds more reasonable to go with an slightly optimized wine perl script. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Magnus Olsen wrote:
Perl is not a standard compiler in windows. it req active perl being install and around 56MB extra (compress form) how much it take uncompress I do not known
Perl is an interpreter, not a compiler and it's installed on all *nix machines, including our server I'm not sure what this has to do with what frik85 was talking about? I think you should re-read his post
Ged.
What is the advantage of this wine script over doxygen ?
Maarten
On Nov 11, 2007 11:53 AM, Klemens Friedl frik85@gmail.com wrote:
WineHQ's API-docu-system consists of static pages that are generated by using a single perl script. The c2man.pl script uses regex expressions to parse the source code and generate static html files. An introduction and more in-deep information about the Wine API documentation can be found on their website: http://www.winehq.org/site/docs/winedev-guide/api-docs
In my opinion, we should try to optimize the c2man.pl for our purpose.
An alternative would be to update or even rewrite the rgenstat tool. Maybe by using the pcre3 regex library, or by writing a lexer+parser+generator. The lexer and parser code could be generated by using tools like bison, yacc or lemon. The later one even supports EBNF and multi-threading.
The benefit of a tool written C or C++ would be that it would be faster and it can be used with RosBE without additional third party packages (like perl). By using regex, especially the pcre3 library which is compatible with perl-regex (the defacto standard) we could refactor the perl-script to C code.
On the otherside, for the meantime it sounds more reasonable to go with an slightly optimized wine perl script. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev