pycrust-users — PyCrust Users and Developers

RE: [PyCrust] No more input dialogs!

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

[Raúl Cota]
>
> Very nice !!!
>
> Thanks a lot.
> All the changes you've made have been very helpful

You are very welcome. Thanks for the feedback. Keep the suggestions coming.

--
Patrick K. O'Brien
Orbtech
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Web:  http://www.orbtech.com/web/pobrien/
Blog: http://www.orbtech.com/blog/pobrien/
Wiki: http://www.orbtech.com/wiki/PatrickOBrien
-----------------------------------------------

Re: [PyCrust] No more input dialogs!

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

Very nice !!!

Thanks a lot.
All the changes you've made have been very helpful

Raul


----- Original Message -----
From: "Patrick K. O'Brien" <po...@or...>
To: "pycr" <PyC...@li...>
Sent: Tuesday, August 27, 2002 9:30 PM
Subject: [PyCrust] No more input dialogs!


>
> For those of you who have wanted the shell to operate as stdin, rather
than
> getting a dialog box, this feature is now in PyCrust in CVS. It works for
> simple cases as well as for input() and raw_input(). Unfortunately, I am
> able to mess things up by putting input(), for example, inside a loop. If
> anyone could apply some real use cases I would appreciate it. Enjoy.
>
> --
> Patrick K. O'Brien
> Orbtech
> -----------------------------------------------
> "Your source for Python programming expertise."
> -----------------------------------------------
> Web:  http://www.orbtech.com/web/pobrien/
> Blog: http://www.orbtech.com/blog/pobrien/
> Wiki: http://www.orbtech.com/wiki/PatrickOBrien
> -----------------------------------------------
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber - The world's fastest growing
> real-time communications platform! Don't just IM. Build it in!
> http://www.jabber.com/osdn/xim
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users
>

[PyCrust] No more input dialogs!

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

For those of you who have wanted the shell to operate as stdin, rather than
getting a dialog box, this feature is now in PyCrust in CVS. It works for
simple cases as well as for input() and raw_input(). Unfortunately, I am
able to mess things up by putting input(), for example, inside a loop. If
anyone could apply some real use cases I would appreciate it. Enjoy.

--
Patrick K. O'Brien
Orbtech
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Web:  http://www.orbtech.com/web/pobrien/
Blog: http://www.orbtech.com/blog/pobrien/
Wiki: http://www.orbtech.com/wiki/PatrickOBrien
-----------------------------------------------

[PyCrust] Recent changes

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

I just changed the way introspection works with regard to determining which
objects are interesting enough to be expandable in the namespace viewer. In
particular, lists and new style classes are now expandable. The changes are
in CVS. Enjoy.

--
Patrick K. O'Brien
Orbtech
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Web:  http://www.orbtech.com/web/pobrien/
Blog: http://www.orbtech.com/blog/pobrien/
Wiki: http://www.orbtech.com/wiki/PatrickOBrien
-----------------------------------------------

RE: [PyCrust] Small request

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

This all looks good to me. I will patch your changes in the next time I work
on PyCrust. Thank you very much for the feedback and the suggestions.

---
Patrick K. O'Brien
Orbtech
http://www.orbtech.com/web/pobrien/


> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Raul Cota
> Sent: Monday, June 10, 2002 4:25 PM
> To: pyCrust
> Subject: [PyCrust] Small request
>
>
>
> Hi,
>
> Not long ago I asked about keeping the wxStyledCtrl as the stdin so I
> could switch to the CommandInterface I use. Then I realized that the
> CommandInterface could benefit a lot from all the support already
> provided by shell.py if I wrapped my CommandInterface to behave like a
> Python Interpreter. (i.e. Create a class with the methods:
> I did so and now I call shell with my own Interpreter class as a
> parameter, the only problem is that in my case, not only ord('.')
> triggers autocomplete, but also ord('/') and ord(' '). I must say that
> it works like a charm !!! Nice work in PyCrust !!
>
> My request, if possible, is:
>
> In the __init__ method of shell, the line
> self.autoCompKeys = [ord('.')]
>
> In the OnChar method of shell, the lines:
> if key in self.autoCompKeys:
> 	command = self.GetTextRange(stoppos, currpos) + chr(key)
> 	self.write(chr(key))
> 	if self.autoComplete: self.autoCompleteShow(command)
>
> That way I can change self.autoCompKeys to self.autoCompKeys =
> [ord('.'), ord(' '), ord('/')] .
>
> In the ideal case I'd like a method of the type
> self.autoCompKeys = self.interp.GetAutoCompKeys()
> That way, the interpreter decides which keys it supports when running
> the method self.interp.getAutoCompleteList. But that's perhaps too much
> to ask ang drifts away from the original concept of shell.
>
>
>
>
> BTW, I noticed that the ShellFrame doesn't do something like:
>
> EVT_CLOSE(self, self.OnCloseWindow)
>
> def OnCloseWindow(self, event):
> 	self.shell.destroy()
> 	self.Destroy()
>
> And for my interpreter I definitely need to call self.shell.destroy() to
> CleanUp myInterpreterClass
>
> Thanks a lot
>
> Raul
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

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

[PyCrust] Small request

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

Hi, 

Not long ago I asked about keeping the wxStyledCtrl as the stdin so I
could switch to the CommandInterface I use. Then I realized that the
CommandInterface could benefit a lot from all the support already
provided by shell.py if I wrapped my CommandInterface to behave like a
Python Interpreter. (i.e. Create a class with the methods: 
I did so and now I call shell with my own Interpreter class as a
parameter, the only problem is that in my case, not only ord('.')
triggers autocomplete, but also ord('/') and ord(' '). I must say that
it works like a charm !!! Nice work in PyCrust !!

My request, if possible, is:

In the __init__ method of shell, the line
self.autoCompKeys = [ord('.')]

In the OnChar method of shell, the lines:
if key in self.autoCompKeys:
	command = self.GetTextRange(stoppos, currpos) + chr(key)
	self.write(chr(key))
	if self.autoComplete: self.autoCompleteShow(command)

That way I can change self.autoCompKeys to self.autoCompKeys =
[ord('.'), ord(' '), ord('/')] . 

In the ideal case I'd like a method of the type 
self.autoCompKeys = self.interp.GetAutoCompKeys()
That way, the interpreter decides which keys it supports when running
the method self.interp.getAutoCompleteList. But that's perhaps too much
to ask ang drifts away from the original concept of shell.




BTW, I noticed that the ShellFrame doesn't do something like:
 
EVT_CLOSE(self, self.OnCloseWindow)

def OnCloseWindow(self, event):
	self.shell.destroy()
	self.Destroy()

And for my interpreter I definitely need to call self.shell.destroy() to
CleanUp myInterpreterClass

Thanks a lot

Raul

RE: [PyCrust] bug in OnKeyDown

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

I see what you mean. Having dialogs for stdin really sucks. I'll definitely
move this up in my list of priorities, but I can't promise when I'll have
this fixed/improved. In the mean time, I know Boa's shell does it the way
you want. You might find code there that you could patch into PyCrust. I
don't think Riaan would mind.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: Raul Cota [mailto:co...@uc...]
> Sent: Wednesday, May 29, 2002 12:04 PM
> To: po...@or...
> Subject: Re: [PyCrust] bug in OnKeyDown
>
>
>
>
> > That should still work. But having the shell's wxSTC as stdin is not
> > available at this point. Boa does it that way and at some point I'll add
> > that option as well. Does the current dialog box for input not
> work for you
> > for some reason?
>
> not that it doesn't work, but the way it si implemented is that in a
> normal run, I write a series of commands and it is also important to see
> the output and the dialog box pops every time right after I send every
> line.
>
>
> for instance, if I run the following line by line in the dialog box...
> units SI
> thermo = VirtualMaterials.Peng-Robinson
> thermo + PROPANE n-BUTANE ISOBUTANE n-PENTANE
> flash = Flash.SimpleFlash()
> cd flash.In
> Fraction = .25 .25 .25 .25
> T = 0 C
> cd ..
> quit
>
> This is what I'd see if I run it from plain python2.2 (in the DOS
> window)
> D:\sim\cmd>python CommandInterface.py
> /> units SI
> /> thermo = VirtualMaterials.Peng-Robinson
> /> thermo + PROPANE n-BUTANE ISOBUTANE n-PENTANE
> /> flash = Flash.SimpleFlash()
> /> cd flash.In
> /flash.In
> /flash.In> Fraction = .25 .25 .25 .25
> /flash.In> T = 0 C
> /flash.In> cd ..
> /flash
> /flash> quit
> D:\sim\cmd>
>
>
>
> As you can see, if I want to drive a whole simulation (this is supposed
> to be a chemical process simulator), with the command line, it is
> important to see in which port or unit operation I'm working on (i.e.
> />, /flash>, /flash.Out>, etcetera) . And it's easier to write in the
> same shell than to a dialog box.
> I hope you see my point.
>
> To tell you the truth, the whole simulator is intended to be driven by a
> gui which uses PyCrust and if I run the commandinterface with PyCrust,
> the stdin would usually be a file and not sys.stdin. But some times for
> plain testing I rather type.
>
>
> Sorry the message got too long
>
> Raul

