Re: KVM mice issues
hi, Yep. In order to avoid moused(8) getting something crazy (after console switch) I just forced psm reset after synchronization error detection. It can be achieved by changing changing of PSM_SYNCERR_THRESHOLD1 define from 20 to 0 (in file sys/isa/psm.c). Please try to do it and let me know result, if you're also happy with solution -- I'll cleanup and commit my patch which forces such behaviour using sysctl(8). On Mon, Mar 24, 2003 at 12:50:24PM +0200, Ruslan Ermilov wrote: > I think Alexey was having similar issues, and may have some > non-production quality patches for you to try. > > On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote: > > > > Greetings hackers, > > > > I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse, > > and I've found that while FreeBSD properly detects the mouse and all its > > functionality (buttons, scrollwheel, etc) upon boot if I switch to > > another port on the KVM and then switch back my mouse "loses" its > > functionality. > > > > After spending a while trying to figure out this problem (and reading PRs > > on the issue (esp. i386/25463)) I found that a solution was not > > immediately available, but might be somewhat easy to achieve. In > > particular, for my mouse, the mouse driver can and does detect invalid > > packets, and invalid packets are always received after a return to my > > FreeBSD system via the KVM. I found that doing a reinitialization of the > > device would fix the mouse, but that doing it from the interrupt handler > > (in sys/isa/psm.c around line 2170) caused some intermediate problems. > > Normally the mouse would just bounce around and generate click events for > > a while and then settle down, but occasionally the driver (or maybe > > mouse?) would lock solid and I'd have to reboot the system. > > > > Anyways, I'd like to work further on this problem and hopefully find a > > solution, but I'm having some trouble understanding where and what I > > should do. I'm not a novice C hacker, but I *am* a very novice kernel > > hacker and would appreciate help from anyone with knowledge of the psm > > (and atkbdc) code. I've considered maybe adding an ioctl to reset the > > mouse and adding a signal handler to moused to force a reset, but that > > seems kind of silly when the kernel driver can detect the problem itself > > and resolve it. On the other hand, maybe that's the right way to go? > > Advice would be greatly appreciated. > > > > -chip > > -- > > chip norkus; renaissance hacker;[EMAIL PROTECTED] > > "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/ > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Ruslan ErmilovSysadmin and DBA, > [EMAIL PROTECTED] Sunbay Software AG, > [EMAIL PROTECTED] FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.orgThe Power To Serve > http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CFR: [Fwd: generalized "\'" flag support for vfprintf() (for both decimal and float numbers)]
hi,
Constructive comments are welcome!
- Forwarded message from Alexey Zelkin <[EMAIL PROTECTED]> -
From: Alexey Zelkin <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: generalized "\'" flag support for vfprintf() (for both decimal and float
numbers)
hi,
Heh, just finished it and it passed my basic tests.
Tommorow I'll go with its cleanup, but anyway
it would be interesting to listen opinions on the
way how it's done.
Index: vfprintf.c
===
RCS file: /home/cvs/freebsd/src/lib/libc/stdio/vfprintf.c,v
retrieving revision 1.36
diff -u -r1.36 vfprintf.c
--- vfprintf.c 17 Dec 2001 15:11:29 - 1.36
+++ vfprintf.c 10 Feb 2002 18:04:30 -
@@ -114,12 +114,11 @@
static int __sprint __P((FILE *, struct __suio *));
static int __sbprintf __P((FILE *, const char *, va_list)) __printflike(2, 0);
-static char*__ujtoa __P((uintmax_t, char *, int, int, char *, int,
-char, const char *));
-static char*__ultoa __P((u_long, char *, int, int, char *, int,
-char, const char *));
+static char*__ujtoa __P((uintmax_t, char *, int, int, char *));
+static char*__ultoa __P((u_long, char *, int, int, char *));
static void__find_arguments __P((const char *, va_list, union arg **));
static void__grow_type_table __P((int, enum typeid **, int *));
+static int __do_grouping __P((char *buf, char **cp, int size, int safety));
/*
* Flush out all the vectors defined by the given uio,
@@ -186,12 +185,10 @@
* use the given digits.
*/
static char *
-__ultoa(u_long val, char *endp, int base, int octzero, char *xdigs,
- int needgrp, char thousep, const char *grp)
+__ultoa(u_long val, char *endp, int base, int octzero, char *xdigs)
{
register char *cp = endp;
register long sval;
- int ndig;
/*
* Handle the three cases separately, in the hope of getting
@@ -203,7 +200,6 @@
*--cp = to_char(val);
return (cp);
}
- ndig = 0;
/*
* On many machines, unsigned arithmetic is harder than
* signed arithmetic, so we do at most one unsigned mod and
@@ -212,29 +208,11 @@
*/
if (val > LONG_MAX) {
*--cp = to_char(val % 10);
- ndig++;
sval = val / 10;
} else
sval = val;
do {
*--cp = to_char(sval % 10);
- ndig++;
- /*
-* If (*grp == CHAR_MAX) then no more grouping
-* should be performed.
-*/
- if (needgrp && ndig == *grp && *grp != CHAR_MAX
- && sval > 9) {
- *--cp = thousep;
- ndig = 0;
- /*
-* If (*(grp+1) == '\0') then we have to
-* use *grp character (last grouping rule)
-* for all next cases
-*/
- if (*(grp+1) != '\0')
- grp++;
- }
sval /= 10;
} while (sval != 0);
break;
@@ -263,50 +241,28 @@
/* Identical to __ultoa, but for intmax_t. */
static char *
-__ujtoa(uintmax_t val, char *endp, int base, int octzero, char *xdigs,
- int needgrp, char thousep, const char *grp)
+__ujtoa(uintmax_t val, char *endp, int base, int octzero, char *xdigs)
{
char *cp = endp;
intmax_t sval;
- int ndig;
/* quick test for small values; __ultoa is typically much faster */
/* (perhaps instead we should run until small, then call __ultoa?) */
if (val <= ULONG_MAX)
- return (__ultoa((u_long)val, endp, base, octzero, xdigs,
- needgrp, thousep, grp));
+ return (__ultoa((u_long)val, endp, base, octzero, xdigs));
switch (base) {
case 10:
if (val < 10) {
*--cp = to_char(val % 10);
return (cp);
}
- ndig = 0;
if (val > INTMAX_MAX) {
*--cp = to_char(val % 10);
- ndig++;
sval = val / 10;
} else
sval = val;
do {
*--cp = to_char(sval % 10);
- ndig++;
- /*
-
Germany trip
Folks, I'll be visiting Germany for next week. My primary targets are Hannover (for CeBIT show), Trier (and possibly Amsterdam, not Germany though, but... :-). Because of this trip I'll be rarely available at e-mail. If you will be experiencing any problems with my recent locale/stdtime MFCs during period of my absence please dig Andrey Chernov <[EMAIL PROTECTED]> for immediate reaction (since he is one of authors of this code) or be patient until I return back. Thanks! PS: If you're living in one of cities mentioned above I'll be happy to meet and get a "cup" of beer or vodka along with pleasant conversation ;-) Drop me a line privately in this case. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CFR: NLS build infrastructure ...
hi,
I've investigated NetBSD's infrastructure used to build/install NLS
files and based on their ideas wrote small additional include file
for /usr/share/mk. I'm not make(1) guru and expect to have there some
bogons.
Since we have now two consumers of NLS catalogs in tree (tcsh and ee)
I've also attached patches which are supposed to convert current way
of NLS files handling into new include .mk file logic.
Attached files are:
1. bsd.nls.mk -- include file supposed to be installed to /usr/share/mk
2. csh.nls.Makefile.patch -- patch for src/bin/csh/nls/Makefile. Applying
of this patch also iluminates need of src/bin/csh/nls/*/Makefile since
it's completely replaces them.
3. ee.Makefile.patch -- patch for src/usr.bin/ee/Makefile
NOTE: These patches are not {build,install}world tested (local tests only)
and provided for review, feedbacks or objections only.
# $NetBSD: bsd.nls.mk,v 1.35 2001/11/28 20:19:08 tv Exp $
# $FreeBSD$
#
# This include file handles building and installing Native
# Language Support (NLS) catalogs
#
# +++ variables +++
#
# GENCATA program for converting .msg files into compiled NLS
# .cat files. [gencat -new]
#
# NLS Source or intermediate .msg files. [set in Makefile]
#
# NLSDIRBase path for National Language Support files
# installation. [${SHAREDIR}/nls]
#
# NLSGRPNational Language Support files group. [${SHAREGRP}]
#
# NLSMODE National Language Support files mode. [${NOBINMODE}]
#
# NLSOWNNational Language Support files owner. [${SHAREOWN}]
#
# NONLS Do not make or install NLS files. [not set]
#
# +++ targets +++
#
# install:
# Install compiled NLS files
#
# bsd.obj.mk: cleandir and obj
# XXX: test with buildworld -- ${DESTDIR}${NLSDIR}
#
GENCAT?=gencat -new
# from NetBSD -- to use in libraries
#NLSNAME?= ${PROG:Ulib${LIB}}
NLSDIR?=${SHAREDIR}/nls
NLSGRP?=${SHAREGRP}
NLSMODE?= ${NOBINMODE}
NLSOWN?=${SHAREOWN}
NLS?=
.MAIN: all
.SUFFIXES: .cat .msg
.msg.cat:
${GENCAT} ${.TARGET} ${.IMPSRC}
#
# .msg file pre-build rules
#
.for file in ${NLS}
.if defined(NLSSRCFILES_${file})
${file}:
@rm -f ${.TARGET}
cat ${NLSSRCDIR_${file}}/${NLSSRCFILES_${file}} > ${.TARGET}
.endif
CLEANFILES+= ${file}
.endfor
#
# .cat file build rules
#
NLSALL= ${NLS:.msg=.cat}
CLEANFILES+=${NLSALL}
#
# installation rules
#
__nlsinstall: .USE
${INSTALL} -o ${NLSOWN} -g ${NLSGRP} -m ${NLSMODE} \
${.ALLSRC} ${.TARGET}
.for F in ${NLSALL}
_F:=${DESTDIR}${NLSDIR}/${F:T:R}/${NLSNAME}.cat
${_F}: ${F} __nlsinstall # install rule
nlsinstall::${_F}
.PRECIOUS: ${_F} # keep if install fails
.endfor
#
.if !defined(NONLS) && !empty(NLS)
all-nls: ${NLSALL}
.else
all-nls:
.endif
all:all-nls _SUBDIR
install:beforeinstall nlsinstall afterinstall
.if !target(distribute)
distribute:
.endif
.if !target(beforeinstall)
beforeinstall:
.endif
.if !target(afterinstall)
afterinstall:
.endif
.include
Index: Makefile
===
RCS file: /cvs/freebsd/src/usr.bin/ee/Makefile,v
retrieving revision 1.19
diff -u -r1.19 Makefile
--- Makefile17 Dec 2001 13:59:33 - 1.19
+++ Makefile14 Feb 2002 15:06:07 -
@@ -15,17 +15,12 @@
8859_15_LINKS = fr_FR de_DE
ENUS_LINKS = ISO8859-1 ISO8859-15
-FILES= ${LANGS:S/$/.ee.cat/}
-CLEANFILES+= ${FILES}
+NLSNAME=ee
.for lang in ${LANGS}
-${lang}.ee.cat: ${.CURDIR}/nls/${lang}/ee.msg
- gencat -new ${.TARGET} ${.ALLSRC}
-.endfor
-
-.for lang in ${LANGS}
-FILESDIR_${lang:S/$/.ee.cat/}= ${NLSDIR}/${lang}
-FILESNAME_${lang:S/$/.ee.cat/}=ee.cat
+NLSSRCDIR_${lang}.msg=${.CURDIR}/nls/${lang}
+NLSSRCFILES_${lang}.msg=ee.msg
+NLS+=${lang}.msg
.endfor
.for link in ${ENUS_LINKS}
@@ -36,3 +31,4 @@
.endfor
.include
+.include
Index: Makefile
===
RCS file: /cvs/freebsd/src/bin/csh/nls/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- Makefile5 Sep 2001 18:10:27 - 1.9
+++ Makefile14 Feb 2002 15:09:25 -
@@ -1,5 +1,24 @@
-# $FreeBSD: src/bin/csh/nls/Makefile,v 1.9 2001/09/05 18:10:27 mp Exp $
+# $FreeBSD$
-SUBDIR= et finnish french german greek italian ja russian spanish ukrainian
+BASESRC= ${.CURDIR}/../../../contrib/tcsh/nls
-.include
+CATALOGS= et:et_EE.ISO8859-15 \
+ finnish:fi_FI.ISO8859-1 \
+ french:fr_FR.ISO8859-1 \
+ german:de_DE.ISO8859-1 \
+ greek:el_GR.ISO8859-7 \
+ italian:it_IT.ISO8859-1 \
+ ja:ja_JP.eucJP \
+ russian:ru_RU.KOI8-R \
+ spanish:es_ES.ISO8859-1 \
+ ukrainian:uk_UA.KOI8-U
+
+NLSNAME= tcsh
+
+.for catalog in ${CATALOGS}
+NLSSRCDIR_${catalog:C/.*://g}.msg:= ${BASESRC}/${catalog:C/:.*//g}
CFR: printf grouping support for floats (%'f)
hi,
This patch fixes *printf() family routines to correctly handle
grouping for both decimals and floats. Current version of printf()
supports grouping for decimals only.
Yes, I know it looks like more hackish way, so other opinions are
welcome!
Since printf() is widely used and quite important function I'd like
to get as much comments as possible (optimizations, simplifications,
others)
Index: vfprintf.c
===
RCS file: /home/cvs/freebsd/src/lib/libc/stdio/vfprintf.c,v
retrieving revision 1.36
diff -u -r1.36 vfprintf.c
--- vfprintf.c 17 Dec 2001 15:11:29 - 1.36
+++ vfprintf.c 12 Feb 2002 13:02:00 -
@@ -114,12 +114,11 @@
static int __sprint __P((FILE *, struct __suio *));
static int __sbprintf __P((FILE *, const char *, va_list)) __printflike(2, 0);
-static char*__ujtoa __P((uintmax_t, char *, int, int, char *, int,
-char, const char *));
-static char*__ultoa __P((u_long, char *, int, int, char *, int,
-char, const char *));
+static char*__ujtoa __P((uintmax_t, char *, int, int, char *));
+static char*__ultoa __P((u_long, char *, int, int, char *));
static void__find_arguments __P((const char *, va_list, union arg **));
static void__grow_type_table __P((int, enum typeid **, int *));
+static int __do_grouping __P((char *, char **, int, int));
/*
* Flush out all the vectors defined by the given uio,
@@ -186,12 +185,10 @@
* use the given digits.
*/
static char *
-__ultoa(u_long val, char *endp, int base, int octzero, char *xdigs,
- int needgrp, char thousep, const char *grp)
+__ultoa(u_long val, char *endp, int base, int octzero, char *xdigs)
{
register char *cp = endp;
register long sval;
- int ndig;
/*
* Handle the three cases separately, in the hope of getting
@@ -203,7 +200,6 @@
*--cp = to_char(val);
return (cp);
}
- ndig = 0;
/*
* On many machines, unsigned arithmetic is harder than
* signed arithmetic, so we do at most one unsigned mod and
@@ -212,29 +208,11 @@
*/
if (val > LONG_MAX) {
*--cp = to_char(val % 10);
- ndig++;
sval = val / 10;
} else
sval = val;
do {
*--cp = to_char(sval % 10);
- ndig++;
- /*
-* If (*grp == CHAR_MAX) then no more grouping
-* should be performed.
-*/
- if (needgrp && ndig == *grp && *grp != CHAR_MAX
- && sval > 9) {
- *--cp = thousep;
- ndig = 0;
- /*
-* If (*(grp+1) == '\0') then we have to
-* use *grp character (last grouping rule)
-* for all next cases
-*/
- if (*(grp+1) != '\0')
- grp++;
- }
sval /= 10;
} while (sval != 0);
break;
@@ -263,50 +241,28 @@
/* Identical to __ultoa, but for intmax_t. */
static char *
-__ujtoa(uintmax_t val, char *endp, int base, int octzero, char *xdigs,
- int needgrp, char thousep, const char *grp)
+__ujtoa(uintmax_t val, char *endp, int base, int octzero, char *xdigs)
{
char *cp = endp;
intmax_t sval;
- int ndig;
/* quick test for small values; __ultoa is typically much faster */
/* (perhaps instead we should run until small, then call __ultoa?) */
if (val <= ULONG_MAX)
- return (__ultoa((u_long)val, endp, base, octzero, xdigs,
- needgrp, thousep, grp));
+ return (__ultoa((u_long)val, endp, base, octzero, xdigs));
switch (base) {
case 10:
if (val < 10) {
*--cp = to_char(val % 10);
return (cp);
}
- ndig = 0;
if (val > INTMAX_MAX) {
*--cp = to_char(val % 10);
- ndig++;
sval = val / 10;
} else
sval = val;
do {
*--cp = to_char(sval % 10);
- ndig++;
- /*
-* If (*grp == CHAR_MAX) then no more grouping
-* should be performed.
-*/
- if (needgrp && *grp != CHAR_MAX && ndig == *grp
-
Re: wc* function
On Thu, Dec 06, 2001 at 12:04:31AM +0300, Sergey Matveychuk wrote: > > Check out Citrus[1] project's CVS Repo. They have quite promising > implementation > > of w* functions. Also as I recall correctly some amount of w* functions > > are already commited in. > > > > [1] http://citurs.bsdclub.org > > Link is dead. Can you check it? Ugh! Typo :-( http://citrus.bsdclub.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wc* function
hi, On Wed, Dec 05, 2001 at 03:28:29PM +0300, Sergey Matveychuk wrote: > According to mail archive, work on supporting wide-char functions was in > progress some time but then stopped. > > May be is there some results of this work somewhere? Continue will better > than beginning from scratch. Check out Citrus[1] project's CVS Repo. They have quite promising implementation of w* functions. Also as I recall correctly some amount of w* functions are already commited in. [1] http://citurs.bsdclub.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: whois(1) patch for review
hi, On Fri, Jun 22, 2001 at 03:37:17AM +0200, Dag-Erling Smorgrav wrote: > > Arg.. I wish you had contacted me before doing this work. From looking at > > your patch, your using an old copy of my work. The newest one is available > > at: http://testbed.q9media.net/freebsd/whois.patch and will be committed > > very-shortly-now(tm). > > Since Mike's patch is a style cleanup with no functional impact except > plugging a memory leak, I feel it's better to commit it first, and > merge in Alexey's patch later, after it's been reviewed by this forum. Thanks! It makes things easer :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: whois(1) patch for review
hi, On Thu, Jun 21, 2001 at 04:25:46PM +0300, Peter Pentchev wrote: > > I have made few modifications to whois(1) to shut up BDECFLAGS > > warnings, cleanup code, and add new features. > [snip] > > > > Resume: with this patch included to add new country's whois server > > we'll need to add only one string to text file, not to modify > > whois(1) code as it has been done by Andrey for '-R' and as > > some pending PR's proposed to do. > > > > PS: I also removed -R switch for whois(1) which was used to point > > to Russian whois server, since it is replaced with "-c ru" > > > > PPS: It's tested on STABLE, but I don't think that there can be problems > > with -current. > > > > PPPS: Patch is dirty threfore any ideas on its cleanup are welcome. Also > > additional idea on improving whois(1) flexibility are welcome! I hope to > > get some free time on this weekend and commit it if nobody has strong > > objections. > > > > http://phantom.cris.net/~phantom/whois_patch.tgz > > Wow. > > I think there's been a GREAT deal of duplication of effort over whois(1).. > > Have you looked at Mike Barcroft's patches, posted both as a PR and > as a longish thread on -audit a couple of days ago, or at Joachim > Strombergson's patches, posted as a longish thread on -audit a month > or so ago? > > My understanding is that Mike Barcroft's patches remove the warnings, > and Joachim Strombergson was working on the server list thing :) I did not follow things going on carefully for almost two months while I'd a deal with graduate project, but now since it's finished (Yay!!!) and I got some time I started to dig to old patches (made during last three months) and it's one of them. :) I'd incorporated few missing points from Mike's PR and have on hold Joachim's (I have plans and ideas to make it even more optimized). So, if people also started to work on this topic it shows its actuality, IMHO. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
whois(1) patch for review
hi, I have made few modifications to whois(1) to shut up BDECFLAGS warnings, cleanup code, and add new features. Main aim of this patch is to add flexibility to people who want to point whois(1) to non-deault whois server, i.e. have to type "-h server name" many times. It adds new command line modifier "-c" to declare server code. Originally it was supposed to point to country's whois server, but with no modifications can be used for other areas. For example you can have following string in your whoisservers configuration file (system wide -- /usr/share/misc/whoiservers or personal ~/.whoisservers): local whois.mydomain.com To point whois(1) to this server now you need to use whois -h whois.mydaomin.com XYZ with patch whois -clocal XYZ It also supposed to be used for country's whois servers. For example with whoisservers. ... ru whois.ripn.net ua whois.net.ua ... whois -c ru freebsd.org.ru (use -- whois.ripn.net) whois -c ua freebsd.org.ua (use -- whois.net.ua) Resume: with this patch included to add new country's whois server we'll need to add only one string to text file, not to modify whois(1) code as it has been done by Andrey for '-R' and as some pending PR's proposed to do. PS: I also removed -R switch for whois(1) which was used to point to Russian whois server, since it is replaced with "-c ru" PPS: It's tested on STABLE, but I don't think that there can be problems with -current. PPPS: Patch is dirty threfore any ideas on its cleanup are welcome. Also additional idea on improving whois(1) flexibility are welcome! I hope to get some free time on this weekend and commit it if nobody has strong objections. http://phantom.cris.net/~phantom/whois_patch.tgz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Monthly Development Status Report, June 2001
hi, On Wed, Jun 13, 2001 at 09:47:52PM -0500, Chris Costello wrote: > > If this ends up being the case (i.e., there's an issue approx. once a > > month), how about archiving them on the web site? We used to have a > > "newsletter", but it quickly grew stale. This sounds like something > > developers actually might be interested in (there's no glory in > > writing something if nobody knows about it ;-) ), so it has a much > > better chance of succeeding. > > > > I don't know if it's worth putting the first issue up not knowing if > > there will be more; anybody else have an opinion on this? > >I'm thinking perhaps it should be made into part of the doc > project. I'm in the middle of converting it into a DocBook > article and will post a URL to it soon. Why ? We already have http://www.freebsd.org/projects/index.html. May be it's better to go with formalizing this page rather than adding new one ? ps: But I think it can be good idea to put sgml'ified copy of this report (and others) to web site, like we had Really Quick Newsletter for some time. Any takers ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: custom release
hi, JP> How much disk space is it necessary to have the entire CVS repository ? Litle more than 800 mb. JP> The idea is to build a custom release. You need 1,5-2 Gig. -- /* Alexey Zelkin && [EMAIL PROTECTED]*/ /* Tavric National University && [EMAIL PROTECTED] */ /* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Terminal colors
hi, AND> Say I want to change the man colors when I read mans at the console. More AND> precisely, I don't like that underlined text shows up as reversed (black AND> letter on while(grey,7) backround). How (and where) do I need to say that AND> I want, say, yellow on black instead of reversed when displaying AND> underlined-supposed-to-be text. Any help is greatly appreciated. For supported escape sequences (sequences used to change colors) you can read screen(4) manpage. Then read termcap(5) manpage. It will describe you termcap file structure. Pay espessial attention for `md' (bold mode on) and `so' (standout mode on) directives. Contact me directly if you need more comments. -- /* Alexey Zelkin && [EMAIL PROTECTED]*/ /* Tavric National University && [EMAIL PROTECTED] */ /* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: loader security problem
hi, On Sun, Nov 07, 1999 at 05:29:02PM +0900, Daniel C. Sobral wrote: > > IMHO, it would be nice to have password protected loader(8) (like linux lilo) > > or just ACLs for loader(8)'s "more" command (like unavailable for viewing > > files) > > cat >/boot/passwd.4th < Say... does LILO have a scripting language? One my friend is linux-fan. And I know about lilo by his speach :) I even did not try to look to lilo's sources and I can't answer such _complex_ question :) -- /* Alexey Zelkin && [EMAIL PROTECTED]*/ /* Tavric National University && [EMAIL PROTECTED] */ /* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
handbook require major update
hi, I just looked over 12th chapter of the handbook (PC Hardware compatibility) and found that we _must_ update and add/extend all sub-chapters there. This chapter is mostly based on information submited at 1995. It's very sad! :-( Please, take a look over this chapter and feel free to submit any new sub-chapters, sections, paragraphs or fixes to existent ones as simple text or SGML patches to -doc maillist. Thanks you very much! -- /* Alexey Zelkin && [EMAIL PROTECTED]*/ /* Tavric National University && [EMAIL PROTECTED] */ /* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rune questions
hi, I am working on additional documentation for locale part of the libc and have some questions. FreeBSD locale is based on rune-type files. By mklocle(1) descriptions all characters are dividing into few categories: . ALPHA - letters . CONTROL - control symbos . DIGIT - digits et cetera. But I don't see anywhere descirptions on PHONOGRAM and IDEOGRAM. Manpages shown that these categories were used by Japan locale only (again without any descriptions :-( ) Anybody can give me answer about that these categories means ? Or url/reference at least. -- /* Alexey Zelkin && [EMAIL PROTECTED]*/ /* Tavric National University && [EMAIL PROTECTED] */ /* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
hi,
>> Does anyone (anyone, that is, who's coded X11 applications) know how you
>> handle X11 callbacks to C++ object methods?
>>
>> Thanks,
TDR> If you mean Xt (and possibly Motif) - the answer is "very carefully."
TDR> The Xt callbacks are C based, so you typically can't directly call a
TDR> C++ method.
TDR> But, you can have an extern "C" block that declares the call back
TDR> function (the extern "C" basically keeps any name mangling from going on)
TDR> and then, in that function, invoke the method as appropriate.
TDR> I believe you do something like:
TDR> class myclass {
TDR> void mymethod(void * arg1) {
TDR> cout << "Ha! I got to the class" << '\n';
TDR> };
TDR> }
TDR> extern "C" {
TDR> void
TDR> callback_function(arg1)
TDR> void *arg1;
TDR> {
TDR> /* Call the method */
TDR> myclass::mymethod(arg1);
TDR> }
TDR> }
Looks good except one point -- mymethod should be static, i.e.
static void mymethod (...) {
...
}
TDR> Then, you register "callback_function" as the Xt/Motif callback.
TDR> I've at least "heard" of doing that kind of thing before...
--
/* Alexey Zelkin && [EMAIL PROTECTED]*/
/* Tavric National University && [EMAIL PROTECTED] */
/* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
