In article aanlktikpmgql8mktb9trjyo52h9-p1a5gkkxxhsae...@mail.gmail.com,
Federico G. Benavento benave...@gmail.com wrote:
isn't this redundant with cpp(1)'s __FUNCTION__?
if __FUNCTION__ isn't standard, then we should change
it to __func__ in cpp and that's it
I'm not sure what cpp's
* Gary V. Vaughan g...@vaughan.pe wrote:
I have never used sysroot in all that time,
Maybe that's the problem. ;-p
I'm using sysroot all the time, since I don't want to tweak
every single package so that the right pathes are found, at
build- as well as runtime.
W/ sysroot you build and
isn't this redundant with cpp(1)'s __FUNCTION__?
if __FUNCTION__ isn't standard, then we should change
it to __func__ in cpp and that's it
On Thu, Nov 18, 2010 at 2:30 AM, Joel C. Salomon joelcsalo...@gmail.com wrote:
On 11/14/2010 04:44 PM, Charles Forsyth wrote:
the list of unimplemented
On 11/18/2010 05:50 PM, Federico G. Benavento wrote:
On Thu, Nov 18, 2010 at 2:30 AM, Joel C. Salomon joelcsalo...@gmail.com
wrote:
Why is __func__ listed as “unwanted”? I’ve found it useful for some
logging functions.
isn't this redundant with cpp(1)'s __FUNCTION__?
if __FUNCTION__
my bad, I thought cpp(1) implemented __FUNCTION__...
On Thu, Nov 18, 2010 at 11:06 PM, Joel C. Salomon
joelcsalo...@gmail.com wrote:
On 11/18/2010 05:50 PM, Federico G. Benavento wrote:
On Thu, Nov 18, 2010 at 2:30 AM, Joel C. Salomon joelcsalo...@gmail.com
wrote:
Why is __func__ listed as
On 11/14/2010 04:44 PM, Charles Forsyth wrote:
the list of unimplemented items in /sys/src/cmd/cc/c99* is:
snip
i can think of something else that's not been noticed, but what other things
have you found?
Why is __func__ listed as “unwanted”? I’ve found it useful for some
logging functions.
Why is __func__ listed as “unwanted”? I’ve found it useful for some
logging functions.
i think the correct interpretation of unwanted in this
context is either don't want or don't want to implement.
one former member of the don't-want list was varadic macros,
which are now supported by both
On Mon, Nov 15, 2010 at 19:32, lu...@proxima.alt.za wrote:
I always had the impression that the object formats
used by the various ?l are more for kernels and the
various formats expected by loaders than for userland
apps. For userland, I would think the intent is for
there to be a single
On Wed, Nov 17, 2010 at 09:38:46AM +0200, Pavel Zholkover wrote:
I did a Go runtime port for x86, it is in already in the main hg repository.
Right now it is cross-compile from Linux for example (GOOS=plan9 8l -s
when linking. notice the -s, it is required).
I have Plan 9 versions of the
On Sun, Nov 14, 2010 at 11:29 PM, Gary V. Vaughan g...@vaughan.pe wrote:
You can either try to remember what all of those are, or use something
like autoconf to probe for known bugs, and gnulib to plug them, or
you can link against a shim library like GNU libposix which will
do all of that
On 15 Nov 2010, at 08:02, Enrico Weigelt weig...@metux.de wrote:
* Gary V. Vaughan g...@gnu.org wrote:
People like to beat on GNU Libtool, and in some cases that criticism is
not undeserved... but in my experience, many critics of the tool come
from a perspective of building on a single
*much* rather wait 90 seconds for each build that try to maintain a giant
tabulation with thousands of entries, which go out of date every time a new
patch or revision of libc or the compiler or the os or the linker comes along.
there seems to be an affliction in the unix world, that started
Dan makes a good point and I agree entirely with his sentiments. But I do
have a qualm: the Plan 9 designers managed to simplify cross-compilation
to a single underlying (OS) platform, but failed (in a suprisingly ugly
way) to cater for different target object formats, even though there were
to a single underlying (OS) platform, but failed (in a
suprisingly ugly
way) to cater for different target object formats, even
though there were
efforts to do so. In my opinion - and this is all I
hold against Plan
9 - by shoehorning various target object formats in the
linker/loader
as
My personal disappointment with autoconf, is that there was no simple
file which the package author writes (or even autgenerates)
describing what features their package depends on.
There is a file, but its anything but simple and as it (ab)uses m4
and shell script macros that it knows exist. It
I always had the impression that the object formats
used by the various ?l are more for kernels and the
various formats expected by loaders than for userland
apps. For userland, I would think the intent is for
there to be a single consistent object format (at least
for a given
if you just want go on plan 9, i think object formats
are a non-sequitor.
But that's not it, really, I want both Go and the ELF capabilities :-)
calling out the guys who wrote plan 9 for not supporting
object formats that plan 9 never used, seems a bit rude
to me.
I am willing to
On Nov 14, 2010, at 1:26, Russ Cox r...@swtch.com wrote:
[a bunch of very reasonable stuff]
I clearly didn't write that well because Russ just disagreed with me by saying
exactly what I was trying to say: the approaches ask and answer different
questions. My main interest was to point out that
Hi Erik et. al,
Thanks for the feedback, all.
On 14 Nov 2010, at 13:24, erik quanstrom wrote:
You may well be right that there's too much momentum behind
autoconf/automake to change GNU. But that doesn't mean it's the right
thing to do, or something sensible people ought to choose to
Hello,
On Sun, Nov 14, 2010 at 09:17:46AM +0700, Gary V. Vaughan wrote:
[[resent from my subscribed email address after the mailing list rejected the
original]]
[...]
AFAICT, without rewriting the entire GNU build system from the ground
up (and there is far too much momentum behind it to
On 14 Nov 2010, at 16:10, tlaro...@polynum.com wrote:
Hello,
Hi Thierry,
On Sun, Nov 14, 2010 at 09:17:46AM +0700, Gary V. Vaughan wrote:
[[resent from my subscribed email address after the mailing list rejected
the original]]
[...]
AFAICT, without rewriting the entire GNU build system
Hello Gary,
On Sun, Nov 14, 2010 at 04:32:34PM +0700, Gary V. Vaughan wrote:
[...]
Does your build system work correctly with shared libraries in Mingw,
cygwin, AIX, HP-UX (to name just a few of the more awkward under-
featured shared library implementations I care about) under various
On 14.11.2010 10:10, tlaro...@polynum.com wrote:
Furthermore, the auto* and libtool were typically made
for trying to do something working to some extend with a chaotic
source. They typically manage to compile things written by
programmers who have been encouraged to look at the finger
GNU awk is a nice piece of software. The core of
GNU grep is very well written even if the surrounding
utility has been embellished a bit too much. Groff is
when mike wrote it, gnu grep was the best thing one
could get if one wasn't at the labs. since brucee started
this, i was in the room
The full standard c library isn't included in a statically linked
executable. Only what's needed is, at least on plan 9, i have no idea what
gcc does.
On Nov 14, 2010 3:14 AM, Gary V. Vaughan g...@vaughan.pe wrote:
Hi Erik et. al,
Thanks for the feedback, all.
On 14 Nov 2010, at 13:24, erik
On Sun, Nov 14, 2010 at 7:56 AM, Jacob Todd jaketodd...@gmail.com wrote:
The full standard c library isn't included in a statically linked
executable. Only what's needed is, at least on plan 9, i have no idea what
gcc does.
To emphasize this comment: Plan 9 has always done the equivalent of
unfortunately, the last i checked, gnu grep mallocs
for each byte of input when using a utf-8 locale.
that bug was fixed in gnu grep years ago,
probably before you found and reported it.
unfortunately, linux distributions were for
many years not updating their copies of
gnu grep to the latest
I have successfully avoided using autoconf and similar stuff in my
projects by adhering to strict C99, but in an ironic twist of fate, Plan
9 will be the OS that forces me to use something like autoconf due to
the limited C99 support.
the list of unimplemented items in /sys/src/cmd/cc/c99* is:
Compound literal support is unimplemented for arrays. Also, most c99
headers are missing, even the simple ones like stdint.h. It seems most of
the work to fix that would be teaching OSTRUCT to work with arrays in
com.c
*dives back into schoolwork*
On Sun, 14 Nov 2010 21:44:07 +, Charles
unfortunately, the last i checked, gnu grep mallocs
for each byte of input when using a utf-8 locale.
that bug was fixed in gnu grep years ago,
probably before you found and reported it.
unfortunately, linux distributions were for
many years not updating their copies of
gnu grep to the
* Gary V. Vaughan g...@gnu.org wrote:
People like to beat on GNU Libtool, and in some cases that criticism is
not undeserved... but in my experience, many critics of the tool come
from a perspective of building on a single architecture.
Actually, I'm building for lots of different archs
On 14 Nov 2010, at 17:50, Carl-Daniel Hailfinger wrote:
On 14.11.2010 10:10, tlaro...@polynum.com wrote:
Furthermore, the auto* and libtool were typically made
for trying to do something working to some extend with a chaotic
source. They typically manage to compile things written by
On 15.11.2010 05:29, Gary V. Vaughan wrote:
On 14 Nov 2010, at 17:50, Carl-Daniel Hailfinger wrote:
On 14.11.2010 10:10, tlaro...@polynum.com wrote:
Furthermore, the auto* and libtool were typically made
for trying to do something working to some extend with a chaotic
source. They
* Charles Forsyth fors...@terzarima.net wrote:
``My last company switched to nmake, and they're OUT OF BUISINESS :-) :-)
:-)''
[fortune]
When it comes to builder systems, I'm still thinking of an more
declarative approach: describing the software's structure by
certain object types and their
* ron minnich rminn...@gmail.com wrote:
If you're the kind of guy who can't resist changing things that don't
need changing, then you won't get it; perhaps you'd be better off
working on libtool. But Plan 9 is far from dead.
Nobody with at least half-sane mind voluntarily works on or even
[[resent from my subscribed email address after the mailing list rejected the
original]]
Hi Enrico,
On 14 Nov 2010, at 02:24, Enrico Weigelt wrote:
* ron minnich rminn...@gmail.com wrote:
If you're the kind of guy who can't resist changing things that don't
need changing, then you won't
On Nov 13, 2010, at 21:17, Gary V. Vaughan wrote:
People like to beat on GNU Libtool, and in some cases that criticism is
not undeserved... but in my experience, many critics of the tool come
from a perspective of building on a single architecture. If you have
never tried to build and link
When I write C code which I intend to be portable, I write against p9p, ...
I don't think this is fair to Gary's well-reasoned mail.
He explicitly said libtool was solving the problem of
providing a single consistent command line tool that
handled the job of building a *shared library* on a
You may well be right that there's too much momentum behind
autoconf/automake to change GNU. But that doesn't mean it's the right
thing to do, or something sensible people ought to choose to
participate in.
to be a bit more blunt, the argument that the tyrrany of the
auto* is unstoppable and
brucee has a t-shirt press.
fun - $5 - 5 minutes (mate's rates). cinap has a reversed glenda shirt
to remind him the cars are on the left of the road. he should be
surfing with tiger - waves were a bit scarey for the boy today.
brucee
GCC makes me wanna smoke crack
On Tue, Nov 9, 2010 at 2:18
On 5 November 2010 19:06, erik quanstrom quans...@labs.coraid.com wrote:
('', '', '||', if, '|', 'and '`{}') with something general
enough to replace mk, you'd be on to something.
i did a mash-inspired version of mk as an inferno shell module once.
it required no new syntax (although it
but it seemed better just to port mk itself.
the intention was to support building both inside and outside the Inferno
environment,
and neither sh nor mash were going to be as easy to reproduce
outside Inferno as simply making mk work (more or less) inside Inferno.
that action alone wasn't
a more than fair justification.
brucee
On Tue, Nov 9, 2010 at 9:22 AM, Charles Forsyth fors...@terzarima.net wrote:
but it seemed better just to port mk itself.
the intention was to support building both inside and outside the Inferno
environment,
and neither sh nor mash were going to be
the intention was to support building both inside and outside the Inferno
environment,
oh. and just like Plan 9 mkfile's and for the same reason, Inferno's mkfiles
were
essentially concise lists of the names of inputs and the names of outputs, with
few instructions,
which suited my little
On Nov 8, 2010, at 4:33 PM, Charles Forsyth wrote:
``My last company switched to nmake, and they're OUT OF BUISINESS :-) :-)
:-)''
That line is tee-shirt worthy.
``My last company switched to nmake, and they're OUT OF BUISINESS
:-) :-) :-)''
That line is tee-shirt worthy.
There are places you can get custom t-shirts made for a reasonable fee,
so you should be able to have one made ;-)
On Saturday 06 of November 2010 03:20:55 Bruce Ellis wrote:
i can answer that one easily. that's why it's called mash rather than
random marketting name. the intention was to replace plan9 rc with a
shell that was maintainable and had loadable modules. i wrote it in
limbo to show it works,
On Fri, Nov 05, 2010 at 02:50:22PM +1100, Bruce Ellis wrote:
mash has a make builtin. very brief, as all the shell type stuff in mk
goes away..
I seem to remember that the mash source was lost?
++L
no. it was the last thing i wrote for the bidness unit.
brucee
On Fri, Nov 5, 2010 at 6:11 PM, Lucio De Re lu...@proxima.alt.za wrote:
On Fri, Nov 05, 2010 at 02:50:22PM +1100, Bruce Ellis wrote:
mash has a make builtin. very brief, as all the shell type stuff in mk
goes away..
I seem to
Quite right:
http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash
Although, no doubt brucee has a new, improved version not fit for mere
mortals to gaze upon.
-eric
On Fri, Nov 5, 2010 at 2:55 AM, Bruce Ellis bruce.el...@gmail.com wrote:
no. it was the last thing i
http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash
that one is indeed fairly old, much as we received it, except for
changes to fit any changes in the environment, but
http://www.vitanuova.com/inferno/man/1/mash.html
and
On Friday 05 of November 2010 14:31:01 Eric Van Hensbergen wrote:
Quite right:
http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash
Although, no doubt brucee has a new, improved version not fit for mere
mortals to gaze upon.
A honest question: what is the rationale for
A honest question: what is the rationale for merging functionality of make and
shell into one?
Use your imagination
Nick
On Friday 05 of November 2010 18:18:44 Nick LaForge wrote:
A honest question: what is the rationale for merging functionality of
make and shell into one?
Use your imagination
Tried, failed.
To me, make is a tool for generating an acyclic, directed graph of
dependencies between build
To me, make is a tool for generating an acyclic, directed graph of
dependencies between build steps from some explicit and some wildcard rules
-- and then traversing it in a sensible order. How's that for daily use shell?
your focus is too narrowed on building. a sequence of commands piping
On Fri, Nov 5, 2010 at 10:32 AM, dexen deVries dexen.devr...@gmail.comwrote:
On Friday 05 of November 2010 18:18:44 Nick LaForge wrote:
A honest question: what is the rationale for merging functionality of
make and shell into one?
Use your imagination
Tried, failed.
To me, make
On Friday 05 of November 2010 18:39:14 andrey mirtchovski wrote:
To me, make is a tool for generating an acyclic, directed graph of
dependencies between build steps from some explicit and some wildcard
rules -- and then traversing it in a sensible order. How's that for
daily use shell?
-- and then traversing it in a sensible order. How's that for daily use
shell?
Why is a shell that can generate acyclic digraphs of dependencies bad?
Someone clearly found a use for it at some point or it wouldn't have been
done.
it is silly bloat if it's not an essential part of the
On 5 November 2010 18:14, erik quanstrom quans...@labs.coraid.com wrote:
-- and then traversing it in a sensible order. How's that for daily use
shell?
Why is a shell that can generate acyclic digraphs of dependencies bad?
Someone clearly found a use for it at some point or it wouldn't
('', '', '||', if, '|', 'and '`{}') with something general
enough to replace mk, you'd be on to something.
i did a mash-inspired version of mk as an inferno shell module once.
it required no new syntax (although it could be confused by
files named :...)
what you did was very cool, but
On Fri, Nov 5, 2010 at 12:07 PM, dexen deVries dexen.devr...@gmail.com wrote:
On Friday 05 of November 2010 14:31:01 Eric Van Hensbergen wrote:
Quite right:
http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash
Although, no doubt brucee has a new, improved version not fit
i can answer that one easily. that's why it's called mash rather than
random marketting name. the intention was to replace plan9 rc with a
shell that was maintainable and had loadable modules. i wrote it in
limbo to show it works, damned well. the first requirement was a make
loadable. it's not
On Thu, Nov 04, 2010 at 09:36:11AM +, Admiral Fukov wrote:
I'm looking at
http://plan9.bell-labs.com/sources/plan9/sys/src/
and I noticed that most of the distribution hasn't been updated in
years.
Is the development of plan 9 abandoned?
Why fix what's perfect? ;-)
++L
and I noticed that most of the distribution hasn't been updated in
years.
Is the development of plan 9 abandoned?
No it is not, a lot, depends on which file(s) you are looking at.
There has been much work recently on the ARM port (guru plug and beagleboard)
Other changes happen as required (or
Unlike many open source systems, plan 9 is stable. Very reliable. It doesn't
get changed just for fun.
iPhone email
On Nov 4, 2010, at 5:43 AM, Admiral Fukov admiralfu...@gmail.com wrote:
I'm looking at
http://plan9.bell-labs.com/sources/plan9/sys/src/
and I noticed that most of the
On Thu, Nov 04, 2010 at 09:36:11AM +, Admiral Fukov wrote:
I'm looking at
http://plan9.bell-labs.com/sources/plan9/sys/src/
and I noticed that most of the distribution hasn't been updated in
years.
Is the development of plan 9 abandoned?
Please note the timestamps in listings
On Thu, Nov 4, 2010 at 2:36 AM, Admiral Fukov admiralfu...@gmail.comwrote:
I'm looking at
http://plan9.bell-labs.com/sources/plan9/sys/src/
and I noticed that most of the distribution hasn't been updated in
years.
Is the development of plan 9 abandoned?
There's a plan9changes google
On Thu, Nov 4, 2010 at 2:36 AM, Admiral Fukov admiralfu...@gmail.comwrote:
I'm looking at
http://plan9.bell-labs.com/sources/plan9/sys/src/
and I noticed that most of the distribution hasn't been updated in
years.
Is the development of plan 9 abandoned?
There's a plan9changes
On Thu, Nov 4, 2010 at 11:55 AM, Stanley Lieber
stanley.lie...@gmail.com wrote:
On Thu, Nov 4, 2010 at 10:39 AM, David Leimbach leim...@gmail.com wrote:
There's a plan9changes google group I believe that will let you see the
commits that have been going in.
On Thu, Nov 4, 2010 at 10:39 AM, David Leimbach leim...@gmail.com wrote:
There's a plan9changes google group I believe that will let you see the
commits that have been going in.
http://groups.google.com/group/plan9changes/topics
doesn't show any updates since July, 2008.
Is there another way
On Thu, Nov 4, 2010 at 11:01 AM, John Floren slawmas...@gmail.com wrote:
Watch Ron's repository, which Venkatesh posted earlier.
http://bitbucket.org/rminnich/sysfromiso
On Thu, Nov 4, 2010 at 11:39 AM, ron minnich rminn...@gmail.com wrote:
sysfromiso makes that clear. It's a great way to
Request to add If you're the kind of person who understands that we
don't need to change 'cat' any further, then you understand the work
that is going on. to fortune.
Ron++
D
On Thu, Nov 4, 2010 at 10:39 AM, ron minnich rminn...@gmail.com wrote:
ignoring the troll, but for the rest of you
On Thu, Nov 4, 2010 at 5:00 PM, erik quanstrom quans...@quanstro.netwrote:
On Thu, Nov 4, 2010 at 2:36 AM, Admiral Fukov admiralfu...@gmail.com
wrote:
I'm looking at
http://plan9.bell-labs.com/sources/plan9/sys/src/
and I noticed that most of the distribution hasn't been
On Thu, Nov 4, 2010 at 1:48 PM, Venkatesh Srinivas m...@acm.jhu.edu wrote:
In the ~8 years since the 4th edition release, there has been pretty
continuous work on Plan 9, both at Bell Labs and in the 9fans community;
nightly an ISO is constructed and uploaded. Changes have been incremental --
On Nov 4, 2010, at 11:39 AM, ron minnich wrote:
If you're the kind of person who understands that we don't need to
change 'cat' any further, then you understand the work that is going
on.
But why isn't the source for mk (3929 lines w/ headers, okay 4661 with mkfile
and acid) at least as
Some people prefer privacy, others are just assholes who want to pick fights
because they are bored.
Asking a perfectly valid question is not trolling, unlike your reply that
adds nothing to the subject at hand.
so, no bait and switch then? was your question answered satisfactorily?
On Thu, Nov 4, 2010 at 6:19 PM, andrey mirtchovski mirtchov...@gmail.comwrote:
Some people prefer privacy, others are just assholes who want to pick
fights
because they are bored.
Asking a perfectly valid question is not trolling, unlike your reply that
adds nothing to the subject at
On Thu, Nov 4, 2010 at 9:00 AM, erik quanstrom quans...@quanstro.netwrote:
On Thu, Nov 4, 2010 at 2:36 AM, Admiral Fukov admiralfu...@gmail.com
wrote:
I'm looking at
http://plan9.bell-labs.com/sources/plan9/sys/src/
and I noticed that most of the distribution hasn't been
But why isn't the source for mk (3929 lines w/ headers, okay 4661 with mkfile
and acid)
at least as long as all that Java in the ant distribution (213151 lines)?
That's a lot of catching up to do.
The market has clearly spoken, and it appears that more lines dominates the
soup.
one interesting
one interesting thing about that example is that if it were done again
for the Plan 9 environment, mk might well be even smaller, since
some of the existing functionality isn't really used,
or might be achieved by simpler mechanisms, or with functionality
added instead by further composition
mash has a make builtin. very brief, as all the shell type stuff in mk
goes away..
brucee
On Fri, Nov 5, 2010 at 12:41 PM, Venkatesh Srinivas m...@acm.jhu.edu wrote:
one interesting thing about that example is that if it were done again
for the Plan 9 environment, mk might well be even
81 matches
Mail list logo