RE: [PyCrust] bug in OnKeyDown

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

[Raul Cota]
>
> One thing I didn't like from pyCrust was that I couldnt do the following
> in a line of code:
> shift+home+backspace to delete a whole line

Right now the Escape key will clear everything back to the last ps1 prompt.
I'll look into supporting shift+home+backspace or adding the patch you give
below.

> The reason is that the backspace doesn't get processed if the cursor is
> at the beginning of the line. When I went to the code to adapt it to my
> needs I realized that the following gets processed without problems:
>
> >>> t = 6
> >>> r = 5
> >>> y
>
> If I select with the mouse from the "t" to the end of the "y" and then I
> press whatever key (backspace, delete, etcetera) all the code up to the
> "t" gets deleted, because after the selection, the cursor is in a valid
> position (right after the "y"). And of course a nice crash occurs right
> after.

This is a bug in PyCrust. It should not allow you to delete any complete
commands that have been sent to the interpreter, except by using
shell.clear() to clear the screen.

> This is how I fixed it for myself:

I like when bugs come with a fix. Thanks. ;-)

[fix snipped]

> It seems to work fine but perhaps there are few redundant "if"
> comparisons.

Thanks a lot. I'll take a look at this when I've got some free time.

> BTW: I'm not sure what's going on here....
> if I run this
> sys.stdin.readline()
>
> I get a dialog box requesting an input line. Where does it come from???
> the wxStyledTextCtrl??

shell.py redefines stdin as:

    def readIn(self):
        """Replacement for stdin."""
        prompt = 'Please enter your response:'
        dialog = wxTextEntryDialog(None, prompt, \
                                   'Input Dialog (Standard)', '')
        try:
            if dialog.ShowModal() == wxID_OK:
                text = dialog.GetValue()
                self.write(text + os.linesep)
                return text
        finally:
            dialog.Destroy()
        return ''

> The reason is that I have some code that works like this:
> interface.ProcessCommandStream(stdin, stdout, stdout)
>
> how do I call it, by keeping the wxStyledTestCtrl as stdin??

That should still work. But having the shell's wxSTC as stdin is not
available at this point. Boa does it that way and at some point I'll add
that option as well. Does the current dialog box for input not work for you
for some reason?

---
Patrick K. O'Brien
Orbtech

[PyCrust] bug in OnKeyDown

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

Hi,

One thing I didn't like from pyCrust was that I couldnt do the following
in a line of code:
shift+home+backspace to delete a whole line

The reason is that the backspace doesn't get processed if the cursor is
at the beginning of the line. When I went to the code to adapt it to my
needs I realized that the following gets processed without problems:

>>> t = 6
>>> r = 5
>>> y 

If I select with the mouse from the "t" to the end of the "y" and then I
press whatever key (backspace, delete, etcetera) all the code up to the
"t" gets deleted, because after the selection, the cursor is in a valid
position (right after the "y"). And of course a nice crash occurs right
after.

This is how I fixed it for myself:


in the OnKey() method of shell.py:

# Don't backspace over the latest prompt.
elif key == WXK_BACK:
	if self.GetSelectionStart() != self.GetSelectionEnd():
		if self.CanEdit():
			event.Skip()
	elif currpos > self.promptPosEnd:
		event.Skip()
# Only allow these keys after the latest prompt.
elif key == WXK_TAB:
	#There's no point on processing a tab for a selection ??
	if self.GetSelectionStart() == self.GetSelectionEnd() and
self.CanEdit():
		event.Skip()



in the CanEdit() method of shell.py:

if self.GetSelectionStart() != self.GetSelectionEnd():
	if self.GetSelectionStart() >= self.promptPosEnd \
		and self.GetSelectionEnd() >= self.promptPosEnd:
		return 1
	else:
		return 0
else:
	return self.GetCurrentPos() >= self.promptPosEnd



