In article [EMAIL PROTECTED], Roman V. Shaposhnik [EMAIL PROTECTED] wrote:
ron minnich wrote:
more useless crap from memory:
the actual correct usage is
//GO.SYSIN DD *
but of course the * would make things messy.
See this and realize this stuff is still being taught!
Hi
On Wed, 2008-07-30 at 12:51 +0200, [EMAIL PROTECTED] wrote:
hello
Access to sources is anonymous since a couple of years (try 9fs sources),
Thanks!!! mount -n solved my issue 100%.
you only need an account if you're going to write in sources (contrib/). I
think if you want an account
On Wed, 2008-07-30 at 12:51 +0200, [EMAIL PROTECTED] wrote:
hello
Access to sources is anonymous since a couple of years (try 9fs sources)
Although, on a second though, if sources.cs.bell-labs.com doesn't
require authentication it probably should reply with Rerror
to a Tauth message. And it
On Tue, Jul 29, 2008 at 12:12:05PM -0700, Bakul Shah wrote:
It is slightly depressing to think that the situation has not really
changed since EWD wrote this in 1975. It will take some young
whippersnapper of a Dijkstra or Hoare or Strachey or Iverson or Backus
to find the critical insight
On Wed, 2008-07-30 at 13:35 +0200, [EMAIL PROTECTED] wrote:
On Tue, Jul 29, 2008 at 12:12:05PM -0700, Bakul Shah wrote:
It is slightly depressing to think that the situation has not really
changed since EWD wrote this in 1975. It will take some young
whippersnapper of a Dijkstra or
I think useful parallel programming paradigms can very probably be
abstracted from really big systems like a national health system or an
army. How parallelism is employed in those systems, would be a good
starting point for a deeper investigation.
Especially a military system must have some very
Although, on a second though, if sources.cs.bell-labs.com doesn't
require authentication it probably should reply with Rerror
to a Tauth message. And it doesn't:
term% aux/9pcon -n tcp!sources.cs.bell-labs.com
Tversion 8192 9P2000
- Tversion tag 65535 msize 8192 version
On Wed, Jul 30, 2008 at 4:35 AM, [EMAIL PROTECTED] wrote:
On Tue, Jul 29, 2008 at 12:12:05PM -0700, Bakul Shah wrote:
It is slightly depressing to think that the situation has not really
changed since EWD wrote this in 1975. It will take some young
whippersnapper of a Dijkstra or Hoare
On Wed, Jul 30, 2008 at 13:50, Roman V. Shaposhnik [EMAIL PROTECTED] wrote:
On Wed, 2008-07-30 at 13:35 +0200, [EMAIL PROTECTED] wrote:
The most efficient is to have tools that match the way our brains work
(or not...). I'm not convinced our brains are parallel (at least mines
are not).
I
Is the human thought process parallel? For _my capacities_, I have the
impression that I'm more multitask than parallel. And context switch is
expensive because there is not only explicit data, but also implicit and
I'm not able, if I'm really doing something involved, to restore the
previous
On Wed, Jul 30, 2008 at 7:32 AM, Roman V. Shaposhnik [EMAIL PROTECTED] wrote:
Do you have any bits and pieces of the software ecosystem not
readily available on Plan9 (dreadful things like a C++ compiler)
covered by these funds or is your intention to use available
Plan9 userland as-is?
In the HPC world, there is lots of conservatism. There is an editor at
LANL, named Fred, written in Fortran, that has been in use for longer
than most of you have been alive. Until very recently, it was a
required part of any HPC system.
So, we're doing a binary compatibility module so we can run
Hello,
Just a dumb question, as i'm totally out of this business, it is easier to
write an emulator than translate the applications to plan9 c ? (for example) or
to write (or port) the C++ and Fortran compilers and related tools?
i'm asking from a technical point of view, i suppose dealing
// Sources is a bit different: it doesn't require
// authentication, but it will accept it.
Is this just 'listen -N' in fossilcons(8)?
Given that listen and users are fossil-wide, rather
than fsys-wide, it seems like duplicating what
sources is doing at a normal Plan 9 installation
would involve
ron minnich wrote:
In the HPC world, there is lots of conservatism. There is an editor at
LANL, named Fred, written in Fortran, that has been in use for longer
than most of you have been alive. Until very recently, it was a
required part of any HPC system.
So, we're doing a binary compatibility
* Venkatesh Srinivas [EMAIL PROTECTED] wrote:
... redirecting back to 9fans ;-P
As far as interfaces go, mmap() is pretty tragic - the underlying
translation structures can express more interesting things, some of
which are even worth doing.
Well, the biggest problem, IMHO are the
On Wed, Jul 30, 2008 at 10:25 AM, [EMAIL PROTECTED] wrote:
i'm asking from a technical point of view, i suppose dealing with the current
users and customers is the real issue, right?
and tens of millions of lines of fortran that no one understands anymore
Its not that we aren't
On Wed, Jul 30, 2008 at 10:21 AM, Steven D. Vormwald [EMAIL PROTECTED] wrote:
So would developers on this platform be encouraged to use languages and
features currently in plan 9 for HPC development,
It is unlikely that existing features in Plan 9 scale applications (or
system services) to
On Wed, Jul 30, 2008 at 8:21 AM, Steven D. Vormwald [EMAIL PROTECTED] wrote:
So would developers on this platform be encouraged to use languages and
features currently in plan 9 for HPC development, or would they target
existing HPC languages and features, which would be added to plan 9,
On Wed, Jul 30, 2008 at 7:10 AM, ron minnich [EMAIL PROTECTED] wrote:
In the HPC world, there is lots of conservatism. There is an editor at
LANL, named Fred, written in Fortran, that has been in use for longer
than most of you have been alive. Until very recently, it was a
required part of
On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote:
Convenience is one point (sometimes be a big point), but another
important one is sharing. Without mmap(), an (real) shared library
support most likely will require special kernel support.
What aspect of shared libraries are you aching
On Wed, Jul 30, 2008 at 8:25 AM, [EMAIL PROTECTED] wrote:
Hello,
Just a dumb question, as i'm totally out of this business, it is easier to
write an emulator than translate the applications to plan9 c ? (for example)
or to write (or port) the C++ and Fortran compilers and related tools?
ron minnich wrote:
On Wed, Jul 30, 2008 at 8:21 AM, Steven D. Vormwald [EMAIL PROTECTED] wrote:
So would developers on this platform be encouraged to use languages and
features currently in plan 9 for HPC development, or would they target
existing HPC languages and features, which would be
On Wed, Jul 30, 2008 at 11:29 AM, Enrico Weigelt [EMAIL PROTECTED] wrote:
Convenience is one point (sometimes be a big point), but another
important one is sharing. Without mmap(), an (real) shared library
support most likely will require special kernel support.
Actually, almost any kernel
On Tue, 2008-07-29 at 12:28 -0400, Venkatesh Srinivas wrote:
As far as interfaces go, mmap() is pretty tragic - the underlying
translation structures can express more interesting things, some of
which are even worth doing.
I can't agree more. The way I look at it is that mmap() seems to
be the
Roman V. Shaposhnik wrote:
Personally, my
experience of trying to use mmap() as a useful abstraction for the
CPU's MMU was the last straw. It can't do even that reliably
and in a portable fashion. Not to digress, but I was even more surprised
to learn that there's not a single API on UNIX that
Joel C. Salomon wrote:
On Wed, Jul 30, 2008 at 11:29 AM, Enrico Weigelt [EMAIL PROTECTED] wrote:
Convenience is one point (sometimes be a big point), but another
important one is sharing. Without mmap(), an (real) shared library
support most likely will require special kernel support.
On Wed, Jul 30, 2008 at 08:50:28AM -0400, erik quanstrom wrote:
i don't see how csp is *not* parallel processing. as soon
as you have more than 1 work process per client, i would call
that parallel processing.
It's a kind of parallelism, of course. But since it makes sense, it is
not
1. rewrite apps in plan 9 c. The Plan 9 C compiler is fine for what we
do on Plan 9. For scientific apps, it's not that great a compiler. The
IBM compilers know all the tricks. The effort to get Plan 9 C up to
the standards of XLC is mind-boggling. And XLF? We're not going to
write a Fortran
What is XLC and where can I find more information on the standard?
XLC is IBM's POWER/PowerPC compiler. It produces great code, but is expensive.
So, does that mean that you guys have a version of XLC that can produce Plan 9
binaries, or are you using some other method to convert it's output?
ron minnich wrote:
On Wed, Jul 30, 2008 at 9:10 AM, Steven D. Vormwald [EMAIL PROTECTED] wrote:
Correct me if I'm wrong here, but don't these require extensive run-time
support, in addition to compiler support? Will the run-time libraries also
be linux libraries running under a compatibility
Can you elaborate here? What tricks can the IBM compilers use
that the Plan 9 ones can't? Are we talking optimization?
No, really, that's not troll bait. I'm actually interested in
understanding the project's basis for discriminating against
specific compiler capability. Obviously Plan 9's
On Wed, Jul 30, 2008 at 1:03 PM, don bailey [EMAIL PROTECTED] wrote:
Can you elaborate here? What tricks can the IBM compilers use
that the Plan 9 ones can't? Are we talking optimization?
No, really, that's not troll bait. I'm actually interested in
understanding the project's basis for
I disagree on philosophical grounds ;-) It's been one of the major
engineering follies to always approach design from a just follow
the nature standpoint. No wonder that before the Wright brothers
everybody thought the best way to fly is to flap some kind of wings.
off topic, but to note:
On Wed, Jul 30, 2008 at 11:03 AM, don bailey [EMAIL PROTECTED] wrote:
Can you elaborate here? What tricks can the IBM compilers use
that the Plan 9 ones can't? Are we talking optimization?
yes. Quite impressive optimization. Which results in very high
measured performance. At least when I've
Obviously Plan 9's compiler
isn't optimal.. but what really are the requirements people
really? that depends on your definition of optimal.
by my definition which heavily rates speed of compliation
and correctness, it's sure closer than the competition.
- erik
On Wed, Jul 30, 2008 at 8:36 AM, Eric Van Hensbergen [EMAIL PROTECTED]wrote:
On Wed, Jul 30, 2008 at 10:25 AM, [EMAIL PROTECTED] wrote:
i'm asking from a technical point of view, i suppose dealing with the
current users and customers is the real issue, right?
and tens of millions of
On Wed, Jul 30, 2008 at 4:36 PM, David Leimbach [EMAIL PROTECTED] wrote:
So is there any traction to use the new platform, or is it mostly just
people running their familiar apps and writing new apps for their familiar
programming environment?
There are always users who are adventurous. I'm
the mindset that everything is a Linux. Once you cross that Rubicon
life gets much easier.
only if it's the rubicon and not the styx.
☺
- erik
On Wed, Jul 30, 2008 at 12:25 PM, Joel C. Salomon
[EMAIL PROTECTED] wrote:
I forget who said it,
Found it in http://9fans.net/archive/2002/08/130:
On Tue, 13 Aug 2002 07:43:45 -0400, David Gordon Hogan [EMAIL PROTECTED]
wrote:
On freebsd and Linux, exec happens via an mmap (more or less).
On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach [EMAIL PROTECTED] wrote:
Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be
worth a ton to me in some situations.
Concurrent programming for the win?
probably not for this community. When we had plan9port in xcpu we got
41 matches
Mail list logo
