[gentoo-science] Re: Scientific herd leadership

[gentoo-science] Re: Scientific herd leadership

[George Shapovalov]

Hi guys.

Sorry that I did not reply yesterday, I had a presentation to prepare for 
today :).

I actually moved to a new place already. I am in Switzerland at the moment 
(Geneva/Lausanne, anybody around?), starting a new postdoc position (somebody 
might remember my email to -core or -dev some time ago). I am getting back up 
to speed, however I am still in much flux and everything official takes soo 
long in Swiss :(. Pluss the stress of starting new work (and getting all the 
equipment together :))...

There are a few points to address, so I'll structure my reply:

1. 
Anyway, as far as the leadership goes, I have been a lead of the sci herd ever 
since I created it (few eyars already, was that really that long ago? :)). 
Unfortunately things were rather quiet lately and, as I am not completely 
"on" yet, I am willing to give the leadership off to somebody who will have 
enough time on his hands. That, or at least I think we should have an active 
co-lead or may be even some more involved structure. Well, lets start with a 
co-lead first, so that we get at least somehting done :).

2. 
It would be good to have more devs involved in Scientific Gentoo. I can 
honestly say, that it surpassed my original expectations (it started out as a 
single category with a herd attached) and seems to have attained a status of 
an important project at the intersection of science and Linux. Looks like we 
have people recommending others to run Gentoo because of science apps we 
carry. Well, at least I saw few reports to that effect some time ago :).

I used to put out calls for new/interested devs to help Scientific Gentoo, 
when I was more active, and the responce was rather positive. However 
recently I did not have enough time to devote to training of new devs, so 
that slipped by. I think it would be usefull to reinstate that initiative, 
but first we need to get a head-count of who feels like doing the training. 
Should we have a 1 year as a dev  requirement for the trainers? (not the 
trainees of course! They are even better picked up from science than from 
Linux althogether :)) I would think so, given complexity of Gentoo nowadays 
and that last thing we want to do is to screw our comprehension by scientific 
community :).

3. Blas/lapack move.
Large part of it has been performed, new ebuild are in portage like for ages 
now. In fact so long, that I no longer feel we can just pick up from the 
point it was left at, but rather do another round of retesting (or even 
rethinking the concept) first. The part it staled at was to move all the 
dependant packages to a new blas/lapack system. I started adjusting some of 
the ebuilds a year or so ago, but I did not have that much time back then and 
did not want to step on the toyes of maintainers of these packages.
I'll try to check the situation with blas/lapack ebuilds soon and then issue 
another call for adjustments (for dependant packages). Can we please get 
those adjustment done this time? Pretty please ;).
Then (and only after that) the old versionf of blas/lapack will be masked and, 
eventually, removed. The bug tracing the status of blas/lapack move is 
#30453. Should we may be start a new, clean tracker bug? The mentioned one is 
pretty long, but it has a lot of essential info.

4.
I am for the regular meetings. It is probably good to try to settle on some 
time (may be easier if we go through with the "more involved unfrastructure", 
but the real need for it will only be there if we get 2x more devs than we 
have now (I mean in Scientific Gentoo)). However I agree, that reviving 
gentoo-science@lists.gentoo.org mailing list is a more realistic (and less 
stressful) option. In fact, everything is setup, lets just use it!
(To give an example, I am CC'ng this message to that list. Sorry for dups, if 
you receive it twice).

5. 
Anything else?

George
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[Olivier Fisette]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

On Thursday, 18 August 2005 05:52 am, George Shapovalov wrote:
> I used to put out calls for new/interested devs to help
> Scientific Gentoo, when I was more active, and the responce
> was rather positive. However recently I did not have enough
> time to devote to training of new devs, so that slipped by. I
> think it would be usefull to reinstate that initiative, but
> first we need to get a head-count of who feels like doing the
> training. Should we have a 1 year as a dev  requirement for
> the trainers? (not the trainees of course! They are even
> better picked up from science than from Linux althogether :))
> I would think so, given complexity of Gentoo nowadays and that
> last thing we want to do is to screw our comprehension by
> scientific community :).

Unless I am mistaken, any Gentoo developer is free to open a "New 
developer" bug for consideration by our recruiters team, as long 
as he is willing to mentor the recruit. I see no reason for the 
sci team to impose additional restrictions upon its members. I 
think we can trust the judgement of the mentoring dev on this.

I am ready to mentor a candidate. I have the necessary free time 
right now and will have it for a few months. I have already 
mentored someone once and found it a very rewarding experience.

Since everybody agrees that we need more hands, I asked 
recruiters to update the Staffing Needs on the gentoo.org Web 
site to reflect this.

Kind regards,

-- 
Olivier Fisette (ribosome)
Gentoo Linux Developer
Scientific applications, Developer relations

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-science] Re: Scientific herd leadership

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Fisette wrote:
| Unless I am mistaken, any Gentoo developer is free to open a "New
| developer" bug for consideration by our recruiters team, as long
| as he is willing to mentor the recruit. I see no reason for the
| sci team to impose additional restrictions upon its members. I
| think we can trust the judgement of the mentoring dev on this.

I wrote up a new mentoring guide recently [1]. The relevant part here is
that you need to be a dev for six months or be a project lead.

1. http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDBLFmXVaO67S1rtsRAvwpAJ9da8yzHPheL7/1CCHIJafGBlz40QCeM30f
90BLKzCpABhqg/4MnOaeVfM=
=I4yP
-----END PGP SIGNATURE-----
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[Jordan Dawe]

Olivier Fisette wrote:

>On Thursday, 18 August 2005 05:52 am, George Shapovalov wrote:
>  
>
>>I used to put out calls for new/interested devs to help
>>Scientific Gentoo, when I was more active, and the responce
>>was rather positive. However recently I did not have enough
>>time to devote to training of new devs, so that slipped by. I
>>think it would be usefull to reinstate that initiative, but
>>first we need to get a head-count of who feels like doing the
>>training. Should we have a 1 year as a dev  requirement for
>>the trainers? (not the trainees of course! They are even
>>better picked up from science than from Linux althogether :))
>>I would think so, given complexity of Gentoo nowadays and that
>>last thing we want to do is to screw our comprehension by
>>scientific community :).
>>    
>>
>
>Unless I am mistaken, any Gentoo developer is free to open a "New 
>developer" bug for consideration by our recruiters team, as long 
>as he is willing to mentor the recruit. I see no reason for the 
>sci team to impose additional restrictions upon its members. I 
>think we can trust the judgement of the mentoring dev on this.
>
>I am ready to mentor a candidate. I have the necessary free time 
>right now and will have it for a few months. I have already 
>mentored someone once and found it a very rewarding experience.
>
>Since everybody agrees that we need more hands, I asked 
>recruiters to update the Staffing Needs on the gentoo.org Web 
>site to reflect this.
>  
>
I'm interested in becoming a sci developer.  I've been using gentoo to 
do computational oceanography for a couple of years now, and it would be 
nice to know how the whole system works.  How do you sign up?  How much 
time would it demand?  The time might be a problem--I'm tyring to finish 
my PhD right now, but if there's too much to do, perhaps I could join up 
later...?

Jordan Dawe
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[Olivier Fisette]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

On Thursday, 18 August 2005 04:35 pm, Jordan Dawe wrote:
> I'm interested in becoming a sci developer.  I've been using
> gentoo to do computational oceanography for a couple of years
> now, and it would be nice to know how the whole system works. 
> How do you sign up?  How much time would it demand?  The time
> might be a problem--I'm tyring to finish my PhD right now, but
> if there's too much to do, perhaps I could join up later...?

I will continue this discussion off-list with Jordan, but here 
are a few remarks about what being a developer entails and how 
much time is necessary. By posting on this list, other 
developers can correct me and add their own opinion.

First of all, as George said, it is not necessary to be a 
Linux/UNIX guru to become a developer. Much more important is 
your interest in dedicating a bit of time every week to improve 
your favorite distribution. ;-) You do need to be reasonably 
familiar with the UNIX operating system and Gentoo Linux, 
though, and to be able to do some basic bash scripting.

Familiarity with one or more scientific packages already in 
Portage, and willfulness to maintain them up-to-date and 
bug-free would be a plus. We currently have no maintainer for 
important packages such as GNU Octave, Maxima or the Staden 
Package. A problem I have with scientific software is that I 
find it hard to test when it applies to a field I am not 
familiar with. This is probably the case with everybody in the 
sci herd. ;-)

Since we have time constraints ourselves, we understand potential 
recruits may only have a few hours during one day of the week to 
do Gentoo development, and that is Ok. However, if you don't 
think you will be able to dedicate at least an hour or two a 
week on average, I am not sure it would be profitable to invest 
time and efforts in the mentoring process.

As soon as a developer is ready to be your mentor, an official 
request to hire you may be opened. You will then go through a 
30-day evaluation period. During this time, you will learn about 
Gentoo's development policies, improve your knowledge of Gentoo 
(and the particulars of ebuild development for Portage), and 
contribute to the project. Your newly acquired abilities will 
then be tested by having you fill in quizzes (with the help of 
your mentor). Once the recruiters deem your work and your 
quizzes' answers satisfactory, you'll be part of the team. :-)

Kind regards,

-- 
Olivier Fisette (ribosome)
Gentoo Linux Developer
Scientific applications, Developer relations

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-science] Re: Scientific herd leadership

[M. Edward (Ed) Borasky]

Olivier Fisette wrote:

>Familiarity with one or more scientific packages already in 
>Portage, and willfulness to maintain them up-to-date and 
>bug-free would be a plus. We currently have no maintainer for 
>important packages such as GNU Octave, Maxima or the Staden 
>Package. A problem I have with scientific software is that I 
>find it hard to test when it applies to a field I am not 
>familiar with. This is probably the case with everybody in the 
>sci herd. ;-)
>  
>
Well ... I don't use Octave, but I am learning how to use Maxima. 
Maintaining the Maxima ebuild, on the other hand, is mostly knowing how 
to deal with the Common Lisp Controller and the four flavors of Lisp 
that will execute Maxima (most of the time -- check some of the bugs 
I've filed :). That's the stuff I don't know.

>Since we have time constraints ourselves, we understand potential 
>recruits may only have a few hours during one day of the week to 
>do Gentoo development, and that is Ok. However, if you don't 
>think you will be able to dedicate at least an hour or two a 
>week on average, I am not sure it would be profitable to invest 
>time and efforts in the mentoring process.
>  
>
I probably spend at least that much time *testing* open source software 
a week. Let's say half of Saturday for a start. But I test a variety of 
stuff, not just science packages.  How big of a leap is it from being a 
hard-core beta tester like myself to actually maintaining a package?
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[Marcus D. Hanwell]

[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]

On Monday 22 August 2005 00:15, M. Edward (Ed) Borasky wrote:
> >Since we have time constraints ourselves, we understand potential
> >recruits may only have a few hours during one day of the week to
> >do Gentoo development, and that is Ok. However, if you don't
> >think you will be able to dedicate at least an hour or two a
> >week on average, I am not sure it would be profitable to invest
> >time and efforts in the mentoring process.
>
> I probably spend at least that much time *testing* open source software
> a week. Let's say half of Saturday for a start. But I test a variety of
> stuff, not just science packages.  How big of a leap is it from being a
> hard-core beta tester like myself to actually maintaining a package?

As Olivier said at least a few hours a week to dedicate to Gentoo would be 
enough, and it sounds as if you already do that. I myself do work in the 
scientific herd (mentored by Olivier) which was the herd I originally joined 
with, the AMD64 porting team, the KDE herd and the net-proxy herd. These are 
just the packages I tend to use a lot, or the areas I work in. Some I just 
maintain because I am a nice guy and find it interesting using new 
packages :)

The leap isn't too great from building betas, being involved upstream and 
keeping up with releases/bug hunting to becoming a developer. You need a good 
background in bash scripting, ebuild writing and the tools used to author 
ebuilds. You also need to prove a certain level of knowledge before you 
become a full developer - please take a look at 
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml and 
http://dev.gentoo.org/~plasmaroo/devmanual/ for further details :)

I remember reading some of your bugs, and working through some R stuff with 
you previously. You don't have to limit yourself to just scientific 
applications if you become a developer.

One thing I hope to improve is communication with users and potential 
developers for the scientific herd. It would be nice to see a little more 
activity on the mailing lists and IRC! Freenode, #gentoo-science - there 
aren't many of us on there but we do idle on that channel amongst others.

Hope that answers a few of your questions - and if I got anything wrong I am 
sure some of the other developers will correct me ;)

Sincerely,

Marcus
-- 
Gentoo Linux Developer
Scientific Applications | AMD64 | KDE | net-proxy

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] Re: Scientific herd leadership

[C Y]

--- Olivier Fisette <ribosome@gentoo.org> wrote:

> Familiarity with one or more scientific packages already in 
> Portage, and willfulness to maintain them up-to-date and 
> bug-free would be a plus. We currently have no maintainer for 
> important packages such as GNU Octave, Maxima or the Staden 
> Package. A problem I have with scientific software is that I 
> find it hard to test when it applies to a field I am not 
> familiar with. This is probably the case with everybody in the 
> sci herd. ;-)

I have some familiarity with Maxima, in fact I was mixed up with the
original creation of that ebuild (although I was not responsible for
the last complex ebuild dependancy magic that finally made it work.)  I
have played a minor role in the development of Maxima itself (some
documentation work and bug finding, primarily).  I don't know nearly
enough about the details of ebuilds to offer comprehensive advice, but
I can say with confidence that the ebuilds for various lisps Maxima
uses are going to outpace the release schedule for Maxima, so either
someone needs to keep creating patches to Maxima or preserve the older
lisps with exact version dependancies for a static Maxima to keep
working.  If the better idea is judged to be patch from cvs as needed,
I would advise waiting for 5.9.2 before starting that, since there are
a LOT of patches since 5.9.1.  (As is, it would be simplier to just use
a cvs tarball instead.)

I would also advise that some more focus be turned on Axiom, which is a
competitor to Maxima and a very powerful program indeed - in some
respects it is unique among computer algebra systems.  It's design
lends some hope to the idea of systematically incorporating new
mathematical abilities into it, which is a big deal.  It retains deep
awareness of things like mathematical types, and unlike Maxima is much
more fully documented :-/.  A cvs ebuild exists and works, with some
edits of the final axiom script produced, but I would like to see a
stable one too.

Unfortunately, I have no significant familiarity with Octave's build
process, having used it only once or twice for minor applications.

> Since we have time constraints ourselves, we understand potential 
> recruits may only have a few hours during one day of the week to 
> do Gentoo development, and that is Ok. However, if you don't 
> think you will be able to dedicate at least an hour or two a 
> week on average, I am not sure it would be profitable to invest 
> time and efforts in the mentoring process.

