Re: Which Common Lisp port for FreeBSD/sparc64?
On Wed, Jan 18, 2012 at 09:50:54PM +0100, Michel Talon wrote: You can find various cmucl snapshots here: http://common-lisp.net/project/cmucl/downloads/snapshots/2012/01/ i think one of the authors has a sparc machine, and also runs maxima, so i would be confident that cmucl works OK on the sparc, but it is here apparently under solaris. Looking into cmucl-2012-01-sparcv9-solaris10.tar.bz2, it seems that the lisp itself is 32-bit: file bin/lisp bin/lisp: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Looking at http://www.cons.org/cmucl/platforms.html, only x86 and amd64 (using the x86 32-bit binaries) are supported on FreeBSD. Only solaris is supported on sparc hardware. And according to http://sbcl.sourceforge.net/platform-table.html, sbcl doesn't run on FreeBSD/sparc. It seems that the latest release only supports x86 and amd64, irrespective of OS. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpOIgeSoU1aH.pgp Description: PGP signature
Re: Sample getaddrinfo Code Compiles in Linux but not FreeBSD.
Peter Andreev writes: #include netinet/in.h Many thanks. That made the FreeBSD version work just as well. As soon as I saw netinet.h, I realized it wasn't in the original code as the Linux libraries apparently accomplish the same thing without that header. Martin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
non-responsive FreeBSD-9.0 after dump command
I'm getting a non-responsive system after issuing dump on a relatively fresh install of FreeBSD-9.0-RELEASE. The system is a VirtualBox 4.1.2 vm, with a 20GB GPT system drive and a 20GB MBR backup drive. Since it was created, the ports tree has been updated and apache22, mysql55-server and python/django installed (and a number of minor utilities). Everything seems to work ok, except for dump: # mount /dev/ada0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ad1as1d on /backup (ufs, local, soft-updates) # # cd /backup # dump -0aLf 20120118.dump / There is no output after hitting enter, and afterwards the system is generally unresponsive. A command (e.g., whoami) typed into the VirtualBox server console and an ssh terminal is echo'd, but that's all. I had started top in a seperate ssh terminal before issuing the dump command, and it shows mksnap_ffs running with 98%-100% WCPU for about 55 minutes, at which point top stops updating. I gave up after 70 minutes and yanked the virtual power cord. I then created a new FBSD-9.0 VM (system install from dvd only, and also create/fdisk/label/mount a new virtual backup drive). On this vm, dump works as expected! I moved the virtual backup drive from new to old, and also re-partitioned/re-labled the backup drive on the problem system, but no effect. FWIW, fdisk reports that on both system disks (non-working and working), the chunks do not start on track boundaries (I used auto installing the systems). Does any of this make any sense to anyone? Any ideas on how to correct the situation? I don't mind re-configure the new vm like the old, but not knowing what went wrong concerns me (and if it's just going to happen again). My basic intent is to get version 2 of a live server working first as a vm, then restore a dump onto real hardware. Thanks in advance for any and all assistance, Dale - Transparency with Trust http://www.dalescott.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: access(FULLPATH, xxx);
On 01/16/12 16:19, Polytropon wrote: On Mon, 16 Jan 2012 12:03:52 +1000, Da Rock wrote: On 01/14/12 22:06, Polytropon wrote: On Sat, 14 Jan 2012 20:37:14 +1000, Da Rock wrote: On 01/14/12 19:54, Robert Bonomi wrote: From owner-freebsd-questi...@freebsd.org Sat Jan 14 02:32:15 2012 Date: Sat, 14 Jan 2012 09:28:21 +0100 From: Polytroponfree...@edvax.de To: Robert Bonomibon...@mail.r-bonomi.com Cc: freebsd-questions@freebsd.org Subject: Re: access(FULLPATH, xxx); On Sat, 14 Jan 2012 02:00:12 -0600 (CST), Robert Bonomi wrote: To repeat some advice from one of my Computer Science professors, many years ago, whenever I asked 'how does it work' questions: Try it and find out. I bet my professor can beat up your professor. :-) Mine used to say several times: Trial and error is NOT a programming concept! As far as writing applications goes, that is _somewhat_ correct. However, 'trial and error' is _not_ the same thing as 'try it and find out'. See the entire subject area of 'benchmarking'. And, the only way to definitively establish if an alternate approach is 'better' -- i.e. 'faster', or 'smaller', or 'more efficient', etc. -- *IS* to run a trial. Your professor undoubtedly would not of approved when I wrote bubble-sort code that _out-performed_ any other sorting technique -- up to the limits of memory. Or when I re-wrote an application that used binary searches of records, with a new version that used a brute-force linear search. I thought I could 'do it better/faster' than the existing code, but the only way to definitively find out was to 'try it'. And the 'trial' proved out -- the replacement code was 'merely' somewhat over 100 times faster. *grin* Ha! Love it... :D Mee too - except that I didn't want to show that typical attitude. In fact, I tried to make a (kinf of humourical) statement about a habit that I could observe at many students when I was at university. Background: When you write source code, you can make errors. Compiler shows errors. Some students started with trial error to just silence the compiler. One form was that all functional parts of the program were enclosed in /* and */ (it was a C class) - no errors, but no action. A different approach was to arbitrarily (!) change the source code, something like that: void *foo(int blah, void *meow())(int ouch); Hmmm... gives me segfaults. Maybe something's wrong with the pointers? void *foo(int blah, void **meow())(int ouch); Not much better, segfaults too. How about that? void *foo(int blah, void meow())(int *ouch); Well... also not better. I've heared about parentheses, maybe those can help? void *foo(int blah), void *meow)(int ouch); Shit, doesn't even compile anymore! Uhm... _what_ did I change? Oh wait, I know: void *foo(int blah, (void *)meow())(int ouch); Just produces garbage, then segfaults... what could I change next? I think you get the idea. Other students could not understand that even if a program compiles without any errors, there _may_ be the possibility that it doesn't do what they intended it to do. They seemed to believe in some kind of magical semantic compiler: int x, y, sum; x = 100; y = 250; sum = a - b; They expected the compiler to notice what's wrong here if you consider the _meaning_ of the identifiers. It's not that obvious if you use x, y, and z. :-) As far as 'doing it once' for the purpose of answering a 'how does it work' question -- where one has _not_ read the documentation, *OR* the existing documentation is _not_clear_, then simple experimentation -- to get *the* authoritative answer -- is entirly justified. When I got the 'try it and find out' advice, I was asking questions about situations where the language _specification_ was unclear -- there were two 'reasonable interpretations' of what the language inthe speciication said, and I just wanted to know which one was the proper interpretation. Now, given that the language in the specification _was_ abiguous and both interpretations were reasonsble, different compiler builders could have implemented differently, and 'try it and find out' was _necessary_ to establish what that particular implementation did.grin There appears to be 2 schools of thought on this subject: a classic case of the old vs the new, in this case punchcards/slow compilers vs gcc/all-in-one compile, link and goof todays tech. I saw a similar conversation about 5 years ago on the linux lists... :) I didn't want to complain about using a test case, with determined variables (relative path vs. absolute path) to see if the interpretation of man 2 access was matching the actual inner workings of the function in use. In fact, I would even judge this the _preferred_ method to be sure. In the light of this conversation and given todays tech I'd say give it a shot unless you think something could break (as in fatal to service quality in production/hardware). Fully agree.
FreeBSD 9
I finally got to install FreeBSD 9 onto my computer and noticed that the installer is now different. It seems to me that it forces you into doing extra steps that I was comfortable doing on my own. I really enjoyed the old installer because then I had complete control over how I tweaked my computer during and after the install. I am surprised that there is no gui present while installing FreeBSD because it feels more like Ubuntu or a windows install (somewhat). Please, please, please take this nightmare away and bring the beloved installer that was before FreeBSD 9. Thank you for listening. Allan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Cross building FreeBSD
On Wed, Jan 18, 2012 at 11:38 PM, Roland Smith rsm...@xs4all.nl wrote: On Wed, Jan 18, 2012 at 01:40:02PM +0100, Christer Solskogen wrote: Hi! I've just installed FreeBSD 9.0-RELEASE on my Mac Mini G4 (powerpc) - Can I use my other, and much faster, machine(amd64) to compile world and kernel to either populate /usr/obj or to generate base.txz, and kernel.txz? It should be possible. See e.g. this article: http://bsdimp.blogspot.com/2006/09/cross-building-freebsd.html Hm, that didn't help me much. I've already built both the kernel and world on my amd64 machine. You do have to look up what the correct values of TARGET and TARGET_ARCH are on powerpc. IIRC, the G4 is 32-bit. So according to running 'make target' in /usr/src, it should be TARGET=powerpc and TARGET_ARCH=powerpc. There is no reason to add TARGET_ARCH when TARGET==TARGET_ARCH :) If you use the DESTDIR variable on the build command line, you can put the generated world and kernel in a separate directory, the contents of which you can then copy (e.g. with tar|nc or with rsync) to /usr/obj on the Mac Mini. Well, that is the question. How to copy those file over. Files have special chflags (for instance in /lib) Personally, 9.0 is the first release where I haven't bothered to build a custom kernel, because the GENERIC kernel seems to have everything I need built-in or available as a module. And neither have I bothered yet with building a custom world. I agree. But there tend to be some erratas when the time comes. (And there is no freebsd-update on ppc) And building on a PPC is a pain :) -- chs, ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Extract photo from digital camera that is not USB mass storage device
Hello, I've bought a new digital camera Canon IXUS 220, it works well (but nothing to do with FreeBSD). But I've been very sad when I saw that I can't set it to mass storage device The device can only be used as PTP device I guess, that's why I don't have any da* device when I connect it. ugen7.2: Canon Inc. at usbus7 What can I do to copy photo without extracting the SD card each time, does gphoto (or something similar) support this kind of generic device? Cheers, -- David Demelier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
