Desmalezadoras y Bordeadoras

2011-01-06 Thread TBX
Bordeadoraeleacute;ctrica 400w  $  
 110  Bordeadora26cc  $ 
  520 Desmalezadora52cc  $  
 860



Garantovano najniže cene - samo u januaru!

2011-01-06 Thread Top Shop
Top Shop

Ne zaboravite na januarski popust!

Ostalo je još samo 18 dana da iskoristite kupon sa popustom i obezbedite
sebi omiljene proizvode uz 10% popusta! PoEurite i iskoristite odmah
garantovano najniEe cene!

Kod Vašeg kupona je: 84ZEACSKJT

VaEi do 31.1.2011.

*kupon moEete koristiti samo za online kupovinu, *kupon popust od 10% ne
vaEi za prizvode koji su veD na sniEenju , * kupon vaEi do 31.1.2011
i moEe se koristiti samo za jednu porudEbinu

-10%

Kupon*

Kliknite ovde i aktivirajte svoj kupon 

WalkMax - patike za mršavljenje

Walk Max

Redovna cena: 3.990 rsd

Vaša cena: 3.591 rsd

PoruD
ite 

Pillow Pets - plišani ljubimci

Pillow Pets

Redovna cena: 2.290 rsd

Vaša cena: 2.061 rsd

PoruD
ite 

Relax  Tone - ruD
ni masaEer

Relax  Tone

Redovna cena: 4.990 rsd

Vaša cena: 4.491 rsd

PoruD
ite 

Spider Pan - set tiganja

Spider Pan

Redovna cena: 4.990 rsd

Vaša cena: 4.491 rsd

PoruD
ite 

Door Gym Xtreme - fitnes rekvizit

Door Gym Xtreme

Redovna cena: 2.490 rsd

Vaša cena: 2.241 rsd

PoruD
ite 

Cardio Twister - kardio steper

Cardio Twister

Redovna cena: 15.990 rsd

Vaša cena: 14.391 rsd

PoruD
ite 

Ovu elektronsku poštu primate, ukoliko ste svojevoljno ostavili svoju
e-mail adresu na nekom od sajtova Top Shop-a, uD
estvovali u našoj poklon
igri ili nagradnom kvizu ili se prijavili za e-D
asopis Top Shop-a ili
nekog od naših brendova.

Ponude date u ovom e-mailu vaEe iskljuD
ivo za porudEbine upuDene
putem Interneta ili broja telefona 021 489 26 60.

Ukoliko ne Eelite više da primate naše elektronske poruke, za
odjavljivanje sa naše e-mailing liste, kliknite ovde.

Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021
489 26 60, Fax: 021 489 29 08,
E-mail: i...@news.top-shop.rs

[IMAGE]If you would no longer like to receive our emails please
unsubscribe by clicking here.



Re: ls(1) multibyte support

2011-01-06 Thread Alexander Polakov
* Alexander Polakov polac...@gmail.com [110105 17:20]:
 Hi,
 
 here's an updated version.
 
 1) en_US.UTF-8.src updates from FreeBSD
 2) wcwidth() changed to use the same code as iswprint()
* maybe just use iswprint() itself?
 3) _RUNETYPE_SW0 changed to be !0 (and match FreeBSD). 0 value is used in
mklocale to perform additional checks required for MAPLOWER and
MAPUPPER, but not SWIDTHx.

  4) _RUNETYPE_SWM changed to make (r_RUNETYPE_SWM) == _RUNETYPE_SW0
  work


Index: lib/libc/locale/iswctype.c
===
RCS file: /OpenBSD/src/lib/libc/locale/iswctype.c,v
retrieving revision 1.1
diff -u -r1.1 iswctype.c
--- lib/libc/locale/iswctype.c  7 Aug 2005 10:16:23 -   1.1
+++ lib/libc/locale/iswctype.c  6 Jan 2011 16:24:20 -
@@ -170,7 +170,9 @@
 int
 wcwidth(wchar_t c)
 {
-return (((unsigned)__runetype_w(c)  _CTYPE_SWM)  _CTYPE_SWS);
+   if (__isctype_w((c), _CTYPE_R))
+   return (((unsigned)__runetype_w(c)  _CTYPE_SWM)  _CTYPE_SWS);
+   return -1;
 }
 
 wctrans_t
