Re: [9fans] any updates on go for plan9/arm?

On 31 December 2015 at 11:57, Richard Miller <9f...@hamnavoe.com> wrote: > Raspberry Pi 2, but has an elusive "one last bug" which I suspect has to > do with cache or page table coherency. > It's still got the explicit cache management code from the old bcm, which isn't right. There might be

Re: [9fans] bug or feature ? --- ip/ping -6

On 30 December 2015 at 12:48, arisawa wrote: > code is simplified. It works better, but it's smaller? With luck, you might start a trend!

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

On 25 December 2015 at 03:03, wrote: > > the functionality that is desired is to be able to "negotiate" the > cipher suits and record layer protocol versions. I could never work up much enthusiasm for TLS because it is needlessly big and complex, but still got

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

On 29 December 2015 at 18:34, Charles Forsyth <charles.fors...@gmail.com> wrote: > extension of the protocol to the occasional new protocol. Sorry, that second "protocol" was supposed to be algorithm or technique.

Re: [9fans] Peter Bosch's TV software

On 2 December 2015 at 19:14, hiro <23h...@gmail.com> wrote: > > > Go personal to Peter Bosch at Lucent. That would be Cisco.

Re: [9fans] unmount

On 1 December 2015 at 03:24, arisawa wrote: > current kernel allows unmount even if after rfork m. > this feature makes sandboxing difficult. > can anyone explain this feature is necessary? > For some applications, similar to ftp or http, I've built a name space

Re: [9fans] Undefined Behaviour in C

On 26 November 2015 at 11:37, wrote: > Plus, in C, 0 is used as a truth value for false... > That doesn't say how a 0 value for a pointer is represented; it's just how it's written in the program text. The compiler knows the types and can convert (same as double = 0). In

Re: [9fans] Compiling ken-cc on Linux

That copy of the compilers was changed quite a bit by someone else, and I only belatedly realised that. I'll try to resurrect that one, since it would help me keep the Plan 9 and Inferno compilers in sync, as well. On 25 November 2015 at 17:24, Vasudev Kamath wrote: >

Re: [9fans] Compiling ken-cc on Linux

On 25 November 2015 at 17:10, Vasudev Kamath wrote: > In file included from > /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, > from 9obj.c:5: > /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and >

Re: [9fans] Undefined Behaviour in C

On 26 November 2015 at 16:42, Brantley Coile wrote: > I’m still kind of dubious that there are any structures where one would > not catch a null pointer. > I don't think there are any. In practice, ome other value lower down will be accessed first. Unless the compiler

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 18:15, Ryan Gonzalez wrote: > the only library on earth that makes me want to bang my head on the floor. There must be others, surely. What about graphics libraries with APIs designed for FORTRAN (no data structures)? What about ostensible crypto

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 21:49, Ryan Gonzalez wrote: > All that is bad...but glibc is worse. The issue is that you kinda *have* > to use it, true, very true.

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 21:51, Charles Forsyth <charles.fors...@gmail.com> wrote: > On 26 November 2015 at 21:49, Ryan Gonzalez <rym...@gmail.com> wrote: > >> All that is bad...but glibc is worse. The issue is that you kinda *have* >> to use it, > > > true,

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 22:02, Ryan Gonzalez wrote: > I remember the time I was trying to build LLVM+Clang on Windows in debug > mode. Because...MinGW...I actually surpassed the file size limit when > linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an >

Re: [9fans] Undefined Behaviour in C

On 26 November 2015 at 23:14, Steve Simon wrote: > I don't know about the PDP but the VAX allowed access to address zero. Not in my port.

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 23:08, Ryan Gonzalez wrote: > Holy crap, that's crazy. I built it in debug mode on Linux, but I don't > think it used that much. I only have 6 GB right now! You have to remember that a C compiler is one of the largest, most complex software components

Re: [9fans] Undefined Behaviour in C

The link to the lwn.net article explains that using mmap the naughty application mapped a page to virtual 0, which was then available in kernel mode in that process, and all they'd need to do is put their own "socket" structure at 0 + offsetof(struct tun_struct, sk). On 25 November 2015 at 10:43,

Re: [9fans] Undefined Behaviour in C

There is quite a bit there to work through, but I was struck by one of the responses to a gcc bug report: "you're leading to undefined behaviour - do you understand this simple fact? in such cases compiler can do *anything* with your code." I've seen similar comments before (about

Re: [9fans] Undefined Behaviour in C

On 23 November 2015 at 11:32, Charles Forsyth <charles.fors...@gmail.com> wrote: > The Plan 9 C compiler is firmly in that historical tradition In short: http://www.terzarima.net/images/careful-now.jpg

Re: [9fans] Undefined Behaviour in C

On 23 November 2015 at 11:50, Brantley Coile wrote: > These bloated compilers can never be idiot proof because idiots are so > ingenious. One thing that struck me about that earlier gcc example, where the test for "tun" is eliminated because of bad compiler reasoning, is

Re: [9fans] Undefined Behaviour in C

On 23 November 2015 at 12:17, Brantley Coile wrote: > I've lived with the old definition so long that I didn't notice Plan 9's > definition, which is not a problem on today's architectures because there > are two equally efficient instructions to choose from. There are a

Re: [9fans] Undefined Behaviour in C

On 23 November 2015 at 10:20, Ramakrishnan Muthukrishnan wrote: > Had been reading the SOSP paper: > > As an example of how tricky it can be, one of their examples is const uint8_t *data = /* buffer head */; const uint8_t

Re: [9fans] About IL

On 20 October 2015 at 17:14, Adriano Verardo wrote: > Could IL be actually more effective than TCP/IP in a closed net ? > I think about a robotic application using very small cpus. > What about Styx -- ore something similar - over IL ? > Styx is (now) the same as 9P,

Re: [9fans] RUDP and/or others

On 18 October 2015 at 23:43, Aleksandar Kuktin wrote: > BAM! I run straight into RUDP. "Designed at Bell Labs for the Plan 9 > operating system". I just skimmed through the (expired) IETF draft from > 1999 and I honestly think the design might be too much. It looks like > it's

Re: [9fans] RUDP and/or others

On 19 October 2015 at 20:31, Aleksandar Kuktin wrote: > I seem to remember IL being more complex than just a UDP with counters > and ACK, which is what I'm - sort of - looking for. > I think you might find Plan 9's rudp is essentially that. Conversations are determined by a

Re: [9fans] Web Gardens

On 14 October 2015 at 04:29, Lyndon Nerenberg wrote: > The reference implementation: > > https://www.youtube.com/watch?v=ifmRgQX82O4 > No, it's https://www.youtube.com/watch?v=zIV4poUZAQo

Re: [9fans] Web Gardens

On 14 October 2015 at 09:32, Charles Forsyth <charles.fors...@gmail.com> wrote: > No, it's https://www.youtube.com/watch?v=zIV4poUZAQo > As usual, the official reference was short on the implementation detail. Try https://www.youtube.com/watch?v=QTQfGd3G6dg

Re: [9fans] Web Gardens

On 12 October 2015 at 23:43, Aleksandar Kuktin wrote: > but it could also be a "Walled Garden".. with shrubbery to hide data from outsiders and, for defence in depth, another shrubbery slightly higher for a two-level effect, with a little path for authorised users

Re: [9fans] Web Gardens

No, that's a web allotment On 12 October 2015 at 10:49, Staven wrote: > I thought a web garden was a hobbyist version of a server farm. > > >

Re: [9fans] off topic - a good Git reference

On 10 October 2015 at 19:25, Álvaro Jurado wrote: > While checking out it looses in any moment some sha key and then fatal. > Other times not. Why do you think that was fsync, and not something else?

Re: [9fans] off topic - a good Git reference

On 12 October 2015 at 17:49, Álvaro Jurado wrote: > what ensures sha key is in fs. The reason many of us are a little sceptical about it being fsync as such preventing the data appearing is that if the git function that writes the key does a write or pwrite, the key will