Perhaps we could have a "support team" behind someone with official
Gentoo developer status - people could point out significant ebuilds
with most logic in place to the developer, help work out quirks in the
programs/ebuilds, and generally speed things up?  Certainly the
developer would bear final responsibility but this way those of us with
five hours every month or so could help out too, particularly for
specialty packages.  (BTY, if some genius could figure out brl-cad I
would be grateful - it's going to take me a year at this point :-/.)

There are a fair number of at least partial ebuilds for useful
scientific software stuck in bugzilla - brl-cad and acl2 come
immediately to mind, and I know there are others.  Plus a fair number
that don't have ebuilds where it would be useful to have them.  Gentoo
is alreay one of the best for scientific software, due to compiling
things being easy and our ebuild pool, but we could definitely do
better.

My machine is probably a poor test machine - what gentoo environment
would we need to maintain?

Cheers,
CY


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[Marcus D. Hanwell]

[-- Attachment #1: Type: text/plain, Size: 2755 bytes --]

On Monday 22 August 2005 08:48, C Y wrote:
> Perhaps we could have a "support team" behind someone with official
> Gentoo developer status - people could point out significant ebuilds
> with most logic in place to the developer, help work out quirks in the
> programs/ebuilds, and generally speed things up?  Certainly the
> developer would bear final responsibility but this way those of us with
> five hours every month or so could help out too, particularly for
> specialty packages.  (BTY, if some genius could figure out brl-cad I
> would be grateful - it's going to take me a year at this point :-/.)

I was wondering myself if some people in here might be receptive to the idea 
of a support team, much like the arch testers we have for the amd64 porting 
team. It often leads on to people becoming devs, but is a great way to help 
out when you can.

Tony Murray is filling that kind of role unofficially with all the work he 
puts into the boinc and setiathome ebuilds, whilst I review, test, improve 
and commit them once they are up to standard. I also have good contact with 
the quickplot developer who has integrated my patches upstream and helped 
significantly with the ebuilds for that package.

I think these relationships are important, and I personally nurture them as 
much as possible. Many scientific packages are very involved and having 
people help test and work out problems can significantly increase our 
efficiency as a team.
>
> There are a fair number of at least partial ebuilds for useful
> scientific software stuck in bugzilla - brl-cad and acl2 come
> immediately to mind, and I know there are others.  Plus a fair number
> that don't have ebuilds where it would be useful to have them.  Gentoo
> is alreay one of the best for scientific software, due to compiling
> things being easy and our ebuild pool, but we could definitely do
> better.

The problem comes down to manpower and a need to recruit some more people to 
the team. Having a support team similar to the arch testers could certainly 
help in our case if those people were not ready to become devs/didn't have 
the time. Once a package has been committed they would also need to help with 
version bumps and fixing bugs with the new packages ideally.
>
> My machine is probably a poor test machine - what gentoo environment
> would we need to maintain?

Just an up to date Gentoo install is fine. If you are testing some more 
experimental stuff (I test new baselayout, glibc, gcc and other core stuff 
sometimes) then a chroot might also be adviseable. Scientific apps just 
require an up to date system.

Thanks,

Marcus
-- 
Gentoo Linux Developer
Scientific Applications | AMD64 | KDE | net-proxy

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] Re: Scientific herd leadership

[M. Edward (Ed) Borasky]

Marcus D. Hanwell wrote:

>On Monday 22 August 2005 08:48, C Y wrote:
>  
>
>>Perhaps we could have a "support team" behind someone with official
>>Gentoo developer status - people could point out significant ebuilds
>>with most logic in place to the developer, help work out quirks in the
>>programs/ebuilds, and generally speed things up?  Certainly the
>>developer would bear final responsibility but this way those of us with
>>five hours every month or so could help out too, particularly for
>>specialty packages.  (BTY, if some genius could figure out brl-cad I
>>would be grateful - it's going to take me a year at this point :-/.)
>>    
>>
>
>I was wondering myself if some people in here might be receptive to the idea 
>of a support team, much like the arch testers we have for the amd64 porting 
>team. It often leads on to people becoming devs, but is a great way to help 
>out when you can.
>  
>
Yeah, it's a good idea -- my tastes are widely varying, though, 
including science and computer music, Ruby on Rails, and just learning 
in general. For myself, I'm probably closer to knowing what's "under the 
hood" in R than any other package; I've been using it since 1.1 or 
thereabouts. In the case of R, I beta test the upstream tarballs 
whenever I have the spare time. But the R ebuild itself isn't 
particularly tricky, nor is there a lot of work maintaining portability 
of it across the Gentoo-supported architectures. Their issues are the 
same as those of most open-source packages -- x86-64 and GCC 4. :)

In the end, we're all volunteers anyhow in this game. We do what we can 
when we can, as long as it's legal and ethical. So I'm going to keep 
spending at least four hours a week doing exactly what I'm doing now, 
whether or not I get some kind of "formal" status or "recognition" -- 
just the learning and having the quality software available when I need 
it is enough!

>Tony Murray is filling that kind of role unofficially with all the work he 
>puts into the boinc and setiathome ebuilds, whilst I review, test, improve 
>and commit them once they are up to standard. I also have good contact with 
>the quickplot developer who has integrated my patches upstream and helped 
>significantly with the ebuilds for that package.
>
>I think these relationships are important, and I personally nurture them as 
>much as possible. Many scientific packages are very involved and having 
>people help test and work out problems can significantly increase our 
>efficiency as a team.
>  
>
It's also important to have lines of communication/liasons with the 
upstream package developers. Since most of Gentoo is built from source, 
it could take as little as a few hours for an upstream release to make 
it into Portage unstable/testing and onto a Gentoo user's system. Good 
news and bad news can travel at the same speed. :) In my case, I've been 
the "user" in the development chain of TeXmacs and Common Music. There's 
no way on Earth I could have done that in Fedora or even Debian. 
(Actually, in the case of TeXmacs, I did try to file a bug in Debian on 
the TeXmacs/R bug I found, but never did figure out their bug filing 
system. And those folks at TeXmacs never *have* fixed the bug, either! :( )

-- 
M. Edward (Ed) Borasky

http://www.borasky-research.net/
http://borasky-research.blogspot.com/

http://pdxneurosemantics.com
http://pdx-sales-coach.com
http://algocompsynth.com

-- 
gentoo-science@gentoo.org mailing list

[gentoo-science] unsubscribe

[John Tee]

Marcus D. Hanwell wrote:
> On Monday 22 August 2005 08:48, C Y wrote:
> 
>>Perhaps we could have a "support team" behind someone with official
>>Gentoo developer status - people could point out significant ebuilds
>>with most logic in place to the developer, help work out quirks in the
>>programs/ebuilds, and generally speed things up?  Certainly the
>>developer would bear final responsibility but this way those of us with
>>five hours every month or so could help out too, particularly for
>>specialty packages.  (BTY, if some genius could figure out brl-cad I
>>would be grateful - it's going to take me a year at this point :-/.)
> 
> 
> I was wondering myself if some people in here might be receptive to the idea 
> of a support team, much like the arch testers we have for the amd64 porting 
> team. It often leads on to people becoming devs, but is a great way to help 
> out when you can.
> 
> Tony Murray is filling that kind of role unofficially with all the work he 
> puts into the boinc and setiathome ebuilds, whilst I review, test, improve 
> and commit them once they are up to standard. I also have good contact with 
> the quickplot developer who has integrated my patches upstream and helped 
> significantly with the ebuilds for that package.
> 
> I think these relationships are important, and I personally nurture them as 
> much as possible. Many scientific packages are very involved and having 
> people help test and work out problems can significantly increase our 
> efficiency as a team.
> 
>>There are a fair number of at least partial ebuilds for useful
>>scientific software stuck in bugzilla - brl-cad and acl2 come
>>immediately to mind, and I know there are others.  Plus a fair number
>>that don't have ebuilds where it would be useful to have them.  Gentoo
>>is alreay one of the best for scientific software, due to compiling
>>things being easy and our ebuild pool, but we could definitely do
>>better.
> 
> 
> The problem comes down to manpower and a need to recruit some more people to 
> the team. Having a support team similar to the arch testers could certainly 
> help in our case if those people were not ready to become devs/didn't have 
> the time. Once a package has been committed they would also need to help with 
> version bumps and fixing bugs with the new packages ideally.
> 
>>My machine is probably a poor test machine - what gentoo environment
>>would we need to maintain?
> 
> 
> Just an up to date Gentoo install is fine. If you are testing some more 
> experimental stuff (I test new baselayout, glibc, gcc and other core stuff 
> sometimes) then a chroot might also be adviseable. Scientific apps just 
> require an up to date system.
> 
> Thanks,
> 
> Marcus

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] unsubscribe

[Patrick Kursawe]

- please have a look at the headers for unsubscribe information.
- please don't write unsubscribe requests to the list.
- please don't quote the full text when you just want to unsubscribe.

Thanks,

Patrick	
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[M. Edward (Ed) Borasky]

C Y wrote:

>I have some familiarity with Maxima, in fact I was mixed up with the
>original creation of that ebuild (although I was not responsible for
>the last complex ebuild dependancy magic that finally made it work.)  I
>have played a minor role in the development of Maxima itself (some
>documentation work and bug finding, primarily).  I don't know nearly
>enough about the details of ebuilds to offer comprehensive advice, but
>I can say with confidence that the ebuilds for various lisps Maxima
>uses are going to outpace the release schedule for Maxima, so either
>someone needs to keep creating patches to Maxima or preserve the older
>lisps with exact version dependancies for a static Maxima to keep
>working.  If the better idea is judged to be patch from cvs as needed,
>I would advise waiting for 5.9.2 before starting that, since there are
>a LOT of patches since 5.9.1.  (As is, it would be simplier to just use
>a cvs tarball instead.)
>  
>
I used to be on the CMUCL and SBCL mailing lists because CMUCL is the 
best overall Lisp for my purposes and SBCL is the most actively 
developed. In addition to Maxima, I use Lisp for algorithmic 
composition, and right now CMUCL is the only one that fully supports 
Rick Taube's Common Music.

I guess the fact that there are four "competing" open source Lisps is a 
"problem", just as the fact that there are two competing open source 
"emacs" packages is a "problem". Still, I think the various 
compatibilities/standards/etc. between Maxima and the four 
currently-existing Lisps are best suited by the current mechanism ... 
they're all available in Portage in at least one "stable" form, however 
ancient that might be, and available in "testing" or "unstable" for us 
amateur beta testers. I don't have a problem joining mailing lists for 
packages I use and filing bug reports upstream -- ask the Texmacs, R, or 
Common Music and SBCL folks about that. :)

Gentoo is about choice, right? If the choice, however, must be where to 
allocate finite (or in some cases zero) volunteer developer/maintainer 
time, I'd cast my vote for CMUCL as the Lisp of choice, at least until 
SBCL hits 1.0 and gets the callback thing worked out for Common Music. 
GCL is a tad faster on some benchmarks, and CLISP has "readline" built in.

>I would also advise that some more focus be turned on Axiom, which is a
>competitor to Maxima and a very powerful program indeed - in some
>respects it is unique among computer algebra systems.  It's design
>lends some hope to the idea of systematically incorporating new
>mathematical abilities into it, which is a big deal.  It retains deep
>awareness of things like mathematical types, and unlike Maxima is much
>more fully documented :-/.  A cvs ebuild exists and works, with some
>edits of the final axiom script produced, but I would like to see a
>stable one too.
>  
>
I'm not sure there's a "stable" Axiom in the minds of the upstream 
people just yet. I had Axiom on my Debian systems when I was running 
Debian but never had a chance to play with it. It takes several hours to 
build from source on a fast machine. I've forgotten what the core symbol 
crunching engine is -- IIRC it carries an older version of one of the 
four open-source Lisps. In any event, I'll join the chorus of "let's 
have as much support for Axiom as we can."

>Unfortunately, I have no significant familiarity with Octave's build
>process, having used it only once or twice for minor applications.
>  
>
A few years ago at my "day job", I had the opportunity to pick an open 
source numerical package to embed in some computer performance 
monitoring and analysis code. At the time, we were doing the analysis 
off line in Excel and Minitab, because they were cheaper. Most of the 
"glue code" and data collection was written in Perl, so I considered 
Perl Data Language (PDL) at first. One of the factors was that the codes 
needed to be available in Red Hat RPM form, preferably from the Red Hat 
distribution CDs. That pretty much reduced the contestants to Octave, 
Lisp-Stat and R, which were available on the Red Hat "professional" 
workstation" CDs.

I did look at Octave, but the two front runners were Luke Tierney's 
Lisp-Stat and R. Lisp-Stat seemed to be frozen in time, and Tierney 
himself was working on the R team. R won, hands down, and it's only 
gotten better since then. Despite the fact that R (formerly known as GNU 
S) is primarily used for high-end statistical processing, the underlying 
numerical core and R language are elegant, powerful, extremely well 
documented and I think *much* more vibrant and alive than GNU Octave.

Again, if the choice is where to allocate limited resources, I'd say 
Octave (and Lisp-Stat) can be left alone and the focus put on R. If 
someone wants to get ambitious, they could Gentoo-ize the CRAN and 
Bioconductor package management systems. Dirk Eddelbuettel does this (by 
hand!) for Debian and it's a thankless job. Even without that, Gentoo is 
the best scientific workstation around.

>Perhaps we could have a "support team" behind someone with official
>Gentoo developer status - people could point out significant ebuilds
>with most logic in place to the developer, help work out quirks in the
>programs/ebuilds, and generally speed things up?  Certainly the
>developer would bear final responsibility but this way those of us with
>five hours every month or so could help out too, particularly for
>specialty packages.  (BTY, if some genius could figure out brl-cad I
>would be grateful - it's going to take me a year at this point :-/.)
>  
>
I think we have that now ... anyone can join the mailing list and the 
Bugzilla site and do whatever they can. I do this because I enjoy 
learning new stuff -- like R, Maxima, Axiom, Common Music and soon, Ruby 
and Ruby on Rails. Other folks are doing this for Xen, etc. We get a 
world-class workstation out of it (at least those of us who can afford 
an x86-64 :) ) for not a whole lot of money or even time.

>There are a fair number of at least partial ebuilds for useful
>scientific software stuck in bugzilla - brl-cad and acl2 come
>immediately to mind, and I know there are others.  Plus a fair number
>that don't have ebuilds where it would be useful to have them.  Gentoo
>is alreay one of the best for scientific software, due to compiling
>things being easy and our ebuild pool, but we could definitely do
>better.
>  
>
I don't know what brl-cad and acl2 are/do, so I can't help you there. 
Where *I* would focus "gentoo-science" -- indeed, all of Gentoo -- is on 
packages that are vibrant, alive and even chaotic upstream. Right now, 
that's R, Maxima, SBCL, Axiom, Ruby/Rails, Xen, TeXmacs, NS/NAM, etc. 
... the stuff that's on *my* hard drive. :)

>My machine is probably a poor test machine - what gentoo environment
>would we need to maintain?
>
Someday real soon now I'll buy an x86-64, but that's clearly the 
"vibrant, alice and even chaotic choice".

-- 
M. Edward (Ed) Borasky

http://www.borasky-research.net/
http://borasky-research.blogspot.com/

http://pdxneurosemantics.com
http://pdx-sales-coach.com
http://algocompsynth.com

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[C Y]

--- "M. Edward (Ed) Borasky" <znmeb@cesmail.net> wrote:

> I used to be on the CMUCL and SBCL mailing lists because CMUCL is
> tge best overall Lisp for my purposes and SBCL is the most actively 
> developed. In addition to Maxima, I use Lisp for algorithmic 
> composition, and right now CMUCL is the only one that fully supports 
> Rick Taube's Common Music.

Cool!  I didn't know Common Music was in active use.  I should look at
that more carefully.

> I guess the fact that there are four "competing" open source Lisps 
> is a "problem", just as the fact that there are two competing open
> source  "emacs" packages is a "problem". Still, I think the various 
> compatibilities/standards/etc. between Maxima and the four 
> currently-existing Lisps are best suited by the current mechanism ...

I guess it's a problem, but I like that there are so many different
environments experimenting with different things.  The biggest fly in
the ointment right now is ANSI compatibility (*cough*gcl*cough*) - once
an ANSI platform can be depended on on all 4 then people can start
stretching the various features available on each, and maybe evolve
what will become ANSI Common Lisp 2.0 :-)  Maxima being able to run on
all of them gives us a) a check that the underlying lisp isn't doing
unexpected things to results b) assurance that if one lisp dies we have
no trouble continuing on c) a good excuse to install lots of lisps ;-)
and d) an extra way to shake bugs out of our code (not that we need any
help right now, granted...)

> they're all available in Portage in at least one "stable" form,
> however ancient that might be, and available in "testing" 
> or "unstable" for us amateur beta testers. I don't have a problem 
> joining mailing lists for packages I use and filing bug reports 
> upstream -- ask the Texmacs, R, or Common Music and SBCL folks 
> about that. :)

My main complaint is that, in many cases, the newer release of the
lisp/CAS/scientific program in general is likely to contain many fixes,
and in fact be more desirable to use generally than the older version. 
In fact, keeping the older, incorrect version around is an active
disservice to people using it thinking it's correct.  Perhaps in the
case of the various lisps I can see waiting a bit (except for gcl ;-)
but in the case of Maxima, when we DO put out a new release there tend
to be fixes for mathematically incorrect behavior and other things that
make no sense to wait on.  It is improbable that Maxima will regress
between versions - there's too much room for improvement.  I would
expect the same would hold for Axiom.  Even if there WERE regression,
it might not be caught for quite some time, since exercising the
capabilities of a CAS is not trivial in and of itself.

> Gentoo is about choice, right? If the choice, however, must be 
> where to allocate finite (or in some cases zero) volunteer
> developer/maintainer  time, I'd cast my vote for CMUCL as the Lisp 
> of choice, at least until SBCL hits 1.0 and gets the callback thing 
> worked out for Common Music.