Index: lib/libc/locale/runetype.h
===
RCS file: /OpenBSD/src/lib/libc/locale/runetype.h,v
retrieving revision 1.5
diff -u -r1.5 runetype.h
--- lib/libc/locale/runetype.h  8 Oct 2007 08:17:15 -   1.5
+++ lib/libc/locale/runetype.h  6 Jan 2011 16:24:20 -
@@ -69,9 +69,9 @@
 #define_RUNETYPE_I 0x0008U /* Ideogram */
 #define_RUNETYPE_T 0x0010U /* Special */
 #define_RUNETYPE_Q 0x0020U /* Phonogram */
-#define_RUNETYPE_SWM   0xc000U/* Mask to get screen width data */
+#define_RUNETYPE_SWM   0xe000U /* Mask to get screen width 
data */
 #define_RUNETYPE_SWS   30  /* Bits to shift to get width */
-#define_RUNETYPE_SW0   0xU /* 0 width character */
+#define_RUNETYPE_SW0   0x2000U /* 0 width character */
 #define_RUNETYPE_SW1   0x4000U /* 1 width character */
 #define_RUNETYPE_SW2   0x8000U /* 2 width character */
 #define_RUNETYPE_SW3   0xc000U /* 3 width character */
Index: share/locale/ctype/en_US.UTF-8.src
===
RCS file: /OpenBSD/src/share/locale/ctype/en_US.UTF-8.src,v
retrieving revision 1.1
diff -u -r1.1 en_US.UTF-8.src
--- share/locale/ctype/en_US.UTF-8.src  7 Aug 2005 10:03:45 -   1.1
+++ share/locale/ctype/en_US.UTF-8.src  6 Jan 2011 16:24:39 -
@@ -491,9 +491,9 @@
  * U+0300 - U+036F : Combining Diacritical Marks
  */
 
-GRAPH 0x0300 - 0x034f  0x0360 - 0x036f
-PRINT 0x0300 - 0x034f  0x0360 - 0x036f
-SWIDTH1   0x0300 - 0x034f  0x0360 - 0x036f
+GRAPH 0x0300 - 0x034e  0x0350 - 0x036f
+PRINT 0x0300 - 0x034e  0x0350 - 0x036f
+SWIDTH0   0x0300 - 0x034e  0x0350 - 0x036f
 
 MAPUPPER   0x0345 0x0399 
 
@@ -583,7 +583,7 @@
 LOWER 0x04c8  0x04ca  0x04cc  0x04ce  0x04d1  0x04d3  0x04d5
 LOWER 0x04d7  0x04d9  0x04db  0x04dd  0x04df  0x04e1  0x04e3
 LOWER 0x04e5  0x04e7  0x04e9  0x04eb  0x04ed  0x04ef  0x04f1
-LOWER 0x04f3  0x04f5  0x04f9
+LOWER 0x04f3  0x04f5  0x04f7  0x04f9
 PUNCT 0x0482
 UPPER 0x0400 - 0x042f  0x0460  0x0462  0x0464  0x0466  0x0468
 UPPER 0x046a  0x046c  0x046e  0x0470  0x0472  0x0474  0x0476
@@ -595,9 +595,10 @@
 UPPER 0x04c5  0x04c7  0x04c9  0x04cb  0x04cd  0x04d0  0x04d2
 UPPER 0x04d4  0x04d6  0x04d8  0x04da  0x04dc  0x04de  0x04e0
 UPPER 0x04e2  0x04e4  0x04e6  0x04e8  0x04ea  0x04ec  0x04ee
-UPPER 0x04f0  0x04f2  0x04f4  0x04f8
-PRINT 0x0400 - 0x0486  0x0488 - 0x04ce  0x04d0 - 0x04f5  0x04f8  0x04f9
-SWIDTH1   0x0400 - 0x0486  0x0488 - 0x04ce  0x04d0 - 0x04f5  0x04f8  0x04f9
+UPPER 0x04f0  0x04f2  0x04f4  0x04f6  0x04f8
+PRINT 0x0400 - 0x0486  0x0488 - 0x04ce  0x04d0 - 0x04f9
+SWIDTH0   0x0483 - 0x0486  0x0488 - 0x0489
+SWIDTH1   0x0400 - 0x0482  0x048a - 0x04ce  0x04d0 - 0x04f9
 
 MAPUPPER   0x0430 - 0x044f : 0x0410 
 MAPUPPER   0x0450 - 0x045f : 0x0400 
@@ -671,6 +672,7 @@
 MAPUPPER   0x04f1 0x04f0 
 MAPUPPER   0x04f3 0x04f2 
 MAPUPPER   0x04f5 0x04f4 
+MAPUPPER   0x04f7 0x04f6 
 MAPUPPER   0x04f9 0x04f8 
 MAPLOWER   0x0400 - 0x040f : 0x0450 
 MAPLOWER   0x0410 - 0x042f : 0x0430 
