Re: pyserial to read from DS1615 temperature recorder chip
Grant Edwards wrote: > On 2006-07-24, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >>>Logs of the serial traffic would be helpful. >> >>Here they are. First a log of the traffic generated by the >>T-logger GUI program, abtained with Portmon. > > > I try to avoid Windows as much as humanly possible, but one > thing that appears to be different is that Tlogger clears RTS > and your program sets it. Try clearing RTS in your program > when you set up the serial port. > > If clearing RTS doesn't help, I guess I'd try different flow > control settings (try enabling and disabling RTS/CTS flow > control). > > Since you're dealing with binary data, make sure that Xon/Xoff > flow control is disabled. It could also be a timing issue or handshaking problem. Having to write to the chip "a byte at a time" implies that it could take it a little while to digest each byte; longer than the natural character time for the baud rate, that is. I'm not sure if I'm reading the portmon output correctly, but it looks like the "T-logger" program is waiting for CTS (or possibly some other condition) before sending each byte. The Python program does not appear to be doing so, it's just sending the three bytes, bang bang bang. -- JK -- http://mail.python.org/mailman/listinfo/python-list
Re: HELP!!! How do I send an ACK packet in UDP?????
[EMAIL PROTECTED] wrote: > I need my udp server to send an ACK back to the client when it > successfully receives data from the client to let it know not to retry > the send (yes, I do know this is how TCP works but must be in UDP) > I am using this example code I found on the net for the server, I need > to figure out how to get the ip and port that the client transmitted > from and return an ack response. Any help would be greatly > appreciated.. > > from socket import * > > # Set the socket parameters > host = "localhost" > port = 21567 > buf = 1024 > addr = (host,port) > > # Create socket and bind to address > UDPSock = socket(AF_INET,SOCK_DGRAM) > UDPSock.bind(addr) > > # Receive messages > while 1: > data,addr = UDPSock.recvfrom(buf) Um... There's the sender's address, right there, per the documentation for recvfrom(), which you seem to have read, since you know recvfrom() returns a 2-item sequence. No doubt you realized that seconds after hitting "send". -- JK -- http://mail.python.org/mailman/listinfo/python-list
Re: HELP!!! How do I send an ACK packet in UDP?????
[EMAIL PROTECTED] wrote: > I need my udp server to send an ACK back to the client when it > successfully receives data from the client to let it know not to retry > the send (yes, I do know this is how TCP works but must be in UDP) > I am using this example code I found on the net for the server, I need > to figure out how to get the ip and port that the client transmitted > from and return an ack response. Any help would be greatly > appreciated.. > > from socket import * > > # Set the socket parameters > host = "localhost" > port = 21567 > buf = 1024 > addr = (host,port) > > # Create socket and bind to address > UDPSock = socket(AF_INET,SOCK_DGRAM) > UDPSock.bind(addr) > > # Receive messages > while 1: > data,addr = UDPSock.recvfrom(buf) Um... There's the sender's address, right there, per the documentation for recvfrom(), which you seem to have read, since you know recvfrom() returns a 2-item sequence. No doubt you realized that seconds after hitting "send". -- JK -- http://mail.python.org/mailman/listinfo/python-list
Re: Need a compelling argument to use Django instead of Rails
John J. Lee wrote: > The fact that "open classes" are apparently thought to be a good thing > in Ruby puzzles (and worries) me. This objection strikes me as having the same nature as, "Python's lack of strong protection for class members puzzles (and worries) me". The Pythonic answer to that objection is usually that this is a feature: it lets people who know what they're doing solve problems more easily than if they had to work around a bunch of "helpful" protection. Classes are effectively open in Python, too, at least where methods are concerned, since one can do klass.__dict__["myMethod"]=myMethod. Though admittedly, it isn't widely advertised as a feature of Python. It makes sense to me to think of open classes as being open for extension, not modification. After all, methods added by clients are unlikely to depend on implementation details (though I suppose they could, to which I would say, "Don't do that"). Steve Yegge's "Opinionated Elf" is an example of a problem that is very easy and elegant to solve with open classes, and painful to solve when classes are closed: http://www.cabochon.com/~stevey/blog-rants/polymorphism-fails.html Cheers, -- JK -- http://mail.python.org/mailman/listinfo/python-list
Re: HELP!!! How do I send an ACK packet in UDP?????
[EMAIL PROTECTED] wrote: > Yes, you were right it was already there (sorry, my mistake), the > bigger problem is how do I send an ack packet Look at the docs for socket.sendto(). Of course, deciding what data should be in your "ACK" packet is for you to decide. Cheers, -- JK -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter pack Problem
H J van Rooyen wrote: > Hi, > > I am struggling to get the pack method to do what I intend. > I am trying to display user input in a seperate window, along with > a little description of the field, something like this: > > Current entry > Company : entered co. name > First entry : entered stuff > The second entry: more entered stuff > Entry number three : Last entered stuff You can achieve this with pack(), but only by using a lot of nested panels: +-+ | Current entry | +-+ +-+ |Company : entered co. name | +-+ +-+ |First entry : entered stuff| +-+ +-+ |The second entry: more entered stuff | +-+ +-+ |Entry number three : Last entered stuff | +-+ Create the subpanels and pack the labels into their respective subpanels with side="left" and the entry fields with side="right"; then pack all the subpanels into the main window with side="top". But this is really a PITA, it would be simpler use grid() as Eric B suggests. Once you learn grid(), you will probably never need to use pack() again. -- JK -- http://mail.python.org/mailman/listinfo/python-list
Re: Threads vs Processes
John Henry wrote: > >>Carl, >> OS writers provide much more tools for debugging, tracing, changing >>the priority of, sand-boxing processes than threads (in general) It >>*should* be easier to get a process based solution up and running >>andhave it be more robust, when compared to a threaded solution. >> >>- Paddy (who shies away from threads in C and C++ too ;-) > > > That mythical "process" is more robust then "thread" application > paradigm again. > > No wonder there are so many boring software applications around. > > Granted. Threaded program forces you to think and design your > application much more carefully (to avoid race conditions, dead-locks, > ...) but there is nothing inherently *non-robust* about threaded > applications. In this particular case, the OP (in a different thread) mentioned that his application will be extended by random individuals who can't necessarily be trusted to design their extensions correctly. In that case, segregating the untrusted code, at least, into separate processes seems prudent. The OP also mentioned that: > If I have a system that has a large area of shared memory, > which would be better? IMO, if you're going to be sharing data structures with code that can't be trusted to clean up after itself, you're doomed. There's just no way to make that scenario work reliably. The best you can do is insulate that data behind an API (rather than giving untrusted code direct access to the data -- IOW, don't use threads, because if you do, they can go around your API and screw things up), and ensure that each API call leaves the data structures in a consistent state. -- JK -- http://mail.python.org/mailman/listinfo/python-list
