You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(21) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
(2) |
May
(3) |
Jun
(4) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2005 |
Jan
(1) |
Feb
(8) |
Mar
|
Apr
(2) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(9) |
Oct
(2) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Mikhail T. <ter...@em...> - 2004-04-27 20:22:49
|
Hi, Any plans for the 1.0 release? Regards, Mike |
From: Mike C. F. <mcf...@ro...> - 2004-04-07 16:11:41
|
Schoenborn, Oliver wrote: ... >When >the user changes something in the view, say data in a text control box, the >view commits the data to a leaf in the hierarchy of the document and >generates a message for '(doc, changed, fromView)' topic, in case 'someone' >is interested in the fact that document has been changed. Similarly, the >import reader generates a message for topic '(doc, changed, fromImport)' >when it imports some external data into some leaves of an existing document. > > Okay, so the approach I outlined should work with PyDispatcher. I'll put it on the (seemingly infinitely long) list of things to play with some day. Basically it would look something like this: def sendHier( signal=Any, sender=Anonymous, *arguments, **named ): if isinstance( signal, HierMessage ): responses = [] while signal: responses.extend(sendExact( signal, sender, *arguments, **named )) signal = signal[:-1] responses.extend( sendExact( Any, sender, *arguments, **named )) return responses else: return send( signal, sender, *arguments, **named ) I'd have to take some time to write up test cases and check that the last sendExact would do the proper thing, but I think that basically gives all the features you've described. Have fun, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Mike C. F. <mcf...@ro...> - 2004-02-18 00:45:22
|
We had an error report sitting in the queue for a few months there (with a patch, no less) and I never noticed it. I've fixed the error and set all of the trackers to copy this list when new items are added and/or items are changed. Should probably put out a 1.0 final release some day, btw. Have fun all, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Mike C. F. <mcf...@ro...> - 2003-12-31 09:09:00
|
Drew Perttula wrote: >Shouldn't that green-text warning on http://pydispatcher.sourceforge.net/ >say 2.3.2 and 2.3.3 (not 2.2.2 / 2.2.3)? I don't recall the 2.2 series >having a weakref problem. > > 2.2.2 and below did, in fact, have a weakref problem, (segfaults during destruction of weakrefs). 2.2.3 fixed that, thanks to Tim Peters. That fix should be in all 2.3 versions as far as I know. >While I'm at it, perhaps we can have a more informative message. I want >to explain the exact risk to people who were about to use a broken py >version, and also to avoid scaring users of pre-2.3, who I think are >not be affected at all (right?): > > Nope, they are affected. The weakref problem being referred to in that message was in 2.2.2. > It is strongly recommended that you use Python 2.3.3 or later > when using PyDispatcher. Python 2.3 versions before 2.3.3 may > seg fault upon program exit due to a problem with the cleanup > routines. Python-2.3.3/Modules/gc_weakref.txt describes the problem. > > There is a different weakref bug in 2.3, fixed in 2.3.3. I just checked in revised index.html with this text, if all agree I'll promote to the web-site when I get a chance (or Patrick can do it if he prefers): PyDispatcher represents one of the more involved usage patterns for Python weakref objects. We have discovered a few problems in weakref operation of which users of the package should be aware. Python 2.2.2 (and earlier) weak reference implementations have a subtle bug <https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=742911> in their weakref destructor code which can cause memory access errors (aka segfaults) on program shutdown. If you are using Python 2.2, it is *strongly recommended* that you use *Python 2.2.3* or later when using PyDispatcher. Note that this will not address the following issue. Python 2.3.2 (and earlier) has a different (even more subtle) bug <http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/gc_weakref.txt?rev=2.1&view=auto> in the weakref destructor code which, again, can cause segfaults. If you are using Python 2.3, it is *strongly recommended* that you use *Python 2.3.3* or later when using PyDispatcher. This bug-fix will not be ported back to the Python 2.2.x branch, so if you are using Python 2.2.3 you may encounter this situation. I'm not sure if the "strongly" is required for the 2.3 recommendation. 2.2.2- will almost certainly fail if you push into any sort of large-scale deployment, while the 2.3.2- is a rarer bug AFAICS. May way to include "rare" in the description of the 2.3 situation somewhere as well. Enjoy yourselves, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Drew P. <dr...@bi...> - 2003-12-31 04:24:32
|
Shouldn't that green-text warning on http://pydispatcher.sourceforge.net/ say 2.3.2 and 2.3.3 (not 2.2.2 / 2.2.3)? I don't recall the 2.2 series having a weakref problem. While I'm at it, perhaps we can have a more informative message. I want to explain the exact risk to people who were about to use a broken py version, and also to avoid scaring users of pre-2.3, who I think are not be affected at all (right?): It is strongly recommended that you use Python 2.3.3 or later when using PyDispatcher. Python 2.3 versions before 2.3.3 may seg fault upon program exit due to a problem with the cleanup routines. Python-2.3.3/Modules/gc_weakref.txt describes the problem. |
From: Drew P. <dr...@bi...> - 2003-12-03 14:42:04
|
> FYI, dispatcher is able to trigger the bug recently discussed on > py-dev. This means that in Python versions approx 2.3 to 2.3.3, you may > get core dumps upon exit, and possibly seg faults earlier, and possibly > memory corruption. > > The detailed description of the bug is here: > > http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/gc_weakref.txt?rev=2.1&view=auto > > The observed symptom for me was a core dump upon exit, where the traceback > involved some GC cleanup function and finished at some object attribute > accessor function. (Sorry, I don't have the trace handy.) > > I shall be testing the release23-maint cvs branch today. The upcoming > 2.3.3 release claims to fix the bug. ..and indeed, Python 2.3.3 (currently in CVS, to be released within a few weeks) does fix the bug. See the other replies to my original message for other possible workarounds, get py2.3.3, or be prepared for core dumps on exit (which take an annoying amount of time to write :). |
From: Mike C. F. <mcf...@ro...> - 2003-12-02 19:37:20
|
Thomas Heller wrote: >po...@or... (Patrick K. O'Brien) writes: > > >>Drew Perttula <dr...@bi...> writes: >> >> >>>I shall be testing the release23-maint cvs branch today. The >>>upcoming 2.3.3 release claims to fix the bug. >>> >>> >>Thanks, Drew. And if you've got a fix for dispatcher, or advice for >>dispatcher users, that would be great. >> >> > >I can only guess what you're talking about since I haven't seen the >message from Drew (was it not sent to the list? Or did I accidently >delete it in the piles of spam I receive?). > > It was sent. Tim's writeup was linked from Drew's email: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/gc_weakref.txt?rev=2.1&view=auto From what I've seen, dispatcher is one of the more advanced uses of weakrefs currently "in the wild", so we do seem to run into a lot of problems with them :) . >I was still using a hacked version of dispatcher from the cookbook, >and my workaround for the crashes (once I discovered the reason) was to >disable gc at the beginning of the weakref callback functions and enable >it at the end again. > > If I'm reading correctly you'd still have a chance of seg-faulting if the callback was called after one of its referenced objects "went insane" (in Tim's terminology). That is, you can wind up getting a call to the callback where the callback and a referenced object are part of a reference cycle and the reference object has already been finalised. In this case (if I'm reading correctly), the gc has already done the damage by the time your callback is called, so you can still wind up accessing the insane object. Still, if it works for you, that's good :) . Just don't be surprised if once in a while you see it blow up :( . Have fun, Mike |
From: Thomas H. <th...@py...> - 2003-12-02 18:54:16
|
po...@or... (Patrick K. O'Brien) writes: > Drew Perttula <dr...@bi...> writes: > >> I shall be testing the release23-maint cvs branch today. The >> upcoming 2.3.3 release claims to fix the bug. > > Thanks, Drew. And if you've got a fix for dispatcher, or advice for > dispatcher users, that would be great. I can only guess what you're talking about since I haven't seen the message from Drew (was it not sent to the list? Or did I accidently delete it in the piles of spam I receive?). I was still using a hacked version of dispatcher from the cookbook, and my workaround for the crashes (once I discovered the reason) was to disable gc at the beginning of the weakref callback functions and enable it at the end again. HTH, Thomas |
From: <po...@or...> - 2003-12-02 16:24:23
|
Drew Perttula <dr...@bi...> writes: > I shall be testing the release23-maint cvs branch today. The > upcoming 2.3.3 release claims to fix the bug. Thanks, Drew. And if you've got a fix for dispatcher, or advice for dispatcher users, that would be great. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: Drew P. <dr...@bi...> - 2003-12-02 10:00:31
|
FYI, dispatcher is able to trigger the bug recently discussed on py-dev. This means that in Python versions approx 2.3 to 2.3.3, you may get core dumps upon exit, and possibly seg faults earlier, and possibly memory corruption. The detailed description of the bug is here: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/gc_weakref.txt?rev=2.1&view=auto The observed symptom for me was a core dump upon exit, where the traceback involved some GC cleanup function and finished at some object attribute accessor function. (Sorry, I don't have the trace handy.) I shall be testing the release23-maint cvs branch today. The upcoming 2.3.3 release claims to fix the bug. -Drew |
From: Mike C. F. <mcf...@ro...> - 2003-08-13 11:07:56
|
Thomas Heller wrote: >"Mike C. Fletcher" <mcf...@ro...> writes: > > ... >>class Holder( object ): >> def __init__( self, method, client ): >> self.method= method # strong reference, kept alive >> self.client = saferef.safeRef( client, onDelete = self.cleanup ) >> >> ... >Mike, thanks for this suggestion. It didn't work exactly as shown above, >but it showed me the way to do it. I assume you meant > self.client = weakref.ref(client, self.cleanup) >instead of > self.client = saferef.safeRef( client, onDelete = self.cleanup ) >or did I miss something. > Probably that I'm using the latest version of pydispatcher (the package) from sourceforge. It splits out the various pieces of functionality into seperate reusable modules, so that there's a saferef module which does all the "safe reference to a method" stuff from the dispatcher module. That way if the client object is itself a method of an object it won't just disappear when the function that accessed it exits. There's also a robustapply module which does all the "figure out which arguments apply to this callable object and call it with that subset of the passed arguments" stuff. The dispatcher module itself also has a few new convenience functions: def getAllReceivers( sender = Any, signal = Any ): """Get list of all receivers from global tables def liveReceivers(receivers): """Filter sequence of receivers to get resolved, live receivers def sendExact( signal=Any, sender=Anonymous, *arguments, **named ): """Send signal only to those receivers registered for exact message def getReceivers( sender = Any, signal = Any ): """Get list of receivers from global tables >And sorry for the late reply. > No problem, I'm far too busy these days myself. Glass houses and stones and all :) . Have fun, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Thomas H. <th...@py...> - 2003-08-13 08:52:33
|
"Mike C. Fletcher" <mcf...@ro...> writes: > Thomas Heller wrote: > ... > >>I hope this forum is the correct one to ask questions about Patrick's >>dispatcher module ;-) >> > Yup, this is the place. Though I'm rather busy these days, so there > may be considerable delays in response from me particularly. > >>The problem occurs when the event handling become more complicated, and >>cannot simply be done by a simple (bound) method call in a widget >>instance. >> >>What I want to achive is something like this: >> >> def on_create(self, widget): >> name = widget.label >> import registry >> model = registry.get(name) >> def handler(model, widget=widget): >> data = model.get_some_data() >> widget.show_value(data) >> >> dispatcher.connect(signal=(name, "changed"), >> receiver=handler) >> >>In other words, the handler for the event must do an operation on the >>model for some data, and then call a method on the widget. (The >>'changed' event in the above code has the model as a parameter to make >>this possible). >> > If I understand correctly, what you want to do is to have the handler > function live a life of its own (not be collected) until the widget > goes out of scope, at which point you want to drop the handler > function. > > class Holder( object ): > def __init__( self, method, client ): > self.method= method # strong reference, kept alive > self.client = saferef.safeRef( client, onDelete = self.cleanup ) > def __call__( self, *args, **named ): > if self.client: > client = self.client() > if client is not None: > return self.method( *args, **named ) > def cleanup( self, oldWeakRef ): > self.client = None > dispatcher.disconnect( self ) > > I haven't tested that, but it should outline the basic approach. You > use weak=False when registering the Holder instance, and the holder > takes care of managing the lifetime of the method (keeps a strong ref > until the client widget goes away). Mike, thanks for this suggestion. It didn't work exactly as shown above, but it showed me the way to do it. I assume you meant self.client = weakref.ref(client, self.cleanup) instead of self.client = saferef.safeRef( client, onDelete = self.cleanup ) or did I miss something. And sorry for the late reply. Thomas |
From: Mike C. F. <mcf...@ro...> - 2003-07-31 23:46:27
|
Thomas Heller wrote: ... >I hope this forum is the correct one to ask questions about Patrick's >dispatcher module ;-) > Yup, this is the place. Though I'm rather busy these days, so there may be considerable delays in response from me particularly. >The problem occurs when the event handling become more complicated, and >cannot simply be done by a simple (bound) method call in a widget >instance. > >What I want to achive is something like this: > > def on_create(self, widget): > name = widget.label > import registry > model = registry.get(name) > > def handler(model, widget=widget): > data = model.get_some_data() > widget.show_value(data) > > dispatcher.connect(signal=(name, "changed"), > receiver=handler) > >In other words, the handler for the event must do an operation on the >model for some data, and then call a method on the widget. (The >'changed' event in the above code has the model as a parameter to make >this possible). > If I understand correctly, what you want to do is to have the handler function live a life of its own (not be collected) until the widget goes out of scope, at which point you want to drop the handler function. class Holder( object ): def __init__( self, method, client ): self.method= method # strong reference, kept alive self.client = saferef.safeRef( client, onDelete = self.cleanup ) def __call__( self, *args, **named ): if self.client: client = self.client() if client is not None: return self.method( *args, **named ) def cleanup( self, oldWeakRef ): self.client = None dispatcher.disconnect( self ) I haven't tested that, but it should outline the basic approach. You use weak=False when registering the Holder instance, and the holder takes care of managing the lifetime of the method (keeps a strong ref until the client widget goes away). >Any ideas, anyone? Is this a common problem? > >Thomas > > Don't know how common it is, I've seen similar patterns in a few cases, but I do a lot of meta-programming. HTH, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Thomas H. <th...@py...> - 2003-07-25 17:00:00
|
(This is a repost of a mail sent to the pycrust users list, Patrick told me about this dispatcher list. BTW: dispatcher is a great module, and I wish you well with the sf project. But expect further questions or usage reports from me, I have at least one.) I hope this forum is the correct one to ask questions about Patrick's dispatcher module ;-) I'm using an old and slightly patched version of the dispatcher module to 'connect' models to widgets in my program. The model instances in my program trigger certain events by calling dispatcher.send(signal=(self._name, "show"), visible=self._active) The frame creates zero, one or more widgets which should display the 'state' of the model, and the frame connects the widgets to the models: def on_create(self, widget): name = widget.label dispatcher.connect(signal=(name, "show"), receiver=widget.show)) The above code arranges that the widget is made visible when the model becomes active, and invisible when the model becomes inactive. The above code works very well, I don't need to disconnect the widgets from the model when they are destroyes, dispatcher does this automatically with it's weak references. The problem occurs when the event handling become more complicated, and cannot simply be done by a simple (bound) method call in a widget instance. What I want to achive is something like this: def on_create(self, widget): name = widget.label import registry model = registry.get(name) def handler(model, widget=widget): data = model.get_some_data() widget.show_value(data) dispatcher.connect(signal=(name, "changed"), receiver=handler) In other words, the handler for the event must do an operation on the model for some data, and then call a method on the widget. (The 'changed' event in the above code has the model as a parameter to make this possible). This code doesn't work, because when the the on_create method returns, the handler function is destroyed, and dispatcher drops the connection. One possibility would be to assign handler to widget as an attribute so that its lifetime is the same as the widget, but this is ugly. And it has a further consequence: because there is a reference cycle between the handler function and the widget, the widget is not destroyed any more (before the next gc.collect() run). Equally ugly would be to make the handler function a method of the widget class, because this would break the separation between the model and the widget. Any ideas, anyone? Is this a common problem? Thomas |
From: <po...@or...> - 2003-07-25 16:36:43
|
Thomas Heller <th...@py...> writes: > I hope this forum is the correct one to ask questions about Patrick's > dispatcher module ;-) Actually, I recently created a separate SourceForge project just for dispatcher. Mike Fletcher gets the credit for helping out quite a lot with enhancements, documentation, examples, etc. http://sourceforge.net/projects/pydispatcher/ We haven't made any announcements about the project yet, but we will soon. So you probably want to join that mailing list and ask your questions again over there: http://lists.sourceforge.net/lists/listinfo/pydispatcher-devel In the mean time, I'll try to look into the issues you raised, though I am quite swamped with work at the moment (on a project that is making heavy use of dispatcher, btw). -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: <po...@or...> - 2003-07-15 00:55:29
|
"Mike C. Fletcher" <mcf...@ro...> writes: > I think we are on track for a 1.0.0a1 release in the next few days. > I've just checked in the setup file changes to include the > documentation directory (even though there is currently very little > there). We still need lots more documentation and samples, but the > system should be usable, providing basically all the functionality of > the original script with a few enhancements. I really appreciate all your work on this. > I would expect we want to take the 1.0.0 release to final fairly > quickly, with a 2.0.0 development plan to be worked out > (e.g. providing a class-based implementation). Mostly I would like to > get the 1.0.0 release out and used as a common stand-alone package (as > opposed to everyone having their own version), so that we start > drawing in other developers (and more users, of course). Would like > to hear your thoughts on the matter. Will not release without your > (Patrick's) agreement, of course. Are there other major features you > want to see in a 1.0 timeframe? Sounds good to me. I'd like to get the basic version out there, then we can refine it. What we've got works for most cases, so let's just roll with it. After we get more people on board we can decide what we want for the next version. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: Mike C. F. <mcf...@ro...> - 2003-07-14 23:38:34
|
Patrick K. O'Brien wrote: ... >Sounds good to me. I'd like to get the basic version out there, then >we can refine it. What we've got works for most cases, so let's just >roll with it. After we get more people on board we can decide what we >want for the next version. > > I haven't got the pydoc docs uploaded, but there's a minimal homepage there, and the 1.0.0a1 sdist and bdist_wininst are available on the project page. We should do a release announcement once it's confirmed that I haven't messed anything up horribly in the packaging (should also produce rpms I suppose, but my RedHat install is hosed at the moment, so I'm not able to produce them). I'm somewhat busy this week, but should have a few hours on the weekend to work on dispatcher-related stuff. Enjoy, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Drew P. <dr...@bi...> - 2003-07-14 21:29:19
|
> drewp, on sending dispatcher events over XMLRPC: > > Worse, however, is that because you take id() of the sender before > > storing/lookup in the receiver mapping, I can't even use strings as > > senders because their ids are different in my client and server. So > > unless that changes, senders are unsupported in the xmlrpc tunnel (not > > the end of the world). > > Let's look at this again, now that we've got the code in SourceForge. Indeed. I think the straightforward fix is to stop using (or sometimes stop using) the id() optimization. There are other ways the XML-RPC design could go, though. I may not be able to do a lot of research on this problem too soon, unfortunately. I will point out, though, that the XMLRPC bridge worked like a champ for a live presentation I did in March. One process did the displaying of the presentation, and another process showed me a control panel I could use to drive the main presentation, the video clips, and the other special tricks. GSD made things -very- convenient. -Drew (I'm on the list now) |
From: <po...@or...> - 2003-07-14 21:22:39
|
Drew Perttula <dr...@bi...> writes: > > Okay. You probably could leave out that parameter as well, which > > would send the signal anonymously. The current version of the code > > implements Anonymous and Any as class instances. See the attached file. > > > > But anonymous sends seemed to have a sender of None, and None doesn't > work over xmlrpc. Neither would Anonymous or Any, I suppose. > > Worse, however, is that because you take id() of the sender before > storing/lookup in the receiver mapping, I can't even use strings as > senders because their ids are different in my client and server. So > unless that changes, senders are unsupported in the xmlrpc tunnel (not > the end of the world). Let's look at this again, now that we've got the code in SourceForge. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: <po...@or...> - 2003-07-14 20:08:52
|
Drew Perttula <dr...@bi...> writes: > I'm a huge fan of your dispatcher.py system; I recommend it all the time > on the #python channel. My current project has a client and server which > communicate via XMLRPC. I wanted the client to call a method deep in > the server process somewhere, and it was going to be silly to connect > all the relevant objects (from the xmlrpc server obj all the way to > the receiver obj, in a faraway module). So, within about half an hour, > I was able to make the following: > > ######## client.py ##################### > > import xmlrpclib > import dispatcher > > serv=xmlrpclib.Server('http://localhost:12345') > > # send all dispatcher signals over to the xmlrpc server > def signal_over_xmlrpc(sender="<none>",**kwds): > """send this signal to the xmlrpc server where it will get > re-raised there""" > print serv.generate_signal(kwds) > dispatcher.connect(signal_over_xmlrpc) > > ... > > dispatcher.send("hover",ang=75) > > > > ######## server.py ##################### > > > from twisted.internet import reactor > from twisted.web import xmlrpc, server > import dispatcher > > class Show(xmlrpc.XMLRPC): > def __init__(self): > ..arrange for all methods to be accessible via xmlrpc.. > > def generate_signal(self,kwds): > dispatcher.send(**kwds) > return "sent signal "+str(kwds['signal']) > > reactor.listenTCP(12345,server.Site(Show())) > reactor.run() > > ##################################### > > Hopefully I pasted all the essentials. The big catch is that all > signals, senders, and other dispatcher.send() arguments have to be XMLRPC > marshalable. NoneType is not marshalable, which is why I have the little > sender="<none>" workaround. > > I'm in a hurry to get my project working for this weekend, but someday > I may be able to refine the XMLRPC tunnel system and maybe even pack it > in a module of its own. > > My own dispatcher.py is slightly patched to log the receivers (using > the new logging module). I also noticed you pitched the module on > some Zope3 page, which I'm all for. Do you imagine hosting the module > as a distutils package someplace? I could contribute docs, examples, > and related stuff such as the XMLRPC tunnel. > > I think I'd prefer if the authoritative site wasn't the ASPN Cookbook, > as I'd like to send users of my projects to a site that says "get this, > run setup.py install" instead of a "here's something hackers like, > and you can paste it into your own file to run it" site. Of course, > stdlib acceptance would solve my problem even better. :) > > Thanks for the great work! You're welcome. Just wanted to let you know that I finally got around to setting up a SourceForge project for dispatcher. Mike Fletcher has done a ton of work to get the files in shape, write unit tests, docs, etc. We'd love to have your help as well. Just let us know how you would like to be involved. The project is here: http://sourceforge.net/projects/pydispatcher/ Be sure to sign up for the developer mailing list as well: http://lists.sourceforge.net/lists/listinfo/pydispatcher-devel -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: Mike C. F. <mcf...@ro...> - 2003-07-06 21:32:56
|
I think we are on track for a 1.0.0a1 release in the next few days. I've just checked in the setup file changes to include the documentation directory (even though there is currently very little there). We still need lots more documentation and samples, but the system should be usable, providing basically all the functionality of the original script with a few enhancements. I would expect we want to take the 1.0.0 release to final fairly quickly, with a 2.0.0 development plan to be worked out (e.g. providing a class-based implementation). Mostly I would like to get the 1.0.0 release out and used as a common stand-alone package (as opposed to everyone having their own version), so that we start drawing in other developers (and more users, of course). Would like to hear your thoughts on the matter. Will not release without your (Patrick's) agreement, of course. Are there other major features you want to see in a 1.0 timeframe? By the way, also checked in expanded documentation strings for the dispatcher module a little earlier. Could you (Patrick) also disable the "members only" posting for the CVS repository, I really don't want an e-mail for every single check-in, so I'm not really interested in signing up for the cvs list. Enjoy, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Patrick K. O'B. <po...@or...> - 2003-07-02 00:51:03
|
On Tuesday 01 July 2003 06:42 pm, Mike C. Fletcher wrote: > Dear OSI board, > > As you are no doubt aware, the Python Software Foundation License is an > aglomeration of various licensing restrictions from various sources, > rather than a coherent attempt to outline a particularly desirable set > of rights and/or responsibilities. The wording of the license is > specific to the Python language, and has very little relevance to new > software development. <snipped> Based on your arguments, and as a sign of support, let's change the license for dispatcher to the one you prefer. I'll leave it to your judgement. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: Eric S. R. <es...@th...> - 2003-07-01 23:59:26
|
Mike C. Fletcher <mcf...@ro...>: > Given that there are other licenses which embody the general terms of > the Python license, I'm wondering if it would be reasonable to add notes > to the Python Software Foundation License page on > http://www.opensource.org/licenses/PythonSoftFoundation.php to the > effect that the license is not particularly intended for reuse in other > projects, possibly pointing the user to the BSD license, or even the > Python CNRI license (as a subset of the PSF license). > > For example: > The Python Software Foundation License represents the historical > interplay of interests in the Python language implementation. It is not > a license designed for reuse for other open source projects. If you are > considering a license for use with a new open source project, you may > want to consider the BSD <link> or MIT <link> licenses. I have directed our webmaster to do this. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> |
From: Mike C. F. <mcf...@ro...> - 2003-07-01 23:42:22
|
Dear OSI board, As you are no doubt aware, the Python Software Foundation License is an aglomeration of various licensing restrictions from various sources, rather than a coherent attempt to outline a particularly desirable set of rights and/or responsibilities. The wording of the license is specific to the Python language, and has very little relevance to new software development. However, Python developers, seeing "Python License" are beginning to use the license as though it were a desirable license for new Open Source development simply because it is associated with Python (despite the 4 or 5 different licensors, and all the other rather ugly attributes of the Python Software Foundation License). Certainly SourceForge must take some of the responsibility for this given that they include the PSF license in the list of available Open Source licenses during project registration, but I'm wondering if the OSI could work to avoid this effect as well. Given that there are other licenses which embody the general terms of the Python license, I'm wondering if it would be reasonable to add notes to the Python Software Foundation License page on http://www.opensource.org/licenses/PythonSoftFoundation.php to the effect that the license is not particularly intended for reuse in other projects, possibly pointing the user to the BSD license, or even the Python CNRI license (as a subset of the PSF license). For example: The Python Software Foundation License represents the historical interplay of interests in the Python language implementation. It is not a license designed for reuse for other open source projects. If you are considering a license for use with a new open source project, you may want to consider the BSD <link> or MIT <link> licenses. With thanks for all your work, Mike Fletcher _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Patrick K. O'B. <po...@or...> - 2003-07-01 22:48:55
|
On Tuesday 01 July 2003 05:31 pm, Mike C. Fletcher wrote: > Patrick K. O'Brien wrote: > >I prefer reST for documentation, or wiki pages. I've got a wiki site that > > we can use, if we want. > > I'd like to include documentation in the distribution. Never used reST, > I tend to write directly in basic HTML w/ class properties and use CSS > to present it. That works fine for me, and produces good-looking > documentation, but I'm certainly open to someone else writing the docs > in reST ;) , as a last resort, I'll learn reST, but I'm not really > thrilled with the format. Wiki is cool for enhancing a basic > documentation set, but I'm thinking here of "basic usage" and reference > docs, the kind of things you really want to have available whereever the > package gets installed. In that case, please do use whatever you prefer. > If I'm working on the site, I'd rather use the SF server, I've got batch > files that allow me to automatically update the website directly via scp > (once SF gets itself fixed). Probably easier than giving me an account > on orbtech. Okay. No argument from me. I was just throwing out options. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |