headers
Michele Mattioni | 7 Nov 2004 15:13
Picon
Favicon

install pdp++ software in gentoo-way

Hi to everybody, 
    anyone has installed the pdp++ software[1], for neural networks
research, on his/her gentoo-box?
There isn't an ebuild, and the software isn't in the portage-tree.
I've tried to install by the rpm-package provided in the site, and now,
according to the install file, I have to set in my 
LD_LIBRARY_PATH the directory where the program has all his library.
I've read that is not very safe to do it and, more over, I don't know
how to workaround this.
Any help will be appreciate.

[1] http://www.cnbc.cmu.edu/Resources/PDP++//PDP++.html 

--
gentoo-science <at> gentoo.org mailing list
Permalink | Reply | 0 comments |
headers
Donnie Berkholz | 8 Nov 2004 03:10
Picon
Favicon

[Fwd: [gentoo-dev] f77 is now just plain old fortran in preparation for gcc4]

Forwarding at the request of M. Edward Borasky.

-------- Forwarded Message --------
From: Travis Tilley <lv <at> gentoo.org>
To: gentoo-dev <at> lists.gentoo.org
Subject: [gentoo-dev] f77 is now just plain old fortran in preparation
for gcc4
Date: Sun, 07 Nov 2004 19:46:04 -0500
the fortran-enabling logic in the gcc ebuilds + toolchain.eclass will 
now be controlled by the fortran USE flag instead of f77. This is some 
very ahead-of-time preparation for gcc 4.0, which doesnt support f77 as 
a gcc lang, but instead supports f95 (and may soon change the gcc lang 
option to plain old fortran as well). I've updated all profiles to also 
set fortran in USE by default, but some non-gcc ebuilds still use f77 to 
enable support, so I havent removed f77 from these profiles.

This may or may not have been important enough to merit an announcement 
on gentoo-dev, but I've learned my lesson about making invasive changes 
without an announcement of some sort. ;p

by the way, if anyone's masochistic enough to play with gcc4, I have an 
ebuild in my devspace you could use:
http://dev.gentoo.org/~lv/gcc-4.0.0_alpha20041024.ebuild

I havent yet updated it with the needed dependencies for enabling 
fortran95, or any other such nonsense... it was made just to test which 
ebuilds no longer compile with the yet-again-stricter gcc 4.0. have fun 
breaking your systems ;p

Travis Tilley
(Continue reading)

Permalink | Reply | 0 comments |
headers
Travis Tilley | 8 Nov 2004 03:36
Picon
Favicon

Re: f77 is now just plain old fortran in preparation for gcc4

M. Edward Borasky wrote:
> 1. You might want to post this to "gentoo-science"; that's where most
> FORTRAN aficionados, like myself, hang out.

added to CC. for those of you who just tuned in, this thread started at:
http://article.gmane.org/gmane.linux.gentoo.devel/22747

> 2. How far "very ahead-of-time" are we talking here? I haven't heard
> anything about GCC 4.x on the R mailing lists, which is where I'd expect
> to see the most scrambling about and beta-testing.

my guess is slightly less than 2 months before the release branch is 
made. the stated goal for making a release branch is less than 100 
regressions, and there are currently about 200 targeted at 4.0. also 
objc++ support was supposed to be merged in before release, and that 
hasnt even happened yet... so i might be overly optimistic in that 
guesstimate.

i'm mainly working on gcc4 stuff now because it's even more strict than 
3.4 in regards to what it will and will not compile.

> 3. I think rather than going with your ebuild, I'll build the whole
> thing in a user-space account from virgin upstream downloads. The "whole
> thing" in this case would be GCC 4, a development release of the Atlas
> linear algebra library, and a development release of R and its packages.
> That way it's easier for me to figure out who's messed up without
> burdening Gentoo with upstream bugs.

sounds like a good idea :)
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Shapovalov | 8 Nov 2004 03:54
Picon
Favicon

should we call for help? (GWN)

Hi guys.

