pycrust-users — PyCrust Users and Developers

Re: [PyCrust] AutoComplete window size

[Robin D. <ro...@al...>]

> The latest wxPython beta (2.3.2b5) still generates an autocomplete window
> that is too narrow for its items. Is this something that can be fixed?

I've noticed this too and will take a look at it the next time I am working
in the wxSTC code.

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

RE: [PyCrust] AutoComplete window size

[Patrick K. O'B. <po...@or...>]

The latest wxPython beta (2.3.2b5) still generates an autocomplete window
that is too narrow for its items. Is this something that can be fixed? Take
a look at just about any object in PyCrust to see what I mean. Here is the
simplest example. Just type "shell." and scroll through the list:

Welcome To PyCrust 0.6.1 - The Flakiest Python Shell
Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Startup script executed: C:\Code\.pythonrc.py
>>> shell.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Neil Hodgson
Sent: Thursday, August 02, 2001 6:05 PM
To: pyc...@li...
Cc: wxp...@li...
Subject: Re: [PyCrust] AutoComplete window size

Patrick K. O'Brien:

   wxSTC questions should really go to the wxPython list so Robin and others
can see them.

> Is there a way to change the size, particularly the width, of the
> auto-completion list window? Some attribute names can be long
> and it seems like the window could stand to be a bit wider.

   The Windows and GTK+ platform layers size the list box to fit the widest
string. It looks like the wxSTC platform code (in
contrib\stc\contrib\src\stc\PlatWX.cpp) does not do this although there is a
call to GetBestSize which may be returning a smaller width than will fit the
widest string.

   Neil



_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users

[PyCrust] Recent CVS changes improve Zope support

[Patrick K. O'B. <po...@or...>]

I just checked in a few changes that make working with Zope a bit better.
Specifically the following enhancements:

Changed introspect.getAllAttributeNames() to break circular references in
object.__class__, which occurs in Zope extension classes. Changed
filling.FillingTree.getChildren() to introspect extension classes.

The best way to experience the impact of this is to do the following in
PyCrust:

Welcome To PyCrust 0.6.1 - The Flakiest Python Shell
Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Startup script executed: C:\Code\.pythonrc.py
>>> import Zope
>>> app = Zope.app()
>>>

Then take a look at the app object in the PyFilling tree.

P.S. Anyone care to guess where I'm heading with PyCrust? This is just the
beginning. <wink>

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

Oops! Was: RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Patrick K. O'B. <po...@or...>]

Oops! That wasn't the only change that got committed to cvs the other night.
Hold on to your hats, there's another feature in the cvs code that might
freak you out if I don't explain. <grin>

The new feature is a shell façade class that I was working on, to simplify
what users see when they type ">>> shell." in the shell window. The idea is
to hide all the attributes that have to do with the StyledTextControl or
internal mechanisms. This lets the shell user focus on the shell commands
that are relevant to the typical shell session. Basically, I was getting
tired of typing "shell." and seeing a huge list of irrelevant stuff. This
new façade class takes care of that problem, while still magically allowing
all the attributes and method calls to work, as long as you know what they
are. And if you ever want to see the full list, you can just do
"shell.other." Here is the code, and you can also see a pretty diff at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pycrust/PyCrust/shell.py.diff
?r1=1.19&r2=1.20.

class ShellFacade:
    """Simplified interface to all shell-related functionality.

    This is a semi-transparent facade, in that all attributes of other are
    still accessible, even though only some are visible to the user."""

    name = 'PyCrust Shell Interface'
    revision = __version__

    def __init__(self, other):
        """Create a ShellFacade instance."""
        methods = ['ask',
                   'clear',
                   'pause',
                   'prompt',
                   'quit',
                   'redirectStderr',
                   'redirectStdin',
                   'redirectStdout',
                   'run',
                   'runfile',
                  ]
        for method in methods:
            self.__dict__[method] = getattr(other, method)
        d = self.__dict__
        d['other'] = other
        d['help'] = 'There is no help available, yet.'


    def __getattr__(self, name):
        if hasattr(self.other, name):
            return getattr(self.other, name)
        else:
            raise AttributeError, name

    def __setattr__(self, name, value):
        if self.__dict__.has_key(name):
            self.__dict__[name] = value
        elif hasattr(self.other, name):
            return setattr(self.other, name, value)
        else:
            raise AttributeError, name

    def _getAttributeNames(self):
        """Return list of magic attributes to extend introspection."""
        list = ['autoCallTip',
                'autoComplete',
                'autoCompleteCaseInsensitive',
                'autoCompleteIncludeDouble',
                'autoCompleteIncludeMagic',
                'autoCompleteIncludeSingle',
               ]
        list.sort()
        return list


---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Patrick K.
O'Brien
Sent: Wednesday, September 19, 2001 7:32 PM
To: pyc...@li...
Subject: RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
cooking soon

That's a perfectly reasonable scenario, so I will indeed add your suggested
code. I try to avoid superfluous code as much as I can, but please don't
take my reluctance as a lack of concern for your needs. I very much want
PyCrust components to be useable in a wide variety of situations and you
have identified something I hadn't considered. Thank you for your
suggestion. It should appear in cvs with the next checkin.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Patrick K. O'B. <po...@or...>]

That's a perfectly reasonable scenario, so I will indeed add your suggested
code. I try to avoid superfluous code as much as I can, but please don't
take my reluctance as a lack of concern for your needs. I very much want
PyCrust components to be useable in a wide variety of situations and you
have identified something I hadn't considered. Thank you for your
suggestion. It should appear in cvs with the next checkin.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Wednesday, September 19, 2001 6:26 PM
To: pyc...@li...
Subject: Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
cooking soon


Well, I guess it has to do more with my very own way of implementing it
in my application. Because the interpreter is just a page in a
wxNotebook (with its own namespace, different to the rest of the
application) so, if I'm in another page, it can send code to the
interpreter (using the run method) or if i'm in the interpreter, and
event is triggered to update the rest of the pages when I move to
another page. So I can be doing stuff either in the interpreter or
somewhere else and a user can forget to leave the cursor at the very
end.

But I guess this is a very specific case, so don't worry about it.

Raul



"Patrick K. O'Brien" wrote:
>
> On the one hand, adding code to set the current position to the end
wouldn't
> hurt anything, and would appear to be a good safeguard. On the other hand,
I
> can't picture how this would be necessary unless someone was messing with
> the cursor position in their code, and I can't imagine why someone would
do
> this. Have you actually run into a situation where the output did not go
at
> the end? If you have, I'd love to hear what the situation was. If you
> haven't, I'd be reluctant to add the code. Feel free to correct me if I'm
> not seeing things the way you see them.
>
> ---
> Patrick K. O'Brien
> Orbtech (http://www.orbtech.com)
> "I am, therefore I think."
>
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Raul Cota
> Sent: Wednesday, September 19, 2001 1:02 PM
> To: pyc...@li...
> Subject: Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
> cooking soon
>
> Well... I took me a while to get back to normal after last week.
>
> Patrick:
> I think the "run" method needs the following lines, to make sure that
> the "command" and the "output" are written at the very end.
>
>     def run(self, command, prompt=1, verbose=1):
>         """Execute command within the shell as if it was typed in
> directly.
>         >>> shell.run('print "this"')
>         >>> print "this"
>         this
>         >>>
>         """
>         # Go to the very bottom of the text.
>         endpos = self.GetTextLength()
>         self.SetCurrentPos(endpos)
>         command = command.rstrip()
>         if prompt: self.prompt()
>         if verbose: self.write(command)
>         self.push(command)
>
> What do you think?
>
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users

_______________________________________________
PyCrust-users mailing list
PyC...@li...
https://lists.sourceforge.net/lists/listinfo/pycrust-users

Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Raul C. <co...@uc...>]

Well, I guess it has to do more with my very own way of implementing it
in my application. Because the interpreter is just a page in a
wxNotebook (with its own namespace, different to the rest of the
application) so, if I'm in another page, it can send code to the
interpreter (using the run method) or if i'm in the interpreter, and
event is triggered to update the rest of the pages when I move to
another page. So I can be doing stuff either in the interpreter or
somewhere else and a user can forget to leave the cursor at the very
end.

But I guess this is a very specific case, so don't worry about it.

Raul



"Patrick K. O'Brien" wrote:
> 
> On the one hand, adding code to set the current position to the end wouldn't
> hurt anything, and would appear to be a good safeguard. On the other hand, I
> can't picture how this would be necessary unless someone was messing with
> the cursor position in their code, and I can't imagine why someone would do
> this. Have you actually run into a situation where the output did not go at
> the end? If you have, I'd love to hear what the situation was. If you
> haven't, I'd be reluctant to add the code. Feel free to correct me if I'm
> not seeing things the way you see them.
> 
> ---
> Patrick K. O'Brien
> Orbtech (http://www.orbtech.com)
> "I am, therefore I think."
> 
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Raul Cota
> Sent: Wednesday, September 19, 2001 1:02 PM
> To: pyc...@li...
> Subject: Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
> cooking soon
> 
> Well... I took me a while to get back to normal after last week.
> 
> Patrick:
> I think the "run" method needs the following lines, to make sure that
> the "command" and the "output" are written at the very end.
> 
>     def run(self, command, prompt=1, verbose=1):
>         """Execute command within the shell as if it was typed in
> directly.
>         >>> shell.run('print "this"')
>         >>> print "this"
>         this
>         >>>
>         """
>         # Go to the very bottom of the text.
>         endpos = self.GetTextLength()
>         self.SetCurrentPos(endpos)
>         command = command.rstrip()
>         if prompt: self.prompt()
>         if verbose: self.write(command)
>         self.push(command)
> 
> What do you think?
> 
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users

RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Patrick K. O'B. <po...@or...>]

Richie Hindle had submitted a patch that added a lot of command history
retrieval functionality. The only part I didn't apply was saving to and
retrieving from a file. I had hoped to have a Session class developed by
now, where this functionality will ultimately reside. But I am behind
schedule. So in the mean time, you may want to look at the methods Richie
supplied. They should work with the existing code:

+     def savehistory( self, filename="PyCrustHistory.txt" ):
+         """Saves the command history to the named file, or to
PyCrustHistory.txt if no name is given."""
+         # Reverse the list so that the commands come out in chronological
order in the file.
+         commands = self.history[:]
+         commands.reverse()
+         file = open( filename, "wt" )
+         for command in commands:
+             file.write( command + "\n" )
+         file.close()
+         self.write( "History saved." )
+
+     def loadhistory( self, filename="PyCrustHistory.txt" ):
+         """Loads the command history from the named file, or from
PyCrustHistory.txt if no name is given."""
+         # Reset the history before loading up the new one.
+         self.history = []
+         self.historyPos = -1
+         file = open( filename, "rt" )
+         for command in file.readlines():
+             self.history.insert( 0, command[ :-1 ] )  # Strip the trailing
newline.
+         file.close()
+         self.write( "History loaded." )

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Wednesday, September 19, 2001 1:02 PM
To: pyc...@li...
Subject: Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
cooking soon

<snip>

BTW... I'm implementing some small methods for my own purposes:
def StartSavingToFile(self, filePath=None, append=false):
   """Begin saving all the code sent or written to the interpreter"""

def CloseFile(self):
   """Close the file and stop saving commands"""

def ChangeFileName(self, filePath, append=false):
   """Begins saving in a new file, copying all the info from the last
file"""

They are basically methods to save all the commands written in the
interpreter, so the user can load them from a file.
Are you interested at all ???

Raúl

RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Patrick K. O'B. <po...@or...>]

On the one hand, adding code to set the current position to the end wouldn't
hurt anything, and would appear to be a good safeguard. On the other hand, I
can't picture how this would be necessary unless someone was messing with
the cursor position in their code, and I can't imagine why someone would do
this. Have you actually run into a situation where the output did not go at
the end? If you have, I'd love to hear what the situation was. If you
haven't, I'd be reluctant to add the code. Feel free to correct me if I'm
not seeing things the way you see them.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Wednesday, September 19, 2001 1:02 PM
To: pyc...@li...
Subject: Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
cooking soon


Well... I took me a while to get back to normal after last week.

Patrick:
I think the "run" method needs the following lines, to make sure that
the "command" and the "output" are written at the very end.

    def run(self, command, prompt=1, verbose=1):
        """Execute command within the shell as if it was typed in
directly.
        >>> shell.run('print "this"')
        >>> print "this"
        this
        >>>
        """
        # Go to the very bottom of the text.
        endpos = self.GetTextLength()
        self.SetCurrentPos(endpos)
        command = command.rstrip()
        if prompt: self.prompt()
        if verbose: self.write(command)
        self.push(command)

What do you think?

Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Raul C. <co...@uc...>]

Well... I took me a while to get back to normal after last week.

Patrick:
I think the "run" method needs the following lines, to make sure that
the "command" and the "output" are written at the very end.

    def run(self, command, prompt=1, verbose=1):
        """Execute command within the shell as if it was typed in
directly.
        >>> shell.run('print "this"')
        >>> print "this"
        this
        >>> 
        """
        # Go to the very bottom of the text.
        endpos = self.GetTextLength()
        self.SetCurrentPos(endpos)        
        command = command.rstrip()
        if prompt: self.prompt()
        if verbose: self.write(command)
        self.push(command)

What do you think?


BTW... I'm implementing some small methods for my own purposes:
def StartSavingToFile(self, filePath=None, append=false):
   """Begin saving all the code sent or written to the interpreter"""

def CloseFile(self):
   """Close the file and stop saving commands"""

def ChangeFileName(self, filePath, append=false):
   """Begins saving in a new file, copying all the info from the last
file"""

They are basically methods to save all the commands written in the
interpreter, so the user can load them from a file.
Are you interested at all ???

Raúl


"Patrick K. O'Brien" wrote:
> 
> The code for runfile should give you one idea for how to get around this.
> I'm open to suggestions for improving this mechanism.
> 
>     def run(self, command, prompt=1, verbose=1):
>         """Execute command within the shell as if it was typed in directly.
>         >>> shell.run('print "this"')
>         >>> print "this"
>         this
>         >>>
>         """
>         command = command.rstrip()
>         if prompt: self.prompt()
>         if verbose: self.write(command)
>         self.push(command)
> 
>     def runfile(self, filename):
>         """Execute all commands in file as if they were typed into the
> shell."""
>         file = open(filename)
>         try:
>             self.prompt()
>             for command in file.readlines():
>                 if command[:6] == 'shell.':  # Run shell methods silently.
>                     self.run(command, prompt=0, verbose=0)
>                 else:
>                     self.run(command, prompt=0, verbose=1)
>         finally:
>             file.close()
> 
> ---
> Patrick K. O'Brien
> Orbtech (http://www.orbtech.com)
> "I am, therefore I think."
> 
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Raul Cota
> Sent: Saturday, September 08, 2001 6:33 PM
> To: pyc...@li...
> Subject: Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
> cooking soon
> 
> <snip>
> 
> 2) My application uses a lot the run command in shell.py, and there's
> something I don't particullary like. The code:
> sh.run('r = 5')
> sh.run('x = 6')
> sh.run('t = 8')
> 
> gives the following output in the interpreter
> >>>
> >>> r = 5
> >>>
> >>> x = 6
> >>>
> >>> t = 8
> >>>
> 
> instead of
> >>> r = 5
> >>> x = 6
> >>> t = 8
> 
> the method run, writes the ouptut one line after the active line, so, if
> the active line is somewhere above... things like this happen (I ran the
> same code several times)...
> >>> parentFlowsh.Solve()
> myFlash
> >>> parentFlowsh.Solve()
> myFlash1
> >>> 1
> >>>
> >>> parentFlowsh.Solve()
> myFlash1
> >>>
> >>> parentFlowsh.Solve()
> myFlash1
> >>>
> >>> par
> >>> parentFlowsh.Solve()
> myFlash1
> >>> entFlowsh.Solve()
> myFlash1
> >>> parentFlowsh.Solve()
> myFlash1
> >>>
> 
> Every two lines it should say ....
> >>> parentFlowsh.Solve()
> myFlash1
> 
> Right now, I was working on trying to fix
> 
> Raul
> 
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users

[PyCrust] Home Page

[Patrick K. O'B. <po...@or...>]

We have none. We need one. Any volunteers?

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

[PyCrust] 0.6 is out of the oven!

[Patrick K. O'B. <po...@or...>]

The latest release of PyCrust is now available at:

http://sourceforge.net/project/showfiles.php?group_id=31263

Here are the details on the latest changes:

=====
0.6   (8/21/2001 to 9/12/2001)
=====
Added PyFilling.py and filling.py.
-----
PyShell.py and PyFilling.py can now be run standalone, as well as
PyCrust.py.
-----
Added crust.py and moved some code from PyCrust.py to it.
-----
Added command history retrieval features submitted by Richie Hindle.
-----
Changed shell.write() to replace line endings with OS-specific endings.
Changed shell.py and interpreter.py to use os.linesep in strings having
hardcoded line endings.
-----
Added shell.redirectStdin(), shell.redirectStdout() and
shell.redirectStderr() to allow the surrounding app to toggle requests that
the specified sys.std* be redirected to the shell. These can also be run
from within the shell itself, of course.
-----
The shell now adds the current working directory "." to the search path:
    sys.path.insert(0, os.curdir)
-----
Added support for distutils installations.
-----

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Patrick K. O'B. <po...@or...>]

The code for runfile should give you one idea for how to get around this.
I'm open to suggestions for improving this mechanism.

    def run(self, command, prompt=1, verbose=1):
        """Execute command within the shell as if it was typed in directly.
        >>> shell.run('print "this"')
        >>> print "this"
        this
        >>>
        """
        command = command.rstrip()
        if prompt: self.prompt()
        if verbose: self.write(command)
        self.push(command)

    def runfile(self, filename):
        """Execute all commands in file as if they were typed into the
shell."""
        file = open(filename)
        try:
            self.prompt()
            for command in file.readlines():
                if command[:6] == 'shell.':  # Run shell methods silently.
                    self.run(command, prompt=0, verbose=0)
                else:
                    self.run(command, prompt=0, verbose=1)
        finally:
            file.close()

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Saturday, September 08, 2001 6:33 PM
To: pyc...@li...
Subject: Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
cooking soon

<snip>

2) My application uses a lot the run command in shell.py, and there's
something I don't particullary like. The code:
sh.run('r = 5')
sh.run('x = 6')
sh.run('t = 8')

gives the following output in the interpreter
>>>
>>> r = 5
>>>
>>> x = 6
>>>
>>> t = 8
>>>

instead of
>>> r = 5
>>> x = 6
>>> t = 8

the method run, writes the ouptut one line after the active line, so, if
the active line is somewhere above... things like this happen (I ran the
same code several times)...
>>> parentFlowsh.Solve()
myFlash
>>> parentFlowsh.Solve()
myFlash1
>>> 1
>>>
>>> parentFlowsh.Solve()
myFlash1
>>>
>>> parentFlowsh.Solve()
myFlash1
>>>
>>> par
>>> parentFlowsh.Solve()
myFlash1
>>> entFlowsh.Solve()
myFlash1
>>> parentFlowsh.Solve()
myFlash1
>>>


Every two lines it should say ....
>>> parentFlowsh.Solve()
myFlash1

Right now, I was working on trying to fix

Raul

RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Patrick K. O'B. <po...@or...>]

This change is now in CVS. Thanks again, Raul.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Patrick K.
O'Brien
Sent: Saturday, September 08, 2001 8:08 PM
To: pyc...@li...
Subject: RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
cooking soon

Ah, yes! Thanks a bunch. That definitely helps.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Saturday, September 08, 2001 7:56 PM
To: pyc...@li...
Subject: Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
cooking soon


if you run PyCrust.py you get a splitter window with the interpreter on
top and the filling below it, right?
Well, if I make the interpreter window as big as I can by reducing the
size of the filling (the on sash event) until the filling window is
totally hidden. Then I can't open it back again (the filling window).
That's why I have to give it a MinimumPaneSize. So the filling is never
totally hidden.

I did it in the __init__event of Crust, and Filling

Raul

Win NT, Python 2.1, wxPython 2.3.1


_______________________________________________
PyCrust-users mailing list
PyC...@li...
https://lists.sourceforge.net/lists/listinfo/pycrust-users

RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Patrick K. O'B. <po...@or...>]

Ah, yes! Thanks a bunch. That definitely helps.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Saturday, September 08, 2001 7:56 PM
To: pyc...@li...
Subject: Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done
cooking soon


if you run PyCrust.py you get a splitter window with the interpreter on
top and the filling below it, right?
Well, if I make the interpreter window as big as I can by reducing the
size of the filling (the on sash event) until the filling window is
totally hidden. Then I can't open it back again (the filling window).
That's why I have to give it a MinimumPaneSize. So the filling is never
totally hidden.

I did it in the __init__event of Crust, and Filling

Raul

Win NT, Python 2.1, wxPython 2.3.1

Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Raul C. <co...@uc...>]

if you run PyCrust.py you get a splitter window with the interpreter on
top and the filling below it, right?
Well, if I make the interpreter window as big as I can by reducing the
size of the filling (the on sash event) until the filling window is
totally hidden. Then I can't open it back again (the filling window).
That's why I have to give it a MinimumPaneSize. So the filling is never
totally hidden. 

I did it in the __init__event of Crust, and Filling

Raul

Win NT, Python 2.1, wxPython 2.3.1


"Patrick K. O'Brien" wrote:
> 
> It's not clear to me what kind of problem you are having. I don't think I
> see this behavior, so could you possibly describe it in a little more
> detail? And where exactly did you add the line of code that fixed things?
> Just in FillingTree or Filling? Or other windows?
> 
> ---
> Patrick K. O'Brien
> Orbtech (http://www.orbtech.com)
> "I am, therefore I think."
> 
> Small annoying suggestions:
> 1) The scrolled windows, when you scroll all the way and you totally
> hide something, for instance, if you totally hide the ingredients tree,
> you can't open it back.
> Only because of that reason, I had to inherit and add the following line
> to the __init__ code:
> self.SetMinimumPaneSize(1)
> 
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users

RE: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Patrick K. O'B. <po...@or...>]

It's not clear to me what kind of problem you are having. I don't think I
see this behavior, so could you possibly describe it in a little more
detail? And where exactly did you add the line of code that fixed things?
Just in FillingTree or Filling? Or other windows?

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

Small annoying suggestions:
1) The scrolled windows, when you scroll all the way and you totally
hide something, for instance, if you totally hide the ingredients tree,
you can't open it back.
Only because of that reason, I had to inherit and add the following line
to the __init__ code:
self.SetMinimumPaneSize(1)

Re: [PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Raul C. <co...@uc...>]

Small annoying suggestions:
1) The scrolled windows, when you scroll all the way and you totally
hide something, for instance, if you totally hide the ingredients tree,
you can't open it back. 
Only because of that reason, I had to inherit and add the following line
to the __init__ code:
self.SetMinimumPaneSize(1)