@@ -744,6 +746,7 @@
 MAPLOWER   0x04f0 0x04f1 
 MAPLOWER   0x04f2 0x04f3 
 MAPLOWER   0x04f4 0x04f5 
+MAPLOWER   0x04f6 0x04f7 
 MAPLOWER   0x04f8 0x04f9 
 
 
@@ -1052,7 +1055,8 @@
 GRAPH 0x0e01 - 0x0e3a  0x0e3f - 0x0e5b
 PUNCT 0x0e3f  0x0e4f  0x0e5a  0x0e5b
 PRINT 0x0e01 - 0x0e3a  0x0e3f - 0x0e5b
-SWIDTH1   0x0e01 - 0x0e3a  0x0e3f - 0x0e5b
+SWIDTH0   0x0e31   0x0e34 - 0x0e3a  0x0e47 - 0x0e4e
+SWIDTH1   0x0e01 - 0x0e30  0x0e32 - 0x0e33  0x0e3f - 0x0e46  0x0e4f - 0x0e5b
 
 TODIGIT0x0e50 - 0x0e59 : 0x 
 
@@ -1283,6 +1287,14 @@
 
 TODIGIT0x1810 - 0x1819 : 0x 
 
+/*
+ * U+1DC0 - U+1DFF : Combining Diacritical Marks 

nc -U -u (Unix datagram socket support)

2011-01-06 Thread Jeremy Evans
This patch adds unix datagram socket support to nc(1).  It's basically
the same patch I sent last June (see
http://marc.info/?l=openbsd-techm=127627296925965w=2), but updated
for -current.

Tested on amd64.  Doesn't appear to cause any regressions to existing
support, tested with unix stream and IP stream and datagram sockets.
Looking for OKs.

Jeremy

Index: atomicio.c
===
RCS file: /cvs/src/usr.bin/nc/atomicio.c,v
retrieving revision 1.9
diff -u -p -r1.9 atomicio.c
--- atomicio.c  7 Sep 2007 14:50:44 -   1.9
+++ atomicio.c  6 Jan 2011 21:48:04 -
@@ -53,7 +53,7 @@ atomicio(ssize_t (*f) (int, void *, size
case -1:
if (errno == EINTR)
continue;
-   if (errno == EAGAIN) {
+   if ((errno == EAGAIN) || (errno == ENOBUFS)) {
(void)poll(pfd, 1, -1);
continue;
}
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.98
diff -u -p -r1.98 netcat.c
--- netcat.c3 Jul 2010 04:44:51 -   1.98
+++ netcat.c6 Jan 2011 21:48:04 -
@@ -89,6 +89,7 @@ u_int rtableid;
 int timeout = -1;
 int family = AF_UNSPEC;
 char *portlist[PORT_MAX+1];
+char *unix_dg_tmp_socket;
 
 void   atelnet(int, unsigned char *, unsigned int);
 void   build_ports(char *);
@@ -99,6 +100,7 @@ int  remote_connect(const char *, const c
 intsocks_connect(const char *, const char *, struct addrinfo,
const char *, const char *, struct addrinfo, int, const char *);
 intudptest(int);
+intunix_bind(char *);
 intunix_connect(char *);
 intunix_listen(char *);
 void   set_common_sockopts(int);
@@ -241,8 +243,6 @@ main(int argc, char *argv[])
 
/* Cruft to make sure options are clean, and used properly. */
if (argv[0]  !argv[1]  family == AF_UNIX) {
-   if (uflag)
-   errx(1, cannot use -u and -U);
host = argv[0];
uport = NULL;
} else if (argv[0]  !argv[1]) {
@@ -265,6 +265,18 @@ main(int argc, char *argv[])
if (!lflag  kflag)
errx(1, must use -l with -k);
 
+   /* Get name of temporary socket for unix datagram client */
+   if ((family == AF_UNIX)  uflag  !lflag) {
+   if(pflag) {
+   unix_dg_tmp_socket = pflag;
+   } else {
+   if((unix_dg_tmp_socket = (char *)malloc(19)) == NULL)
+   errx(1, not enough memory);
+   strlcpy(unix_dg_tmp_socket, /tmp/nc.XX, 19);
+   mktemp(unix_dg_tmp_socket);
+   }
+   }
+
/* Initialize addrinfo structure. */
if (family != AF_UNIX) {
memset(hints, 0, sizeof(struct addrinfo));
@@ -307,8 +319,12 @@ main(int argc, char *argv[])
int connfd;
ret = 0;
 
-   if (family == AF_UNIX)
-   s = unix_listen(host);
+   if (family == AF_UNIX) {
+   if(uflag)
+   s = unix_bind(host);
+   else
+   s = unix_listen(host);
+   }
 
/* Allow only one connection at a time, but stay alive. */
for (;;) {
@@ -337,17 +353,19 @@ main(int argc, char *argv[])
if (rv  0)
err(1, connect);
 
-   connfd = s;
+   readwrite(s);
} else {
len = sizeof(cliaddr);
connfd = accept(s, (struct sockaddr *)cliaddr,
len);
+   readwrite(connfd);
+   close(connfd);
}
 
-   readwrite(connfd);
-   close(connfd);
if (family != AF_UNIX)
close(s);
+   else if (uflag)
+   connect(s, NULL, 0);
 
if (!kflag)
break;
@@ -361,6 +379,8 @@ main(int argc, char *argv[])
} else
ret = 1;
 
+   if(uflag)
+   unlink(unix_dg_tmp_socket);
exit(ret);
 
} else {
@@ -421,18 +441,19 @@ main(int argc, char *argv[])
 }
 
 /*
- * unix_connect()
- * Returns a socket connected to a local unix socket. Returns -1 on failure.
+ * unix_bind()
+ * Returns a unix socket bound to the given path
  */
 int
