On Aug 3, 2008, at 12:29 PM, Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> Hi,
>>
>> Dag Sverre Seljebotn wrote:
>>> In making it possible to have runnable code in pxds, I need to
>>> make a
>>> choice. The problem is that interned strings, objects etc. live in
>>> seperate scopes and you get double copies, basically now I get the
>>> following code twice in my c-file:
>>>
>>> static char __pyx_k___getbuffer__[] = "__getbuffer__";
>>> static PyObject *__pyx_kp___getbuffer__;
>>>
>>> which gcc isn't too thrilled about.
>>> [...]
>>> 2) Move these things from the scopes to code.global (a global
>>> context of
>>> the CCodeWriter). This fits nicely with utility_code going over
>>> as well.
>>> This means that for now each scope simply pipe their things into
>>> code
>>> where they are merged, while in time then e.g. StringNode could
>>> intern a
>>> string during code generation rather than bothering with it during
>>> analysis. (I think this is a viable way forward, but may take an
>>> hour or
>>> three longer for me to do.)
>>
>> Since I previously worked a bit on the string interning code, I
>> think it would
>> really benefit from such a change. Please go ahead.
>
> 1) OK I've made some changes in this direction:
>
> - BlockNode now forwards the entries it deals with to
> Code.GlobalState,
> which tries to do the same thing but filters out duplicates (which
> comes
> from pxds and pyxes doing the same thing). In time, I expect all of
> BlockNode to vanish.
>
> - Also, the code dealing with interned strings/ints and cached
> builtins
> from ModuleNode is moved to Code.GlobalState; which uses a different
> strategy: Rather than iterating over the contents of a scope, it
> simply
> allocates many CodeWriter instances/buffers and outputs
> initialiazation
> code at the same time as the declaration code, though to a seperate
> buffer. (One can like or not like this I suppose -- only argument I
> have
> is it tends to keep code more "together" in one location, but the real
> reason is that it was easier this way.)
>
> - Because one cannot have insertion points within functions (would
> create h). Therefore I extracted some things from the module
> initialization function into two more functions, __Pyx_InitGlobals and
> __Pyx_InitCachedBuiltins. I could potentially get rid of this with a
> special "I promise not to use temps or modify labels"-insertion-point,
> but this was easier. (Also, one could argue for it from a design
> viewpoint: c-file globals are more tied to the c-file as such than
> necesarrily the module -- if a single C file were to implement both a
> module and some of its submodules [1], then cached builtins could be
> shared but the module init func would not be!)
>
> This all runs the test cases etc. and I consider it "done" in some
> sense, but I want to have some feedback before I consider it ready for
> merging.
Thanks. Haven't actually looked at the code yet, but it all sounds good.
> Of course, it represents a transitional solution. In the end, I expect
> one would add something like this:
>
> self.result_code = code.globalcode.py_string_literal("abc")
>
> and so on (details must be discussed when the day comes), but that, as
> my new mantra has become, "is pending a result_code refactoring". But
> the design now allows for creating such a thing, it would all happen
> within Code.py. (I'll get to that some day of course, especially as
> Greg
> has a lot of it done, but I have my GSoC priorities to worry about).
Yep. Perfect is the enemy of the good.
> [1] (Is this possible in Python? What I've done now opens up for
> Cython
> supporting this (think compiling a dir tree to a single .so) and get
> some degree of sharing constant literals etc., but that's hardly a
> priority.)
>
> 2) During writing this, I realized that some code could be written
> in a
> shorter fashion:
>
> (self.initwriter
> .putln("return 0;")
> .put_label(self.initwriter.error_label)
> .putln("return -1;")
> .putln("}")
> .exit_cfunc_scope()
> )
>
> ...where I've changed some functions to return "self" (much like C++
> iostreams). Do you like or dislike this? Consider both with and
> without
> the indendation-matching-the-C-code. It does create some dissymetry
> (see the put_label where you need a new reference to the writer), this
> could be fixed by adding put_error_label, or by going back
>
> The counterargument is that I could say "c = self.initwriter" first
> instead to get almost the same brevity.
>
> Of course, this is only an added option for new code. So inconsistency
> would be added. Still I'm +1/2 because of when doing all the C code
> I've
> written in Buffer.py I always thought that it tended to become quite
> long-winded to express what I wanted...
>
> (Some code is using this in my branch which I'll redo if the vote
> is not
> positive.)
Honestly, I find that harder to read than the explicit way, and would
rather stick with the "explicit is better than implicit" mantra on
this one.
> 3) For buffers, this means that I've manged to strip all NumPy
> specific
> code from Buffer.py, instead you currently can define __getbuffer__
> and
> __releasebuffer__ in numpy.pxd
Nice.
> I have not introduced a generic "final" mechanism or similar;
> rather an
> exception is introduced specifically for __getbuffer__ and
> __releasebuffer__ and specifically for the purpose of
> Py2.5-GetBuffer-faking. I'd like to leave it like this for now, but it
> will be a "hidden" feature and I will warn people not to rely on it.
>
> In time I see it like this: A "final" language feature is added, and
> anything declared "final" can reside in pxds. But that is not done
> now,
> hence the special cases for these two functions.
Yep. I would like to get a general sense of what people think of
adding a "final" keyword to the language (for cdef functions only(?)).
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
