[Lustre-devel] Language choice for Lustre tests

[Lustre-devel] Language choice for Lustre tests

[Nathan Rutman]

At LAD'12 we proposed a plan for improving the Lustre test framework as an important part of the Lustre quality story.  One of the discussion points there was that the bash language of the current tests was lacking in a variety of areas.  We're moving forward with this work but need community agreement on the best course.  

Given the requirements and language options below, the reasonable choices rapidly diminish to a showdown between perl and python.  I think we're leaning at this point toward perl, based on it's superior speed and inter-version compatibility.  The final piece of the puzzle is the knowledge of existing Lustre test writers, so please chime in.  (But note that "popularity" is the reason we chose bash the first time, and look where that got us...)

	requirements
		1. easy to use
		2. strict structure
		3. universally available
		4. widely maintained
		5. widely understood
		6. good filesystem interface: posix API
		7. fast - replace e.g. createmany with embedded function
		8. operate remote instances
		9. inter-version compatibility
	options
		bash - capable, but too flexible, easy to abuse
		perl - forward compatible, universal, more widely understood, xperior, compact; hard to read later
			posix::open, opendir, lseek, etc.
	parallel::MPI
			~2x faster than python
			more version compatible
		python - very clear structure, swig module for c inclusion; non-standard installations, support
			os.open: all c flags	
			MPI bindings
			tab/space requirements make remote editing more difficult
		cucumber - ruby based, difficult deployment
		java - easy deployment, dev environ, debugger, fast; must compile
		ruby - compact


http://silicainsilico.wordpress.com/2012/03/26/switching-from-perl-to-python-speed/
http://tenser.typepad.com/tenser_said_the_tensor/2006/08/python_vs_perl_.html
http://opennomad.com/content/performance-different-scripting-languages-shell-v-perl-v-python-v-ruby
http://hentenaar.com/serendipity/index.php?/archives/27-Benchmark-PHP-vs.-Python-vs.-Perl-vs.-Ruby.html


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20121023/3ba94dff/attachment.htm>

[Lustre-devel] Language choice for Lustre tests

[Jacques-Charles Lafoucriere]

hello all

I personally always had difficulties with perl ...
the code is generally very hard to read, and the language brings very 
quickly to tricky optimization only experts understood
python is a more generic language, very easy to learn and if we make the 
right basic object definitions, it will help a lot for future 
improvement and code structure
at CEA our admin tools like shine or cluster-shell are python based and 
this choice allows us in getting scallable/reliable tools
For example, the initial version of shine (~6 years ago) was perl based 
and we were pleased to move to python for the new design

The target is lustre developers (ie kernel developers), it will be much 
easier for them to learn python than perl.
it will also be easier for them to get the right "python" way of 
programming than the right "perl" way of programming
(in both cases the worst way is to use the new language as bash, which 
can arrive much quickly with perl than with python)

about python, what do you mean by non standard installation ?
if your python configuration is right, the local differences should be 
hidden to the test framework

Bye

JC

On 10/23/2012 08:36 PM, Nathan Rutman wrote:
> At LAD'12 we proposed a plan for improving the Lustre test framework 
> as an important part of the Lustre quality story.  One of the 
> discussion points there was that the bash language of the current 
> tests was lacking in a variety of areas.  We're moving forward with 
> this work but need community agreement on the best course.
>
> Given the requirements and language options below, the reasonable 
> choices rapidly diminish to a showdown between perl and python.  I 
> think we're leaning at this point toward perl, based on it's superior 
> speed and inter-version compatibility.  The final piece of the puzzle 
> is the knowledge of existing Lustre test writers, so please chime in. 
>  (But note that "popularity" is the reason we chose bash the first 
> time, and look where that got us...)
>
> requirements
> 1. easy to use
> 2. strict structure
> 3. universally available
> 4. widely maintained
> 5. widely understood
> 6. good filesystem interface: posix API
> 7. fast - replace e.g. createmany with embedded function
> 8. operate remote instances
> 9. inter-version compatibility
> options
> bash - capable, but too flexible, easy to abuse
> perl - forward compatible, universal, more widely understood, xperior, 
> compact; hard to read later
> posix::open, opendir, lseek, etc.
> parallel::MPI
> ~2x faster than python
> more version compatible
> python - very clear structure, swig module for c inclusion; 
> non-standard installations, support
> os.open: all c flags
> MPI bindings
> tab/space requirements make remote editing more difficult
> cucumber - ruby based, difficult deployment
> java - easy deployment, dev environ, debugger, fast; must compile
> ruby - compact
>
>
> http://silicainsilico.wordpress.com/2012/03/26/switching-from-perl-to-python-speed/
> http://tenser.typepad.com/tenser_said_the_tensor/2006/08/python_vs_perl_.html
> http://opennomad.com/content/performance-different-scripting-languages-shell-v-perl-v-python-v-ruby
> http://hentenaar.com/serendipity/index.php?/archives/27-Benchmark-PHP-vs.-Python-vs.-Perl-vs.-Ruby.html
>
>
>
>
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20121023/6616133b/attachment.htm>

