[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sshfs
- To: petsc-dev@xxxxxxxxxxx
- Subject: sshfs
- From: Ethan Coon <etc2103@xxxxxxxxxxxx>
- Date: Thu, 03 Apr 2008 09:39:09 -0400
- In-reply-to: <37604ab40803170827g5b4e191n65e2547081dce970@mail.gmail.com>
- References: <E9103C03-5EB9-406C-AA6E-AA918A30C2D4@mcs.anl.gov> <a9f269830803170823v8961bcdoa9d33adc3eb76ca2@mail.gmail.com> <37604ab40803170827g5b4e191n65e2547081dce970@mail.gmail.com>
- Reply-to: petsc-dev@xxxxxxxxxxx
- Sender: owner-petsc-dev@xxxxxxxxxxx
hey Aron,
Is there a good (preferably non-fink) version of sshfs/fuse for mac? I
saw a few options... MacFuse, http://www.pqrs.org/tekezo/macosx/sshfs/
etc
any thoughts?
ethan
On Mon, 2008-03-17 at 11:27 -0400, Aron Ahmadia wrote:
> Can the namespace issue be fixed with some macro magic?
>
> #ifdef UNIQUE_PETSC_NAMESPACE
> #define Mat PetscMat
> #endif
>
> ...
> ...
>
> #undef Mat
>
> This seems like it would satisfy both parties, and a compiler/build
> flag could uniqueify the namespace if needed.
>
> ~A
>
> On Mon, Mar 17, 2008 at 11:23 AM, Matthew Knepley <knepley@xxxxxxxxx> wrote:
> > On Sun, Mar 16, 2008 at 7:38 PM, Barry Smith <bsmith@xxxxxxxxxxx> wrote:
> > >
> > >
> > > There are two significant changes I'd like to see before the
> > > next PETSc release:
> > >
> > > 1) remove the overly complicated (from a user perspective) matrix
> > > subclassing for the various external
> > > matrix solver packages and replace with MatSolverSetType() -
> > > mat_solver_type <type> that simply
> > > flips the various factorization/solver functions with those
> > > requested and
> >
> > This seems not too hard. Just a layer on top to run the code a user must
> > run now.
> >
> >
> > > 2) properly name-space PETSc by putting a Petsc in front of all PETSc
> > > objects, function names etc
> > > (this will require changing a few names also to keep them below
> > > the 32 character limit). This will
> > > be very painful change for some users who are not comfortable
> > > ever changing code, hence I hesitate
> > > to do it, but it is the right thing to do and should have been
> > > done originally.
> >
> > I guess I still do not see the need for this. NIMROD is a not a sufficient
> > driver in my mind. If we really want namespaces, use a real language that
> > has namespaces. There are plenty. If we are still using C, I say we stick
> > with the old division. The imposition of this much pain on the overwhelming
> > majority of users seems unjustified.
> >
> > Namespaces issues can be trivially fixed in say C++, which we should do.
> >
> > Matt
> >
> >
> >
> > > Maybe we can do a release in around a couple of months, it would
> > > be 2.4
> > >
> > > Barry
> > >
> > >
> > >
> >
> >
> >
> > --
> > What most experimenters take for granted before they begin their
> > experiments is infinitely more interesting than any results to which
> > their experiments lead.
> > -- Norbert Wiener
> >
> >
>
--
-------------------------------------------
Ethan Coon
DOE CSGF - Graduate Student
Dept. Applied Physics & Applied Mathematics
Columbia University
212-854-0415
http://www.ldeo.columbia.edu/~ecoon/
-------------------------------------------