Slashdot Mirror

As a member of the team working on the Lewis project, I'd like to provide some additional technical details. It should also be noted that the Lewis project is not intended to replace human photographers. It's an easily accessible research-oriented endeavor to explore human/robot interactions in a real-world environment.

Specifications:

• Pentium III 800Mhz CPU
• Linux operating system, kernel v2.2
• Wireless ethernet
• Sony DFW-VL500 digital 1394 camera
• Approximately 4' 6" tall, 2' diameter, 300 lbs with batteries
• 4 12V deep cycle lead-acid batteries provide nearly 6 hours of continuous use between charges.

Processor - Lewis is a B21r mobile research robot from iRobot Corporation. It's powered by a single 800Mhz Pentium IV processor. This CPU must handle all of the motor drive and low-level robot tasks such processing the data from the large array of sensors. On top of this CPU load is the task of finding faces, navigating crowds, and taking and processing the photos. The two additional processors to be installed in the future will allow Lewis much more power for its photographer duties.

Camera - Lewis currently uses a Sony DFW-VL500 [technical manual] digital 1394 (Firewire) camera. This has a 1/3" CCD that produces 640x480 color images at up to 30 frames per second. Image output is YUV 422 format and is not compressed. The built-in 12X zoom lens is sensitive to 14 lx (F1.8). Higher-resolution 1394 cameras are available, but these do not have built-in lenses; this is bad because focus, aperture, and zoom must be fixed.

Safety - The entire enclosure is lined with bump-sensitive panels, so that if the robot runs into anything, the currently executing program is terminated, the motors are halted, and the brake is applied.

Operating System - The operating system on Lewis is a standard Linux distribution using kernel version 2.2. Various libraries for control of the motors, sensors, pan/tilt unit, and camera are used.

A couple of other comments: the camera is not an NTSC video camera. It was chosen because of the easy ability to control zoom, focus, and aperture from software. Since our goal at the moment is not film-quality pictures, this camera suffices.

Sample photos are available on our website. We have been slow in posting samples due to privacy concerns, not because the pictures are bad. We have over 3,500 photos, and I'd say well less than 2% are false hits -- photos of doors, walls, elbows, etc.

sPh

It's slashdotted; I've at least got the text mirrored; images added as I get them.

http://wuarchive.wustl.edu/users/tom/mirrors/cde xp lode

I've set up a mirror of the screenshots site:


http://wuarchive.wustl.edu/users/tom/kde31alpha/

Enjoy!

And remember, in the immortal words of Michael Abrash, "Assume Nothing. Measure the improvements. If you don't measure, you're just guessing."

Indeed. But last time I touched my Amiga was sometime back in 1994 (just after I discovered UNIX :-) when I wrote this. At some point I really do need to go through my old floppy collection and transfer all my old source code to a UAE-able form before it gets irretrievably lost.

Back on topic: Somewhere, I started on a Spectrum emulator that managed to emulate the weird Speccy screen layout by using the copper - the alternative at the time had to re-draw the screen every few frames, which really killed emulation speed.

But I guess that illustrates the point nicely between an emulator and a VM. The side effect of changing a single byte could means lots of work for the emulator, whereas changing another byte at some other address with the same instruction could just be as simple as storing the data.

DJ Solenoid

KWUR Radio

Well...the Dragon book for starters, as mentioned earlier. That's probably the ur-source for most of the theory behind the magic. Makes my head hurt, though.

Terence Parr's book, Practical Computer Language Recognition and Translation (out of print). His doctoral dissertation is a useful thing too (try the Purdue University library).

comp.compilers is another useful resource. It's archived at http://compilers.iecc.com.

Alan Holub's Compiler Design in C is a classic.

The ACM's SIGPLAN ("Special Interest Group On Programming Languages") and it's journal SIGPLAN Notices of the ACM are all fine resources. So is ACM Transactions on Programming Languages and Systems.

