[9fans] [Off-Topic] Troff macros for professinal looking resume, cv and coverletters
Hi Anybody know of a collection of troff macros for resume, cv and cover letters? regards fernan
Re: [9fans] 9vx bootimage build instructions?
2011/5/26 erik quanstrom quans...@quanstro.net: 9vx uses plan9.ini? last i checked, that assumption was false. That depends where you checked. Ron's version (or mine, they are the same now) has some support for plan9.ini files with the -f flag, as is documented in the man page: http://bytebucket.org/yiyus/vx32/wiki/9vx.html. However, although plan9.ini is used to set some config values (as the root file system or the memory limit mentioned in this thread), 9vx cannot load a kernel file. So: i think you need to modify the 9vx kernel directly. is right. Modifying the 9vx kernel is not funny because of the bad state of the .ed files in a/. I hope newer versions of gcc with plan9 extensions make most of these scripts unnecessary, but as far as I know nobody has tried. -- - yiyus || JGL .
Re: [9fans] [Off-Topic] Troff macros for professinal looking resume, cv and coverletters
There is a description here: http://alumnus.caltech.edu/~copeland/work/, search on the page for resume, but once you have read it you will see that there is not much too it really. letters: plan9's ms macros has the .LT document type though I have not tried it, I always did it rather more manually using troff and various indents. -Steve
[9fans] 9vx patches [was: 9vx bootimage build instructions?]
On Thu, 26 May 2011 09:40:31 +0200, yy wrote:
2011/5/26 erik quanstrom quans...@quanstro.net:
9vx uses plan9.ini? last i checked, that assumption was false.
That depends where you checked. Ron's version (or mine, they are the
same now) has some support for plan9.ini files with the -f flag, as
is
documented in the man page:
http://bytebucket.org/yiyus/vx32/wiki/9vx.html. However, although
plan9.ini is used to set some config values (as the root file system
or the memory limit mentioned in this thread), 9vx cannot load a
kernel file. So:
There was a minor inconsistency. There is a comment in 9vx/mmu.c which
states that memsize can be overwritten with the '-m' option, but no -m
switch was provided in main. The following diff adds that (tested):
--- main.c 2011-05-26 08:34:02.687051389 -0500
+++ main.c 2011-05-26 08:34:10.830709411 -0500
@@ -170,6 +170,9 @@
username = EARGF(usage());
break;
+ case 'm':
+ memsize = atoi(EARGF(usage()));
+ break;
default:
usage();
}ARGEND
Also, thanks for the pointer. Setting memsize in a plan9.ini also
works.
i think you need to modify the 9vx kernel directly.
is right.
Modifying the 9vx kernel is not funny because of the bad state of the
.ed files in a/. I hope newer versions of gcc with plan9 extensions
make most of these scripts unnecessary, but as far as I know nobody
has tried.
The following command line switch (-n) adds an initial hack to
conf.nproc to override the 2000 hard coded limit. While this allws me
to now run over 64 threads, running it to high gives me a warning that
there are to many procs for devproc. I'm providing the patch here as
is, but will likely take a poke at it again over the weekend. As a
note, I need to be able to spawn over 3000 procs to stress test some
code. I would like to get this working under 9vx as well...
--- main.c 2011-05-26 08:40:00.286043255 -0500
+++ main.c 2011-05-26 08:43:42.369712636 -0500
@@ -64,6 +64,8 @@
static char* getuser(void);
+int nproclimit = 2000; // allow override of the hardlimit set to the
number of procs
+
void
usage(void)
{
@@ -173,6 +175,9 @@
case 'm':
memsize = atoi(EARGF(usage()));
break;
+ case 'n':
+ nproclimit = atoi(EARGF(usage()));
+ break;
default:
usage();
}ARGEND
@@ -284,8 +289,8 @@
conf.npage += conf.mem[i].npage;
conf.upages = conf.npage;
conf.nproc = 100 + ((conf.npage*BY2PG)/MB)*5;
- if(conf.nproc 2000)
- conf.nproc = 2000;
+ if(conf.nproc nproclimit)
+ conf.nproc = nproclimit;
conf.nimage = 200;
conf.nswap = 0;
conf.nswppo = 0;
I do not think I have write access to your 9vx repository, and I do not
know if you want the nproc limit hack. Let me know if you find these
acceptable.
EBo --
Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]
2011/5/26 EBo e...@sandien.com:
On Thu, 26 May 2011 09:40:31 +0200, yy wrote:
2011/5/26 erik quanstrom quans...@quanstro.net:
9vx uses plan9.ini? last i checked, that assumption was false.
That depends where you checked. Ron's version (or mine, they are the
same now) has some support for plan9.ini files with the -f flag, as is
documented in the man page:
http://bytebucket.org/yiyus/vx32/wiki/9vx.html. However, although
plan9.ini is used to set some config values (as the root file system
or the memory limit mentioned in this thread), 9vx cannot load a
kernel file. So:
There was a minor inconsistency. There is a comment in 9vx/mmu.c which
states that memsize can be overwritten with the '-m' option, but no -m
switch was provided in main. The following diff adds that (tested):
Yeah, I added this option years ago but it must have been lost in some
of the SoC work plus merges at some point.
--- main.c 2011-05-26 08:34:02.687051389 -0500
+++ main.c 2011-05-26 08:34:10.830709411 -0500
@@ -170,6 +170,9 @@
username = EARGF(usage());
break;
+ case 'm':
+ memsize = atoi(EARGF(usage()));
+ break;
default:
usage();
}ARGEND
Also, thanks for the pointer. Setting memsize in a plan9.ini also works.
Or maybe yiyus added it here in an attempt to get things out of CLI
opts when the plan9.ini stuff happened.
i think you need to modify the 9vx kernel directly.
is right.
Modifying the 9vx kernel is not funny because of the bad state of the
.ed files in a/. I hope newer versions of gcc with plan9 extensions
make most of these scripts unnecessary, but as far as I know nobody
has tried.
The following command line switch (-n) adds an initial hack to conf.nproc to
override the 2000 hard coded limit. While this allws me to now run over 64
threads, running it to high gives me a warning that there are to many procs
for devproc. I'm providing the patch here as is, but will likely take a
poke at it again over the weekend. As a note, I need to be able to spawn
over 3000 procs to stress test some code. I would like to get this working
under 9vx as well...
--- main.c 2011-05-26 08:40:00.286043255 -0500
+++ main.c 2011-05-26 08:43:42.369712636 -0500
@@ -64,6 +64,8 @@
static char* getuser(void);
+int nproclimit = 2000; // allow override of the hardlimit set to the number
of procs
+
void
usage(void)
{
@@ -173,6 +175,9 @@
case 'm':
memsize = atoi(EARGF(usage()));
break;
+ case 'n':
+ nproclimit = atoi(EARGF(usage()));
+ break;
default:
usage();
}ARGEND
@@ -284,8 +289,8 @@
conf.npage += conf.mem[i].npage;
conf.upages = conf.npage;
conf.nproc = 100 + ((conf.npage*BY2PG)/MB)*5;
- if(conf.nproc 2000)
- conf.nproc = 2000;
+ if(conf.nproc nproclimit)
+ conf.nproc = nproclimit;
conf.nimage = 200;
conf.nswap = 0;
conf.nswppo = 0;
I do not think I have write access to your 9vx repository, and I do not know
if you want the nproc limit hack. Let me know if you find these acceptable.
Typically the way to do this is to create your own public fork, and
then send a pull request to the maintainer of whoever you forked from
since hg has the distributed model.
EBo --
[9fans] Fonts: PostScript 229 and 315 glyphes
Hello, Since I'm moving to the 1.0 release of kerTeX, there is one area that I need to tidy up: fonts. The support for utf-8/runes will have to be put (later) in the compilation, replacing the xord[] handling. This is the gestion of the input. In the meantime, the use of tcs(1) to convert to some encoding for TeX input will do the job. The next step in the process is the conversion of an input code to a TeX command that can be a literal : a defined character. But TeX must have the correct information for the correct glyph, and a dvi driver must put afterwards the correct glyph in the correct place computed by TeX. The correct way and the most flexible way to do the handling is to use the virtual fonts, the input code in TeX being mapped to some sequences and/or some glyphes in whatever fonti(s) the virtual font is combining. For example, for latin1 users, it can be far more easy to enter directly the code for some non ASCII letter (even an ASCII accented one) than to use the escaping commands. So my goal is to tidy up this mess, and to provide virtual fonts mapping to CMR or PostScript core (the core 35 fonts) and to explicate (unfold/unhide) the process so that it can be relatively easy to adapt to one's needs. Adobe has provided not the definition of the fonts (the drawing) but the metrics (what is needed by TeX to compute the layout). There are two versions (see Redbook, E.5): standard (0229 glyphes) and extended (0315 glyphes). My intention is to provide the mapping by creating (for example) the accented letters via a combination of glyphes from the 0229 glyphes (the standard version). Has anyone seen the wild use of the 0315 flavour? that has more than just the accented glyphes. -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]
The following command line switch (-n) adds an initial hack to
conf.nproc to override the 2000 hard coded limit. While this allws me
to now run over 64 threads, running it to high gives me a warning that
there are to many procs for devproc. I'm providing the patch here as
this is a bug in the warning message.
; diffy -c devproc.c
/n/dump/2011/0526/sys/src/9/port/devproc.c:139,147 - devproc.c:139,149
* If notepg, c-pgrpid.path is pgrp slot, .vers is noteid.
*/
#define QSHIFT 5 /* location in qid of proc slot # */
+ #define SLOTBITS 23 /* number of bits in the slot */
+ #define SLOTMASK((1SLOTBITS)-1 QSHIFT)
#define QID(q) ulong)(q).path)0x001F)0)
- #define SLOT(q) (ulong)(q).path)0x07FE0)QSHIFT)-1)
+ #define SLOT(q) (ulong)(q).path)SLOTMASK)QSHIFT)-1)
#define PID(q) ((q).vers)
#define NOTEID(q) ((q).vers)
/n/dump/2011/0526/sys/src/9/port/devproc.c:288,294 - devproc.c:290,296
static void
procinit(void)
{
- if(conf.nproc = (1(16-QSHIFT))-1)
+ if(conf.nproc = (SLOTMASKQSHIFT) - 1)
print(warning: too many procs for devproc\n);
addclock0link((void (*)(void))profclock, 113); /* Relative prime to HZ
*/
}
- erik
Re: [9fans] Fonts: PostScript 229 and 315 glyphes
On Thu, May 26, 2011 at 05:29:05PM +0200, tlaro...@polynum.com wrote: There are two versions (see Redbook, E.5): standard (0229 glyphes) and extended (0315 glyphes). Certainly not 0229 in octal... Must be 229 different letters? signs? in total. -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] hgfs?
Typically the way to do this is to create your own public fork, and then send a pull request to the maintainer of whoever you forked from since hg has the distributed model. A project idea: murkyfs -- browse not just your own mercurial repo and also the one you cloned from! Extra points for mapping hg commands like push/pull/merge/diff in a useful way. Another idea is a better integration of acem + hg. [One side effect using Eclipse is I have been thinking about how one might build a simple IDE around acme or something similar.]
Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]
On Thu, 26 May 2011 11:34:29 -0400, erik quanstrom wrote: ... it to high gives me a warning that there are to many procs for devproc... this is a bug in the warning message. ; diffy -c devproc.c ... + #define SLOTBITS 23 /* number of bits in the slot */ + #define SLOTMASK((1SLOTBITS)-1 QSHIFT) ... Thanks, I have added this patch to my ebuilds. The system still crashes with very large numbers of procs (I think it is overrunning the static definition of libvx32/proc.c vxproc *procs[VXPROCSMAX]), but for now spawning 64 tasks is ok for development, but all the tests are shooting for 512. It would be nice to get all the systems running consistently. Any suggestions are greatly appreciated. EBo --
Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]
The system still crashes with very large numbers of procs (I think it
is overrunning the static definition of libvx32/proc.c vxproc
*procs[VXPROCSMAX]), but for now spawning 64 tasks is ok for
development, but all the tests are shooting for 512. It would be nice
to get all the systems running consistently. Any suggestions are
greatly appreciated.
unless someone has broken 9vx since i last pulled, the code has
that case handled.
for (pno = 0; ; pno++) {
if (pno == VXPROCSMAX) {
errno = EAGAIN;
return NULL;
}
if (procs[pno] == 0)
break;
}
if you follow vxproc_alloc calls, you'll see that each
caller checks the return value and does something reasonable.
given this,
main.c:318: conf.nproc = 100 + ((conf.npage*BY2PG)/MB)*5;
main.c:319: if(conf.nproc 2000)
main.c:320: conf.nproc = 2000;
i'd suspect that the real problem is you're not giving 9vx enough
kernel memory. try setting kernelpercent to something largeish.
but of course, i'm just guessing. it would be helpful to have some
debugging output.
- erik
Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]
On Thu, 26 May 2011 14:58:11 -0400, erik quanstrom wrote: The system still crashes with very large numbers of procs (I think it is overrunning the static definition of libvx32/proc.c vxproc *procs[VXPROCSMAX]), but for now spawning 64 tasks is ok for development, but all the tests are shooting for 512. It would be nice to get all the systems running consistently. Any suggestions are greatly appreciated. ... main.c:318: conf.nproc = 100 + ((conf.npage*BY2PG)/MB)*5; main.c:319: if(conf.nproc 2000) main.c:320: conf.nproc = 2000; The problem here is that I had to override this test to pass in a limit. On plan9 (running in kvm) it took over 3000 procs to run the 512 tasks, and I set the memsize to 2047 (it crashed with 2048). The behavior is interesting. It is moroting along and either aborts with a panic: sigsegv on cpu5, a panic: mmap address space 0, or it goes off into never never land (if I look at the CPU usage at this time it is essentially 0 where throwing 64 tasks at it causes one of the cores to go full tilt). i'd suspect that the real problem is you're not giving 9vx enough kernel memory. try setting kernelpercent to something largeish. I've played around with setting it from 70 to 100. but of course, i'm just guessing. it would be helpful to have some debugging output. I'll see what I can get you after I put out the immediate fires. Thanks for the suggestions. EBo --
Re: [9fans] hgfs?
do you even realize that plan 9 / unix is supposed to be an IDE? On Thu, May 26, 2011 at 6:39 PM, Bakul Shah ba...@bitblocks.com wrote: Typically the way to do this is to create your own public fork, and then send a pull request to the maintainer of whoever you forked from since hg has the distributed model. A project idea: murkyfs -- browse not just your own mercurial repo and also the one you cloned from! Extra points for mapping hg commands like push/pull/merge/diff in a useful way. Another idea is a better integration of acem + hg. [One side effect using Eclipse is I have been thinking about how one might build a simple IDE around acme or something similar.]
Re: [9fans] hgfs?
On Thu, May 26, 2011 at 1:39 PM, Bakul Shah ba...@bitblocks.com wrote: Typically the way to do this is to create your own public fork, and then send a pull request to the maintainer of whoever you forked from since hg has the distributed model. A project idea: murkyfs -- browse not just your own mercurial repo and also the one you cloned from! Extra points for mapping hg commands like push/pull/merge/diff in a useful way. Another idea is a better integration of acem + hg. [One side effect using Eclipse is I have been thinking about how one might build a simple IDE around acme or something similar.] http://ueber.net/code/r/hgfs
Re: [9fans] hgfs?
A project idea: murkyfs -- browse not just your own mercurial repo and also the one you cloned from! Extra points for mapping hg commands like push/pull/merge/diff in a useful way. Another idea is a better integration of acem + hg. [One side effect using Eclipse is I have been thinking about how one might build a simple IDE around acme or something similar.] http://ueber.net/code/r/hgfs file servers are great, but hg concepts aren't really file-system oriented. it might be nice to be able to diff -c (default mybranch)^/sys/src/9/pc/mp.c but hg diff figures out all the alloying stuff, like the top-level of the repo anyway. also, ideas like push, pull, update, etc., don't map very well. so a hg file server seems to me a bit like, have hammer, see nail. if i'm missing why this is an interesting idea, i'd love to know what i don't see. - erik