In general, what the code does is to handle the case of a key pressed
when there is a selection ( i.e. self.GetSelectionStart() !=
self.GetSelectionEnd() )

It seems to work fine but perhaps there are few redundant "if"
comparisons.

I hope what I said made sense

Take Care 

Raúl

BTW: I'm not sure what's going on here.... 
if I run this
sys.stdin.readline()

I get a dialog box requesting an input line. Where does it come from??? 
the wxStyledTextCtrl??

The reason is that I have some code that works like this:
interface.ProcessCommandStream(stdin, stdout, stdout)

how do I call it, by keeping the wxStyledTestCtrl as stdin??

[PyCrust] Bug Fix in CVS

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

Fixed call tip bug where a tip was displayed when a "(" was typed after an
object that wasn't actually callable.

Since this is a minor bug, and the new wxPython has not been released, I'm
considering this part of PyCrust 0.7.2. Is that okay with you Robin? You'll
need to get a fresh snapshot.

---
Patrick K. O'Brien
Orbtech

[PyCrust] RE: [Pythoncard-users] Example of Zope in PyCrust

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

I assumed I didn't need to mention this, but I guess I should have. Your
suspicions are correct. Zope is compiled for Python 2.1, not 2.2. At least,
not yet. So for now you need to launch PyCrust using Python 2.1 in order to
be able to import Zope. Otherwise you'll get the dll mismatch error that you
got.

---
Patrick K. O'Brien
Orbtech

> There is always an awkward one isn't there. I think I may have
> confounded this by running Python 2.2 on my machine (Windows
> 2000, Zope 2.5.0, PyCrust 0.7 - from wxPython 2.3.2.1).
>
> When I add the zope home/lib/python to my path and "import Zope"
> I get a pop up stating "The dynamic link library python21.dll
> could not be found in the specified path " followed by the
> contents of my %PATH%. So, I added "E:\\Work\\Zope\\bin" to my
> path as well (the location of python21.dll) but that didn't solve
> the problem. I'm presuming that this is because I launch pycrust
> using Python 2.2 and that the dlls are somehow incompatible. Or,
> I could just be doing something wrong.
>
> Regards,
> Andy
>
>

[PyCrust] Re: [Pythoncard-users] Example of Zope in PyCrust

[<an...@ha...>]

On Wed, 20 February 2002, "Patrick K. O'Brien" wrote:

> 
> For anyone who wants to poke around Zope from inside PyCrust, here is an
> example of how one starts. Zope must be installed on your machine, but can't
> be running at the same time that PyCrust is accessing it.
> 
> >>> import sys
> >>> sys.path.insert(1, 'C:\\Zope\\lib\\python')
> >>> import Zope
> >>> app = Zope.app()
> >>>
> 
> The app object is the root of the Zope database. From here you can get to
> everything. The easiest way is to drill down into stuff in the namespace
> viewer.
> 
> Note that the path you add to the PythonPath (sys.path) needs to match the
> location on your machine. The example above happens to match where I have
> Zope installed on a Windows machine. The default is for Zope to install
> under Program Files. So in that case the line would be:
> 
> >>> sys.path.insert(1, 'C:\\Program Files\\Zope\\lib\\python')
> 
> If you get an error when you import Zope, you've done something wrong. ;-)
> 
> ---
> Patrick K. O'Brien
> Orbtech
> 
> 

There is always an awkward one isn't there. I think I may have confounded this by running Python 2.2 on my machine (Windows 2000, Zope 2.5.0, PyCrust 0.7 - from wxPython 2.3.2.1).

When I add the zope home/lib/python to my path and "import Zope" I get a pop up stating "The dynamic link library python21.dll could not be found in the specified path " followed by the contents of my %PATH%. So, I added "E:\\Work\\Zope\\bin" to my path as well (the location of python21.dll) but that didn't solve the problem. I'm presuming that this is because I launch pycrust using Python 2.2 and that the dlls are somehow incompatible. Or, I could just be doing something wrong.

Regards,
Andy

RE: [PyCrust] Example of Zope in PyCrust

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

That should work fine. As long as you can import the Zope package, Zope
should take care of the rest. The fact that the files are not on your local
machine shouldn't matter. I guess I misspoke in my original instructions.