[Lustre-devel] Language choice for Lustre tests

[Kilian Cavalotti]

Hi,

On Tue, Oct 23, 2012 at 8:36 PM, Nathan Rutman
<nathan_rutman@xyratex.com> wrote:
> Given the requirements and language options below, the reasonable choices
> rapidly diminish to a showdown between perl and python.  I think we're
> leaning at this point toward perl, based on it's superior speed and
> inter-version compatibility.

I myself tend towards Python, but that's perfectly knowing this
couldn't be very different from the recurring, almost religious "emacs
vs vim" or "kde vs gnome" flame wars. It's a matter of taste, and it's
almost pointless to try to convince somebody to adopt the other one
once their choice is made.

I would only recommend reading this :
http://www.strombergers.com/python/python_perl_slurp_file.html.

And the obligatory XKCD: http://xkcd.com/353/

Cheers,
-- 
Kilian

[Lustre-devel] [lustre-devel] Language choice for Lustre tests

[Bruce Korb]

Hi,

On Tue, Oct 23, 2012 at 12:39 PM, Jacques-Charles Lafoucriere <
jacques-charles.lafoucriere@cea.fr> wrote:

>  hello all
>
> I personally always had difficulties with perl ...
> the code is generally very hard to read, and the language brings very
> quickly to tricky optimization only experts understood
>

At first blush, I had a hard time reading C code.  I was looking at the
first implementation of
the C preprocessor and nobody had figured out how to write clean code yet.
 Truly awful.
I also had a professor who claimed he could make any language look like
FORTRAN.
I believe him to this day.  It takes effort, care, examples and some
training to write
clean comprehensible code in any language, beit C or bash or perl or python
or ruby.

it will also be easier for them to get the right "python" way of
> programming than the right "perl" way of programming
> (in both cases the worst way is to use the new language as bash, which can
> arrive much quickly with perl than with python)
>

In both cases, you need to find good examples of language usage,
characterize what makes the good examples good and then emulate that.
Perl can be clean and comprehensible.  Even bash can be clean and
comprehensible.
And Python can be illegible.  It takes effort.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20121023/fca398f5/attachment.htm>

[Lustre-devel] Language choice for Lustre tests

[Roman Grigoryev]

Hi JC, all,

I should say more words about compatibility.

In comparing with server-only tools(which are often pretty good
maintained and controlled
on limited node set),  test tools often work on wider sets. Minimally,
it should work
on some clients and  also on clients with different versions then
servers, include clients in real clusters,
developers virtual clusters and so on.

As I know, Lustre users could have environment with Lustre latest
servers and  1.8 clients,
some companies use RedHat5.x clients and RedHat6.x(SL6.x) server, other
use Ubuntu. 

RH5 has only python2.4, SL61  has python2.4 and python2.6, and looks
like only
last Fedora will have python3. In same time, Ubuntu says that from next
release want to have only Python 3.
Which version should we use and how long backward compatibility will be
supported by Python and distros//for
selected version/?/

Precision Python version could be installed from non standard repos,
compiled from sources also as used
"non standard installation". Last item also mean testing own
installation on wide set of distros. Also we should
remember about external Python libraries which also could be touched by
breaking legacy compatibility.

I think, testing system should be friendly to developers as possible and
pushing to install precision version while
one or more pythons already in os could not be the simplest solution.

Now Lustre tests compatibility for wide set of system is solved by shell
and standard utilities. Perl also has great
compatibility history, many scripts could work on latest version as 10
years ago. It is reason why I see Perl as
good decision.

From compatibility(and my) point of view, also Java is preferable
solution then Python. It has few good described ways
of installation, proved compatibility, great library managers (maven,
ant+ivy) and could support scripting
languages(JPython, JRuby and more).
But it needs more memory and pretty big start time.  

Thanks,
    Roman
