Re: Serial port programming problems
On Sat, May 01, 2010 at 15:30:28 -0700, J.C. Roberts wrote: > > status = tcsetattr(fd, TCSANOW, &options); > > How does it behave if you use "TCSAFLUSH" rather than "TCSANOW" ? I made that substitution and added a #define DEBUG 1 The resulting binary sometimes fails to return and I then have to hit ctrl-c. I've tried it several times, and not seen any (repeating) pattern in terms of when it works and when it fails. Here's some typical output: # grep TCSA ex_obsd_flush.c status = tcsetattr(fd, TCSAFLUSH, &options); # cc -Wall -o ex_obsd_flush ex_obsd_flush.c # time ./ex_obsd_flush Port has been opened and set up 1 bytes available, read: 6 0m1.21s real 0m0.00s user 0m0.00s system # time ./ex_obsd_flush Port has been opened and set up ^C0m6.07s real 0m0.00s user 0m0.00s system # time ./ex_obsd_flush Port has been opened and set up ^C0m7.49s real 0m0.00s user 0m0.00s system # time ./ex_obsd_flush Port has been opened and set up 1 bytes available, read: 6 0m1.21s real 0m0.00s user 0m0.00s system Following this I had two more failures, one success, one failure and one success in that order. -- Neil
partitions
Hi, I'm new to openbsd. Sorry if the question is obvious to you but I couldn't find the answer in the docs. So here it is: what is the reason why the install suggests so many different partitions? Why not simply / and /home for example? Thanks. Cantabile
Re: partitions
On May 02 10:03:21, Cantabile wrote: > Hi, > I'm new to openbsd. Sorry if the question is obvious to you but I couldn't > find the answer in the docs. So here it is: > what is the reason why the install suggests so many different partitions? Why > not simply / and /home for example? Don't just read http://openbsd.org/faq/faq4.html#Partitioning read the whole thing.
Re: partitions
Cantabile writes: > I'm new to openbsd. Sorry if the question is obvious to you but I > couldn't find the answer in the docs. So here it is: what is the > reason why the install suggests so many different partitions? Why > not simply / and /home for example? you actually will find the answer in the faq (very close to the url Jan posted), but I'll offer this: pe...@deeperthought:~$ mount /dev/sd0a on / type ffs (local) /dev/sd0k on /home type ffs (local, nodev, nosuid) /dev/sd0d on /tmp type ffs (local, nodev, nosuid) /dev/sd0f on /usr type ffs (local, nodev) /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev) /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) /dev/sd0e on /var type ffs (local, nodev, nosuid) - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Serial port programming problems
On Sun, May 2, 2010 at 5:33 PM, Neil O'Brien wrote: > On Sat, May 01, 2010 at 15:30:28 -0700, J.C. Roberts wrote: >> > status = tcsetattr(fd, TCSANOW, &options); >> >> How does it behave if you use "TCSAFLUSH" rather than "TCSANOW" ? > > I made that substitution and added a > #define DEBUG 1 > > The resulting binary sometimes fails to return and I then have to > hit ctrl-c. I've tried it several times, and not seen any (repeating) > pattern in terms of when it works and when it fails. > > Here's some typical output: > > # grep TCSA ex_obsd_flush.c > status = tcsetattr(fd, TCSAFLUSH, &options); > # cc -Wall -o ex_obsd_flush ex_obsd_flush.c > # time ./ex_obsd_flush > Port has been opened and set up > 1 bytes available, read: 6 >0m1.21s real 0m0.00s user 0m0.00s system > # time ./ex_obsd_flush > Port has been opened and set up > ^C0m6.07s real 0m0.00s user 0m0.00s system > > # time ./ex_obsd_flush > Port has been opened and set up > ^C0m7.49s real 0m0.00s user 0m0.00s system > > # time ./ex_obsd_flush > Port has been opened and set up > 1 bytes available, read: 6 >0m1.21s real 0m0.00s user 0m0.00s system > > Following this I had two more failures, one success, one failure and > one success in that order. > > -- > Neil > > Hi, Is the system running Linux running on the same type of board as your OpenBSD system? If not, try running Linux on a system identical to the one you're using - see if it's the board causing the problem. Regards -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: How to work around this compiler bug
On Sat, 1 May 2010 14:11:22 +0200 Marc Espie wrote:
> On Sat, May 01, 2010 at 11:39:00AM +0200, Christopher Zimmermann wrote:
> > Hi,
> >
> > the following piece of code compiles fine using g++ 4.2.4, but
> > fails using g++ 3.3.5 in the base system:
> >
> > error: operands to ?: have different types
> >
> > It is part of ptlib, which is the base library for opal, which in
> > turn is needed for ekiga, which I'm trying to port.
> >
> > What is your suggestion? Can anyone think of a workaround for
> > this or should I just compile it using eg++ 4.2.4 ?
> >
> >
> > Christopher
> >
> >
> > #include
> >
> > #define WarnIfNULL(x) ((x) ? (x) : (warn("blub"),(x)))
> >
> > class A
> > {
> > protected:
> > int a;
> > };
> >
> > class B : A
> > {
> > public:
> > void blub()
> > {
> > WarnIfNULL(A::a);
> > }
> > };
>
> Why do some C++ programmer still use macros where they're not needed ?
> bunch of idiots, let them stay with C.
>
> #include
>
> template
> inline T WarnIfNULL(T x)
> {
> if (!x)
> warn("blub");
> return x;
> }
>
> class A
> {
> protected:
> int a;
> };
>
> class B : A
> {
> public:
> void blub()
> {
> WarnIfNULL(A::a);
> }
> };
>
ok, thanks. That seems to be the solution, still I have to wrap it in a macro,
because I need __LINE__, __FILE__, __CLASS__...
Re: partitions
On 05/02/10 05:23, Peter N. M. Hansteen wrote: Cantabile writes: I'm new to openbsd. Sorry if the question is obvious to you but I couldn't find the answer in the docs. So here it is: what is the reason why the install suggests so many different partitions? Why not simply / and /home for example? you actually will find the answer in the faq (very close to the url Jan posted), but I'll offer this: pe...@deeperthought:~$ mount /dev/sd0a on / type ffs (local) /dev/sd0k on /home type ffs (local, nodev, nosuid) /dev/sd0d on /tmp type ffs (local, nodev, nosuid) /dev/sd0f on /usr type ffs (local, nodev) /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev) /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) /dev/sd0e on /var type ffs (local, nodev, nosuid) - P Hey, at least throw in that > /dev/sd0g on /usr/X11R6 type ffs (local, nodev) > /dev/sd0h on /usr/local type ffs (local, nodev) > /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) > /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) as partitions are for convenience, not strictly necessary as partitions. You NEED to understand why, though. Besides the FAQ, read the manual pages, over and over until they start to make sense. (Eventually all will become clear.) :)
Re: partitions
Thanks, everybody! Cantabile Le dimanche 02 mai 2010 C 10:03 +0200, Cantabile a C)crit : > Hi, > I'm new to openbsd. Sorry if the question is obvious to you but I couldn't > find the answer in the docs. So here it is: > what is the reason why the install suggests so many different partitions? Why > not simply / and /home for example? > > Thanks. > Cantabile
Venez me joindre sur « Nous avons la Parole de Dieu »!
Nous avons la Parole de Dieu: Le site Nous avons la Parole de Dieu vous souhaite la bienvenue ! Venez me joindre sur Nous avons la Parole de Dieu! Antoinette Gurrieri Cliquez sur le lien ci-dessous pour vous joindre C un rC)seauB : http://nousavonslaparolededieu.ning.com/?xgi=26mNF5G5ciDhhY&xg_source=msg_invite_net If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser Membres dC)jC sur Nous avons la Parole de Dieu Konan Kouakou Omer, Lesage Marc, tao gerard, PERIE, yvesw...@live.fr Au sujet du rC)seau: Nous avons la Parole de Dieu La vision du site est lbC)vangC)lisation et la proclamation de la Parole de Dieu. 649 membres 416 photos 109 chansons 111 vidC)os 324 discussions 25 billets Pour dC)terminer quels courriels vous recevez dans le coin, ou exclusion, passer C : http://nousavonslaparolededieu.ning.com/?xgo=gXSPQPO7MwtwWIKo0unMNSpVkyWne6n8Gb4Gc6hp-ZhTbeUbMu3rsQ&xg_source=msg_invite_net
low httpd performance. Apache 2.2 as default? never? *sighs
Hi. OpenBSD's stock httpd is very slow and outdated. It is about 6 years old. Almost an abandonware. Is it that impossible to see OpenBSD coming with (chroot'ed) Apache 2.2.x by the default? That would be great! The license problem would be solved by discussing it with the Apache community, imho. http://old.nabble.com/OpenBSD---the-Apache-license-problem.-Why--td28387885.html Thanks
Re: Serial port programming problems
On Sun, May 02, 2010 at 20:56:36 +1000, Aaron Mason wrote: > On Sun, May 2, 2010 at 5:33 PM, Neil O'Brien wrote: > > On Sat, May 01, 2010 at 15:30:28 -0700, J.C. Roberts wrote: > >> > status = tcsetattr(fd, TCSANOW, &options); > >> > >> How does it behave if you use "TCSAFLUSH" rather than "TCSANOW" ? > > > > I made that substitution and added a > > #define DEBUG 1 > > > > The resulting binary sometimes fails to return and I then have to > > hit ctrl-c. I've tried it several times, and not seen any (repeating) > > pattern in terms of when it works and when it fails. > > > Is the system running Linux running on the same type of board as your > OpenBSD system? If not, try running Linux on a system identical to > the one you're using - see if it's the board causing the problem. > Hi Aaron, No, they are very different machines. I don't have a spare ALIX system that I can load Linux onto for testing. If I can't resolve it any other way I will switch my current machine to Linux; but having just got everything set up in OpenBSD, I'd like to avoid that if possible. I have however tried the code in my initial email on a different OpenBSD machine (a Dell Optiplex Pentium II, dmesg is at http://www.tigerturnings.dyndns.dk/dmesg-dell) In this case I used cua0, the onboard serial port, on an ns16550a controller. Running the example from my initial post, with #define DEBUG 1 added and /dev/ttyU0 replaced by /dev/cua00, I get sporadic failures: # time ./ex_obsd_now_cua0 ; sleep 3 ; time ./ex_obsd_now_cua0 Port has been opened and set up 1 bytes available, read: 6 0m0.12s real 0m0.00s user 0m0.00s system Port has been opened and set up ^C0m7.00s real 0m0.00s user 0m0.00s system If I replace TCSANOW with TCSAFLUSH on this machine, it doesn't help, though the instrument does sometimes send 21 (NAK) which I've never seen it do when using TCSANOW. # time ./ex_obsd_flush_cua0 Port has been opened and set up 1 bytes available, read: 6 0m0.14s real 0m0.00s user 0m0.00s system # time ./ex_obsd_flush_cua0 Port has been opened and set up ^C0m3.97s real 0m0.00s user 0m0.01s system # time ./ex_obsd_flush_cua0 Port has been opened and set up ^C0m3.65s real 0m0.00s user 0m0.00s system # time ./ex_obsd_flush_cua0 Port has been opened and set up 1 bytes available, read: 21 Expecting , got 21 0m0.23s real 0m0.00s user 0m0.00s system I think that this should rule out any problems with the USB-RS232 converter or its drivers, and with the USB controller on the ALIX system. I'd be grateful for any further ideas or suggestions. -- Neil
Re: low httpd performance. Apache 2.2 as default? never? *sighs
On Sun, May 2, 2010 at 5:31 PM, Dexter Tomisson wrote: > Hi. > > OpenBSD's stock httpd is very slow and outdated. It is about 6 years old. No, it's not. Stop spreading lies. -- chs
Re: low httpd performance. Apache 2.2 as default? never? *sighs
On Sun, May 02, 2010 at 06:31:22PM +0300, Dexter Tomisson wrote: > Hi. > > OpenBSD's stock httpd is very slow and outdated. It is about 6 years old. > Almost an abandonware. > Is it that impossible to see OpenBSD coming with (chroot'ed) Apache 2.2.x by > the default? No, and by reading your email you know this and still whine about it. > That would be great! pkg_add apache wow I am tired, someone feed me some grapes. > > The license problem would be solved by discussing it with the Apache > community, imho. Go ahead, tell them to make it ISC, BSD or MIT licensed. Good luck with that and report back when it is all done. > > http://old.nabble.com/OpenBSD---the-Apache-license-problem.-Why--td28387885.html > > Thanks
man 4 dc missing
Hi, the manpage for the dc Ethernetcard isn't on my system and in the online manpages. I have 4.6 stable installed und man 4 dc isn't found. The website shows only the manpage for man 1 dc (desktop calculator) and not man 4 dc. But the list on this site shows a dc manpage for section 4: http://www.openbsd.org/cgi-bin/man.cgi?query=(4)&sektion=&apropos=1&manpath=OpenBSD+Current&title=Section Maybe a documentation bug (missing manpage)? Cheers Rene -- Reni Maroufi i...@maroufi.net
Re: low httpd performance. Apache 2.2 as default? never? *sighs
On May 02 18:31:22, Dexter Tomisson wrote: > Hi. > > OpenBSD's stock httpd is very slow and outdated. It is about 6 years old. > Almost an abandonware. > Is it that impossible to see OpenBSD coming with (chroot'ed) Apache 2.2.x by > the default? > That would be great! > > The license problem would be solved by discussing it with the Apache > community, imho. "Police? I just got trolled."
Re: man 4 dc missing
On Sun, May 02, 2010 at 05:53:56PM +0200, Rene Maroufi wrote: > Hi, > > the manpage for the dc Ethernetcard isn't on my system and in the online > manpages. I have 4.6 stable installed und man 4 dc isn't found. The > website shows only the manpage for man 1 dc (desktop calculator) and not > man 4 dc. But the list on this site shows a dc manpage for section 4: > http://www.openbsd.org/cgi-bin/man.cgi?query=(4)&sektion=&apropos=1&manpath=OpenBSD+Current&title=Section > > Maybe a documentation bug (missing manpage)? > > Cheers > Rene > -- > Reni Maroufi > i...@maroufi.net I don't know what you did to your system, but I've checked a 4.6 system and a current system, and both have the dc(4) man page. The web site not showing it is a known problem. -Otto
Re: Serial port programming problems
On Sun, 2 May 2010 16:45:44 +0100 "Neil O'Brien" wrote: > On Sun, May 02, 2010 at 20:56:36 +1000, Aaron Mason wrote: > > On Sun, May 2, 2010 at 5:33 PM, Neil O'Brien > > wrote: > > > On Sat, May 01, 2010 at 15:30:28 -0700, J.C. Roberts wrote: > > >> > status = tcsetattr(fd, TCSANOW, &options); > > >> > > >> How does it behave if you use "TCSAFLUSH" rather than "TCSANOW" ? > > > > > > I made that substitution and added a > > > #define DEBUG 1 > > > > > > The resulting binary sometimes fails to return and I then have to > > > hit ctrl-c. I've tried it several times, and not seen any > > > (repeating) pattern in terms of when it works and when it fails. > > > > > Is the system running Linux running on the same type of board as > > your OpenBSD system? If not, try running Linux on a system > > identical to the one you're using - see if it's the board causing > > the problem. > > > > Hi Aaron, > > No, they are very different machines. I don't have a spare ALIX > system that I can load Linux onto for testing. If I can't resolve it > any other way I will switch my current machine to Linux; but having > just got everything set up in OpenBSD, I'd like to avoid that if > possible. > > I have however tried the code in my initial email on a different > OpenBSD machine (a Dell Optiplex Pentium II, dmesg is at > http://www.tigerturnings.dyndns.dk/dmesg-dell) > > In this case I used cua0, the onboard serial port, on an ns16550a > controller. Running the example from my initial post, with #define > DEBUG 1 added and /dev/ttyU0 replaced by /dev/cua00, I get sporadic > failures: > > # time ./ex_obsd_now_cua0 ; sleep 3 ; time ./ex_obsd_now_cua0 > Port has been opened and set up > 1 bytes available, read: 6 > 0m0.12s real 0m0.00s user 0m0.00s system > Port has been opened and set up > ^C0m7.00s real 0m0.00s user 0m0.00s system > > If I replace TCSANOW with TCSAFLUSH on this machine, it doesn't help, > though the instrument does sometimes send 21 (NAK) which I've never > seen it do when using TCSANOW. > > # time ./ex_obsd_flush_cua0 > Port has been opened and set up > 1 bytes available, read: 6 > 0m0.14s real 0m0.00s user 0m0.00s system > # time ./ex_obsd_flush_cua0 > Port has been opened and set up > ^C0m3.97s real 0m0.00s user 0m0.01s system > > # time ./ex_obsd_flush_cua0 > Port has been opened and set up > ^C0m3.65s real 0m0.00s user 0m0.00s system > > # time ./ex_obsd_flush_cua0 > Port has been opened and set up > 1 bytes available, read: 21 > Expecting , got 21 > 0m0.23s real 0m0.00s user 0m0.00s system > > I think that this should rule out any problems with the USB-RS232 > converter or its drivers, and with the USB controller on the ALIX > system. > > I'd be grateful for any further ideas or suggestions. > > -- Neil > I should be able to figure this out, but my C language serial port hacking skills are a bit rusty. These days, C is only used for time-critical portions of instrument automation for test/mfg environments, but for everything else, languages like perl, tcl or custom/proprietary LabView executables are used. Lots of instruments speak "skippy" (SCPI) otherwise known as Standard Commands for Programmable Instruments. Your *UNNAMED* instrument might speak a custom protocol as you claimed, or it might also speak "skippy" either natively or with some configuration. http://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instrumentation If your instrument can speak "skippy" then your life gets a whole lot easier, so it's definitely worth checking. I'm not sure why you failed to post the make and model number details of your instrument, but they would be really helpful. As I mentioned off list, TCSAFLUSH is often required, but more than that, it's just good practice to flush the buffers to make sure you're starting in a known state (e.g. no crap in the buffers). Both your C code, and not understanding the behavior and output you posted seems to indicate you followed one of the countless (poorly written) how-to pages or books like: http://www.easysw.com/~mike/serial/serial.html The above has some good spots but it also has plenty of errors and unfortunately, it is highly ranked by search engines. In your code you seem to have inherited one of the mistakes, namely you think read(2) gives you "bytes available" rather than "bytes read" as stated (twice) in the read(2) man page. $ man 2 read ... Upon successful completion, read(), readv(), pread(), and preadv() return the number of bytes actually read and placed in the buffer. The system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of- file, but in no other case. ... The other problem is understanding what is happening. Unless you specifically configured the descriptor to return immediately, your read(2) call will sleep
Re: How to work around this compiler bug
On Sun, May 2, 2010 at 3:59 AM, Christopher Zimmermann
wrote:
> On Sat, 1 May 2010 14:11:22 +0200 Marc Espie wrote:
>
>> On Sat, May 01, 2010 at 11:39:00AM +0200, Christopher Zimmermann wrote:
>> > Hi,
>> >
>> > the following piece of code compiles fine using g++ 4.2.4, but
>> > fails using g++ 3.3.5 in the base system:
>> >
>> > error: operands to ?: have different types
>> >
>> > It is part of ptlib, which is the base library for opal, which in
>> > turn is needed for ekiga, which I'm trying to port.
>> >
>> > What is your suggestion? Can anyone think of a workaround for
>> > this or should I just compile it using eg++ 4.2.4 ?
>> >
>> >
>> > Christopher
>> >
>> >
>> > #include
>> >
>> > #define WarnIfNULL(x) ((x) ? (x) : (warn("blub"),(x)))
>> >
>> > class A
>> > {
>> > protected:
>> > int a;
>> > };
>> >
>> > class B : A
>> > {
>> > public:
>> > void blub()
>> > {
>> > WarnIfNULL(A::a);
>> > }
>> > };
>>
>> Why do some C++ programmer still use macros where they're not needed ?
>> bunch of idiots, let them stay with C.
>>
>> #include
>>
>> template
>> inline T WarnIfNULL(T x)
>> {
>> if (!x)
>> warn("blub");
>> return x;
>> }
>>
>> class A
>> {
>> protected:
>> int a;
>> };
>>
>> class B : A
>> {
>> public:
>> void blub()
>> {
>> WarnIfNULL(A::a);
>> }
>> };
>>
>
> ok, thanks. That seems to be the solution, still I have to wrap it in a
macro, because I need __LINE__, __FILE__, __CLASS__...
You example obviously isn't showing the exact usage you require. I
imagine the macro is being used in assignments, not just in the blub()
method as you display.
Cheers,
--patrick
$ cat fuck.c++
#include
#include
#include
#define WarnIfNULL(x) ((!(x) && ((void)warnx("blub"),1)) ? (x) : (x))
class A {
protected:
int a;
};
class B : public A {
public:
voidblub(void) { WarnIfNULL(A::a); }
};
int
main(int argc, char *argv[])
{
int bs = 10;
B cxxsucks;
cxxsucks.blub();
bs = WarnIfNULL(100);
::std::cout << "bullshit: " << bs << ::std::endl;
exit(0);
}
$ c++ fuck.c++
/usr/lib/libstdc++.so.49.0: warning: strcpy() is almost always
misused, please use strlcpy()
/usr/lib/libstdc++.so.49.0: warning: strcat() is almost always
misused, please use strlcat()
$ ./a.out
a.out: blub
bullshit: 100
Re: How to work around this compiler bug
On Sun, May 02, 2010 at 12:54:42PM -0700, patrick keshishian wrote:
> On Sun, May 2, 2010 at 3:59 AM, Christopher Zimmermann
> wrote:
> > On Sat, 1 May 2010 14:11:22 +0200 Marc Espie wrote:
> >
> >> On Sat, May 01, 2010 at 11:39:00AM +0200, Christopher Zimmermann wrote:
> >> > Hi,
> >> >
> >> > the following piece of code compiles fine using g++ 4.2.4, but
> >> > fails using g++ 3.3.5 in the base system:
> >> >
> >> > error: operands to ?: have different types
> >> >
> >> > It is part of ptlib, which is the base library for opal, which in
> >> > turn is needed for ekiga, which I'm trying to port.
> >> >
> >> > What is your suggestion? Can anyone think of a workaround for
> >> > this or should I just compile it using eg++ 4.2.4 ?
> >> >
> >> >
> >> > Christopher
> >> >
> >> >
> >> > #include
> >> >
> >> > #define WarnIfNULL(x) ((x) ? (x) : (warn("blub"),(x)))
> >> >
> >> > class A
> >> > {
> >> > protected:
> >> > int a;
> >> > };
> >> >
> >> > class B : A
> >> > {
> >> > public:
> >> > void blub()
> >> > {
> >> > WarnIfNULL(A::a);
> >> > }
> >> > };
> >>
> >> Why do some C++ programmer still use macros where they're not needed ?
> >> bunch of idiots, let them stay with C.
> >>
> >> #include
> >>
> >> template
> >> inline T WarnIfNULL(T x)
> >> {
> >> if (!x)
> >> warn("blub");
> >> return x;
> >> }
> >>
> >> class A
> >> {
> >> protected:
> >> int a;
> >> };
> >>
> >> class B : A
> >> {
> >> public:
> >> void blub()
> >> {
> >> WarnIfNULL(A::a);
> >> }
> >> };
> >>
> >
> > ok, thanks. That seems to be the solution, still I have to wrap it in a
> > macro, because I need __LINE__, __FILE__, __CLASS__...
>
>
> You example obviously isn't showing the exact usage you require. I
> imagine the macro is being used in assignments, not just in the blub()
> method as you display.
>
Doesn't change a lot.
It's still a very good idea to stay away from macros for most things in C++,
and if you require __LINE__, __FILE__, __func__, *then* you write a proper
inline function (or a template if it needs to be polymorphic), and only wrap
the most external call into a macro that inserts __LINE__... where needed.
That way, you get actual parameter type checking that you can understand,
and the macros themselves.
Everyone sane does things that way, and has used similar tricks even on
C compiler (check a proper getc definition on most any reasonable library,
the macro just inlines the buffer check, and defers the actual complicated
code to an out-of-line function).
Re: man 4 dc missing
On Sun, May 02, 2010 at 08:51:05PM +0200, Otto Moerbeek wrote: > > I don't know what you did to your system, but I've checked a 4.6 > system and a current system, and both have the dc(4) man page. OK, sorry, after a sh /etc/weekly the manpage is shown. It was on my system, but makewhatis was not up to date. Thats my desktop system and i switch it off at night and it doesn't run /etc/weekly. Cheers Reni -- Reni Maroufi i...@maroufi.net
Re: [SOLVED] How to work around this compiler bug
ok, thanks everyone. Problem is solved and I even learned some things, too. Christopher
boot Debian on a RouterStation Pro
Can anyone post a howto/doc, help about booting a Debian on a RouterStation Pro?:\ https://forum.openwrt.org/viewtopic.php?pid=108415#p108415 I still didn't manage to boot from it. Or any other "normal distro" :\ Thank you.. p.s.: a little more detailed howto:\
Re: boot Debian on a RouterStation Pro
On Sun, May 2, 2010 at 15:26, Jozsi Vadkan wrote: > Can anyone post a howto/doc, help about booting a Debian on a > RouterStation Pro?:\ > > https://forum.openwrt.org/viewtopic.php?pid=108415#p108415 > > I still didn't manage to boot from it. > > Or any other "normal distro" :\ > > Thank you.. > > p.s.: a little more detailed howto:\ > > Wrong mailing list, wrong platform, wrong OS... You're just plain wrong... Please take this to a debian mailing list...
Re: Serial port programming problems
On Sun, 2 May 2010 12:01:59 -0700 "J.C. Roberts"
wrote:
> The other problem is understanding what is happening. Unless you
> specifically configured the descriptor to return immediately, your
> read(2) call will sleep until it gets the requested number of bytes
> from the descriptor, until an interval timer expires, or until an
> error occurs. Since the instrument is not sending you any data, it
> sleeps until you lose your patience and hit CTL-C to end the program.
> --This should not be a surprise. ;)
I should have referenced your code so the above makes sense.
>> int open_port(void)
>> {
>> int fd;
>>
>> fd = open("/dev/ttyU0", O_RDWR | O_NOCTTY | O_NDELAY);
>> if (fd < 0)
>> {
>> errx(1,"open_port: Unable to open /dev/ttyS0.");
>> }
>> else
>> {
>> fcntl(fd, F_SETFL, 0);
>> }
>> return (fd);
>> }
Setting O_NDELAY (or better said O_NONBLOCK) on open gets wiped out
when you run "fcntl(fd, F_SETFL, 0)"
I have no idea why you're doing that (probably just mistyped example
code), but if you insist, then you'd actually want:
fcntl(fd, F_SETFL, FNDELAY);
or
fcntl(fd, F_SETFL, FNONBLOCK);
Hence the reason why you're actually blocking on read.
--
The OpenBSD Journal - http://www.undeadly.org
Re: low httpd performance. Apache 2.2 as default? never? *sighs
> OpenBSD's stock httpd is very slow and outdated. It is about 6 years old. > Almost an abandonware. I will print this mail and laugh everyday with it. :)
Re: partitions
On Sun, May 2, 2010 at 4:06 AM, Chris Bennett wrote: > Hey, at least throw in that >> /dev/sd0g on /usr/X11R6 type ffs (local, nodev) >> /dev/sd0h on /usr/local type ffs (local, nodev) >> /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) >> /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) > > as partitions are for convenience, not strictly necessary as partitions. One thing that I'm a little curious about is why the installer by default recommends dedicated partitions for /usr/src and /usr/obj, but not /usr/xenocara or /usr/ports.
Re: partitions
On 05/02/10 20:26, Matthew Dempsky wrote: On Sun, May 2, 2010 at 4:06 AM, Chris Bennett wrote: Hey, at least throw in that /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev) /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) as partitions are for convenience, not strictly necessary as partitions. One thing that I'm a little curious about is why the installer by default recommends dedicated partitions for /usr/src and /usr/obj, but not /usr/xenocara or /usr/ports. Well, /usr/ports is updated, but never needs to be erased unless really messed up by user error I would like to know why the xenocara stuff stuff isn't also offered as partitions. Next time I do a full fresh install, I plan on adding xenocara partitions
Re: partitions
On Sun, May 2, 2010 at 6:46 PM, Chris Bennett wrote: > Well, /usr/ports is updated, but never needs to be erased unless really > messed up by user error That's true of /usr/src too though, right?
OpenBSD disk scheduler
Hi Guys, Reading some archives, I found people saying that OpenBSD has no disk scheduler. My first question is: is this true? If so, what is the reason? Is it technical or there are no resources for this? Thanks in advance, Luis.
Re: low httpd performance. Apache 2.2 as default? never? *sighs
Are you able to read? At least this http://www.openbsd.org/faq/faq1.html#Included and snippet from it : # Our improved and secured version of the Apache 1.3 web server. The OpenBSD team has added default chrooting, privilege revocation, and other security-related improvements. Also includes mod_ssl and DSO support. so version number doesn't mean that it's 6 years old or that it's crappy. On Sun, May 2, 2010 at 5:31 PM, Dexter Tomisson wrote: > Hi. > > OpenBSD's stock httpd is very slow and outdated. It is about 6 years old. > Almost an abandonware. > Is it that impossible to see OpenBSD coming with (chroot'ed) Apache 2.2.x by > the default? > That would be great! > > The license problem would be solved by discussing it with the Apache > community, imho. > > http://old.nabble.com/OpenBSD---the-Apache-license-problem.-Why--td28387885.html > > Thanks > > -- http://www.openbsd.org/lyrics.html