Don't forget the IEEE as well.

Not to mention Abelman and Sussman: Structure and Interpretation of Computer Programs.

The garbage collection page is a good source for information on memory management and garbage collection.

Your university's library is another good resource.

Well. That should keep you out of trouble.

When my mother left her systems programmer job at MD, she kept all her reference materials. System manuals, assemby references, everything. Although, her shop didn't quite get to the 390 before she left (lots of nifty 360 stuff, though).

Speaking of IBM's stuff, ever try hacking AIX? Some idiot changed the root password to our webserver without telling anyone, and then forgot it. Absolute bitch to get back in. Took me 3 days, and I had the advantage of physically being at the console with an account, which was in the security, sys, audit, and system groups. Of course later some script kiddies got in through an unpatched copy of wuftpd (which I had turned off and abovementioned idiot turned back on). Oh well. At least they saw fit to mention the unusualness of the system.

When my mother left her systems programmer job at MD, she kept all her reference materials. System manuals, assemby references, everything. Although, her shop didn't quite get to the 390 before she left (lots of nifty 360 stuff, though).

Speaking of IBM's stuff, ever try hacking AIX? Some idiot changed the root password to our webserver without telling anyone, and then forgot it. Absolute bitch to get back in. Took me 3 days, and I had the advantage of physically being at the console with an account, which was in the security, sys, audit, and system groups. Of course later some script kiddies got in through an unpatched copy of wuftpd (which I had turned off and abovementioned idiot turned back on). Oh well. At least they saw fit to mention the unusualness of the system.

Things I was unaware of until the article's author enlightened me:

- Bioinformatics == Computational Pharmacokinetics


That annoyed me too. On the other hand, everyone seems to have a different opinion as to what the main problems in bioinformatics are. According to the O'Reilly books, bioinformatics is just writing Perl scripts to parse BLAST output...

Come to think of it... the great majority of 'bioinformaticians' I've met at conferences were CS grads. I must have been tricked into attending those fake bioinformatics conferences...

Well, I did a postdoc in a CS department (my doctorate was in microbiology), and there do seem to be a number of bioinformatics conferences that seem a little *too* much CS and not enough biology -- RECOMB is the classic example -- hardly ever is a practical problem discussed -- simply proving that some simplified bioinformatics problem is NP-hard doesn't cut it as bioinformatics IMHO.

But at the more useful bioinformatics conferences like ISMB and PSB you'll find a good mix of people approaching bioinformatics from both directions. And sometimes it is hard to tell who is who -- most people would imagine that Hidden Markov Model guru Sean Eddy is a computer scientist, but his background is actually in experimental genetics.

Much as I like IP, it's a really bad protocol for stuff that requires real time delivery for proper quality.

OTOH, while IP may not be the *best* protocol for distributed apps, how many people use it directly? You work with something that sits on top of it, some communications layer designed for distributed work...say ACE and similar things. Generally distributed apps don't require real-time response, so it's not the end of the world if something takes a bit to go across the pipe.