On 10/23/2012 11:39 PM, Jacques-Charles Lafoucriere wrote:
> hello all
.......
> about python, what do you mean by non standard installation ?
> if your python configuration is right, the local differences should be
> hidden to the test framework
>
> Bye
>
> JC
>
> On 10/23/2012 08:36 PM, Nathan Rutman wrote:
>> At LAD'12 we proposed a plan for improving the Lustre test framework
>> as an important part of the Lustre quality story.  One of the
>> discussion points there was that the bash language of the current
>> tests was lacking in a variety of areas.  We're moving forward with
>> this work but need community agreement on the best course.  
>>
>> Given the requirements and language options below, the reasonable
>> choices rapidly diminish to a showdown between perl and python.  I
>> think we're leaning at this point toward perl, based on it's superior
>> speed and inter-version compatibility.  The final piece of the puzzle
>> is the knowledge of existing Lustre test writers, so please chime in.
>>  (But note that "popularity" is the reason we chose bash the first
>> time, and look where that got us...)
>>
>> requirements
>> 1. easy to use
>> 2. strict structure
>> 3. universally available
>> 4. widely maintained
>> 5. widely understood
>> 6. good filesystem interface: posix API
>> 7. fast - replace e.g. createmany with embedded function
>> 8. operate remote instances
>> 9. inter-version compatibility
>> options
>> bash - capable, but too flexible, easy to abuse
>> perl - forward compatible, universal, more widely understood,
>> xperior, compact; hard to read later
>> posix::open, opendir, lseek, etc.
>> parallel::MPI
>> ~2x faster than python
>> more version compatible
>> python - very clear structure, swig module for c inclusion;
>> non-standard installations, support
>> os.open: all c flags
>> MPI bindings
>> tab/space requirements make remote editing more difficult
>> cucumber - ruby based, difficult deployment
>> java - easy deployment, dev environ, debugger, fast; must compile
>> ruby - compact
>>
>>
>> http://silicainsilico.wordpress.com/2012/03/26/switching-from-perl-to-python-speed/
>> http://tenser.typepad.com/tenser_said_the_tensor/2006/08/python_vs_perl_.html
>> http://opennomad.com/content/performance-different-scripting-languages-shell-v-perl-v-python-v-ruby
>> http://hentenaar.com/serendipity/index.php?/archives/27-Benchmark-PHP-vs.-Python-vs.-Perl-vs.-Ruby.html
>>
>>
>>
>>
>> _______________________________________________
>> Lustre-devel mailing list
>> Lustre-devel at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20121024/75f5193c/attachment.htm>

[Lustre-devel] Language choice for Lustre tests

[Kilian Cavalotti]

Hi Roman,

On Wed, Oct 24, 2012 at 8:31 AM, Roman Grigoryev
<roman_grigoryev@xyratex.com> wrote:
> RH5 has only python2.4, SL61  has python2.4 and python2.6, and looks like
> only last Fedora will have python3.

I agree that inter-version compatibility could be a problem with
Python. But to take this argument literally, the best way to avoid
compatibility issues is to use the widest-spread and most version
consistent language across supported distributions, ie. bash.

> In same time, Ubuntu says that from next
> release want to have only Python 3.

Since only RHEL, CentOS and SLES are supported, should we really care
about python versions in Ubuntu?
When installing Lustre in Ubuntu, users already have to do their own
packaging, so I'm not sure that having to install a specific version
of a scripting language would make much of a difference.

> Now Lustre tests compatibility for wide set of system is solved by shell and
> standard utilities. Perl also has great
> compatibility history, many scripts could work on latest version as 10 years
> ago. It is reason why I see Perl as
> good decision.

So what's wrong with bash again? If it's just "too flexible, easy to
abuse", I'm afraid there's little in Perl to prevent falling into the
same pitfalls. :)

Cheers,
-- 
Kilian

[Lustre-devel] Language choice for Lustre tests

[Roman Grigoryev]

Hi Kilian,

if you want I could try to explain why not bash from my point of view.

I agree that bash is language which could be used for test frameworks
and test-framework.sh prove it. But some
bash feature make current framework support pretty hard. For example, I
don't see good way to  use  bash unit tests for test-framework.sh

More structured requests:

1) Language features. Perl/Python/Java has many features which allows
simple write complex logic (OOP,AOP and so on)
2) Pretty wide set of libraries.
3) powerful and useful unit test frameworks.
4) support tools, e.g. inline documentation, schema generator based on
code, coverage collectiors, copyright checkers

Ubuntu is building by Intel
(http://build.whamcloud.com/job/lustre-b2_3/), so looks like it is
important platform.

Thanks,
    Roman
> Hi Roman,
>
> On Wed, Oct 24, 2012 at 8:31 AM, Roman Grigoryev
> <roman_grigoryev@xyratex.com> wrote:
>> RH5 has only python2.4, SL61  has python2.4 and python2.6, and looks like
>> only last Fedora will have python3.
> I agree that inter-version compatibility could be a problem with
> Python. But to take this argument literally, the best way to avoid
> compatibility issues is to use the widest-spread and most version
> consistent language across supported distributions, ie. bash.
>
>> In same time, Ubuntu says that from next
>> release want to have only Python 3.
> Since only RHEL, CentOS and SLES are supported, should we really care
> about python versions in Ubuntu?
> When installing Lustre in Ubuntu, users already have to do their own
> packaging, so I'm not sure that having to install a specific version
> of a scripting language would make much of a difference.
>
>> Now Lustre tests compatibility for wide set of system is solved by shell and
>> standard utilities. Perl also has great
>> compatibility history, many scripts could work on latest version as 10 years
>> ago. It is reason why I see Perl as
>> good decision.
> So what's wrong with bash again? If it's just "too flexible, easy to
> abuse", I'm afraid there's little in Perl to prevent falling into the
> same pitfalls. :)
>
> Cheers,

[Lustre-devel] Language choice for Lustre tests

[DEGREMONT Aurelien]

Hello

I've developed in Perl and Python for several years in both languages. I 
enjoyed both.
Regarding starting a new project, for testing framework, here is several 
points which are the key points for choosing the right language.

- Longevity

Perl as a long history behind it, is available in all distros, that's 
true. But Perl is there for compatibility for running projects which 
were starting a long time ago. Nobody is starting a really big and fancy 
project in Perl nowadays. All new hackers are only speaking of Python or 
Ruby. You will not attract contributors with Perl. Perl 5 is very 
compatible because no new changes is really added to this language.
And do not tell me that Perl 6 is coming. If Perl 6 is an option, then 
there is no issue with Python 3 and forget your compatibility.

- Compat

Developping in Python, for a large number of environment means coding 
for Python 2.4+. This will run nicely on Python up to 2.7
As long as only Python 2 only is concerned, compat for Python is fine.
But I agree that Python 3 is coming, and at long term, it should be 
taken in account even if no major distro is using it right now.
(No Python 3 before RHEL7 or next Ubuntu LTS (14.04))

-Lustre is for system people

Lustre is developped by system guys, which mainly use vim or emacs to 
develop in Lustre. Very few of them are using IDE or stuff like Maven. 
Population developing Java with Maven is the exact opposite of guys 
coding in C, for Kernel code. Moreover, JVM are awful to install 
regarding a standard Python, Perl or Ruby interpreter in all major distro.


My choice would go for Python 2 with a clear path to migrate to Python 3 
when needed (in 1 year)


Aur?lien



Le 24/10/2012 10:44, Roman Grigoryev a ?crit :
> Hi Kilian,
>
> if you want I could try to explain why not bash from my point of view.
>
> I agree that bash is language which could be used for test frameworks
> and test-framework.sh prove it. But some
> bash feature make current framework support pretty hard. For example, I
> don't see good way to  use  bash unit tests for test-framework.sh
>
> More structured requests:
>
> 1) Language features. Perl/Python/Java has many features which allows
> simple write complex logic (OOP,AOP and so on)
> 2) Pretty wide set of libraries.
> 3) powerful and useful unit test frameworks.
> 4) support tools, e.g. inline documentation, schema generator based on
> code, coverage collectiors, copyright checkers
>
> Ubuntu is building by Intel
> (http://build.whamcloud.com/job/lustre-b2_3/), so looks like it is
> important platform.
>
> Thanks,
>      Roman
>> Hi Roman,
>>
>> On Wed, Oct 24, 2012 at 8:31 AM, Roman Grigoryev
>> <roman_grigoryev@xyratex.com>  wrote:
>>> RH5 has only python2.4, SL61  has python2.4 and python2.6, and looks like
>>> only last Fedora will have python3.
>> I agree that inter-version compatibility could be a problem with
>> Python. But to take this argument literally, the best way to avoid
>> compatibility issues is to use the widest-spread and most version
>> consistent language across supported distributions, ie. bash.
>>
>>> In same time, Ubuntu says that from next
>>> release want to have only Python 3.
>> Since only RHEL, CentOS and SLES are supported, should we really care
>> about python versions in Ubuntu?
>> When installing Lustre in Ubuntu, users already have to do their own
>> packaging, so I'm not sure that having to install a specific version
>> of a scripting language would make much of a difference.
>>
>>> Now Lustre tests compatibility for wide set of system is solved by shell and
>>> standard utilities. Perl also has great
>>> compatibility history, many scripts could work on latest version as 10 years
>>> ago. It is reason why I see Perl as
>>> good decision.
>> So what's wrong with bash again? If it's just "too flexible, easy to
>> abuse", I'm afraid there's little in Perl to prevent falling into the
>> same pitfalls. :)
>>
>> Cheers,
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

