Pycrust enhancement with plugins

Hello all,

Because Pycrust is my most beloved program in the
wxPython distribution (and the best python shell),
I want to customize it and make it commonly extensible,
without breaking the code.

The best solution: Plugins!
(For me, with this mechanism, we could improve it simple).

Dan Pozmanter introduced with DrPython this
simple, highly functional mechanism,
which I tried to adopt into Pycrust.

Thanks to Dan for this geat Editor!!
All my coding I do with DrPython, and it saves
me a lot of time!

I placed the plugins directory directly under Py to eliminate
the Directory switching.
It is my first Prototype.
    
My reasons:
  - Pycrust should stay small, and with adding more features, can become bloated,
      and will maybe getting slower.
  - Everyone can decide, what functionality he/she wants to add yourself.
  - New code will not break other code (simply deactivate the plugin, if
      it will come to problem and/or try to solve the problem)
  - some seldom used function or functions, which not many user need,
      could also be back up in plugins (for example the "free editing" mode)
      (I don't know, if it is possible so easy, but this come into my mind)
  
To the two plugins (I have posted them a few months ago,
but I didn't get any response; all the same) some words:

  AutoCompManager:
    simply try out, it should be self explaining.
    it isn't complete yet (multiple inheritence, show call tip,
      filter for classes, show class trees, ....) are in my mind.
    It could be especially useful for beginners.
    (I use it often to see the functions separated in the resective base classes;
     searching is easy)
    if you type for example "*get" in the edit box (all functions which contains get are listed)
    "=get" all this which contains "get", but don't start with "get"
    Coloring of different base class should simplify the recognition of them.

    you can navigate (up down) the listctrl without losing the focus in the textctrl.
    
    Sortable after Function name and after Classes.
    Show Derived and non derived members.
    Shrink (non shrink isn't working properly yet)
    
  IdleColorStyle:
    I like the colouring of IDLE, so I tried to duplicate this.
    For (my own reasons), I didn't use the EVT_STYLE_NEEDED event,
      because the parsing would be much more difficult,
      and I assigned the styles for prompt, stdin, and stderr directly.
      Maybe someone is other opinion, but this I found much more simpler.
      Still not perfect (String parsing for example).
    It could also simplify the transition for people, who uses IDLE
      and the Pycrust. :wink:
      
    And this is the good point:
     Plugins are not part of the "core" Pycrust, and if someone don't like them,
       simply do not include them or customize them to your needs.
      
I really enjoy this playing with Pycrust
  and additionally Pycrust itself helps me to enhance Pycrust!! :slight_smile:

I would be interested, if it is commonly found useful,
  but please no critic on code at this time (as said protoype).

Any suggestions, comments and even ideas for new PyCrust plugins are
highly welcomed.
And also is this working for everyone (also on Linux?)

@Robin: Could you in principle imagine to include such
  a functionality into a further release?

If so: Would you prefer sending patches?

There is still the PyCrust project on Sourceforge, but not maintained anymore for years.
Should we continue there?
Create a new project (under another name)?
Shall we restrict the project to only make plugins and offer them for download?

I have plans to enhance the plugin functionality (Plugin Help, preferences, About)
Load plugins manually, after you started PyCrust.

Beside plugins, short scripts (or in other words macros) would also be interesting.

Enough said.

To (safely) try out:
  please make a backup or better copy your py directory (name it py_original or similar)
    then in the original py, you excract my changed files.

http://mitglied.lycos.de/drpython/pycrustpluginsample12_Feb_2006.zip
(to minimize the download size (32 kb), I have only packed the changed files)
  
Cheers,

···

--
Franz Steinhaeusler

I have a panel that contains a TextCtrl for the user to enter their
email address. I want to check that it is a valid email address when the
user leaves that text control (by tabbing out or clicking on another
TextCtrl).

I haven't had much success with TextCtrl events (EVT_KILL_FOCUS doesnt
seem to work, nor have I had any luck with EVT_TXT_ENTER bound to the
other controls on the page) and because I don't want to have the user to
have to hit a submit button when they are done, I'm not sure how to use
a validator on this either.

Any help would be greatly appreciated.

Thanks,

Matt

matthew@departurempls.com wrote:

I have a panel that contains a TextCtrl for the user to enter their
email address. I want to check that it is a valid email address when the
user leaves that text control (by tabbing out or clicking on another
TextCtrl).

I haven't had much success with TextCtrl events (EVT_KILL_FOCUS doesnt
seem to work, nor have I had any luck with EVT_TXT_ENTER bound to the
other controls on the page) and because I don't want to have the user to
have to hit a submit button when they are done, I'm not sure how to use
a validator on this either.

