Re: [9fans] GCC/G++: some stress testing
On Fri, Feb 29, 2008 at 10:39 PM, Lyndon Nerenberg [EMAIL PROTECTED] wrote: But none of this code will just work on Plan 9 (especially the Fortran code), so what's the point? Why do you say that? ron Looking at GCC, there's plenty more effort required before the full suite of compilers (don't forget ADA's in there, too) is ready for prime time under Plan 9. But it does seem that in going there, it is possible to feed back to GNU how to avoid the more obvious pitfalls (Auto* tools when the compiler in fact defines the environment almost entirely) and, reason prevailing, this might lead to a different approach. One way or another, eventually the current flood of software has to undergo some quality control and at that point it would be good if there were principles by which to measure such quality. Looking the other way isn't going to be helpful and we're all caught up in it, so those of us with opinions and knowledge may need to contribute. ++L PS: I still haven't a single offer of software to stress test GCC 3.0, nevermind the assistance I'm bound to need to make use of the C++ features.
Re: [9fans] GCC/G++: some stress testing
One way or another, eventually the current flood of software has to undergo some quality control and at that point it would be good if there were principles by which to measure such quality. Perhaps you should look at this page: http://www.gnu.org/software/reliability.html It is no fluke that the GNU utilities are so reliable. There are good reasons why free software tends to be of high quality. We don't need any measurement for free software, because everything will get well if you just license your software under the GPL. You must keep ini mind, that even Cancer Clinic Relies on Free Software! It must be all good! -- hiro
Re: [9fans] GCC/G++: some stress testing
can it compile a working pm?---BeginMessage--- Before I apply some serious effort to bring P9GCC in line with the latest release, I'd like to convince myself that the effort is worth it. I'm keen to catch two birds with one stone: (a) make sure that version 3.0 is sufficiently functional and (b) determine how useful it really is. Please will anybody who has a Plan 9 objective that can only be attained using GCC/G++ please drop me a line to let me know briefly what it is? If the whole exercise gets a lot of support, I'll happily set up more infrastructure to deal with it (wiki, blog, remote access, whatever Bell Labs would rather not do themselves). ++L PS: I prefer if you use the 9fans list, I may miss your mail if I haven't already have entered your sender address in my whitelist. Use your discretion.---End Message---
[9fans] intellect?
On 2008-Mar-1, at 03:13 , hiro wrote: Perhaps you should look at this page: Perhaps you should read this book (among others): http://www.powells.com/biblio/0-201-03669-X?PID=30607
Re: [9fans] intellect?
i think hiro was being sarcastic
Re: [9fans] intellect?
On 2008-Mar-1, at 03:47 , Lyndon Nerenberg wrote: Perhaps you should read this book (among others): And I should go crawl in the hot tub. I'll shut up now. It's been a long day.
Re: [9fans] problem with compilation of abaco from fgb's sources
I also had been trying to compile Abaco and ended up just downloading the binary. Though one necessary font was missing, once that was remediated, Abaco worked fine _ Product Reviews Read Unbiased Beauty Product Reviews and Join Our Product Review Team! http://thirdpartyoffers.juno.com/TGL2111/fc/JKFkuJNzkI7wuwvoUfP5WdIThCahsqOuCxv8ajXt0uMMMQKcmgeyZH/
Re: [9fans] intellect?
http://en.wikipedia.org/wiki/Irony, eh. Perhaps you should read this book (among others) Oh, you are a good man;) -- hiro
Re: [9fans] GCC/G++: some stress testing
can it compile a working pm? I'll try. ++L
Re: [9fans] intellect?
His books are controlling quality more than we could ever do. The books take over the brains of its readers. Furthermore a lot of them will end up here on this list.
Re: [9fans] GCC/G++: some stress testing
Hello, At work, most of the users need a fortran compiler (although almost none of them actually use gfortran, they prefer ifort) and some of them do parallel computation so they need MPI. If I could have at least those two items thanks to P9GCC, maybe I could convince some of them to work on the plan9 servers I'm slowly setting up there. As for me, I'd be pretty happy if I could have a bittorrent client (especially libtorrent/rtorrent, written in c++) on plan9 so it'd be rather nice if your P9GCC could achieve building that. But yeah, that one relies on auto*, configure, etc.. Mathieu. On Sat, Mar 01, 2008 at 06:55:06AM +0200, [EMAIL PROTECTED] wrote: Before I apply some serious effort to bring P9GCC in line with the latest release, I'd like to convince myself that the effort is worth it. I'm keen to catch two birds with one stone: (a) make sure that version 3.0 is sufficiently functional and (b) determine how useful it really is. Please will anybody who has a Plan 9 objective that can only be attained using GCC/G++ please drop me a line to let me know briefly what it is? If the whole exercise gets a lot of support, I'll happily set up more infrastructure to deal with it (wiki, blog, remote access, whatever Bell Labs would rather not do themselves). ++L PS: I prefer if you use the 9fans list, I may miss your mail if I haven't already have entered your sender address in my whitelist. Use your discretion. -- GPG key on subkeys.pgp.net: KeyID: | Fingerprint: 683DE5F3 | 4324 5818 39AA 9545 95C6 09AF B0A4 DFEA 683D E5F3 --
Re: [9fans] GCC/G++: some stress testing
Why not just port Version 7 f77 and Version 7 Ratfor? On Mar 1, 2008, at 9:45 AM, [EMAIL PROTECTED] wrote: Hello, At work, most of the users need a fortran compiler (although almost none of them actually use gfortran, they prefer ifort) and some of them do parallel computation so they need MPI. If I could have at least those two items thanks to P9GCC, maybe I could convince some of them to work on the plan9 servers I'm slowly setting up there. As for me, I'd be pretty happy if I could have a bittorrent client (especially libtorrent/rtorrent, written in c++) on plan9 so it'd be rather nice if your P9GCC could achieve building that. But yeah, that one relies on auto*, configure, etc.. Mathieu. On Sat, Mar 01, 2008 at 06:55:06AM +0200, [EMAIL PROTECTED] wrote: Before I apply some serious effort to bring P9GCC in line with the latest release, I'd like to convince myself that the effort is worth it. I'm keen to catch two birds with one stone: (a) make sure that version 3.0 is sufficiently functional and (b) determine how useful it really is. Please will anybody who has a Plan 9 objective that can only be attained using GCC/G++ please drop me a line to let me know briefly what it is? If the whole exercise gets a lot of support, I'll happily set up more infrastructure to deal with it (wiki, blog, remote access, whatever Bell Labs would rather not do themselves). ++L PS: I prefer if you use the 9fans list, I may miss your mail if I haven't already have entered your sender address in my whitelist. Use your discretion. -- GPG key on subkeys.pgp.net: KeyID: | Fingerprint: 683DE5F3 | 4324 5818 39AA 9545 95C6 09AF B0A4 DFEA 683D E5F3 --
Re: [9fans] GCC/G++: some stress testing
On Sat, Mar 1, 2008 at 12:39 AM, Lyndon Nerenberg [EMAIL PROTECTED] wrote: On 2008-Feb-29, at 22:02 , Eric Van Hensbergen wrote: It will no doubt be useful to us folks doing work for the gov't. They DOE has lots of apps written for GCC or Fortran -- while there may be other methods of accommodating these applications, having them just work with GCC (particularly if the GCC fortran could be part of the port) would help us a lot. It could also serve as a baseline for performance/efficiency comparisons with other methodologies such as linuxemu, etc. But none of this code will just work on Plan 9 (especially the Fortran code), so what's the point? We are well aware of the peeling onion effect - it is just a step. Many of the HPC apps will just work with a minimum of fuss, others will require a considerable bit of fuss. To add to Ron's MPQC example, I'll just through out the HPCC benchmark suite: http://icl.cs.utk.edu/hpcc/ -eric
Re: [9fans] GCC/G++: some stress testing
Why not just port Version 7 f77 and Version 7 Ratfor? Sounds like an idea. Where do I find the source code? Mind you, it's been tens of years since I programmed in Fortran IV, it's going to be hard for me to do any testing. ++L
Re: [9fans] GCC/G++: some stress testing
At work, most of the users need a fortran compiler (although almost none of them actually use gfortran, they prefer ifort) and some of them do parallel computation so they need MPI. If I could have at least those two items thanks to P9GCC, maybe I could convince some of them to work on the plan9 servers I'm slowly setting up there. I don't have any hasty plans for Fortran, but it seems to be in greater demand than C++. We'll see how things pan out. I am a little concerned that potential users need more than a compiler invocation to make things work, specially on the graphics side and maybe I ought to wave that flag rather frantically. Still, one obstacle out of the way may encourage others to address the next ones. As for me, I'd be pretty happy if I could have a bittorrent client (especially libtorrent/rtorrent, written in c++) on plan9 so it'd be rather nice if your P9GCC could achieve building that. But yeah, that one relies on auto*, configure, etc.. Let me emphasise that the auto* stuff is nowhere near the stumbling block it's made out to be. Benavento (I hope I'm not pointing fingers at the wrong person right now - no way to check) and I have different techniques to address this, but we both have done a good deal of porting auto* dependent stuff to APE with the help of moderately simple mkfiles. Then again, I stumbled with Graphviz version 2, sadly. Graphics, networking and multithreading are much bigger issues to resolve. So your bittorrent client may be difficult to port and damn easy to redevelop. Any chance you may give it a try? ++L
Re: [9fans] GCC/G++: some stress testing
On Sat, Mar 1, 2008 at 9:02 AM, [EMAIL PROTECTED] wrote: Graphics, networking and multithreading are much bigger issues to resolve. So your bittorrent client may be difficult to port and damn easy to redevelop. Any chance you may give it a try? Networking and multithreading are going to be more important than graphics to us -- but as you said earlier, one step at a time. We'll be working towards this stuff as well as part of the FastOS program so hopefully we'll be able to help provide some of these pieces. IBM has already done a good amount w.r.t. supporting POSIX networking APIs using Inferno devip as a backend, I imagine we can apply many of these techniques to APE or other accomodation platforms. -eric
Re: [9fans] GCC/G++: some stress testing
Caldera (now SCO) released the source code a while ago. It has since been mirrored. The direct links to the f77 and Ratfor are: http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/f77 http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/ratfor I can get started with it later today. On Mar 1, 2008, at 10:17 AM, [EMAIL PROTECTED] wrote: Why not just port Version 7 f77 and Version 7 Ratfor? Sounds like an idea. Where do I find the source code? Mind you, it's been tens of years since I programmed in Fortran IV, it's going to be hard for me to do any testing. ++L
Re: [9fans] GCC/G++: some stress testing
On Fri, Feb 29, 2008 at 11:29 PM, Lyndon Nerenberg [EMAIL PROTECTED] wrote: On 2008-Feb-29, at 23:11 , ron minnich wrote: But none of this code will just work on Plan 9 (especially the Fortran code), so what's the point? Why do you say that? The lack of a F95 compiler in /bin? (If you have one in house, that's cheating.) The comment was especially the Fortran code, but also saying none of this code. So my question stands: why is it that *none* of this code would work? ron
Re: [9fans] GCC/G++: some stress testing
On Sat, Mar 1, 2008 at 7:17 AM, [EMAIL PROTECTED] wrote: Why not just port Version 7 f77 and Version 7 Ratfor? Sounds like an idea. Where do I find the source code? Mind you, it's been tens of years since I programmed in Fortran IV, it's going to be hard for me to do any testing. very litlle f77 left in my world, maybe somebody else has some. Ratfor? Surely you must be joking. ron
Re: [9fans] GCC/G++: some stress testing
There is a lot of G code that really essentially is only portable to linux (or close, e.g. BSDs). There is other code that works nearly everywhere that has a GCC. The why bother pessimism is best reserved for more suitable occasions. I'm really glad when APE allows me to compile legacy code and would be equally pleased when on the odd occaison that GCC was needed, available and kind to me. brucee On Sun, Mar 2, 2008 at 3:40 AM, ron minnich [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 11:29 PM, Lyndon Nerenberg [EMAIL PROTECTED] wrote: On 2008-Feb-29, at 23:11 , ron minnich wrote: But none of this code will just work on Plan 9 (especially the Fortran code), so what's the point? Why do you say that? The lack of a F95 compiler in /bin? (If you have one in house, that's cheating.) The comment was especially the Fortran code, but also saying none of this code. So my question stands: why is it that *none* of this code would work? ron
Re: [9fans] GCC/G++: some stress testing
Also note that neither F77 nor ratfor produced particularly good code. They did, however, work. Both attributes are required by the Fortran community. If the GCC stuff provides this service and you want to do the work then I won't throw stones. brucee On Sun, Mar 2, 2008 at 3:41 AM, ron minnich [EMAIL PROTECTED] wrote: On Sat, Mar 1, 2008 at 7:17 AM, [EMAIL PROTECTED] wrote: Why not just port Version 7 f77 and Version 7 Ratfor? Sounds like an idea. Where do I find the source code? Mind you, it's been tens of years since I programmed in Fortran IV, it's going to be hard for me to do any testing. very litlle f77 left in my world, maybe somebody else has some. Ratfor? Surely you must be joking. ron
Re: [9fans] GCC/G++: some stress testing
On Sat, Mar 01, 2008 at 05:02:59PM +0200, [EMAIL PROTECTED] wrote: As for me, I'd be pretty happy if I could have a bittorrent client (especially libtorrent/rtorrent, written in c++) on plan9 so it'd be rather nice if your P9GCC could achieve building that. But yeah, that one relies on auto*, configure, etc.. Let me emphasise that the auto* stuff is nowhere near the stumbling block it's made out to be. Benavento (I hope I'm not pointing fingers at the wrong person right now - no way to check) and I have different techniques to address this, but we both have done a good deal of porting auto* dependent stuff to APE with the help of moderately simple mkfiles. Then again, I stumbled with Graphviz version 2, sadly. Graphics, networking and multithreading are much bigger issues to resolve. So your bittorrent client may be difficult to port and damn easy to redevelop. Any chance you may give it a try? Well if there was one project I'd try to code for, that would probably be it. I even thought about proposing myself as a student for gsoc with this idea in mind (although I seem to recall one condition is to be a student irl, which is not my case anymore). However I'm pretty sure I would not be able to commit enough time to it, so it would be kindof worthless to start with it and never get to finish it properly. Besides, I have not coded seriously in a long time, so I'm probably not the right candidate to write something that doesn't suck atm. Mathieu. -- GPG key on subkeys.pgp.net: KeyID: | Fingerprint: 683DE5F3 | 4324 5818 39AA 9545 95C6 09AF B0A4 DFEA 683D E5F3 --
Re: [9fans] GCC/G++: some stress testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If GNU was so reliable we wouldn't see the C compiler generate random opcodes for architectures we use at my work. And that's *with* the 4x toolchain. I think we've all had enough software evangelism. Everyone has bugs. GNU is absolutely no exception. D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHyZ1WyWX0NBMJYAcRAkfYAKCZ4tXZlv6Q8GoiJ1fYSdViUMOf0QCeLS1j itTtT5VQs1lyfmjq1++uRtQ= =w2e0 -END PGP SIGNATURE-
Re: [9fans] GCC/G++: some stress testing
If GNU was so reliable we wouldn't see the C compiler generate random opcodes for architectures we use at my work. And that's *with* the 4x toolchain. I think we've all had enough software evangelism. Everyone has bugs. GNU is absolutely no exception. they do, with complete reliability, break new things in new releases. - erik
Re: [9fans] GCC/G++: some stress testing
If GNU was so reliable we wouldn't see the C compiler generate random opcodes for architectures we use at my work. And that's *with* the 4x toolchain. I'm not sure if I read you correctly, but all I'm looking for is some confidence that P9GCC is worth pursuing. I can't use the supplied regression tests because they rely on expect and in any event they only prove that things work, not that there are needs out there that P9GCC actually satisfies. ++L
Re: [9fans] GCC/G++: some stress testing
Ron, I think you're confusing ratfor with software tools. There was a ratfor implementation in C on Unix, and I wrote ratfor when I had to use Fortran, and others did too, independent of the software tools effort. The point of Ratfor was to make Fortran bearable; I can't imagine writing bare Fortran any more. I compiled ratfor and f2c on my home Plan 9 systems a while ago and they just worked. I don't remember any porting effort. I might have had to change a path name in a makefile.
Re: [9fans] GCC/G++: some stress testing
There are a ton of biology tools written in rather simple c++. Those people are willing to look at p9 if we have two things: -g++ -python thanks ron
Re: [9fans] GCC/G++: some stress testing
On Sat, Mar 1, 2008 at 12:29 PM, [EMAIL PROTECTED] wrote: Ron, I think you're confusing ratfor with software tools. There was a ratfor implementation in C on Unix, and I wrote ratfor when I had to use Fortran, and others did too, independent of the software tools effort. The point of Ratfor was to make Fortran bearable; I can't imagine writing bare Fortran any more. You're right. My mistake. No more stones. Sorry brucee. ron
Re: [9fans] GCC/G++: some stress testing
I mentioned to skip that you were mistaken but it seemed like an honest mistake so we had brunch. Where is all the abuse gone anyway, or are my filters working? brucee On Sun, Mar 2, 2008 at 8:36 AM, ron minnich [EMAIL PROTECTED] wrote: On Sat, Mar 1, 2008 at 12:29 PM, [EMAIL PROTECTED] wrote: Ron, I think you're confusing ratfor with software tools. There was a ratfor implementation in C on Unix, and I wrote ratfor when I had to use Fortran, and others did too, independent of the software tools effort. The point of Ratfor was to make Fortran bearable; I can't imagine writing bare Fortran any more. You're right. My mistake. No more stones. Sorry brucee. ron
Re: [9fans] GCC/G++: some stress testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a project on the go that would make an awesome plan9 platform. Except that all our users code in C++. The complicated kind, with templates and hideous metaprogramming. And can even show good reason to do so. Makes me weep. Paul On Mar 1, 2008, at 1:36 PM, ron minnich wrote: There are a ton of biology tools written in rather simple c++. Those people are willing to look at p9 if we have two things: -g++ -python thanks ron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFHyf3ApJeHo/Fbu1wRAuyOAKCvc0TnvBfcxd3qBvI1CetHHFqJPQCgkROU B0P9e8lJdECTriryAsB3ut0= =J9rR -END PGP SIGNATURE-
Re: [9fans] GCC/G++: some stress testing
On Sat, Mar 1, 2008 at 5:07 PM, Paul Lalonde [EMAIL PROTECTED] wrote: Except that all our users code in C++. The complicated kind, with templates and hideous metaprogramming. And can even show good reason to do so. welcome to my life. Lots of holes in the walls around here, roughly the size of my head. ron
[9fans] upas/fs to imap: removed messages sometimes regenerate
I'm seeing some odd (wrong) behavior with Plan 9's upas/fs and was wondering of others have seen it, before I start digging further. I use upas/fs to talk to a local mailbox and two IMAP servers. The local store and one of the IMAP servers work reliably correctly. On the other IMAP server, upas/fs will *sometimes* get into a state where when I remove a message, it'll re-insert itself into the tree with a higher message number. For example, with the IMAP server dalet: :; cd /mail/fs/dalet :; ls 1 2 ctl :; rm 1 2 ; ls 3 4 ctl Messages 34 are the same as 12; nothing new's actually come in. Other IMAP clients I've used behave properly with this server. I've not yet identified the pattern which causes it, but it's not random. Anyone else seen this or similar?
