Documentation?
D Sievers
I'm not sure if there's any traffic on the group, or if there's some
discussion on GitHub that I should find. Please point me to the right
place!
Regardless, I'm glad to see this project exists. I'm new to the whole
SPICE thing, and have been using the gEDA suite to learn some basics.
Although the existing gschem is very good, I would really like to use
something a little more "user friendly". I understand this project is
in the beginning, but I can see the promise of having something easily
scriptable so it can hook into netlist generators, simulators, post-
processors, etc.
With that said, I hope that I can help in some way. I do have a little
coding experience but not sure how much I can contribute to the
software itself at this point. I'm working on porting it over to the
PySide bindings, since it's an easy install for Windows users.
I would be willing to work on some documentation, if you think the
code is at a point that it would be helpful. I've got the software
installed and I'm not sure exactly what to do to get that nice
screenshot on the project page. I would hope for some examples or
scripts or anything that I can reference to build it. For lack of all
else, I'm going to start pouring through the code and see what I can
learn. And of course, any "documentation standards" that you would
like to implement please note those up front, if you accept the offer.
I've heard of epydoc but would have to learn it.
And just in case you haven't heard of this particular spice
implementation, I'm trying to learn some basics of signal integrity
for work, and stumbled upon it. It has pretty good python integration
by the looks of it.
EiSpice : http://www.thedigitalmachine.net/eispice.screenshot.html
Best Regards,
Doug
Andrzej
>
> I'm not sure if there's any traffic on the group, or if there's some
> discussion on GitHub that I should find. Please point me to the right
> place!
Yes, this is the right place for discussions about Pschem. As you've
perhaps noticed, you're the first person to post on this group (big
welcome!). There were more people who expressed interest in the
project privately but I'd really like to make such communications as
public as possible (that's what open source is also about).
> Regardless, I'm glad to see this project exists. I'm new to the whole
> SPICE thing, and have been using the gEDA suite to learn some basics.
> Although the existing gschem is very good, I would really like to use
> something a little more "user friendly". I understand this project is
> in the beginning, but I can see the promise of having something easily
> scriptable so it can hook into netlist generators, simulators, post-
> processors, etc.
Indeed, these are all goals I'm targeting with Pschem. What IMO
distinguishes Pschem from gEDA (which also attempts to be a platform
rather than "just" a tool) is that Pschem is built on top of a design
database. This is to guarantee that all tools (GUI, user scripts) have
a consistent view of the whole design at all times and to enable some
more advanced features. BTW, by the "database" I mean an API, not a
file format. I haven't decided on the actual backed file format yet.
For sure the files will be user editable and likely it will be based
on XML or s-expressions.
> With that said, I hope that I can help in some way. I do have a little
> coding experience but not sure how much I can contribute to the
> software itself at this point. I'm working on porting it over to the
> PySide bindings, since it's an easy install for Windows users.
Any help would be very useful. Making sure that Pschem runs with
PySide is certainly a good idea. I've tried that once just after
PySide was first released but I hit some obscure problems.
If you're feeling ambitious, you could start hacking around user
actions related stuff. I've started doing that some time ago but I'm
not really happy with the result so far (I'll probably scrap it at
some point and start from scratch). The idea is to make the actions as
compatible with Qt framework (based on QAction?) and yet pipe all or
most of them through the Controller object, so that there is a trace
of them in the command window and that they can be started using a
python command. Maybe we could follow some patterns from LibreCAD.
I remain mostly focused on the database stuff, reverting to GUI only
when I need it to debug the database. So it should be fairly easy to
avoid collisions if you're mostly interested in the frontend.
> I would be willing to work on some documentation, if you think the
> code is at a point that it would be helpful. I've got the software
> installed and I'm not sure exactly what to do to get that nice
> screenshot on the project page.
Look at the newSchematic method in the PWindow class.
It refers to some of the gEDA designs I could find on the web. If you
download them and arrange in the specified path you can then select
"New schematic" from the menu (or press Ctrl-N) to load them into the
in-memory database.
Sorry, I know that's an ugly hack but it's just a part of my
"interactive test framework".
> I would hope for some examples or
> scripts or anything that I can reference to build it.
There is no build system yet. Just run pschem.py or pschem.sh for now.
> For lack of all
> else, I'm going to start pouring through the code and see what I can
> learn. And of course, any "documentation standards" that you would
> like to implement please note those up front, if you accept the offer.
> I've heard of epydoc but would have to learn it.
That's always a good idea. Feel free to add as many docstrings as you
like. From what I've seen epydoc is just a markup for PyDoc so I have
no problem with standardizing on it (i.e. it's still useful even
without epydoc installed).
> And just in case you haven't heard of this particular spice
> implementation, I'm trying to learn some basics of signal integrity
> for work, and stumbled upon it. It has pretty good python integration
> by the looks of it.
> EiSpice : http://www.thedigitalmachine.net/eispice.screenshot.html
That's interesting. Indeed, I wasn't aware of this project.
Thanks a lot,
Andrzej
D Sievers
Ok, that all sounds great.
For documentation, as I go through the code and figure things out, I
will add some docstrings in as you suggested. I was also thinking
about user documentation though, in addition to API documentation. For
someone like me, I had to dig through the code and find where to put
the geda/examples and geda/schematics folders. For the other stuff
you're importing, I haven't figured out the sources yet, though I am
familiar with gSim a little. I was curious if there is some kind of
Wiki or whatnot, that you would like to put some kind of "Getting
started with Pschem" documents, building out an FAQ as others discover
the project and have questions, etc. It looks like even though you're
hosting on GitHub, that Google Code would be the best place for this
kind of thing. Another option might be to build this into the app
itself, under the Help menu. I'll have to look at the PyQt
documentation to figure out how to do it, but that might be the best
(or second) home for it.
Regards to coding, sure I would be happy to look into the user actions
and do some UI work. I'll take a look at LibreCAD since you mentioned
it, and see what I can figure out.
Regards to the PySide bindings, I think I would need your input on
that one. It seems the PySide bindings only implement the "PyQt API
2", which has no QString or QVariant. Since it appears a lot of
sections in your code use QVariant, for now I'll attribute that to
your coding style. I haven't dug into it much yet, but I guess to make
it compatible to both, there would be a lot of "if API1, do A, else do
B" coding involved. I doubt you have desire to maintain that type of
code. So I guess up front, I'll let you decide if you want to stick
with API 1 only, have a lot of if/else code, or switch over to API 2.
It does sound like API 2 is the "wave of the future" but there will be
a little learning curve involved. It sounds like you can set the API
to be module specific, so it could be ported over slowly, in theory.
Let me know what you think is best.
Regards,
Doug
On Mar 24, 10:04 pm, Andrzej <ndrwr...@googlemail.com> wrote:
Andrzej
>
> [...] I was also thinking
> about user documentation though, in addition to API documentation. For
> someone like me, I had to dig through the code and find where to put
> the geda/examples and geda/schematics folders.
I understand. It would be great to have at least some user
documentation framework ready and some basic docs explaining how to
start with Pschem and what are its basic design concepts. I haven't
done that yet because (a) Pschem is nowhere near the usable state (b)
my resources are rather limited. Same is true for testing framework -
I've done some experiments with it and it indeed helps to keep the
code within the spec.
I don't want to be too fussy about the methodology, though. The
obvious limitation is that at the moment the design (including many of
the abstractions) is evolving quite quickly and in a rather
unpredictable manner (if I could predict the design issue, I'd simply
design it differently in the first place). Unless we have a large team
of programmers working on Pschem it is better to make sure we simply
talk to each other often.
> For the other stuff
> you're importing, I haven't figured out the sources yet, though I am
> familiar with gSim a little. I was curious if there is some kind of
> Wiki or whatnot, that you would like to put some kind of "Getting
> started with Pschem" documents, building out an FAQ as others discover
> the project and have questions, etc. It looks like even though you're
> hosting on GitHub, that Google Code would be the best place for this
> kind of thing.
I've left the Google Code page active but I'm not terribly happy with
it. There is a support for wiki but many important features are
missing (e.g. images have to be hosted externally). I think we should
put the docs on a more capable site (GitHub wiki? Google Sites?). Let
me know if you have some good ideas for this.
> Another option might be to build this into the app
> itself, under the Help menu. I'll have to look at the PyQt
> documentation to figure out how to do it, but that might be the best
> (or second) home for it.
I'd prefer the Help menu to point to an on-line user editable wiki
(ideally with some context aware index). This is to encourage
contributions. IMHO this should be the default setup for development
releases of Pschem and an option for stable releases (once we get to
this point).
> Regards to coding, sure I would be happy to look into the user actions
> and do some UI work. I'll take a look at LibreCAD since you mentioned
> it, and see what I can figure out.
That's just one pointer. Feel free to try anything you like, the goal
is to somehow integrate our "command line" with the Qt's action
dispatch system. I've already noticed that for some events this may
not be possible, AFAIR some of operations on MDI windows were
hardcoded in Qt.
> Regards to the PySide bindings, I think I would need your input on
> that one. It seems the PySide bindings only implement the "PyQt API
> 2", which has no QString or QVariant. Since it appears a lot of
> sections in your code use QVariant, for now I'll attribute that to
> your coding style. I haven't dug into it much yet, but I guess to make
> it compatible to both, there would be a lot of "if API1, do A, else do
> B" coding involved. I doubt you have desire to maintain that type of
> code. So I guess up front, I'll let you decide if you want to stick
> with API 1 only, have a lot of if/else code, or switch over to API 2.
> It does sound like API 2 is the "wave of the future" but there will be
> a little learning curve involved. It sounds like you can set the API
> to be module specific, so it could be ported over slowly, in theory.
> Let me know what you think is best.
Is API 2 available for Python 2 or is it only for Python 3? To be
honest, I wasn't even aware of its existence - I was happily coding to
whatever was provided by PyQt4-4.6(7) and Python-2.6(7). If switching
to API 2 requires rising the bar to PyQt4.7 - I have no problem with
that. However, if it means moving to Python 3, than I'd rather wait a
bit to let the things settle.
My general policy for dealing with dependencies is that it is OK to
rely on new stable releases of:
- Python2 (with transition to Python3 once it becomes more widespread)
- Qt
- PyQt/PySide
and have no (unless we absolutely need them) other external
dependencies for core user visible features. However, it is OK to have
additional dependencies (as long as they are free) in the development
framework, and additional dependencies (free or or non-free) for
plugins or interoperability with other tools.
Regards,
Andrzej
D Sievers
Ok, I'll try to find a good home for the documentation, set up a site,
and start using it. If it feels like too much of a hack, I'll find
something better. But, I'll keep you updated on progress when I feel
there's something that's decent.
Regards to the PyQt API's, I'll need to do some more research there.
From what I understand, API 2 is the default for Python 3, and API 1
is the default for Python 2, but I believe in Python 2 or 3 that you
can specify which API you want. However, PySide only implements API 2,
for both Python 2 and 3. I'm not sure how stable the PyQt API 2 is or
exactly what PyQt version it starts with. I'll post over to the PyQt
mailing list and get some input there. Once I have the requirements
clear, and an idea of what kind of code changes would be needed, I'll
let you know.
I agree, Python 3 seems it hasn't really caught on yet, as a lot of
packages don't support it. SciPy recently gained support, but I'm
still waiting for matplotlib and PIL to catch up.
Also, I will start playing around with the actions. Once I think I've
got something, then I'll ping you back and see if you think it's
usable.
Regards,
Doug
On Mar 28, 12:08 am, Andrzej <ndrwr...@googlemail.com> wrote:
Andrzej
I'm OK with any site as long as it does the job. I think we should
stick to something simple (plain html? wiki?) to avoid problems with
moving the docs in the future.
I was playing with PySide checking what would be required to make the
PSchem compatible with it and... I've ported PSchem to it.
It turned out not to be very difficult, remembering that PySide and
new PyQt no longer need QVariant and conversion from QString to
unicode, and that some utility functions (e.g. checking Qt version)
are implemented differently. In some places I hit real compatibility
issues (PyQt still wanted QVariant whereas PySide didn't work with
them) so I temporarily have switched off some minor features. I'll fix
these later - in the next couple of days I have to do some other work.
PySide seems to be more fussy about errors in the application code (I
found quite a few of real issues in it) so for now I've left this
backend enabled by default. You can always revert it by changing the
Globals.py file.
Regards,
Andrzej
Andrzej
>
> Also, I will start playing around with the actions. Once I think I've
> got something, then I'll ping you back and see if you think it's
> usable.
The current implementation works as follows:
- An action is a "Command" object embedding a snippet of python code
to be executed.
Commands are created either from the Console (let's call them
"synchronous") or from some UI events ("asynchronous"). This
distinction is important for tracking them in the console.
- Commands are being processed by a Controller object.
- Commands (synchronous) are stored in a History object.
This works pretty well for actions I make, which have only a couple of
sources and only one output (i.e. the console). The problem appears
when there are multiple outputs to notify. For example, an action can
be triggered by clicking a check box or by writing a command in the
console. In both cases the check box should be flipped and the command
printed out on the console. I haven't dwell on it much but I expect
problems here as the check box updates itself automatically and emits
a signal afterwards. I don't know how does the QAction framework work
in detail but maybe plugging our Command objects into it would help.
Another aspect of UI, which is currently almost completely
disconnected from the above control loop, are user actions in the
DesignView (QGraphicsView). The idea is to make most of editing
commands follow this pattern:
1. User selects an object(s).
2. User triggers a new action. This causes a new "editing mode" (e.g.
MoveMode) to be pushed on a "ModeStack".
3. User clicks on a starting point (optionally we can use mouse
position at the time action was triggered)
4. User clicks on an ending point. Editing operation is being executed
and for recurring actions the Mode goes to the state 3.
5. The action either ends automatically of for recurring actions the
user presses escape key. The editing mode is popped from the ModeStack
and the previous mode is (re)activated.
At any time user should be able to change the selection, trigger a new
action or cancel the current one.
There are also many isolated actions (zoom in/out, pan left/right/...,
Ctrl-C/X/V - which may either be implemented as sort of degenerated
Modes or simply hard coded into a default one (SelectMode)).
This part of the UI is really messy at the moment, this is because a
large fraction of the supporting framework (database editing,
Selection abstraction, visual feedback) is not implemented yet or is
broken. Still, we should think how to integrate this mechanism into
the main control loop.
Regards,
Andrzej
D Sievers
I've set up a temporary Wiki for PSchem on GitHub, and started playing
with it a bit.
I managed to make some basic kind of installing document, and a self-
hosted screenshot.
You can check it out here:
https://github.com/dwsievers/pschem-wiki/wiki
My thoughts:
1) I'm not too fond of the "Markdown" syntax... it's OK but sometimes
I feel it wastes a lot of screen real estate. There are other choices
but I like the "hints" and Markdown was the most complete. Regardless,
it does the job and was easy for me to do without having ever used it,
so it should be easy for most beginners.
2) Adding the screenshot was not so easy. Unless I missed an obvious
"upload file" link somewhere, it's not currently possible upload an
image through the site. To get the image in there, I had to make a
local git clone, add & commit the image, then push back my changes. If
you want to allow a large group of users to make howto's with
screenshots outlining steps, it's not very simple.
So, you can host images, but getting them there is a little bit of
work.
I'll see if I can't find an easier way. I'll also check out some other
Wikis, but I figure if it's possible to have one site for source and
documentation that works, that's the best option.
Regards,
Doug
On Mar 29, 3:36 pm, Andrzej <ndrwr...@googlemail.com> wrote:
Andrzej
Thank you for checking that, the result looks pretty good. I've
fetched your docs (thanks!) and put them in the wiki section of my
repository (just to keep it close to the repo). Is that OK with you?
If so I'll change the google code page to point to the new address.
I've seen your feature request on github, let's hope they will improve
wiki support in the future, it's a bit spotty now. In addition to a
file uploader, I wish they provided their standard (as in regular
github repos) web interface to the underlying git repository. That
would make it a bit easier to track forks and issues.
Regards,
Andrzej
D Sievers
Of course, moving the Wiki over to your project is the "right place"
for the docs. I was able to edit/update some stuff about symbols in
the "Installing" page with it under your project, so I'm happy as far
as being able to edit it. Unless you see a need for it, I'm going to
kill the existing repo I have so there's no debate over where the real
Wiki's home is.
When you say reference in the Google groups, I assume you're going to
leave what notes you have there for now. I would be happy to move that
documentation over to the Wiki, at which point if you want to remove
all of those docs also then there will be a single place for all docs
and code.
I'm glad you're happy with the results.
Regards,
Doug
On Apr 2, 9:07 pm, Andrzej <ndrwr...@googlemail.com> wrote:
> Hi Doug,
>
> Thank you for checking that, the result looks pretty good. I've
> fetched your docs (thanks!) and put them in the wiki section of my
> repository (just to keep it close to the repo). Is that OK with you?
> If so I'll change the google code page to point to the new address.
>
> I've seen your feature request on github, let's hope they will improve
> wiki support in the future, it's a bit spotty now. In addition to a
> file uploader, I wish they provided their standard (as in regular
> github repos) web interface to the underlying git repository. That
> would make it a bit easier to track forks and issues.
>
> Regards,
>
> Andrzej
>
Andrzej
>
> Of course, moving the Wiki over to your project is the "right place"
> for the docs. I was able to edit/update some stuff about symbols in
> the "Installing" page with it under your project, so I'm happy as far
> as being able to edit it. Unless you see a need for it, I'm going to
> kill the existing repo I have so there's no debate over where the real
> Wiki's home is.
Can you check if you can "git push" to the wiki repository?
If it doesn't work or if you find the forked repository useful then
just keep using it - it was fairly straightforward for me to merge
your changes.
> When you say reference in the Google groups, I assume you're going to
> leave what notes you have there for now. I would be happy to move that
> documentation over to the Wiki, at which point if you want to remove
> all of those docs also then there will be a single place for all docs
> and code.
I've already updated the Google Code page. I'll delete the page and
the repository once the transition is completed. The mailing list
(Google Groups) will stay - it's as good as any other.
I've also pushed a README file so that we have some basic information
available on the "project page". It was my first attempt at using
markdown - it's alright but rather simplistic. I think other formats
(I tried asciidoc before) might be better suited for the user
documentation. It looks like github renderer doesn't support all
features, though.
Regards,
Andrzej
D Sievers
I can't do the git push. I think you might have to go to your repo's
Admin tab, and add me as a collaborator, if that's something you're
comfortable with. Otherwise, I think I would have to fork it and sent
you push requests, or something like that. I'm still fairly new to git
so I'm guessing there. Let me know what you think is best. I added you
as a collaborator on my project, just to see how easy the add is. It
was very easy, but I'm not sure what it allows other to do.
Be certain though, at this point I'm not going to be touching anything
with PSchem itself, just the docs : )
For Markdown, you may be right. Actually, there is a python doc engine
called Sphinx that is based on restructured text, which is one of the
options. I'm playing around with Sphinx a bit, I'm not sure if that's
something that would be useful or not. It sounds like it can output to
multiple formats... html, pdf, and even Qt Doc format, so later any
docs could be pulled into the program's help system. Of course, I know
you said you prefer to have a Wiki link, which is good too, but it
leaves the option there. I think for now I'll stick with the Markdown
until I have a feeling for the other options, but you're absolutely
right that it's a little strange to use.
Regards,
Doug
On Apr 3, 2:49 am, Andrzej <ndrwr...@googlemail.com> wrote:
Andrzej
I've created an "organization" on github and added you to the list of
contributors. This means you should be now able to push to both the
code and wiki repository. The side effect of this change is that
project page, wiki and repository have moved (sorry about that) to a
new address:
https://github.com/PSchem/PSchem
When committing to the repo please use a branch (I'll do so as well),
unless you're absolutely certain that the change is safe (that is
minor and local) and important enough to commit it to the master
branch. Then we can periodically merge accumulated changes into the
master.
Sphinx indeed looks pretty good. Can you check if it's compatible
enough with reStructuredText
to be (at least partially) rendered on github?
For the time being please stick to markdown, I guess it will be a
while before we hit its limits.
Regards,
Andrzej
D Sievers
On Apr 3, 8:14 pm, Andrzej <ndrwr...@googlemail.com> wrote:
> Hi Doug,
>
> I've created an "organization" on github and added you to the list of
> contributors. This means you should be now able to push to both the
> code and wiki repository. The side effect of this change is that
> project page, wiki and repository have moved (sorry about that) to a
> new address:
>
> https://github.com/PSchem/PSchem
>
fresh
> When committing to the repo please use a branch (I'll do so as well),
> unless you're absolutely certain that the change is safe (that is
> minor and local) and important enough to commit it to the master
> branch. Then we can periodically merge accumulated changes into the
> master.
>
think for images for the Wiki, I would prefer to just push right to
the master, unless you object. Other Wiki changes I'll just make
directly.
As for as the actual code, yes I agree a branch is better.
I guess now I'm a little curious... do you have a recommendation on
this branching? Do I fork on github and add a branch to my fork, or
clone the main project and add a branch there, or clone the main
project and keep the branch in my local copy until there's something
good, or some other option? I can just try one and see what works
best, but I don't want to clutter up the repo unnecessarily either.
I'm hoping you might have some input.
Regarless, I'm not ready to make any real code changes... like you
said, maybe some docstrings for starters, and once I get comfortable
with what the code is doing then I will dive in to the UI/Actions. But
that's going to be a while off. I'm pretty new to PyQt and working
through Mark Summerfield's PyQt book. I've always planned to learn
PyQt but your project has given me the extra incentive to just go for
it and learn it. And of course, there's that thing called work that
gets in my way most of my day : )
> Sphinx indeed looks pretty good. Can you check if it's compatible
> enough with reStructuredText
> to be (at least partially) rendered on github?
>
> For the time being please stick to markdown, I guess it will be a
> while before we hit its limits.
>
GitHub reST compatibility to see if there are some best practices I
can learn. I think Sphinx uses some "extras" so it might be as simple
as organizing the Wiki in a certain way, pulling it from git, and
compiling the docs straight into whatever format with Sphinx. But, I
think markdown will handle what we need for now, while I figure out
the best path there.
Thanks,
Doug
> Regards,
>
> Andrzej
Andrzej
> Hi Andrzej,
>
> On Apr 3, 8:14 pm, Andrzej <ndrwr...@googlemail.com> wrote:
>
>> When committing to the repo please use a branch (I'll do so as well),
>> unless you're absolutely certain that the change is safe (that is
>> minor and local) and important enough to commit it to the master
>> branch. Then we can periodically merge accumulated changes into the
>> master.
>>
>
> Are you referring to actual changes to PSchem code, or the Wiki too? I
> think for images for the Wiki, I would prefer to just push right to
> the master, unless you object. Other Wiki changes I'll just make
> directly.
Changes to the documentation are (or at least should be) safe, so go
ahead and push your commits to the master branch.
> As for as the actual code, yes I agree a branch is better.
>
> I guess now I'm a little curious... do you have a recommendation on
> this branching? Do I fork on github and add a branch to my fork, or
> clone the main project and add a branch there, or clone the main
> project and keep the branch in my local copy until there's something
> good, or some other option? I can just try one and see what works
> best, but I don't want to clutter up the repo unnecessarily either.
> I'm hoping you might have some input.
Using your own repo is as good as using a branch in the "main" repo (I
mean, I can merge your changes just as easy). The difference is only
in the "visibility" of your work and in the potential of damaging the
repository by mistake (git makes is fairly easy).
> Regarless, I'm not ready to make any real code changes... like you
> said, maybe some docstrings for starters, and once I get comfortable
> with what the code is doing then I will dive in to the UI/Actions. But
> that's going to be a while off. I'm pretty new to PyQt and working
> through Mark Summerfield's PyQt book. I've always planned to learn
> PyQt but your project has given me the extra incentive to just go for
> it and learn it. And of course, there's that thing called work that
> gets in my way most of my day : )
Good, I'm glad you're enjoying this idea. It's indeed a lot of fun to
work with this framework. I don't think PSchem would evolve to the
state it's in now, if I started writing it using some lower level
tools. Definitely worth learning if you ever need a productive toolkit
in the future.
> I'm planning to do exactly as you suggest, and play around with Sphinx/
> GitHub reST compatibility to see if there are some best practices I
> can learn. I think Sphinx uses some "extras" so it might be as simple
> as organizing the Wiki in a certain way, pulling it from git, and
> compiling the docs straight into whatever format with Sphinx. But, I
> think markdown will handle what we need for now, while I figure out
> the best path there.
I noticed that epydoc can alternatively use reST instead of the
default epytext. Not sure how do they compare but I guess epytext
might be better supported.
Thanks,
Andrzej
Doug Sievers
I believe I have everything updated on the Wiki from the Google code site. The only minor thing was the UML diagram, which I added. It looks like the rest was taken care of by your README. So if you want to kill the Google code site I think you're ok. I also scrapped my wiki repo.
Regards to forks, branches, so on, it'll take me some time to figure out. I created a fork for now of the code, and I assume I would make a branch under the fork. But I'll need to figure out how to keep my fork (relatively) in sync with your code, and at that I guess I don't know where your "live" code is, or if I should even worry about it at this point.
Regards,
Doug
--
You received this message because you are subscribed to the Google Groups "pschem" group.
To post to this group, send email to psc...@googlegroups.com.
To unsubscribe from this group, send email to pschem+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pschem?hl=en.
Andrzej
>
> I believe I have everything updated on the Wiki from the Google code site.
> The only minor thing was the UML diagram, which I added. It looks like the
> rest was taken care of by your README. So if you want to kill the Google
> code site I think you're ok. I also scrapped my wiki repo.
Thank you for this work. I'll disable the Google Code site, then.
As you have probably noticed, I've added a new repo (PSchem_E_) to my
github page - it was originally supposed to be (and still is) a
component of PSchem (for adding scripting ability to user _designs_)
but I found it separate enough to justify making it a separate
project. I'll think how to integrate it in the PSchem code later - I'd
like to use git submodule capability, not sure if it works as
advertised, though.
As part of this effort I made some experiments with the docs.
Essentially the whole wiki is written in reST and is designed for
processing with Sphinx. At the same time it is still viewable as a
wiki, although I had to prepare a separate Home page and its
formatting differs somewhat from the version generated by Sphinx. I
guess we could adopt a similar technique for PSchem.
> Regards to forks, branches, so on, it'll take me some time to figure out. I
> created a fork for now of the code, and I assume I would make a branch under
> the fork. But I'll need to figure out how to keep my fork (relatively) in
> sync with your code, and at that I guess I don't know where your "live" code
> is, or if I should even worry about it at this point.
The github "fork" is just a separate repo (it is not updated
automatically) that just happens to be marked as "fork" in the github
UI. What I normally do is adding several "remotes" to my git client
and fetching/pushing changes from my local repo from/to these remotes.
What platform and what git client are you using? When I'm on Windows I
use tortoisegit - I found it a lot easier than any of the Linux
offerings.
Thanks,
Andrzej
Doug Sievers
Hi Andrzej,
OK, thanks for the input on Git. Indeed I've been using Windows mostly, since it's more convenient, but I plan to do some stuff on linux too since the whole gEDA stack lives there.
I'll take a look at the module and the docs. Glad to hear the docs are functioning well.
I think next time I have some ideas about stuff, I'll try to implement it myself first and then have you take a look and see if it fits. I feel a little like I'm distracting you from the more important things like design and coding, which doesn't really make me much of a contributer to the project. I'll take your initial input and try working on some gui stuff, and update the Wiki as I learn things so as other people join the project they can come up to speed quickly.
Thanks,
Doug