MJ Research, who filed the lawsuit, is a manufacturer of "affordable" lab equipment - including thermocyclers for PCR amplificaton of DNA - which might have been a previous patent issue for them (since they don't explicitly mention PCR in the description). Judging from their product line, they'd like to crack the sequencing market. As an aside, they have offices "all over the world", including Lake Tahoe (Incline Village, NV) - I wonder if that's a condo?

CS nerds might be in a good position to end the recession. We know how to do big simulations and distributed computing and how to mine for data to feed a simulation. We know how to run several simulations in parallel, each representing a different course of economic intervention.

The economy is driven primarily by human actions and decisions. In principle, humans could all agree that recessions are bad, and each tweak our behavior to end the damn thing. Given how much suffering the economy can cause, it seems ridiculous to leave it entirely to chance.

It may turn out that benign interventions are impossible because of conflicts of interest (an individual's own interests dictate behavior that prolongs the recession or injures society, what the economics folks call a tragedy of the commons). But it might at least merit investigation.

My own small effort in this direction appears in my sig.

Since this movie was shot in Super-35, the 4x3 version won't really be pan-and-scanned in the way that you're thinking.

And related stuff that may interest you...
* BioPython
* BioCORBA
* BioXML
* BioJava
* BioRuby
* BioExchange Software tools (other tools for working with bio*, interesting.)

The Computer Science Department of the Courant Institute of Mathematical Sciences at New York University received a contract from the Ada 9X Project Office, under the direction of Ms Christine M. Anderson, to develop a GNU/Ada system. The work was co-sponsored by ARPA and the Ada Joint Program Office.

GNAT has been validated on many platforms, by Ada Core Technologies (ACT), a company devoted to supporting users of this compiler.

Besides that, if you use Windows, you can use a free IDE, AdaGIDE, developed at the Department of Computer Science of the USAF Academy. The IDE is of course free software put under the terms of the GPL.

Well there are plenty of screengrab tools available on Aminet

As pointed out earlier, it's most likely that a photo was used to show the OS running on a laptop, rather than just to show what the OS looks like

Buckyballs are your friend.

They can fight many different types of nerve damage, they may help treating cancer, they can be superconductors at high temperature (now imagine a bewolf cluster of these!), and lots more.

From The R. Buckminster Fuller FAQ:

The exciting part of the discovery of C60 molecules is that they are only the third naturally occurring form of carbon to be found (graphite and diamond of course being the first two). C60 was first isolated from graphite (I think) in 1985.

As Paul Houle writes, C60 is formed in the shape of a geodesic sphere (like the panels of a soccer ball), hence the name ``buckminsterfullerene'' or ``buckyballs'' for short. Each carbon has three sp2 hybrid orbitals and the fourth electron of each carbon resides in a delocalized pi orbital that ranges over the entire ball (like benzene).

The physical appearance of C60 is very much similar to graphite, as are some of its physical properties. C60, unlike graphite, can be dissolved in benzene to form a translucent amber solution.

Other developments of buckyballs:

1) Radicalization - Besides just the pure C60 form, researchers at Rice have added hydrogen molecules to the carbon junctures to form molecules such as C60H36. Also, work is progressing on making C60 radical groupings (similar to benzene -> phenol).

2) Property measurement - Although many of the properties of C60 are known, most of the properties of its compounds are still hazy.

3) Higher molecules - Other stable forms with greater numbers of carbons have been isolated as well, including C70, C72, and a couple of others I can't remember. All of these have geodesic shapes as classified by Buckminster Fuller and look like lopsided versions of the normal C60 molecule.

4) Ionization - One can trap metallic ions such as Fe++ and Mg++ in the cage of the C60 to make the molecule act as a very large ion.

5) Superconductivity - As far as I know, the 18K Tc for C60 is the correct figure. This of course is much lower than high-temperature superconductors, but this fact may be used in some way at a later date.

Buckminsterfullerene (C60) is becoming ever easier to get in quantity and shows many interesting optical properties. It stops light -- the brighter the light the more effectively it stops it. Nano and pico-second laser pulses are effectively and instantly opaqued by small quantities of C60. A helmet visor treated with fullerene will instantly block an incoming laser beam -- the stronger the ray, the faster the face glass turns dark (cooler than those ``photosensitive'' sunglasses) (Patterson AFB in Ohio is studying such applications). Many other optical properties of the fullerenes are under study.

However, C60 remains forty times more expensive than gold. As Smalley put it ``it's the yield, stupid'' -- i.e. the central issue facing fullerene researchers, in Smalley's opinion, is how to get more of it. The Smalley team approach of using parabolic mirrors to sun-generate fullerenes (to produce ``sunnyballs'') appears to be a potentially promising approach. Concentrated sunlight has less of the damaging frequencies in high-powered lasers that apparently to inhibit fullerene formation from vaporized carbon).
Fullerene is quite reactive and can be used as a building block in other structures. In some crystal formations, doped with potassium for example, it conducts electricity with no resistance (is a superconductor).

