On 15 March 2013 16:52, Joel C. Salomon wrote:
> BTW, the C11 standard includes a restricted form of 9c's anonymous
> sub-structs (with no pointer conversion).
>
isn't the pointer conversion most of the point of them?
It isn't just one "cloud machine", and includes several servers that I own,
and virtual servers that I lease,
and my Internet connections are usually good; if they are not, the machines
I'd otherwise connect to outside
the house aren't accessible anyway, so I don't need the keys.
On 28 February 2013 23:02, Jeff Sickel wrote:
> that just removes the
> offending EBADF
>
it should generate EBADF for any bit set in any of the fd_sets when that
bit doesn't correspond to an open file descriptor.
the mistake was producing EBADF on a very specific condition associated
with an *o
ANSI C has a "_Noreturn" attribute that I started to implement,
but I think I might fall back to a #pragma, which would be quicker to do.
On 28 February 2013 14:15, Steve Simon wrote:
> I have rebuilt equis with the change in ape's select
> and it seems to work fine (tested with xlock and xter
i assumed you wanted a b c as command line arguments in the second case,
not echoed in.
in the first case, you indexed a variable. in the second case, you indexed
nothing.
% rc -c 'echo @ $*(2-) @' a b c
@ b c @
On 27 February 2013 15:41, Steve Simon wrote:
> Hi,
>
> rc is not working how I e
On 27 February 2013 08:24, wrote:
> I hope this post leads to constructive discussion of the import/exportfs
> protocol.
As you'll have noticed, it isn't a great protocol as it stands. I don't
think your option makes it worse.
Thanks for the detailed discussion. I think at least one existing sy
On 26 February 2013 17:01, Jeff Sickel wrote:
> Of course, if we're going the Linux route, we'll need to up FD_SETSIZE to
> at
> least 1024, we're currently at 96. Seems that 1024 has become the default
> these days.
>
I meant only for trying to work out what seems to satisfy X11 as regards
err
On 26 February 2013 16:20, Charles Forsyth wrote:
> If APE's select does the same, it will be fine, without breaking Python's
> pipes.
"it will be fine" -- I meant X11 will be fine, since it's relying on
closing a file descriptor in
one part of the program
On 26 February 2013 15:29, Jeff Sickel wrote:
> But if the X11 port does expect EBADF on the EOF, then I'd expect
> it to break.
>
It breaks anyway:
http://lists.opensuse.org/opensuse-bugs/2012-08/msg02390.html
Note, however, that the EBADF in that example is on the output side (and
outputs are
On 26 February 2013 11:25, Yaroslav wrote:
> 've come to the conclusion that the code that causes error is intentional
I don't think that code is right. It's correct to return with a bit set in
rfds for a file descriptor that's ready with only an end of file (zero
read).
EBADF should only be g
On 26 February 2013 07:35, Devon H. O'Dell wrote:
> So I
> googled the directory and presto chango. Took about 3 minutes.
>
The dates on the file and the file with the e-mail exchange with Lesk
suggests the file only turned up there on 14 Feb this year,
which probably explains why it wasn't quit
"My other question is: what's the security implications of cpu? You
get to do processes on the remote box, but then they also get to have
filesystem access on yours. "
If you don't entirely trust the cpu server, you *should* export a name
space from your terminal,
limit the processes on the cpu s
On 19 February 2013 10:05, Bruce Ellis wrote:
> i could only presume that the #includes are expected to be in the first
> block.
that would be all right, I suppose, but I didn't think the go command
compiled C programs as well
(or at least, that's what I'd read). It's a bit like PIP, though, so
On 18 February 2013 19:23, andrey mirtchovski wrote:
> sorry, not all source files, just the 'import' section.
I could see the relevance of reading the contents 7 times (since there were
separate go clean requests), but
it wasn't clear to me why it was apparently reading 4k from each file in
th
On 18 February 2013 19:23, andrey mirtchovski wrote:
> sorry, not all source files, just the 'import' section.
In nemo's example, it seemed to have wandered off into go/src/cmd, reading
4k from everything there each time, which began to add up,
if I've read the iostats correctly.
As to caching
On 19 February 2013 01:36, Charles Forsyth wrote:
> I wonder if there's something about nemo's example
> that gets {go clean ...} wandering through all the src/cmd stuff so often.
>
One difference is that I had floren's code outside the go tree, although it
would sti
On 18 February 2013 15:02, erik quanstrom wrote:
> since nested functions are not allowed, applying nested scope seems
> a bit odd.
>
Nevertheless, that is what it is.
On 18 February 2013 13:02, Comeau At9Fans wrote:
> seems to be doing is setting up allowing the call to compile and once that
> is satisfied then the subsequent definition "has" to match it, as perhaps a
> way to do type punning.
No, the compiler is simply applying scope rules. Without that inn
No, but the value at least isn't bizarre. It would be correct for rloge as
an array, and i assume it gets through because of the way the
array->pointer change is done. Even so, if it had been GCC, by now it would
be an essential extension, and have been used to implement an elisp
interpreter, shave
I couldn't get the vbox I downloaded to work properly with Solaris.
Several hours of my life are missing.
On 1 February 2013 02:39, ron minnich wrote:
> vbox is a useful bit paperweight. Maybe you have too many bits, and
> they might float away. Use vbox to hold them down. If you ever need
> the
On 31 January 2013 17:44, Rox 64 wrote:
> If I wanted to implement human beings, physical laws, an universe and an
> operating system inside a missing text editor inside a Lisp interpreter on a
> C compiler I'm pretty sure I would add 1200 options.
That's a great summary. Thank you.
On 28 January 2013 23:37, erik quanstrom wrote:
> is the compiler free to assume that
> d2 has not been modified?
It's free to do it, but whether it ought to is another matter.
Your specific example has appeared once before, but I can't remember
the context and resolution
(it might have turned up
On 18 January 2013 18:43, trebol wrote:
> This is a shame... I was very happy with the multilingual point in the OS's
> design.
troff predated the multilingual part by a few decades;
its parent roff was even older.
Blue Gene
On 13 January 2013 18:00, Lyndon Nerenberg wrote:
> Charles, what sort of PPC hardware were you running on?
The distribution, I suppose, or something like it, and code we wrote.
I don't know of any publicly-available big-endian machines to test new things.
On 13 January 2013 17:45, erik quanstrom wrote:
> are you speaking of the distribution, or of plan 9 code in general?
> i was speaking of plan 9 cod
I'd be surprised if there are too many endian problems, because
everything I tried ran happily on PowerPC
which is usually big-endian.
On 13 January 2013 17:08, erik quanstrom wrote:
> i'm sure that
> we're in a similar situation with endianness, but perhaps even
> worse.
Sorry, I was unclear, and mixed the reply in with some extraneous comments.
I'm afraid none of the documentation for Plan 9 or Inferno has been
translated into Italian.
The only Italian documentation I've seen is Inferno material at
http://basile.web.cs.unibo.it/inferno/
(I don't know whether it'
Unfortunately it coincided with a period during which people with no
apparent previous link to Inferno or Plan 9
were offering to translate to different languages, with a slightly
strange follow-up, and we thought it was another one of those.
I don't think any of the papers let alone the manual pa
The first Python port aimed at a so-called "native" port but as I
worked on it to import a newer version of Python, it became clear that
Python's standard libraries, certainly as used by most Python
applications, are so closely bound up with POSIX interfaces (eg, the
exact components of the stat st
and 0x8000 is thereby unsigned int, which changes the nature of
the comparison.
On 2 January 2013 15:53, Charles Forsyth wrote:
> those are being done at compile time.
>
> On 2 January 2013 15:07, erik quanstrom wrote:
>> i get the same results for all compilers:
those are being done at compile time.
On 2 January 2013 15:07, erik quanstrom wrote:
> i get the same results for all compilers:
Sorry, I was unclear, I meant stat("" ...)
On 22 December 2012 15:59, erik quanstrom wrote:
> , although I don't know
>> anything that relies on that.
I don't think either of those is a special rule, or undocumented.
Indeed, I can't think of any behaviour that isn't covered in section 5.
Following an attach, you're at the root, and a walk with no qids will
leave you there, so stat will just work,
although I don't know anything that relies on tha
it's up to sched to handle nlocks, which it does, via delaysched.
On 20 December 2012 18:23, erik quanstrom wrote:
> why does preempted() not check up->nlocks?
>
> - erik
>
it doesn't say that taslock.5 defines free incompatibly: there's a
disagreement about lock.
free and taslock are being linked together, and both call lock, but
they have incompatible definitions for lock, most likely because Lock
is different in each scope.
taslock.5 defines lock; free calls it.
O
oh no, not MMX. SSE/SSE2 surely (ie, XMM)?
On 11 December 2012 00:10, Anthony Martin wrote:
> It is if you're using MMX registers.
MOVQ isn't a 32-bit instruction.
On 10 December 2012 16:42, Anthony Martin wrote:
> There's also a few instructions (MOVQ, EMMS, etc.)
I was explaining why the top bits of the mode were in qid.type
(replacing the older single bit directory flag at the top of
qid.path).
I wasn't saying which of those were important to which applications.
You could, of course, not bother to put QTEXCL in that set
specially, and then have special cas
cfs, fscfs
On 5 December 2012 12:39, erik quanstrom wrote:
> i couldn't find a single program that takes advantage of this
The qid.type is defined to be the top 8 bits of the mode.
See the end of intro(5) and the discussion in stat(5).
On 5 December 2012 09:41, Pavel Klinkovsky wrote:
> I really do not understand why such a redundancy (QTEXCL/qid and DMEXCL/mode)
> is there...
The reason for having those bits in the qid.type is because the qid is
returned on open,
allowing (say) caching programs to discover directory/not
append-only/not and other details
without needing another transaction (and a race) to stat the file.
On 5 December 2012 11:01, Charles Forsyth wrote
I see. That might be tedious.
On 3 December 2012 14:58, Kurt H Maier wrote:
> This may be true, but this is not what is being taught at the university
> level.
>> C++ and java feel highly inconsistent and are full of stupid busywork
>> and strange programming philosophies that you have to "learn" about,
I've written programs in both languages and you don't really have to
worry about the philosophies,
if by that is meant things like the Pattern stuff, whe
Oh. I think you might still have to tweak the result by hand, because
the calling conventions are different.
Then again, if you're linking it with something else using the same
conventions, it will work.
On 3 December 2012 10:11, Charles Forsyth wrote:
> Perhaps you could do the transf
Perhaps you could do the transformation using a sam -d script.
I've done that incrementally by hand in the past, I think, for 68k not x86.
On 3 December 2012 10:02, Jens Staal wrote:
> Alternative ways of dealing with GAS ASM and still get native object files are
> also welcome :)
My problem is that the kernel is not currently capable of supplying
what Erik defines, to the process level even internally,
and even for his described applications (delays of a small interval,
tiny retransmission times), it's not clear that the traditional sleep,
which has
*always* been sloppy, is
well, that's ok.
On 28 November 2012 21:43, Bakul Shah wrote:
> And in any case why stick to an artificial choice made decades
> ago when it gets in the way of at lease some applications?
> Seems best to get rid of the fixed 100Hz clock and allow as
> fine a timer resolution (& accuracy) as a par
If you look at the manual pages for nanosleep, clock_nanosleep and
others on Linux you'll see that they have many bits
of advice, BUGS notes, and other statements to the effect that the
standard things do not work well, and most need some
sort of real-time support to do anything sensible. An earlie
RTT computation isn't the problem. you're going to use a multicore
numa 64-bit processor to clock edges into a simple device register at
microsecond resolution without any attempt at timeliness? seriously?
On 28 November 2012 19:38, Bakul Shah wrote:
> RTT
> computation as Erik pointed out. If y
No, I don't think it is, in this case. I really don't see many
applications deeply yearning for tiny sleeps and naplets.
On 28 November 2012 18:58, Bakul Shah wrote:
> Chicken and egg.
Because they claim to be providing a service that's not actually being provided.
On 28 November 2012 13:30, erik quanstrom wrote:
> why do extra zeros on the right bother you?
No, really, I'm quite serious. A grep of /sys/src/cmd/ suggests that
most sleeps are relatively large, and arbitrary.
None of the applications look likely to need microsecond let alone
nanosecond resolution, and that seems reasonable to me.
One exception is sleep(0), but that's yield()
If I want t
the relative unimportance of sleep?
On 27 November 2012 23:19, erik quanstrom wrote:
> why is sleep(2) limited in resolution to HZ in the
> portable code? the underlying mechanism is often
> much finer grained than HZ, and if there is a limit,
> one would think that it's related to the hardware
/runtime/runtime.h: uintptr n; // number of parameters
./src/pkg/runtime/thread_netbsd.c: uintptr nout;
./src/pkg/runtime/cpuprof.c: uintptr nlog;
On 22 November 2012 12:39, Anthony Martin wrote:
> Charles Forsyth once said:
>> On 22 November 2012 03:44, Bruce Ellis wrote:
>> &
It was changed in Ritchie's own compiler in v7 as I noted earlier.
It was that, use long, or limit your sizeof'd data to half the 16-bit
address space.
On 22 November 2012 11:54, Steve Simon wrote:
> I wish I had been in the standards meeting with a big stick when somone
> suggested sizeof() retu
It was in v6 (and a nasty bug):
/*
* sizeof gets turned into a number here.
* Bug: sizeof(structure-member-array) is 2 because
* the array has been turned into a ptr already.
*/
if (op==SIZEOF) {
t1 = length(p1);
p1->op = CON;
p1->type = INT;
I meant, "detect code". It's easy to find: just look at libflate, but
there were many more.
On 22 November 2012 11:32, Charles Forsyth wrote:
> it's quite
> hard to find code (automatically) that assumes they are 32 bits.
To try to clarify: most existing Plan 9 code doesn't worry about the
actual type of sizeof or pointer differences.
They assume int/long or uint/ulong. It's obvious from this discussion
that hardly anyone noticed usize.
Since its introduction years ago, grep shows that only kernel code has
used usiz
On 22 November 2012 11:00, Richard Miller <9f...@hamnavoe.com> wrote:
> OTOH, it's not worth making special provision for physical memory addresses.
> I think that any code which is dealing with those is not likely to be
> portable to another architecture for many other reasons. I can't envision
>
I hadn't noticed that particularly, but having grep'd the source, I
see it's also used for variables that are counters and numbers of
things.
Is that right too? I suspect it's more out of expediency. Some other
type usage looks odd too. int32 where int would do. Curious.
On 22 November 2012 03:44,
That will obviously work, and indeed I use uintmem the same way to
avoid having yet another type,
but that's only because that's specific to the kernel, and of little use.
Otherwise, I think there's a difference between storing a pointer
value in an integer, and storing a size.
For one thing, many
By which I meant that yes, it's legal ANSI C code to combine them. The
strange way the compiler implements volatile references probably led
to that odd diagnostic.
As I said, I'd try nopping the volatile.
On 21 November 2012 13:30, Charles Forsyth wrote:
> static is scope, volatil
>static volatile svn_atomic_t cache_init_state = 0;
svn_atomic_t? has it got its own thread library? coroutines?
static is scope, volatile has dynamic effects, very dynamic. you
should be able to #define volatile
to nothing (-Dvolatile'=') and it will usually work. certainly for
statics and externals.
the one real effect it might have is on automatic variables if the
usage in conjunction
with setjmp is a litt
local paging algorithms can avoid thrashing: "the process pages against
itself".
global paging algorithms typically do not (invariably do not, in my
experience, but most people use essentially the same one, so there might be
some that worked).
Wilkes has a nice discussion of paging algorithms as a
We'll see.
I'll reiterate my original remark that it would be worthwhile tracking down
and fixing the virtual memory or paging bug in sources plan 9,
not necessarily to make use of paging, but to ensure that the paging
problem isn't just a symptom of something else that normally gets by.
If 9front
There's a non-trivial chance that what now goes wrong with paging
(which did once work, even if it isn't great) is a symptom of a bug
that afflicts the virtual memory code itself. (For instance, a page unlocked
during a critical period, a race, and so on.)
On 2 November 2012 19:18, erik quanstro
There has been a storm, I believe.
On 31 October 2012 10:13, kali wrote:
> is it still offline ? the name doesnt even resolve.
"But my point was that a programmer should understand the standard"
But suppose the standard does not evidently aim to be understood, in the
generally understood meaning of "understood",
or there are more words in the standard than will ever appear in the
programmer's own programs?
Worse! "Standar
He can fool it once, but can he fool it twice? Can he recompile?
On 29 October 2012 22:35, Bakul Shah wrote:
> But it is easy to fool compilers to do what he wanted
I don't see any problem with having to talk to invisible firmware.
Surely that's normal for devices with firmware?
In this case, it seems even better for Plan 9, because the OpenGL/ES engine
is in the firmware,
so we don't need to write or port one, just talk to an existing one.
It's similar situat
Blocks are intended for IO.
On 19 October 2012 22:49, erik quanstrom wrote:
> Block*s (well at least the buffer)
> needs to be special because the ethernet on the marvell is not
> cache coherent.
>
I think it's better to specify memory that must have special cache
properties, rather than assuming that everything is.
Try compiling under iostats.
On 19 October 2012 19:45, wrote:
>
> What I don't understand is where the 386 compilation finds the int32
> definition missing in arm. I lo
http://planb.lsub.org/ls/octopus.html
is a user interface that includes graphics, exploits name space
representations, and doesn't just mimic the xerox desktop.
the qopen sets the queue limit to 8k, which seems a little low, unless it's
reset later.
the later unchecked qpass (with comment) will toss the data away, which is
a little drastic.
On 29 September 2012 22:46, Richard Miller <9f...@hamnavoe.com> wrote:
> It often gets about 8k at a time (a comple
I don't see how it can do it.
On 19 September 2012 09:48, Steve Simon wrote:
> I am happy if the answer is "Brdline() cannot do this", I just feel like
> I am missing a trick, and there is elegant solution.
>
And a cleaner link to that: http://research.swtch.com/acme
On 17 September 2012 19:24, Charles Forsyth wrote:
> And this just in:
> ...
>
And this just in:
http://research.swtch.com/acme?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+hnycombinator+%28HN+-+hnycombinator%29
"Copy" is a little strong: inspired by, certainly, by way of help/help,
but there's an amazing difference in the structure of acme as "text editor
as file server"
with many independent clients accessing it through the file system.
Oberon had a more conventional module "plug-in" structure within a s
Probably never heard of Oberon either.
On 14 September 2012 15:07, Lucio De Re wrote:
> Still, Oberon had all that a long time ago, if memory isn't betraying
> me.
>
Probably never heard of Acme.
On 14 September 2012 14:12, dexen deVries wrote:
> Seems a well-meaning developer sort of re-invented Acme
> http://www.youtube.com/watch?v=bUR_eUVcABg
>
> --
> dexen deVries
>
> [[[↓][→]]]
>
> I'm sorry that this was such a long letter, but I didn't have time to
>
That's a bit elaborate. vt(1) might be easier.
On 12 September 2012 15:30, Matthew Veety wrote:
> You can make a telnet client that dumbs down the stream to your terminal.
> Telnet is trivial to implement.
n 10 September 2012 10:45, dexen deVries wrote:
> On Monday 10 of September 2012 10:42:12 Charles Forsyth wrote:
> > From GNU programs you will then get moans about the terminal:
> > %TERM=dumb
> > % man date
> > WARNING: terminal is not fully functional
> > - (pr
>From GNU programs you will then get moans about the terminal:
%TERM=dumb
% man date
WARNING: terminal is not fully functional
- (press RETURN)
because it doesn't emulate a device that was last built decades ago.
At least they don't demand 3270s.
On 10 September 2012 10:20, Aram Hăvărneanu wrot
No, I didn't explain it well.
NETPATHLEN isn't named in the manual pages, so ndb/dns doesn't use it.
On the other hand, dial does, but because it's ...LEN, it's an easy mistake
to think of it as the length of a string, which wouldn't include the
terminating zero byte,
instead of the length of the
it makes perfect sense: if the length of the path is NETPATHLEN, length of
a string usually referring to
non-zero bytes, you need to allow for the terminating zero byte.
unfortunately, as you describe, it's a bit pointless because the dnsresolve
callers rely on the manual page
("The path name is gu
You'll need to use Inferno's auth/ai2key to convert the keyring file to the
form used by that infauth.
On 7 September 2012 09:48, Jiten Pathy wrote:
> thanks ! :)
>
> On Thu, Sep 6, 2012 at 9:40 PM, Charles Forsyth > wrote:
>
>> http://www.vitanuova.com/dist/iauth/iauth.tgz
>>
>>
>
spki/source/browse/trunk#trunk%2F9%2Ffactotum.
> I will try and see the current status.
>
>
> On Wed, Sep 5, 2012 at 11:55 PM, Jiten Pathy
> wrote:
>
>> can you point me where ? The official factotum has p9any and p9sk* but
>> not infauth support.
>>
>>
yes, there are bits for both plan 9 and p9p factotum.
On 6 September 2012 11:17, Jiten Pathy wrote:
> Hi,
> I was looking at the auth mechanisms for inferno. Anyone have done any
> work to add support for inferno's public crypto auth mechanism based on
> diffie-hellman to plan9 factotum ?
>
> Re
Little-endian mips.
On 6 September 2012 05:12, Skip Tavakkolian wrote:
> spim not spin?
>
> On Wed, Sep 5, 2012 at 7:51 AM, erik quanstrom
> wrote:
> > i was wondering what use the spim compiler had been put to, and
> > if this use is still active. does anyone know?
> >
> > - erik
> >
>
>
Just modifying a configuration file, and substituting
nocache.c and noswap.c (you won't have them, but they're easy)
to eliminate the devmnt cache and the pager, I can get
8l -o 9pctiny -T0xF0100020 -l l.8 plan9l.8 cga.8 i8253.8 i8259.8 kbd.8
main.8 memory.8 mmu.8 random.8 syscallfmt.8 trap.8 pcti
it's a shell script that copies updated files from a Bell Labs system to
sources.
The observation was that people at the time were adding clumsy
programming-language features to make,
which then executed commands it didn't really understand (ie, couldn't even
parse them),
and might it not be better just to add dependency operators (and others as
needed) to a well-designed comman
That's true, but the C compiler also does each .c in parallel up to NPROC.
On 30 August 2012 18:18, erik quanstrom wrote:
> > Even more common than reduce is map. No reason why you can't
> > parallelize
> >
> > 8c *.c
>
> we already do—with mk.
>
The source of mash as VN inherited it from the defunct Lucent organisation
on 1 September 1999 remains in the tree,
so it wasn't lost.
On 30 August 2012 16:13, Charles Forsyth wrote:
>
> On 30 August 2012 16:13, Lucio De Re wrote:
>
>> Inferno (Vitanuova) released a &qu
Errr ... no. Twice: mash was not VN code but brucee's preemptive strike
against a POSIX shell for Lucent's Inferno;
VN's Inferno had a shell with a different style done by Roger Peppe.
On 30 August 2012 16:13, Lucio De Re wrote:
> Inferno (Vitanuova) released a "mash" a ways back, but apparently
As another example, also from Flex,
J M Foster, I F Currie, "Remote Capabilities", The Computer Journal, 30(5),
1987, pp. 451-7.
http://comjnl.oxfordjournals.org/content/30/5/451.full.pdf
On 30 August 2012 15:45, Charles Forsyth wrote:
> If you look at the paper I referenced, you
If you look at the paper I referenced, you will. Similar abilities appeared
in systems that supported persistence and persistent programming
languages (cf. Malcolm Atkinson, not Wikipedia).
On 30 August 2012 14:33, erik quanstrom wrote:
> i don't see that the os can really help here.
typed command languages:
I F Currie, J M Foster, Curt: The Command Interpreter Language for Flex
http://www.vitanuova.com/dist/doc/rsre-3522-curt.pdf
501 - 600 of 1197 matches
Mail list logo
