Hi,
On Sun, Nov 18, 2012 at 8:22 AM, Georg Brandl wrote:
> One way would be to use one hg repo per version, and (maybe, if needed)
> a master repo that has them as subrepos.
Or have all versions in the same repo as usual (with branches), but
have hg subrepos point to different repos: ones extrac
Am 18.11.2012 10:00, schrieb Armin Rigo:
> Hi,
>
> On Sun, Nov 18, 2012 at 8:22 AM, Georg Brandl wrote:
>> One way would be to use one hg repo per version, and (maybe, if needed)
>> a master repo that has them as subrepos.
>
> Or have all versions in the same repo as usual (with branches), but
>
Yes!
For many years I have been very frustrated by the install-centric nature of
python. I am biased, of course, by the fact that I am developing an
application where python is embedded, an application that needs to run out of
the box. A developer may have many many versions (branches) of the
On Sun, Nov 18, 2012 at 8:54 PM, Kristján Valur Jónsson <
krist...@ccpgames.com> wrote:
> I don't have a well formed solution in mind, but I would see it desirable
> to have a way for someone to release his package with all its dependencies
> as a self-contained and isolated unit. E.g. if package
Interesting work indeed.
From profiling CPython it has long been clear to me that enormous gains can be
made by making instruction dispatching faster. A huge amount of time is spent
in the evaluation loop. I have also been making small inroads to offline
bytecode optimization. Identifying com
On Sat, 17 Nov 2012 11:17:40 +0100
Armin Rigo wrote:
> Hi Victor,
>
> On Sat, Nov 17, 2012 at 2:13 AM, Victor Stinner
> wrote:
> > The major drawback of the register approach (at least of my implementation)
> > is that it changes the lifetime of objects. Newly created objects are only
> > "destr
Zitat von Armin Rigo :
Hi,
On Sun, Nov 18, 2012 at 8:22 AM, Georg Brandl wrote:
One way would be to use one hg repo per version, and (maybe, if needed)
a master repo that has them as subrepos.
Or have all versions in the same repo as usual (with branches), but
have hg subrepos point to dif
On 17.11.12 03:13, Victor Stinner wrote:
The major drawback of the register approach (at least of my
implementation) is that it changes the lifetime of objects. Newly
created objects are only "destroyed" at the exit of the function,
whereas the stack-based VM destroys "immediatly" objects (thanks
2012/11/18 Antoine Pitrou :
> Also, I would point out that the reference counting behaviour is an
> important feature of *C*Python (to the point that we have test cases
> checking against reference cycles), so we can't break it nilly-willy.
The tests about reference cycles are just tests that garb
On Sun, 18 Nov 2012 09:37:57 -0500
Benjamin Peterson wrote:
> 2012/11/18 Antoine Pitrou :
> > Also, I would point out that the reference counting behaviour is an
> > important feature of *C*Python (to the point that we have test cases
> > checking against reference cycles), so we can't break it n
2012/11/18 Antoine Pitrou :
> On Sun, 18 Nov 2012 09:37:57 -0500
> Benjamin Peterson wrote:
>
>> 2012/11/18 Antoine Pitrou :
>> > Also, I would point out that the reference counting behaviour is an
>> > important feature of *C*Python (to the point that we have test cases
>> > checking against refe
On Sun, Nov 18, 2012 at 6:18 AM, wrote:
>
> Zitat von Armin Rigo :
>
>
>> Hi,
>>
>> On Sun, Nov 18, 2012 at 8:22 AM, Georg Brandl wrote:
>>>
>>> One way would be to use one hg repo per version, and (maybe, if needed)
>>> a master repo that has them as subrepos.
>>
>>
>> Or have all versions in t
On Sun, 18 Nov 2012 11:27:32 -0500
Benjamin Peterson wrote:
> 2012/11/18 Antoine Pitrou :
> > On Sun, 18 Nov 2012 09:37:57 -0500
> > Benjamin Peterson wrote:
> >
> >> 2012/11/18 Antoine Pitrou :
> >> > Also, I would point out that the reference counting behaviour is an
> >> > important feature of
On 11/18/2012 12:05 PM, Brian Curtin wrote:
On Sun, Nov 18, 2012 at 6:18 AM, wrote:
Zitat von Armin Rigo :
Or have all versions in the same repo as usual (with branches), but
have hg subrepos point to different repos: ones extracted from the
main repo by containing only the correct branch.
14 matches
Mail list logo
