On Wed, Apr 8, 2015 at 10:11 PM, Yury Selivanov wrote:
> BTW, there is another project to migrate issues:
> https://github.com/arthur-debert/google-code-issues-migrator
Seems like one of his forks gone too far away:
https://github.com/abusalimov/google-code-issues-migrator
According the commit l
Google already got back to me -- they can repro my problem and will try to
fix it.
On Wed, Apr 8, 2015 at 12:11 PM, Yury Selivanov
wrote:
> Yes, I can’t find anything particular about 208 (for instance) to see why
> it wasn’t exported.
>
> BTW, there is another project to migrate issues:
> https
Yes, I can’t find anything particular about 208 (for instance) to see why it
wasn’t exported.
BTW, there is another project to migrate issues:
https://github.com/arthur-debert/google-code-issues-migrator
Yury
> On Apr 8, 2015, at 3:04 PM, Guido van Rossum wrote:
>
> The Google code migration
The Google code migration tool claims to migrate issues. You can see how
far it got in this example repo:: https://github.com/gvanrossum/tulip-try1
-- apparently the issue migration is flaky. :-(
But I won't declare the package migrated until the issues and wiki have
been migrated fully.
On Wed,
Hi Guido,
How will we migrate issues? Just recreate them on guthub, or abandon and
start from scratch?
I was going to continue discussion
on https://code.google.com/p/tulip/issues/detail?id=208
Yury
On Wednesday, April 8, 2015 at 1:32:40 PM UTC-4, Guido van Rossum wrote:
>
> Because Google co
The Migrate button promises it will migrate the wiki too. Unfortunately it
seems it tries to migrate that last, so I haven't seen the results yet.
FWIW here's an example of a failed migration:
https://github.com/gvanrossum/tulip-try1
On Wed, Apr 8, 2015 at 11:53 AM, Andrew Svetlov
wrote:
> Would
Would you migrate wiki pages also?
Or, please, just enable it for github project -- I'll transfer those
pages manually.
On Wed, Apr 8, 2015 at 2:47 PM, Guido van Rossum wrote:
> FWIW, I'm running into issues with the migration. It seems the code gets
> migrated fine but the issues are migrated in
FWIW, I'm running into issues with the migration. It seems the code gets
migrated fine but the issues are migrated incompletely (failing at a
different place each time). I'm giving up for now.
On Wed, Apr 8, 2015 at 10:32 AM, Guido van Rossum wrote:
> Because Google code is shutting down, I'm ab
Because Google code is shutting down, I'm about to migrate the Tulip repo
to GitHub. I'll post here again once the migration is done.
--
--Guido van Rossum (python.org/~guido)
It is also what Victor Stinner said at first, but I am quite sure it is.
Also I proposed to inherit from Future to improve the cancel() call and
made this patch: https://github.com/aio-libs/aioredis/pull/59/files
Could you tell me if it is the right way to do it?
Le mercredi 8 avril 2015 14:21:
On 8 April 2015 at 11:14, Rémy Hubscher wrote:
> Hello,
>
> I am using aioredis on a BLPOP which is a blocking call on a redis
> connection.
>
> redis.blpop is a Future created here:
> https://github.com/aio-libs/aioredis/blob/master/aioredis/connection.py#L154-L157
>
> When using asyncio.wait_fo
I have seen a similar behavior with aioredis:
See my message here:
https://groups.google.com/forum/#!topic/python-tulip/_J6BedIpu5I
Le vendredi 3 avril 2015 17:17:08 UTC+2, Victor Stinner a écrit :
>
> Hum, I didn't get any reply to this message :-( I opened an issue to
> at least document the
Hello,
I am using aioredis on a BLPOP which is a blocking call on a redis
connection.
redis.blpop is a Future created here:
https://github.com/aio-libs/aioredis/blob/master/aioredis/connection.py#L154-L157
When using asyncio.wait_for(redis.blpop("channel"), timeout=5) if the
timeout is raised
13 matches
Mail list logo