-unix_connect(char *path)
+unix_bind(char *path)
 {
struct 

Re: nc -U -u (Unix datagram socket support)

2011-01-06 Thread Ted Unangst
On Thu, Jan 6, 2011 at 6:32 PM, Jeremy Evans jer...@openbsd.org wrote:
 This patch adds unix datagram socket support to nc(1).  It's basically
 the same patch I sent last June (see
 http://marc.info/?l=openbsd-techm=127627296925965w=2), but updated
 for -current.

 Tested on amd64.  Doesn't appear to cause any regressions to existing
 support, tested with unix stream and IP stream and datagram sockets.
 Looking for OKs.

Why is the socket name specified via -p for datagrams or possibly
random?  Shouldn't this be just like the stream unix code?

 +   /* Get name of temporary socket for unix datagram client */
 +   if ((family == AF_UNIX)  uflag  !lflag) {
 +   if(pflag) {
 +   unix_dg_tmp_socket = pflag;
 +   } else {
 +   if((unix_dg_tmp_socket = (char *)malloc(19)) ==
NULL)
 +   errx(1, not enough memory);
 +   strlcpy(unix_dg_tmp_socket, /tmp/nc.XX,
19);
 +   mktemp(unix_dg_tmp_socket);
 +   }
 +   }
 +



Re: nc -U -u (Unix datagram socket support)

2011-01-06 Thread Jeremy Evans
On 01/06 07:07, Ted Unangst wrote:
 On Thu, Jan 6, 2011 at 6:32 PM, Jeremy Evans jer...@openbsd.org wrote:
  This patch adds unix datagram socket support to nc(1). ?It's basically
  the same patch I sent last June (see
  http://marc.info/?l=openbsd-techm=127627296925965w=2), but updated
  for -current.
 
  Tested on amd64. ?Doesn't appear to cause any regressions to existing
  support, tested with unix stream and IP stream and datagram sockets.
  Looking for OKs.
 
 Why is the socket name specified via -p for datagrams or possibly
 random?  Shouldn't this be just like the stream unix code?

I believe that for unix stream sockets, you don't need to have a sending
socket file created, while you do for datagram sockets, as otherwise you
can't have a bidirectional connection.

I have no problem with always using a random sending socket file, and
ignoring -p in the unix datagram case, if you think that is best.
Thinking more about it, -s would be more appropriate than -p anyway if
you did want to specify the source socket.

Jeremy

 
  + ? ? ? /* Get name of temporary socket for unix datagram client */
  + ? ? ? if ((family == AF_UNIX)  uflag  !lflag) {
  + ? ? ? ? ? ? ? if(pflag) {
  + ? ? ? ? ? ? ? ? ? ? ? unix_dg_tmp_socket = pflag;
  + ? ? ? ? ? ? ? } else {
  + ? ? ? ? ? ? ? ? ? ? ? if((unix_dg_tmp_socket = (char *)malloc(19)) == 
  NULL)
  + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? errx(1, not enough memory);
  + ? ? ? ? ? ? ? ? ? ? ? strlcpy(unix_dg_tmp_socket, /tmp/nc.XX, 
  19);
  + ? ? ? ? ? ? ? ? ? ? ? mktemp(unix_dg_tmp_socket);
  + ? ? ? ? ? ? ? }
  + ? ? ? }
  +



Re: nc -U -u (Unix datagram socket support)

2011-01-06 Thread Ted Unangst
On Thu, Jan 6, 2011 at 7:19 PM, Jeremy Evans jer...@openbsd.org wrote:
 I believe that for unix stream sockets, you don't need to have a sending
 socket file created, while you do for datagram sockets, as otherwise you
 can't have a bidirectional connection.

 I have no problem with always using a random sending socket file, and
 ignoring -p in the unix datagram case, if you think that is best.
 Thinking more about it, -s would be more appropriate than -p anyway if
 you did want to specify the source socket.

The part that's confusing me is, who is at the other end of this tmp
socket?  How do they know about it?



Re: increase i386 data size

2011-01-06 Thread Ariane van der Steldt
On Fri, Dec 24, 2010 at 05:14:13PM -0500, Ted Unangst wrote:
 On Fri, Dec 24, 2010 at 5:02 PM, Mark Kettenis mark.kette...@xs4all.nl
 wrote:
  Date: Fri, 24 Dec 2010 16:54:23 -0500 (EST)
  From: Ted Unangst ted.unan...@gmail.com
 
  increase the hard limit on i386 max data size to 2GB-1.  This will allow
  memory hungry processes to potentially use more RAM if you increase data
  limits appropriately.
 
  I really think that -1 is odd.  Where would those potential overflows be?
 
 Anyone who stores the limit in a signed int (or long).  Do I know of
 any such software?  No.  Am I willing to risk the possibility of such
 existing to squeeze out a few more bytes?  No.
 
 I will happily set it to straight 2GB, or even higher if we don't care
 about possible trouble, so long as everybody promises not to complain
 if an issue is found. :)

I object against the -1. MAXDSIZ is always compared against multiples of
page size, so there is no reason to make it not a multiple of page size.
Furthermore, the -1 means that a calculation like what's the first page
after data becomes hell.

I have no objection against -PAGE_SIZE. But for that matter, I don't
object against plain 2GB either. It shouldn't end up in a signed value
anyway.

-- 
Ariane



Re: nc -U -u (Unix datagram socket support)

2011-01-06 Thread Jeremy Evans
On 01/06 08:56, Ted Unangst wrote:
 On Thu, Jan 6, 2011 at 7:19 PM, Jeremy Evans jer...@openbsd.org wrote:
  I believe that for unix stream sockets, you don't need to have a sending
  socket file created, while you do for datagram sockets, as otherwise you
  can't have a bidirectional connection.
 
  I have no problem with always using a random sending socket file, and
  ignoring -p in the unix datagram case, if you think that is best.
  Thinking more about it, -s would be more appropriate than -p anyway if
  you did want to specify the source socket.
 
 The part that's confusing me is, who is at the other end of this tmp
 socket?  How do they know about it?

With a stream socket where you are acting as a client, you don't need a
temporary socket created, because a stream socket is bidirectional. If
you send a datagram to a server listening on a unix datagram socket,
there is no way for the server program to respond to you unless the
sending program is also bound to a socket.

So with this patch, if you are operating nc in client mode and
sending a datagram to a unix datagram socket, nc binds a temporary
unix datagram socket so that you can receive responses.

guenther@ agreed back in 2008 that it was necessary to create a
temporary socket if you want bidirectional communication, see
http://marc.info/?l=openbsd-techm=120299257422367w=2.  He also
mentioned that it might be beneficial to implement two modes, one
providing bidirectional and one providing unidirectional, but I have
not implemented that (yet).

Jeremy



Re: increase i386 data size

2011-01-06 Thread Ted Unangst
On Thu, Jan 6, 2011 at 9:34 PM, Ariane van der Steldt ari...@stack.nl wrote:
 I have no objection against -PAGE_SIZE. But for that matter, I don't
 object against plain 2GB either. It shouldn't end up in a signed value
 anyway.

we're going to go with flat 2GB after all.



Canon EOS - Digital Reflex

2011-01-06 Thread DigitalesNet
USD870Camara Digital CANON EOS 500D T1I
KIT 18-55 Caacute;mara  reacute;flex
digital de objetivos intercambiables  /
Sensor de imagen Tipo CMOS / Tamantilde;o 22.30
 x 14.90 mm / Filtro de color RGB / Espacio de  
   color sRGB, Adobe RGB / Resolucioacute;n Total  
   15.5 MP Consutetambieacute;n por
Body y Kit 18-135