Re: [9fans] off topic - a good Git reference

On 7 October 2015 at 16:17, Álvaro Jurado wrote: > because it has an strong dependency of fsync to freeze sha keys in fs > during fetching. And that is just a dummy in Plan 9 ape fsync causes any operating system buffers in the "buffer cache" to be flushed to "disk" (not

Re: [9fans] Frogs?

On 5 October 2015 at 17:42, Kare Nuorteva wrote: > Could someone please explain what is a frog in a filename? It's many decades old, and not restricted to file names. It originally referred to an unexpected non-ASCII character in a text file: "There's a frog in my file!"

Re: [9fans] copy of 9.txt.gz?

On 1 October 2015 at 13:06, Mark Bucciarelli wrote: > By the way, is there any version of the John Lyons > notes on Plan 9 from 1989? They Lyons books says > circulation was restricted to distribution Bell Labs. > There are two books mentioned: > It's on Amazon:

Re: [9fans] copy of 9.txt.gz?

On 1 October 2015 at 14:43, Charles Forsyth <charles.fors...@gmail.com> wrote: > On 1 October 2015 at 13:06, Mark Bucciarelli <mkb...@gmail.com> wrote: > >> By the way, is there any version of the John Lyons >> notes on Plan 9 from 1989? They Lyons books says

Re: [9fans] copy of 9.txt.gz?

On 1 October 2015 at 15:48, Brantley Coile wrote: > I think he meant the Plan 9 Lion’s commentary, not the Sixth Edition one. Yes, and that was in the text I quoted in my reply!

Re: [9fans] off topic - a good Git reference

On 1 October 2015 at 18:31, Jeff Sickel <j...@corpus-callosum.com> wrote: > > On Sep 30, 2015, at 2:59 AM, Charles Forsyth <charles.fors...@gmail.com> > wrote: > > > > Here's a small but representative example. > > That’s just an example of a C

Re: [9fans] off topic - a good Git reference

On 30 September 2015 at 04:11, erik quanstrom wrote: > > > is there someone else interested in write a git tool for plan 9 ? it would be useful, to access git repositories directly. unfortunately, git is a C program, so it's not very portable.

Re: [9fans] off topic - a good Git reference

On 30 September 2015 at 08:47, Charles Forsyth <charles.fors...@gmail.com> wrote: > I was being sarcastic about the portability of so much contemporary C code. Here's a small but representative example. #if HAVE_SYS_TIME_H #include #endif #if HAVE_SYS_CLOCK_GETTIME time_t time

Re: [9fans] Replacement for find

On 30 September 2015 at 09:01, Wolfgang Helbig wrote: > But I consider it ugly, to ask for the disk usage if you just want to > recursively list all files. > It probably is not ideal, even when the circumlocution is hidden in a script. Perhaps find's syntax and conventions

Re: [9fans] off topic - a good Git reference

On 30 September 2015 at 08:36, hiro <23h...@gmail.com> wrote: > Why do you say C programs aren't portable, we have a C compiler already? I was being sarcastic about the portability of so much contemporary C code. You can't just compile it, even in an an ANSI/POSIX environment.

Re: [9fans] manual qer(8)

On 26 September 2015 at 06:29, arisawa wrote: > I think “runq” should be replaced by “upas/runq” mine has /bin/upas/runq -a /mail/queue /mail/lib/remotemail

Re: [9fans] Out of pseudo mount points

On 24 September 2015 at 20:55, Adriano Verardo wrote: > B->A woks, A->B doesnt. > Probably there is something wrong on A, not in exportfs. > You need /mnt/exportfs with a set of numbered directories in it, which might be missing on A: % ls /mnt/exportfs

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:55, Charles Forsyth <charles.fors...@gmail.com> wrote: > On 13 September 2015 at 19:46, <cinap_len...@felloff.net> wrote: > >> so we really want to have n->type == double/float > > > no, it happens to be wrong for ordinary integer

Re: [9fans] kenc vlong double

On 14 September 2015 at 13:59, wrote: > is there any reason to handle the as single operations instead > of breaking it down into separate and operations? that is, > is (a = b) always equivalent to (a = a b)? > you then have to fuss whether the evaluation of a has

Re: [9fans] kenc vlong double

On 14 September 2015 at 14:18, Charles Forsyth <charles.fors...@gmail.com> wrote: > 8c is a little more > involved because of the 387's architecture. there probably won't be much > code, > but it's fiddly. > in fact it was easy. i'll collect the changes shortly.

Re: [9fans] kenc vlong double

On 13 September 2015 at 15:23, wrote: > > lets see what charles thinks about this. I thought at first that one had been fixed some time ago, but it was probably just the version with compiled code (eg, amd64). i'll have a look at it.

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:46, wrote: > so we really want to have n->type == double/float no, it happens to be wrong for ordinary integers too: int x(int a, double d) { a += (a += d); return a; } should have the outer += done as int using the result of a += d as

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:21, erik quanstrom wrote: > isn't the && !mixedasop() added to the condition the problem: > the cast should not be elided if it's a float/double. t > the test is correct, because in mixed-mode assignment, you want to do the calculation in

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:01, wrote: > just assigning t to n->type fixes the type, but why did it > call arith() in the first place? > for P += I, P -= I, and other more straightforward cases of mixed-modes, you need "the usual arithmetic conversions" first.

Re: [9fans] kenc vlong double

On 13 September 2015 at 15:23, wrote: > the problem is v += d propagates the whole expression > to double. so we somehow need to convert v to double, > do the then convert back but return the double > result. > the type of E1 op=E2 is the same as the type of E1 = E1

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 7 September 2015 at 01:30, erik quanstrom wrote: > unless by name an entry in a table shared by the set of memory sharing > processes is what is meant the table isn't shared. the address of the table is the same, but the underlying memory is private, and indeed can't

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

In any case, an implementation along the lines of tprivalloc seems ok, and passes my naive test program. #include #include static Lock privlock; static int privinit; static u32int privmap; extern void **_privates; extern int _nprivates; void ** privalloc(void) { void **p; int i; lock();

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 6 September 2015 at 16:02, erik quanstrom wrote: > a slot of local interest? doesn't malloc serve that purpose well enough? It doesn't create a name for a per-process global.

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 6 September 2015 at 19:21, wrote: > manpage, might just get rid of privfree() itself. globally allocate > the slots one after another. > it's useful to be able to reset some or all of the state in a supervisory process after a failure and restart. the

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 6 September 2015 at 00:38, wrote: > is privfree() broken? it appears it chains the slots together, > but only the calling process will get a correct chain. > The only way it works is to have a main process allocate and free slots for use by all participants, which

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 5 September 2015 at 15:03, Giacomo Tesio wrote: > For extra safety I added an assert(*p == nil) just after rfork, and after > a few (apparently?) successful spawns, the assert fails. The stack is a logical copy of the parent process's stack at rfork, even with RFMEM, since

Re: [9fans] On Linux, what is the rc init file?

On 30 August 2015 at 19:25, Teodoro Santoni asbras...@gmail.com wrote: I don't see any real difference between adding modified versions of my .bashrc things to rcmain or putting them to $home/lib/profile rcmain is shared. the profile is per-user

Re: [9fans] read9pmsg usage

On 12 August 2015 at 10:18, Giacomo Tesio giac...@tesio.it wrote: So, seem that ignoring zeros is simply wrong. A residual from the past... There doesn't seem to be any justification for it now, whatever the original problem. Even if there were something, I'd fix that instead of ignoring the

Re: [9fans] read9pmsg usage

As a further historical note, originally 9P required a stream that preseved record boundaries, and the reliable datagram protocol IL/IP and pipes did that. Once TCP/IP was used, there was some fussing needed to work out where the records were, so the revision 9P2000 added a size and the stream

Re: [9fans] read9pmsg usage

Zero conventionally means end-of-file, but record boundaries are preserved on capable streams, so if a writer writes zero, the reader reads zero. Having said that, I think the comment is wrong, and read9pmsg returning zero should be interpreted as the end of the (9p) stream. In most cases, the

Re: [9fans] read9pmsg usage

On 10 August 2015 at 21:17, Giacomo Tesio giac...@tesio.it wrote: Zero can either mean EOF or I'm alive but boring. I can't see how a reliable communication (a cpu connection for example) can survive this mismatch. I'm probably missing something. A specialised reader and writer can always

Re: [9fans] Small Plan 9 Platforms

On 7 August 2015 at 18:13, Brian L. Stuart blstu...@bellsouth.net wrote: So depending on where plan9-bcm stands, it might be just right. That seems to be an old version of /sys/src/9/bcm (perhaps with modifications) so Richard Miller's version in contrib will be more up-to-date, I think.

Re: [9fans] Small Plan 9 Platforms

On 5 August 2015 at 21:39, Brian L. Stuart blstu...@bellsouth.net wrote: Obviously, the Raspberry Pi is a candidate. I think the big advantage of the Rpi or Rpi2 (for speed, memory and cores) is that there's a wealth of published projects for them, including hardware ones, and other stuff, and

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

On 27 July 2015 at 13:08, Aram Hăvărneanu ara...@mgk.ro wrote: 'd expect GCC compiling Plan 9 at a speed reasonably comparable to kencc. I used gcc for one of my own OS projects years ago, without all the #include crud. It is slow. For one thing, it still(!) produces textual assembly code

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

On 27 July 2015 at 14:44, Charles Forsyth charles.fors...@gmail.com wrote: It is slow. But it doesn't matter anyway if your aim is to compile a ton of stuff that only gcc can compile.

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

On 27 July 2015 at 15:19, Anthony Sorace a...@9srv.net wrote: (for many, it’s pretty much just a browser) One of the reasons mere POSIX isn't enough is that there are many non-POSIX tendrils that have worked their way throughout the system, notably d-bus and now systemd, but there are many

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

On 26 July 2015 at 18:33, erik quanstrom quans...@quanstro.net wrote: if fast compilation is a feature over plan 9, I'd like to see some numbers. That wasn't the point, I think. The mention of speed was rather that on fast enough hardware the speed with gcc isn't that bad, so you can use

Re: [9fans] Has Linux jumped the shark?

On 24 July 2015 at 04:54, Prof Brucee prof.bru...@gmail.com wrote: has Linux with the release of 4.0 finally jumped the shark. Since it's called Hurr Durr I'ma Sheep, I thought I'd ask a celebrity what he thought of it. The response was much as I'd expected: http://goo.gl/ZefDFV Others simply

Re: [9fans] Has Linux jumped the shark?

On 24 July 2015 at 20:20, Devon H. O'Dell devon.od...@gmail.com wrote: But POSIX remembers and indeed insists on minutiae from 40 years ago! If only we could all be more like POSIX. I didn't mean it as a good thing.

Re: [9fans] Has Linux jumped the shark?

On 24 July 2015 at 18:08, Devon H. O'Dell devon.od...@gmail.com wrote: doesn't remember given that this would have been over 40 years ago. But POSIX remembers and indeed insists on minutiae from 40 years ago!

Re: [9fans] Gawk in 9front-ports

On 7 July 2015 at 16:25, Jens Staal staal1...@gmail.com wrote: most likely not since the whole system is static... The loaders support creating a module, with the -u and -x options, with import and export tables, which are type-checked, to be dynamically loaded. If the program you're working

Re: [9fans] replace p9sk1 with something better(9front)

for mutual authentication and key exchange. Wanted: more ciphers, support for user certificates, support for certificate verification. ECDSA! ECDHE! I think that I'd avoid putting the negotiation and certificate stuff (as such) in the kernel device. On 2 July 2015 at 13:57, Charles Forsyth charles.fors

Re: [9fans] replace p9sk1 with something better(9front)

On 2 July 2015 at 13:30, Anthony Sorace a...@9srv.net wrote: The p9sk1 *model* is great, and it'd be a real shame to drop it. There always seems to be trouble setting it up, which suggests that the documentation people typically first see might need revising (or better pointers if it exists

Re: [9fans] replace p9sk1 with something better(9front)

On 2 July 2015 at 17:44, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: isn't it settled that keeping of secrets and exchange thereof are the domain of factotum? I hope so.

Re: [9fans] Basic limbo programming help

On 27 June 2015 at 05:58, Roswell Grey orangecal...@gmail.com wrote: So, if there are any limbo programmers out there, would you mind giving me a hand? I'll have a look at your example. The online doc was tested at the time, but perhaps something else changed after that. There's a dedicated

Re: [9fans] Basic limbo programming help

On 27 June 2015 at 11:35, Charles Forsyth charles.fors...@gmail.com wrote: The online doc was tested at the time, but perhaps something else changed after that. Use the examples in /doc/descent/descent.pdf (/doc/descent/descent.ms), which was updated to reflect language and window system

Re: [9fans] Help with interrupting fgetc()

On 27 June 2015 at 21:30, Nils M Holm n...@t3x.org wrote: if (!strcmp(s, interrupt)) { A minor stylistic point: Plan 9 code almost invariably uses if(strcmp(...) == 0), and for pointers if(p == nil) instead of if(!p). if(!!...) is never used.

Re: [9fans] Help with interrupting fgetc()

On 27 June 2015 at 21:30, Nils M Holm n...@t3x.org wrote: It should keep echoing after printing oopsie, but it just exits instead. What am I missing? if interrupted, fgetc returns EOF because the underlying read system call returns -1 (with error string interrupted). System calls are

Re: [9fans] enc64() vs dec64()

On 22 June 2015 at 10:05, Oleg lego12...@yandex.ru wrote: May be a stupid question. enc64() returns a null terminated string. But dec64() not doing the same. What is the reason for it? enc: binary - string dec: string - binary binary is just an array of bytes, and there isn't a special

Re: [9fans] Why does pread(2) modify the channel offset?

On 21 June 2015 at 11:44, Anthony Martin al...@pbrane.org wrote: Thoughts? As with programming language specifications, when it says equivalent it is ignoring any subtle differences. Neither call is supposed to change the offset, although it wasn't noticed for the reason you gave. One

[9fans] make passive aggressive gcc

If you're using gcc 4.8.2 to compile ... anything, really ... but certainly Plan 9 or Inferno components, and those use for loops with arrays, be sure to include the compilation options -fno-strict-aliasing\ -fno-aggressive-loop-optimizations\ and it will save you some time and effort. It will

Re: [9fans] ... and ##' stuff with pcc?

On 31 May 2015 at 17:31, Ori Bernstein o...@eigenstate.org wrote: It doesn't understand the named ... variant, which I suppose is more recent tinkering. Use the older __VA_ARGS__. IIRC, the named variant is older, but it's also a GNU extension. I've looked at the C99 and C1x standards

Re: [9fans] ... and ##' stuff with pcc?

On 25 May 2015 at 19:44, Jens Staal staal1...@gmail.com wrote: It did however not work (I guess the ... and ## are to blame?) so now I wonder how/if it is possible with the posix compiler on plan9? It doesn't understand the named ... variant, which I suppose is more recent tinkering. Use the

Re: [9fans] Ports tree for Plan 9

On 30 May 2015 at 08:21, Jens Staal staal1...@gmail.com wrote: am also interested in seeing how compatible the ported m4 is with GNU m4 if there are good tests GNU m4 is insane, and completely missed the point about GPM (and thus m4). My m4 port is based on Ritchie's m4, although I might

Re: [9fans] on cp /fd/1 /fd/0

On 12 May 2015 at 15:17, Daniel Bastos dbas...@toledo.com wrote: What is the relationship between file descriptor 1 and /fd/1? When a program runs, 1 is already open for writing. But apparently it's open only for writing. A read on it yields inappropriate use of fd. The same seems to happen

Re: [9fans] fossil+venti performance question

On 8 May 2015 at 17:13, David du Colombier 0in...@gmail.com wrote: Also, the issue is definitely related to the loopback. There is no problem when using an address on /dev/ether0. oh. possibly the queue isn't big enough, given the window size. it's using qpass on a Queue with Qmsg and if the

Re: [9fans] fossil+venti performance question

On 6 May 2015 at 22:28, David du Colombier 0in...@gmail.com wrote: Since the problem only happen when Fossil or vacfs are running on the same machine as Venti, I suppose this is somewhat related to how TCP behaves with the loopback. Interesting. That would explain the clock-like delays.

Re: [9fans] fossil+venti performance question

On 6 May 2015 at 23:35, Steven Stallion sstall...@gmail.com wrote: Were these the changes that erik submitted? I don't think so. Someone else submitted a different set of tcp changes independently much earlier.

Re: [9fans] fossil+venti performance question

On 6 May 2015 at 21:55, David du Colombier 0in...@gmail.com wrote: However, now I'm sure the issue was caused by a kernel change in 2013. There is no problem when running a kernel from early 2013. Welly, welly, welly, well. That is interesting.

Re: [9fans] fossil+venti performance question

On 4 May 2015 at 19:51, David du Colombier 0in...@gmail.com wrote: I've just made some measurements when reading a file: Vacfs running on the same machine as Venti: 151 KB/s Vacfs running on another machine: 5131 KB/s How many times do you time it on each machine?

Re: [9fans] fossil+venti performance question

On 5 May 2015 at 16:38, David du Colombier 0in...@gmail.com wrote: How many times do you time it on each machine? Maybe ten times. The results are always the same ~5%. Also, I restarted vacfs between each try. It was the effect of the ram caches that prompted the question. My experience

Re: [9fans] mips linker hoisting stack freeing operation

On 1 April 2015 at 02:34, cinap_len...@felloff.net wrote: theres my attempt at preventing the linker from doing so: It's one of those cases where it's funny it hasn't been noticed before, since the effects won't be confined to libdraw. Anyway, that change seems ok, although it's really a

Re: [9fans] puzzling 9P server / 9pcon interaction

On 1 April 2015 at 00:23, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: trying 9pcon on the same fd (e.g. aux/9pcon /srv/foo) results in inappropriate use of fd. You aren't allowed to read or write an fd directly once it has been used for 9P traffic by mount (devmnt).

Re: [9fans] Why didn't anyone tell me about the new slogan?

I think that sums up why we never got as far as we'd hoped. On 1 April 2015 at 16:46, Anthony Sorace a...@9srv.net wrote: http://t.co/qyvHkuP2m8 Sounds a bit pollyanna to me, but who am I to judge?

Re: [9fans] using git

On 19 March 2015 at 18:26, arn...@skeeve.com wrote: Charles Forsyth charles.fors...@gmail.com wrote: On 19 March 2015 at 16:09, arn...@skeeve.com wrote: There is definitely some learning curve and mindset change Just what I want from a little servant that's supposed to help me

Re: [9fans] using git

On 19 March 2015 at 16:09, arn...@skeeve.com wrote: There is definitely some learning curve and mindset change Just what I want from a little servant that's supposed to help me manage some file changes.

Re: [9fans] using git

Anyway, I moved all my Google Code stuff to mercurial at Bitbucket. I find both the command and web interfaces less annoying and less error-prone.

Re: [9fans] ken cc for linux

On 13 March 2015 at 01:31, erik quanstrom quans...@quanstro.net wrote: was, as in google code is dead. It's a good example of how the cloudy future is seriously unsettled by services suddenly vanishing, even from big suppliers. Also, I rather trust the Google storage infrastructure, but I'm

Re: [9fans] ken cc for linux

On 12 March 2015 at 08:51, Aram Hăvărneanu ara...@mgk.ro wrote: Plan 9 and Inferno have working 64-bit compilers. Periodically I pull the Plan 9 and Inferno variants into line, so they should be about the same. It's one reason I split off the Thumb implementation, although it handled ARM/Thumb

<    1   2   3   4   5   6   7   8   9   10   >