Ikaros is a framework for writing and running component-based simulators. It is used for simulations of brain areas and learning models, but is general enough to be easily used for any discrete-time simulations. A simulation consists of modules written in C or C++ that are connected in the simulator, with connections specified in an XML file. It runs on the console, and can optionally generate a dynamic browser-based UI with SVG for graphics generation. There are also socket-based hooks for adding a full GUI. The package contains a number of modules and complete documentation for working with the framework.
Re: Won't gain wide adoption without a distro
> There are already too many different
> software packaging and distribution
> systems. Some of them are good (e.g.,
> FreeBSD ports and packages, and, from
> what I hear, apt), and some are not so
> good (e.g., RPM), but the proliferation
> is a real problem. As a user, I don't
> want to worry about whether a particular
> piece of software has been packaged
> using the system I use. As a programmer,
> I don't want to be bothered creating
> many different packages. I recently
> googled on the name of a piece of
> software I wrote, and found out that
> several people were distributing old
> versions in RPM format. On the one hand,
> it's flattering that they went to the
> trouble, but on the other hand, it's a
> drag that they're distributing old
> Rather than adding one more packaging
> system to the mix, I'd rather see some
> of the badly designed ones (RPM
> especially) go away, so that effort
> could be better focused on the ones that
> are well designed.
*sigh* You are confusing very different things here.
RPM != apt
RPM == deb
RPM is a package format, and is neither better or worse than the deb format (which debian uses).
Apt is a package manager, which can use deb, RPM or whatever package format. An alternative to Apt is Yum, which also in principle can work with whatever package format.
Removing RPM as an alternative would do nothing, zero, squat for solving packaging problems. In fact, suggesting that we dump the most commonly used format is counterproductive; if you want to standardize, why dump the one that is used by over 90% of distros already? Debian could in principle switch over to RPM from Deb without its users even noticing; just push an update over apt.
Package problems are really due to differences between distros. If you want to hand out binary packages, they pretty much need to be built separately for every distro you wish to support.
Re: Interesting but incomplete
> I actually did that today, and
> surprisingly enough the performance
> isn't significantly different from
> spamassassin without the bayesian
> filter. In fact it scored slightly worse
> on the final "TCR" analysis - though as
> I said by an insignificant amount.
> Of course I may have done something
> wrong - I just deleted the contents of
> the $HOME/.spamassassin directory,
> touched $HOME/.spamassassin/user_prefs
> and then ran sa-learn on the training
> emails. And then ran spamassassin as
> My training sets are smaller than
> recommended by spamassassin, so it may
> be essentially ignoring them?
I'm surprised as well. I found a marked difference in performance when I trained the Bayeasian filtering. As you say, it may have an internal threshold on the number of training instances before it decides to trust the filter. Another factor is of course what the threshold for classifying something as spam is set up as; by default, Spamassassin is quite conservative. WIth a high threshold, the impact from the Bayesian filtering may be too low.