I think that's what we used. You'd have to talk to the person in charge of the lab (go to www.cec.wustl.edu/news) and click on that email link - she's an administrator (as in she shuffles paperwork), but she's in charge and can point you to who you need to talk to. I think we use lpquota (Wash U doesn't enforce the limits - see below) and we run it off UNIX, but that's as much as I know.

You also might want to be sure that this is a good idea, like I said, we run lpquota, but don't enforce it 'cause it's not worth the time to track down and add a $.50 charge to someone's transcript, have them raise hell 'cause they didn't know there was a printer limit, and then ultimately get someone to remove it. Not to mention then getting your ass chewed after this happens enough times.

If you actually want to affect the people who print out large numbers of pages, screen out any print jobs larger than 50 pages (not file size) - it's amazing how many people view something a few pagedowns into a really long (poorly segmented) webpage, and then click pring, expecting only that page to show up, and then not realize that it comes out as 104 pages take the 1 they want and throw the rest away (ignoring the bright blue recycle bin). If people complain to your lab admins or whoever, it's an excellent chance to teach them the wonders of how to choose exactly which pages (ie, pages 3-4) they actually want.

Another Java assembler is the Java Bytecode Assembler

To make it even better, there is a Jasmin backend to GCC, so any language that GCC supports can be compiled into Java bytecode!!

Q: What is the trick with the 'Walker' case?

A: In the base version, it consists of a bottom and a top part. The bottom part takes the mainboard and diverse connectors. The top part contains the drives, mainly the CD-ROM. In between, you can put a middle part. A daughterboard plugs into the expansion connector of the mainboard and carries standard CPU and/or Zorro and/or Video and/or PCI slots or whatever else will be created. Many different types of daughterboards can be envisioned, for example only with PCI slots or with one CPU slot and two combined Zorro/Video slots. Depending on the daughterboard, the middle part can be of varying heights, all the way up to a full tower.

Q: What is the trick with the 'Walker' case?

A: In the base version, it consists of a bottom and a top part. The bottom part takes the mainboard and diverse connectors. The top part contains the drives, mainly the CD-ROM. In between, you can put a middle part. A daughterboard plugs into the expansion connector of the mainboard and carries standard CPU and/or Zorro and/or Video and/or PCI slots or whatever else will be created. Many different types of daughterboards can be envisioned, for example only with PCI slots or with one CPU slot and two combined Zorro/Video slots. Depending on the daughterboard, the middle part can be of varying heights, all the way up to a full tower.

Q: What is the trick with the 'Walker' case?

A: In the base version, it consists of a bottom and a top part. The bottom part takes the mainboard and diverse connectors. The top part contains the drives, mainly the CD-ROM. In between, you can put a middle part. A daughterboard plugs into the expansion connector of the mainboard and carries standard CPU and/or Zorro and/or Video and/or PCI slots or whatever else will be created. Many different types of daughterboards can be envisioned, for example only with PCI slots or with one CPU slot and two combined Zorro/Video slots. Depending on the daughterboard, the middle part can be of varying heights, all the way up to a full tower.

Well... he didn't go nuts, but he didn't make it around the world. Not from lack of alertness, just bad weather. See here.

I doubt OO will help with computational efficiency in the problems you mentioned. Where it could help is in the man-hours department. Creating reusable and extensible OO objects can reduce your coding time on any particular problem a great deal.

For example, I am a contributor to the Scythe Statistical Library which is essentially a big matrix object which supports many common operations. Scythe was initially designed by two professors who do a lot of monte carlo simulation. They still write programs that are essentially procedural to do each simulation, but the library greatly reduces the overall coding effort on each project. Other portions of the library (random number generators, numerical optimizers, etc) are as procedural and stand-alone as a standard c library. But matrices are so important that it makes sense to create an object for them. If needed we could create extending objects like triangular matrices, etc with little effort.

In essence, if you can think of some portion of your coding effort that is object-like (a matrix, a polygon, an engine part) and important enough to many different projects, creating an object for it makes sense. This is especially true if you can think of sub-objects which you might use in the future.

There are tons of great software titles available for the Amiga. If you consider the sheer amount of FREELY available high quality software titles avaiable for the Amiga, it`s not a bad idea to get AmigaOS XL running on your PC.

What exactly is the agreement I have with the University?
Briefly, my agreement with the University allows me, as well as members of my group, to produce open source software so long as:
(1) all authors agree for the software to be open source,
(2) the funding source agrees with the code being open source, and
(3) no laws are broken (including aspects of patent law embodied in the Bayh-Dole act).

Note that while this agreement permits my group to produce open source software, it does not require that we produce open source software. This is a blanket agreement covering all of my software written at the University.

Who funded this research?
The agreement covers all of my software development, regardless of source (though, as noted above, each source must be consulted). It was drawn up before I had any funding, as part of my employment agreement. Since then, my research has been funded from public sources (NIH, NSF, DOE, LBNL, and the University of California), and from a private charity (a Searle Scholarship).

Some clarifications of my views, where the article was imprecise

1. I believe it is desirable for authors to be allowed to produce open source software. At this point, I think it would be inappropriate for it to be required, as others have proposed. I currently have no problem with other scientists who readily distribute their software but not use open source licenses.
   
2. I believe that prospective authors of open source should approach their Universities with a standard contract similar to mine. I do not presently support a movement to "force universities to allow 'open source' publishing," as the article states.
   
3. I am not opposed to the Novartis/Syngenta agreement at Berkeley, as the article suggests. In fact, I have not studied that agreement carefully, and so I have no considered view of it. My impression is that much being said here about the agreement is incorrect.
   
4. I feel that fixing bugs is only one of many benefits of open source, and probably not the primary benefit (as the article suggests)
   
5. My agreement does not run counter to laws that allow the University to enter exclusive licensing agreements. The primary law governing such agreements is Bayh-Dole, which covers patents. My agreement only covers copyright. Moreover, my agreement has as a prerequisite permission from the funding source.
   
6. I agree with Phil Green that many individuals have greater respect for software that they've paid for. No problem: have both an Open Source and a commercial license for the code (as is the case for important programs like HMMER).

1. The University's default licensing agreement allows anyone to use the source code for non-commercial, research purposes. It's not nearly as bad as most posters here suggest. See it here (note: the original site is down; this is the google cache).
   
2. It is instructive to actually read the U.S. patent code as modified by the Bayh-Dole act. As I understand it, the main point of this act is encourage intellectual property from federal funding to be developed, rather than left to sit on in the dust on a shelf.
   
3. The University of California, Berkeley was quite helpful in arranging my open source agreement. I understand why their default license is different, and I appreciate their assistance in modifying their standard terms to accommodate my scientific goals. I was very happy with the University's response, and I think the agreement is eminently reasonable.

I welcome follow-up postings here and will try to answer further questions that arise.

Steven E. Brenner
http://compbio.berkeley.edu

The Silicon Valley article is a bit misleading, and doesn't accurately reflect the range of distribution alternatives being used for Bioinformatics software. It is certainly true that many Universities claim ownership of computer software copyrights, but it is important to appreciate that there many levels at which the implementation of these policies is decided. For example, both the WU-BLAST and the HMMer packages were developed by researchers at Washington U. in St. Louis. WU-BLASTbinaries are available to academics after an appropriate license is signed, and licensed commercially. HMMer i is available under the GPL but a commercial license is also available.

Likewise, the FASTA package, can be freely downloaded by both academic and commerical users, but must be licensed from the U. of Virginia to be redistributed. This has allowed the software to be widely used by researchers and also incorporated into commerical packages.

As a Bioinformatics researcher and software author, my goal is to have my research and software be used as widely as possible. This improves my ability to obtain future external funding, to get my papers cited, etc. etc. Even at universities like Wisconsin and Stanford, which derive enormous sums from IP licensing, these funds are less than 10% the value of NIH and other external funding. Thus, it is not hard to argue that software licensing policies should maximize the likelihood of external funding, and the widest possible distribution (though not necessarily GPL) is likely to have the greatest impact and long term benefit. (Moreover, once software becomes widely used, it is much more valuable commercially.)

Thus, while a university's Vice-President for Research may be interest in IP licensing, a Dept. Chairman may be more interested in faculty success in obtaining external funding, and a broader software distribution.

The Silicon Valley article is a bit misleading, and doesn't accurately reflect the range of distribution alternatives being used for Bioinformatics software. It is certainly true that many Universities claim ownership of computer software copyrights, but it is important to appreciate that there many levels at which the implementation of these policies is decided. For example, both the WU-BLAST and the HMMer packages were developed by researchers at Washington U. in St. Louis. WU-BLASTbinaries are available to academics after an appropriate license is signed, and licensed commercially. HMMer i is available under the GPL but a commercial license is also available.

Likewise, the FASTA package, can be freely downloaded by both academic and commerical users, but must be licensed from the U. of Virginia to be redistributed. This has allowed the software to be widely used by researchers and also incorporated into commerical packages.

As a Bioinformatics researcher and software author, my goal is to have my research and software be used as widely as possible. This improves my ability to obtain future external funding, to get my papers cited, etc. etc. Even at universities like Wisconsin and Stanford, which derive enormous sums from IP licensing, these funds are less than 10% the value of NIH and other external funding. Thus, it is not hard to argue that software licensing policies should maximize the likelihood of external funding, and the widest possible distribution (though not necessarily GPL) is likely to have the greatest impact and long term benefit. (Moreover, once software becomes widely used, it is much more valuable commercially.)

Thus, while a university's Vice-President for Research may be interest in IP licensing, a Dept. Chairman may be more interested in faculty success in obtaining external funding, and a broader software distribution.

Since I haven't seen it, here are several free programs useful for computational chemistry:

GAMESS Free Electronic Structure Package

ViewmolMany types of visualization

gOpenMolVisualization and property Calculation

RasMolVisualization

EgoMolecular Dynamics Program

TinkerMultifacited Package

X-PLORMolecular Dynamics Tailored for Biological Systems

As a whole, the CommonC++ design is pretty messy, relying on massive amounts of kludgy ifdefs and macros in the header files. I believe they are working on cleaning it up.

Other libraries I would consider:

• ACE: threads, synchronization, sockets. ACE's design is not very object-oriented, but its probably the most extensively portability layer you will find.

• IOLib, portable I/O (also includes identical ports for C and Objective-C).

• ZThread for threads.

• Nescape Portable Runtime (NSPR), a C library: sockets/IPC, threads, synchronization primitives, layered I/O, ADTs/algorithms, portable shared libraries, logging, etc.

Others have said it already, but I'd like to add my vote for ACE. I work on air-traffic control equipment at a major defense contractor, and ACE is used extensively and successfully here. It is stable, reliable, mature, and comprehensive. It is very well designed, IMHO. It is widely used by the government and the aerospace industry. It is also open-source, and has excellent support from it's creators.

One of the standout features of ACE is that is not only a set of OS-neutral wrappers; although it can be used successfully for that purpose alone. The creator of ACE, Doug Schmidt, is a respected member of the Software Patterns community (he has helped write and/or edited several of the seminal patterns books). ACE is designed to implement many of the patterns that recur in networked programs, saving the programmer from reimplementing and debugging those patterns for the nth time. For example, if your application is an event-driven server that must demultiplex input and output on multiple files and ports, it's a prime candidate for the Reactor pattern. Rather than write and debug a reactor on your own, you can just use an ACE Reactor and save yourself the trouble.

The patterns discovered and/or used in ACE are thoroughly documented in Schmidt's book, Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects.

No, I'm not associated with ACE or Schmidt in any way. I'm just a contented user.

Others have said it already, but I'd like to add my vote for ACE. I work on air-traffic control equipment at a major defense contractor, and ACE is used extensively and successfully here. It is stable, reliable, mature, and comprehensive. It is very well designed, IMHO. It is widely used by the government and the aerospace industry. It is also open-source, and has excellent support from it's creators.

One of the standout features of ACE is that is not only a set of OS-neutral wrappers; although it can be used successfully for that purpose alone. The creator of ACE, Doug Schmidt, is a respected member of the Software Patterns community (he has helped write and/or edited several of the seminal patterns books). ACE is designed to implement many of the patterns that recur in networked programs, saving the programmer from reimplementing and debugging those patterns for the nth time. For example, if your application is an event-driven server that must demultiplex input and output on multiple files and ports, it's a prime candidate for the Reactor pattern. Rather than write and debug a reactor on your own, you can just use an ACE Reactor and save yourself the trouble.

The patterns discovered and/or used in ACE are thoroughly documented in Schmidt's book, Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects.

No, I'm not associated with ACE or Schmidt in any way. I'm just a contented user.

Others have said it already, but I'd like to add my vote for ACE. I work on air-traffic control equipment at a major defense contractor, and ACE is used extensively and successfully here. It is stable, reliable, mature, and comprehensive. It is very well designed, IMHO. It is widely used by the government and the aerospace industry. It is also open-source, and has excellent support from it's creators.

One of the standout features of ACE is that is not only a set of OS-neutral wrappers; although it can be used successfully for that purpose alone. The creator of ACE, Doug Schmidt, is a respected member of the Software Patterns community (he has helped write and/or edited several of the seminal patterns books). ACE is designed to implement many of the patterns that recur in networked programs, saving the programmer from reimplementing and debugging those patterns for the nth time. For example, if your application is an event-driven server that must demultiplex input and output on multiple files and ports, it's a prime candidate for the Reactor pattern. Rather than write and debug a reactor on your own, you can just use an ACE Reactor and save yourself the trouble.

The patterns discovered and/or used in ACE are thoroughly documented in Schmidt's book, Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects.

No, I'm not associated with ACE or Schmidt in any way. I'm just a contented user.

Others have said it already, but I'd like to add my vote for ACE. I work on air-traffic control equipment at a major defense contractor, and ACE is used extensively and successfully here. It is stable, reliable, mature, and comprehensive. It is very well designed, IMHO. It is widely used by the government and the aerospace industry. It is also open-source, and has excellent support from it's creators.

One of the standout features of ACE is that is not only a set of OS-neutral wrappers; although it can be used successfully for that purpose alone. The creator of ACE, Doug Schmidt, is a respected member of the Software Patterns community (he has helped write and/or edited several of the seminal patterns books). ACE is designed to implement many of the patterns that recur in networked programs, saving the programmer from reimplementing and debugging those patterns for the nth time. For example, if your application is an event-driven server that must demultiplex input and output on multiple files and ports, it's a prime candidate for the Reactor pattern. Rather than write and debug a reactor on your own, you can just use an ACE Reactor and save yourself the trouble.

The patterns discovered and/or used in ACE are thoroughly documented in Schmidt's book, Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects.

No, I'm not associated with ACE or Schmidt in any way. I'm just a contented user.

Look at the ACE tookit at http://www.cs.wustl.edu/~schmidt/ACE.html.

It has cross platform support for: networking, threading, IPC, file API, etc.

You can grab it from here. Its got a non-standard compilation method, but for anyone with half a brain, it shouldnt be too hard. And it supports all unicies and win32. They've also chosen to expose a unix style API for their OS abstraction layer, which is perfect.

Hope it helps.

http://www.cs.wustl.edu/~schmidt/ACE.html

Jim

Absolutely,

As someone using ACE at the moment (well, in another screen). I can say that I've never found a more well-constructed cross-platform middleware package. You can find it here. In addition, the DOC group's TAO package provides a CORBA implementation on top of ACE that works really well for... well, those CORBA things *grins*.

One drawback when using any middleware package that I've seen is that you have to buy in pretty heavily to the package, somewhat adopting the development philosophy of the package's designers. With ACE that hasn't been as much of a problem (For instance, it provides a method of dispatching QT events) mostly because the underlying design is heavily pattern based.

On other fronts, I also continually find the Boost libraries to be very useful. They can be found here.

Probably the last thing to consider is that if you vary your development platform, you are likely going to be changing your C/C++ implementation--and they are not all created equal. Personally, I've found that the cross-platform availability and easy integration of the Dinkumware C/C++ libraries are pretty much worth the middle-of-the-road costs involved. Dinkum's located here.

I'm using ACE for this purpose, and it really works.

For threading:
use the boost library, Boost.Threads

For network:
Use ACE

Port io is trickier; i am aware of a couple of free libraries for NT, which are rumoured to make things more like unix, butI have never really used them. look on google for dlportio and giveio.

Have a look at ACE. It provides all you'll need - and probably a lot more!

For a simple, free, portable threading library, also have a look at OmniThread.

I'll second the recommendation of ACE. In addition to ACE, The ACE ORB (TAO), Zen, their real-time ORB, and Jaws, An Application Framework for High Performance Web Systems, are all worth a look. This stuff has been around for quite some time and has been ported to nearly every compiler-platform imaginable.

I'll second the recommendation of ACE. In addition to ACE, The ACE ORB (TAO), Zen, their real-time ORB, and Jaws, An Application Framework for High Performance Web Systems, are all worth a look. This stuff has been around for quite some time and has been ported to nearly every compiler-platform imaginable.

ACE is an open-source framework that provides many components and patterns for developing high-performance, distributed real-time and embedded systems. ACE provides powerful, yet efficient abstractions for sockets, demultiplexing loops, threads, synchronization primitives.
I've never tested this framework but it seems very good. I know several companies which use it and which are happy with it.

As many here have already noted, FPGAs cannot yet approach the complexity of current processors, yet current processors lack some basic (and very useful) features of FPGAs. Perhaps the best way to leverage the strengths of both would be to embed a small FPGA in processors that is controlled (bitfile, I/O, etc) from the cpu itself. That way, if you had need for say, a priority encoder or massively parallel ALU, you just load a module into the onboard CPU and away you go. This would eliminate one of the biggest bottlenecks for off-board FPGA coprocessors (memory bandwidth) and limit the complexity of the implementation. I'm taking a FPGA design course right now and you'd be amazed what you can do in 10-20k gates. Anyone else have any experience in this area?

Derek

Here is a list I came across a while ago now. It lists close to all known computer languages. Go check it out now.

Mr. McMaster could have saved himself some time and money by checking the ol' internet. A search for "nutating disk engine" on Google turns up this web page:

http://www.me.wustl.edu/ME/faculty/tk/nutating.htm

Which claims a patent exists on the device (in 1993!). Since the article says McMaster came up with his "revolutionary" new design in 2000, you can see we have a little problem.

The web page also has a video of a (non-working) prototype.

-AC (who's not so much a coward as too lazy to register -- you should have an "Anonymous Lazy Bastard" option)

Nope. We play what we please. It's our decision entirely, as students, and we consciously chose to try and support the underground music scene, because our mission is to educate our listeners. If you're interested, we're KWUR 90.3FM in Clayton, MO (a few hundred feet from the St. Louis city limits). Website: http://kwur.wustl.edu