Looking at sheer success of the similar call for help for haskell herd (in two 
weeks something like 10-15 people responded and proposed their help) I am 
thinking that we should really put a bold notice in some coming GWN wrt 
Scientific Gentoo :). It would be nice to double the number of participants 
in this group (one can always dream :)), as ~10 developers is not nearly 
enough to even maintain 180 packages we have solely in app-sci. And I 
remember some more exciting projects discussed here at times :).

There is one catch though :). I have my thesis defence scheduled in one month 
and then its a lot of activity moving around. So, realistically speaking I 
will not be able to train people in a few coming month. However there may be 
some stuff we can let people do without cvs access and may be somebody will 
want to take a trainee or two :).

So, for now I would like to discuss:

1. what kind of help do we need, conceptually - maintaining ebuilds, testing 
fixes and new submissions, what else?

2. what categories or packages require more maintainership?

3. Who is willing to coach newcomers? How many people can we tak up right 
away, how many in a month or two?

4. anythoing else considered important or relevant.

George
(Continue reading)

Permalink | Reply | 2 comments |
headers
George Shapovalov | 8 Nov 2004 04:09
Picon
Favicon

app-sci is 180, split in order?

Hi guys.

I tried to count how many packages we already have in sci for that previous 
message (recruiting new devs) and realized we are at 180 solely in app-sci 
already. So, should we split this? I envision something along these lines:

sci-stat    statistics, data analysis
sci-simu    simulations, MD, Monte Carlo, etc.
sci-hpc     high performance computing, clustering
sci-libs    well, libs essentially
sci-misc    everything else

possible other if they warrant a separate category
sci-linalg    linear algebra packages, kind of covered by sci-libs for most
sci-symbolic  symbolic algebra stuff, again, does not seem to be that many of 
these so that hey wouldn't fit into sci-misc..

Some stuff may be moved from elsewhere. For example dev-lang/R may be better 
suited for sci-stat, as this is essentially data-analysis package (I know 
people look for it under app-sci when I tell them there is such a thing. And, 
btw, search does not quite work in that particular case, its just one latter 
which is also uppercase :)).

Would that be all or did I forget something? 5 categories would give us 35-40 
packages per cat, so there is even some room for expansion. There are ~100 
more packages fresh sitting in bugzilla, but I think we will only be able to 
realistically deal with them after we get some more devs onto sci herd (see 
my other todays message to gentoo-science).

George
(Continue reading)

Permalink | Reply | 28 comments |
headers
Donnie Berkholz | 8 Nov 2004 04:28
Picon
Favicon

Re: app-sci is 180, split in order?

(Please CC gentoo-dev, I forgot to send to both at once. "Reply to List"
is a killer.)

On Sun, 2004-11-07 at 19:09 -0800, George Shapovalov wrote:
> Hi guys.
> 
> I tried to count how many packages we already have in sci for that
previous 
> message (recruiting new devs) and realized we are at 180 solely in
app-sci 
> already. So, should we split this? I envision something along these
lines:
> 
> sci-stat    statistics, data analysis
> sci-simu    simulations, MD, Monte Carlo, etc.

How do you discriminate between this and the next one?

> sci-hpc     high performance computing, clustering

Probably sys-cluster for the lower-level stuff

> sci-libs    well, libs essentially

Sure, there's a bunch of stuff in various *-libs now that should
probably be in a sci* thing.

> sci-misc    everything else
Permalink | Reply | 1 comment |
headers
M. Edward Borasky | 8 Nov 2004 04:29
Favicon

Re: app-sci is 180, split in order?

On Sun, 2004-11-07 at 19:09, George Shapovalov wrote:

[snip]

> Some stuff may be moved from elsewhere. For example dev-lang/R may be better 
> suited for sci-stat, as this is essentially data-analysis package (I know 
> people look for it under app-sci when I tell them there is such a thing. And, 
> btw, search does not quite work in that particular case, its just one latter 
> which is also uppercase :)).
> 
> Would that be all or did I forget something? 5 categories would give us 35-40 
> packages per cat, so there is even some room for expansion. There are ~100 
> more packages fresh sitting in bugzilla, but I think we will only be able to 
> realistically deal with them after we get some more devs onto sci herd (see 
> my other todays message to gentoo-science).
> 
> George

Well ... I hate to say again, "Debian does it thusly" :). Debian has a
"science" and a "math" main category. R is in math, as are many of the
packages in "app-sci" -- octave, yacas and maxima, for example. So I
would put the "pure math" packages in one group and the scientific
applications in another. And yes, I'd move R into the math group and out
of the language group, even though it *is* a language. LISP is a
language, and all of the LISP interpreters/compilers are in "dev-lisp".

By the way, I wish I had the free time to join the "sci" herd. I just
have too many other irons in the fire to devote the kind of time to it
that it would require. I do spend a fair amount of time testing bleeding
edge software, so at least you'll get bug reports and info from upstream
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Grant | 8 Nov 2004 06:22

Re: app-sci is 180, split in order?

I have always had an objective to having stuff like qcad and pcb in 
app-sci.  "sci" to me implies "science" and pcb and qcad are NOT science.

Let's make an entirely separate engineering category, like app-eng or 
something.  Off the top of my head, we can also put all geda, spice, and 
the electric packages there.

Getting packages like these out of sci-* or app-sci would make me happy.

David

George Shapovalov wrote:

>Hi guys.
>
>I tried to count how many packages we already have in sci for that previous 
>message (recruiting new devs) and realized we are at 180 solely in app-sci 
>already. So, should we split this? I envision something along these lines:
>
>sci-stat    statistics, data analysis
>sci-simu    simulations, MD, Monte Carlo, etc.
>sci-hpc     high performance computing, clustering
>sci-libs    well, libs essentially
>sci-misc    everything else
>
>possible other if they warrant a separate category
>sci-linalg    linear algebra packages, kind of covered by sci-libs for most
>sci-symbolic  symbolic algebra stuff, again, does not seem to be that many of 
>these so that hey wouldn't fit into sci-misc..
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
George Shapovalov | 8 Nov 2004 03:31
Picon
Favicon

Re: app-sci is 180, split in order?

On Sunday 07 November 2004 19:28, Donnie Berkholz wrote:
> > sci-simu    simulations, MD, Monte Carlo, etc.
>
> How do you discriminate between this and the next one?
>
> > sci-hpc     high performance computing, clustering
For example gromacs. It does not really care about clustering (all is done 
through mpi libs) and it is a simulation rogram after all. Although you have 
a point, 
1. HPC is not that well defined
2. there may not be enough on one or another side to fill the category

> Probably sys-cluster for the lower-level stuff
Yea, I actually thought more along these lines when mentioning sci-hpc. So, 
what about 
sci-simu  and
sci-cluster

1. Can we get enough packages to do this split?
2. Shouldn't we simply concentrate all clustering stuff under sys-cluster. In 
other words, are there any "really scientific" clustering packages which 
won't work for generic clustering?

Looks like in the end it may be worth to sucrifice one of sci- categories in 
favor of eng, as was proposed elsewhere. Lets see if we get more comments and 
then try to rationalize it all :).

George

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus Luisser | 8 Nov 2004 09:28
Picon

Re: app-sci is 180, split in order?

Hi folks!

On Monday 08 November 2004 04:09, George Shapovalov wrote:
> [...]
> sci-stat    statistics, data analysis
> sci-simu    simulations, MD, Monte Carlo, etc.
> sci-hpc     high performance computing, clustering
> sci-libs    well, libs essentially
> sci-misc    everything else

I favor this splitting over the other proposals - though like Donnie
said:

>> sci-simu    simulations, MD, Monte Carlo, etc.
>
>How do you discriminate between this and the next one?
>
>> sci-hpc     high performance computing, clustering

Since i'm an engineer myself i wouldnt object having an engineering
section but i guess sci-misc is ok for that stuff. I dont think that its
a good idea to have a completely different math section, i'd keep those
packages inside the umbrella term category.

> Some stuff may be moved from elsewhere. For example dev-lang/R may be
> better suited for sci-stat, as this is essentially data-analysis package 

I have to agree to that since i fell into this pit :P

On Monday 08 November 2004 03:54, George Shapovalov wrote:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane