Re: [Cython] Cython 0.15 release

2011-07-24 Thread 최원준 
Can I test the generators?


2011/7/22 Stefan Behnel 

> Robert Bradshaw, 22.07.2011 01:00:
>
>  Are the lxml failures at
>> https://sage.math.washington.**edu:8091/hudson/job/cython-**
>> devel-lxml-trunk-py27/
>> expected?
>>
>
> Yes, the "test_xmlschema_import_file" test keeps crashing with a high
> probability. Some kind of threading related bug, no idea how to reproduce it
> in a debuggable way...
>
> Just ignore those two jobs for the time being. I keep looking at the tests
> from time to time, because it's not *always* that bug that kills them.
>
> Stefan
>
> __**_
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/**mailman/listinfo/cython-devel
>
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython 0.15 release

2011-07-24 Thread Vitja Makarov 
2011/7/25 최원준 :
> Can I test the generators?
>
>

Sure, generators support is in master already:

https://github.com/cython/cython

-- 
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython 0.15 release

2011-07-24 Thread 최원준 
I don't know where it is.. sorry

2011/7/25 Vitja Makarov 

> 2011/7/25 최원준 :
> > Can I test the generators?
> >
> >
>
> Sure, generators support is in master already:
>
> https://github.com/cython/cython
>
> --
> vitja.
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython 0.15 release

2011-07-24 Thread Stefan Behnel 

최원준, 25.07.2011 08:03:

2011/7/25 Vitja Makarov

2011/7/25 최원준:

Can I test the generators?


Sure, generators support is in master already:

https://github.com/cython/cython


I don't know where it is.. sorry


It's actually not that hard. You go to that URL, click on the big fat 
"Downloads" button, and then select the archive format you prefer. Next, 
you unpack it on your machine, change into the extracted directory and run 
"python setup.py install".


Besides, this is a question for the cython-users mailing list, not the core 
developers mailing list.


Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython 0.15 release

2011-07-24 Thread 최원준 
ok

2011/7/25 Stefan Behnel 

> 최원준, 25.07.2011 08:03:
>
>> 2011/7/25 Vitja Makarov
>>
>>> 2011/7/25 최원준:
>>>
>>>  Can I test the generators?

>>>
>>> Sure, generators support is in master already:
>>>
>>> https://github.com/cython/**cython 
>>>
>>
>> I don't know where it is.. sorry
>>
>
> It's actually not that hard. You go to that URL, click on the big fat
> "Downloads" button, and then select the archive format you prefer. Next, you
> unpack it on your machine, change into the extracted directory and run
> "python setup.py install".
>
> Besides, this is a question for the cython-users mailing list, not the core
> developers mailing list.
>
> Stefan
>
> __**_
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/**mailman/listinfo/cython-devel
>
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Build failed in Jenkins: cython-devel-sdist #522

2011-07-24 Thread Vitja Makarov 
2011/7/25 Hudson on sage-math :
> See 
>
> --
> Started by user scoder
> Building on master
> Checkout:workspace / 
>  - 
> hudson.remoting.LocalChannel@5aa4a4a9
> Using strategy: Default
> Last Built Revision: Revision 6af313c91dddad29ac5b69e394c6a60031724b05 
> (origin/master)
> Checkout:workspace / 
>  - 
> hudson.remoting.LocalChannel@5aa4a4a9
> Fetching changes from the remote Git repository
> Fetching upstream changes from git://github.com/cython/cython
> Commencing build of Revision 6af313c91dddad29ac5b69e394c6a60031724b05 
> (origin/master)
> Checking out Revision 6af313c91dddad29ac5b69e394c6a60031724b05 (origin/master)
> FATAL: Unable to produce a script file
> hudson.util.IOException2: Failed to create a temp file on 
> 
>        at hudson.FilePath.createTextTempFile(FilePath.java:966)
>        at 
> hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:104)
>        at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66)
>        at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58)
>        at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
>        at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:664)
>        at hudson.model.Build$RunnerImpl.build(Build.java:177)
>        at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
>        at 
> hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:430)
>        at hudson.model.Run.run(Run.java:1376)
>        at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>        at hudson.model.ResourceController.execute(ResourceController.java:88)
>        at hudson.model.Executor.run(Executor.java:175)
> Caused by: java.io.IOException: No space left on device
>        at java.io.FileOutputStream.writeBytes(Native Method)
>        at java.io.FileOutputStream.write(FileOutputStream.java:260)
>        at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
>        at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:297)
>        at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:130)
>        at java.io.OutputStreamWriter.close(OutputStreamWriter.java:216)
>        at hudson.FilePath$12.invoke(FilePath.java:960)
>        at hudson.FilePath$12.invoke(FilePath.java:944)
>        at hudson.FilePath.act(FilePath.java:758)
>        at hudson.FilePath.act(FilePath.java:740)
>        at hudson.FilePath.createTextTempFile(FilePath.java:944)
>        ... 12 more
> Build step 'Execute shell' marked build as failure
> Archiving artifacts
> Recording fingerprints
>
>

It seems like hudson server is running out of space.

-- 
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Build failed in Jenkins: cython-devel-sdist #522

2011-07-24 Thread Stefan Behnel 

Vitja Makarov, 25.07.2011 08:32:

It seems like hudson server is running out of space.


It's actually the /tmp directory that's full here. Contains some 65GB from 
other jobs that are running on the machine. I wrote a message to the 
cluster users mailing list to have someone with appropriate rights clean it up.


Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Utility Codes and templates

2011-07-24 Thread Vitja Makarov 
2011/7/23 Robert Bradshaw :
> On Fri, Jul 22, 2011 at 3:12 AM, mark florisson
>  wrote:
>> For my work on the _memview branch (and also on fused types) I noticed
>> that UtilityCodes started weighing heavily on me in their current
>> form, so I wrote a little loader in the _memview branch:
>>
>> https://github.com/markflorisson88/cython/commit/e13debed2db78680ec0bd8c343433a2b73bd5e64#L2R110
>>
>> The idea is simple: you put your utility codes in Cython/Utility in
>> .pyx, .c, .h files etc, and then load them. It works for both
>> prototypes and implementations, for UtilityCode and CythonUtilityCode:
>
> This sounds like it could be a nice way to organize our UtilityCode
> snippets. So far we haven't really needed any more templating than
> simple substitution, but for what you're doing I can see this being
> quite handy. This may also provide a more flexible way forward for
> supporting multiple backends.
>
>> myutility.c
>>
>> // UtilityProto: MyUtility
>> header code here
>>
>> // UtilityCode: MyUtility
>> implementation code here
>>
>> You can add as many other utilities as you like to the same file. You
>> can then load it using
>>
>>    UtilityCode.load_utility_from_file("myutility.c", "MyUtility")
>
> I agree with you that having multiple related, named snippets in same
> file is worthwhile. What about
>
> // MyUtility.proto ///
>
> and
>
>  MyCyUtility ##
>
> so the chunks are easy to see.
>

C++ comments looks ugly. May be it's better to have something like this:

/* UtilityCode:  MyUtility.proto */
and

