Tibco Rendezvous
Has anyone found or written a Tibco Rendezvous (tibrv) module for Python? I've only found some really old ones with German documentation and not updated since some time around 2000. -- http://mail.python.org/mailman/listinfo/python-list
Re: web page text extractor
To maintain paragraphs, replace any p or br tags with your favorite operating system's crlf. On Jul 13, 8:57 am, kublai <[EMAIL PROTECTED]> wrote: > On Jul 13, 5:44 pm, Paul McGuire <[EMAIL PROTECTED]> wrote: > > > > > On Jul 12, 4:42 am, kublai <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > For a project, I need to develop a corpus of online news stories. I'm > > > looking for an application that, given the url of a web page, "copies" > > > the rendered text of the web page (not the source HTNL text), opens a > > > text editor (Notepad), and displays the copied text for the user to > > > examine and save into a text file. Graphics and sidebars to be > > > ignored. The examples I have come across are much too complex for me > > > to customize for this simple job. Can anyone lead me to the right > > > direction? > > > > Thanks, > > > gk > > > One of the examples provided with pyparsing is an HTML stripper - view > > it online athttp://pyparsing.wikispaces.com/space/showimage/htmlStripper.py. > > > -- Paul > > Stripping tags is indeed one strategy that came to mind. I'm wondering > how much information (for example, paragraphing) would be lost, and if > what would be lost would be acceptable (to the project). I looked at > pyparsing and I see that it's got a lot of text processing > capabilities that I can use along the way. I sure will try it. Thanks > for the post. > > Best, > gk -- http://mail.python.org/mailman/listinfo/python-list
Re: Tibco Rendezvous
Sent you an email - have you found anything else on this? I'm not all that familiar with ctypes, and am having a little trouble getting started with this. Anything I could use just to get started would be fantastic - I can go from there. Thanks! On Jul 13, 1:43 pm, "Kip Lehman" <[EMAIL PROTECTED]> wrote: > Circa summer 2003, at a company I previously worked at, a co-worker and > I had an occasion to see if we could get Python and TIBCO Rendezvous > working together. > > The SWIG-based tibrv mechanism was insufficient, buggy and was problematic > in terms of keeping up with Python releases. > > We resorted to using ctypes with the relevant TIBCO header files > and confabulating our own package to work with TIBCO Rendezvous messages > (both publishing and subscribing). > We didn't concern ourselves with certified messages. > > Feel free to contact me directly if you want me to see if I can > unearth any further info. > > -- > > -- > Kip Lehman > kipster t earthlink net > > ...still waiting for PanAm, Amtrack and the USPS to deliver my .sig -- http://mail.python.org/mailman/listinfo/python-list
Re: Unexpected timing results with file I/O
It doesn't matter how many doors opening and closing there are, it matters the order in which the opening, walking through, and closing are done. That's my point. In the second example, all of the disk operations are done at the same time. That's what I meant by people going through the doors. Maybe it was more clear in my head. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unexpected timing results with file I/O
On Feb 4, 10:17 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> After reading an earlier thread about opening and closing lots of files,
> I thought I'd do a little experiment.
>
> Suppose you have a whole lot of files, and you need to open each one,
> append a string, then close them. There's two obvious ways to do it:
> group your code by file, or group your code by procedure.
>
> # Method one: grouped by file.
> for each file:
> open the file, append the string, then close it
>
> # Method two: grouped by procedure.
> for each file:
> open the file
> for each open file:
> append the string
> for each open file:
> close the file
>
> If you have N files, both methods make the same number of I/O calls: N
> opens, N writes, N closes. Which is faster?
>
> Intuitively, the first method has *got* to be faster, right? It's got one
> loop instead of three and it doesn't build an intermediate list of open
> file objects. It's so *obviously* going to be faster that it is hardly
> worth bothering to check it with timeit, right?
>
> Well, I wouldn't be writing unless that intuitive result was wrong. So
> here's my test results:
>
> Method 1:
>
> >>> import timeit
> >>> names = ['afile' + str(n) for n in range(1000)]
> >>> T = timeit.Timer('''for name in names:
>
> ... fp = open(name, 'a'); fp.write('xyz\\n'); fp.close()
> ... ''', 'from __main__ import names')>>> min(T.repeat(6, 500))
>
> 17.391216039657593
>
> Method 2:
>
> >>> for name in names: # reset the files to an empty state.
>
> ... fp = open(name, 'w'); fp.close()
> ...>>> T = timeit.Timer('''files = [open(name, 'a') for name in names]
>
> ... for fp in files:
> ... fp.write('xyz\\n')
> ... for fp in files:
> ... fp.close()
> ... ''', '''from __main__ import names''')>>> min(T.repeat(6, 500))
>
> 16.823362112045288
>
> Surprisingly, Method 2 is a smidgen faster, by about half a second over
> 500,000 open-write-close cycles. It's not much faster, but it's
> consistent, over many tests, changing many of the parameters (e.g. the
> number of files, the number of runs per timeit test, etc.).
>
> I'm using Linux and Python 2.5.
>
> So, what's going on? Can anyone explain why the code which does more work
> takes less time?
>
> --
> Steven
The code that does more work takes more time. The second one does
quite a bit less work. Think of it like this:
You have 500,000 people to fit through a door. Here are your options:
1. For each person, open the door, walk through the door, then close
the door.
2. Open the door, allow everyone to walk through, then close the
door.
Which one would you say would be a more efficient way to fit 500,000
people through the door?
--
http://mail.python.org/mailman/listinfo/python-list
Windows - remote system window text
OK - I know how to get the text/title of the windows on a local system by using the window handle. What I want to do is to get the text/ title of the windows on a remote system. Enumerating the window handles will of course not work remotely, I know that. Does anyone know anything short of a client/server setup that *will* work? Everything would be Windows 2003 server, and I can assume that I have administrative rights to all affected machines. Any ideas? -- http://mail.python.org/mailman/listinfo/python-list
Re: Unexpected timing results with file I/O
On Feb 4, 1:12 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Feb 4, 12:53 pm, rdahlstrom <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Feb 4, 10:17 am, Steven D'Aprano <[EMAIL PROTECTED]
>
> > cybersource.com.au> wrote:
> > > After reading an earlier thread about opening and closing lots of files,
> > > I thought I'd do a little experiment.
>
> > > Suppose you have a whole lot of files, and you need to open each one,
> > > append a string, then close them. There's two obvious ways to do it:
> > > group your code by file, or group your code by procedure.
>
> > > # Method one: grouped by file.
> > > for each file:
> > > open the file, append the string, then close it
>
> > > # Method two: grouped by procedure.
> > > for each file:
> > > open the file
> > > for each open file:
> > > append the string
> > > for each open file:
> > > close the file
>
> > > If you have N files, both methods make the same number of I/O calls: N
> > > opens, N writes, N closes. Which is faster?
>
> > > Intuitively, the first method has *got* to be faster, right? It's got one
> > > loop instead of three and it doesn't build an intermediate list of open
> > > file objects. It's so *obviously* going to be faster that it is hardly
> > > worth bothering to check it with timeit, right?
>
> > > Well, I wouldn't be writing unless that intuitive result was wrong. So
> > > here's my test results:
>
> > > Method 1:
>
> > > >>> import timeit
> > > >>> names = ['afile' + str(n) for n in range(1000)]
> > > >>> T = timeit.Timer('''for name in names:
>
> > > ... fp = open(name, 'a'); fp.write('xyz\\n'); fp.close()
> > > ... ''', 'from __main__ import names')>>> min(T.repeat(6, 500))
>
> > > 17.391216039657593
>
> > > Method 2:
>
> > > >>> for name in names: # reset the files to an empty state.
>
> > > ... fp = open(name, 'w'); fp.close()
> > > ...>>> T = timeit.Timer('''files = [open(name, 'a') for name in names]
>
> > > ... for fp in files:
> > > ... fp.write('xyz\\n')
> > > ... for fp in files:
> > > ... fp.close()
> > > ... ''', '''from __main__ import names''')>>> min(T.repeat(6, 500))
>
> > > 16.823362112045288
>
> > > Surprisingly, Method 2 is a smidgen faster, by about half a second over
> > > 500,000 open-write-close cycles. It's not much faster, but it's
> > > consistent, over many tests, changing many of the parameters (e.g. the
> > > number of files, the number of runs per timeit test, etc.).
>
> > > I'm using Linux and Python 2.5.
>
> > > So, what's going on? Can anyone explain why the code which does more work
> > > takes less time?
>
> > > --
> > > Steven
>
> > The code that does more work takes more time. The second one does
> > quite a bit less work. Think of it like this:
>
> > You have 500,000 people to fit through a door. Here are your options:
>
> > 1. For each person, open the door, walk through the door, then close
> > the door.
> > 2. Open the door, allow everyone to walk through, then close the
> > door.
>
> > Which one would you say would be a more efficient way to fit 500,000
> > people through the door?
>
> Bad analogy. A better analogy would be if each person has their own
> door to walk through.
>
> My hunch is that is has to do with the OS I/O scheduling. Closing a
> file triggers a cache flush, which in turn triggers the I/O to
> schedule a write to disk; the OS scheduler is perhaps more efficient
> (for a given number of total writes) when it can combine many writes
> at the same time.
>
> Carl Banks
The analogy holds. It's faster to open the door, do what you need to
do, then close the door than it is to open and close the door each
time.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Windows - remote system window text
On Feb 4, 2:17 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Well, i guess you will need a process on each machine you need to > monitor, and then you do have a client server setup. > > This can be easily accomplished with fx Pyro (http:// > pyro.sourceforge.net/) for communication, and the Win32 Python library > (https://sourceforge.net/projects/pywin32/) for creating a service. Crap, that's what I didn't want to do. I am slowly coming to the realization that I'm going to have to, but I really didn't want to do that. That brings up a whole host of other things that I would then have to do - remote installation, etc. I guess I could do it, but I'd really rather not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows - remote system window text
On Feb 4, 2:50 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I can understand that. But look at the bright side, you don't have to > rely on windows authentication, you just need an open port. Now i > don't know what you are building, but with a client/server setup you > can also get to other data that you might need, like mouse movement to > detect for activity, username, etc. That is true, and I could use some of the additional functionality I guess... -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows - remote system window text
On Feb 5, 3:54 am, Tim Golden <[EMAIL PROTECTED]> wrote: > Gabriel Genellina wrote: > > En Mon, 04 Feb 2008 17:25:00 -0200, rdahlstrom <[EMAIL PROTECTED]> > > escribió: > >> On Feb 4, 2:17 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > >>> Well, i guess you will need a process on each machine you need to > >>> monitor, and then you do have a client server setup. > >> Crap, that's what I didn't want to do. I am slowly coming to the > >> realization that I'm going to have to, but I really didn't want to do > >> that. > > > Try WMI. I don't know for sure if you can enumerate windows, maybe yes. At > > least you can enumerate remote processes. > > Pretty sure not. You can just about get hold of a logon session > on the other machine and I did poke about through some of the > Lsa... and other stuff to see whether that was enough to give > you a remote workstation / windows list. But it doesn't seem > likely. (Happy to be proved wrong :) > > TJG You don't know how happy to be proved wrong I would be... but I don't think WMI will do what I want. I can get almost everything - command line parameters, process ID, kill, restart, etc., but not the window name, which I need. -- http://mail.python.org/mailman/listinfo/python-list
CTypes, 64 bit windows, 32 bit dll
So I have a 64 bit Windows 2003 system, running python 2.5.1.1. I can import a Windows .dll (msvcrt or whatever) using ctypes, but when attempting to import another application-specific .dll (tibrv.dll if anyone is familiar with it), I receive the error WindowsError: [Error 193] %1 is not a valid Win32 application. I know there's a Windows on Windows (wow) which allows 32 bit processes to run on 64 bit windows - is there a way to work this in somehow? Maybe I'm barking up the wrong tree? Code is simple, and works on 32 bit systems no from ctypes import * #this doesn't work tibrv = cdll.tibrv #this does work msvcrt = cdll.msvcrt -- http://mail.python.org/mailman/listinfo/python-list
Re: CTypes, 64 bit windows, 32 bit dll
On Mar 31, 10:22 am, rdahlstrom <[EMAIL PROTECTED]> wrote: > So I have a 64 bit Windows 2003 system, running python 2.5.1.1. > > I can import a Windows .dll (msvcrt or whatever) using ctypes, but > when attempting to import another application-specific .dll (tibrv.dll > if anyone is familiar with it), I receive the error WindowsError: > [Error 193] %1 is not a valid Win32 application. > > I know there's a Windows on Windows (wow) which allows 32 bit > processes to run on 64 bit windows - is there a way to work this in > somehow? Maybe I'm barking up the wrong tree? > > Code is simple, and works on 32 bit systems no > > from ctypes import * > #this doesn't work > tibrv = cdll.tibrv > #this does work > msvcrt = cdll.msvcrt And by "works on 32 bit systems no", I mean "works on 32 bit systems no problem." -- http://mail.python.org/mailman/listinfo/python-list
Re: CTypes, 64 bit windows, 32 bit dll
On Mar 31, 12:53 pm, "mimi.vx" <[EMAIL PROTECTED]> wrote: > On Mar 31, 4:22 pm, rdahlstrom <[EMAIL PROTECTED]> wrote: > > > > > So I have a 64 bit Windows 2003 system, running python 2.5.1.1. > > > I can import a Windows .dll (msvcrt or whatever) using ctypes, but > > when attempting to import another application-specific .dll (tibrv.dll > > if anyone is familiar with it), I receive the error WindowsError: > > [Error 193] %1 is not a valid Win32 application. > > > I know there's a Windows on Windows (wow) which allows 32 bit > > processes to run on 64 bit windows - is there a way to work this in > > somehow? Maybe I'm barking up the wrong tree? > > > Code is simple, and works on 32 bit systems no > > > from ctypes import * > > #this doesn't work > > tibrv = cdll.tibrv > > #this does work > > msvcrt = cdll.msvcrt > > all dlls and python must be 32bit or 64bit, no mixed ... Crap, no way to make a 32 bit load, even using the wowexec? -- http://mail.python.org/mailman/listinfo/python-list
Re: CTypes, 64 bit windows, 32 bit dll
On Apr 1, 2:03 am, Tim Roberts <[EMAIL PROTECTED]> wrote: > rdahlstrom <[EMAIL PROTECTED]> wrote: > >On Mar 31, 12:53 pm, "mimi.vx" <[EMAIL PROTECTED]> wrote: > >> On Mar 31, 4:22 pm, rdahlstrom <[EMAIL PROTECTED]> wrote: > > >> > So I have a 64 bit Windows 2003 system, running python 2.5.1.1. > > >> > I can import a Windows .dll (msvcrt or whatever) using ctypes, but > >> > when attempting to import another application-specific .dll (tibrv.dll > >> > if anyone is familiar with it), I receive the error WindowsError: > >> > [Error 193] %1 is not a valid Win32 application. > > >> > I know there's a Windows on Windows (wow) which allows 32 bit > >> > processes to run on 64 bit windows - is there a way to work this in > >> > somehow? Maybe I'm barking up the wrong tree? > >>... > > >> all dlls and python must be 32bit or 64bit, no mixed ... > > >Crap, no way to make a 32 bit load, even using the wowexec? > > No. In Win64, a process is either entirely 32-bit, or entirely 64-bit. To > do the kind of crossing you seek, you would need to create a separate > process for the 32-bit DLL and use interprocess communication. > -- > Tim Roberts, [EMAIL PROTECTED] > Providenza & Boekelheide, Inc. Shoot. Alright, thanks for your help. I guess I'll have to roll out a 64-bit version of the tibco software. -- http://mail.python.org/mailman/listinfo/python-list
Windows - window status (Running vs Not Responding)
Does anyone know how to determine the window status (Running or Not Responding)? I've tried various methods with no success... This would be on a variety of Windows systems, but all at least XP, and mostly server 2003. Everyone will have Python 2.5.1 on them, and the script would be running locally. Any ideas? -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows - window status (Running vs Not Responding)
On Apr 11, 1:45 pm, rdahlstrom <[EMAIL PROTECTED]> wrote: > Does anyone know how to determine the window status (Running or Not > Responding)? I've tried various methods with no success... > > This would be on a variety of Windows systems, but all at least XP, > and mostly server 2003. Everyone will have Python 2.5.1 on them, and > the script would be running locally. > > Any ideas? Basically, I'm looking for something similar to the Process.Responding property in System.Diagnostics... -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows - window status (Running vs Not Responding)
On Apr 11, 11:18 pm, Ross Ridge <[EMAIL PROTECTED]> wrote: > rdahlstrom <[EMAIL PROTECTED]> wrote: > >Basically, I'm looking for something similar to the Process.Responding > >property in System.Diagnostics... > > You probably want to use IsHungAppWindow(): > > IsHungAppWindow Function > > You call the IsHungAppWindow function to determine if > Microsoft Windows considers that a specified application is not > responding. An application is considered to be not responding > if it is not waiting for input, is not in startup processing, > and has not called PeekMessage within the internal timeout period > of 5 seconds. > > Syntax > > BOOL IsHungAppWindow( > HWND hWnd > ); > > ... > > You can use EnumWindows() to enumerate the all the top level windows. > > Ross Ridge > > -- > l/ // Ross Ridge -- The Great HTMU > [oo][oo] [EMAIL PROTECTED] > -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ > db // Holy crap, so simple, yet so awesome. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
