>>"Web sites and HTML5 run best when they run natively, on a browser
>>optimized for the operating system on your device."
>A more generalized form of the above statement would not be devoid
>of fact.
it actually misses the point: once the processor has waded through a vast array
of code
that
>Frankly I'd be more interested in a video player (just a few common
>codecs that's all) than a modern web browser.
that's possibly feasible.
>why is everyone on about native web? what does that even mean?
good questions. i liked that reference, which i hadn't seen before.
>let's abstract away differences between platforms
but they don't `abstract away': they enumerate them.
> complaining is because you _need_ linux... to furnish all the things
> you can't do with plan 9 - either personally, or within your organization.
it's true, but at least i haven't got to run either Windows or MacOS.
the underlying problem is that the things we might simply import (mainly
brows
> [1] For those gnashing teeth over glibc - might want to check out
> musl libc. It's no plan 9 libc, but it's definitely "less worse" than glibc.
``News: As of version 0.7.7, musl has been successfully bootstrapped by a
third-party system integrator.''
hmm. they had to do more than just compil
>Compiling glibc (on Linux) usually takes over half a day.
you're not counting iterations where something goes wrong, as it always does
for me.
> Observation 1: There doesn't seem to be any provision for moving a
> directory from one directory into another directory; that is, moving
> it to a different directory on the same file system.
>
> Observation 2: There doesn't seem to be any support for hard links.
In http://cm.bell-labs.com
>I'm still not sure a length limit on the string of 1 Gbyte makes
>sense, and I have no idea if 64K is too low, but the 64k-limit patch
>does make it all work. I'm going to try to apply it tomorrow and see
>what shakes.
at some point, a value
ep = bp + lim
will be formed. if bp+lim is too
>also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach)
>structure (depending on if up is set or not), so the maximum sprint
>to something on the stack is always going to be < 4k.
that's fine, but the sprint is the one from the c library
which needs to support more than that. t
in fact, even 64k might be too big a value for the given buf if it's near the
top of memory (eg, a local variable on a stack that's in high memory);
the PowerPC reference in the original comment is misleading because that
was just a particular system where the general problem appeared.
>+ n = vsnprint(buf, 65536, fmt, args);
...
>Note the len = 1 << 30; why was that ever done? I never figured that out
there is nothing to limit the length of a string to 64k bytes
PSDoc is fully declared in ps_util.c but not
ps_list.c because only ps_util.c includes ps_intern.h
which provides the full declaration.
in ps_list.h, DLIST refers to PSDoc in the declarations of DLIST.malloc
and DLIST.free, so the type of DLIST in ps_list.c (ps_list.8) is not
the same as the type
it means that dlst_freenode is declared as one type in the scope of pslib.c
and another different type in the scope of pslist.c, which is wrong.--- Begin Message ---
the error message is like this:
8l box.8 pslib.8 ...
??none?? incompatible type signetures c2d44e4 (pslib.8) and affc2df4
(pslist.8)
>ah, that's the c type system.
not exactly: ansi changed it.
the original one had unsigned as an attribute that remained despite changes of
word length.
ansi changed it for various reasons to `value preserving' from `unsigned
preserving'.
>and 8l will sort it out.
by which i meant: you then don't name any libraries at all,
since 8l will pick up the names from the references in the
include files. and therefore, as well as not having to name libf2c.a,
> you shouldn't need to mention libap.a,
the solution is to add
#pragma lib "/$M/lib/ape/libf2c.a"
to the include file that f2c's generated code uses,
and 8l will sort it out. you shouldn't need to mention libap.a,
either, since something should be including an ape include file
(and those have the #pragma libs)
>just curious is it normal for 8l to follow some sort of precendence
>based on the commandline? this being done through ape/pcc
it seems fairly logical; the procedure is somewhat unsportingly documented
in man page 2l(1).
>Removing -T from the compiler option seems to allow me to compile with
>no problems. The resulting compiled code seems to run just fine.
in many cases, that will be true, for instance because void* and int* are the
same
size and interchangeable, and both point to something. (even then, int* and
the bug is calling wakeup(r) on deallocated r.
sleep and wakeup communicate about the event represented by r,
not the structure containing r.
i think it might be helpful to have a transport protocol along the lines
of Bryan Ford's SST, which allows a stream to create substreams
with separate flow control and other attributes. a primary 9p stream
might create a substream for a large Tread or Twrite.
the facility could be emulated for exis
>usually with oversized log files.
sam -d, indeed!
> 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.
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.
>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
> >$ size /usr/local/bin/clang
> > textdata bss dec hex filename
> >228428621023204 69200 2393526616d3922 /usr/local/bin/clang
i suppose a more useful comment might be a question:
how does a C compiler get to be that big? what is all that code doing?
>you'll hear people call [fringe benefits] "French Benefits".
i did not expect that! i'd have guessed: `cheese'.
>$ size /usr/local/bin/clang
> textdata bss dec hex filename
>228428621023204 69200 2393526616d3922 /usr/local/bin/clang
impressive. certainly in the sense of `makes quite a dent if dropped'.
>Then set up a repo on a free place like bitbucket.
or github. wasn't that in the news lately?
>The docs I've read seem to
>suggest that gcc is kind of "glued onto the side of" Plan 9 proper.
it's kind of unglued off the side of Plan 9 proper: gcc came unstuck
(in more ways than one).
i'm afraid it's harder to port (or do i mean compile?) than it ever was.
and then there's glibc, which you
> So, what changes are needed to set it up for full 64bit?
i'm confused. why would you bother if you can only run 32-bit x86 code in vx32?
in the plan 9 world, a 64-bit kernel runs 64-bit applications,
and 32-bit applications run on a 32-bit kernel.
a 64-bit 9vx would run programs produced by 6[acl]
(well, in principle: it would need to be derived from the 64-bit kernel)
i've merged those additions into inferno-os on googlecode,
except for the change to mkconfig that forced arm objtype.
(use objtype=arm mk ... on Plan 9.)--- Begin Message ---
> i am trying to run inferno emu on plan9 running on sheevaplug.
>
> does anyone know how to build emu for arm? i am surpri
>Did I not allude to that when I used the word "daemon"?
not exactly. one important difference is that a file server in plan 9
"by definition" if you like interprets the 9P protocol.
there's no such guarantee for an arbitrary "daemon".
("That same daemon that hath gulled thee thus.")
> Am I close?
a Plan 9 "file server" is just a program that responds to the 9P protocol
described
in section 5 of the manual. (there is library support for writing a file
server.)
a file server can provide a service other than conventional data storage:
consider
rio, the plan 9 window system, a
things shouldn't be written to venti by existing software
unless there is (or soon will be) a root
that refers to them, so i don't think the copying scheme
would work as things stand.
>0xd000 (as it is on native Plan 9).
of course, that too can change, but i know you know that,
and the current go implementation was just to get going.
>I did not realize this was currently supported by Plan 9 ... maybe I
>didn't get the memo?
go's 8c/8l convert extern register to references off a segment register,
although the implementation of extern register isn't general enough for plan 9
kernel use;
it's just enough for go. it sounds as tho
i suspect go is using segment register(s) to implement extern register,
and that isn't expected (or perhaps even supported) by 9vx.
just a guess.
> I want to build Plan9 from scratch under Windows/*NIX.
> I built working (seems :) toolchain (yacc, 8a, 8c, 8l) under Windows
> XP using Open Watcom Compiller.
> Has anyone done something similar?
a few years ago, using the Inferno compiler suite, I built an
environment on Solaris/sparc to cross
I think it's fair to say that the IO path for fossil is
> considerably slower than the IO path for kernel-based file systems in
> Linux: slower as in multiples of 10, not multiples. There's a fair
> amount of copying, allocation, and bouncing in and out of the kernel,
for common applications you'd
>The way I move files to/from Dropbox and these other services is via
>streams, btw :-)
yes, and some streams are better than others, but i suspect (based on observed
behaviour and wireshark) that there are non-trivial delays and thus latency
visible within the stream. it isn't a nice stream of re
it's curious that people are still worrying about "local" file systems
when so much of most people's data increasingly is miles
away on Google, S3, S3 via Drop Box, etc, which model is closer if anything to
the
original plan 9 model of dedicated file servers than the
unix/linux model of "the whole
>ether1116.c:573: cachedwbse(&r->cs, BY2SE);
led me to read:
/* set up receive descriptor */
r = &ctlr->rx[ctlr->rxtail];
assert(((uintptr)r & (Descralign - 1)) == 0);
r->countsize = Bufsize(Rxblklen);
r
>On a system that supports dynamic linking this is trivial.
it's usually error prone, for instance there's no type checking,
and dangerous: the main application crashes each time a plug-in blows a fuse,
because dynamically loaded things are simply read in to the same protection
domain.
in your p
>exportfs never detects this bit being set. i would expect the
>type to be 90, not 80 in this example ...
>; mkdir q; mount /srv/boot q; ls -qd q
>(0001 48 80) q
i wouldn't! it's not set on the *mounted* file system in the scope of exportfs
but on the file (/srv/boot), once opened, t
QTMOUNT allows exportfs to detect an attempt to open a /srv file
that has been opened and mounted somewhere on the system running exportfs
(i'll refer to that as the `called system' and the client of exportfs as
the `calling system').
exportfs opens the /srv file, mounts that file descriptor itsel
> I'm running on 9vx, so I can imagine some random interaction there (I can't
> justify the power bills to keep a plan9 386 box going these days given the
> frequency I use it).
the atom boards are not too bad.
my 9-collection no longer heats the loft,
and there was a we-e dip in the e-bill for e-
>i'll see how those compare with sources.
i can't get 5c to fail when compiling rc. ghostscript might be another matter;
i haven't tried that yet.
>hmmm works on all 5cs i have. charles will fix the glitch, maybe.
it seems to work with the ones i've got.
i'll see how those compare with sources.
>unfortunately, there's just not enough bits to easily export
>(an export)+.
i think that works: it checks for clashes.
>i'd say it's a bug. fossil could easily reserve some number of bits
>of the qid (say 20 bits) to make the files in the dump unique
>while still allowing space for a sufficient number of live files.
that's possibly closest to the intent of the qid discussion in intro(5),
although
it's not clear t
>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:
>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 bra
> 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 inte
> A honest question: what is the rationale for merging functionality of make and
> shell into one?
at the time, people were pushing more and more scripting or programming language
functionality into accretions of the original make, and someone observed that
it might be better
instead to put a sma
>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 interes
funnily enough, i know someone who needed one of those last week.--- Begin Message ---
HAHAHAHAHA
--
cinap
--- Begin Message ---
scour my mail, send me this, and i'll laugh
http://www.limbo.com.au/
--- End Message ---
--- End Message ---
> Let's try to define 'decent' for this thread -- a decent fileserver is one
> on which close()s do not have any client-visible or semantic effect other
> than to invalidate the Fid that was passed to them. Lets see how many file
> servers we can think of that are 'decent': fossil, kfs, ken, memfs,
>I think functional programming or at least category theory gets you into
>these upper level abstract ways of thinking
uh oh. is there an analogy to Godwin's Law for mentioning category theory?
>on the other hand inferno's sys-export(2) services all requests
>(except Tflush) asynchronously,
>so the race will always be present.
no, that mistakes the problem. without the change, the issuing process
will see the clunk completed before it attempts any further operations:
no race. with the ch
>i don't believe that is possible in my implementation. will check.
it was your implementation i was testing.
>having the original process send the Tclunk and not wait
>for the Rclunk is different.
ah. having thought about it, i see it's different only in the case of
one process. it isn't different if you have several processes that are
trying to co-operate in an allowed way: failing to let the issuing
pr
>Do you do completely asynch clunks or just the wait for the response?.
it uses `completely' async clunks, which is why it can be broken.
having the original process send the Tclunk and not wait
for the Rclunk is different. i think it was mentioned last time this
matter came up, and that's probab
>in practise, there is no race if the tree is being imported via
>plan9's exportfs(4)
>because it services clunk requests synchronously.
there is indeed a race because another process is issuing the clunk(s),
not the one that's doing the open(s).
> things up with standard (as opposed to synthetic) file systems?
why should a "synthetic" file system (actually they are all synthetic, i think)
be considered not "standard"? i thought file systems were the common currency
in the system.
>What you are saying is that the problem could be something like:
>-> Tclunk
>(do not wait for response)
>-> Topen (the file is exclusive)
no, because what actually happens is closer to
A: Topen
...
queue request to *another process* to send Tclunk
...
A: T
>Also, if that is racy, isn't this at least analogous?
i don't think so: that instance is entirely at the discretion of the programmer.
it would be analogous if the text of the program actually contained `spawn
clunk(f)',
but i was trying to represent the effects of the rewriting the system would
you're essentially replacing
f := open(name, ...)
...
close(f)
which runs as a sequential process, and subject to the usual rules for
sequential
composition, by
f := open(name, ...)
...
spawn clunk(f)
which introduces a race with an invisible anon
>Sorry that wing-commander can't package it for today.
sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but
one of the sprogs had a prang with the bally old semantics and the other brass
hats ordered it back to the boffins
>http://reflex.gforge.inria.fr/
that's certainly remarkable.
>The transition from a stream to the packet-oriented file IO protocol has never
>been comfortable.
`RPC-oriented' might be more accurate than `packet-oriented', given the
way that streams are implemented.
> if i am right, charles was planning to give a session on inferno
> roadmap or something in the 5th plan9 workshop. did it happen?
i was asked to do it some time ago, but it wasn't in the schedule,
and i didn't notice that until too late.
Ron's changes emulate the following linux/cnk calls:
[4] {"write", sys_write, 3, {.i = -1}},
[5] {"cnkopen", sysopen, 2, {.i = -1}},
[24]{"getuid", cnkgeteuid, 0, {.i = -1}},
[45]{"cnkbrk", cnkbrk, 1, {.i = -1}},
>and then an appropriate sequence of byte-by-byte loads (or stores) will be
>used to access it,
for static references such as s.c there's an optimisation that allows the
nearest
aligned values to be loaded, shifted & masked, and or'd together to save
accesses
by byte, but that doesn't seem to be
actually, it gets worse. i looked up the stuff for ARM, and it was much
as i expected, but they also pointed out another problem, obvious in retrospect.
you say you want structure assignments to work, or at least not
fail. fair enough, but what about this:
S s;
int *p = &s.c;
>Example: Xen 2 used __attribute__ packed heavily, realized at some
>point it was a bad idea, and took another path.
at the time, gcc on arm didn't generate the code to fetch or store the values a
byte
at a time, which probably came as a surprise. i haven't tried it myself with gcc
more recently.
>It's the compiler's prerogative to decide just how
>the fields should be packed so therefore, the construct is never portable.
it's worse than that: you can't use them to access hardware structures, since
(especially if values are misaligned) there's no guarantee that the generated
code will acce
since it's a pragma, i suppose it shouldn't affect correctness.
still, i don't know how far down this route i'd like to go.
i'd actually plump for disabling the pragma.
(realistically, most of the original reasons for it have vanished,
since so much stuff is in gcc or c++.)
still, what are you usin
when i can't use cpu and secstore to log in directly, i use netkey.
there are non-Plan9 implementations of netkey.
i think i've got a Java version somewhere.
>Would I be right in thinking that 9p originally had 16 bit fids? If
>so, it suggests that no-one has used kfs in anger for a while.
how are you using the kfs? just locally?
a plan 9 client normally re-used fids, so i'd have thought you'd need to have
>32767 active files,
which most people probab
> It's probably time to move past "lp". They don't exist much anymore
> in the real world.
has anyone ported CUPS? i just wanted to check whether someone should be burnt
at the stake.
>There should be some macro packages out there that
>fit particular universities' requirements.
oh. if there were whacky requirements (i think the main one
for me was a now-obsolete requirement for 1.5 spacing) i tweaked
settings as required. it was fairly minor effort (and i don't
typically under
>2) I heard and read that the 'ms' troff macros are not suitable for
>longer documents (I want to write my PhD thesis), as opposed
>supposedly to the 'me' macros (which, however are not in plan9, I
>believe). Can anybody give me their opinion?
i don't see the problem. i've used -ms without fuss on
>that avoids the exploding 9vx problem. But we need to get a real fix.
i'm sure i posted the real fix to the list (essentially issuing CLD at specific
points).
in rcinputproc
s = setecho(sfd, 0);
if(write(rcfd, pair.s, pair.ns) < 0)
threadexitsall(nil);
if(s)
setecho(sfd, s);
there's a race between setting echo off, writing to rcfd, resetting echo and
the read
>Perhaps we could turn on async clunk for other files when the chan has
>CCACHE set (mount -C iirc). We already believe that the fileserver is
>'decent' then...
that's more plausible, since you've declared that you're not interested
in certain details, but then the larger question arises: why pick
>Research Inferno has ha async clunks on 'M' for 15 years with no
>problems, just no deadlocks.
>Think about it a bit.
there is a simple and obvious test program that fails unpredictably under that
regime
but works in the other systems, and would be expected to work.
>close must be synchronous, unless you aim for NFS semantics.
to be more explicit: think of exclusive-use services, services that wait for a
close to commit,
files with DMEXCL, and files opened ORCLOSE
close must be synchronous, unless you aim for NFS semantics.
plan 9 will hand the work to a service process [only] when a process is
interrupted by a note
during a closefgrp (eg, when a file-group is closed when a process exits), to
allow
deadlocks to be broken (by a note), or to compensate for d
>Is one interrupt being dispatched to two cpus, I wonder?
even so, that should be fine, but ether8169.c doesn't seem to make much use of
the rlock it declares.
>Or is it bigger than that?
the go toolchain is replete with go-specific things,
and produces incompatible .8 files (and perhaps for other architectures),
because of the way certain changes were made.
as russ suggested, it's probably easiest just to have a /bin/go
and put go/8c, go/8l etc in that
>Would you try %luX? It may work better?
he's calling printf, not print
it's interesting that neither of philippe's changes,
however justified, make any visible difference
to 9vx on my ubuntu 10.04LTS system: 9vx still
fails almost immediately. that's consistent with
9vx behaving itself as well as on any other platform
until i changed the linux and/or ubuntu version.
i
>Is it more reasonable in this case to name the executive vx32 instead of
>9vx since it is a plan 9 emulator for linux?
not really, because vx32 is the library, and 9vx is just one sample application.
(there are others.)
i wasn't clear enough what i meant by `interrupt handler'. i didn't mean
the device-specific function, but its caller. in pc/trap.c you see
if(up && !clockintr)
preempted();
and on other platforms (perhaps not enough) there are calls to preemp
>in Linux parlance, Plan 9 is a "preemptible" kernel. Interrupt handlers can be
>interrupted, so to speak.
interrupt handlers are not normally interruptible during the interrupt
processing, but rather at the end (eg, when anyhigher, anyready or preempted
is called).
processes running at non-inte
>Maybe newer GCC versions are causing trouble?
the 9vx that doesn't work for me is one that was compiled
over a year ago and has run happily on several Ubuntu and other
Linux versions until Ubuntu 10.04LTS. although i realise that
thanks to shared libraries, compiler variations could still play
a
>If you run it -g, what happens?
init: starting /bin/rc
1416: signal: sys: segmentation violation
>You don't get to change the license
``3. REQUIREMENTS
A. Distributor may choose to distribute the Program in any form under
this Agreement or under its own license agreement, provided that:
...
c. if distributed under Distributor's own license agreement, such
license agreement:
801 - 900 of 1197 matches
Mail list logo