# UtilityCode: MyCyUtility

That's also pretty easy to parse

-- 
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Utility Codes and templates

2011-07-24 Thread Stefan Behnel 

Vitja Makarov, 25.07.2011 08:41:

2011/7/23 Robert Bradshaw:

On Fri, Jul 22, 2011 at 3:12 AM, mark florisson
  wrote:

For my work on the _memview branch (and also on fused types) I noticed
that UtilityCodes started weighing heavily on me in their current
form, so I wrote a little loader in the _memview branch:

https://github.com/markflorisson88/cython/commit/e13debed2db78680ec0bd8c343433a2b73bd5e64#L2R110

The idea is simple: you put your utility codes in Cython/Utility in
.pyx, .c, .h files etc, and then load them. It works for both
prototypes and implementations, for UtilityCode and CythonUtilityCode:


This sounds like it could be a nice way to organize our UtilityCode
snippets. So far we haven't really needed any more templating than
simple substitution, but for what you're doing I can see this being
quite handy. This may also provide a more flexible way forward for
supporting multiple backends.


myutility.c

// UtilityProto: MyUtility
header code here

// UtilityCode: MyUtility
implementation code here

You can add as many other utilities as you like to the same file. You
can then load it using

UtilityCode.load_utility_from_file("myutility.c", "MyUtility")


I agree with you that having multiple related, named snippets in same
file is worthwhile. What about

// MyUtility.proto ///

and

 MyCyUtility ##

so the chunks are easy to see.



C++ comments looks ugly. May be it's better to have something like this:

/* UtilityCode:  MyUtility.proto */
and

# UtilityCode: MyCyUtility

That's also pretty easy to parse


For the parser, it makes no difference. For a human, it does. A big fat 
marker like "/" is hard to miss, whereas a tiny one 
like "/* ... */" is easily overlooked within a longer piece of code.


Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel