>It is a C/C++/Obj-C compiler & does static analysis, has
>backends for multiple processor types as well as C as a
>target, a lot of optimization tricks etc.
22mbytes is still a lot of "etc.". i've no objection
to optimisations big and small, but that still wouldn't explain
the size (to me). FORT
On Thu, 3 Feb 2011 08:35:53 +, Charles Forsyth wrote:
It is a C/C++/Obj-C compiler & does static analysis, has
backends for multiple processor types as well as C as a
target, a lot of optimization tricks etc.
... FORTRAN H Enhanced did so much with so little! ...
Is there a compiler that
FORTRAN H Enhanced was an early optimising compiler.
FORTRAN H for System/360, then FORTRAN H Extended for System/370;
FORTRAN H Enhanced added further insight to get better code.
> The finished version will support strings backed by file storage
string(2) doesn't go quite that far, but is used by the mailer upas
and perhaps other things to reduce the instances of arbitrarily low limits
and bounds exceeded.
On Thu, 3 Feb 2011 09:46:00 +, Charles Forsyth wrote:
FORTRAN H Enhanced was an early optimising compiler.
FORTRAN H for System/360, then FORTRAN H Extended for System/370;
FORTRAN H Enhanced added further insight to get better code.
Ah. Thanks for the info. I asked because some of the ph
On Thu, Feb 03, 2011 at 03:47:17AM -0600, EBo wrote:
>
> Ah. Thanks for the info. I asked because some of the physicists and
> atmospheric scientists I work with are likely to insist on having
> FORTRAN. I still have not figured how I will deal with that if at
> all.
>
If the cost can be met, p
On Feb 2, 9:11 pm, quans...@quanstro.net (erik quanstrom) wrote:
> On Wed Feb 2 05:04:07 EST 2011, nyanhtoo...@gmail.com wrote:
>
> > Hi, Running plan 9 on virtual box 4.0.2, I've configured network
> > adaptaters as below.
> > Attached to NAT
> > Adapter type: PCnet-FAST 3(Am79C973)
> > check cab
In article ,
erik quanstrom wrote:
>> Even C has a runtime. Perhaps you should look more into how programming
>> languages are implemented :-). C++ has one too, especially in the wake of
>> exceptions and such.
>
>really? what do you consider to be the c runtime?
>i don't think that the asm goo
> %: %.$O
> $LD $LDFLAGS -o $target $prereq
Not a good idea. '%' matches everything, not just files with no suffix.
> Ah. Thanks for the info. I asked because some of the physicists and
> atmospheric scientists I work with are likely to insist on having
> FORTRAN. I still have not figured how I will deal with that if at all.
it's not just the FORTRAN but supporting libraries, sometimes large ones,
including
On the other hand, can anyone explain this?
term% cat foo.mk
%: /dev/null
echo making $target
term% mk -f foo.mk x.y
echo making x.y
making x.y
term% mk -f foo.mk x.y z.w
echo making x.y
making x.y
echo making z.w
making z.w
echo making command line arguments
making command line argum
On Thursday, February 03, 2011 11:16:05 am Richard Miller wrote:
> > %: %.$O
> >
> > $LD $LDFLAGS -o $target $prereq
>
Perhaps wont' be a problem with mk(1), but make(1) had biten me more than once
with a rule like `-o $SOMEOUTPUT $SOMESOURCES'. When $SOMEOUTPUT was empty...
the sourc
On Thursday, February 03, 2011 11:24:53 am dexen wrote:
> On Thursday, February 03, 2011 11:16:05 am Richard Miller wrote:
> > > %: %.$O
> > >
> > > $LD $LDFLAGS -o $target $prereq
>
> Perhaps wont' be a problem with mk(1), but make(1) had biten me more than
> once with a rule like `-o $
On 3 February 2011 10:23, Richard Miller <9f...@hamnavoe.com> wrote:
> On the other hand, can anyone explain this?
> term% mk -f foo.mk x.y z.w
> echo making x.y
> making x.y
> echo making z.w
> making z.w
> echo making command line arguments
> making command line arguments
> term%
yes, it's becau
On Thu, Feb 03, 2011 at 10:37:39AM +, roger peppe wrote:
>
> you're not supposed to have a metarule with a target
> that matches "command line arguments"!
What would break if "mk" had an empty rule matching "command line
arguments" itself?
++L
As this list seems to be open to discussion of strange OS-related ideas, here
goes my question:
why do we keep distinction between files and directories? Does it provide any
extra value over model with unified file/directory?
A possible consideration for representation of unified files/director
On Thu, 3 Feb 2011 10:38:30 +, C H Forsyth wrote:
it's not just the FORTRAN but supporting libraries, sometimes large
ones,
including ones in C++, are often required as well. i'd concluded that
cross-compilation was currently the only effective route.
i hadn't investigated whether something
> > > Hi, Running plan 9 on virtual box 4.0.2, I've configured network
> > > adaptaters as below.
> > > Attached to NAT
> > > Adapter type: PCnet-FAST 3(Am79C973)
> > > check cable connected.
> >
> > > After booting plan 9, I typed ip/ipconfig, after waiting some time,
> > > ipconfig: no success wi
> why do we keep distinction between files and directories? Does it provide any
> extra value over model with unified file/directory?
yes. the advantage is that it's easy to tell the difference
between a file and a directory. and we have a lot of code
that works with the current model.
what is
On Thu Feb 3 04:36:35 EST 2011, fors...@terzarima.net wrote:
> > The finished version will support strings backed by file storage
>
> string(2) doesn't go quite that far, but is used by the mailer upas
> and perhaps other things to reduce the instances of arbitrarily low limits
> and bounds excee
On 3 February 2011 11:45, dexen deVries wrote:
> read(open("/foo")) returns byte stream under entry `foo' in the root object.
>
> readdir("/foo") returns `bar' (and possibly others) -- entries in hierarchical
> section of object `/foo'.
there's no distinction between readdir and read in plan 9.
On 3 February 2011 13:01, erik quanstrom wrote:
> i think you're better off with char*s and realloc.
> it's worth looking at the heavy machinery in sam
> and acme, though, and comparing against ed.
i'd hesitate before trying to edit 500MB files in ed...
nor does ed cope with arbitrary length lin
On Thu Feb 3 08:39:20 EST 2011, rogpe...@gmail.com wrote:
> On 3 February 2011 11:45, dexen deVries wrote:
> > read(open("/foo")) returns byte stream under entry `foo' in the root object.
> >
> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> > hierarchical
> > section of ob
On Thursday, February 03, 2011 02:05:02 pm erik quanstrom wrote:
> > why do we keep distinction between files and directories? Does it provide
> > any extra value over model with unified file/directory?
>
> yes. the advantage is that it's easy to tell the difference
> between a file and a directo
On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> On 3 February 2011 11:45, dexen deVries wrote:
> > read(open("/foo")) returns byte stream under entry `foo' in the root
> > object.
> >
> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> > hierarchical section of
On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote:
> On 3 February 2011 13:01, erik quanstrom wrote:
> > i think you're better off with char*s and realloc.
> > it's worth looking at the heavy machinery in sam
> > and acme, though, and comparing against ed.
>
> i'd hesitate before trying t
> How about 8c(1)? would it be too confusing to issue:
> 8c foo.c
> if `foo.c' contained some C code, AND `foo.c/bar.h' contained some more C
> code?
>
> rc(1)? How could `. foo.rc' handle situation when also
> `foo.rc/bar.rc/baz.rc'
> exists?
exactly. this is the same problem one has with a
On 3 February 2011 13:44, dexen deVries wrote:
> On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
>> On 3 February 2011 11:45, dexen deVries wrote:
>> > read(open("/foo")) returns byte stream under entry `foo' in the root
>> > object.
>> >
>> > readdir("/foo") returns `bar' (and poss
i've found it very useful quite a few times.
usually with oversized log files.
On 3 February 2011 13:59, erik quanstrom wrote:
> On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote:
>> On 3 February 2011 13:01, erik quanstrom wrote:
>> > i think you're better off with char*s and realloc.
>
On Thu Feb 3 09:17:27 EST 2011, rogpe...@gmail.com wrote:
> i've found it very useful quite a few times.
> usually with oversized log files.
>
> On 3 February 2011 13:59, erik quanstrom wrote:
> > On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote:
> >> On 3 February 2011 13:01, erik quan
On 3 February 2011 14:17, erik quanstrom wrote:
> On Thu Feb 3 09:17:27 EST 2011, rogpe...@gmail.com wrote:
>> i've found it very useful quite a few times.
>> usually with oversized log files.
>>
>> On 3 February 2011 13:59, erik quanstrom wrote:
>> > On Thu Feb 3 08:41:23 EST 2011, rogpe...@gm
>usually with oversized log files.
sam -d, indeed!
On Thursday, February 03, 2011 03:15:29 pm roger peppe wrote:
> On 3 February 2011 13:44, dexen deVries wrote:
> > On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> >> On 3 February 2011 11:45, dexen deVries wrote:
> >> > read(open("/foo")) returns byte stream under entry `foo' in t
On Thursday, February 03, 2011 03:15:29 pm roger peppe wrote:
> On 3 February 2011 13:44, dexen deVries wrote:
> > On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> >> On 3 February 2011 11:45, dexen deVries wrote:
> >> > read(open("/foo")) returns byte stream under entry `foo' in t
On Wednesday, February 2, 2011, erik quanstrom wrote:
>> It is a C/C++/Obj-C compiler & does static analysis, has
>> backends for multiple processor types as well as C as a
>> target, a lot of optimization tricks etc. See llvm.org. But
>> frankly, I think they have lost the plot. C is basically
To be fair, gcc, g++ and gobjc combined are actually bigger than clang+llvm.
At least on my system. So it could have been worse.
2011/2/3 David Leimbach
> On Wednesday, February 2, 2011, erik quanstrom
> wrote:
> >> It is a C/C++/Obj-C compiler & does static analysis, has
> >> backends for mult
Plan 9 is a research operating system. It also happens that many
people who use it for research also use it in production.
Many of the engineering decisions that went into Plan 9 were a matter
of priorities. The creators of Plan 9 chose a simple, comprehensible C
compiler over more complex alterna
On Thu, 03 Feb 2011 12:45:33 +0100 dexen deVries
wrote:
>
> why do we keep distinction between files and directories?
David Cheriton's `thoth' operating system didn't keep this
distinction. But every other OS I know of keeps them
separate. IIRC thoth provided functions for getting the
first c
On Thu, 03 Feb 2011 07:08:57 PST David Leimbach wrote:
> On Wednesday, February 2, 2011, erik quanstrom wrote:
> >> It is a C/C++/Obj-C compiler & does static analysis, has
> >> backends for multiple processor types as well as C as a
> >> target, a lot of optimization tricks etc. See llvm.org. B
> I agree with their goal but not its execution. I think a
> toolkit for manipulating graph based program representations
> to build optimizing compilers is a great idea but did they
> do it in C++?
are you sure that the problem isn't the graph representation?
gcc also takes a graph-based approac
EBo writes:
> Ah. Thanks for the info. I asked because some of the physicists and
> atmospheric scientists I work with are likely to insist on having
> FORTRAN. I still have not figured how I will deal with that if at
> all.
I thought those folks used languages like Matlab & Mathematica for
an
Consider what `stalin' does in about 3300 lines of Scheme
> code. It translates R4RS scheme to C and takes a lot of time
> doing so but the code is generates is blazingly fast. The
> kind of globally optimized C code you or I wouldn't have the
> patience to write. Or the ability to keep all that co
On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom wrote:
> > I agree with their goal but not its execution. I think a
> > toolkit for manipulating graph based program representations
> > to build optimizing compilers is a great idea but did they
> > do it in C++?
>
> are you sure that the problem
dexen deVries writes:
>> oh yes, maintaining the usual semantics for cp becomes tricky.
>>
>> mkdir z
>> cp x.c z
>>
>> do i mean to write x.c to z itself, or to a new file within z?
>
> nb., with the current semantics you *could* say `cp x.c z/' to be unambiguous
> you want to create a child
cool! it seems you could implement an fs with unlimited name length
using the file-backed-strings and store the data as the file name;
very efficient.
On Wed, Feb 2, 2011 at 7:35 PM, wrote:
> ron minnich writes:
>
>> OK, let's do a test. You write your stuff with iterators and put it on
>> a ma
On Thu, Feb 3, 2011 at 10:21 AM, wrote:
> EBo writes:
>
>> Ah. Thanks for the info. I asked because some of the physicists and
>> atmospheric scientists I work with are likely to insist on having
>> FORTRAN. I still have not figured how I will deal with that if at
>> all.
>
> I thought those f
On Thu Feb 3 13:33:52 EST 2011, bakul+pl...@bitblocks.com wrote:
> On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom
> wrote:
> > > I agree with their goal but not its execution. I think a
> > > toolkit for manipulating graph based program representations
> > > to build optimizing compilers is a
On Thu, 03 Feb 2011 18:21:28 +, smi...@zenzebra.mv.com wrote:
Ah. Thanks for the info. I asked because some of the physicists and
atmospheric scientists I work with are likely to insist on having
FORTRAN. I still have not figured how I will deal with that if at
all.
I thought those folks
On Thu, 03 Feb 2011 13:54:05 EST erik quanstrom wrote:
> On Thu Feb 3 13:33:52 EST 2011, bakul+pl...@bitblocks.com wrote:
> > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom wr
> ote:
> > > > I agree with their goal but not its execution. I think a
> > > > toolkit for manipulating graph based
> I must also say llvm has a lot of functionality. But even so
> there is a lot of bloat. Let me just say the bloat is due to
> many factors but it has far *less* to do with graphs.
> Download llvm and take a peek. I think the chosen language
> and the habits it promotes and the "impedance match"
I don't know if f2c meets your needs, but it has always worked.
On Thu, Feb 3, 2011 at 9:07 AM, EBo wrote:
> On Thu, 3 Feb 2011 10:38:30 +, C H Forsyth wrote:
>>
>> it's not just the FORTRAN but supporting libraries, sometimes large ones,
>> including ones in C++, are often required as well.
On Thu, Feb 3, 2011 at 12:49 PM, Federico G. Benavento
wrote:
> I don't know if f2c meets your needs, but it has always worked.
As compared to modern fortran compilers, it is basically a toy.
ron
> > I don't know if f2c meets your needs, but it has always worked.
>
>
> As compared to modern fortran compilers, it is basically a toy.
>
But he did say some of his source is in ratfor,
I am pretty sure f2c would be happy with ratfor's output.
years ago I supported the pafec FE package - ten
On Thursday 03 of February 2011 19:42:39 smi...@zenzebra.mv.com wrote:
> dexen deVries writes:
> >> oh yes, maintaining the usual semantics for cp becomes tricky.
> >>
> >> mkdir z
> >> cp x.c z
> >>
> >> do i mean to write x.c to z itself, or to a new file within z?
> >
> > nb., with the curre
I don't write in fortran, but I certainly link to libraries written
in it. It is a truly awful language in any of its incarnations, but
sometimes the library you need is in fortran. Fortunately it's
not to hard to link to from C once you understand its calling
conventions and array ordering.
>
On Thu, 03 Feb 2011 23:08:38 +, John Stalker wrote:
I don't write in fortran, but I certainly link to libraries written
in it. It is a truly awful language in any of its incarnations, but
sometimes the library you need is in fortran. Fortunately it's
not to hard to link to from C once you u
On Thu, Feb 3, 2011 at 10:58 AM, Bakul Shah wrote:
> On Thu, 03 Feb 2011 12:45:33 +0100 dexen deVries
> wrote:
>>
>> why do we keep distinction between files and directories?
>
> David Cheriton's `thoth' operating system didn't keep this
> distinction. But every other OS I know of keeps them
>
On Thu, 3 Feb 2011 21:32:24 +, Steve Simon wrote:
> I don't know if f2c meets your needs, but it has always worked.
As compared to modern fortran compilers, it is basically a toy.
But he did say some of his source is in ratfor,
I am pretty sure f2c would be happy with ratfor's output.
y
Eric Van Hensbergen writes:
>> build an experimental OS around it! But if you go this path,
>> do consider providing a few more datatypes in the filesystem
>> (integers, file-id, strings, ...). Basically persistent data
>> types. Or just use an object or relational database as your
>> filesystem
try asking his jail warden.
On Thu, Feb 3, 2011 at 4:24 PM, wrote:
> /me wonders what ever happened to Hans...
> me wonders what ever happened to Hans...
Is that really necessary? I'm guessing it was intended as a joke.
Back in the 10th grade I spent a few months running a Reiser4 linux
root. It was kind of a piece of junk, frequently locking up and
giving inconsistent performance. C.f.
http://en.wikip
On Thu, 03 Feb 2011 18:42:39 +
smi...@zenzebra.mv.com wrote:
> There's no way that I know of to possibly interperet a path ending in
> "/" as a file (with the exception of reading raw Dir data, as on Plan
> 9 or "cat /" on, what was it, Solaris?).
FreeBSD 8.0 lets you cat the raw data of a di
> FreeBSD 8.0 lets you cat the raw data of a directory, and I would
> expect the other free BSDs to have that misfeature, too.
i don't see how allowing this is a misfeature. regardless,
plan 9 allows it.
; sha1sum < /adm/timezone
05d16cd216a58fae746ae36f72c784d10bcc1392
- erik
On Thu, 3 Feb 2011 20:49:17 -0500
erik quanstrom wrote:
> > FreeBSD 8.0 lets you cat the raw data of a directory, and I would
> > expect the other free BSDs to have that misfeature, too.
>
> i don't see how allowing this is a misfeature. regardless,
> plan 9 allows it.
>
> ; sha1sum < /adm/tim
On Feb 3, 2011, at 9:30 PM, Robert Ransom wrote:
>>
>>
>
> This feature might be more useful if the directory entries were
> presented to clients of the FS in a textual format, but that would
> encourage, if not require, far more parsing in the system, and that is
> bad both for performance
did i hear cloud-backed directory entries?
> >> >> > > This feature might be more useful if the directory entries
> were > presented to clients of the FS in a textual format, but that
> would > encourage, if not require, far more parsing in the system, and
> that is > bad both for performance and for security.
>
> Sounds like a good argume
> $ size /usr/local/bin/clang
> text data bss dec hex filename
> 22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang
"It is interesting to note the 5 minutes reduction in system time. I
assume that this is in part because of the builtin assembler."
-- http
On Thu, 03 Feb 2011 15:33:57 EST erik quanstrom wrote:
> > I must also say llvm has a lot of functionality. But even so
> > there is a lot of bloat. Let me just say the bloat is due to
> > many factors but it has far *less* to do with graphs.
> > Download llvm and take a peek. I think the chose
69 matches
Mail list logo
