Re: c99 project
On 02/04/2013 08:48 PM, Eitan Adler wrote: Is the following page still useful? Would there be any objection to me removing it? http://www.freebsd.org/projects/c99/index.html We are still working on complex and long double functions. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Providing a default graphical environment on FreeBSD
On 09/17/12 11:14, Lorenzo Cogotti wrote: Il 17/09/2012 17:42, Poul-Henning Kamp ha scritto: In message blu0-smtp510b16745b704c714268e2d5...@phx.gbl, Lorenzo Cogotti writ es: Hi, I was wondering about the possibility of FreeBSD to provide an official supported graphical environment. We already do: It's called X11 :-) (sending back to mailing list due to a mistake replying personally, I apologize) That's surely more of a standard than Linux can provide, considering Wayland :-) I meant something more abstract that could provide a default desktop feel and the possibility of writing more complex GUI interfaces in less time, so that, for example, I could create a GUI tool while being consistent with the rest of the environment. Right now this can't be achieved (in an easy way) without taking into account Qt, GTK+, X and an enormous number of other toolkits available. In message blu0-smtp86e4bbd140d6911f5297b1d5...@phx.gbl, Lorenzo Cogotti writ es: Right now this can't be achieved (in an easy way) without taking into account Qt, GTK+, X and an enormous number of other toolkits available. Do what everybody else does: Pick the toolkit you prefer to work in and move on... This idea would precisely serve the purpose of removing this need and eliminate redundancy of toolkits, when it comes to essential utilities that FreeBSD would want to provide, like devices automounting, partitioning (taking advantage of the system features) and so on... but it's just an idea, of course. I think most FreeBSD developers don't care to do this. If you want this to happen, you should create your own product. Call it Cogotti-BSD-Grafix, or whatever you like. Then you take the code base of FreeBSD, and work very hard to create a stable graphics environment, package it, and put up your own website advocating it. If you pick software with the right licenses, you could even sell your product. Or if you don't want to do this, find someone else who will. For all I know, maybe someone has already done this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ways to promote FreeBSD?
Find some mailing lists that have nothing to do with FreeBSD, and barrage them with spam promoting FreeBSD. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle)
On 01/18/2012 06:57 PM, Dieter BSD wrote: Andriy writes: And dealing with PRs is not always exciting. Neither is brushing your teeth or cleaning the kitchen, but most of us manage to do them at least occasionally. Part of being a grown up. Instead of looking for a stick to hold over developers to get them to fix PRs, let's look for carrots to make fixing PRs more appealing. Idea 1: Fix 'n' PRs, get a tee-shirt, fridge magnet, plush daemon, ... Idea 2: Give it status. Set up a web page with PR fixing stats name/handle..total PRs fixed...fixed in last 12 months...average fixed/year Sheldon..150...9072 Leonard..131..11067 Howard...104...2052 Raj...80...8080 You should get extra points for difficult PR's. One way to measure this would be to give more points for fixing older PR's than newer PR's. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: package building failure irritation
I also build my ports in a jail environment (only its not a really a
jail, just a chroot).
After I have built the ports I want, I create the packages using the
following little script. (My mail client will have mangled the script,
so take care when you copy and paste it, e.g. it needs to be tabs not
spaces and the beginning of lines.)
#!/usr/bin/make -f
PACKAGES?=/usr/home/stephen/packages-8-amd
PKG_DBDIR?=/var/db/pkg
PORTSDIR?=/usr/ports
PKG_LIST!=ls ${PKG_DBDIR}
all:${PKG_LIST:C+(.*)+${PACKAGES}/All/\1.tbz+}
.for target in ${PKG_LIST}
${PACKAGES}/All/${target}.tbz: ${PKG_DBDIR}/${target}/+CONTENTS
@origin=${PORTSDIR}/`sed -n 's/@comment ORIGIN://p' \
${PKG_DBDIR}/${target}/+CONTENTS`; \
if [ $$origin != ${PORTSDIR}/ ] [ -e $$origin ] (! [ -e
$$origin/work ] || [ -e $$origin/work/.install_done* ]); then \
echo creating package ${target}; \
make -C $$origin PACKAGES=${PACKAGES} package-links; \
pkg_create -GjY -b ${target} $@ || (rm -f $@ false); \
fi
.endfor
.BEGIN:
@mkdir -p ${PACKAGES}/All
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checksum mismatch -- will transfer entire file
Victor Sudakov wrote: But to hell with this. I started the topic because I think something is wrong with SVN to CVS export, which upsets cvsup and causes Checksum mismatch errors. Is anybody willing to look at it? I second Victor's request. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checksum mismatch -- will transfer entire file
Doug Barton wrote: I was not going to reply on this thread at all, but the amount of random speculation has now reached a pathological level. The spurious new line at the end of a file has nothing to do with svn, it is an artifact of how the file was originally transferred to the cvsup mirror. The checksum mismatch will be triggered a few different ways, the most common is to switch between cvsup and csup, and/or switching mirrors for the same checked out tree. The message is harmless, it's not an error, and in fact you can take the message as a reassuring sign that the system is working exactly as designed. :) I tend to agree with Victor that there is something more going on. I started getting these messages at about the same time as svn was introduced. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Suggestion: rename killall to fkill, but wait five years to phase the new name in
I would like to introduce a program into the base called screw-the-whole-system. It would do something like this: while true; do \ echo Please wait while your system is being destroyed... sleep 10 done ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Alfred Perlstein wrote: * Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) I think that this kind of talk calls for boycotting certain device drivers! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009, Julian Elischer wrote: Stephen Montgomery-Smith wrote: Alfred Perlstein wrote: * Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) I think that this kind of talk calls for boycotting certain device drivers! In OpenBSD they have project sponsored healthware and sometimes you have to wait in a queue to get you notifications, and sometimes the queue is so long events have to get merged! Not for me! I want all my individual events to be lost After I get them. It's my right! Perhaps you are getting too much information through the cable network. Your system might be getting all wee weed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: the web site
RW wrote: On Sun, 29 Mar 2009 17:40:30 -0400 Chuck Robey chu...@telenix.org wrote: I just had to see if I could locate if there was a gnome project page by looking at the FreeBSD web pages. Why don't you try that yourself? I'll tell you, it's really FAR from being obvious. I'm just saying, even if folks don't want to change the web page, then a TOC-like section should be added near the bottom, to make navigation easier. If you click on site map, at the bottom of the page, the gnome link is on the first line. There is also the handy search feature which will tell you the following: Search Results The archive www contains the following items relevant to `gnome': Didn't get what you expected? Look here for searching hints. Return to the search page Nothing found. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: RFC: small syscons and kbd patch
Nate Eldredge wrote:
int bangbang(int x) { return !!x; }
int ternary(int x) { return x ? 1 : 0; }
Stylewise, I prefer
int notzero(int x) { return x!=0; }
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Calling malloc from a signal handler
I notice that if you use malloc from within a signal handler on FreeBSD-6.x, that you can potentially trigger a recursive call error. But this seems to have changed in FreeBSD-7.x. Is it now permissible to call malloc from within a signal handler in FreeBSD-7.x? If so, should the man page of sigaction(2) be upgraded to say this? Thanks, Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommend literature for beginner programer
Jingshao Chen wrote: Hi, Since you have been unix admin for a few years, I guess you probably have some experience with C programming. This book is more advanced, but it is a really good one. Advanced Programming in the UNIX Environment: Paperback Edition (2nd Edition) http://www.amazon.com/Advanced-Programming-UNIX-Environment-Addison-Wesley/dp/0321525949/ref=sr_1_1?ie=UTF8s=booksqid=1219855535sr=1-1 Thanks, Jingshao I have read some other books by (the late) Richard Stevens, and he writes really good books. Some of the info is slightly outdated or inapplicable for FreeBSD, but those finer points you can get from the man pages. But for getting a good overview, his writing style is so easy to follow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years
Lothar Braun wrote: What about having two utilities for the installation process? Something like a very small (non-gui/non-X) version of sysinstall that just installs a base system and only has the functionality to - partition/label a disk - configure the network (if needed for installation) - install the base system (or parts of it) - install a boot manager and a second utility sysconf that provides the other stuff like post installation system configuration (sshd, mouse), installing packages, etc. The second utility could have an X-based GUI without disturbing the installation process of serial console users or people that don't like X on their machines. Would that be a good idea? Why not leave sysconf as a curses based interface? To my mind, the difference between X-based and curses is cosmetic. (Plus one of sysconfs duties will be to install X, so it would be a bit self-referential.) Next, it seemed to me that the OP's main complaint was that he had to change the CD's about 40 times when installing packages. Why not just fix that? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
time used by a thread
I want to use getrusage to see how much time a program is using. But this is a multithreaded program, and I just want the time taken by that particular thread! I know this info must be available somewhere, because top -H seems to provide it. But getrusage seems to give the total rusage for the whole program, not just the thread. Any ideas? I would especially appreciate a portable solution that works for OS other than FreeBSD (e.g. linux, etc as well). I tried apropos thread | grep usage. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time used by a thread
Sergey Babkin wrote: I want to use getrusage to see how much time a program is using. But this is a multithreaded program, and I just want the time taken by that particular thread! I know this info must be available somewhere, because top -H seems to provide it. But getrusage seems to give the total rusage for the whole program, not just the thread. Any ideas? I would especially appreciate a portable solution that works for OS other than FreeBSD (e.g. linux, etc as well). On Linux and Solaris it can be done by reading the /proc filesystem. Probably on FreeBSD too, haven't tried. But it's different on each OS. Thanks. I developed a non-portable solution using kvm_getprocs. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
Rob Lytle wrote: Hi Kevin, The sysinstall dependency problem has existed for 10 years, so I doubt that its unique to me. It has occurred in every installation I have ever done. I use portupgrade for all ports. i strongly disagree with using ports for huge packages. I don't have the time to waste compiling. Plus, you are presented with numerous nag screens so you have to babysit the whole process. You can get rid of the nag screens by putting BATCH=yes into /etc/make.conf. (Not that this negates your other points.) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
Rob Lytle wrote: On Thu, Jul 3, 2008 at 9:33 PM, Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: Rob Lytle wrote: Hi Kevin, The sysinstall dependency problem has existed for 10 years, so I doubt that its unique to me. It has occurred in every installation I have ever done. I use portupgrade for all ports. i strongly disagree with using ports for huge packages. I don't have the time to waste compiling. Plus, you are presented with numerous nag screens so you have to babysit the whole process. You can get rid of the nag screens by putting BATCH=yes into /etc/make.conf. (Not that this negates your other points.) What the hell does yes mean? That all option boxes are checked, or none at all? I have never seen this explained anywhere. It means it acts as though you didn't change any of the check boxes at all. (So either the default, or if it was previously set in /var/db/ports, then what that is.) It is explained in man ports but not in great detail. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years
On the whole, I rather like the installation process for FreeBSD. Generally what I really like about FreeBSD is the ease of system administration, and whenever I use Linux distributions I get rather frustrated. If, as the OP suggests, installation of packages from the FreeBSD CD's requires switching around 40 times, then that is bad. But it should be something easily fixable, without greatly modifying the rest of the process. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Small change to top
top doesn't get TIME right for threaded processes. How about this small
change:
--- usr.bin/top/machine.c-orig 2008-06-12 23:06:08.0 -0500
+++ usr.bin/top/machine.c 2008-06-12 23:06:51.0 -0500
@@ -725,6 +725,7 @@
prev_pp = pp;
} else {
prev_pp-ki_pctcpu += pp-ki_pctcpu;
+ prev_pp-ki_runtime += pp-ki_runtime;
}
}
(Sorry if the mail client messes up the patch, but it is so short that
it can be easily entered by hand.)
I do realize that this is not foolproof, because it won't measure any
threads that have finished. But it is perhaps a bit better than the
current state of affairs, which randomly picks a runtime of one of the
threads.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvidia working?
Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wondering ... I have (I think) nvidia working on my box, or at least, I am calling out the nvidia driver in the xorg.conf, but I was wondering if there is any program that only works with the nvidia hardware, some way I can absolutely prove that I have the real nvidia card working here? Before I had it working, I was using the vesa driver, and most things look exactly the same, and if I could fine some program that shows the 8600GTS's abilities, I would sure like that. xlock -mode atunnel is a good work out. bzflag simply will grind to a halt without GL acceleration. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Before After Under The Giant Lock
On Sun, 25 Nov 2007, Robert Watson wrote: In FreeBSD 8, I expect we'll see a continued focus on both locking granularity and improving opportunities for kernel parallelism by better distributing workloads over CPU pools. This is important because the number of cores/chip is continuing to increase dramatically, so MP performance is going to be important to keep working on. That said, the results to date have been extremely promising, and I anticipate that we will continue to find ways to better exploit multiprocessor hardware, especially in the network stack. I just want to add my 2 cents, that my recent experience with FreeBSD MP has been extremely positive. I tend to use highly CPU bound MP programs, typically lots and lots of floating point operations. It used to be that Linux beat FreeBSD hands down - now FreeBSD seems to have a slight edge! Basically my program runs about twice as fast when I run two threads as opposed to one - I cannot see doing any better than that! (Also when I run 4 threads with 2 cpus, each with hyperthreading, it goes 2.5 to 3 times faster - surprising since hyperthreading gets quite bad press for its performance improvements - I should add that Linux didn't do at all well at taking advantage of hyperthreading, running at the same speed as with 2 threads.) Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Before After Under The Giant Lock
On Sun, 25 Nov 2007, Roman Divacky wrote: On Sun, Nov 25, 2007 at 02:41:35PM -0600, Stephen Montgomery-Smith wrote: On Sun, 25 Nov 2007, Robert Watson wrote: In FreeBSD 8, I expect we'll see a continued focus on both locking granularity and improving opportunities for kernel parallelism by better distributing workloads over CPU pools. This is important because the number of cores/chip is continuing to increase dramatically, so MP performance is going to be important to keep working on. That said, the results to date have been extremely promising, and I anticipate that we will continue to find ways to better exploit multiprocessor hardware, especially in the network stack. I just want to add my 2 cents, that my recent experience with FreeBSD MP has been extremely positive. I tend to use highly CPU bound MP programs, typically lots and lots of floating point operations. It used to be that Linux beat FreeBSD hands down - now FreeBSD seems to have a slight edge! Basically my program runs about twice as fast when I run two threads as opposed to one - I cannot see doing any better than that! pure computation does not need kernel operations most of the time.. ie. multi-threading kernel wont help much ;) Yes, I know. But something else was also done to FreeBSD, perhaps fine tuning with the scheduler, that did bring about massive improvements. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Before After Under The Giant Lock
On Sun, 25 Nov 2007, Kip Macy wrote: I just want to add my 2 cents, that my recent experience with FreeBSD MP has been extremely positive. I tend to use highly CPU bound MP programs, typically lots and lots of floating point operations. It used to be that Linux beat FreeBSD hands down - now FreeBSD seems to have a slight edge! Basically my program runs about twice as fast when I run two threads as opposed to one - I cannot see doing any better than that! pure computation does not need kernel operations most of the time.. ie. multi-threading kernel wont help much ;) Yes, I know. But something else was also done to FreeBSD, perhaps fine tuning with the scheduler, that did bring about massive improvements. I assume you're using ULE. Jeff has gone to great lengths to take cache affinity into account. This may be what you are benefiting from. No, I'm using 4BSD under FreeBSD 7.0. But I just tried it with ULE under FreeBSD 8.0 (Witnesses and invariants switched off), and the speed marginally slower, but only by 2% or so. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slight problem with make actual-package-depends with ports
Alexander Leidinger wrote: Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Tue, 17 Jul 2007 19:46:11 -0500): I appreciate that most people won't have this problem, but it has bitten me. After you have made and installed a port, but don't clean it, and then made a bunch of other ports, if you go back to the original port and then do make package, then +CONTENTS can be a bit messed up for the package. This is because the creation of other ports might disturb Can you please give an example what messed up means in this context, e.g. post a diff between a good an a bad contents file? And what actions you did to get this difference? I don't have an example to hand right now. _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. You mean that if you create a leaf package and then rebuild a package which is in the middle of the dependency tree with options which change the dependency graph of the leaf package you get problems? If yes: this has to be expected. You need to rebuild the packages in the right order. This happens to me because I make all my ports on one machine and then copy them as packages to other machines. Then on the other machines, the structure of /var/db/pkg gets a bit messed up and pkg_delete -r malfunctions. I have a lot of jails where I use the packages build in other jails. I haven't seen a problem there. The package install doesn't change the +CONTENTS files, so /var/db/pkg should be messed up on the build machine too... It seems to me that the cure is to slightly change make actual-package-depends so that if the port is already installed, it just uses +CONTENTS. This is wrong. What if you have a port installed and you want to rebuild the same version with other OPTIONS which changes the +CONTENTS file? If I read your patch right, it will use the wrong contents... You cannot install the port until you have first deinstalled it (unless you use some kind of FORCE option, and it is reasonable that this would mess things up). Thus at installation time, +CONTENTS will never exist. But I take your point if perhaps you do need to use some kind of FORCE option. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slight problem with make actual-package-depends with ports
Alexander Leidinger wrote: Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Tue, 17 Jul 2007 19:46:11 -0500): I appreciate that most people won't have this problem, but it has bitten me. After you have made and installed a port, but don't clean it, and then made a bunch of other ports, if you go back to the original port and then do make package, then +CONTENTS can be a bit messed up for the package. This is because the creation of other ports might disturb Can you please give an example what messed up means in this context, e.g. post a diff between a good an a bad contents file? And what actions you did to get this difference? _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. You mean that if you create a leaf package and then rebuild a package which is in the middle of the dependency tree with options which change the dependency graph of the leaf package you get problems? If yes: this has to be expected. You need to rebuild the packages in the right order. In other words, you have to perform the make package right after the make install before you install any other ports. Otherwise you have to use pkg_create -b (which I have recently started doing). This happens to me because I make all my ports on one machine and then copy them as packages to other machines. Then on the other machines, the structure of /var/db/pkg gets a bit messed up and pkg_delete -r malfunctions. I have a lot of jails where I use the packages build in other jails. I haven't seen a problem there. The package install doesn't change the +CONTENTS files, so /var/db/pkg should be messed up on the build machine too... It seems to me that the cure is to slightly change make actual-package-depends so that if the port is already installed, it just uses +CONTENTS. This is wrong. What if you have a port installed and you want to rebuild the same version with other OPTIONS which changes the +CONTENTS file? If I read your patch right, it will use the wrong contents... The other option (to allow the users to do make package much later than make install) would be to have two different actual-package-depends, one for make install, and the other for make package. However if this is perceived to be a non-problem by everyone else, I am going to withdraw my suggestion. I'll just leave a note here in case anyone else has this problem (as indeed it seems at least one other person did), that you must do the make package right after the make install. (I did file a PR - committers should close it if they feel it is not an issue. But I leave it with them.) Best regards, Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with +CONTENTS being messed up by pkg_delete -f
If you pkg_delete -f a package and then install the port again (but after it has been bumped up a version), then the +CONTENTS of ports that require the original port will be incorrect. This apparently messes up programs like portmanager. There is a sense in which one should never do pkg_delete -f and expect /var/db/pkg to keep its integrety - on the other hand this is exactly what make deinstall does. My feeling is that the integrety of /var/db/pkg should be maintained across a make deinstall and subsequent make install of a bumped version of the port. This is my suggestion. When a pkg_delete -f is executed, it looks through +REQUIRED_BY of the port it is going to delete, and modifies the +CONTENTS file of each of them, replacing lines like @pkgdep xineramaproto-1.1.2 @comment DEPORIGIN:x11/xineramaproto to maybe something like @comment DELDEPORIGIN:x11/xineramaproto (deleted dependency origin). A subsequent make install of x11/xineramaproto should look through the +CONTENTS of all entries in /var/db/pkg and change these lines to something like @pkgdep xineramaproto-1.1.3 @comment DEPORIGIN:x11/xineramaproto A further benefit of this approach is that one could also accurately reconstruct the +REQUIRED_BY of the port just reinstalled - right now this is left empty and thus inaccurate. What do you guys think? I know I could write the code for this quite quickly, but I want some feedback before I work on it. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with +CONTENTS being messed up by pkg_delete -f
Robert Noland wrote: On Wed, 2007-07-18 at 15:56 -0500, Stephen Montgomery-Smith wrote: If you pkg_delete -f a package and then install the port again (but after it has been bumped up a version), then the +CONTENTS of ports that require the original port will be incorrect. This apparently messes up programs like portmanager. There is a sense in which one should never do pkg_delete -f and expect /var/db/pkg to keep its integrety - on the other hand this is exactly what make deinstall does. My feeling is that the integrety of /var/db/pkg should be maintained across a make deinstall and subsequent make install of a bumped version of the port. This is my suggestion. When a pkg_delete -f is executed, it looks through +REQUIRED_BY of the port it is going to delete, and modifies the +CONTENTS file of each of them, replacing lines like @pkgdep xineramaproto-1.1.2 @comment DEPORIGIN:x11/xineramaproto to maybe something like @comment DELDEPORIGIN:x11/xineramaproto (deleted dependency origin). A subsequent make install of x11/xineramaproto should look through the +CONTENTS of all entries in /var/db/pkg and change these lines to something like @pkgdep xineramaproto-1.1.3 @comment DEPORIGIN:x11/xineramaproto Hrm, not quite what I had in mind... I don't want to misrepresent that a port was built against a newer version of a dependency. What I was hoping for would be that a port when reinstalled would not list both the current version of a dependency as well as a previous version of the same origin (which it aquired via the +CONTENTS of some other direct dependency). It should only list the currently installed version of that origin. That way it is still possible to determine that the interim port was built against an older version. I just want the +CONTENTS file to accurately list the versions that a given port was built against. I think I was not understanding your problem, nor how portmanager works. Sorry about that. In general, I do really like how the present actual-package-depends works, and so I would rather see this kept, and portmanager modified to accomodate, rather than the other way around. Robert sent me some private emails about how actual-package-depends was messing up portmanager. Probably he should send the problem descriptions to the mailing lists, and maybe someone else could solve them. I thought I had some ideas for quick fixes, but it seems I was looking before I was leaping. I don't really have enough time right now for long fixes, so someone else will have to figure it out. I have to say that I simply don't use portmanager or portsinstall or anything like that, so I don't know how they work. (Rather I use my own home brew tools for doing the same thing, and since they are home brew and only for my use, they don't need to get everything right everytime, they can be simple, and they don't have to be at all user-friendly.) Best regards, Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Slight problem with make actual-package-depends with ports
I appreciate that most people won't have this problem, but it has bitten me.
After you have made and installed a port, but don't clean it, and then
made a bunch of other ports, if you go back to the original port and
then do make package, then +CONTENTS can be a bit messed up for the
package. This is because the creation of other ports might disturb
_LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS.
This happens to me because I make all my ports on one machine and then
copy them as packages to other machines. Then on the other machines,
the structure of /var/db/pkg gets a bit messed up and pkg_delete -r
malfunctions.
It seems to me that the cure is to slightly change make
actual-package-depends so that if the port is already installed, it
just uses +CONTENTS.
I enclose a patch. Unless I get a bunch of negative comments, I'll
submit this as a PR as well.
Stephen
--- bsd.port.mk-old 2007-07-17 19:31:08.0 -0500
+++ bsd.port.mk 2007-07-17 19:29:16.0 -0500
@@ -5485,7 +5485,9 @@
done
ACTUAL-PACKAGE-DEPENDS?= \
- if [ ${_LIB_RUN_DEPENDS} !=]; then \
+ if [ -e ${PKG_DBDIR}/${PKGNAME}/+CONTENTS ]; then \
+ ${AWK} -F '( |:)' 'BEGIN { pkgname=broken_contents } /@pkgdep
/ { pkgname=$$2 } /@comment DEPORIGIN:/ { printf %s:%s\n, pkgname, $$3;
pkgname=broken_contents }' ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \
+ elif [ ${_LIB_RUN_DEPENDS} !=]; then \
origins=$$(for pkgname in ${PKG_DBDIR}/*; do \
if [ -e $$pkgname/+CONTENTS ]; then \
${ECHO_CMD} $${pkgname\#\#*/}; \
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
Jack L. wrote: On 6/24/07, Martin Turgeon [EMAIL PROTECTED] wrote: Hi, I recently installed AMD64 6.2 Release on 2 PowerEdge servers, both with dual core Xeon (3070 and 5110). I noticed when I was updating the sources that it was compiling as an Athlonxp by default. I was wondering if I should change the CPUTYPE in make.conf to something else. I read at some places that it is not recommended because it could cause problems but I thought it would be interesting to start the debate here. Please note that I would prefer not to go with the -STABLE or -CURRENT branch because these a going to be essential productions servers. Thank you for your opinions, Martin I use nocona. That should be the correct one. I know I am hijacking the thread a bit - but: In general, how does one decide which CPUTYPE to use? The connection between the options for CPUTYPE and the output of dmesg is not so obvious to me. I looked at the features advertised by dmesg (which in my case included SSE3) and then reverse engineered bsd.cpu.mk to figure out I should be using prescott, but I am hoping I figured it out the hard way. Also, does setting CPUTYPE make a lot of difference to performance? Right now I have no CPUTYPE set at all. Thanks, Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using shell commands versus C equivalents
On Wed, 13 Jun 2007, [EMAIL PROTECTED] wrote: PS I'm looking at pkg_install and pkg_version mostly, but I'll be looking into the other package utilities closely in the next couple weeks, evaluating what approaches I should take in solving some bottlenecks with installing packages and ports. My goals are up on http://wiki.freebsd.org/GarrettCooper, and will be modified soon. Since you are interested in speeding up the pkg_* stuff, I thought I would bring these to your attention (speed ups to the pkg_create and port registration processes, not quite what you are doing, but related). http://www.freebsd.org/cgi/query-pr.cgi?pr=112765 http://www.freebsd.org/cgi/query-pr.cgi?pr=112630 Let me also wish you good luck in your speed improvements. I was rather encouraged by these two, but all my future searches proved somewhat negative. In particular I looked rather hard at trying to speed up make (required for pkg_version when it calls make -V PKGNAME multiple times). I can tell you that in that instance, replacing linear lists by berkeley DB made no difference at all - it was very disappointing. In short, you really want to do a lot of profiling and see where the speed bottlenecks really are before writing lots of code. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
On Wed, 30 May 2007, Bakul Shah wrote: Peter Jeremy [EMAIL PROTECTED] wrote: On 2007-May-27 16:12:54 -0700, Bakul Shah [EMAIL PROTECTED] wrote: Given the size and complexity of the port system I have long felt that rather than do everything via more and more complex Mk/*.mk what is is needed is a ports server and a thin CLI frontend to it. I don't believe this is practical. Both package names and port dependencies depend on the options that are selected as well as what other ports are already installed. A centralised ports server is not going to have access to this information. I didn't mean a centralized server at freebsd.org but on your freebsd system and can know about what ports are installed. Conditional dependencies have to be dealt with. Perhaps the underlying reason for changing package names can be handled in a different way. What happens now is that mostly static information from various files is recomputed many times. While that can be handled by a local database, it seems to be a daemon provides a lot of benefits. Come to think of it, even a centralized server can work as there are a finite number of combinations and it can cache the ones in use. But all this is just an educated guess. Your idea really looks very fine to me. From reading other emails on this thread, I get the impression that a lot of the underlying work has already been done in perhaps the portupgrade port, and so all you would have to do is to provide an interface from the make file to the database produced by portupgrade. Perhaps this could be made conditional, so that those who don't install portupgrade wouldn't use it. Even so, I also get the feeling that to implement this would be quite some work, so a volunteer needs to step forward. But my gut reaction is that this is almost certain to make things like make clean and pkg_version way way faster. And I must admit that I am having more doubts about my calculate the variables just in time idea. The thought of working really hard to make it work, and then seeing mediocre speed increases is rather offputting to me. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Hartmut Brandt wrote: Having done a great deal of rewriting of make some two years ago I can tell you that even a small change to make is a tough job testing-wise: run all the combinations of !-j and -j N on all architectures and run the change through the port-building cluster. That's a warning to start with. Second I would start with careful profiling to find out where the problem actually is. You might be surprised. As an example: several times the idea came up to use a hash structure instead of linear lists for make variables. I got a patch for this and - it makes absolutely no difference performance-wise (well, there was some indication that performance gets worse, but that was around or below noise level). With careful I mean to find out who takes the time: Yes, I must admit that I thought that a hash structure for the variables would greatly increase the speed of make. I rewrote it using Berkeley databases, and like you said - absolutely no difference!! I even tried btrees. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Ivan Voras wrote: Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. As long as far-out ideas are being discussed, how about caching such information (including dependenices) in a file (I'd call it a database but then I'd had to start a holy war :) ) so it's calculated only once, preferably on the portsnap / cvsup servers and not at the end-user? Because the information is not a constant. For example, the mpg123 port changes its PKGNAME as soon as esound is installed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Jeremy Chadwick wrote: On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I have a related question, pertaining to make all-depends-list and the utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in bsd.ports.mk. I posted this to [EMAIL PROTECTED], but now I am realizing that it is [EMAIL PROTECTED] that gets more responses. Anyway, here is a multithreaded program all-depends-list that can get you double the speed on dual processor systems, and even some small speed gains on single processor systems. E.g. all-depends-list /usr/ports/x11/xorg http://www.math.missouri.edu/~stephen/all-depends-list.c ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
On Mon, 28 May 2007, David Naylor wrote: On Monday 28 May 2007 03:43, you wrote: Maybe I should look at the inner workings of cmake and gmake. Maybe they have some good ideas. However having looked through the source code of make, and also looking at the cvs logs, it does seem to be well written. The only possibility I see of making it go a lot faster is a complete redesign, e.g. my just in time idea for processing variables. Stephen Just in time (jit), if I remember correctly, is a term used by java interpreters which compile the byte code into machine code!!! Perhaps this could be developed for makefile's, especially bsd.*.mk. This, I think, could be done in two ways: 1) Develop the bsd.*.mk files in C and link it in with make, or 2) Use the makefiles as source to compile into machine code (passibly via C-ASM). The machine code could be created on demand, or cached and only updated if the source makefile changes. I am not sure if this could work or even if it will have any significant speed increase. However if method 2 does work it has the potential to radically increase the speed of ports _while_ maintaining the flexability. All that will be needed is an API for the machine code and a compiler??? My gut reaction is the same as yours - I doubt that this would bring any speed increases. And the programming effort would be huge. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Roman Divacky wrote: On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote: Jeremy Chadwick wrote: On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I have a related question, pertaining to make all-depends-list and the utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in bsd.ports.mk. I posted this to [EMAIL PROTECTED], but now I am realizing that it is [EMAIL PROTECTED] that gets more responses. Anyway, here is a multithreaded program all-depends-list that can get you double the speed on dual processor systems, and even some small speed gains on single processor systems. E.g. all-depends-list /usr/ports/x11/xorg http://www.math.missouri.edu/~stephen/all-depends-list.c btw.. stehpen, when are you getting a commit bit? :) I certainly hope that soon enough ;) Probably not. The program seems to have a bug in it. In particular, I didn't read the fgetln man page sufficiently well. So think of it as a proof of concept rather than a finished product. I'm going to rest from this stuff for a while, but I enjoyed the exchanges and it has given me encouragement to work on it again in the future sometime. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Looking for speed increases in make index and pkg_version for ports
I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I suggest rewriting make so that variables are only evaluated on a need to know basis. So, for example, if all we need to know is PKGNAME, there is no need to evaluate, for example, _RUN_LIB_DEPENDS, unless the writer of that particular port has done something like having PORTNAME depend on the value of _RUN_LIB_DEPENDS. So make should analyze all the code it is given, and only figure it out if it is needed to do so. This would include, for example, figuring out .for and .if directives on a need to know basis as well. I have only poked around a little inside the source for make, but I have a sense that this would be a major undertaking. I certainly have not thought through what it entails in more than a cursory manner. However I am quite excited about the possibility of doing this, albeit I may well put off the whole thing for a year or two or even forever depending upon other priorities in my life. However, in the mean time I want to throw this idea out there to get some feedback, either of the form of this won't work, or of the form I will do it, or I have tried to do this. Best regards, Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index
On Mon, 28 May 2007, Michel Talon wrote: Stephen Montgomery-Smith said: I suggest rewriting make so that variables are only evaluated on a need to know basis. or I have tried to do this. Of course a lot of people have thinked about it, and quickly realized that it was not going to work. In the bsd.ports.mk, evaluation of one variable may be dependent on some conditional, which may itself be dependant on some other variable, appearing as some target. This constantly happens in bsd.ports.mk. If you think about that, you convince yourself that a reduced make needs to understand targets, needs to understand conditionals, and needs to evaluate not only the variable under consideration, but but possibly any other. In other words, you need a full blown make. Actually I have thought quite a lot about this over the last couple of weeks. You are correct in that the make really does have to be a full blown make. What I am suggesting is something rather different - a rather sophisticated make that works hard to only that which it really has to do. And it certainly would require a lot of sophistication, precisely for the reasons you state. To gain some performance, a first idea would be to simplify bsd.ports.mk. I am convinced that a substantial part of the 4000 lines are historical crap which serve no useful purpose. There are tons of variables who have probably purely anecdotical interest. There are targets which could be happily suppressed. Of course, due to the complexity of bsd.ports.mk, rewriting it is certainly not an easy task. There is a freebsd port whose aim is to rewrite it, i don't know how far they are. The NetBSD people have completely rewritten the system, i have no idea if the new one is faster. The OpenBSD people have also rewritten bsd.ports.mk, with apparently much faster makefile. I rewrote a bsd.ports.mk in which ALL targets were removed, and all it did was evalute variables. (I wrote a perl script that did this automatically.) The net effect was no speed gain. In other words, processing unnecessary targets is not the problem. I really have looked at bsd.ports.mk a lot, and given that it is written in the context of what make requires, it seems to be rather well and efficiently written. I did find one speed increase in bsd.gnome.mk, which I am kind of proud of, but even that only gained about a 5-10% speed increase in make index. A second idea would be to multithread make, since modern machines will have a lot of cores. At present make -j something forks submakes and waits for their completion. This doesn't help for the problem at hand. However, multithreading the execution of a single makefile is certainly not trivial due to the interdependencies. I don't think multithreaded make will help in this situation. Anyways, one of the things which cannot be a big factor is reading bsd.ports.mk from hard disk. It is certainly cached in memory when you run make index. On the other hand it is so big that it probably doesn't fit in cache, or probably only fits in caches of machines generously endowed. I have remarked that the difference of execution speed of make index between machines of similar speed but very different cache size (i am thinking Pentium 4 versus Core 2 Duo) is striking. It is less than 10 minutes on the big cache machine versus 30 minutes on the small cache one. If the cache effect is indeed dominant, then reducing the size of bsd.ports.mk by all possible means would be very beneficial. My suspicion is that the timne taken to read bsd.ports.mk from the hard disk is a rather small part of what takes it so long. Compare doing a make with a simple cat and the time differences are very great. I think make spends far more time processing the file than reading it. By the way an alternative system would be to use something other than make to do the job. This is what the Gentoo people are doing, using first a python based system, and now a C++ one (paludis). Here also i don't have any idea if it is faster. It would be nice to find a solution that doesn't involve redesigning the whole ports process from scratch. -- Michel TALON ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for make
index and pkg_version and things like that. So for example, in
pkg_version, it calls make -V PKGNAME for every installed package. Now
make -V PKGNAME should be a speedy operation, but the make has to load in
and analyze bsd.port.mk, a quite complicated file with about 200,000
characters in it, when all it is needing to do is to figure out the value of
the variable PKGNAME.
I have a related question, pertaining to make all-depends-list and the
utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't
know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in
bsd.ports.mk.
I call it an atrocity because it's a mix of make variable expansion
combined with sh scripting, and it's nearly impossible to read. It's
not commented either, so folks like myself are left thinking What IS
this mess?!. It's expanded via $$(${ALL-DEPENDS-LIST}) in for loops,
throughout several places in bsd.port.mk.
I do not entirely understand what ALL-DEPENDS-LIST is about (that should
be apparent), but upon performing some of my benchmarks, I found this to
be a very slow piece of bsd.port.mk. make -V _DEPEND_DIRS is incredibly
fast, but ALL-DEPENDS-LIST is not.
Does it need to be done this way? Can we just iterate through all of
the ports, call make -V _DEPEND_DIRS, then sort | uniq the results? I
suppose that depends on the operation (make vs. make clean vs.
others)...
The port I used for testing some of the benchmarks was net/gacxtool. It
seems to be a good example of a hefty port.
I looked very hard at this particular piece of code. Once you
understand how it works, you realize that it is rather well written. It
basically does what you suggest, except it keeps a list of ports it has
already checked, so that it doesn't do them over again. This piece of
code is as efficient as it can possibly be, given that the program has
to recursively call make on every dependency port at least once (and as
it happens only once).
I suggest rewriting make so that variables are only evaluated on a need
to know basis. So, for example, if all we need to know is PKGNAME, there
is no need to evaluate, for example, _RUN_LIB_DEPENDS, unless the writer of
that particular port has done something like having PORTNAME depend on the
value of _RUN_LIB_DEPENDS. So make should analyze all the code it is
given, and only figure it out if it is needed to do so. This would include,
for example, figuring out .for and .if directives on a need to know basis as
well.
This sounds like a good solution. In fact, I'm lead to believe that
heavy reliance on /bin/sh is part of why the ports collection is slow.
No, it's not the sole reason, but it's one of many. I'm of the belief
that anything we can do to migrate portions into native make would be
benefitial.
I have done profiling tests on make, and in its current form,
bsd.ports.mk actually spends rather little time inside of bin/sh. Thw
writers of bsd.ports.mk have done a very good job of minimizing the
bin/sh calls.
That said, I'll ask this out in the open: am I the only one who sees the
benefit of GNU make in regards to this? There's a lot of built-in
functions in GNU make which could help in regards to ports. I have no
qualms with PMake per se, but if another tool gives us what we need,
then maybe we should consider the pros and cons of adapting that.
There's also CMake, which is incredibly fast.
Maybe I should look at the inner workings of cmake and gmake. Maybe
they have some good ideas. However having looked through the source
code of make, and also looking at the cvs logs, it does seem to be well
written. The only possibility I see of making it go a lot faster is a
complete redesign, e.g. my just in time idea for processing variables.
Stephen
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
I'm looking for something that will work with the existing framework. But yes, I get the feeling that maybe using make to process the ports might be the source of the problem. Make is a program primarily designed for figuring out which was made first, the target or the source, but in the ports what we really want is a scripting language that presides over cd WKSRC; make. (P.S. sorry for top-posting, but I am following your lead.) Bakul Shah wrote: Not quite what you asked for but... Given the size and complexity of the port system I have long felt that rather than do everything via more and more complex Mk/*.mk what is is needed is a ports server and a thin CLI frontend to it. This server can store dependency data in an efficient manner, deal with conditional dependencies, port renames, security and what not. It can build or fetch or serve packages, handle updates etc. Things mentioned in UPDATING file can instead be done by the server. In general it can automate a lot of stuff, remove error prone redundancies etc. If it is small enough and written in C, it can even be shipped with the base system instead of various pkg_* programs. It can provide two interfaces, one for normal users (with commands like add, check, config, delete, info, search, update, which) and one for port developers (command for adding/remove/renaming ports, etc.). Initially it must work with existing Makefiles. I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I suggest rewriting make so that variables are only evaluated on a need to know basis. So, for example, if all we need to know is PKGNAME, there is no need to evaluate, for example, _RUN_LIB_DEPENDS, unless the writer of that particular port has done something like having PORTNAME depend on the value of _RUN_LIB_DEPENDS. So make should analyze all the code it is given, and only figure it out if it is needed to do so. This would include, for example, figuring out .for and .if directives on a need to know basis as well. I have only poked around a little inside the source for make, but I have a sense that this would be a major undertaking. I certainly have not thought through what it entails in more than a cursory manner. However I am quite excited about the possibility of doing this, albeit I may well put off the whole thing for a year or two or even forever depending upon other priorities in my life. However, in the mean time I want to throw this idea out there to get some feedback, either of the form of this won't work, or of the form I will do it, or I have tried to do this. Best regards, Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sin()/cos()/tan() for kernel code? '_ 'a
On Sun, 11 Feb 2007, Daniel Eischen wrote: On Sun, 11 Feb 2007, Eugene M. Kim wrote: Hello all, I am writing a mouse device driver for my Wacom tablet (Intuos 2 9x12). The tablet comes with a mouse and I managed to get valid coordinate data from the device. However, unlike usual mice, the coordinate system is tied not to the orientation of the mouse itself, but to the tablet, which acts much like a mouse pad. So, for example, if I rotate the mouse 30 degrees to the left and move it left and right, the mouse cursor would move not horizontally, but to 2- or 8-o'clock. Fortunately the mouse also provides orientation data along with coordinate data, so the correct cursor movement could be calculated from it. The problem: The calculation needs trigonometry, but there seems to be no math library support in the kernel (I ran grep -w cos on the -CURRENT source tree, which turned nothing up). Does anyone have an idea on how to do this? Can't you do this in userland? Teach moused? Since you will only need sin and cos evaluated to the nearest degree, if that, I suggest a simple look up table. There is also something called the CORDIC method, I think, but I suspect that the look up table will be so much easier to program, and negligable extra space overhead. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sin()/cos()/tan() for kernel code? '_ 'a
On Sun, 11 Feb 2007, Stephen Montgomery-Smith wrote: On Sun, 11 Feb 2007, Daniel Eischen wrote: On Sun, 11 Feb 2007, Eugene M. Kim wrote: Hello all, I am writing a mouse device driver for my Wacom tablet (Intuos 2 9x12). The tablet comes with a mouse and I managed to get valid coordinate data from the device. However, unlike usual mice, the coordinate system is tied not to the orientation of the mouse itself, but to the tablet, which acts much like a mouse pad. So, for example, if I rotate the mouse 30 degrees to the left and move it left and right, the mouse cursor would move not horizontally, but to 2- or 8-o'clock. Fortunately the mouse also provides orientation data along with coordinate data, so the correct cursor movement could be calculated from it. The problem: The calculation needs trigonometry, but there seems to be no math library support in the kernel (I ran grep -w cos on the -CURRENT source tree, which turned nothing up). Does anyone have an idea on how to do this? Can't you do this in userland? Teach moused? Since you will only need sin and cos evaluated to the nearest degree, if that, I suggest a simple look up table. There is also something called the CORDIC method, I think, but I suspect that the look up table will be so much easier to program, and negligable extra space overhead. Stephen And if you do need more accuracy than the nearest degree, the formulae sin(x+h) = sin(x) + h cos(x); cos(x+h) = cos(x) - h sin(x) for small h (say |h| less than half a degree) should provide way more accuracy than you should need. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
Dan Nelson wrote: In the last episode (Jan 30), [EMAIL PROTECTED] said: An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). Are you sure? In 6.2 at least, s0 in interactive mode results in a 1-second delay, and top -s0 prints top: warning: seconds delay should be positive -- using default You can run top -s0 as root (not that this negates your point in any way). Incidently, this is an excellent way to generate those calcru going backwards errors, at least in some recent versions of FreeBSD. Just run a highly threaded, CPU intensive job at the same time. I did this on SMP systems, so I don't know if it also does this on non-SMP systems. On versions of FreeBSD 5.x I was able to induce kernel panics, the likes of which produced useless core dumps, but this seems to have been fixed with more recent versions. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reading in real time from a file without pipes
Matthew Hudson wrote: Mon Dec 11 09:08:37 PST 2006 c0re dumped wrote: I wonder if is possible to read data from a certain file without using a pipe. Let me explain: I have a process already writing messages to a logfile. I want to read all written data (without neither stop nor interfere normal log process) from another process in real time. How can I achieve it ? When on the command line, I do this using the program 'socat' (net/socat in ports). I.e. socat FILE:/var/log/messages,ignoreeof - This gives me the same sort of behavior as 'tail -f' except that it reads the entire file in first. I also use this when I'm say scp'ing over a really large tarball of text files and want to start looking at the files as they're coming in: * bigdir.tgz is a big tarball being scp'd over, 3 hours remaining * socat FILE:bigdir.tgz,ignoreeof - | gzip -dc | tar xf - and just like that I now have bigdir.tgz being expanded in realtime without having to do anything that may have interfered with the scp (such as using ssh to run 'tee' on the remote host and do it that way. Wouldn't tail -f +1 do the same thing? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syncing cpus on a multi-cpu, dual core system
M. Warner Losh wrote: In message: [EMAIL PROTECTED] M. L. Dodson [EMAIL PROTECTED] writes: : On a computational chemistry list I subscribe to there is a : current thread about multi-cpu systems needing to have the cpu : frequencies synced (this is in a Linux context). This is : evidently not just having the cpus running at nominally the same : frequency but something else in addition. A posting in the thread : said variations less than 0.1% were not problematic. However, the : poster said it was an issue in a dual cpu, dual core system he had : set up. : : My questions are: : 1. Is this real or an urban legend? : 2. If real, is this a Linuxism or is FreeBSD affected as well? : 3. How do you sync the cpus, if it is needed? : 4. anything else some one wants to expound on along this line. Linux keeps the cpu's frequencies 'synchronized' so that it can use the fast time keeping hardware (TSC). FreeBSD uses different mechanisms for its timekeeping, so doesn't need to keep them in sync at all, and doesn't even try at this point. Maybe this is what they are talking about... Warner One thing I have noticed with FreeBSD is that if I am running a program that multithreads and creates and destroys threads a lot (e.g. the fftw3 port), then top underreports significantly - that is on a 4 processor system it might report 60% (or even 0%) cpu usage, when it is clear from the TIME field that it is closer to 250% cpu usage. The other thing I have noticed is that when I split jobs using threads so that I can use several processors, the speed up to the program is far less than one might expect - indeed sometimes it even gets slower. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI Express graphics reliability/functionality in 6.1?
Clifton Royston wrote: I'm soon to build myself a new AMD X2 workstation system on which I plan to multiboot various operating systems including FreeBSD, a couple Linux distros and probably Windows XP Pro, and probably also run virtualization software (VMWare and/or Xen.) I'm hoping for it to last me through a few years of occasional upgrades, which makes me dubious about choosing an AGP motherboard. I can't find anything specific about PCI Express in the 6.1 release notes. However, I have Googled up some reports of various PCI-E graphic cards working badly in Xorg under FreeBSD and other open source OSes. In general should PCI Express graphics cards work properly and perform reasonably well for Xorg and OpenGL graphics under FreeBSD, if I avoid the touchier nVidia cards, or do I need to stick with AGP for reliability? I have a PCI-E nvidia card 6600 with a particular Intel board (whose numbers I don't remember right now) which used to be problematic, and generated quite a few messages on the internet to that effect. But it turned out to be a problem with the BIOS on the motherboard which was fixed when Intel came out with a BIOS upgrade. So what I am saying is that the problem might be motherboard specific rather than graphics card specific. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Files in C.
Pablo Mora wrote: what do they think of the book: Advanced Programming In The Unix Environment (Richard Stevens) ?? is a good option to learn C on Unix ? I really liked his Unix Network Programming Vol 1, but this book and his Vol 2 are also very good, so I would suggest getting all three. I might have hesitation over Vol 2, but only because it covers stuff that you might not need. He writes extremely well. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HTT/SMP Dual Xeon systems unstable
John Baldwin wrote: There is a problem in the kernel that causes with 3 or more processors (including logical CPUs from HTT). Disabling HTT in the BIOS is probably your best bet as it will get you down to 2 CPUs which should work much better. HTT also isn't but so useful anyways for most workloads. The instability problems have just been fixed in HEAD and will hopefully be MFC'd for 5.4 btw. It looks like I have lucked out so far, because I have this set up with no problems so far. I hope this fix gets to 5.x-stable soon because for my particular workloads HTT helps a lot. Stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UInaqble to install OpenOffice 1.1.3 from porte, 5.3R
Simon Burke wrote: Whener i try to install openoffice 1.1 from ports after several hours of compiling etc, i get the following error message. Is openoffice 1.1 port broken? or is it me? Im running 5.3R and i've cvsuped ports to get gnome 2.8 running which went fine. Any ideas? I once had problems like that. I found that the solution was to build jdk14 before building apache-ant and openoffice - jdk14 seemed to work better than linux-jdk14. But this was a while back, and so your problem might be something else. But worth a try. Stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: List of fake vs. real SATA drives.
FUJISHIMA Satsuki wrote: Currently native SATA drives are still not so popular. There are: Seagate Barracuda ATA V, 7200.7, 7200.8 I have one of these, and I am really impressed by its performance. I added one to my computer, which came with a Maxtor 6Y080L0. My main disk intensive operation is creating the CTM deltas (as in CTM which is an alternative to CVSUP for people behind unfriendly firewalls). The performance difference was somewhat collosal, as in something like 3 times faster. To be honest, I am still at a loss to explain why the Seagate did so very much better - maybe it is the 8M cache as compared to the 2M cache. The Seagate 7200.7 had similar performance to a Seagate 160MHz SCSI drive that I have on another computer. Stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: List of fake vs. real SATA drives.
Thomas Wolf wrote: Stephen Montgomery-Smith [EMAIL PROTECTED] schrieb: FUJISHIMA Satsuki wrote: Currently native SATA drives are still not so popular. There are: Seagate Barracuda ATA V, 7200.7, 7200.8 I have one of these, and I am really impressed by its performance. I added one to my computer, which came with a Maxtor 6Y080L0. My main disk intensive operation is creating the CTM deltas (as in CTM which is an alternative to CVSUP for people behind unfriendly firewalls). The performance difference was somewhat collosal, as in something like 3 times faster. To be honest, I am still at a loss to explain why the Seagate did so very much better - maybe it is the 8M cache as compared to the 2M cache. The Seagate 7200.7 had similar performance to a Seagate 160MHz SCSI drive that I have on another computer. Ah, please tell me more about it, is this a ST3120827AS? (I would need the exact PartNo.) What controller dou you have and finally, on which version of FreeBSD? ST380013AS with Intel ICH5 SATA150 controller and FreeBSD 4.10-Stable. The kernel reports that it is running at UDMA33, but the actual performance seems much better than that. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port bonding on nc3122 ( dual fxp ) NIC
Steven Hartland wrote: Does anyone know if this is possible. I've done some googling around and cant find anything. Using 5.1-RELEASE is just detecting them as fxp0 and fxp1 Assuming that I understand what you are asking, I believe that in FreeBSD they call it netgraph - man ng_one2many should give you the info you need. I had a friend who tried it out, and it seems to be completely compatible with the port bonding that Linux provides. (He also felt that the documentation for FreeBSD netgraph was better than the documentation that came with Linux port bonding, in particular the FreeBSD docs were better at explaining how it worked.) -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raw socket programming
Alin-Adrian Anton wrote:
Well, I don't wanna be idiot, perhaps I am too tired, but n_long appears
in ip.h defined as :
beast# grep ipt_time /usr/include/netinet/ip.h
union ipt_timestamp {
n_long ipt_time[1];
n_long ipt_time;
} ipt_timestamp;
beast# grep ipt_time /usr/include/netinet/*
/usr/include/netinet/ip.h: union ipt_timestamp {
/usr/include/netinet/ip.h: n_long ipt_time[1];
/usr/include/netinet/ip.h: n_long ipt_time;
/usr/include/netinet/ip.h: } ipt_timestamp;
beast#
And, I simply don't find where ipt_time is defined ! I suppose it is
structure, perhaps it is of type ipt_timestamp, *g*.
And yes, those are all the files I include, nothing more, nothing less.
Alin.
I did
grep -R ipt_time /usr/include
and got exactly the same output as you have above. It looks like ipt_time is
not defined anywhere. It looks to me like netinet/ip.h is broken.
What is it that you need netinet/ip.h for? Maybe there are some other include
files that would work just as well.
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raw socket programming
I did grep -R ipt_time /usr/include and got exactly the same output as you have above. It looks like ipt_time is not defined anywhere. It looks to me like netinet/ip.h is broken. What is it that you need netinet/ip.h for? Maybe there are some other include files that would work just as well. Sorry - it is I who is the complete idiot. Please totalyl ignore my last post. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqueue alternative?
Select doesn't work with files. Really? `man 2 select' says nothing about that. It just talks about 'file descriptors'. Now if it said 'socket descriptors' or 'non-file file descriptors' I would understand, but I don't think that that statement is implied by the man page. Is there something I'm missing? Well I did a little experimentation. It looks like this. select will say that a file is ready for reading if read(2) will not block. However, if you get to an end of file, then read does not block, rather it returns 0 to indicate end of file. Thus select will not block and will say that this file is ready for reading. In essence, calling select will always say that a file is ready for reading, and calling select serves no purpose. Well I definitely learned something. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqueue alternative?
Joshua Oreman wrote: On Sun, 15 Jun 2003, Matthew Hagerty wrote: I'm writing a little application that needs to watch a file that another process is writing to, think 'tail -F'. kqueue and kevent are going to do it for me on *BSD, but I'm also trying to support *cough* linux and other UN*X types OSes. From what I can find on google, the linux community seems very opposed to kqueue and has not yet implemented it (they say: blah blah blah, aio_*, blah blah balh.) What alternatives do I have with OSes that don't support kqueue? I'd really hate to poll with stat(), but do I have any other choices? I would say, use select(2). Is there a reason this wouldn't work? -- Josh Either select(2) or poll(2) should work. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
Thorsten Futrega wrote: The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. - Remove GNU tar. I really don't see a need for any version of tar to be in the base system. I mean, where does it actually get used (other than things like installation, which don't really matter). - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. Shouldn't we also drop support for the earlier pentium systems as well? I think that we can safely assume that everyone is running a pentium 4 or better. - Remove ext2 support (GPL encumbered). Remove ffs support also (BSD license encumbered). - Add perl 5.8 *and* python 2.2 to base. I agree - perl makes a perfect replacement for tar. - Remove Sendmail and replace it with Postfix. I prefer USPS. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: i-Buddie 4: Synaptics touch pad FreeBSD support?]
If you want to get tpconfig to work (so that you can customise various features of the touchpad), I have a PR that will allow you to do this. It is a combination of a hack to the kernel, and a port of tpconfig. Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=24299 http://www.freebsd.org/cgi/query-pr.cgi?pr=20352 -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
runtime
How do I do the following: 1) Find out how much time a program has currently consumed in computer time (something like what the time command outputs - but I want the program to do find this out about itself); 2) Have a thread wait for a specified amount of computer time (not actual time so nanosleep won't work). I looked at the man pages, but all I could find was runtime which seems only to be accessible from the kernel. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: runtime
It looks like exactly what I want. Thanks. Sergey Lyubka wrote: Would getrusage() help ? On Fri, Aug 16, 2002 at 10:21:07AM -0500, Stephen Montgomery-Smith wrote: How do I do the following: 1) Find out how much time a program has currently consumed in computer time (something like what the time command outputs - but I want the program to do find this out about itself); 2) Have a thread wait for a specified amount of computer time (not actual time so nanosleep won't work). I looked at the man pages, but all I could find was runtime which seems only to be accessible from the kernel. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Uptime of a system
Daniel Jonsson wrote:
Just like to share my experience with FreeBSD 4.x as a server:
4:17PM up 378 days, 5:41, 8 users, load averages: 0.00, 0.00, 0.00
This was as of today. The machine was installed 378 days ago and is
a rather active box normally.
I made a simple patch to my system that is giving me phenomenally high
uptimes:
hub# uptime
8:09PM up 5790 days, 1:24, 1 user, load averages: 0.00, 0.00, 0.00
--- usr.bin/w/w.c-orig Tue Jul 9 20:04:56 2002
+++ usr.bin/w/w.c Tue Jul 9 20:08:05 2002
@@ -456,6 +456,7 @@
if (sysctl(mib, 2, boottime, size, NULL, 0) != -1
boottime.tv_sec != 0) {
uptime = now - boottime.tv_sec;
+ uptime += 5;
if (uptime 60)
uptime += 30;
days = uptime / 86400;
(Sorry, couldn't resist it.)
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
setrlimit and large maxssiz
I am not sure which is the right mailing list, so sorry about the
cross-posting:
I want to use a lot of memory in my program, so I set the following in
/boot/loader.conf:
kern.maxdsiz=2147483648
kern.maxssiz=2147483648
kern.dfldsiz=2147483648
Then I run this simple program:
#include sys/types.h
#include sys/time.h
#include sys/resource.h
#include stdio.h
int main() {
struct rlimit rlp;
getrlimit(RLIMIT_STACK,rlp);
fprintf(stderr,%lld %lld\n,rlp.rlim_cur,rlp.rlim_max);
rlp.rlim_cur = 512*1024*1024;
fprintf(stderr,%lld %lld\n,rlp.rlim_cur,rlp.rlim_max);
setrlimit(RLIMIT_STACK,rlp);
exit(0);
}
and it crashes like this:
2147483648 2147483648
536870912 2147483648
Bus error (core dumped)
Maybe I am expecting too much from the system. I have a dual Athlon MP
system with about 3G of RAM, and I want to be able to use a good portion
of this RAM in a single process. But I also want to use linuxthreads so
that I can take advantage of the two processors. But linuxthreads uses
setrlimit, and crashes in a similar way to my simple program.
I looked at the kernel code in /usr/src/sys/kern/kern_resource.c at the
function dosetrlimit, which I guess is where the action takes place, but
I have no idea what to make of it.
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
allocating memory
I have access to a rather large computer (3GB of RAM) and I would like
to write a program to access most of this memory. I find that I am
unable to malloc more than about 0.5 GB of memory, even if I do it in
small increments. Now I am trying mmap, and this lets me get to about
2.5 GB of memory (again I ask for the memory in small increments). What
is it that causes these limitations?
Here is the kind of program I used to find these limits:
#include stdlib.h
#include unistd.h
#include stdio.h
#include sys/types.h
#include sys/mman.h
#define size 1
#define nr 100
main() {
char *a[nr];
unsigned int i, j;
for (j=0;jnr;j++) {
fprintf(stderr,Mallocing a[%d] with %d bytes\n,j,size);
a[j] =
mmap(NULL,size,PROT_READ|PROT_WRITE,MAP_ANON|MAP_NOCORE,-1,0);
fprintf(stderr,%d\n,(int)(a[j]));
if (a[j]==MAP_FAILED) {
perror(malloc error);
exit(EXIT_FAILURE);
}
fprintf(stderr,Filling a[%d]\n,j);
for(i=0;isize;i++) a[j][i] = i;
fprintf(stderr,Done\n);
}
while(1){} /* so the program doesn't stop and stays at the top of top
*/
}
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Linking libc before libc_r into application causesweirdproblems
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Stephen Montgomery-Smith [EMAIL PROTECTED] writes: : cc -o test test.c -pthread -D_THREAD_SAFE : : or am I misunderstanding something? Ah, yes. -D_THREAD_SAFE is technically needed. I am curious - what are the possible consequences if you forget to include -D_THREAD_SAFE? I have done many compilations having forgotten to include this flag, with no obvious problems. Did I just get lucky? -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Linking libc before libc_r into application causes weirdproblems
M. Warner Losh wrote: Confirmed. test.c appears to work properly when compiled: cc -o test test.c -pthread ./test Generally speaking, if you want to add -lc_r, you are doing things incorrectly. I've done way to much building... In FreeBSD 3.x you did need to do -lc_r, but that was changed to -pthread in 4.0. Warner According to the man page for gcc, you are supposed to write cc -o test test.c -pthread -D_THREAD_SAFE or am I misunderstanding something? -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
John Baldwin wrote: You know, I have no idea. It is someone elses code. These are the instructions. Can anyone tell me? movl 32(%0),%1\n adcl %1,32(%0)\n Also, from this discussion, what I have decided to do is provide it as an option for the user to add by editing the Makefile - not to do it automatically. These instructions are 386 instructions. What we need to see are the contraints (the stuff after the actual instructions with colons in them) to see if it is somehow using Pentium Pro+ specific registers. And actually, just for the record, a PPro is a 686. :) OK, this is it in context: register Word32 *_x = x; register int _a = 0; asm(xorl %1,%1\n /* clear C */ movl 124(%0),%1\n adcl %1,124(%0)\n : : r (_x), r (_a) ); -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
John Baldwin wrote: On 07-Jan-02 Stephen Montgomery-Smith wrote: John Baldwin wrote: You know, I have no idea. It is someone elses code. These are the instructions. Can anyone tell me? movl 32(%0),%1\n adcl %1,32(%0)\n Also, from this discussion, what I have decided to do is provide it as an option for the user to add by editing the Makefile - not to do it automatically. These instructions are 386 instructions. What we need to see are the contraints (the stuff after the actual instructions with colons in them) to see if it is somehow using Pentium Pro+ specific registers. And actually, just for the record, a PPro is a 686. :) OK, this is it in context: register Word32 *_x = x; register int _a = 0; asm(xorl %1,%1\n /* clear C */ movl 124(%0),%1\n adcl %1,124(%0)\n : : r (_x), r (_a) ); Looks like rather silly code to double the value at x + 124. I say silly casue it clears carry and then does a addcl. However, since CF is zero, this is the same as doing an addl. Since it is just doubling the value, a shl would make more sense (and only be 1 instruction.) More likely I am butchering the code by trying to only give you part of it. The whole code is designed to take N 32 bit words and do a left shift on it: register Word32 *_x = x; register int _a = 0; asm(xorl %1,%1\n /* clear C */ movl (%0),%1\n adcl %1,(%0)\n #if (N = 2) movl 4(%0),%1\n adcl %1,4(%0)\n #endif #if (N = 3) movl 8(%0),%1\n adcl %1,8(%0)\n #endif #if (N = 4) movl 12(%0),%1\n adcl %1,12(%0)\n #endif #if (N = 5) movl 16(%0),%1\n adcl %1,16(%0)\n #endif #if (N = 6) movl 20(%0),%1\n adcl %1,20(%0)\n #endif #if (N = 7) movl 24(%0),%1\n adcl %1,24(%0)\n #endif #if (N = 8) movl 28(%0),%1\n adcl %1,28(%0)\n #endif #if (N = 9) movl 32(%0),%1\n adcl %1,32(%0)\n #endif #if (N = 10) movl 36(%0),%1\n adcl %1,36(%0)\n #endif #if (N = 11) movl 40(%0),%1\n adcl %1,40(%0)\n #endif #if (N = 12) movl 44(%0),%1\n adcl %1,44(%0)\n #endif #if (N = 13) movl 48(%0),%1\n adcl %1,48(%0)\n #endif #if (N = 14) movl 52(%0),%1\n adcl %1,52(%0)\n #endif #if (N = 15) movl 56(%0),%1\n adcl %1,56(%0)\n #endif #if (N = 16) movl 60(%0),%1\n adcl %1,60(%0)\n #endif #if (N = 17) movl 64(%0),%1\n adcl %1,64(%0)\n #endif #if (N = 18) movl 68(%0),%1\n adcl %1,68(%0)\n #endif #if (N = 19) movl 72(%0),%1\n adcl %1,72(%0)\n #endif #if (N = 20) movl 76(%0),%1\n adcl %1,76(%0)\n #endif #if (N = 21) movl 80(%0),%1\n adcl %1,80(%0)\n #endif #if (N = 22) movl 84(%0),%1\n adcl %1,84(%0)\n #endif #if (N = 23) movl 88(%0),%1\n adcl %1,88(%0)\n #endif #if (N = 24) movl 92(%0),%1\n adcl %1,92(%0)\n #endif #if (N = 25) movl 96(%0),%1\n adcl %1,96(%0)\n #endif #if (N = 26) movl 100(%0),%1\n adcl %1,100(%0)\n #endif #if (N = 27) movl 104(%0),%1\n adcl %1,104(%0)\n #endif #if (N = 28) movl 108(%0),%1\n adcl %1,108(%0)\n #endif #if (N = 29) movl 112(%0),%1\n adcl %1,112(%0)\n #endif #if (N = 30) movl 116(%0),%1\n adcl %1,116(%0)\n #endif #if (N = 31) movl 120(%0),%1\n adcl %1,120(%0)\n #endif #if (N = 32) movl 124(%0),%1\n adcl %1,124(%0)\n #endif : : r (_x), r (_a) ); -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
Matthew D. Fuller wrote: On Fri, Jan 04, 2002 at 12:02:03PM -0600 I heard the voice of Stephen Montgomery-Smith, and lo! it spake thus: I want to create a Makefile for a C program that includes some Pentium II specific inline assembler code. How do I tell the compiler whether we are compiling on a i686? Dunno, how well will your Pentium II specific inline assembler code run on my Pentium Pro? You know, I have no idea. It is someone elses code. These are the instructions. Can anyone tell me? movl 32(%0),%1\n adcl %1,32(%0)\n Also, from this discussion, what I have decided to do is provide it as an option for the user to add by editing the Makefile - not to do it automatically. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Tell gcc I have a i686
I want to create a Makefile for a C program that includes some Pentium II specific inline assembler code. How do I tell the compiler whether we are compiling on a i686? For Linux, I can do something like this (for gnu-make) Arch = $(shell arch) cc .. -DArch . and inside the program #ifdef i686 But arch doesn't exist on FreeBSD. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
Alfred Perlstein wrote:
* Stephen Montgomery-Smith [EMAIL PROTECTED] [020104 12:02] wrote:
I want to create a Makefile for a C program that includes some Pentium
II specific inline assembler code. How do I tell the compiler whether
we are compiling on a i686?
For Linux, I can do something like this (for gnu-make)
Arch = $(shell arch)
cc .. -DArch .
and inside the program
#ifdef i686
But arch doesn't exist on FreeBSD.
Isn't this somewhat trivial?
ARCH=i686
CFLAGS+=-D${ARCH}
?
What I want is a makefile that automatically detects whether it is on an
i686 or not (not for me to tell it so).
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Simple pthread question
I have successfully used sleep in this situation. I wanted a process that
activated every hour (it did some garbage collection), so it went something
like
while (1) {
sleep(3600);
do_stuff();
}
and the other threads worked fine.
Arjan Knepper wrote:
How do I suspend one particular thread without suspending the whole process?
I can not use sleep or usleep can I?
TIA
Arjan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Simple pthread question
Arjan Knepper wrote: How do I suspend one particular thread without suspending the whole process? I can not use sleep or usleep can I? Also, if you do apropos pthread you will see listed a whole bunch of functions, some of which may be more suitable for you, depending upon your particular problem, for example pthread_cond_timedwait -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Unix Philosophers Please!
Nicpon, John wrote: Please specifically define where data goes that is sent to /dev/null Answer 1. Data is not like energy. There is no conservation of data law. So the data simply disappears. Answer 2. All the data goes into another dimension, and comes out of /dev/random. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Could not bind
Thanks everyone for exellent answers - I learned something from every single email I received in response. Thanks, Stephen Stephen Montgomery-Smith wrote: I have written a server program that listens on port 3000. The program works very well except for one feature. I am asking if that is normal, or whether I forgot something. If I run the program it does fine. If I then kill the program (after it has accepted connections), and then run the program again, the bind function fails to work, and I get a message like Could not bind (see program below). If I wait a while, like a minute or two, then the program will work again. Is this normal behavior, or did I miss something? -- Stephen Montgomery-Smith [EMAIL PROTECTED] 307 Math Science Building [EMAIL PROTECTED] Department of Mathematics [EMAIL PROTECTED] University of Missouri-Columbia Columbia, MO 65211 USA Phone (573) 882 4540 Fax (573) 882 1869 http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Could not bind
I have written a server program that listens on port 3000. The program
works very well except for one feature. I am asking if that is normal,
or whether I forgot something.
If I run the program it does fine. If I then kill the program (after it
has accepted connections), and then run the program again, the bind
function fails to work, and I get a message like Could not bind (see
program below). If I wait a while, like a minute or two, then the
program will work again. Is this normal behavior, or did I miss
something?
I got the programming style from Richard Steven's book on network
programming. The structure of the program is something like this:
typedef struct {
int connfd;
struct in_addr addr;
u_short port;
}
arg_pass_type;
void *process_client(void *arg) {
int connfd = ((arg_pass_type*)arg)-connfd;
struct in_addr addr = ((arg_pass_type*)arg)-addr;
u_short port = ((arg_pass_type*)arg)-port;
free(arg);
pthread_detach(pthread_self());
do_lots_of_stuff();
}
int main () {
int listenfd;
struct sockaddr_in servaddr;
socklen_t slen;
pthread_t tid;
arg_pass_type *arg;
listenfd=socket(AF_INET,SOCK_STREAM,0);
bzero(servaddr,sizeof(servaddr));
servaddr.sin_family=AF_INET;
servaddr.sin_addr.s_addr=htonl(INADDR_ANY);
servaddr.sin_port=htons(3000);
if (bind(listenfd,(struct sockaddr*)servaddr,sizeof(servaddr)) 0)
{
fprintf(stderr,Could not bind\n);
exit(1);
}
listen(listenfd,6);
while (1)
{
slen=sizeof(servaddr);
arg = malloc(sizeof(arg_pass_type));
arg-connfd = accept(listenfd,(struct sockaddr*)servaddr,slen);
arg-addr = servaddr.sin_addr;
arg-port = servaddr.sin_port;
pthread_create(tid,NULL,process_client,(void*) arg);
}
exit(0);
}
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: running diff on huge files
Rob wrote: I am trying to run diff on two huge files (220M) and I run out of swap space. Is there another alternative? I have a Python script that does something similar, but works on huge files, but it is much slower than diff. Thanks, Rob. When I tried something like this, I froze the whole computer. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ncurses
Hans Zaunere wrote: I'm sorry that this is offtopic, but I've looked/asked everywhere and no one has a clue. Once a program does initscr(), is it possible to printf()? I can printf() stuff without a problem, but it doesn't get to the screen until the program exits? I've done every ncurses function I can think of, endwin(), etc. However if there is a printf() anywhere after ncurses stuff has happened, nothing is printed to the screen until the program exits. What am I missing? Is there a trick to this, as it must be possible, right? Thank you, Hans [EMAIL PROTECTED] fprintf(stderr,..) will print stuff when ncurses is running. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ghostscript 6.51 + HP printer = WOW!
I guess that you compiled it without the ports. There are some PR's awaiting to be processed at include hpijs in the port versions of ghostscript. I hope someone commits them soon. Poul-Henning Kamp wrote: The new ghostscript 6.51 has integrated the HPIJS backends for HP printers. HPIJS is written by HP and contains most of their weird colormunging technologies. I managed to compile a 6.51 yesterday and ran it on my HP1220C printer and I can only say WOW!. I beats the pants of all the other HP/PCL/whatever backends in ghostscript. Highly recommended! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: math library difference between linux emulation and native freebsd (and native linux)
The correct answer to the level of accuracy you quote is:
137581029243568295877658.36934931
Both are correct to about 15 sig figs, which is about what the precision
of IEEE double precision arithmetic is supposed to be.
[EMAIL PROTECTED] wrote:
So I have stumbled across a linux emulation bug in freebsd. Below
is the program that returns different results based on FreeBSD,
Linux or Linux emulation under FreeBSD.
Running natively under FreeBSD:
x = 53.2785
exp(x) = 137581029243568449912832.
Running natively under Linux:
x = 53.278500
exp(x) = 137581029243568449912832.00
Running under FreeBSD in Linux emulation mode:
x = 53.2785
exp(x) = 137581029243567812378624.
#include stdio.h
#include math.h
#include stdlib.h
int main (int argc, char **argv) {
double x = 53.278500;
printf (x = %8lf\n, x);
printf (exp(x) = %8lf\n, exp(x));
exit (0);
}
There are only two shared libaries in common (libc and libm) and
both are the same on FreeBSD (in /compat/linux) and Linux.
So any ideas on where the program is going wrong?
- JimP
--
--- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $
__o [EMAIL PROTECTED] - [EMAIL PROTECTED]
_'\,_ Senior Systems Engineer, Walt Disney Feature Animation
(*)/ (*)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: math library difference between linux emulation and native freebsd (and native linux)
[EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 07/14/2001 at 11:09 AM, [EMAIL PROTECTED] said: Running natively under FreeBSD: x = 53.2785 exp(x) = 137581029243568449912832. Running natively under Linux: x = 53.278500 exp(x) = 137581029243568449912832.00 Running under FreeBSD in Linux emulation mode: x = 53.2785 exp(x) = 137581029243567812378624. My guess is difference between Linux emulation and native 's floating point formatting for printf. With the number of significant digits you're invoking, small differences in handling low order bits can be significant. You could check this out by trying the following double x,y; x = 53.278500; y = exp(x); for(i=0;isizeof(double);i++) printf(%d ,((unsigned char*)y)[i]); printf(\n); or something like that. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: math library difference between linux emulation and native freebsd (and native linux)
Yes, I tried out the program
#include stdio.h
#include math.h
main() {
double x,y;
int i;
x = 53.278500;
y = exp(x);
printf(%8lf\n,x);
for(i=0;isizeof(double);i++)
printf(%x ,((unsigned char*)(x))[i]);
printf(\n);
printf(%8lf\n,y);
for(i=0;isizeof(double);i++)
printf(%x ,((unsigned char*)(y))[i]);
printf(\n);
}
On FreeBSD and Linux I get
53.278500
cf f7 53 e3 a5 a3 4a 40
137581029243568449912832.00
e7 7d 89 54 48 22 bd 44
and on Linux emulation under FreeBSD I get
53.278500
cf f7 53 e3 a5 a3 4a 40
137581029243567812378624.00
c1 7d 89 54 48 22 bd 44
I don't really know the format of IEEE very well, but it looks like some
low order bits are different - the answers are really different.
I also tried the same experiment with sin and gamma - then the problem
does not occur. Well except that the answer for gamma(53.278500) is
reported as 157.464664 which is way wrong.
When I tried it for x=52 they gave almost the same answer, only
seperated by the last bit (the decimal versions were reported as the
same). For x=54 they both gave the same wrong answer 160.331128.
I don't know a whole lot about IEEE. What is the largest number it is
supposed to handle? Looking at man math it says it should handle
numbers as large as 1.8e308 - we certainly are not in that range!!!
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: math library difference between linux emulation and native freebsd (and native linux)
[EMAIL PROTECTED] wrote: I also tried the same experiment with sin and gamma - then the problem does not occur. Well except that the answer for gamma(53.278500) is reported as 157.464664 which is way wrong. When I tried it for x=52 they gave almost the same answer, only seperated by the last bit (the decimal versions were reported as the same). For x=54 they both gave the same wrong answer 160.331128. I don't know a whole lot about IEEE. What is the largest number it is supposed to handle? Looking at man math it says it should handle numbers as large as 1.8e308 - we certainly are not in that range!!! But remember, floating point is DIFFERENT--nothing is exact. You can create a number with a magnitude about 1.8e308, but you sure don't get 308 significant digits. You missed my point (or I didn't explain it well). I was wondering if the problem was because we were dealing with such large numbers that the arithmetic got out of wack. exp(54) = 160.331128 is way way wrong, by orders of magnitude. Same for gamma(53.27850) = 157.464664. My point is that the correct answers are way less than 1e308, so there is no excuse for the wrong answers. By the way, Mathematica, which is Linux binary running under emulation, gets the answers correct. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: math library difference between linux emulation and native freebsd (and native linux)
Stephen Montgomery-Smith wrote: exp(54) = 160.331128 is way way wrong, by orders of magnitude. Sorry - programming error - I forgot to change gamma back to exp. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: math library difference between linux emulation and native freebsd (and native linux)
Stephen Montgomery-Smith wrote: Same for gamma(53.27850) = 157.464664. Figured out this problem. gamma is returning the result of lgamma. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
dbopen man page
I have some questions about the dbopen(3) man page. 1. It seems to me that the list of includes should include something like #include fcntl.h otherwise the various flags for open(2) are not defined (like O_RDWR, etc), and these are needed for dbopen. 2. If I do something like this: db-get(db,key,data,0); db-del(db,key,0); then after the del command, the values pointed to by data are no longer valid (that is *(data.data) will have a new value). With hindsight this is obvious, but it caught me out, and maybe a warning in the man page would be appropriate. (Or maybe it is there and I didn't see it.) 3. This is nothing to do with FreeBSD, but maybe someone here knows. In Red-Hat Linux the dbopen man page is the same as for FreeBSD, but in the include files dbopen is supposed to have an extra 2nd argument of type DBX*. Anyone know what this is? The programs I wrote for FreeBSD won't compile in Red-Hat Linux. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
Mike Silbersack wrote: Matt's performance manpage covers a lot of this, but is probably not as easy to digest as an interactive script. What do I type to read this man page? -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: The FreeBSD NVIDIA Driver Initiative
Cyrille Lefevre wrote: Munish Chopra [EMAIL PROTECTED] writes: If the following isn't an appropriate subject for discussion on this particular mailing list, please move ensuing discussion to one that is more appropriate (possibly -hackers or -hardware). NVidia discussions usually are in -multimedia, no ? I can see that in general that one would like to limit day to day discussions about video cards to only the appropriate newsgroups. But I think that an announcement such as this is of such great interest that it should be sent several groups. I don't think that announcements as to how this is proceeding on a day by day basis should be distributed widely. But I do hope that when beta versions are available that this info will also be widely distributed. Also, maybe Munish could send his announcement to the comp.unix.bsd.freebsd newsgroups. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: config and config -r
I had a similar problem once when I changed the processor on my motherboard from a 486 to a 586. I recompiled the kernel but I also got those page faults. I asked on these newsgroups and people suggested the processor was broken. Then I tried config -r (well I didn't know the -r option so I did the equivalent - deleting the compile/XXX directory) and then it worked great. I think that config -r has to be done very occasionally. I guess when it has to be done, it is obvious. Maxime Henrion wrote: Hello, .. As I didn't want to recompile the whole stuff, I used a config and not a config -r to build a new kernel, after having changed its configuration. I removed several devices and I thought that won't cause any problem, as the objects files for these devices won't be linked into the kernel. But after rebooting on this new kernel, I had a page fault before any kernel message :/ Is there anything to check in order to know if I can use a config instead of a config -r ? If using a config without the -r option is dangerous, I think it shouldn't be the default. Is it the case ? -- Stephen Montgomery-Smith Department of Mathematics, University of Missouri, Columbia, MO 65211 Phone 573-882-4540, fax 573-882-1869 http://www.math.missouri.edu/~stephen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