2) My application uses a lot the run command in shell.py, and there's
something I don't particullary like. The code:
sh.run('r = 5')
sh.run('x = 6')
sh.run('t = 8')

gives the following output in the interpreter
>>> 
>>> r = 5
>>> 
>>> x = 6
>>> 
>>> t = 8
>>> 

instead of 
>>> r = 5
>>> x = 6
>>> t = 8

the method run, writes the ouptut one line after the active line, so, if
the active line is somewhere above... things like this happen (I ran the
same code several times)...
>>> parentFlowsh.Solve()
myFlash
>>> parentFlowsh.Solve()
myFlash1
>>> 1
>>> 
>>> parentFlowsh.Solve()
myFlash1
>>> 
>>> parentFlowsh.Solve()
myFlash1
>>> 
>>> par
>>> parentFlowsh.Solve()
myFlash1
>>> entFlowsh.Solve()
myFlash1
>>> parentFlowsh.Solve()
myFlash1
>>> 


Every two lines it should say ....
>>> parentFlowsh.Solve()
myFlash1

Right now, I was working on trying to fix

Raul


"Patrick K. O'Brien" wrote:
> 
> I'd like to get an official 0.6 release out asap. If those of you who are
> downloading from CVS could update and give it a whirl I would appreciate it.
> If no one hollers I'll wrap it up into a release and get started on the next
> set of features. CVS has the following changes since 0.5.3:
> 
> =====
> 0.6   (8/21/2001 to //2001)
> =====
> Added PyFilling.py and filling.py.
> -----
> PyShell.py and PyFilling.py can now be run standalone, as well as
> PyCrust.py.
> -----
> Added crust.py and moved some code from PyCrust.py to it.
> -----
> Added command history retrieval features submitted by Richie Hindle.
> -----
> Changed shell.write() to replace line endings with OS-specific endings.
> Changed shell.py and interpreter.py to use os.linesep in strings having
> hardcoded line endings.
> -----
> Added shell.redirectStdin(), shell.redirectStdout() and
> shell.redirectStderr() to allow the surrounding app to toggle requests that
> the specified sys.std* be redirected to the shell. These can also be run
> from within the shell itself, of course.
> -----
> The shell now adds the current working directory "." to the search path:
>     sys.path.insert(0, os.curdir)
> -----
> 
> =====
> 0.5.4 (8/17/2001 to 8/20/2001)
> =====
> Changed default font size under *nix to:
>     'size'   : 12,
>     'lnsize' : 10,
> -----
> Changed Shell to expect a parameter referencing an Interpreter class, rather
> than an intepreter instance, to facilitate subclassing of Interpreter, which
> effectively broke when the Editor class was eliminated.
> -----
> Fixed PyCrustAlaCarte.py, which had been broken by previous changes.
> Created InterpreterAlaCarte class as an example for use in the demo.
> -----
> Split PyCrust.py into PyCrust.py and PyShell.py in anticipation of
> PyFilling.
> -----
> 
> ---
> Patrick K. O'Brien
> Orbtech (http://www.orbtech.com)
> "I am, therefore I think."
> 
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users

[PyCrust] 0.6 in the oven, now with PyFilling, should be done cooking soon

[Patrick K. O'B. <po...@or...>]

I'd like to get an official 0.6 release out asap. If those of you who are
downloading from CVS could update and give it a whirl I would appreciate it.
If no one hollers I'll wrap it up into a release and get started on the next
set of features. CVS has the following changes since 0.5.3:

=====
0.6   (8/21/2001 to //2001)
=====
Added PyFilling.py and filling.py.
-----
PyShell.py and PyFilling.py can now be run standalone, as well as
PyCrust.py.
-----
Added crust.py and moved some code from PyCrust.py to it.
-----
Added command history retrieval features submitted by Richie Hindle.
-----
Changed shell.write() to replace line endings with OS-specific endings.
Changed shell.py and interpreter.py to use os.linesep in strings having
hardcoded line endings.
-----
Added shell.redirectStdin(), shell.redirectStdout() and
shell.redirectStderr() to allow the surrounding app to toggle requests that
the specified sys.std* be redirected to the shell. These can also be run
from within the shell itself, of course.
-----
The shell now adds the current working directory "." to the search path:
    sys.path.insert(0, os.curdir)
-----


=====
0.5.4 (8/17/2001 to 8/20/2001)
=====
Changed default font size under *nix to:
    'size'   : 12,
    'lnsize' : 10,
-----
Changed Shell to expect a parameter referencing an Interpreter class, rather
than an intepreter instance, to facilitate subclassing of Interpreter, which
effectively broke when the Editor class was eliminated.
-----
Fixed PyCrustAlaCarte.py, which had been broken by previous changes.
Created InterpreterAlaCarte class as an example for use in the demo.
-----
Split PyCrust.py into PyCrust.py and PyShell.py in anticipation of
PyFilling.
-----

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

Re: [PyCrust] PyCrust in wxPython distribution

[Robin D. <ro...@al...>]

>
> Robin, is PyCrust going to be part of the next release of wxPython??
>

Yes.  It will be in the wxPython.lib.PyCrust package.  The old shell modules
will still be there, but deprecated.

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

[PyCrust] PyCrust in wxPython distribution

[Raul C. <co...@uc...>]

Robin, is PyCrust going to be part of the next release of wxPython??

Raul

Re: [PyCrust] problems with os

[Raul C. <co...@uc...>]

Thanks a lot. I was so used to import files for different paths that
way, that I never bothered learning the "correct" way of doing it.

Raul

"Patrick K. O'Brien" wrote:
> 
> The short answer is that what you see right now is the default behavior of
> the Python interpreter. The other shells, such as IDLE, play useful tricks
> by adding things to the sys.path behind the scenes. In particular, the
> following bit of code will illustrate what you want by adding the current
> directory, as represented by ".", to the sys.path. Then when you os.chdir()
> you will be able to import from the current working directory.
> 
> >>> from pprint import pprint
> >>> import sys
> >>> pprint(sys.path)
> ['',
>  'C:\\Code',
>  'C:\\Python21\\win32',
>  'C:\\Python21\\win32\\lib',
>  'C:\\Python21',
>  'C:\\Python21\\Pythonwin',
>  'C:\\PYTHON21\\DLLs',
>  'C:\\PYTHON21\\lib',
>  'C:\\PYTHON21\\lib\\plat-win',
>  'C:\\PYTHON21\\lib\\lib-tk',
>  'C:\\PYTHON21\\Numeric']
> >>> import os
> >>> sys.path.insert(0, os.curdir)
> >>> pprint(sys.path)
> ['.',
>  '',
>  'C:\\Code',
>  'C:\\Python21\\win32',
>  'C:\\Python21\\win32\\lib',
>  'C:\\Python21',
>  'C:\\Python21\\Pythonwin',
>  'C:\\PYTHON21\\DLLs',
>  'C:\\PYTHON21\\lib',
>  'C:\\PYTHON21\\lib\\plat-win',
>  'C:\\PYTHON21\\lib\\lib-tk',
>  'C:\\PYTHON21\\Numeric']
> 
> Because this is pretty useful, I will probably add sys.path.insert(0,
> os.curdir) as standard behavior in the shell so you won't have to jump
> through this hoop in the future. In fact, I just checked this change into
> cvs. Hope this helps. Thanks for the feedback.
> 
> ---
> Patrick K. O'Brien
> Orbtech (http://www.orbtech.com)
> "I am, therefore I think."
> 
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Raul Cota
> Sent: Friday, September 07, 2001 4:04 PM
> To: pycr
> Subject: [PyCrust] problems with os
> 
> why doesn't this code work???
> >>> import os
> >>> os.chdir('d:\sim')
> >>> import SThermoAdmin
> Traceback (most recent call last):
>   File "<input>", line 1, in ?
> ImportError: No module named SThermoAdmin
> 
> Needless to say , that I tested the same lines in another interpreter
> and they work fine.
> Tried it with any file that is not in the python path and I get the same
> results.
> 
> I'll try to find the reason myself since I'm going to be playing around
> with PyCrust today, because I'm planning on implementing it in my
> application (currently I'm using shell.py that comes in the wxPython
> distribution)
> 
> BTW. Thanks for the icon... it looks really cool!!!
> 
> Raul
> 
> Win NT; Python 2.1; wxPython 2.3.1
> 
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users
> 
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users

RE: [PyCrust] problems with os

[Patrick K. O'B. <po...@or...>]

The short answer is that what you see right now is the default behavior of
the Python interpreter. The other shells, such as IDLE, play useful tricks
by adding things to the sys.path behind the scenes. In particular, the
following bit of code will illustrate what you want by adding the current
directory, as represented by ".", to the sys.path. Then when you os.chdir()
you will be able to import from the current working directory.

>>> from pprint import pprint
>>> import sys
>>> pprint(sys.path)
['',
 'C:\\Code',
 'C:\\Python21\\win32',
 'C:\\Python21\\win32\\lib',
 'C:\\Python21',
 'C:\\Python21\\Pythonwin',
 'C:\\PYTHON21\\DLLs',
 'C:\\PYTHON21\\lib',
 'C:\\PYTHON21\\lib\\plat-win',
 'C:\\PYTHON21\\lib\\lib-tk',
 'C:\\PYTHON21\\Numeric']
>>> import os
>>> sys.path.insert(0, os.curdir)
>>> pprint(sys.path)
['.',
 '',
 'C:\\Code',
 'C:\\Python21\\win32',
 'C:\\Python21\\win32\\lib',
 'C:\\Python21',
 'C:\\Python21\\Pythonwin',
 'C:\\PYTHON21\\DLLs',
 'C:\\PYTHON21\\lib',
 'C:\\PYTHON21\\lib\\plat-win',
 'C:\\PYTHON21\\lib\\lib-tk',
 'C:\\PYTHON21\\Numeric']

Because this is pretty useful, I will probably add sys.path.insert(0,
os.curdir) as standard behavior in the shell so you won't have to jump
through this hoop in the future. In fact, I just checked this change into
cvs. Hope this helps. Thanks for the feedback.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Friday, September 07, 2001 4:04 PM
To: pycr
Subject: [PyCrust] problems with os


why doesn't this code work???
>>> import os
>>> os.chdir('d:\sim')
>>> import SThermoAdmin
Traceback (most recent call last):
  File "<input>", line 1, in ?
ImportError: No module named SThermoAdmin

Needless to say , that I tested the same lines in another interpreter
and they work fine.
Tried it with any file that is not in the python path and I get the same
results.


I'll try to find the reason myself since I'm going to be playing around
with PyCrust today, because I'm planning on implementing it in my
application (currently I'm using shell.py that comes in the wxPython
distribution)

BTW. Thanks for the icon... it looks really cool!!!

Raul

Win NT; Python 2.1; wxPython 2.3.1

_______________________________________________
PyCrust-users mailing list
PyC...@li...
https://lists.sourceforge.net/lists/listinfo/pycrust-users

RE: [PyCrust] problems with os

[Patrick K. O'B. <po...@or...>]

Anyone who likes the icon could do me a favor by sending a thank-you to the
artist, Kaijian Xu [xk...@ma...], to let them know we appreciate
their support.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Friday, September 07, 2001 4:04 PM
To: pycr
Subject: [PyCrust] problems with os

[POB] <snip>

BTW. Thanks for the icon... it looks really cool!!!

Raul

Win NT; Python 2.1; wxPython 2.3.1

_______________________________________________
PyCrust-users mailing list
PyC...@li...
https://lists.sourceforge.net/lists/listinfo/pycrust-users

[PyCrust] problems with os

[Raul C. <co...@uc...>]

why doesn't this code work???
>>> import os
>>> os.chdir('d:\sim')
>>> import SThermoAdmin
Traceback (most recent call last):
  File "<input>", line 1, in ?
ImportError: No module named SThermoAdmin

Needless to say , that I tested the same lines in another interpreter
and they work fine.
Tried it with any file that is not in the python path and I get the same
results.


I'll try to find the reason myself since I'm going to be playing around
with PyCrust today, because I'm planning on implementing it in my
application (currently I'm using shell.py that comes in the wxPython
distribution)

BTW. Thanks for the icon... it looks really cool!!!

Raul

Win NT; Python 2.1; wxPython 2.3.1

RE: [PyCrust] PyCrust.ico problem

[Patrick K. O'B. <po...@or...>]

Yeah. I messed up the first time I had added the file. I thought I had fixed
it, but apparently I hadn't. So I deleted the file and added it again making
extra sure it went into cvs as a binary file. I think I got it right this
time.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Robin Dunn
Sent: Friday, September 07, 2001 2:21 PM
To: po...@or...; pycr
Subject: Re: [PyCrust] PyCrust.ico problem

> Sorry. It works fine for me. When exactly do you get this error and can
you
> capture the entire error message? And what platform are you running on?
> Oops, I see that you are on Win NT, right?

I've seen it too.  I expect that the icon in CVS has gotten corrupted.

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





_______________________________________________
PyCrust-users mailing list
PyC...@li...
https://lists.sourceforge.net/lists/listinfo/pycrust-users