Re: [Repoze-dev] Chameleon 1.1 and z3c.pt problems
On 9 April 2010 21:30, Hanno Schlichting wrote: > Sure. I think the approach we took was good. It gave as a hugely > successful, stable and performant engine. I just have the feeling that > the current model has become somewhat convoluted and hinders us to do > any more optimizations. I certainly don't want to go anywhere near > what Spitfire did with its four different optimization stages. There > are things which are better left to JIT compilers like Unladen > Swallow. True. > RepeatNode > \-- AssignNode > \-- ConditionNode > \ ContentNode That's what I tried to do, but failed because of poor approach. I think it's possible to redo this in a sane way, e.g. establish an AST not for Python code, but for template primitives such as the ones you suggest. I think part of the problem was scope creep; suddenly we had i18n in there along with metal and various other concepts. > or something similar "high-level". For the repeat variable case, I'd > then want to take each RepeatNode and traverse it's inner nodes. If > the "repeat" variable is accessed the RepeatNode would get a flag set > and generate the corresponding code at a later stage. For this to > work, you need to be able to ask each Node for the variables it's > operating on. Really, what we need is something like: > Scope > -- RepeatNode > ... Such that the code generator will take care of backing up scope variables, when necessary, e.g. when it's not temporary variables within the scope. Similar, the code generator should generate temporary variable names itself. > Maybe you could also optimize the above tree to move the AssignNode > outside the loop, if it isn't dependent on the loop variable of the > RepeatNode. There's plenty other things you can do. I don't know which > ones of these make sense to have and which ones are better left to > Python itself. I'd say that all refactoring should be left to independent AST optimization logic, whether this be in the JIT-compiler, in CPython or tentatively in a Python library. > > > icon > > > text > > One problem here is that you don't know that ``view.useIcons()`` is static. That said, I think we could have a flag ``treat_calls_as_static`` which would enable such optimizations. But isn't it symptom treatment? Shouldn't the language instead be better: > >icon > > >text > Maybe introducing node variables such as ``this``, ``next``, ``previous``, and ``parent`` would make sense. There's always the option of going inline: > ``if view.useIcons():`` > icon > ``else:`` > text I find that double backticks are much more readable than or other such combinations; and nobody uses them for prose. To group, either use a tag from the default namespace, or ``tal`` (or whatever): > ``if some_condition:`` > > ... > Personally, I kind of feel that ``tal:content`` and ``tal:attributes`` and friends are awkward because they mix Python and attributes. On the contrary, I don't mind ``i18n`` because it's declarative. For ``metal``, it's even problematic to require tag usage because of oddballs like DOCTYPE. I'll have to think about that one; it's only ``use-macro`` that requires Python, the rest is declarative. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon 1.1 and z3c.pt problems
On 4/9/10 20:30 , Hanno Schlichting wrote: > > > icon > > > text > > > > You can easily save 2 * len(items) function calls here, by using one > more temporary variable. I haven't figured out who or what code should > do something to avoid this yet :) You can't do that. For all you know iterating over items might have a side-effect which influences the result of view.useIcons. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Problem with repoze.what-pylons sample application
I really need help with this, especially because i don't think the problem is there because i did somthing wrong. Repoze worked fine in the older version (except the unicode thing), but now no login is possible. Database is ok and password is authentified correctly. And the same problem in the sample application just confirme my suspicion tht it is a general issue under this constellation of the newest module versions. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Using the multiprocessing module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, is it save to use the 'multiprocessing' module inside a BFG app? In particular I need to maintain a multiprocessing.Pool() instance... this is working at the first glance however the BFG app won't shutdown in a clean way when stopped through a keyboard interrupt. The apps hangs usually inside the following code: File "/opt/python-2.6.4/lib/python2.6/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/opt/python-2.6.4/lib/python2.6/multiprocessing/util.py", line 260, in _exit_function _run_finalizers(0) File "/opt/python-2.6.4/lib/python2.6/multiprocessing/util.py", line 235, in _run_finalizers finalizer() File "/opt/python-2.6.4/lib/python2.6/multiprocessing/util.py", line 174, in __call__ res = self._callback(*self._args, **self._kwargs) File "/opt/python-2.6.4/lib/python2.6/multiprocessing/pool.py", line 363, in _terminate_pool cls._help_stuff_finish(inqueue, task_handler, len(pool)) File "/opt/python-2.6.4/lib/python2.6/multiprocessing/pool.py", line 348, in _help_stuff_finish inqueue._rlock.acquire() There is a Pool.terminate() method for closing the pool manually however I don't know exactly where to trigger the code. Thoughts? Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvAdm4ACgkQCJIWIbr9KYwUCwCeIl2swbQg61OkMdYXfaR5EWPE 2tkAoOoZ/KN/tIRLCBiBP8tKttJMc9ok =pn9J -END PGP SIGNATURE- <>___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Problem with repoze.what-pylons sample application
I'm not sure that I remember the entire context here, but if you are using r.who 2.0, ensure that your "auth_tkt" plugin is both an identifier and and authenticator. In r.who 1.0 this did not need to be true; in r.who 2.0, configurations need to change so that it is true. On 4/10/10 7:11 AM, Phenex wrote: > I really need help with this, especially because i don't think the problem is > there because i did somthing wrong. Repoze worked fine in the older version > (except the unicode thing), but now no login is possible. Database is ok and > password is authentified correctly. And the same problem in the sample > application just confirme my suspicion tht it is a general issue under this > constellation of the newest module versions. > ___ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev > -- Chris McDonough Agendaless Consulting, Fredericksburg VA The repoze.bfg Web Application Framework Book: http://bfg.repoze.org/book ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Using the multiprocessing module
On 4/10/10 9:00 AM, Andreas Jung wrote:
> is it save to use the 'multiprocessing' module inside a BFG app?
I don't know think it is any less safe to use it in BFG than it would be in any
other app.
Multiprocessing does some weird stuff at startup time in its "utils" module.
For instance:
def _exit_function():
global _exiting
info('process shutting down')
debug('running all "atexit" finalizers with priority >= 0')
_run_finalizers(0)
for p in active_children():
if p._daemonic:
info('calling terminate() for daemon %s', p.name)
p._popen.terminate()
for p in active_children():
info('calling join() for process %s', p.name)
p.join()
debug('running the remaining "atexit" finalizers')
_run_finalizers()
atexit.register(_exit_function)
Library code that registers an atexit hook or mutates module global state for
purposes other than defining classes, functions, or variables as the result of
an import is lame, lame, lame, lame. I'm sure this is the reason you're
getting this traceback but I don't know how to avoid it.
> In particular I need to maintain a multiprocessing.Pool() instance...
> this is working at the first glance however the BFG app won't shutdown
> in a clean way when stopped through a keyboard interrupt. The apps
> hangs usually inside the following code:
>
>File "/opt/python-2.6.4/lib/python2.6/atexit.py", line 24, in
> _run_exitfuncs
> func(*targs, **kargs)
>File "/opt/python-2.6.4/lib/python2.6/multiprocessing/util.py", line
> 260, in _exit_function
> _run_finalizers(0)
>File "/opt/python-2.6.4/lib/python2.6/multiprocessing/util.py", line
> 235, in _run_finalizers
> finalizer()
>File "/opt/python-2.6.4/lib/python2.6/multiprocessing/util.py", line
> 174, in __call__
> res = self._callback(*self._args, **self._kwargs)
>File "/opt/python-2.6.4/lib/python2.6/multiprocessing/pool.py", line
> 363, in _terminate_pool
> cls._help_stuff_finish(inqueue, task_handler, len(pool))
>File "/opt/python-2.6.4/lib/python2.6/multiprocessing/pool.py", line
> 348, in _help_stuff_finish
> inqueue._rlock.acquire()
>
> There is a Pool.terminate() method for closing the pool manually however
> I don't know exactly where to trigger the code.
I think you probably need to ask on the Python-users newsgroup or ask the
author of multiprocessing.
- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Repackaged PIL 1.1.7
Hi. I took the time and repackaged PIL 1.1.7 for distribute / setuptools based on Chris work for 1.1.6. There's a fork on bitbucket [1] with my changes. bitbucket is not behaving right now, so I put up a source dist on jarn.com [2]. In order to generate the manifest I used setuptools_hg which is now in setup_requires. I'm not sure that's the best way to do it, so if someone has a better idea, please speak up. After I get some positive feedback, I'll put this into the downloads section on bitbucket and would be happy to see it copied to the usual dist.* places :) Cheers, Hanno [1] http://bitbucket.org/hannosch/pil-117-distribute/ [2] http://dist.jarn.com/public/PIL-1.1.7-preview.tar.gz ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
Hi Hanno, On 2010-04-10, Hanno Schlichting wrote: > Hi. > > I took the time and repackaged PIL 1.1.7 for distribute / setuptools > based on Chris work for 1.1.6. > > There's a fork on bitbucket [1] with my changes. bitbucket is not > behaving right now, so I put up a source dist on jarn.com [2]. > > In order to generate the manifest I used setuptools_hg which is now in > setup_requires. I'm not sure that's the best way to do it, so if > someone has a better idea, please speak up. > > After I get some positive feedback, I'll put this into the downloads > section on bitbucket and would be happy to see it copied to the usual > dist.* places :) w00t. :-) A couple questions: (1) Just curious have you seen any issues with PIL and Zope 2 along these lines: 04:45 < wiggy> argh, PIL 1.1.7 breaks Zope 06:42 < aclark> wiggy: how? 06:42 < wiggy> aclark: it includes an ImageFile module at toplevel 06:42 < wiggy> aclark: Zope2 has one as well 06:42 < aclark> ah 06:42 < wiggy> and if the PIL one is found first things go boom 06:43 < aclark> can you control the order? 06:43 < wiggy> nope 06:43 < aclark> seems to me I've used 1.1.7 w/Zope 2… 06:43 < wiggy> I suspect it's pretty much random 06:44 < aclark> interesting 06:44 < wiggy> try reordeing the paths in bin/instance (2) Why the repackaging? I was under the impression that 1.1.7 alreaded works with setuptools OOB, e.g.: acl...@alex-clarks-macbook-pro:~/Developer/ > virtualenv pil-test New python executable in pil-test/bin/python Installing setuptoolsdone. acl...@alex-clarks-macbook-pro:~/Developer/ > cd pil-test acl...@alex-clarks-macbook-pro:~/Developer/pil-test/ > bin/pip install pil Downloading/unpacking pil Downloading PIL-1.1.7.tar.gz (506Kb): 506Kb downloaded Running setup.py egg_info for package pil WARNING: '' not a valid package name; please use only.-separated package names in setup.py WARNING: '' not a valid package name; please use only.-separated package names in setup.py Installing collected packages: pil Running setup.py install for pil WARNING: '' not a valid package name; please use only.-separated package names in setup.py WARNING: '' not a valid package name; please use only.-separated package names in setup.py --- using frameworks at /System/Library/Frameworks building '_imaging' extension … PIL 1.1.7 SETUP SUMMARY version 1.1.7 platform darwin 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] --- TKINTER support available --- JPEG support available --- ZLIB (PNG/ZIP) support available --- FREETYPE2 support available *** LITTLECMS support not available To add a missing option, make sure you have the required library, and set the corresponding ROOT variable in the setup.py script. To check the build, run the selftest.py script. changing mode of build/scripts-2.6/pilconvert.py from 644 to 755 changing mode of build/scripts-2.6/pildriver.py from 644 to 755 changing mode of build/scripts-2.6/pilfile.py from 644 to 755 changing mode of build/scripts-2.6/pilfont.py from 644 to 755 changing mode of build/scripts-2.6/pilprint.py from 644 to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilconvert.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pildriver.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilfile.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilfont.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilprint.py to 755 Successfully installed pil The confusion surrounding PIL almost makes me want to write some sort of über document listing the orginal problem along with all the various hack-arounds. Alex > Cheers, > Hanno > > [1] http://bitbucket.org/hannosch/pil-117-distribute/ > [2] http://dist.jarn.com/public/PIL-1.1.7-preview.tar.gz -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
On Sun, Apr 11, 2010 at 3:14 AM, Alex Clark wrote: > A couple questions: > > (1) Just curious have you seen any issues with PIL and Zope 2 > along these lines: > 04:45 < wiggy> argh, PIL 1.1.7 breaks Zope > 06:42 < aclark> wiggy: how? > 06:42 < wiggy> aclark: it includes an ImageFile module at toplevel [...] > (2) Why the repackaging? I was under the impression that 1.1.7 > alreaded works with setuptools OOB, e.g.: > > Running setup.py egg_info for package pil > WARNING: '' not a valid package name; please use only.-separated > package names in setup.py [...] > The confusion surrounding PIL almost makes me want to write some sort of über > document listing the orginal problem along with all the various hack-arounds. Both of these show you the exact problem the official distribution has with setuptools. It uses a package name of '', which causes all modules in the distribution to be installed into the top-level namespace, instead of installing them into a package called PIL. So instead of "from PIL import ImageFile" they become available as "import ImageFile". PIL is a perfectly good user of distutils, but it's specific setup.py isn't compatible with setuptools or any tools based on that. All the repackaged tarballs use setuptools directly and install the modules correctly. There's two versions of this repackaging, which both do essentially the same. One retains the distribution name PIL and was done by Chris, the other one is called PILwoTk by Jim Fulton and does the same, but also disables the rarely used Tk support. As this is a repackaging of a specific version of PIL, it needs to be done again for each new release. So far we only had a repackaging of the 1.1.6 version, I contributed one for 1.1.7 now. Hanno ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
