Post R36 plans

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

Post R36 plans

Art Haas
Hi.

I made the thirty-sixth release about two weeks ago, then picked up some
contract work which kept me busy. I'd meant to mail the list sooner with
a post-release note.

It took far too long between the thirty-fifth and thirty-sixth release,
and I'd like to avoid that happening again. There were a couple of
months where I got nothing accomplished, and I had a stretch of time
doing contract work which kept me busy but not with PythonCAD. It is
clear to me that more developers are needed to keep the project moving
at a decent pace and avoid long delays between releases. This note,
then, can be considered somewhat a 'call-for-help' note as well as a
'call-for-suggestions' as to what I can do to help encourage more people
to regularly contribute to PythonCAD development.

One thing I want to do, and I've said it before, is to replace the
centralized Subversion repository with a distributed SCM. I'm 99.999%
certain it will be git, as I use git for building the Linux kernel and
retrieving code from a variety of projects. One drawback to git is there
is not a native Windows client right now. Aside from the recent work
done to store the preferences in the APPDATA directory common to other
Windows programs I hear next to nothing from Windows users and don't
regularly get patches from them so I'm guessing they get PythonCAD via
the tarball releases and not Subversion.

Switching to a distributed SCM will hopefully encourage more developers
to invest some time with PythonCAD as their local copy of the tree will
be entirely theirs to play with - commit, delete, modify, etc. The
current centralized model requires people to send me patches, wait for
me to commit them, and then push my tree out. While I feel that this
model has worked well enough at the start of the project, it is time to
change and the availability of distributed open-source SCM packages
like git make a transition possible. I'll e-mail the list more info
regarding my plans and efforts shortly.

Please feel free to add your comments about what can be done to help
bring more developers into PythonCAD.

Art
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: Post R36 plans

Eric Wilhelm-2
# from Art Haas
# on Thursday 24 May 2007 11:59 am:

>One thing I want to do, and I've said it before, is to replace the
>centralized Subversion repository with a distributed SCM.

I have some doubts that this will make that big of a difference to
contributors.  Maybe there are a lot of people lurking here that will
tell you differently, but svk already runs everywhere without you
making changes to the repository, so if developers are being held back
by the centralized SCM they should have figured out svk by now.

As for "patch latency" -- if indiscriminantly handing out commit bits
for the branches/ dir doesn't do the trick, git won't either.

Casual developers in general don't typically have a great grasp of SCM
anyway.

That's just my take on it.  I think SCM is fairly minor among the number
of factors in open-source community building.

While there's no science to it, I think the time/money, skill, and
motivation factors are more significant.  What is the barrier-to-entry
for developers and what audience (i.e. profession) are they in?

--Eric
--
We who cut mere stones must always be envisioning cathedrals.
--Quarry worker's creed
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Centralized SCM not the problem

Glenn Meader
I agree that centralized SCM is not an issue preventing participation by
developers.

Other issues are much more critical.
PythonCAD is a moderately complex application.
I am a casual developer just learning Python.

One major barrier to my participation is simply figuring out how the code is
architected so that I can understand where to make changes and/or additions.

I spent a bunch of hours on this, submitted some patches for R36, but still
don't know how to get started implementing things.

For example:
Implementing Architectural dimensions (Feet, inches and fractions). I sent
Art some Python code to convert decimal feet to Arch dims, but I can't yet
figure out how to integrate that code into PythonCAD...

I'd also like to add scrollbars to the drawing area, but there's a huge
learning curve to the GTK toolkit, and I don't really understand how
PythonCAD draws into the drawing area enough to understand how implementing
scrolling would affect that.

More detailed code documentation and a detailed spec of the software
architecture would be very helpful. Like: exactly what methods in what
objects are called when a user clicks a button to do something.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Eric Wilhelm
Sent: Thursday, May 24, 2007 4:07 PM
To: [hidden email]
Subject: Re: [PythonCAD] Post R36 plans

# from Art Haas
# on Thursday 24 May 2007 11:59 am:

>One thing I want to do, and I've said it before, is to replace the
>centralized Subversion repository with a distributed SCM.

I have some doubts that this will make that big of a difference to
contributors.  

That's just my take on it.  I think SCM is fairly minor among the number
of factors in open-source community building.

While there's no science to it, I think the time/money, skill, and
motivation factors are more significant.  What is the barrier-to-entry
for developers and what audience (i.e. profession) are they in?

--Eric


_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: Centralized SCM not the problem

José Antonio Martín Prieto
Hi,
I agree with both Glenn and Eric.
I think that SCM could be justified if there were a lot of developers,
and changes to the code in the repo were dependent on Art. But this is
not the case: there are not a lot of developers.
By the way, I know how to use svn, but I don't know anything about SCM and git.

I'm, much like Glenn, a casual developer. I have coded some basic
python programs and have read a lot about python. But I really get
lost in PythonCAD code. This is a problem of mine, because PythonCAD
code is great, as are the guidelines that art wrote in the website.

I would like to help further in the development of PythonCAD. I made
up the web site and created the wiki, but I would like to do some hard
work also. But a project as complex as PythonCAD is too much for me at
the moment.

So I have a suggestion. In order to help casual developers, maybe Art
(and other expert developers, if any) could write a more exhaustive
guide for PythonCAD coding, so that the architecture is more
understandable. I know this effort could seem useless in the short
term, but I'm sure that it could encourage more casual developers in
the long term.

About the profile of potential developers, I think that there are two
groups interested in PythonCAD. First, expert coders with only basic
knowledge of CAD, and second, expert CAD users with only basic
knowledge of programming. That's why I think that my suggestion could
be useful.

-- José Antonio

On 5/25/07, Glenn Meader <[hidden email]> wrote:

> I agree that centralized SCM is not an issue preventing participation by
> developers.
>
> Other issues are much more critical.
> PythonCAD is a moderately complex application.
> I am a casual developer just learning Python.
>
> One major barrier to my participation is simply figuring out how the code is
> architected so that I can understand where to make changes and/or additions.
>
> I spent a bunch of hours on this, submitted some patches for R36, but still
> don't know how to get started implementing things.
>
> For example:
> Implementing Architectural dimensions (Feet, inches and fractions). I sent
> Art some Python code to convert decimal feet to Arch dims, but I can't yet
> figure out how to integrate that code into PythonCAD...
>
> I'd also like to add scrollbars to the drawing area, but there's a huge
> learning curve to the GTK toolkit, and I don't really understand how
> PythonCAD draws into the drawing area enough to understand how implementing
> scrolling would affect that.
>
> More detailed code documentation and a detailed spec of the software
> architecture would be very helpful. Like: exactly what methods in what
> objects are called when a user clicks a button to do something.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Eric Wilhelm
> Sent: Thursday, May 24, 2007 4:07 PM
> To: [hidden email]
> Subject: Re: [PythonCAD] Post R36 plans
>
> # from Art Haas
> # on Thursday 24 May 2007 11:59 am:
>
> >One thing I want to do, and I've said it before, is to replace the
> >centralized Subversion repository with a distributed SCM.
>
> I have some doubts that this will make that big of a difference to
> contributors.
>
> That's just my take on it.  I think SCM is fairly minor among the number
> of factors in open-source community building.
>
> While there's no science to it, I think the time/money, skill, and
> motivation factors are more significant.  What is the barrier-to-entry
> for developers and what audience (i.e. profession) are they in?
>
> --Eric
>
>
> _______________________________________________
> PythonCAD mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/pythoncad
>


--
"In a world without frontiers, who needs Gates and Windows?
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: Centralized SCM not the problem

Eric Wilhelm-2
# from José Antonio Martín Prieto
# on Thursday 24 May 2007 11:39 pm:

>So I have a suggestion. In order to help casual developers, maybe Art
>(and other expert developers, if any) could write a more exhaustive
>guide for PythonCAD coding, so that the architecture is more
>understandable.

Has there been any work in the python community to create dot (graphviz)
diagrams of code flow/linkage?  Yes that could be difficult to do as
static analysis, but maybe possible at runtime.

Possibly just adding a hotkey to dump a trace from A to B (e.g.
Ctrl+Alt+A sets the start and Ctrl+Alt+B dumps the trace.)  I'm not
familiar with the python debugging scheme, but this sort of thing would
definitely give casual developers a way to figure out what code is
being triggered by their actions in the GUI.

Maybe you want the "trace" module?  (trace.run() has to run on main() ?)  
If it means relaunching, then possibly the hotkeys are just to mark the
trace output, then maybe a post-process filter to dump just the
relevant bits?

If it requires pdb, maybe it would be beneficial to write a frontend
that allows newbies to extract this information without really learning
the debugger.  That, or a howto.

If you understand objects/classes/methods, you can probably manage to
make a useful change in a big program even without learning everything
about it.  The trouble is usually in the several hours spent trying to
figure out how we get from main() to foo.thingamajig() and/or
discovering that thingamajig is the method in question.