I would tend to agree, except I don't know how CMUCL does on non-x86
platforms.  Clisp at least tends to run on ANYTHING, despite it's not
being the performance choice.  IIRC that's why Clisp was originally set
as the no-choice-given default for Maxima, although that may have
changed since.
 
> GCL is a tad faster on some benchmarks, and CLISP has "readline"
> built in.

GCL can use readline too, at this point - not sure if it's in the
ebuild by default.

Oh, I recommend rlwrap for cmucl, by the way - assuming one is being
foolish like me and not using SLIME ;-).  Must learn SLIME, must learn
SLIME...

> I'm not sure there's a "stable" Axiom in the minds of the upstream 
> people just yet. 

Hmm, good question.

> I had Axiom on my Debian systems when I was running Debian but
> never had a chance to play with it. It takes several hours to 
> build from source on a fast machine.

Yep - reminds me of acl2's build, or to a lesser extent brl-cad's :-). 
All the good stuff takes forever to build ;-).

> I've forgotten what the core symbol crunching engine is -- IIRC it 
> carries an older version of one of the four open-source Lisps.

GCL, although of late they have been staying relatively current.

> In any event, I'll join the chorus of "let's have as much support 
> for Axiom as we can."

:-)

[snip - interesting about Octave vs. R - maybe the Octave interface
should be bolted onto the R core!]
 