It is still true that the Zope server cannot be running. Nor should any
other application have the Zope database open. Let me know if you run into a
snag.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: Keith J. Farmer [mailto:kf...@th...]
> Sent: Wednesday, February 20, 2002 2:02 PM
> To: po...@or...; pycr; Pythoncard
> Subject: RE: [PyCrust] Example of Zope in PyCrust
>
>
> What if you've got the zope directory on a foreign machine, mapped to a
> local drive?
>
> ----------
> Keith J. Farmer
> kf...@th...
> http://www.thuban.org
>
>
> -----Original Message-----
> From: Patrick K. O'Brien [mailto:po...@or...]
> Sent: Wednesday, February 20, 2002 10:06
>
> example of how one starts. Zope must be installed on your machine, but
> can't
> be running at the same time that PyCrust is accessing it.

RE: [PyCrust] Example of Zope in PyCrust

[Keith J. F. <kf...@th...>]

What if you've got the zope directory on a foreign machine, mapped to a
local drive?

----------
Keith J. Farmer
kf...@th...
http://www.thuban.org


-----Original Message-----
From: Patrick K. O'Brien [mailto:po...@or...]
Sent: Wednesday, February 20, 2002 10:06

example of how one starts. Zope must be installed on your machine, but
can't
be running at the same time that PyCrust is accessing it.

[PyCrust] Example of Zope in PyCrust

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

For anyone who wants to poke around Zope from inside PyCrust, here is an
example of how one starts. Zope must be installed on your machine, but can't
be running at the same time that PyCrust is accessing it.

>>> import sys
>>> sys.path.insert(1, 'C:\\Zope\\lib\\python')
>>> import Zope
>>> app = Zope.app()
>>>

The app object is the root of the Zope database. From here you can get to
everything. The easiest way is to drill down into stuff in the namespace
viewer.

Note that the path you add to the PythonPath (sys.path) needs to match the
location on your machine. The example above happens to match where I have
Zope installed on a Windows machine. The default is for Zope to install
under Program Files. So in that case the line would be:

>>> sys.path.insert(1, 'C:\\Program Files\\Zope\\lib\\python')

If you get an error when you import Zope, you've done something wrong. ;-)

---
Patrick K. O'Brien
Orbtech

[PyCrust] PyCrust now allows pasting of multiple commands

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

Did you ever wish you could paste a big chunk of code (like a class
definition, for example) from your editor directly into the PyCrust shell?
Now you can. Any valid sequence of Python code can now be pasted in from the
clipboard. Multiple commands and multiline commands (with or without
prompts, in the event that you are pasting from one shell to another) will
all be handled intelligently. Pasted in text is broken down into individual
commands which are executed and added to the command history. This new
functionality is bound to the Ctrl+Shift+V key combination.

Available in CVS, until the next release. Hope you like it.

---
Patrick K. O'Brien
Orbtech

Re: [PyCrust] FW: underscore kills command completion

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

>
>    Alternate sorting orders could be options if anyone cares enough to
> implement them, but sorting orders should always be consistent.
>
>    One aspect that still isn't handled is that strings that differ only in
> case should have a fixed ordering. As it is, I just consider it a
limitation
> that Scintilla does not support lists with items that differ only in case.

If Scintilla had a set of flags that could be set that determined how to
perform the search it would be cool.  Perhaps a flag for binary (as it is
now), linear_till_greater (assumes sorted, searches until list item is >
search item), and linear_till_end (searches until item is found or end of
list).  With the last one it wont matter if the list order matches the
comparrison order as long the list is not huge.

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

Re: [PyCrust] FW: underscore kills command completion

[Neil H. <ne...@sc...>]

Patrick:

> Will this fix work if I keep the sort order the way it was -
>
>     attributes.sort(lambda x, y: cmp(x.lower(), y.lower()))

   No, as you are using an order that is not consistent with Scintilla.

> I kind of prefer this as it seems more "pythonic" to have the underscore
> attributes at the head of the list. Actually, I'm more partial to that in
> the namespace viewer, which I just changed to sort this way. I guess a
case
> could be made that underscore attributes are less likely to be useful when
> called in the shell, and therefore should be at the end of the list. So it
> isn't a huge deal, I'm just curious.

   Alternate sorting orders could be options if anyone cares enough to
implement them, but sorting orders should always be consistent.

   One aspect that still isn't handled is that strings that differ only in
case should have a fixed ordering. As it is, I just consider it a limitation
that Scintilla does not support lists with items that differ only in case.

   Neil