I spent the better part of last week discovering how mozilla's
link-clicked handling works.  It took me way too long to discover the
magic environment variable NSPR_LOG_MODULES and even then the code flow
and consequence was far from intuitive.  I think python has the tools
to make that much easier :-D

--Eric
--
Chicken farmer's observation:  Clunk is the past tense of cluck.
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: Centralized SCM not the problem

nescivi
On Friday 25 May 2007 10:00:47 Eric Wilhelm wrote:

> # from José Antonio Martín Prieto
>
> # on Thursday 24 May 2007 11:39 pm:
> >So I have a suggestion. In order to help casual developers, maybe Art
> >(and other expert developers, if any) could write a more exhaustive
> >guide for PythonCAD coding, so that the architecture is more
> >understandable.
>
> Has there been any work in the python community to create dot (graphviz)
> diagrams of code flow/linkage?  Yes that could be difficult to do as
> static analysis, but maybe possible at runtime.

does Doxygen work on Python code?

that is usually quite a good method to get to know your way around code.

sincerely,
marije
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: Doc tools are not the solution.

Glenn Meader
Doxygen works with Python. It would be a somewhat useful to have Doxygen run
on the PythonCAD code. Perhaps I will do that. I already tried PyDoc. It was
not very useful.

However using a doc tool is not a solution to the PythonCAD problem.

Doc tools are great for documenting APIs that were designed from the ground
up to be a programmer *interface* to be used by others.

However, doc tools are not so good for documenting complete applications.
This requires a human to actually write descriptions of the architecture --
how the flow of control moves between objects. How the objects actually
interact when a user clicks on some UI widget. Prose examples that
demonstrate how each major feature works... Perhaps even flowcharts...

José gives an excellent suggestion below.

Art, in what city do you live?  Perhaps someone could visit you and record
an audio interview as you describe the architecture...

I started documenting the code on the PythonCAD Wiki:
http://morgul.no-ip.com/dokuwiki/doku.php?id=program_code_description

Feel free to add your contributions to the PythonCAD Wiki!

Glenn Meader
Berkeley, CA

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of nescivi
Sent: Friday, May 25, 2007 6:07 PM
To: [hidden email]
Subject: Re: [PythonCAD] Centralized SCM not the problem

On Friday 25 May 2007 10:00:47 Eric Wilhelm wrote:

> # from José Antonio Martín Prieto
>
> # on Thursday 24 May 2007 11:39 pm:
> >So I have a suggestion. In order to help casual developers, maybe Art
> >(and other expert developers, if any) could write a more exhaustive
> >guide for PythonCAD coding, so that the architecture is more
> >understandable.
>
> Has there been any work in the python community to create dot (graphviz)
> diagrams of code flow/linkage?  Yes that could be difficult to do as
> static analysis, but maybe possible at runtime.

does Doxygen work on Python code?

that is usually quite a good method to get to know your way around code.

sincerely,
marije


_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: tracing pythoncad

Eric Wilhelm-2
In reply to this post by nescivi
# from nescivi
# on Friday 25 May 2007 06:07 pm:

>does Doxygen work on Python code?

I agree with Glen here.  I'll add that doxygen was really intended for
static code -- dynamic languages can do much more powerful things.

If someone is familiar with python's concept of runtime and debugging,
please look into this:  building a wrapper that launches pythoncad with
trace.run() would be IMO the most valuable tool for understanding what
is happening.

Glen is right about the architecture overview issue -- it would be very
valuable.

However, I imagine that fully understanding the architecture is possibly
too time-consuming and is a large conceptual burden as far as making
simple changes go.  That is, a lower barrier to entry would allow
someone who is completely unfamiliar with the architecture to make a
useful addition or change by easily discoving what bits of code are
relevant.  Or, "understanding the whole by starting with the details."  
I think it is much easier to stay motivated and not get overwhelmed if
you can clearly see what is happening and what you want to have happen.  
If you can easily make a difference, you'll keep coming back to do
more.

Just get the patience required for first-time hacking down to about 5
minutes or less (this roughly assumes a familiarity with python, but
zero familiarity with pythoncad.)  If you can give instructions as
simple as this, I think you'll have it:

  svn co \
    http://subversion.pythoncad.org:9000/svn/pythoncad/trunk pythoncad
  cd pythoncad
  # setup.py?
  python tracegtkpycad.py
  # now hit Ctrl+Alt+1, do stuff, hit Ctrl+Alt+2
  $EDITOR pycadtrace.txt

