On Sat, Sep 11, 2010 at 9:59 PM, erik quanstrom wrote:
>> -#define USTKTOP (0x400) /* byte just beyond
>> user stack */
>> +#define USTKTOP (0x800) /* byte just beyond
>> user stack */
>
> shouldn't you add a 0 to that? what's wrong with
> do you have the fonts?
> they do not come with plan9port, because the
> postscript fonts cannot be redistributed except
> with plan 9 itself.
turns out no. Here is a sticky question (one I will likely have to write
Bigelow & Holmes for final clarification), but if I write a script (portage
eb
> -#define USTKTOP (0x400) /* byte just beyond
> user stack */
> +#define USTKTOP (0x800) /* byte just beyond
> user stack */
shouldn't you add a 0 to that? what's wrong with giving a process 2gb
of address space? fundamental 9vx limits
OK, the bigger user stack is committed to my vx32 at bitbucket.
ron
diff -r 6ab31397d4b9 src/9vx/a/mem.h
--- a/src/9vx/a/mem.h Sat Sep 11 23:09:14 2010 +0200
+++ b/src/9vx/a/mem.h Sat Sep 11 19:31:19 2010 -0700
@@ -41,7 +41,7 @@
#defineVMAPSIZE(0x1000-VPTSIZE-KMAPSIZE)
#defineUZERO 0 /* base of user
Actually it's really simple. Stack in 9vx begins at 48 MB. A bit small
for compiling gs I suppose :-)
I'll see how to grow it.
ron
the problematic code is at /sys/src/9/port/segment.c:483,491
for(i = 0; i < NSEG; i++) {
ns = up->seg[i];
if(ns == 0 || ns == s)
continue;
if(newtop >= ns->base && newtop < ns->top) {
qunlock(&s
This operating system is so much fun it's unfair at times.
term% grep Brk /dev/text | grep 8l
4684 8l Brk 0xdeba 0003ea58 = 0 ""
0x11d2943ddb0c6c28 0x11d2943ddb0ccdd0
4684 8l Brk 0xdeba 000570f8 00017494 1fa8 = 0 ""
0x11d2943ded6477a8 0x11d2943ded64cd98
4684 8l Brk 0xdeba 000
On Sat, Sep 11, 2010 at 4:35 PM, Robert Ransom wrote:
> BUGS
> There is a large but finite limit on the size of an argment
> list, typically around 409,600 bytes. The kernel constant
> TSTKSIZ controls this.
> ...
>
>
> Robert Ransom
>
no, I'm running under ratrace an
On Sat, 11 Sep 2010 16:07:54 -0700
ron minnich wrote:
> any good ideas here? I'm running with 9vx -m 1024. Kind of hard to
> believe I'm out.
> mk gs
> pcc -o 8.out obj/gs.8 obj/adler32.8 obj/compress.8 obj/crc32.8
> obj/deflate.8 obj/dscparse.8 obj/gconfig.8 obj/gdevabuf.8
> obj/iinit.8 obj/i
get some more memory? :)
On Sat, Sep 11, 2010 at 5:07 PM, ron minnich wrote:
> any good ideas here? I'm running with 9vx -m 1024. Kind of hard to
> believe I'm out.
>
>
> mk gs
> pcc -o 8.out obj/gs.8 obj/adler32.8 obj/compress.8 obj/crc32.8
> obj/deflate.8 obj/dscparse.8 obj/gconfig.8 obj/gdeva
any good ideas here? I'm running with 9vx -m 1024. Kind of hard to
believe I'm out.
mk gs
pcc -o 8.out obj/gs.8 obj/adler32.8 obj/compress.8 obj/crc32.8
obj/deflate.8 obj/dscparse.8 obj/gconfig.8 obj/gdevabuf.8
obj/gdevbbox.8 obj/gdevbj10.8 obj/gdevcd8.8 obj/gdevcdj.8
obj/gdevdbit.8 obj/gdevddrw
OK, just checked, and my vx32 repo at bitbucket.org has the cld
patch. I guess yiyus committed it?
ron
That sounds about right, unfortunately.
You might be better off just using TeX.
It's better at math, it runs on Plan 9,
and your colleagues who don't use
Plan 9 will still be able to collaborate
on documents with you.
Russ
On Thu, Sep 9, 2010 at 4:13 PM, erik quanstrom wrote:
> lately, i've been seeing email with gigantic headers.
> 120 header lines are not that uncommon. unfortunately
> upas has sometimes inserts a blank line about
> (but not exactly) 4k into the file. a bit of digging, upas/send
> was assuming t
> this doesn't work for me either on p9p, but it does work under
> plan 9. it's a font problem.
do you have the fonts?
they do not come with plan9port, because the
postscript fonts cannot be redistributed except
with plan 9 itself.
i believe that if you copy /sys/lib/postscript/font/*
to /usr/lo
2010/9/11 Paul Lalonde :
> I'm getting essentially every file tagged as "locally modified; will not
> update".
The option -s for replica could help you with that. I have used
replica from 9vx and it works (yes, a lot of warnings, but it works).
However, what I usually do is to keep a sysfromiso hg
hg diff
diff -r c7e9b5edb8d4 src/9vx/main.c
--- a/src/9vx/main.cSun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/main.cFri Sep 03 16:58:16 2010 +0100
@@ -55,6 +55,7 @@
static voidbootinit(void);
static voidsiginit(void);
+static void machkeyinit(void);
static char* getuser(void);
Try 2. sorry.
Thanks again to charles for finding that CLD issue.
ron
hg diff
diff -r c7e9b5edb8d4 src/9vx/main.c
--- a/src/9vx/main.cSun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/main.cFri Sep 03 16:58:16 2010 +0100
@@ -55,6 +55,7 @@
static voidbootinit(void);
static voidsigin
Hello,
this starts to be daunting...
When I use troff with the R font, troff uses metrics from /sys/lib/troff/font/R.
Then something, when dpost -f is running, must take the real glyphs
and put them into the final ps.
I guess that something must read /sys/lib/postscript/troff/R to find
out that c
2010/9/11 Lucio De Re :
> That bit was easy, just move the leading # from nopcap to etherpcap:
>From now on, this is the default in my 9vx version:
http://bitbucket.org/yiyus/vx32/
If anybody thinks pcap should be compiled by default, please let me know.
> Now, where do I find Charles' fix for th
On Sat, Sep 11, 2010 at 01:46:16PM -0400, Devon H. O'Dell wrote:
>
> pcap is for the virtual ethernet driver to use the native ip stack.
> there's another one that uses TAP that yiyus finalized from someone
> else's efforts (I'm not giving due credit here, sorry). If you don't
> have pcap just don
pcap is for the virtual ethernet driver to use the native ip stack.
there's another one that uses TAP that yiyus finalized from someone
else's efforts (I'm not giving due credit here, sorry). If you don't
have pcap just don't build etherve.c.
--dho
2010/9/11 Lucio De Re :
> On Sat, Sep 11, 2010 a
On Sat, Sep 11, 2010 at 10:24:05AM -0700, ron minnich wrote:
> >>
> > Is that included in rminnich/vx32, where default compilation fails with
> > a missing "pcap.h"?
>
> the pcap.h thing is unrelated and I think I'm going to change it so
> that it builds default with no pcap support, since I'm not
On Sat, Sep 11, 2010 at 10:18 AM, Lucio De Re wrote:
> On Sat, Sep 11, 2010 at 09:34:20AM -0700, ron minnich wrote:
>>
>> I am pretty sure Charle's patch will fix this problem
>>
> Is that included in rminnich/vx32, where default compilation fails with
> a missing "pcap.h"?
the pcap.h thing is un
On Sat, Sep 11, 2010 at 09:34:20AM -0700, ron minnich wrote:
>
> I am pretty sure Charle's patch will fix this problem
>
Is that included in rminnich/vx32, where default compilation fails with
a missing "pcap.h"?
What should I be looking for?
++L
Hi, I just did a fresh pull for my sysfromiso tree from bitbucket, mk
nuke etc. and it built fine.
It's a lot of fun to look at, e.g.,
http://bitbucket.org/rminnich/sysfromiso/changeset/147b5c83d6f4
and see all the good stuff still being done on this kernel :-)
ron
I am pretty sure Charle's patch will fix this problem
ron
On Fri, Sep 10, 2010 at 10:32 PM, erik quanstrom wrote:
>> > What am I doing wrong?
>>
>> I would argue that, while it is quite cool in principle, replica is
>> the wrong way to solve the source distribution problem. I gave up on
>> replica a year ago because I got tired of the kinds of problems y
On Sat, Sep 11, 2010 at 09:02:36AM +0200, Lucio De Re wrote:
>
> I was hoping to try 9vx.tgz from swtch.com which is not 9vx*.bz2, but
> that does not behave any differently.
>
s/not 9/now 9/
++L
Not much more than
init: starting /bin/rc
Segmentation fault
from a freshly compiled 9vx or the 9vx.Linux contained in the HG
repository on bitbucket.org.
I was hoping to try 9vx.tgz from swtch.com which is not 9vx*.bz2, but
that does not behave any differently.
The platform
31 matches
Mail list logo
