Thursday, April 19, 2007

Erlang

Erlang: "Blogs

There's a lot of activity in the blogsphere; go to Google search and search for Erlang blogs. Also, here's some articles you might enjoy:

Web sites

Now go and look in this directory: http://www.erlang.org/doc/doc-5.5.3/pdf/. You'll find 50 odd PDF files here.

I've chosen a few of these for you to look at:

Each one of these represents a book that is just waiting to be written :-)

Have a good read.

Copyright © 2007 Joe Armstrong"

Friday, April 13, 2007

Virtualization with coLinux

Virtualization with coLinux: "Virtualization with VmWare, Xen, and Kernel-based Virtual Machine (KVM) are all the rage these days. But did you know that you can run Linux® cooperatively with Microsoft® Windows®? This article explores Cooperative Linux (coLinux), starting with a quick introduction to virtualization and then looking at the approach taken by coLinux. You'll also see how to get coLinux up and running on Windows."

InfoQ: .NET Memory Leaks

InfoQ: .NET Memory Leaks: "A problem with .NET that isn't talked about is the problems caused by using dynamic code generation. In a nut shell, dynamic code generation, which is used in XML Serialization, Regular Expressions, and XSLT transformations, can lead to memory leaks.

While the Common Language Runtime (CLR) can unload whole App Domains, it cannot unload individual assemblies. Code generation relies on creating temporary assemblies. These assemblies are often loaded into the primary app domain, meaning that cannot be unloaded until the application exits.

For libraries like XML Serialization, this isn't much of a problem. Usually the serialization code for a given type is cached, which limits the application to one temporary assembly per type. But there are XMLSerializer overloads that don't use caching. If a developer uses one of these without providing some sort of application-level cache, memory can be slowly leaked as new instances of essentially the same code is loaded into memory. For more information specifically on XML, see .NET Memory Leak: XmlSerializing your way to a Memory Leak.

The potential problems are far worse for code that habitually rewrites itself at runtime such as those written in LISP. For that sort of language, either the code has to be run entirely interpreted, that is never being compiled to IL code, or placed in separate AppDomains that can be purged fr"

Monday, April 09, 2007

Re: ICMP Ping

Re: ICMP Ping: "Look at http://home.uninet.ee/~taavi/files/erlang/

contains port driver for ICMP ping (freebsd ping program was used as start).

best regards,
taavi

> I am trying to write a very simple network monitoring tool. Not trying
> to replace any of the commercial products/open source, but as a nice
> example to try and learn about erlang features (concurrency and
> Mnesia) in a real scenario."

Thursday, April 05, 2007

There Are Only Four Software Licenses: "Jeff Atwood writes a great summary of Open Source Licenses. As far as I’m concerned, there’s really only four software licenses to worry about (open source or otherwise).

1. Proprietary - The code is mine! You can’t look at it. You can’t reverse engineer it. Mine Mine Mine!
2. GPL - You can do whatever you want with the code, but if you distribute the code or binaries, you must make your changes open via the GPL license.
3. New BSD - Use at your own risk. Do whatever the hell you want with the code, just keep the license intact, credit me, and never sue me if the software blows your foot off. The MIT license is a notable alternative to the New BSD and is very very similar.
4. Public Domain - Do whatever you want with the code. Period. No need to mention me ever again. You can forget I ever existed."

Wednesday, April 04, 2007

Making it stick.: Systems: "Would you rather your body attempt to act as one 'logical' cell, or are you happy to survive as a system of cooperating cells with billions dying off and being replaced each day?

Steve Loughran reminding us of a Note on Distributed Computing. From the note...
We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
A favorite quote from elsewhere by Jim Waldo, one of the authors...
I've been known to claim that there are two kinds of reliable message systems. The first kind are those that come with an asterisk; following the asterisk leads you to the small print, where you find out when the messaging system can fail and so it is not, therefore, reliable. The second kind are those systems that simply lie – they are no more reliable, but they don't tell you that there are circumstances where they can fail.
posted by Patrick Logan # 9:21 PM

Distributed Systems in Practice: The Human Body
Patrick has noticed the parallels as has Werner Vogels. There’s an awful lot of stuff to be learnt about building distributed systems from the human body including how control isn’t centralized, how reliability is achieved and how the ..."

Monday, April 02, 2007

Create an Eclipse-based application using the Graphical Editing Framework: "Graphical Modeling Framework (GMF)

The GMF project was born out of the frustration in creating graphical editors manually (especially in the context of using the Eclipse Modeling Framework). GMF allows you to effectively map (see Figure 5) your semantic (business logic) model to a notional (graphical) model. Once this mapping is complete using a few configuration files, GMF will generate a fully functional graphical editor for you.

Figure 5. GMF development flow
GMF development flow

If your use cases have you using the Eclipse Modeling Framework for your model, it is highly recommend that you use GMF instead of GEF directly. Read Chris Aniszczyk's 'Learn Eclipse GMF in 15 minutes' for more information (see Resources).

Zest

Zest is a lightweight visualization toolkit (see Figure 6) that provides a JFace-like wrapping on top of traditional GEF editors. Zest has been modeled after JFace, and all the Zest views conform to the same standards and conventions as existing Eclipse views (think label and content providers). This means that the providers, actions, and listeners used within existing applications can be leveraged within Zest. Also, Zest has reusable layouts that can be applied to your visualizations with ease.

Figure 6. Sample Zest Visualizations
Sample Zest Visualiz"