Re: [ros-dev] Tracking implementation API status

[Aleksey Bragin]

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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Klemens Friedl]

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.

[Magnus Olsen]

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(a)gmail.com>
To: "ReactOS Development List" <ros-dev(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Ged]

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.

[Maarten Bosma]

What is the advantage of this wine script over doxygen ?

Maarten

On Nov 11, 2007 11:53 AM, Klemens Friedl <frik85(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>