gtkdoc help wanted tickets

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

gtkdoc help wanted tickets

Stefan Sauer-4
hi,

for the near future I won't be able to work on gtk-doc feature requests.
I am cleaning up the code to make it testable and converting the silly
integrations tests into unit tests. This will help to get pasring
issues/bugs under control with less chance of causing regressions.

Here are the current feature requests, if someone would like to help:

https://gitlab.gnome.org/GNOME/gtk-doc/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=4.%20Help%20Wanted&label_name[]=4.%20Newcomers

Remember, it is now python, so no perl knowledge needed anymore.


Also is there someone who could help to turn gtkdoc into something that
can be published on pypy, so that people can pull the latest with pip?


Thanks,

Stefan


_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: gtkdoc help wanted tickets

Bastien Nocera
On Fri, 2018-11-30 at 13:08 +0100, Stefan Sauer wrote:

> hi,
>
> for the near future I won't be able to work on gtk-doc feature requests.
> I am cleaning up the code to make it testable and converting the silly
> integrations tests into unit tests. This will help to get pasring
> issues/bugs under control with less chance of causing regressions.
>
> Here are the current feature requests, if someone would like to help:
>
> https://gitlab.gnome.org/GNOME/gtk-doc/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=4.%20Help%20Wanted&label_name[]=4.%20Newcomers
>
> Remember, it is now python, so no perl knowledge needed anymore.
>
>
> Also is there someone who could help to turn gtkdoc into something that
> can be published on pypy, so that people can pull the latest with pip?

Having filed a bunch of feature requests and bugs against gtk-doc
recently, I ran into the problem that, in addition to my Python only
being slightly better than my Perl, I had trouble finding what parts of
the code generated the code that I wanted, and how to create small test
cases for the problems I was filing bugs about.

Some guidance on the bugs, like which function should be modified, or
where to start prodding, would definitely be useful, at least until the
internals themselves are better documented.

(as for PyPi support, I personally build gtk-doc in jhbuild, and build
my modules that use gtk-doc in jhbuild as well, so I always have the
latest gtk-doc to generate docs, contributors would probably want to
use gtk-doc from git in any case)

_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: gtkdoc help wanted tickets

Stefan Sauer-4
On 11/30/2018 03:14 PM, Bastien Nocera wrote:

> On Fri, 2018-11-30 at 13:08 +0100, Stefan Sauer wrote:
>> hi,
>>
>> for the near future I won't be able to work on gtk-doc feature requests.
>> I am cleaning up the code to make it testable and converting the silly
>> integrations tests into unit tests. This will help to get pasring
>> issues/bugs under control with less chance of causing regressions.
>>
>> Here are the current feature requests, if someone would like to help:
>>
>> https://gitlab.gnome.org/GNOME/gtk-doc/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=4.%20Help%20Wanted&label_name[]=4.%20Newcomers
>>
>> Remember, it is now python, so no perl knowledge needed anymore.
>>
>>
>> Also is there someone who could help to turn gtkdoc into something that
>> can be published on pypy, so that people can pull the latest with pip?
> Having filed a bunch of feature requests and bugs against gtk-doc
> recently, I ran into the problem that, in addition to my Python only
> being slightly better than my Perl, I had trouble finding what parts of
> the code generated the code that I wanted, and how to create small test
> cases for the problems I was filing bugs about.
>
> Some guidance on the bugs, like which function should be modified, or
> where to start prodding, would definitely be useful, at least until the
> internals themselves are better documented.
Git has doc/gtkdoc.dot, which helps to understand what happens at which
stage. With the cleanups in the code base I also try to make it more
hackable (etc add comment describing how each tool works). I recently
added new tests for gtkdoc-scan and gtkdoc-mkdb and these are relative
straight forward python unittests, so if you have a code snippet that
gets not properly parsed, we an easily turn this into a test (I think
you files some for 'unsigned' in parameters and I will probably cover
this with the tests in the coming days.
There are still lots of parts that are not very testable and it is going
to take a while to refactor the code :/
> (as for PyPi support, I personally build gtk-doc in jhbuild, and build
> my modules that use gtk-doc in jhbuild as well, so I always have the
> latest gtk-doc to generate docs, contributors would probably want to
> use gtk-doc from git in any case)
>
Thats a good point, maybe then this is not so important.

Stefan


_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list