--Eric
--
So malloc calls a timeout and starts rummaging around the free chain,
sorting things out, and merging adjacent small free blocks into larger
blocks. This takes 3 1/2 days.
--Joel Spolsky
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: Doc tools are not the solution.

Floris Bruynooghe-2
In reply to this post by Glenn Meader
On Fri, May 25, 2007 at 07:41:49PM -0700, Glenn Meader wrote:
> Doxygen works with Python. It would be a somewhat useful to have Doxygen run
> on the PythonCAD code. Perhaps I will do that. I already tried PyDoc. It was
> not very useful.

I must agree here, I have before explored the code using pydoc trying
to learn my way around it.

> However using a doc tool is not a solution to the PythonCAD problem.
>
> Doc tools are great for documenting APIs that were designed from the ground
> up to be a programmer *interface* to be used by others.
>
> However, doc tools are not so good for documenting complete
> applications.

Sure, I partially agree here.  But I'll also argue that
PythonCAD/Generic *is* supposed to be an library with good API to be
used by the people hacking on the interfaces.

I have, a while ago, started to figure out to add complete docstrings
to something as basic as entity.py while reading the code.  I do
believe that a good structured program (which I'm sure pythoncad is)
and good docstrings (which it is lacking currently IMHO) help a great
deal with understanding it all.

That doesn't mean that the effort you describe, creating architecture
overviews, are not useful and important.  I just wanted to argue that
adding good docstings (and thus improving pydoc and doxygen) are also
a worthwile effort.  Maybe I should have a look at that again and
actually produce some patches...

Regards
Floris

--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: Post R36 plans

Yagnesh Desai
In reply to this post by Art Haas
Gr8 so many people on pythonCAD mailing list

I see a very important input here.

2 types of contributers

First are those programmer and have some interest in CAD
while others are those CAD users who have some programming
inclinations. I am in second lot I am still with Python cad
since I felt with "python" I might be able to
contribute. I am yet to find way to contribute since lot
of these programming terms are not in my vocab.
If some way is deviced to help contribution from the cad
users inclind on programming it would be great achievement.

I think since PythonCAD has come to level where the Programmers
should contribute more in direction to help non-programmers
so that efforts by programmers start "MULTIPLYING".

Regards

Yagnesh




-----[hidden email] wrote: -----


To: [hidden email]
From: "Art Haas" <[hidden email]>
Sent by: [hidden email]
Date: 05/24/2007 10:59PM
Subject: [PythonCAD] Post R36 plans

Hi.

I made the thirty-sixth release about two weeks ago, then picked up some
contract work which kept me busy. I'd meant to mail the list sooner with
a post-release note.

It took far too long between the thirty-fifth and thirty-sixth release,
and I'd like to avoid that happening again. There were a couple of
months where I got nothing accomplished, and I had a stretch of time
doing contract work which kept me busy but not with PythonCAD. It is
clear to me that more developers are needed to keep the project moving
at a decent pace and avoid long delays between releases. This note,
then, can be considered somewhat a 'call-for-help' note as well as a
'call-for-suggestions' as to what I can do to help encourage more people
to regularly contribute to PythonCAD development.

One thing I want to do, and I've said it before, is to replace the
centralized Subversion repository with a distributed SCM. I'm 99.999%
certain it will be git, as I use git for building the Linux kernel and
retrieving code from a variety of projects. One drawback to git is there
is not a native Windows client right now. Aside from the recent work
done to store the preferences in the APPDATA directory common to other
Windows programs I hear next to nothing from Windows users and don't
regularly get patches from them so I'm guessing they get PythonCAD via
the tarball releases and not Subversion.

Switching to a distributed SCM will hopefully encourage more developers
to invest some time with PythonCAD as their local copy of the tree will
be entirely theirs to play with - commit, delete, modify, etc. The
current centralized model requires people to send me patches, wait for
me to commit them, and then push my tree out. While I feel that this
model has worked well enough at the start of the project, it is time to
change and the availability of distributed open-source SCM packages
like git make a transition possible. I'll e-mail the list more info
regarding my plans and efforts shortly.

Please feel free to add your comments about what can be done to help
bring more developers into PythonCAD.

Art
--
Man once surrendering his reason, has no remaining guard against
absurdities
the most monstrous, and like a ship without rudder, is the sport of every
wind.

-Thomas Jefferson to James Smith, 1822
_______________________________________________
PythonCAD mailing list
[hidden email]://mail.python.org/mailman/listinfo/pythoncad

_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad