Re: mg - corner-case backward scrolling
There is a corner case when the screen buffer is only 1 line long where the loop that looks for the current dot line goes through the whole buffer until it finds the correct line. This means the line number decrement is way over what it should be. This diff accounts for that corner case. ok? This version uses the existing function backline() that already moves the cursor and linep by one line. This keeps the backpage() function for paging backwards. -lum Index: basic.c === RCS file: /cvs/src/usr.bin/mg/basic.c,v retrieving revision 1.34 diff -u -p -r1.34 basic.c --- basic.c 1 Jun 2012 11:22:06 - 1.34 +++ basic.c 7 Jun 2012 15:25:34 - @@ -309,7 +309,7 @@ backpage(int f, int n) if (!(f FFARG)) { n = curwp-w_ntrows - 2;/* Default scroll. */ if (n = 0) /* Don't blow up if the */ - n = 1; /* window is tiny. */ + return(backline(f, 1)); /* window is tiny. */ } else if (n 0) return (forwpage(f | FFRAND, -n));
Re: ramdisk overflow during make release with -stable on amd64
On Wed, Jun 6, 2012 at 5:29 PM, Peter Bisroev pe...@int19h.net wrote: Thanks Stuart. I'll try running 'make release' again, and if that does not work I'll modify the Makefile. But before I do that, is there anything I can do to help troubleshoot this issue? I have tried re-running 'make release' again and it failed with the same error. I edited distrib/amd64/Makefile and set SUBDIR= ramdisk_cd cdfs. Everything went well. The only warning that came up was that floppy51.fs cannot be found. But that is expected now, so everything is good. cd /usr/rel; sum -a sha256 INSTALL.`arch -ks` bsd bsd.mp bsd.rd cd51.iso floppy51.fs pxeboot cdboot cdbr base51.tgz comp51.tgz man51.tgz game51.tgz etc51.tgz SHA256 sum: cannot open floppy51.fs: No such file or directory Thank you for everyone's help! --peter
mg - save backup files to homedir (diff v2)
[note: I've modifed this diff from the first version with comments from eric@ and Sunil Nimmagadda.] I find the backup files mg creates scattered around a pain but then again I don't want to switch backups off since they can be useful. Also, I don't feel the need to implement something in mg as fancy as emacs's backup functionality ie. moving backup files, versioning, deleting old backup versions etc With this diff I've only added the emacs functionality of moving the backup files to a single directory instead of having them scattered around everywhere. There are some drawbacks to having the backups in one directory of course, only one backup version is maintained for files of the same name but which originate in different directories (But that is enough for me) Since the functionality isn't trying to mimic emacs exactly, the command name I've chosen isn't trying to reuse one of emacs'. backup-to-home-directory This is open to suggestions of course. The backup directory name ~/.mg.d stems from emacs's ~/.emacs.d. Any comments? -lum Index: def.h === RCS file: /cvs/src/usr.bin/mg/def.h,v retrieving revision 1.123 diff -u -p -r1.123 def.h --- def.h 7 Jun 2012 15:15:04 - 1.123 +++ def.h 7 Jun 2012 17:38:26 - @@ -446,6 +446,7 @@ struct list *make_file_list(char *); int fisdir(const char *); int fchecktime(struct buffer *); int fupdstat(struct buffer *); +int backuptohomedir(int, int); /* kbd.c X */ int do_meta(int, int); Index: fileio.c === RCS file: /cvs/src/usr.bin/mg/fileio.c,v retrieving revision 1.89 diff -u -p -r1.89 fileio.c --- fileio.c25 May 2012 04:56:58 - 1.89 +++ fileio.c7 Jun 2012 17:38:26 - @@ -22,6 +22,10 @@ #include kbd.h +static char *bkuplocation(const char *); + +static char *bkupdir; + /* * Open a file for reading. */ @@ -189,6 +193,26 @@ ffgetline(FILE *ffp, char *buf, int nbuf } /* + * Location of backup file. This function creates the correct path. + */ +static char * +bkuplocation(const char *fn) +{ + struct stat sb; + char *fname, *c; + + if (bkupdir != NULL (stat(bkupdir, sb) == 0) + S_ISDIR(sb.st_mode)) { + c = strrchr(fn, '/'); + if (asprintf(fname, %s%s, bkupdir, c) == -1) + return (NULL); + } else if ((fname = strndup(fn, NFILEN)) == NULL) + return (NULL); + + return (fname); +} + +/* * Make a backup copy of fname. On Unix the backup has the same * name as the original file, with a ~ on the end; this seems to * be newest of the new-speak. The error handling is all in file.c. @@ -203,23 +227,27 @@ fbackupfile(const char *fn) int from, to, serrno; ssize_t nread; char buf[BUFSIZ]; - char*nname, *tname; + char*nname, *tname, *bkpth; if (stat(fn, sb) == -1) { ewprintf(Can't stat %s : %s, fn, strerror(errno)); return (FALSE); } - if (asprintf(nname, %s~, fn) == -1) { + if ((bkpth = bkuplocation(fn)) == NULL) + return (FALSE); + + if (asprintf(nname, %s~, bkpth) == -1) { ewprintf(Can't allocate temp file name : %s, strerror(errno)); return (ABORT); } - if (asprintf(tname, %s.XX, fn) == -1) { + if (asprintf(tname, %s.XX, bkpth) == -1) { ewprintf(Can't allocate temp file name : %s, strerror(errno)); free(nname); return (ABORT); } + free(bkpth); if ((from = open(fn, O_RDONLY)) == -1) { free(nname); @@ -610,4 +638,28 @@ fchecktime(struct buffer *bp) return (TRUE); +} + +int +backuptohomedir(int f, int n) +{ + const char *c = ~/.mg.d; + char*p; + + if (bkupdir == NULL) { + p = adjustname(c, TRUE); + bkupdir = strndup(p, NFILEN); + if (bkupdir == NULL) + return(FALSE); + + if (mkdir(bkupdir, 0700) == -1 errno != EEXIST) { + free(bkupdir); + bkupdir = NULL; + } + } else { + free(bkupdir); + bkupdir = NULL; + } + + return (TRUE); } Index: funmap.c === RCS file: /cvs/src/usr.bin/mg/funmap.c,v retrieving revision 1.39 diff -u -p -r1.39 funmap.c --- funmap.c7 Jun 2012 15:15:04 - 1.39 +++ funmap.c7 Jun 2012 17:38:26 - @@ -25,6 +25,7 @@ static struct funmap functnames[] = { {fillmode, auto-fill-mode,}, {indentmode, auto-indent-mode,}, {backtoindent,
taskset for smp
Hi, I just ran a script converting a bunch of files to mp3 and since I have a 8 core machine now I'd like to make my little script multi-threaded. So each resulting lame process will go to another core. When I ran the script I noticed that all processes ended up being run on the same processor. The next instance of the script also ran on the same processor. It was nu until I started a new shell they moved to another processor. So apparently each process and all it's children are being run on the same processor. Is that by design? Is there a setting which changes this behaviour so each child process goes to a random core? Would it be nice if there was a program like taskset which enables you to move processes to other cores? http://linuxcommand.org/man_pages/taskset1.html # Han -- Please CC me since I am not subscribed to this list.
omaggio E-BOOK Linee guida per una sana alimentazione Italiana (Istituto Nazionale di Ricerca per gli Alimenti e la Nutrizione).
Mese della prevenzione del sovrappeso e dell'obesità. dimagrire -10Kg in soli 21gg. per non ingrassare mai più! richiedi l'e-book gratuito Linee Guida per una sana alimentazione Italiana (Istituto Nazionale di Ricerca per gli Alimenti e la Nutrizione). cliccando QUI Hai anche l'opportunità di avere la CONSULENZA on-line GRATUITA per sapere come regolarizzare il Tuo metabolismo NATURALMENTE (senza farmaci o integratori, senza rinuncie e stress) in modo da perdere tutti i kg superflui e portarti al NORMO-PESO per NON INGRASSARE MAI PIU' - clicca QUI [demime 1.01d removed an attachment of type image/jpeg which had a name of 1.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of 2.jpg]
Re: taskset for smp
Would it be nice if there was a program like taskset which enables you to move processes to other cores? No. Let me be more clear on what Philip is saying by asking some questions. Can only root move programs to different processors via this program? Or can any user move their own or other programs to different processors? In the first instance, it is useless and unusable. In the second instance, please give me an account on an important box so that I can demonstrate the security impact to you... The scheduler must try to do the best. Yes, we know -- the scheduler does a poor job at the moment... Never let root try to do a job the operating system should do itself. Furthermore, never let a user try to do it, either. Unless you prefer a system you never let people onto. And if that is your use case, you are better off choosing something which has infinite flexibility, and then disconnecting it from the net.