> I don't know what brl-cad and acl2 are/do, so I can't help you there.

Acl2 is...  well, here's their own description:

"ACL2 is both a programming language in which you can model computer
systems and a tool to help you prove properties of those models." 

http://www.cs.utexas.edu/users/moore/acl2/

Here's one of its more famous uses:

"Remember the Intel FDIV bug? The first Pentium [trademark, Intel, Inc]
could not divide floating-point numbers correctly and it reportedly
cost Intel $500 million to fix. At the time that was happening, we used
ACL2 to verify that the floating point division microcode on AMD's
competing microprocessor, the AMD-K5, was correct. AMD used ACL2 to
verify the elementary floating-point operations for the recently
released Athlon."
 
This and HOL4 would be my first two candidates for proof systems to
create ebuilds for.  I took the bugzilla one for 2.8 and tried it on
2.9 (the current version) - it seemed to build successfully, although
I've not done any fancy testing with it yet.

BRL-CAD (http://brlcad.org/) 
BRL stands for Ballistic Research Laboratory - this is  a powerful
constructive solid geometry (CSG) modeling package used by the army for
decades to do real world simulation.  It was recently released as open
source software, and it has the potential to plug a major gap in the
lineup of open source software solutions.  Unfortunately, it's history
is so long that it predates Linux and the library naming conventions
that go with it, and uses tweaked versions of other standard libraries.
 The result is that an improper install will wreck havock on an
unsuspecting Gentoo box :-/.  I ultimately had to reinstall.  What it
needs is to have all relevant libraries in their own directory (say
/usr/lib/brlcad/) and go from there, but I don't know how to make an
ebuild that a) builds it with those targets and b) updates the system
correctly so brl-cad doesn't try to use the wrong libraries (e.g. in
/usr/lib) or not know about the ones in /usr/lib/brlcad.

