You are receiving this email because we wish you to use our cost-effective IT services.
We are a China based Custom Software Application Development provider. We offer full cycle custom software programming services, from product idea, software development to support and enhancement. We employ a large pool of software engineers coming from different backgrounds. We are able to balance product development efforts and project duration to your business needs.
Custom Application Development
Custom Software Development
iPhone Application Development
iPad Application Development
Mobile Application Development
Android Mobile Application Development
Soft Product Development
Game Design & Development
Game Testing & Quality Assurance
CRM Software Application Development
ERP Software Application Development
Enterprise Portal Solution
Sales Force Automation Solution
Game Design & Development
Knowledge Management Solution
Workflow Management Solution
SharePoint Development Services
Microsoft Online Services
Microsoft Azure Services
ITVIATSA Software Development
Pls send address to larryremove123(a)msn.com for remove
at the language summit many people told me that the HPy team should try to
communicate more with the CPython developers, so let's try :).
In HPy we want to design an API to build bytes/str objects in two steps, to
avoid the problem that currently in CPython they are not really immutable.
Before making any proposal, I spent quite a lot of time in researching how
the current API are used to construct bytes/str objects, and I summarized
my results here:
I think that my survey could be interesting for the people in this ML,
independently of HPy.
That said, I also opened an issue where to discuss concrete proposals for
the HPy API to do that: https://github.com/hpyproject/hpy/issues/214
I would be glad to receive comments and suggestions about that, and
especially to know whether I missed some important use case in my analysis.
Also, if you think that these kind of mails are off-topic in this ML,
please let me know and I'll stop.
For my research, IBM wrote a tracing GC for CPython and I was trying out
some ideas on how we would support the CAPI.
I know about handles used in HPy but I felt they can actually incur
allocation overhead and use more memory.
Instead, I thought of changing the semantics of the union type (PyObject)
to not point to internal structures and use a stack for sharing data
between Python and C. There can be one push function for each Python type
with a direct representation in C: Py_pushInteger for ints, etc. When a C
function returns, all values in the stack are returned to Python as the
results of the C function. Assuming we can have a way of returning multiple
values in Python.
typedef struct Object *PyObject;
typedef unsigned int PyObject;
Where now PyObject becomes an index into an internal array that stored all
values that had to be given to. This means that when a value is in that
array, it would not be collected by Python. When the C function returns its
whole array is erased, and the values used by the function are collected.
This setup gets us a reliable Union type (PyObject), the garbage collector
can also move objects. I think that backward compatibility can easily be
implemented using macros.
What is some feedback on this approach and am I overconfident of having
reasonable backward compatibility? Also, can this experiment uncover any
insights that CPython would find useful?
*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program." Alan J. Perlis*