[Lustre-devel] [lustre-devel] Language choice for Lustre tests

[Christopher J. Morrone]

We can pick a completely new language so no gets their current favorite. 
  I nominate go (http://golang.org/).  :)

On 10/24/2012 09:30 AM, DEGREMONT Aurelien wrote:
> Hello
>
> I've developed in Perl and Python for several years in both languages. I
> enjoyed both.
> Regarding starting a new project, for testing framework, here is several
> points which are the key points for choosing the right language.
>
> - Longevity
>
> Perl as a long history behind it, is available in all distros, that's
> true. But Perl is there for compatibility for running projects which
> were starting a long time ago. Nobody is starting a really big and fancy
> project in Perl nowadays. All new hackers are only speaking of Python or
> Ruby. You will not attract contributors with Perl. Perl 5 is very
> compatible because no new changes is really added to this language.
> And do not tell me that Perl 6 is coming. If Perl 6 is an option, then
> there is no issue with Python 3 and forget your compatibility.
>
> - Compat
>
> Developping in Python, for a large number of environment means coding
> for Python 2.4+. This will run nicely on Python up to 2.7
> As long as only Python 2 only is concerned, compat for Python is fine.
> But I agree that Python 3 is coming, and at long term, it should be
> taken in account even if no major distro is using it right now.
> (No Python 3 before RHEL7 or next Ubuntu LTS (14.04))
>
> -Lustre is for system people
>
> Lustre is developped by system guys, which mainly use vim or emacs to
> develop in Lustre. Very few of them are using IDE or stuff like Maven.
> Population developing Java with Maven is the exact opposite of guys
> coding in C, for Kernel code. Moreover, JVM are awful to install
> regarding a standard Python, Perl or Ruby interpreter in all major distro.
>
>
> My choice would go for Python 2 with a clear path to migrate to Python 3
> when needed (in 1 year)
>
>
> Aur?lien
>
>
>
> Le 24/10/2012 10:44, Roman Grigoryev a ?crit :
>> Hi Kilian,
>>
>> if you want I could try to explain why not bash from my point of view.
>>
>> I agree that bash is language which could be used for test frameworks
>> and test-framework.sh prove it. But some
>> bash feature make current framework support pretty hard. For example, I
>> don't see good way to  use  bash unit tests for test-framework.sh
>>
>> More structured requests:
>>
>> 1) Language features. Perl/Python/Java has many features which allows
>> simple write complex logic (OOP,AOP and so on)
>> 2) Pretty wide set of libraries.
>> 3) powerful and useful unit test frameworks.
>> 4) support tools, e.g. inline documentation, schema generator based on
>> code, coverage collectiors, copyright checkers
>>
>> Ubuntu is building by Intel
>> (http://build.whamcloud.com/job/lustre-b2_3/), so looks like it is
>> important platform.
>>
>> Thanks,
>>      Roman
>>> Hi Roman,
>>>
>>> On Wed, Oct 24, 2012 at 8:31 AM, Roman Grigoryev
>>> <roman_grigoryev@xyratex.com>  wrote:
>>>> RH5 has only python2.4, SL61  has python2.4 and python2.6, and looks
>>>> like
>>>> only last Fedora will have python3.
>>> I agree that inter-version compatibility could be a problem with
>>> Python. But to take this argument literally, the best way to avoid
>>> compatibility issues is to use the widest-spread and most version
>>> consistent language across supported distributions, ie. bash.
>>>
>>>> In same time, Ubuntu says that from next
>>>> release want to have only Python 3.
>>> Since only RHEL, CentOS and SLES are supported, should we really care
>>> about python versions in Ubuntu?
>>> When installing Lustre in Ubuntu, users already have to do their own
>>> packaging, so I'm not sure that having to install a specific version
>>> of a scripting language would make much of a difference.
>>>
>>>> Now Lustre tests compatibility for wide set of system is solved by
>>>> shell and
>>>> standard utilities. Perl also has great
>>>> compatibility history, many scripts could work on latest version as
>>>> 10 years
>>>> ago. It is reason why I see Perl as
>>>> good decision.
>>> So what's wrong with bash again? If it's just "too flexible, easy to
>>> abuse", I'm afraid there's little in Perl to prevent falling into the
>>> same pitfalls. :)
>>>
>>> Cheers,
>> _______________________________________________
>> Lustre-devel mailing list
>> Lustre-devel at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/lustre-devel-opensfs.org
> .
>