Re: Help: Guide needed in trying to delete/flush the content of a fifo file.
On Nov 14, 11:55 pm, MRAB wrote: > On 14/11/2010 14:48, ton ph wrote:> Hi python geeks, > > I have problem which i have been trying to find out for the past > > some days, i have a device which feeds info to my fifo continuosly, and > > a thread of mine reads the > > fifo continuosly. Now when i change a parameter in the device, it sends > > me different values. Now my problem is that , i want to get rid of the > > contents of my previous info which > > is present in my buffer of the fifo.So i want to flush the fifo content > > when my device starts sending different info i am implementing > > writing and reading the fifo using two different threads. > > Please someone guide me solving my problem. > > I highly apologise everyone in case my post is not so clear... > > Thanks everyone in advance. > > When the info changes, the thread which is putting items into the fifo > could flush it just by getting items from it (using a non-blocking get) > until it's empty. Hi Mrab, Thanks for your immediate reply , can you please guide me with any tool or library function which i can flush my fifo content .. i use os.mkfifo() to make the fifo. Or is there any other way i could do this ... Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Help: Guide needed in trying to delete/flush the content of a fifo file.
On Nov 16, 1:47 am, MRAB wrote: > On 15/11/2010 11:03, Ton wrote: > > > > > On Nov 14, 11:55 pm, MRAB wrote: > >> On 14/11/2010 14:48, ton ph wrote:> Hi python geeks, > >>> I have problem which i have been trying to find out for the past > >>> some days, i have a device which feeds info to my fifo continuosly, and > >>> a thread of mine reads the > >>> fifo continuosly. Now when i change a parameter in the device, it sends > >>> me different values. Now my problem is that , i want to get rid of the > >>> contents of my previous info which > >>> is present in my buffer of the fifo.So i want to flush the fifo content > >>> when my device starts sending different info i am implementing > >>> writing and reading the fifo using two different threads. > >>> Please someone guide me solving my problem. > >>> I highly apologise everyone in case my post is not so clear... > >>> Thanks everyone in advance. > > >> When the info changes, the thread which is putting items into the fifo > >> could flush it just by getting items from it (using a non-blocking get) > >> until it's empty. > > > Hi Mrab, > > Thanks for your immediate reply , can you please guide me with any > > tool or library function which i can flush my fifo content .. i use > > os.mkfifo() to make the fifo. Or is there any other way i could do > > this ... > > Thanks > > Ah, you're using pipes; I thought you might've been using a queue. I > don't know of a way of flushing a pipe. > > I wonder whether it's a good idea for the producer to keep filling the > fifo, because the consumer know how 'old' the info is when it arrives, > and there's your problem of discarding stale info. Perhaps the producer > should wait until the consumer has sent an acknowledgement before > sending more info. Thanks Mrab, the problem now is that the producer continously dumps the information and since i am implementing the producer using the subprocess as like this cmd = ['my files'] proc = subprocess.Popen(cmd, shell=True, bufsize=0, stdout=subprocess.PIPE, stderr=subprocess.STDOUT ) while flag == True: line = proc.stdout.read() Now what i want is to synchronise the problem of actual info the device is sending and the proper reading as the device is sending and not about reading the previous old info in the fifo... hope i have made clearer my prob. even i have tried proc.stdout.flush(), to flush the previous old info in the fifo. Thnks -- http://mail.python.org/mailman/listinfo/python-list
Re: Help: Guide needed in trying to delete/flush the content of a fifo file.
Thanks Mrab ... the way of how to use the pipe for the producer as well as the consumer is a bit confusing to me. As i am using the subprocess for both the producer and the consumer as above. Can you please explain me further using a bit of pseudocode. Thanks for ur concern. In Nov 17, 12:13 am, MRAB wrote: > On 16/11/2010 06:52, Ton wrote: > > > > > On Nov 16, 1:47 am, MRAB wrote: > >> On 15/11/2010 11:03, Ton wrote: > > >>> On Nov 14, 11:55 pm, MRAB wrote: > >>>> On 14/11/2010 14:48, ton ph wrote:> Hi python geeks, > >>>>> I have problem which i have been trying to find out for the past > >>>>> some days, i have a device which feeds info to my fifo continuosly, and > >>>>> a thread of mine reads the > >>>>> fifo continuosly. Now when i change a parameter in the device, it sends > >>>>> me different values. Now my problem is that , i want to get rid of the > >>>>> contents of my previous info which > >>>>> is present in my buffer of the fifo.So i want to flush the fifo content > >>>>> when my device starts sending different info i am implementing > >>>>> writing and reading the fifo using two different threads. > >>>>> Please someone guide me solving my problem. > >>>>> I highly apologise everyone in case my post is not so clear... > >>>>> Thanks everyone in advance. > > >>>> When the info changes, the thread which is putting items into the fifo > >>>> could flush it just by getting items from it (using a non-blocking get) > >>>> until it's empty. > > >>> Hi Mrab, > >>> Thanks for your immediate reply , can you please guide me with any > >>> tool or library function which i can flush my fifo content .. i use > >>> os.mkfifo() to make the fifo. Or is there any other way i could do > >>> this ... > >>> Thanks > > >> Ah, you're using pipes; I thought you might've been using a queue. I > >> don't know of a way of flushing a pipe. > > >> I wonder whether it's a good idea for the producer to keep filling the > >> fifo, because the consumer know how 'old' the info is when it arrives, > >> and there's your problem of discarding stale info. Perhaps the producer > >> should wait until the consumer has sent an acknowledgement before > >> sending more info. > > > Thanks Mrab, > > the problem now is that the producer continously dumps the > > information and since i am implementing the producer using the > > subprocess as like this > > > cmd = ['my files'] > > proc = subprocess.Popen(cmd, shell=True, bufsize=0, > > stdout=subprocess.PIPE, stderr=subprocess.STDOUT ) > > > while flag == True: > > line = proc.stdout.read() > > > Now what i want is to synchronise the problem of actual info the > > device is sending and the proper reading as the device is sending and > > not about reading the previous old info in the fifo... hope i have > > made clearer my prob. even i have tried proc.stdout.flush(), to flush > > the previous old info in the fifo. Thnks > > Use two pipes, one each way. The consumer could use send a message to > the producer requesting an update, which the producer could send back > via the other pipe. Thanks marab for your immediate reply. But how actually i go for using pipes in the producer and consumer is a bit doubtful . can you please explain with a pseudocode ... as in my case both producer and consumer are executed using the subprocess as my previous post Thanks -- http://mail.python.org/mailman/listinfo/python-list
Help: problem in setting the background colour ListBox
Hi everyone , I have a requirement of displaying my data in a textCtrl like widget , but i need that the data in the row be clickable , so as when i click the data i could be able to get fire and even and get me the selected data value.After a long search i found ListBox to be perfect for my use but When i try to set the backGround colour to the colour of my application requirement i am not able to do so, but i am able to set the foreground colour . Hope someone will guide me in solving my problem Thanks -- http://mail.python.org/mailman/listinfo/python-list
Help: Guide needed in trying to delete/flush the content of a fifo file.
Hi python geeks, I have problem which i have been trying to find out for the past some days, i have a device which feeds info to my fifo continuosly, and a thread of mine reads the fifo continuosly. Now when i change a parameter in the device, it sends me different values. Now my problem is that , i want to get rid of the contents of my previous info which is present in my buffer of the fifo.So i want to flush the fifo content when my device starts sending different info i am implementing writing and reading the fifo using two different threads. Please someone guide me solving my problem. I highly apologise everyone in case my post is not so clear... Thanks everyone in advance. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
On Sat, 16 Apr 2011 13:20:32 +1000, Alec Taylor wrote: >Good Afternoon, > >I'm looking for an IDE which offers syntax-highlighting, >code-completion, tabs, an embedded interpreter and which is portable >(for running from USB on Windows). > >Here's a mockup of the app I'm looking for: http://i52.tinypic.com/2uojswz.png > >Which would you recommend? > >Thanks in advance for any suggestions, > >Alec Taylor For the record, do have a look at the Python Toolkit (PTK) project at http://pythontoolkit.sourceforge.net/ There is a platform independant source (.zip), however wxPython is a requirement (so possibly not 'exactly' what you are looking for) -- Ton -- http://mail.python.org/mailman/listinfo/python-list
Re: python at command prompt
On Thu, 01 Nov 2007 09:17:00 -0700, [EMAIL PROTECTED] wrote: >Hi, >I am python newbie and the command prompt is having an issue with >python. I installed python 2.4.4 onto my windows machine, opened a >command prompt window, and typed python to start the interactive mode. >Got the following error. > >D:\>python >'python' is not recognized as an internal or external command, >operable program or batch file. > >The following programs work fine >IDLE (Python GUI) >Python (command line) >PythonWin > >For some strange reason, python is not recognized at the command >prompt. >Does anyone have any ideas as to why this is happening? >thanks, There's could also be an issue with entering 'python' at the command line, and not 'python.exe'. Once the PATH is setup correctly, try to enter 'python.exe', and check whether that works. IMHO, to get any 'program-name' (without the .exe extension) to work, one needs to: 1. register the executable with windows (doesn't work for python) or 2. make sure the the PATHEXT environment variable is set correctly, and includes the .EXE extension (on my w2k system it looks like: .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH) -- Ton -- http://mail.python.org/mailman/listinfo/python-list
Re: python at command prompt
On Sat, 03 Nov 2007 22:51:05 GMT, Tim Roberts <[EMAIL PROTECTED]> wrote: >Ton van Vliet <[EMAIL PROTECTED]> wrote: >> >>There's could also be an issue with entering 'python' at the command >>line, and not 'python.exe'. Once the PATH is setup correctly, try to >>enter 'python.exe', and check whether that works. >> >>IMHO, to get any 'program-name' (without the .exe extension) to work, >>one needs to: >>1. register the executable with windows (doesn't work for python) or >>2. make sure the the PATHEXT environment variable is set correctly, >>and includes the .EXE extension (on my w2k system it looks like: >>.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH) please note that I state 1 *or* 2 >You're confusing two things here. Executables (.exe) are always available, >and do not need to be registered to be run without the extension. but *only* if the PATHEXT environment variable is setup correctly >It is possible to have Windows execute "abc.py" when you type "abc", and >that DOES require registering the .py extension and adding .py to the >PATHEXT environment variable. There are executables (.exe) that have a 'registering' option builtin, and need to be registered to have their capabilities made available using the /regserver switch (possibly related to OLE/COM services, but I'm not an expert here ;-) see: http://consumer.installshield.com/kb.asp?id=Q108199 (last para) >A very useful thing to do, by the way. I have many command line tools for >which I have forgotten whether they are batch files, small executables, or >Python scripts. And that's how it should be. -- Ton -- http://mail.python.org/mailman/listinfo/python-list
Re: python at command prompt
On Mon, 05 Nov 2007 11:03:36 +1100, "[david]" <[EMAIL PROTECTED]> wrote: >Tim Roberts wrote: >> Ton van Vliet <[EMAIL PROTECTED]> wrote: >>> There's could also be an issue with entering 'python' at the command >>> line, and not 'python.exe'. Once the PATH is setup correctly, try to >>> enter 'python.exe', and check whether that works. >>> >>> IMHO, to get any 'program-name' (without the .exe extension) to work, >>> one needs to: >>> 1. register the executable with windows (doesn't work for python) or >>> 2. make sure the the PATHEXT environment variable is set correctly, >>> and includes the .EXE extension (on my w2k system it looks like: >>> .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH) >> >> You're confusing two things here. Executables (.exe) are always available, >> and do not need to be registered to be run without the extension. >> >> It is possible to have Windows execute "abc.py" when you type "abc", and >> that DOES require registering the .py extension and adding .py to the >> PATHEXT environment variable. >> >> A very useful thing to do, by the way. I have many command line tools for >> which I have forgotten whether they are batch files, small executables, or >> Python scripts. And that's how it should be. > >That is, > >"Executables (.exe) are always available," >... provided that the PATHEXT environment variable >has not been set incorrectly... Right >and >"Executables ... do not need to be registered" Right also, however they may be 'registered' to get a 'similar' kind of response: If you have a look at the following registry key: HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths you may find several 'registered' applications that can be launched without appending the .exe extension from the 'start|run' menu If you want to experiment for yourself: (needless to say: be carefull) 1. Select a small stand-alone .exe application of your choice 2. *copy* the .exe into some directory that is not on your PATH (e.g. d:\temp) 3. Rename the application (e.g. to 'eppo.exe') 4. Open regedit and add an 'eppo.exe' to the above mentioned 'App Paths' key 5. Modify its (Default) value to 'd:\temp\eppo.exe' >From now on you can just enter 'eppo' at 'Start|Run' entry field, to launch the application To make entering 'eppo' working at the command prompt, the directory in which the eppo.exe is located must be in the (search) PATH, even if the PATHEXT is *not* setup correctly. If the applications directory is not on your PATH, you may still start it with 'start eppo' I definitely am not an expert in this area, so may someone else may come with a better explanation of this .exe registering stuff, I'm sure there's more involved (like setting of the 'open with' keys, registering COM servers, etc) but I just wanted to bring up that 'registering' executables is not *that* uncommon. HTH ;-) -- Ton -- http://mail.python.org/mailman/listinfo/python-list
Re: python at command prompt
On Tue, 06 Nov 2007 04:20:17 GMT, Tim Roberts <[EMAIL PROTECTED]> wrote: >>There are executables (.exe) that have a 'registering' option builtin, >>and need to be registered to have their capabilities made available >>using the /regserver switch (possibly related to OLE/COM services, but >>I'm not an expert here ;-) > >Yes, that's strictly for COM. Thanks for the confirmation. >And the "App Paths" registry key you mentioned is only for Explorer >things, like the Start menu's "Run" box. It doesn't apply to the >command line. Try typing "wordpad" in a cmd shell, then try it >in Start -> Run. Which, as I learned now, can be 'simulated' by typing 'start wordpad' at the command line (I wasn't aware of that before) Let's hope the OP got his problem solved ;-) -- Ton -- http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
On Fri, 23 Nov 2007 17:16:25 -0800, "Patrick Mullen" <[EMAIL PROTECTED]> wrote: >Most of the time self doesn't bother me in the slightest. The one >time it does bother me however, is when I am turning a function into a >method. In this case, often I have many local variables which I >actually want to be instance variables, so I have to add self to all >of them. Of course, this is going to cause me some grief no matter >which language I am using. If it was enough trouble, it wouldn't be >hard to make a filter that converts my code automatically. Just bringing up something I sometimes miss from good-old Turbo-Pascal here, which has the WITH statement to reduce the typing overhead with (long) record/struct prefixes, used like: with do begin a = ... b = ... end; where all variables would be automatically prefixed with the (if present in the already available record definition!) In your case where you have something like: def somefunction(...): a = ... b = ... ... c = a + b could (simply :-) become something like: def somefunction(self, ...): using self: a = ... b = ... ... c = a + b so only one line extra and an indentation shift. Of course the interpreter would have to be (much) smarter here, since the (in this case just a simple 'self', but it could be more complex, e.g. some module.levels.deep) is not necessarily defined in advance. Since 'with' is already in use, another keyword (e.g. 'using') would be needed I guess speed would also be a major issue, but readibility would gain from it (IHMO :-) -- Ton -- http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
On 24 Nov 2007 08:48:30 GMT, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: >On Sat, 24 Nov 2007 09:12:34 +0100, Ton van Vliet wrote: > >> Just bringing up something I sometimes miss from good-old Turbo-Pascal >> here, which has the WITH statement to reduce the typing overhead with >> (long) record/struct prefixes, used like: >> >> with do begin >> a = ... >> b = ... >> end; >> >> where all variables would be automatically prefixed with the >> (if present in the already available record definition!) > >And here lies the problem: The compiler decides at compile time which >names are local to a function and there is no equivalent of a record >definition to make that decision. > The whole clause following 'using self:' could be seen as the record definition: all attribute assignments/bindings in there should be prefixed with 'self' (if not already existing in the self namespace?) and thereby become instance attributes, which outside the 'using self' clause still need 'self.' as the (namespace?) prefix. It would not bring an 'implicit' self, but could possibly improve readability in some areas (btw, personally, I don't have anything against the 'explicit' self in general) Even in Pascal the 'with' statement was not meant to improve speed, but merely for readability, especially with complex records. Please, bear with me, I am relatively new to Python (reading books, scanning newsgroups, etc) and feel in no way capable of giving 'educated' or 'well overthought' advise, just my 2 cents ;-) -- Ton -- http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
On 24 Nov 2007 13:56:37 GMT, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]>
wrote:
>On Sat, 24 Nov 2007 14:09:04 +0100, Ton van Vliet wrote:
>
>> On 24 Nov 2007 08:48:30 GMT, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]>
>> wrote:
>>
>>>On Sat, 24 Nov 2007 09:12:34 +0100, Ton van Vliet wrote:
>>>
>>>> Just bringing up something I sometimes miss from good-old Turbo-Pascal
>>>> here, which has the WITH statement to reduce the typing overhead with
>>>> (long) record/struct prefixes, used like:
>>>>
>>>> with do begin
>>>> a = ...
>>>> b = ...
>>>> end;
>>>>
>>>> where all variables would be automatically prefixed with the
>>>> (if present in the already available record definition!)
>>>
>>>And here lies the problem: The compiler decides at compile time which
>>>names are local to a function and there is no equivalent of a record
>>>definition to make that decision.
>>
>> The whole clause following 'using self:' could be seen as the record
>> definition: all attribute assignments/bindings in there should be
>> prefixed with 'self' (if not already existing in the self namespace?)
>> and thereby become instance attributes, which outside the 'using self'
>> clause still need 'self.' as the (namespace?) prefix.
>
>So::
>
>def meth(self):
>using self:
>tmp = raw_input('Enter age: ')
>age = int(tmp)
>
>becomes::
>
>def meth(self):
>using self:
>self.tmp = self.raw_input('Enter age: ')
>self.age = self.int(tmp)
>
>Binding `tmp` unnecessarily to the object and trying to get `raw_input()`
>and `int()` from the object. Ouch. :-)
Absolutely.
However, I was more thinking in terms of attributes only, like this:
def meth(self):
using self:
self.tmp = raw_input('Enter age: ')
self.age = int(self.tmp)
and for the methods check whether there *is* a self. defined
in the class (or even within the 'using' clause), then use it, or else
leave it as it is.
It would require more 'lookup' work, but we're talking 'readability'
here (which would btw not bring much in the example you give ;-)
It would boil down to choice: explicit/speed vs implicit/readability
--
ci vediamo
Ton
--
http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
On 24 Nov 2007 16:07:18 GMT, Duncan Booth <[EMAIL PROTECTED]> wrote: >Ton van Vliet <[EMAIL PROTECTED]> wrote: > >> It would boil down to choice: explicit/speed vs implicit/readability > >No, it would boil down to explicit+speed+readability+maintainability vs >implicit+error prone. It would not be a full fledged *implicit*, but only used in small areas where many self's are coming together, and possibly clutter readability (a subjective classification anyhow) and even could degrade (code) maintainability. >It would mean that as well as the interpreter having to search the >instance to work out whether each name referenced an attribute or a global >the reader would also have to perform the same search. IMHO if it is limited to small overviewable sections I think it could make life of the reader/coder/maintainer even easier and less error prone. I cannot judge for the interpreter part (*if* at all doable, it would probably be the coder's choice between speed and readability) >It would mean that adding a new attribute to an instance would change >the meaning of the methods which is a recipe for disaster. I don't see what you have in mind here? As stated some message levels back: 'bear with me', I'm not an expert, just a beginning user ;-) I have no problems with the explicit self at all, but just brought up Pascal's 'with' statement, invented to improve readability only (and saving some typing as well) and 'transposed' it to python, just as my 2 cents. I don't want to defend or formally propose an implementation, just giving comments where *I* do not fully understand the counter arguments. So let's not 'beat it to death', ok ;-) -- Ton -- http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
On Mon, 26 Nov 2007 20:14:50 +0100, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: >> However, I was more thinking in terms of attributes only > >Too bad : in Python, everything's an object, so 'methods' are attributes >too. Right, but I'm sure *you* know a way to distinguish between them (I'm just a beginner ;-) -- Ton -- http://mail.python.org/mailman/listinfo/python-list
