[tg-trunk] Re: python 2.5 on windows
On 2/3/07, Mark Ramm [EMAIL PROTECTED] wrote: If you could throw create a ticket for a 2.5 version, you can attach the eggs there, and Lee or one of the other folks can work out where to host these on the site. done it is here : http://trac.turbogears.org/ticket/1280 Cheers, Florent. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Please help me decide if need to use database for my app...
On Feb 1, 2:59 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm doing a stock app that displays lots of graphs/data and lets user customize some of it online. ** When a user wants to save their work, I can either create a file (with a bunch of numbers) or stuff those numbers in the database. I'm not sure what the benefits of either are. The file way seems easier and more *portable* so what will a database do for me? ** The session data should be held in RAM/python objects rather than hitting the database or file system for speed right? This advice isn't focused on you only, it's general advice I give to anyone who asks questions like this, and i'm not trying to be condescending, I have learned these the hard way, you can too if you won't and I won't look down on you :) The first rule of web apps is, don't optimise anything you don't have to. Only pain and pointlessly sleepless nights comes from that. So unless you're looking at dealing with a seriously scary number of hits, use the stuff you're given by Turbogears wherever possible, it's already debugged, it works in threads and it fails in a known, and usually graceful fashion. This means turning on the session object and using that, and it means putting your data in a database. Only once you've done that, and figured out a load testing scenario, and *then* decided that it's too slow, should you start thinking about the benefits of developing your own processes for handling things you're given for free. At which point you can come back and ask, or ask me directly, and I will supply you with a dizzying array of ways to make your apps faster :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Generating SWFs with TurboGears
Here's an updated one, with sunshine_TV and HTML text added. http://samfeltus.com/sonomasunshine.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: problem using py2exe with turbogears (and eggs) to build an exe :(
Hello, I see no one has come up with a fix to the "pkg_resources.DistributionNotFound: TurboGears" problem. I was hoping to come back from holiday and it would magically be fixed :( I've come up with a hack solution that makes the "tg-admin makexe" work for me. I still can't make py2exe work however. The basic problem seems to be the "easy_install.pth" that gets put into the dist/Lib/site-packages. On my system, the file contained the file names for the eggs in non-case sensitive form. i.e the file names were all lower case. This meant that TurboGears wasn't being registered and picked up by setuptool's "pkg_resources.py" The following hack process works for me currently, but its far from ideal. What is interesting is that the easy_install.pth (with all lowercase filenames) works in the standard system installed python, but not in the packaged tg2exe version. Maybe now I can py2exe the working tg2exe distro... The hack fix: * tg-admin makexe * Open the "dist\Lib\site-packages" * Delete the modules tg-admin has created for the turbogears project. There is no point having these around as well as the egg version. cherrypy, dispatch, elementtree, formencode, kid, paste, protocols, py2exe, setuptools, simplejson, turbogears, turbojson * Copy in my eggs (in zip format downloaded from tg site): Cheetah-1.0-py2.4-win32.egg CherryPy-2.2.1-py2.4.egg DOMinclude-1.0-py2.4.egg LightBox-2.0-py2.4.egg Paste-0.9.7-py2.4.egg PasteDeploy-0.9.6-py2.4.egg PyProtocols-1.0a0dev_r2082-py2.4-win32.egg ruledispatch-0.5a0.dev_r2115-py2.4-win32.egg SQLObject-0.7.1dev_r1860-py2.4.egg TurboGears-1.0.1-py2.4.egg TurboJson-1.0-py2.4.egg TurboKid-0.9.8-py2.4.egg cElementTree-1.0.5_20051216-py2.4-win32.egg configobj-4.3.2-py2.4.egg elementtree-1.2.6-py2.4.egg kid-0.9.3-py2.4.egg simplejson-1.3-py2.4.egg setuptools-0.6c5-py2.4.egg FormEncode-0.6-py2.4.egg PasteScript-1.1-py2.4.egg TurboCheetah-0.9.5-py2.4.egg * Create the easy_install.pth making sure the case is correct in the filenames: import sys; sys.__plen = len(sys.path) ./Cheetah-1.0-py2.4-win32.egg ./CherryPy-2.2.1-py2.4.egg ./DOMinclude-1.0-py2.4.egg ./LightBox-2.0-py2.4.egg ./Paste-0.9.7-py2.4.egg ./PasteDeploy-0.9.6-py2.4.egg ./PyProtocols-1.0a0dev_r2082-py2.4-win32.egg ./ruledispatch-0.5a0.dev_r2115-py2.4-win32.egg ./SQLObject-0.7.1dev_r1860-py2.4.egg ./TurboGears-1.0.1-py2.4.egg ./TurboJson-1.0-py2.4.egg ./TurboKid-0.9.8-py2.4.egg ./cElementTree-1.0.5_20051216-py2.4-win32.egg ./configobj-4.3.2-py2.4.egg ./elementtree-1.2.6-py2.4.egg ./kid-0.9.3-py2.4.egg ./simplejson-1.3-py2.4.egg ./setuptools-0.6c5-py2.4.egg ./FormEncode-0.6-py2.4.egg ./PasteScript-1.1-py2.4.egg ./TurboCheetah-0.9.5-py2.4.egg import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new) * Copy the "prod.cfg" into the dist dir. * from the dist dir try running the script: [EMAIL PROTECTED] [dist] ./python.exe start-tgpy2exe.pyc Traceback (most recent call last): File ".\start-tgpy2exe.py", line 26, in ? File "z:\aam\tgpy2exe\dist\lib\site-packages\TurboGears-1.0.1-py2.4.egg\turbogears\startup.py", li ne 300, in start_server File "z:\aam\tgpy2exe\dist\lib\site-packages\CherryPy-2.2.1-py2.4.egg\cherrypy\_cpserver.py", line 72, in start File "z:\aam\tgpy2exe\dist\lib\site-packages\CherryPy-2.2.1-py2.4.egg\cherrypy\_cpengine.py", line 104, in start File "z:\aam\tgpy2exe\dist\lib\site-packages\CherryPy-2.2.1-py2.4.egg\cherrypy\_cpserver.py", line 76, in _start File "z:\aam\tgpy2exe\dist\lib\site-packages\CherryPy-2.2.1-py2.4.egg\cherrypy\_cpengine.py", line 76, in setup File "z:\aam\tgpy2exe\dist\lib\site-packages\CherryPy-2.2.1-py2.4.egg\cherrypy\filters\__init__.py ", line 66, in init File "z:\aam\tgpy2exe\dist\lib\site-packages\CherryPy-2.2.1-py2.4.egg\cherrypy\lib\cptools.py", li ne 226, in attributes File "z:\aam\tgpy2exe\dist\lib\site-packages\CherryPy-2.2.1-py2.4.egg\cherrypy\lib\cptools.py", li ne 215, in modules File "z:\aam\tgpy2exe\dist\lib\site-packages\CherryPy-2.2.1-py2.4.egg\cherrypy\filters\xmlrpcfilte r.py", line 84, in ? ImportError: No module named xmlrpclib [EMAIL PROTECTED] [dist] * Copy the missing xmlrpclib.pyc into dist/Lib * Retry, hop to localhost:8080, ta-da... * Done All the best, Oisin Oisin Mulvihill wrote: I'm currently tracking it down. It looks like pkg_resources isn't finding turbogears when its looking for packages in the dist/Lib/site-packages directory. Turbogears is there. If you do import turbogears you see its imported it its just the call to require inside turbogears startup that isn't finding itself. Copying the egg file in doesn't solve the problem at the moment. More prints are still needed. I don't think I'll get this sorted before I go on holiday tomorrow, maybe next week sometime :( All the best, Oisin Diego wrote: I wonder if you were able to resolve the problem. I'm getting the same error after using
[TurboGears] Re: Install problem on Mac OS X
Which package is it trying to compile when you receive this message? On Feb 2, 4:41 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I was trying to install Turbogears on my iBook G4 (Mac OS X 1.4.8) by running sudo python tgsetup.py. But the install failed with gcc: cannot specify -o with -c or -S and multiple compilations. Can anyone please help me to solve this problem? I have python 2.4.4 installed on my iBook. Thanks in advance. Young-Jin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Install problem on Mac OS X
It looks like Cheetah-2.0rc7. Below is the entire error message I got. Downloading http://cheeseshop.python.org/packages/source/C/Cheetah/ Cheetah-2.0rc7.tar.gz#md5=8a3749a203719e0de6b0af0e841f5371 Processing Cheetah-2.0rc7.tar.gz Running Cheetah-2.0rc7/setup.py -q bdist_egg --dist-dir /tmp/ easy_install-syntcx/Cheetah-2.0rc7/egg-dist-tmp-66dPdA warning: no files found matching '*.cfg' warning: no files found matching 'examples' warning: no files found matching 'docs' warning: no files found matching 'bin' warning: no files found matching '*' under directory 'docs' warning: no files found matching '*' under directory 'examples' warning: no previously-included files matching '*.pyc' found under directory 'src' warning: no previously-included files matching '*~' found under directory 'src' warning: no previously-included files matching '*.aux' found under directory 'src' warning: no previously-included files matching '*~' found under directory 'docs' warning: no previously-included files matching '*.aux' found under directory 'docs' gcc: cannot specify -o with -c or -S and multiple compilations error: Setup script exited with error: command 'gcc' failed with exit status 1 Thanks. On Feb 3, 11:50 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Which package is it trying to compile when you receive this message? On Feb 2, 4:41 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I was trying to install Turbogears on my iBook G4 (Mac OS X 1.4.8) by running sudo python tgsetup.py. But the install failed with gcc: cannot specify -o with -c or -S and multiple compilations. Can anyone please help me to solve this problem? I have python 2.4.4 installed on my iBook. Thanks in advance. Young-Jin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] More Mac Installe problems!
The latest TuboGears package (1.0.1) fails to work on mac. I went so far to reinstalled python 2.4.2 from scratch and got the same failure when trying to access an app just created with quickstart: Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy/ _cpwsgiserver.py, line 198, in run request.parse_request() File /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy/_cpwsgi.py, line 139, in parse_request _cpwsgiserver.HTTPRequest.parse_request(self) File /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy/ _cpwsgiserver.py, line 61, in parse_request method,path,version = request_line.strip().split( , 2) ValueError: need more than 1 value to unpack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Any one use SA please help me.
Em Sex, 2007-01-26 às 10:19 +, Olli Wang escreveu: BTW, my platform is windows XP. SA is 0.3.3. TG is 1.0.1. I tried this on my desktop and notebook, and both of them have the same problem. Didn't you happen to this problem? I believe this is causd by the following bug: http://trac.turbogears.org/ticket/1267 As you say, session.flush() should be done automatically by the TG code, but it is not because TG thinks the SO is being used when it calls run_with_transaction. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Turbogears Ubuntu dependencies (please read if ur in this platform)
Em Sex, 2007-02-02 às 18:30 +, SamFeltus escreveu: I wish TurboGears would just show up on Ubuntu Package Manager... Would that be hard to do? Would that start issues of supporting multiple install methods? TurboGears is packaged for Debian, so if you are running Etch or Sid you will find the python-turbogears package on your Package Manager of choice. I see that the Debian package is being updated in Ubuntu feisty, from time to time: http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=namesversion=allexact=1keywords=python-turbogears You can also add: deb http://ftp.debian.org/debian sid main To your list of repositories (editabled through Synaptic), but that may make your package manager's life a bit more complicated, so perhaps you would like to pester the Ubuntu universe maintainer for python-turbogears to update it from Debian. I don't understand how Synaptic Package Manager or tgsetup.py works, and like not knowing... :) We're working to keep you from having to =). See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Identity tutorial problem. SA?
On Fri, 2007-02-02 at 21:50 -0500, Karl Guertin wrote: On 2/2/07, iain duncan [EMAIL PROTECTED] wrote: It says that one needs to use the shell if using SA, which I would take to mean that the shell examples would work. but g.addUser(u) gets an error message that the group has no method addUser() and I see in the identity code in my model, that there are no methods defined at all on group. Is this tutorial SO only? http://groups.google.com/group/turbogears/browse_thread/thread/4005bb55625f5378/1cad0c6096808d7f Ha ha, man I can't even remember what I've tried anymore. Well, as the misleading wording is still there, what do you suggest gets done about it? I still believe it would be better to clearly state that the tutorial does not cover SA. Which also made me wonder, why not add an addUser() method to the SA API and make them more consistent? ( Wrapping the g.users.appennd(u) ) Are there good reasons to not do so that I'm not thinking of? [1] http://www.splee.co.uk/2006/10/28/simpleblog-part-3-many-to-many-relationships/ yeah I used that, Lees tutorials are really good. Doesn't cover the particular use case I'm trying to get working though. I'll keep hunting through the SA docs. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Please help me decide if need to use database for my app...
iain duncan [EMAIL PROTECTED] writes: This is very good advice. ( Though I'm curious about that dizzying array ... ) A lot of people worry at length about template rendering speeds and database caching and then their users go and put two or three huge pictures on the page, and your speed issues are totally moot. ; ) Indeed... Network latency seems to play a major role than rendering time. Add to that huge pictures and then all your concerns vanishes. :-) -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] MySQL going to sleep vs Postgresql
Can anyone tell me whether the mysql going to sleep issue also happens with postgresql? Or if there are any similar issues for pg? I need to deploy a new site on a very tight schedule in the next two weeks and the client has a trade show, so it would be A Very Bad Thing to have problems keeping the site up. If I cut out some variables by using postgresql, I could do the switch, but right now I know mysql a lot better. I got the cronjob hitting a page technique working with mysql on another site, but it rubs me the wrong way. Is it really reliable? Thoughts on this issue? Thanks iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: MySQL going to sleep vs Postgresql
On 2/3/07, iain duncan [EMAIL PROTECTED] wrote: Can anyone tell me whether the mysql going to sleep issue also happens with postgresql? Or if there are any similar issues for pg? I need to deploy a new site on a very tight schedule in the next two weeks and the client has a trade show, so it would be A Very Bad Thing to have problems keeping the site up. If I cut out some variables by using postgresql, I could do the switch, but right now I know mysql a lot better. I got the cronjob hitting a page technique working with mysql on another site, but it rubs me the wrong way. Is it really reliable? Thoughts on this issue? I've never seen any issue like that with PostgreSQL and SQLAlchemy and TG or Pylons. I've also never used SQLObject and/or MySQL in production with TG though, so I can't really directly compare them. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: MySQL going to sleep vs Postgresql
Bob Ippolito [EMAIL PROTECTED] writes: I've never seen any issue like that with PostgreSQL and SQLAlchemy and TG or Pylons. I've also never used SQLObject and/or MySQL in production with TG though, so I can't really directly compare them. I have used SO in production. And I also never saw a problem with PostgreSQL (but I confess I don't like MySQL at all...). -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Complete docs... API... ever???
I understand the frustration. Fundamentally we need more help. Documentation is a big project, and a lot of people have worked very hard to get us where we are. There's still some way to go, I don't think we're miles away from good enough. The largest missing pieces are the API docs, a good overview, and some additional widget documentaiton, so the end is really in sight. We ran into snags with API documentation generation in the last sprint, and as far as I know there hasn't been any movement on that since. If somebody has time to work out the kinks we've experienced with epydoc that would be great. If somebody is willing to try to get pudge, or another doc generation tool working that would also be great. But I'm hoping that somebody will volunteer to help out with it again at our next docsprint and we can actually move this piece across the finish line, and get API docs linked up to docs.turbogears.org. What I'd really love is for a couple of people to work with different API generation tools, so if we run into snags with one tool or another we still have a good chance of actually getting something completed. --Mark Ramm On 2/3/07, Steve Bergman [EMAIL PROTECTED] wrote: I've been following TG for about 16 months. I've noted an ongoing background lament about how we should have more complete docs. And while things may have gotten better, the documentation is still a disgrace compared to other frameworks like Rails. (And Rails is sometimes criticized for insufficient docs.) Documentation sprints have come and gone, complete with reports from the battlefront about how amazingly well things were going and how much progress was being made. But after the sprints... nothing. The last sprint was no exception. I'm looking at docs.turbogears.org/1.0 for docs. Am I simply mistaken? Should I be looking somewhere else for official docs? Still no proper widget documentation. Still no proper API reference. And yet I distinctly remember a report from the last sprint that great progress was being made in that area. I've heard it said that the book documents TurboGears 1.0. It does not. It is not a reference. And compared to more in depth books like Agile Programming With Rails, is really just an overview. Frankly, TG needs decent 1.0 reference documentation a *lot* more than it needs a 2.0. 1.0 was not supposed to be allowed out without complete docs... or so I remember hearing many times. And if it takes closing all TG branches on Trac to all tickets that are not documentation bug fixes than so be it. I apologize for the negative tone. And I really *do* appreciate all the hard work that has gone into writing the actual TG code. And I apologize if I have just screwed up and am not looking in the right place. (But please don't point me to yet another collection of little user-provided use case snippets on some wiki.) After 17 months, it is not at all unreasonable for users to expect real docs, and (silently) to move on to something else if they don't exist. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: MySQL going to sleep vs Postgresql
On Sat, 2007-02-03 at 13:33 -0800, iain duncan wrote: Can anyone tell me whether the mysql going to sleep issue also happens with postgresql? Or if there are any similar issues for pg? to be fair, i dont know what 'the sleep' issue is, but ive mainly used postgres over years for a variety of projects (all non TG :-( ) - never had any issues of it becoming non-responsive in anyway(or of any other sort of issue either really) glenn I need to deploy a new site on a very tight schedule in the next two weeks and the client has a trade show, so it would be A Very Bad Thing to have problems keeping the site up. If I cut out some variables by using postgresql, I could do the switch, but right now I know mysql a lot better. I got the cronjob hitting a page technique working with mysql on another site, but it rubs me the wrong way. Is it really reliable? Thoughts on this issue? Thanks iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Complete docs... API... ever???
I will definitely not judge TG's state of documentation because CherryPy's one is still rough around the edge and not so much user friendly. However I come down to the conclusion that the problem, beyond having more people, is that you can't write proper documentation as long as the project spends so much in changing the product itself. I think the CP's documentation will get better and better as we go because CP is now stable enough that it will unlikely chang fundamentally for quite some time. From an external POV (really since I actually don't use TG), TurboGears seems should stop developing new features, pause and trim down a lot what his a requirement and what is not. The huge volume of messages on this list is not only due to the framework popularity but because people look for information they can't find elsewhere. This is not a good sign. Personally it's like TG tries to do everything at once and therefore finishes nothing at all. It's harsh and probably wrong but that's a feeling I can't help having. For instance when widgets started I thought this is too huge when the core of the framework is not stable yet. Widgets should have waited. In fact I'd dare say that they should be dropped from TG2 core features list until TG2 is actually stable and usable. I fear for TG more and more. People are willing but will also loose appetite if there is no visibility. Sorry for sounding negative. I hope TG will recover and be shiny as it once was when Kevin introduced it but currently it looks well... a mess to me (again this is from a completely external POV). One more note, recently we were discussing over at #cherrypy and I stated that if I needed a web framework today I'd certainly opt for Pylons over TG. People who know my relative passion for WSGI (wink /) but I can't help it. When I look at Pylons it seems stable, clear and fairly well documented. It gives me the core features I need and let me do the fancy stuff as I would require. I don't think this is a problem of technology used underneath but simply because the guys behind Pylons have not tried to make it bigger than the project could cope with. TG has missed that opportunity with TG1 I think and should rectify that with TG2. Of course I understand a lot has been done on TG and some people around here seem to have done a fantastic job but maybe the team should step back and understand what should be their focus. And if they already do they might want to be a little more public about it :) - Sylvain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Complete docs... API... ever???
On 2/3/07, Steve Bergman [EMAIL PROTECTED] wrote: Documentation sprints have come and gone, complete with reports from the battlefront about how amazingly well things were going and how much progress was being made. One documentation sprint has come and gone, progress is being made. We picked up several of editors who have been making great contributions. I'm looking at docs.turbogears.org/1.0 for docs. Am I simply mistaken? Should I be looking somewhere else for official docs? That's the place, there are no other official docs, though there are a number of pages in RoughDocs that need to be pushed into the index. http://docs.turbogears.org/1.0/RoughDocs I've heard it said that the book documents TurboGears 1.0. It does not. It is not a reference. And compared to more in depth books like Agile Programming With Rails, is really just an overview. Frankly, TG needs decent 1.0 reference documentation a *lot* more than it needs a 2.0. Unfortunately, it's much easier to get people to contribute code than it is to get anybody to contribute docs of any sort. All of my personal coding time since October has been spent writing these docs. I've been busy with work this past month and busy with the holidays in December. I have free time coming up when I'll work on the docs in the next few weeks. The nice thing about having more editors is that sizeable docs are being written by someone besides me, so progress has been steadier. 1.0 was not supposed to be allowed out without complete docs... or so I remember hearing many times. I remember this as well. My intention in October was to get the docs in order for 1.0. Unfortunately, I ran out of time. I think Kevin wanted to push 1.0 out so he could leave the project at a milestone and turn things over to Alberto. After 17 months, it is not at all unreasonable for users to expect real docs, and (silently) to move on to something else if they don't exist. Contributions are always welcome. It's a cliche response, but we're 2 for 3 in converting rants to doc editors (myself and Christopher Ardnt). People looking to help out don't even have to write anything. If you just go through the Trac documents in RoughDocs and confirm that they work (logged in comment or mail to turbogears-docs), that'd be an excellent contribution. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Identity tutorial problem. SA?
On 2/3/07, iain duncan [EMAIL PROTECTED] wrote: Which also made me wonder, why not add an addUser() method to the SA API and make them more consistent? ( Wrapping the g.users.appennd(u) ) Are there good reasons to not do so that I'm not thinking of? The group.addUser() API is SO's way of adding an item to a many-to-many relation. group.users.append() is SA's way. The goal for TG 2.0 is to reduce the surface area of TG, so adding wrappers doesn't really make sense (and I don't want to create more docs work explaining why identity is a special case exception when you're using SA). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Ticket #1281: identity throws exceptions for encrypted passwords with unicode characters
Hi, I'm starting this thread to get some opinions about the best strategy to fix ticket #1281 [1], especially regarding the propose test cases to uncover the problem. The hardest problem to me is how to change the encryption setting during the unittest. In my patch [2] I'm just emptying a private list but this ugly and has some unwanted side effects on the test cases... Maybe a new API call in visit/api is needed, disable_visit_plugin( plugin )? fs [1] http://trac.turbogears.org/ticket/1281 [2] http://trac.turbogears.org/attachment/ticket/1281/unicode_with_encrypted_passwords.patch --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: MySQL going to sleep vs Postgresql
On Sun, 2007-04-02 at 09:28 +1100, Glenn Davy wrote: On Sat, 2007-02-03 at 13:33 -0800, iain duncan wrote: Can anyone tell me whether the mysql going to sleep issue also happens with postgresql? Or if there are any similar issues for pg? to be fair, i dont know what 'the sleep' issue is, but ive mainly used postgres over years for a variety of projects (all non TG :-( ) - never had any issues of it becoming non-responsive in anyway(or of any other sort of issue either really) The sleep issue is that when tg runs with cherrypy, it's in a long-running process that keeps a mysql connection alive. But if mysql doesn't receive a hit on that connection in a long time, it goes to sleep and then the first hit fails. Which is Really Annoying. So the workaround is to have something make a hit every hour. Which is Really Ugly. ; ) Apparently this was brought to the attention of the mysql folks but I don't know the status on that these days ... Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Complete docs... API... ever???
After 17 months, it is not at all unreasonable for users to expect real docs, and (silently) to move on to something else if they don't exist. Yeah, I, unfortunately, agree. I suspect that is silently happening a good deal. Which is not to say that I don't appreciate all the doc efforts, I sure do! But from an open source project management perspective, I do think stability of docs to api is under prioritized right now in TG in a big way. My two cents. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Complete docs... API... ever???
Unfortunately, it's much easier to get people to contribute code than it is to get anybody to contribute docs of any sort. All of my personal coding time since October has been spent writing these docs. I've been busy with work this past month and busy with the holidays in December. Yes, this is always true. But, there could be a policy in place saying that if you don't provide at least a starting point for docs, your contribution doesn't go in to the release. Then after that others will at least clean them up, which is a *lot* easier for someone like myself to do than to start writing new docs. I can edit someone elses docs while learning a platform, but I am not going to write any new ones if I feel my understanding is incomplete. A policy like the above is used in Csound, and works very well. You don't write a manual entry and programmer docs: your new opcode or extension doesn't go in the canonical branch. IMHO a firm policy is the only thing that prevents undocumented feature creep. Contributions are always welcome. It's a cliche response, but we're 2 for 3 in converting rants to doc editors (myself and Christopher Ardnt). Well, rants come from new users who are stumbling. They won't write docs until they are sure they won't mislead others. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: MySQL going to sleep vs Postgresql
The sleep issue is that when tg runs with cherrypy, it's in a long-running process that keeps a mysql connection alive. But if mysql doesn't receive a hit on that connection in a long time, it goes to sleep and then the first hit fails. Which is Really Annoying. So the workaround is to have something make a hit every hour. Which is Really Ugly. ; ) yes - that is very ugly - I gave up on mysql with TG, at least for SO due to unicode issues - (no great loss as postgres is by far my 'sentimental' favourite) but 80% of my paid work atm is ruby on rails + mysql, so while ive experienced no issues I thought id better check - apparently mongrel has a timeout value, which if lower than that of the mysql connection will 'revive' the connection before it 'goes stale' - perhaps cherrypy can be extended to have something similar to this added, given lack of response from mysql people? anyhow good luck - and thanks for the explanation glenn Apparently this was brought to the attention of the mysql folks but I don't know the status on that these days ... Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: attn CherryPY gurus Re: MySQL going to sleep vs Postgresql,
On Sun, 2007-04-02 at 12:21 +1100, Glenn Davy wrote: The sleep issue is that when tg runs with cherrypy, it's in a long-running process that keeps a mysql connection alive. But if mysql doesn't receive a hit on that connection in a long time, it goes to sleep and then the first hit fails. Which is Really Annoying. So the workaround is to have something make a hit every hour. Which is Really Ugly. ; ) yes - that is very ugly - I gave up on mysql with TG, at least for SO due to unicode issues - (no great loss as postgres is by far my 'sentimental' favourite) but 80% of my paid work atm is ruby on rails + mysql, so while ive experienced no issues I thought id better check - apparently mongrel has a timeout value, which if lower than that of the mysql connection will 'revive' the connection before it 'goes stale' - perhaps cherrypy can be extended to have something similar to this added, given lack of response from mysql people? Maybe it does and I don't know about it? CherryPy gurus? I have every intention of learning Postgresql, but I also have a bad habit of trying to pick up too many new things at once and digging myself into a whole of stress and caffeine ... Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: attn CherryPY gurus Re: MySQL going to sleep vs Postgresql,
I have every intention of learning Postgresql, but I also have a bad habit of trying to pick up too many new things at once and digging myself into a whole of stress and caffeine ... lol - i think thats an industry pre-requisite I remember hearing Jacob Kaplin-moss (?) of Django fame say you couldn't pay him not to work on postgres - tend to feels some way (though in truth, im a DB slut, have been known to work on any platform for $$) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