[PyCrust] Better ZODB/Zope support in PyCrust

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

I improved PyCrust support for ZODB/Zope by extending the namespace viewer
so that it now allows you to drilldown into all the items stored in ZODB
BTrees, which act much like Python dictionaries. This enhancement is
available in the CVS version.

This has been tested with Python 2.2 and the latest StandaloneZODB. As I
intend to support ZODB as much as possible, please let me know any problems
you run into, or features you would like to see.

---
Patrick K. O'Brien
Orbtech

[PyCrust] RE: [wxPython] PyCrust Tasters Wanted: Apply Within

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

Well, I did manage to break something under versions less that Python 2.2.
That has been fixed and is available in CVS. As far as I know, all known
bugs have been patched and everything works on all Python 2.x versions.
Holler if you find otherwise.

P.S. I don't consider lack of documentation a bug. But for those of you
bugged by the lack of documentation, you can now do >>> shell.help() and get
*some* useful information, like keybindings. At least until some generous
volunteer offers to help with the documentation.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: wxp...@li...
> [mailto:wxp...@li...]On Behalf Of Patrick K.
> O'Brien
> Sent: Tuesday, February 05, 2002 1:41 PM
> To: wxPython-Users; pycr
> Subject: [wxPython] PyCrust Tasters Wanted: Apply Within
>
>
> Bad puns aside, I've made some recent changes to PyCrust so that it tastes
> better with Python 2.2. Anyone who would like to help test things should
> check out the version in CVS (0.7.1) and let me know if anything is still
> broken, or whether anything new broke when used with older versions of
> Python (I tested Python 2.1.2 and Python 2.2). Thanks.
>
> http://sourceforge.net/projects/pycrust/
>
> ---
> Patrick K. O'Brien
> Orbtech
>
>
> _______________________________________________
> wxpython-users mailing list
> wxp...@li...
> http://lists.wxwindows.org/mailman/listinfo/wxpython-users

RE: [PyCrust] FW: underscore kills command completion

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

Will this fix work if I keep the sort order the way it was -

    attributes.sort(lambda x, y: cmp(x.lower(), y.lower()))

I kind of prefer this as it seems more "pythonic" to have the underscore
attributes at the head of the list. Actually, I'm more partial to that in
the namespace viewer, which I just changed to sort this way. I guess a case
could be made that underscore attributes are less likely to be useful when
called in the shell, and therefore should be at the end of the list. So it
isn't a huge deal, I'm just curious.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Neil
> Hodgson
> Sent: Thursday, February 07, 2002 12:10 AM
> To: Robin Dunn; po...@or...; Kevin Altis; pycr
> Subject: Re: [PyCrust] FW: underscore kills command completion
>
>
> Robin:
> > Will do.  Neil, will this be going into a Scintilla release soon?
>
>     It is in CVS but as I just released 1.44 a couple of days ago there
> probably won't be another release for two weeks. I hope to solve
> the limited
> line length problem along with caching LineLayout objects for
> that release.
>
>    Neil
>
>
>
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users

Re: [PyCrust] FW: underscore kills command completion

[Neil H. <ne...@sc...>]

Robin:
> Will do.  Neil, will this be going into a Scintilla release soon?

    It is in CVS but as I just released 1.44 a couple of days ago there
probably won't be another release for two weeks. I hope to solve the limited
line length problem along with caching LineLayout objects for that release.

   Neil

Re: [PyCrust] FW: underscore kills command completion

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

Will do.  Neil, will this be going into a Scintilla release soon?

--Robin

----- Original Message -----
From: "Patrick K. O'Brien" <po...@or...>
To: "Neil Hodgson" <ne...@sc...>; "Kevin Altis"
<al...@se...>; "pycr" <PyC...@li...>
Cc: "Robin Dunn" <ro...@al...>
Sent: Wednesday, February 06, 2002 2:48 PM
Subject: RE: [PyCrust] FW: underscore kills command completion


> I don't have the tools to do this, plus it sounds like Robin's domain.
> Robin?
>
> ---
> Patrick K. O'Brien
> Orbtech
>
> > -----Original Message-----
> > From: pyc...@li...
> > [mailto:pyc...@li...]On Behalf Of Neil
> > Hodgson
> > Sent: Wednesday, February 06, 2002 3:10 PM
> > To: po...@or...; Kevin Altis; pycr
> > Subject: Re: [PyCrust] FW: underscore kills command completion
> >
> >
> > Me:
> > > > Something is still broken in the search routine.
> > >
> > >     Yes, there is a bug here so I will look into it.
> >
> >    I think changing the string comparison functions to compare
> > non-alphabetic to upper cased characters will fix this. If you have
> > facilities to build wxPython, then change scintilla/src/PropSet.cxx:
> >
> > int CompareCaseInsensitive(const char *a, const char *b) {
> >  while (*a && *b) {
> >   if (*a != *b) {
> >    char upperA = MakeUpperCase(*a);
> >    char upperB = MakeUpperCase(*b);
> >    if (upperA != upperB)
> >     return upperA - upperB;
> >   }
> >   a++;
> >   b++;
> >  }
> >  // Either *a or *b is nul
> >  return *a - *b;
> > }
> >
> > int CompareNCaseInsensitive(const char *a, const char *b, int len) {
> >  while (*a && *b && len) {
> >   if (*a != *b) {
> >    char upperA = MakeUpperCase(*a);
> >    char upperB = MakeUpperCase(*b);
> >    if (upperA != upperB)
> >     return upperA - upperB;
> >   }
> >   a++;
> >   b++;
> >   len--;
> >  }
> >  if (len == 0)
> >   return 0;
> >  else
> >   // Either *a or *b is nul
> >   return *a - *b;
> > }
> >
> >
> >    Neil
> >
> >
> >
> > _______________________________________________
> > PyCrust-users mailing list
> > PyC...@li...
> > https://lists.sourceforge.net/lists/listinfo/pycrust-users
>
>

RE: [PyCrust] FW: underscore kills command completion

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

I don't have the tools to do this, plus it sounds like Robin's domain.
Robin?

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Neil
> Hodgson
> Sent: Wednesday, February 06, 2002 3:10 PM
> To: po...@or...; Kevin Altis; pycr
> Subject: Re: [PyCrust] FW: underscore kills command completion
>
>
> Me:
> > > Something is still broken in the search routine.
> >
> >     Yes, there is a bug here so I will look into it.
>
>    I think changing the string comparison functions to compare
> non-alphabetic to upper cased characters will fix this. If you have
> facilities to build wxPython, then change scintilla/src/PropSet.cxx:
>
> int CompareCaseInsensitive(const char *a, const char *b) {
>  while (*a && *b) {
>   if (*a != *b) {
>    char upperA = MakeUpperCase(*a);
>    char upperB = MakeUpperCase(*b);
>    if (upperA != upperB)
>     return upperA - upperB;
>   }
>   a++;
>   b++;
>  }
>  // Either *a or *b is nul
>  return *a - *b;
> }
>
> int CompareNCaseInsensitive(const char *a, const char *b, int len) {
>  while (*a && *b && len) {
>   if (*a != *b) {
>    char upperA = MakeUpperCase(*a);
>    char upperB = MakeUpperCase(*b);
>    if (upperA != upperB)
>     return upperA - upperB;
>   }
>   a++;
>   b++;
>   len--;
>  }
>  if (len == 0)
>   return 0;
>  else
>   // Either *a or *b is nul
>   return *a - *b;
> }
>
>
>    Neil
>
>
>
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users

Re: [PyCrust] FW: underscore kills command completion

[Neil H. <ne...@sc...>]

Me:
> > Something is still broken in the search routine.
>
>     Yes, there is a bug here so I will look into it.

   I think changing the string comparison functions to compare
non-alphabetic to upper cased characters will fix this. If you have
facilities to build wxPython, then change scintilla/src/PropSet.cxx:

int CompareCaseInsensitive(const char *a, const char *b) {
 while (*a && *b) {
  if (*a != *b) {
   char upperA = MakeUpperCase(*a);
   char upperB = MakeUpperCase(*b);
   if (upperA != upperB)
    return upperA - upperB;
  }
  a++;
  b++;
 }
 // Either *a or *b is nul
 return *a - *b;
}

int CompareNCaseInsensitive(const char *a, const char *b, int len) {
 while (*a && *b && len) {
  if (*a != *b) {
   char upperA = MakeUpperCase(*a);
   char upperB = MakeUpperCase(*b);
   if (upperA != upperB)
    return upperA - upperB;
  }
  a++;
  b++;
  len--;
 }
 if (len == 0)
  return 0;
 else
  // Either *a or *b is nul
  return *a - *b;
}


   Neil