How are you using EVT_KILL_FOCUS.

On most platforms, the following should work...

class ...:
    def __init__(self, ...):
        ...
        self.tc = wx.TextCtrl(self, -1, "")
        self.tc.Bind(wx.EVT_KILL_FOCUS, self.OnValidate)
        ...
    def OnValidate(self, evt):
        ...

Are you doing something like the above, or something different?

- Josiah

On another note, make sure you are generous in what you accept as an e-mail address. Remember that things like plus signs (+), multiple dots (.) and underscores before the @ sign, and unusual TLDs are all legitimate parts of an e-mail address.

(Having an unusual address myself I like to evangelize this when I hear about people doing address validation.)

Regards,
Nate

···

On Feb 12, 2006, at 10:07 AM, matthew@departurempls.com wrote:

I have a panel that contains a TextCtrl for the user to enter their
email address. I want to check that it is a valid email address when the
user leaves that text control (by tabbing out or clicking on another
TextCtrl).

Thanks so much for your quick response!

You know, I was mimicking they way wxGlade sets up binds self.Bind(wx.EVENT_KILL_FOCUS, self.OnValidate, self.tc)... but doing it the way you suggested worked like a charm. Thanks again.

- Matt

Josiah Carlson wrote:

···

matthew@departurempls.com wrote:
  

I have a panel that contains a TextCtrl for the user to enter their
email address. I want to check that it is a valid email address when the
user leaves that text control (by tabbing out or clicking on another
TextCtrl).

I haven't had much success with TextCtrl events (EVT_KILL_FOCUS doesnt
seem to work, nor have I had any luck with EVT_TXT_ENTER bound to the
other controls on the page) and because I don't want to have the user to
have to hit a submit button when they are done, I'm not sure how to use
a validator on this either.
    
How are you using EVT_KILL_FOCUS.

On most platforms, the following should work...

class ...:
    def __init__(self, ...):
        ...
        self.tc = wx.TextCtrl(self, -1, "")
        self.tc.Bind(wx.EVT_KILL_FOCUS, self.OnValidate)
        ...
    def OnValidate(self, evt):
        ...

Are you doing something like the above, or something different?

- Josiah

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Thanks so much for your quick response!

You know, I was mimicking they way wxGlade sets up binds
self.Bind(wx.EVENT_KILL_FOCUS, self.OnValidate, self.tc)... but doing it
the way you suggested worked like a charm. Thanks again.

From what I understand, the only events that get passed from a control
to its parent (and on up until it is handled...) are wx.CommandEvent
derived events. I don't know precisely which events are derived from
wx.CommandEvent, but when all else fails, try both kinds of bindings.

- Josiah

···

Matthew Korsmo <matthew@departurempls.com> wrote:

Josiah Carlson wrote:
> matthew@departurempls.com wrote:
>
>> I have a panel that contains a TextCtrl for the user to enter their
>> email address. I want to check that it is a valid email address when the
>> user leaves that text control (by tabbing out or clicking on another
>> TextCtrl).
>>
>> I haven't had much success with TextCtrl events (EVT_KILL_FOCUS doesnt
>> seem to work, nor have I had any luck with EVT_TXT_ENTER bound to the
>> other controls on the page) and because I don't want to have the user to
>> have to hit a submit button when they are done, I'm not sure how to use
>> a validator on this either.
>>
>
> How are you using EVT_KILL_FOCUS.
>
> On most platforms, the following should work...
>
> class ...:
> def __init__(self, ...):
> ...
> self.tc = wx.TextCtrl(self, -1, "")
> self.tc.Bind(wx.EVT_KILL_FOCUS, self.OnValidate)
> ...
> def OnValidate(self, evt):
> ...
>
> Are you doing something like the above, or something different?
>
> - Josiah
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

There used to be an STCStyleEditor.py which was supplied with wxPython.
It handled all of the color changing and style definitions for
stc-derived controls. I don't know what happened to it, but it may be
useful for you.

In terms of styling output from stdout and stderr, that sounds like a
useful addition, though I question the use of fully manual syntax
styling. Future versions of the stc and scintilla editor control may
include the multi-language syntax highlighting (if the sinkworld project
is ever merged), which would handle such things quite nicely.

- Josiah

···

Franz Steinhäusler <franz.steinhaeusler@gmx.at> wrote:

  IdleColorStyle:
    I like the colouring of IDLE, so I tried to duplicate this.
    For (my own reasons), I didn't use the EVT_STYLE_NEEDED event,
      because the parsing would be much more difficult,
      and I assigned the styles for prompt, stdin, and stderr directly.
      Maybe someone is other opinion, but this I found much more simpler.
      Still not perfect (String parsing for example).
    It could also simplify the transition for people, who uses IDLE
      and the Pycrust. :wink:

Matt,

matthew@departurempls.com wrote:

I have a panel that contains a TextCtrl for the user to enter their
email address. I want to check that it is a valid email address when the
user leaves that text control (by tabbing out or clicking on another
TextCtrl).

Did you look at maskedEditControls? In the wxPython demo under "More Windows/Controls", check the second tab "Auto-formatted controls", the 5th control.

Werner

···

I haven't had much success with TextCtrl events (EVT_KILL_FOCUS doesnt
seem to work, nor have I had any luck with EVT_TXT_ENTER bound to the
other controls on the page) and because I don't want to have the user to
have to hit a submit button when they are done, I'm not sure how to use
a validator on this either.

Any help would be greatly appreciated.

Thanks,

Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Franz Steinhäusler wrote:

Any suggestions, comments and even ideas for new PyCrust plugins are
highly welcomed.
And also is this working for everyone (also on Linux?)

There should be a way (environment variable or etc.) to use some other dir as the location of the plugins because a user doesn't always have write access to the place where Py is installed.

@Robin: Could you in principle imagine to include such
  a functionality into a further release?

Probably, as long as there is minimal impact on current functionality.

If so: Would you prefer sending patches?

Yes. That is the easiest way to ensure that your changes don't overwrite any that I have made.

There is still the PyCrust project on Sourceforge, but not maintained anymore for years.
Should we continue there?
Create a new project (under another name)?
Shall we restrict the project to only make plugins and offer them for download?

PyCrust itself should stay in the wxPython project to avoid divergence, but I think that having a separate project for developing plugins makes sense, and the PyCrust SF project would be a good place to do it.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

  IdleColorStyle:
    I like the colouring of IDLE, so I tried to duplicate this.
    For (my own reasons), I didn't use the EVT_STYLE_NEEDED event,
      because the parsing would be much more difficult,
      and I assigned the styles for prompt, stdin, and stderr directly.
      Maybe someone is other opinion, but this I found much more simpler.
      Still not perfect (String parsing for example).
    It could also simplify the transition for people, who uses IDLE
      and the Pycrust. :wink:

There used to be an STCStyleEditor.py which was supplied with wxPython.
It handled all of the color changing and style definitions for
stc-derived controls. I don't know what happened to it, but it may be
useful for you.

I know. It comes from Boa Constructonr. By chance, a few days ago,
I subitted a patch to update it to new code style. :wink:

In terms of styling output from stdout and stderr, that sounds like a
useful addition, though I question the use of fully manual syntax
styling.

Yet, it looks long winded, but apparantly no better possibility is
available.

Future versions of the stc and scintilla editor control may
include the multi-language syntax highlighting (if the sinkworld project
is ever merged), which would handle such things quite nicely.

It looks like sinkworld isn't developed for some time.