I'm a bit like you - I love to tinker.  The odds I'll do any serious
CAD work with BRL-CAD are remote, but I like the idea of it being
available in case I DO hit something that makes it necessary/worthwhile
to put in the time.  So if you've got the itch, I recommend BRL-CAD
:-).  (incidently, the main interaction environment is not called
brlcad - it's something I forget at the moment.  But if typing brlcad
doesn't do anything it's not unexpected.)

> Where *I* would focus "gentoo-science" -- indeed, all of Gentoo -- 
> is on packages that are vibrant, alive and even chaotic upstream.
> Right now, that's R, Maxima, SBCL, Axiom, Ruby/Rails, Xen, TeXmacs, 
> NS/NAM, etc.
> 
> ... the stuff that's on *my* hard drive. :)

You definitely want to check out BRL-CAD - it's still actively used by
quite a few people, IIRC.  The project lead is Sean Morrison - very
helpful guy.  Even if you don't do CAD, worth a look as a potential
assist to open source in general :-).  I always make sure I've got
Blender installed for the same reasons (or non-reasons :-P) even though
you can fit my artistic talent in the head of a pin :-/.

Cheers,
CY


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[Marcus D. Hanwell]

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

On Thursday 18 August 2005 10:52, George Shapovalov wrote:
> Hi guys.
>
> Sorry that I did not reply yesterday, I had a presentation to prepare for
> today :).
>
> I actually moved to a new place already. I am in Switzerland at the moment
> (Geneva/Lausanne, anybody around?), starting a new postdoc position
> (somebody might remember my email to -core or -dev some time ago). I am
> getting back up to speed, however I am still in much flux and everything
> official takes soo long in Swiss :(. Pluss the stress of starting new work
> (and getting all the equipment together :))...

It is great to hear that from you, and that you are still active. I heard you 
were moving around and we figured that may be you didn't have time right now. 
I hope the new position goes well.
>
> There are a few points to address, so I'll structure my reply:
>
> 1.
> Anyway, as far as the leadership goes, I have been a lead of the sci herd
> ever since I created it (few eyars already, was that really that long ago?
> :)). Unfortunately things were rather quiet lately and, as I am not
> completely "on" yet, I am willing to give the leadership off to somebody
> who will have enough time on his hands. That, or at least I think we should
> have an active co-lead or may be even some more involved structure. Well,
> lets start with a co-lead first, so that we get at least somehting done :).

If you are still around and still want to be involved with the scientific herd 
then I for one think you should maintain leadership of the herd, but I would 
be glad to help out as co-lead or whatever people feel is appropriate to try 
and get things moving a little faster in the scientific herd. We have closed 
out quite a few bugs over the last few days already :)
>
> 2.
> It would be good to have more devs involved in Scientific Gentoo. I can
> honestly say, that it surpassed my original expectations (it started out as
> a single category with a herd attached) and seems to have attained a status
> of an important project at the intersection of science and Linux. Looks
> like we have people recommending others to run Gentoo because of science
> apps we carry. Well, at least I saw few reports to that effect some time
> ago :).
>
> I used to put out calls for new/interested devs to help Scientific Gentoo,
> when I was more active, and the responce was rather positive. However
> recently I did not have enough time to devote to training of new devs, so
> that slipped by. I think it would be usefull to reinstate that initiative,
> but first we need to get a head-count of who feels like doing the training.
> Should we have a 1 year as a dev  requirement for the trainers? (not the
> trainees of course! They are even better picked up from science than from
> Linux althogether :)) I would think so, given complexity of Gentoo nowadays
> and that last thing we want to do is to screw our comprehension by
> scientific community :).

I agree with Olivier that 6 months in line with official policy seems 
adequate, and see no reason for us to impose additional limits. I should have 
time to mentor a suitable candidate unless you want to place the 12 month 
requirement (in which case I have only been an official dev for 9 months or 
so).
>
> 4.
> I am for the regular meetings. It is probably good to try to settle on some
> time (may be easier if we go through with the "more involved
> unfrastructure", but the real need for it will only be there if we get 2x
> more devs than we have now (I mean in Scientific Gentoo)). However I agree,
> that reviving gentoo-science@lists.gentoo.org mailing list is a more
> realistic (and less stressful) option. In fact, everything is setup, lets
> just use it! (To give an example, I am CC'ng this message to that list.
> Sorry for dups, if you receive it twice).

We could try and figure a time, announce it on here and open the 
#gentoo-science channel up to all interested developers and users for 
discussion. These discussions could also take place on the lists, and if 
enough people turn up IRC logs could be posted here too.
>
> 5.
> Anything else?

I think you covered everything - it is good to hear you are still around! I 
hope everything is going well.

Sincerely,

Marcus
-- 
Gentoo Linux Developer
Scientific Applications | AMD64 | KDE | net-proxy

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]