Paga $680 por Camara Digital L50 Fuji C/12 mp . SOLO POR HOY!!!
Si no podes visualizar este mail, ingresa a: http://news1.bonuscupon.com.ar/r.html?uid=1.1r.295h.ue.5pfrxk48l0
C Programming Language - KR books to be given...
Hi misc@, tech@, If it is difficult to grab hold of a copy of KR 2nd ed., please drop me a private note -- I have a bunch of copies (5) which I can send across your way as a gift. I'll probably ask you to cover the shipping (~$6 US). These are Indian reprints which cost a lot less here in India (~$2.5 US), than they do in the US or the EU. Thank you. -Amarendra
Re: C Programming Language - KR books to be given...
On Mon, Jul 2, 2012 at 4:47 AM, Amarendra Godbole amarendra.godb...@gmail.com wrote: Hi misc@, tech@, If it is difficult to grab hold of a copy of KR 2nd ed., please drop me a private note -- I have a bunch of copies (5) which I can send across your way as a gift. I'll probably ask you to cover the shipping (~$6 US). These are Indian reprints which cost a lot less here in India (~$2.5 US), than they do in the US or the EU. Thank you. -Amarendra they are cheap in india for a specific reason, and they are expensive in US/EU for another specific reason. this is getting into import/export. be careful. good luck
Re: tftpd patch
that tftpd has been unlinked from the tree, and therefore unlikely to get patches against it. have you tried the new one to see if you get annoying errors out of it? dlg On 29/06/2012, at 4:11 AM, Peter J. Philipp wrote: Hi, I have the weird scenario when I try to tftp a file from a remote tftpd that's also openbsd that my pf doesn't keep a state open. This is something I need to fix, however I found this in the logs on the remote tftpd and it's misleading: Jun 28 14:03:21 hostname tftpd[2506]: recv: Connection refused It first boggled my mind what it's trying to recv and then it came to me... the write error message is delayed because of the ICMP port unreachable travel time at which point the descriptor is already blocking in read I guess. So I have changed it to this: Jun 28 14:03:21 hostname tftpd[2506]: sendfile: Connection refused which to me is a lot more explanatory on what it fails on. sendfile is the function not the syscall. I'd rather see send in there than recv. Here is the patch: Index: tftpd.c === RCS file: /cvs/src/libexec/tftpd/tftpd.c,v retrieving revision 1.63 diff -u -r1.63 tftpd.c --- tftpd.c 27 Oct 2009 23:59:32 - 1.63 +++ tftpd.c 28 Jun 2012 18:00:29 - @@ -669,7 +669,10 @@ error = 1; if (errno == EINTR) continue; - syslog(LOG_ERR, recv: %m); + if (errno == ECONNREFUSED) + syslog(LOG_ERR, sendfile: %m); + else + syslog(LOG_ERR, recv: %m); goto abort; } ap-th_opcode = ntohs((u_short)ap-th_opcode); If you think kittens will die because of this patch then don't commit it but otherwise I'm just trying to make sense of this better. Cheers, -peter
rc(8) patch
Re-create a seed file on a first boot too -- better than not having any seed at all. Index: etc/rc === RCS file: /cvs/src/etc/rc,v retrieving revision 1.400 diff -u etc/rc --- etc/rc 6 Apr 2012 15:11:30 - 1.400 +++ etc/rc 2 Jul 2012 22:30:44 - @@ -104,13 +104,13 @@ if [ -f /var/db/host.random ]; then dd if=/var/db/host.random of=/dev/arandom bs=65536 count=1 \ /dev/null 21 - chmod 600 /var/db/host.random /dev/null 21 - - # reset seed file, so that if a shutdown-less reboot occurs, - # the next seed is not a repeat - dd if=/dev/arandom of=/var/db/host.random bs=65536 count=1 \ -/dev/null 21 fi + + # reset seed file, so that if a shutdown-less reboot occurs, + # the next seed is not a repeat + dd if=/dev/arandom of=/var/db/host.random bs=65536 count=1 \ +/dev/null 21 + chmod 600 /var/db/host.random /dev/null 21 } fill_baddynamic()
Re: tinyscheme + mg
On 06/29/12 01:03, Otto Moerbeek wrote: On Thu, Jun 28, 2012 at 12:40:57PM -0600, Nick Bender wrote: On Thu, Jun 28, 2012 at 12:29 PM, Otto Moerbeek o...@drijf.net wrote: On Thu, Jun 28, 2012 at 11:00:24AM -0600, Nick Bender wrote: raises head TCL? BSD, small, fast, been around forever, C like syntax. In base would be awesome... ducks How can a language where everything is a string be good? How can a language where everything is a string be _not_ good? How can a language where everything is an object be good? Silly questions. ? ? ? ?-Otto While that was true in early versions it is no longer the case. As values are used they are converted to the appropriate representation, e.g.: set x 1; set y 2 set z [expr $x+$y] After assignment x and y are strings. During the evaluation of expr they are converted to integers and z is assigned an integer value. Type unsafeness is staring me in the face. TCL is fairly modern at this point with features such as JIT byte compilation of procs. Having a smart interpreter doesn't make the language better. Anyway, I don't want to go into language wars here. -Otto Not that that's what you were doing, but one problem Tcl has these days shedding 10-year-old fud arguments. That and being awesome, which is admittedly less of a problem. Stu
Re: tinyscheme + mg
On 06/28/12 13:00, Nick Bender wrote: On Thu, Jun 28, 2012 at 9:16 AM, Ted Unangst t...@tedunangst.com wrote: Integration is one of the goals. I can't predict what extensions you may want to write. I mean, mg already reads a .mg file. If we knew what people were going to put in their .mg files, we could just hard code it in the program and cut out the startup file bloat. That said, some concrete examples would help, both to make sure we're building something useful and to demonstrate that it is useful. Why do people still use emacs and not mg? For text editing not usenet browsing or whatever. I don't want to add some python editor mode just to hear I don't use python. raises head TCL? BSD, small, fast, been around forever, C like syntax. In base would be awesome... ducks Don't duck - stand proud! Stu
Re: bug fix: 'opencvs log' mangles RCS branch number
On Mon, Jul 2, 2012 at 01:41 UTC, Michael W. Bombardieri m...@ii.net wrote:
On Sun, Jul 01, 2012 at 11:04:31AM -0400, Ted Unangst wrote:
I had trouble finding a decent file where there was a difference,
thanks. I guess we need an uglier patch to only skip magic if the
version is 1.1.1?
Yeah, I see what you mean. This is pretty ugly...
We can incorporate a shiny new macro RCSNUM_ISDEFBRANCH to
check for the special case of 1.1.1.
This seems to work as expected with tagged RCS files.
Does this look ok?
Index: getlog.c
===
RCS file: /cvs/src/usr.bin/cvs/getlog.c,v
retrieving revision 1.95
diff -u -r1.95 getlog.c
--- getlog.c 30 Jul 2010 21:47:18 - 1.95
+++ getlog.c 2 Jul 2012 01:35:59 -
@@ -269,14 +269,17 @@
if (!(runflags L_NOTAGS)) {
cvs_printf(symbolic names:\n);
TAILQ_FOREACH(sym, (cf-file_rcs-rf_symbols), rs_list) {
- rev = rcsnum_alloc();
- rcsnum_cpy(sym-rs_num, rev, 0);
- if (RCSNUM_ISBRANCH(sym-rs_num))
+ if (RCSNUM_ISBRANCH(sym-rs_num)
+ !RCSNUM_ISDEFBRANCH(sym-rs_num)) {
+ rev = rcsnum_alloc();
+ rcsnum_cpy(sym-rs_num, rev, 0);
rcsnum_addmagic(rev);
-
- cvs_printf(\t%s: %s\n, sym-rs_name,
- rcsnum_tostr(rev, numb, sizeof(numb)));
- rcsnum_free(rev);
+ cvs_printf(\t%s: %s\n, sym-rs_name,
+ rcsnum_tostr(rev, numb, sizeof(numb)));
+ rcsnum_free(rev);
+ } else
+ cvs_printf(\t%s: %s\n, sym-rs_name,
+ rcsnum_tostr(sym-rs_num, numb,
sizeof(numb)));
}
}
Index: rcs.h
===
RCS file: /cvs/src/usr.bin/cvs/rcs.h,v
retrieving revision 1.99
diff -u -r1.99 rcs.h
--- rcs.h 3 Jun 2011 10:02:25 - 1.99
+++ rcs.h 2 Jul 2012 01:35:59 -
@@ -104,6 +104,8 @@
#define RCSNUM_ISBRANCH(n) ((n)-rn_len % 2)
#define RCSNUM_ISBRANCHREV(n) (!((n)-rn_len % 2) ((n)-rn_len = 4))
+#define RCSNUM_ISDEFBRANCH(n) \
+ (((n)-rn_len == 3) (((n)-rn_id[0]|(n)-rn_id[1]|(n)-rn_id[2])
== 1))
That seems like an insult to compilers to me, a hand optimization that
in fact binds the compiler to behavior you don't need (handling 0s as
1s as long as one of the three is 1).
/* file flags */
#define RCS_READ (10)
Cheers,
Dave Hart
Re: bug fix: 'opencvs log' mangles RCS branch number
On Tue, Jul 03, 2012 at 12:42:45AM +, Dave Hart wrote:
On Mon, Jul 2, 2012 at 01:41 UTC, Michael W. Bombardieri m...@ii.net wrote:
On Sun, Jul 01, 2012 at 11:04:31AM -0400, Ted Unangst wrote:
I had trouble finding a decent file where there was a difference,
thanks. ?I guess we need an uglier patch to only skip magic if the
version is 1.1.1?
Yeah, I see what you mean. This is pretty ugly...
We can incorporate a shiny new macro RCSNUM_ISDEFBRANCH to
check for the special case of 1.1.1.
This seems to work as expected with tagged RCS files.
Does this look ok?
Index: getlog.c
===
RCS file: /cvs/src/usr.bin/cvs/getlog.c,v
retrieving revision 1.95
diff -u -r1.95 getlog.c
--- getlog.c ? ?30 Jul 2010 21:47:18 - ? ? ?1.95
+++ getlog.c ? ?2 Jul 2012 01:35:59 -
@@ -269,14 +269,17 @@
? ? ? ? if (!(runflags L_NOTAGS)) {
? ? ? ? ? ? ? ? cvs_printf(symbolic names:\n);
? ? ? ? ? ? ? ? TAILQ_FOREACH(sym, (cf-file_rcs-rf_symbols), rs_list) {
- ? ? ? ? ? ? ? ? ? ? ? rev = rcsnum_alloc();
- ? ? ? ? ? ? ? ? ? ? ? rcsnum_cpy(sym-rs_num, rev, 0);
- ? ? ? ? ? ? ? ? ? ? ? if (RCSNUM_ISBRANCH(sym-rs_num))
+ ? ? ? ? ? ? ? ? ? ? ? if (RCSNUM_ISBRANCH(sym-rs_num)
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? !RCSNUM_ISDEFBRANCH(sym-rs_num)) {
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rev = rcsnum_alloc();
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rcsnum_cpy(sym-rs_num, rev, 0);
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rcsnum_addmagic(rev);
-
- ? ? ? ? ? ? ? ? ? ? ? cvs_printf(\t%s: %s\n, sym-rs_name,
- ? ? ? ? ? ? ? ? ? ? ? ? ? rcsnum_tostr(rev, numb, sizeof(numb)));
- ? ? ? ? ? ? ? ? ? ? ? rcsnum_free(rev);
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cvs_printf(\t%s: %s\n, sym-rs_name,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rcsnum_tostr(rev, numb, sizeof(numb)));
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rcsnum_free(rev);
+ ? ? ? ? ? ? ? ? ? ? ? } else
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cvs_printf(\t%s: %s\n, sym-rs_name,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rcsnum_tostr(sym-rs_num, numb,
sizeof(numb)));
? ? ? ? ? ? ? ? }
? ? ? ? }
Index: rcs.h
===
RCS file: /cvs/src/usr.bin/cvs/rcs.h,v
retrieving revision 1.99
diff -u -r1.99 rcs.h
--- rcs.h ? ? ? 3 Jun 2011 10:02:25 - ? ? ? 1.99
+++ rcs.h ? ? ? 2 Jul 2012 01:35:59 -
@@ -104,6 +104,8 @@
?#define RCSNUM_ISBRANCH(n) ? ? ((n)-rn_len % 2)
?#define RCSNUM_ISBRANCHREV(n) ?(!((n)-rn_len % 2) ((n)-rn_len = 4))
+#define RCSNUM_ISDEFBRANCH(n) \
+ ? ? ? (((n)-rn_len == 3) (((n)-rn_id[0]|(n)-rn_id[1]|(n)-rn_id[2])
== 1))
That seems like an insult to compilers to me, a hand optimization that
in fact binds the compiler to behavior you don't need (handling 0s as
1s as long as one of the three is 1).
?/* file flags */
?#define RCS_READ ? ? ? ? (10)
Cheers,
Dave Hart
Sorry, my fault. The intent was bitwise-and not bitwise-or.
Third version of the diff follows.
In regards to hand optimisations, we could be even worse
and do something like add rn_id values, subtract rn_len, check
if zero. :)
Index: getlog.c
===
RCS file: /cvs/src/usr.bin/cvs/getlog.c,v
retrieving revision 1.95
diff -u -r1.95 getlog.c
--- getlog.c30 Jul 2010 21:47:18 - 1.95
+++ getlog.c3 Jul 2012 01:38:06 -
@@ -269,14 +269,17 @@
if (!(runflags L_NOTAGS)) {
cvs_printf(symbolic names:\n);
TAILQ_FOREACH(sym, (cf-file_rcs-rf_symbols), rs_list) {
- rev = rcsnum_alloc();
- rcsnum_cpy(sym-rs_num, rev, 0);
- if (RCSNUM_ISBRANCH(sym-rs_num))
+ if (RCSNUM_ISBRANCH(sym-rs_num)
+!RCSNUM_ISDEFBRANCH(sym-rs_num)) {
+ rev = rcsnum_alloc();
+ rcsnum_cpy(sym-rs_num, rev, 0);
rcsnum_addmagic(rev);
-
- cvs_printf(\t%s: %s\n, sym-rs_name,
- rcsnum_tostr(rev, numb, sizeof(numb)));
- rcsnum_free(rev);
+ cvs_printf(\t%s: %s\n, sym-rs_name,
+ rcsnum_tostr(rev, numb, sizeof(numb)));
+ rcsnum_free(rev);
+ } else
+ cvs_printf(\t%s: %s\n, sym-rs_name,
+ rcsnum_tostr(sym-rs_num, numb, sizeof(numb)));
}
}
Index: rcs.h
===
RCS file: /cvs/src/usr.bin/cvs/rcs.h,v
retrieving revision 1.99
diff -u -r1.99 rcs.h
--- rcs.h 3 Jun 2011 10:02:25 - 1.99
+++ rcs.h 3 Jul 2012 01:38:06 -
@@ -104,6 +104,8 @@
#define RCSNUM_ISBRANCH(n) ((n)-rn_len % 2)
#define
Re: bug fix: 'opencvs log' mangles RCS branch number
On Tue, Jul 3, 2012 at 01:49 UTC, Michael W. Bombardieri m...@ii.net wrote: Sorry, my fault. The intent was bitwise-and not bitwise-or. Third version of the diff follows. In regards to hand optimisations, we could be even worse and do something like add rn_id values, subtract rn_len, check if zero. :) I don't understand why you don't simply write the obvious comparison of each to 1 for equality, anding them together logically, and let the compiler play the bit-twiddling games. Bitwise and will be correct, I believe, but obfuscated in a place where micro-optimization seems pointless. The same goes for the add then subtract alternative. Cheers, Dave Hart
Re: bug fix: 'opencvs log' mangles RCS branch number
On Tue, Jul 03, 2012 at 02:03:39AM +, Dave Hart wrote: On Tue, Jul 3, 2012 at 01:49 UTC, Michael W. Bombardieri m...@ii.net wrote: Sorry, my fault. The intent was bitwise-and not bitwise-or. Third version of the diff follows. In regards to hand optimisations, we could be even worse and do something like add rn_id values, subtract rn_len, check if zero. :) I don't understand why you don't simply write the obvious comparison of each to 1 for equality, anding them together logically, and let the compiler play the bit-twiddling games. Bitwise and will be correct, I believe, but obfuscated in a place where micro-optimization seems pointless. The same goes for the add then subtract alternative. I automatically typed the bitwise code, either because it seems somehow simpler, or because it's marginally less typing. Something like the following might be easier for people to read. I don't have a strong opinion on this in any case. #define RCSNUM_ISDEFBRANCH(n) \ ((n)-rn_len == 3 (n)-rn_id[0] == 1 \ (n)-rn_id[1] == 1 (n)-rn_id[2] == 1) Cheers, Dave Hart
Re: bug fix: 'opencvs log' mangles RCS branch number
On Mon, Jul 02, 2012 at 11:18:21PM -0400, David Higgs wrote: On Mon, Jul 2, 2012 at 10:49 PM, Michael W. Bombardieri m...@ii.net wrote: On Tue, Jul 03, 2012 at 02:03:39AM +, Dave Hart wrote: On Tue, Jul 3, 2012 at 01:49 UTC, Michael W. Bombardieri m...@ii.net wrote: Sorry, my fault. The intent was bitwise-and not bitwise-or. Third version of the diff follows. In regards to hand optimisations, we could be even worse and do something like add rn_id values, subtract rn_len, check if zero. :) I don't understand why you don't simply write the obvious comparison of each to 1 for equality, anding them together logically, and let the compiler play the bit-twiddling games. Bitwise and will be correct, I believe, but obfuscated in a place where micro-optimization seems pointless. The same goes for the add then subtract alternative. I automatically typed the bitwise code, either because it seems somehow simpler, or because it's marginally less typing. Something like the following might be easier for people to read. I don't have a strong opinion on this in any case. #define RCSNUM_ISDEFBRANCH(n) \ ((n)-rn_len == 3 (n)-rn_id[0] == 1 \ (n)-rn_id[1] == 1 (n)-rn_id[2] == 1) Um... Bitwise-or, bitwise-and, summing, and the triple equality test are not equivalent. Unless you intend to match things other than 1.1.1, only the latter is correct. Please refrain from optimizing until you understand why. Noted. I will go back to my corner. --david