At the other side, I asked Neil, if it is possible to
make the lexer more flexibel (to lex only certain areas of code,
but he said, it isn't so simple).

Maybe as he said, a look at pythonwin could be useful.

http://mailman.lyra.org/pipermail/scintilla-interest/2006-February/007376.html
http://mailman.lyra.org/pipermail/scintilla-interest/2005-August/006430.html

···

On Sun, 12 Feb 2006 14:57:57 -0800, Josiah Carlson <jcarlson@uci.edu> wrote:

Franz Steinhäusler <franz.steinhaeusler@gmx.at> wrote:

--
Franz Steinhaeusler

Franz Steinhäusler wrote:

Any suggestions, comments and even ideas for new PyCrust plugins are
highly welcomed.
And also is this working for everyone (also on Linux?)

There should be a way (environment variable or etc.) to use some other
dir as the location of the plugins because a user doesn't always have
write access to the place where Py is installed.

I see.
I think, environment variable is too circumstantial or costly for this.
I would allow the user to set it, and store it in a separate file
into the (new) pycrust settings directory.

(And we could let it by default (if this settings file doesn't exist)
in the subdir of the current pycrust settings directory).
(in my case C:\Dokumente und Einstellungen\SteinhaF\Anwendungsdaten\PyCrust).
wx.StandardPaths.Get().GetUserDataDir() /pycrust
So there is always read/write access and no need
to take care of assigning a plugin directory manually.

BTW: For what purpose is the GetPluginsDir() in the standard path?

@Robin: Could you in principle imagine to include such
  a functionality into a further release?

Probably, as long as there is minimal impact on current functionality.

I will take care. :wink:

If so: Would you prefer sending patches?

Yes. That is the easiest way to ensure that your changes don't
overwrite any that I have made.

Good.

There is still the PyCrust project on Sourceforge, but not maintained anymore for years.
Should we continue there?
Create a new project (under another name)?
Shall we restrict the project to only make plugins and offer them for download?

PyCrust itself should stay in the wxPython project to avoid divergence,
but I think that having a separate project for developing plugins makes
sense, and the PyCrust SF project would be a good place to do it.

Em, if anyone has access (permission)?
If nobody knows (and anyway), it would be perhaps better
to create a new projectg (pycrust plugins).

BTW: Is it reasonable, to always stress the word Pycrust?
it is more the Py Package itself.
What is a good topic for it?

···

On Mon, 13 Feb 2006 10:02:47 -0800, Robin Dunn <robin@alldunn.com> wrote:
--
Franz Steinhaeusler

Franz Steinhaeusler wrote:

Franz Steinhäusler wrote:

Any suggestions, comments and even ideas for new PyCrust plugins are
highly welcomed.
And also is this working for everyone (also on Linux?)

There should be a way (environment variable or etc.) to use some other dir as the location of the plugins because a user doesn't always have write access to the place where Py is installed.

I see.
I think, environment variable is too circumstantial or costly for this.
I would allow the user to set it, and store it in a separate file
into the (new) pycrust settings directory.

(And we could let it by default (if this settings file doesn't exist)
in the subdir of the current pycrust settings directory).
(in my case C:\Dokumente und Einstellungen\SteinhaF\Anwendungsdaten\PyCrust).
wx.StandardPaths.Get().GetUserDataDir() /pycrust
So there is always read/write access and no need
to take care of assigning a plugin directory manually.

BTW: For what purpose is the GetPluginsDir() in the standard path?

It would be for plugins that are installed by system tools, such as from vendor installers and etc. Perhaps it would be a good idea to look both in that dir and also in GetUserDataDir()

There is still the PyCrust project on Sourceforge, but not maintained anymore for years.
Should we continue there?
Create a new project (under another name)?
Shall we restrict the project to only make plugins and offer them for download?

PyCrust itself should stay in the wxPython project to avoid divergence, but I think that having a separate project for developing plugins makes sense, and the PyCrust SF project would be a good place to do it.

Em, if anyone has access (permission)?
If nobody knows (and anyway), it would be perhaps better
to create a new projectg (pycrust plugins).

I'm sure that a mail to Patrick with an explaination of what it would be used for would be all it took to get admin permissions. But a new project would probably work just as well.

BTW: Is it reasonable, to always stress the word Pycrust?
it is more the Py Package itself.
What is a good topic for it?

It started life as PyCrust, and then Patrick just started calling it Py when it was being expanded to include all the other capabilities. But I think that since "Py" is the prefix of so many projects it didn't really catch on because of potential confusion, and so "PyCrust" is still the common name for all of "Py".

···

On Mon, 13 Feb 2006 10:02:47 -0800, Robin Dunn <robin@alldunn.com> wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

(Yup; I can post again with gmane ;))

[...]
BTW: For what purpose is the GetPluginsDir() in the standard path?

It would be for plugins that are installed by system tools, such as from
vendor installers and etc. Perhaps it would be a good idea to look both
in that dir and also in GetUserDataDir()

I see, thanks for your explanation.

There is still the PyCrust project on Sourceforge, but not maintained anymore for years.
Should we continue there?
Create a new project (under another name)?
Shall we restrict the project to only make plugins and offer them for download?

PyCrust itself should stay in the wxPython project to avoid divergence,
but I think that having a separate project for developing plugins makes
sense, and the PyCrust SF project would be a good place to do it.

Em, if anyone has access (permission)?
If nobody knows (and anyway), it would be perhaps better
to create a new projectg (pycrust plugins).

I'm sure that a mail to Patrick with an explaination of what it would be
used for would be all it took to get admin permissions. But a new
project would probably work just as well.

Ok, I will try to contact Patrick.

BTW: Is it reasonable, to always stress the word Pycrust?
it is more the Py Package itself.
What is a good topic for it?

It started life as PyCrust, and then Patrick just started calling it Py
when it was being expanded to include all the other capabilities. But I
think that since "Py" is the prefix of so many projects it didn't really
catch on because of potential confusion, and so "PyCrust" is still the
common name for all of "Py".

Then let it PyCrust; this term is unique.

···

On Wed, 15 Feb 2006 14:08:03 -0800, Robin Dunn <robin@alldunn.com> wrote:

--
Franz Steinhaeusler

I'm sure that a mail to Patrick with an explaination of what it would be
used for would be all it took to get admin permissions. But a new
project would probably work just as well.

With Patricks compliance, I copy/paste
my conversation:

Mail and answer from Patrick:

Hello Patrick K. O'Brien,

I hope, I can reach you with this email adddress.

We try to enhance Pycrust (the wonderful project you
wrote some years ago) and it would be convenient
to use this project page.

If you don't have any demurs and you are not inclined to work further on the
"Py" Packager, I (we) would be glad to
get administration rights.

If you don't want, also no problem.
(We could start a new SF project)

   Actually, my team has been working on our hosting situation so that we
   are able to do a really good job at hosting open source projects using
   tools like Subversion, Trac and Pudge. And we are doing it in a way
   that will make it easy to have sub-administrators as well. I'd like to
   talk it over with the rest of my team, but if they are in favor of it
   then I'd like to offer to host this project.

   In fact, under the
   assumption that everyone will think this is a good idea, I just
   purchased the pycrust.org and pycrust.com domain names.

That would be great!

Background: I'm planing to add a plugin functionality,
and a good place for sharing them and collect bug reports
is and was this place.

   While I haven't been active with wxPython for a while, I did notice your
   activity with it and was excited to see someone taking the lead.

:slight_smile: I liked Pycrust from the beginning.
Even if I wasn't really in wxPython, I preferred very much over IDLE.
Alone the calltips and autocomplete is very helpful together with the
filling tree (namespace viewer).

···

On Wed, 15 Feb 2006 14:08:03 -0800, Robin Dunn <robin@alldunn.com> wrote:

   I think adding plugins would be great. I'd also love to see a standalone
   version of PyCrust because I think more people would use it if it was
   available as a single binary installer (at least more Windows people
   would use it).

Yes, you are certainly right.

    I've also talked with the IPython folks about using the
   IPython interpreter within the PyCrust GUI but neither of us ever had
   the time to make that happen.

That would make PyCrust the more public.

   So, there are many reasons to make
   PyCrust an independent project once again.

For more information, you can look at:

ActiveState Community - Boosting coder and team productivity with ready-to-use open source languages and tools.

   I'm glad Robin likes the idea. We'll just need to coordinate providing
   patches back to the wxPython team so that the main wxPython distribution
   stays in synch with anything done at pycrust.org.

--
Franz Steinhaeusler

Hi NG,

I post herewith my last patch at:
http://mitglied.lycos.de/drpython/py_210206.zip

I hope (i tested it with Pyalacarte, pyshell, ...)
there is no significant bug.

With this patch, there is a (basic) plugin support,
the user can also adjust a plugin directory.
I also attached a simple Sampleplugin.

If there are no errors (I will test myself again),
I want to submit a patch (I think, best with the sample plugin),
and write a small readme or history.txt, which could be added
to the existing one.

I have problems with access to CVS.
Is it sufficient to make a diff with the last
test release?
(My two plugins are not ripe yet, so I exclude them from the package).
(They are still in
http://mitglied.lycos.de/drpython/pycrustpluginsample12_Feb_2006.zip
)

···

--
Franz Steinhaeusler

Franz Steinhäusler wrote:

Hi NG,

I post herewith my last patch at:
http://mitglied.lycos.de/drpython/py_210206.zip

I hope (i tested it with Pyalacarte, pyshell, ...)
there is no significant bug.

With this patch, there is a (basic) plugin support,
the user can also adjust a plugin directory.
I also attached a simple Sampleplugin.

If there are no errors (I will test myself again),
I want to submit a patch (I think, best with the sample plugin),
and write a small readme or history.txt, which could be added
to the existing one.

I have problems with access to CVS.
Is it sufficient to make a diff with the last
test release?

If that's the best you can do then I can probably work around it. but please keep an eye on CVS via http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/wx/py/ and try to make sure that if there are any changes done there since the the version that you are diff-ing that they are not overwritten by your changes.

What problems are you having accessing CVS?

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

I think, I'm behind a firewall.

Ok, I will write my own recipe for submitting patches,
based on viewcvs.

Reason: remember myself and maybe it is useful for others.

(My current working dir is py)

1) I make a backup from the last download of wxPython into py_orig
   and also to py_orig_2621.

2) I go to (in my case):
    http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/wx/py/
    sort after date and download the changed files (newer then
      the time elapsed from the last download).
    
3) I see crust.py, shell.py and filling.py are newer.
   So I download them and copy them into py_orig.

4) I open an editor and Winmerge.
   I compare this three files from py_orig and py_orig_2621.
   Aha: in cvs there are unix line endings and on my
   PC Windows CRLF's.
   I'm not sure about this, but I converted this three files
     to Windows Line Endings.
   Ok I compare again, much better.

5) I step through each difference of the three files:
     py_orig and py_orig_2621.
   I opend Winmerge with a second instance and compare
     py_orig and py directory.
   Then I check all changes from the first, and if they fit
     I realize them in the second open winmerge.
    (Ok I had not change filling.py so I copy it only to my py directory).
    
  (It is like a manually 3-Way merge).

6) I copy the (now 3 different) files to my py directory,
     but renamed them in the form shell_orig.py.
   Open a prompt and call for the tree files
    C:\Python24\Lib\site-packages\wx-2.621-msw-ansi\wx\py>
      diff -u3 shell_orig.py shell.py > shell.diff
      diff -u3 crust_orig.py crust.py > crust.diff
      diff -u3 frame_orig.py frame.py > frame.diff
    
    and submit this into the patch tracker to Robin.
    
If I need this more often, I of course will look to a way
to rationalize.

···

On Tue, 21 Feb 2006 17:22:37 -0800, Robin Dunn <robin@alldunn.com> wrote:

If that's the best you can do then I can probably work around it. but
please keep an eye on CVS via
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/wx/py/ and try
to make sure that if there are any changes done there since the the
version that you are diff-ing that they are not overwritten by your changes.

What problems are you having accessing CVS?

--
Franz Steinhaeusler

Franz Steinhaeusler wrote:

···

On Tue, 21 Feb 2006 17:22:37 -0800, Robin Dunn <robin@alldunn.com> wrote:

If that's the best you can do then I can probably work around it. but please keep an eye on CVS via http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/wx/py/ and try to make sure that if there are any changes done there since the the version that you are diff-ing that they are not overwritten by your changes.

What problems are you having accessing CVS?

C:\Programme\GNU\WinCvs 1.2>cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cv
sroot/wxpython co -P wx
cvs [checkout aborted]: connect to cvs.sourceforge.net:2401 failed: Network is u
nreachable

If your firewall is not letting you out then this won't help you any, but you do have a couple things wrong in the CVSROOT you use. It should be:

  -d:pserver:anoncvs@cvs.wxwidgets.org:/pack/cvsroots/wxwidgets

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!