Planet Trapexit - Erlang/OTP News

Caoyuan's Blog: Scala for NetBeans Screenshot#12: Better Completion with More Types Inferred

Fri, 09 May 2008 11:52:48 +0000

Well, the type inference work is not so easy (with performance in mind), but anyway, I've got a bit more progress, at least, the chained member call can now be correctly inferred in a lot of cases. It's some level as Tor's JavaScript for NetBeans now.

First, let's create a val "node", which is a "scala.xml.Node"

Then, input '.' to invoke completion, as I know which type is of "node", the proposal items look good.

I choose "descendant" function (which returns a "List"), and input '.' again, we can see the proposal items look still good.

These features also work on Java's class.

Known issues:

It seems the indexing/scanning for Scala standard library source will perform twice when you first installed Scala plugins
The type inference is not consistence yet, so don't be strange for the strange behavior sometimes

Again, don't forget to download scala standard library's source jars and unzip to $SCALA_HOME/src, per sub-folder per jar

Caoyuan's Blog: Which Programming Language J. Gosling Would Use Now, Except Java?

Thu, 08 May 2008 14:39:02 +0000

>>> Updated later
Maybe we can get completeness of J. Gosling's opinions about Java/Scaka/JVM from here
===

According to Adam Bien's blog from JavaOne

During a meeting in the Community Corner (java.net booth) with James Gosling, a participant asked an interesting question: "Which Programming Language would you use *now* on top of JVM, except Java?". The answer was surprisingly fast and very clear: - Scala.

I think Fortress will also be a very good future choice when it gets mature.

EazyErl!: EasyErl goes Mobile Friendly

noreply@blogger.com (rolphin) — Thu, 08 May 2008 08:35:17 +0000

Hi, I'm experiencing Mobile Tagging.
You can see it at the left side of this page.
Tags are generated dynamically, I'm using of course Erlang, Mochiweb, Ghostscript (rendering backend) and iec16022 to build the semacode.

Since I own a Nokia N95, I can efficiently scan my own codes, but I don't know if it's the case for everyone :)

So leave me a comment if you find those code hard to read...
Thanks

Hypothetical Labs: Busy x 10^bazillion

Thu, 08 May 2008 00:55:13 +0000

As the saying goes, when it rains it pours. I’ve been so busy over the past few days I’ve hardly had time to even think about this blog, let alone write anything.

I can see the end to this busy period, though. Once that happens I’ll be blogging about the insanely cool stuff I’ve got going on. All I can say right now is that it’s Erlang related and I think its the bee’s knees.

Until then, your patience is appreciated.

Torbjorn Tornkvist: The dsl_engine demo

Wed, 07 May 2008 12:47:53 +0000

I have been trying out Erlware recently; and I like it a lot!

As an example, I created a demo application that show the use of the dsl_engine I wrote about earlier. Now, before I explain in more detail how I did this with the Erlware tools; here is how to try it out:

wget http://faxien.googlecode.com/files/faxien-launcher-universal-0.3.3.py sudo python faxien-launcher-universal-0.3.3.py sudo /usr/local/erlware/bin/faxien install-release dslenginedemo /usr/local/erlware/bin/dslenginedemo

Point your browser to: http://localhost:9898/

Erlang Training and Consulting
- Jobs: Experienced Server Engineer, Los Angeles, California, permanent position

Wed, 07 May 2008 00:00:00 +0000

Do you know the difference between static and dynamic typing? Are you obsessed with ducks? Do you want to jump ship from large corporations!? If so, then we’re looking for you.

Our high energy startup is committed to revolutionizing the way people think about their mobile phones. It has the potential to capture hundreds of thousand of users in the uncharted space of mobile social networking. Our service promotes, assists & inspires face-to-face connections between friends and family through the use of digital devices while maintaining an uncompromising commitment to privacy & security.

To make this happen we focus on working hard, fostering a creative job setting, working harder, indulging in our successes, and then working even harder still –you could say our ambition teeters on the insane, the good kind though.

We are seeking an experienced server engineer to join our small but rapidly growing team. This individual will thrive in a startup environment and is passionate about creating server software that scales to hundreds of thousands of concurrent users and beyond.

You will be involved in all phases of the software lifecycle, from specification to design, coding, and deployment. We will enjoy finding someone who takes pride in the quality of his/her work.

Requirements:

• Expert level server-side coding experience (Python, Erlang,Jabber/XMPP, C/C++)
• Object oriented programming background
• Experienced with functional programming
• Knowledge of distributed programming
• Strong knowledge of Postgres or MySQL and development of database-backed applications.
• Extensive experience with working with data intensive applications including data manipulation, structures and integration.
• Scalability, security and performance are at the front of your mind.

For this reason, you should have exposure to high-volume, high-availability apps and have a knack in building distributed systems.

To apply for this job, you need to be eligible to work in the US. This employer will not be sponsoring candidates.

If interested, send us your CV.

Kevin Scaldeferri's Weblog: Twittering

Tue, 06 May 2008 08:54:29 +0000

I’m now on Twitter. I’d been sort of contemplating it for a while, but Selena finally talked me into it while we were out #drunkgeeking last week. So far only 25% of my tweets are about what I’m eating.

Comments

khi's life with an exh: khigia

Tue, 06 May 2008 07:19:16 +0000

Minor updates for erlocaml (more exactly on ocamerl) … mostly code cleaning and minor refactoring!

Only one new feature: ability for Erlang processes to send message to unregistered ocaml processes. An example of that is “ex_node_mult” which generalize “ex_node_double” by dynamically creating ocaml process to perform a multiplication … yep I know, not very useful


% erlang code using the ocaml node
{byn, OcamlNode} ! {self(), 2},
By2 = receive M -> M after 1 -> error,
{byn, OcamlNode} ! {self(), 3},
By3 = receive M -> M after 1 -> error,
P1 = make_ref(),
P2 = make_ref(),
By2 ! {self(), P1, 21},
By3 ! {self(), P1, 21},
ok = receive {P1, 42} -> ok after 1 -> error end,
ok = receive {P2, 63} -> ok after 1 -> error end

With this feature, ocamerl begin to be usable … and that’s exactly what I will be doing next: experiment with more useful (at least less silly) examples! Some ideas are:

tiny mapreduce example with ocaml workers (erlang doing the network part);
using the ocaml image processing lib from erlang (not best example as lot of data need to be exchange … this is task to be solved for future erlocaml development);
others???

Caoyuan's Blog: Scala for NetBeans Screenshot#11: Go to Remote Declaration and Doc Tooltip

Sat, 03 May 2008 07:04:41 +0000

Two crazy days of my spare time, I was coding between sleeping and eating, with a lot of cups of coffee. Now Scala plugins support Go-To remote declarations (CTRL + Click on var/function name), and when you put cursor on the identifier name with CTRL pressed, or under auto-completion, the doc will also be shown as tooltip.

These features work for Java classes too ~~with a bit poor performance, I'll fix it later~~ (fixed).

Not all identifiers have been type inferred, so these features are not applicable for all identifiers.

Please update to Scala Editing module as version 1.0.26.xxx when it's available, which is the only stable one these days. Remember to unzip Scala lib's source under $SCALA_HOME/src

Programming in the 21st Century: Purely Functional Retrogames, Part 3

Sat, 03 May 2008 06:00:00 +0000

(Read Part 1 if you missed it.)

Every entity in a game needs some data to define where it is and what it's doing. At first thought, a ghost in Pac-Man might be defined by:

{X, Y, Color}

which looks easy enough, but it's naive. There needs to be a lot more data than that: direction of movement, behavior state, some base clock values for animation, etc. And this is just simplistic Pac-Man. In an imperative or OO language this topic barely deserves thought. Just create a structure or object for each entity type and add fields as the situation arises. If the structure eventually contains 50 fields, who cares? But...

In a functional language, the worst thing you can do is create a large "struct" containing all the data you think you might need for an entity.

First, this doesn't scale well. Each time you want to "change" a field value, a whole new structure is created. For Pac-Man it's irrelevant--there are only a handful of entities. But the key is that if you add a single field, then you're adding overhead across the board to all of the entity processing in your entire program. The second reason this is a bad idea is that it hides the flow of data. You no longer know what values are important to a function. You're just passing in everything, and that makes it harder to experiment with writing simple, obviously correct primitives. Which is less opaque:

step_toward({X,Y} TargetX, TargetY, Speed) ->
   ...

step_toward(EntityData, TargetX, TargetY, Speed) ->
   ...

The advantage of the first one is that you don't need to know what an entity looks like. You might not have thought that far ahead, which is fine. You've got a simple function for operating on coordinate pairs which can be used in a variety of places, not just for entity movement.

If we can't use a big struct, what does an entity look like? There are undoubtedly many ways to approach this, but I came up with the following scheme. Fundamentally, an entity is defined by an ID of some sort ("I am one of those fast moving spinning things in Robotron"), movement data (a position and maybe velocity), and the current behavioral state. At the highest level:

{Id, Position, State}

Each of these has more data behind it, and that data varies based on the entity type, the current behavior, and so on. Position might be one of the following:

{X, Y}
{X, Y, XVelocity, YVelocity}

State might look like:

{Name, StartTime, EndTime}
{Name, StartTime, EndTime, SomeStateSpecificData}

StartTime is so there's a base clock to use for animation or to know how long the current state has been running. EndTime is the time in the future when the state should end; it isn't needed for all states.

In my experiments, this scheme got me pretty far. Everything is very clean at a high level--a three element tuple--and below that there's still the absolute minimum amount of data not only per entity type, but for the exact state that the entity is in. Compare that to the normal "put everything in a struct" approach, where fields needed only for the "return to center of maze" ghost logic are always sitting there, unused in most states.

But wait, what about additional state information, such as indicating that a Pac-Man ghost is invulnerable (which is true when a ghost has been reduced to a pair of eyes returning to the center of the maze)? If you remember Part 2, then the parenthetical note in the previous sentence should give it away. If the ghost is invulnerable when in a specific state, then there's no need for a separate flag. Just check the state.

Trapexit's Erlang Blog Filter: A Comment on “Multilanguage Programming”

Sat, 03 May 2008 04:44:27 +0000

A commenter named Nick left a thoughtful response to my post about my “Multilanguage Programming” column. Rather than respond to it with another comment, I thought I’d turn my response into a full posting, as I think Nick’s feedback is representative of how many people feel about the topic.

Nick said:

I would say that instead of spending a lot of time on a conceptually different language it could be more beneficial to study, say, distributed algorithms or software/system architecture principles or your business domain. There is so much knowledge in this world that learning how to code the same thing in, roughly speaking, one more syntax seems like a waste of time. Even paying real attention to what is going on in the cloud computing can easily consume most of one’s spare time.

I think there are assumptions here that are not necessarily true. Specifically, you’re not necessarily learning how to code the same thing in multiple languages; rather, the idea is that by choosing the best language for the task, coding is “just right” for the problem at hand. For example, I know from significant first-hand experience that if you want to write a set of distributed services that support replication, failover, and fault tolerance, the code you’d write to do that in C++ will be extremely different from the code you’d write in Erlang to achieve the same thing (well, actually, you’d be able to achieve far more in Erlang, in far fewer lines of code).

This is about much more than syntax. It’s about facilities, semantics, and trade-offs. If it were just syntax, then that would imply that all languages are equal in terms of expressiveness and capability, which we already know and accept to be untrue.

The cloud computing topic actually provides a good example of why knowing multiple languages can be useful. To use the Google App Engine, for example, you need to develop your applications in Python. What if you don’t know Python? Too bad for you.

From a real life perspective, it takes years or working on nontrivial software to master a language. For example, some people still manage to have only a vague idea of util.concurent — and this is just a small enough (and well explained in the literature) part of Java. How realistic is it to expect that the majority of developers will be able to master multiple languages concurrently?

I disagree that it takes years to master a language. One of the best OO developers I ever worked with was a mechanical engineer who taught himself programming. One of my current coworkers — a relatively young guy — started programming in Erlang only a few months ago, and he’s already writing some fairly sophisticated production-quality code. In 1988, I started using C++; by 1989, I was starting to help guys like Stan Lippman, Jim Coplien, and others correct coding mistakes in their excellent books. I have a BSEE, no formal computer science training whatsoever, and am completely self-taught as far as programming languages go. (The only class I ever had in any computer language was a BASIC class I had to take in 1981.) Two other coworkers started with Python just a few months ago and they do quite well with it at this point. I can cite numerous such examples from throughout my career. I don’t think any of us are super-programmers or anything like that, so if we can do it, I don’t see why it would be a problem for anyone else.

Perhaps you’re falling trap to the “huge language” problem I mentioned in my column. It certainly can take some people many years to master enormous languages like Java and C++, but most languages are simply nowhere near that big.

And who wants to maintain a code base written in widely different languages? Which most likely means multiple IDEs, unit testing frameworks, build systems (hey, not everyone is using even Maven yet), innumerable frameworks etc. And most of the interpreted languages among those are not even likely to run in the same VM. Not to mention the number of jobs asking for non-C++/Java skills.

I use a number of languages daily and I really have no trouble maintaining the code regardless of which language any particular piece happens to be written in, or whether I wrote the code or one of my teammates did. Once you know a language, you know it; switching to it is no more difficult than using your one and only language if you’re a monolingual developer.

You also mention the “multiple IDE” problem. The first draft of my column contained some fairly direct language describing my dislike of IDEs, or more accurately, my dislike of the IDE culture, but Doug Lea suggested I take it out, so I did. The problem is that some folks let the tool drive their solutions, rather than using the tool as a means to developing solutions. I’ve had numerous people tell me they won’t consider using a language unless their IDE fully supports it with Java- or Smalltalk-like refactoring. To me, that’s completely backwards. I’d rather use an extensible editor that can handle pretty much any language, thus letting me develop optimal solutions using the right languages, rather than having a mere editing tool severely limit my choice of possible solutions.

But there are language mavens and there are tool mavens, and they typically disagree. Follow that link and read, as the posting there is incredibly insightful. I am definitely a language maven; languages are my tools. I suspect, though, that Nick and others who raise similar questions to the ones quoted here lean more toward being tool mavens. I’m not passing judgment on either; I’m only pointing out the different camps to help pinpoint sources of disagreement.

As far as unit test frameworks, build systems, and frameworks go, I haven’t ever found any big issues in those areas when using multiple languages. The reason, not surprisingly, is that knowing multiple languages gives you multiple weapons for testing and integration. Ultimately, when you’re used to using multiple languages, you’re used to these kinds of issues and thus they don’t really present any formidable barriers.

And as far as jobs go, the best developers I’ve known throughout my career have been fluent in a number of programming languages, and each of them could work virtually wherever they wanted to. I don’t believe this correlation is mere coincidence.

Curiously enough, this argumentation is hardly ever mentioned. Authors tend to assume that developers are lazy or have nothing else to learn.

I don’t assume developers are lazy. Rather, I think our industry generally has a bad habit of continually seeking homogeneity in platforms, in languages, in tools, in frameworks, etc., and we really, really ought to know better by now. Once you learn to accept the fact that heterogeneity in computing is inevitable — since nothing can do it all, right? — you find yourself able to use that heterogeneity to your advantage, rather than continually battling against it and losing.

Personally, I am planning to look at Scala and probably Erlang but even judging from the number of books on those it’s clear to me that they represent merely a niche market.

Today’s niche market is tomorrow’s mainstream market. Regardless of whether either of those languages continues to grow, learning one or both will make you a better developer than you are today.

Consider the final question I ask in my column:

After all, do any of us really believe we’ve already learned the last programming language we’ll ever need?

I suspect the vast majority of developers would answer “no” to this question. Assuming that’s the case, then if you don’t regularly practice learning new languages, how do you know when you really need to start learning a new one, and how capable will you be of learning that next language when the need arises? The longer you stay with one language, the more isolated you become, typically without even realizing it. Shifting gears gets harder and harder. Then one day you look up and all the interesting work is elsewhere, out of your reach. Is that a position you want to put yourself in?

Trapexit's Erlang Blog Filter: Erlang: It’s About Reliability

Thu, 01 May 2008 13:19:10 +0000

In a recent post, Ted Neward gives a brief description of a variety of programming languages. It’s a useful post; I’ve known Ted for awhile now, and he’s quite knowledgeable about such things. Still, I have to comment on what he says about Erlang:

Erlang. Joe Armstrong’s baby was built to solve a specific set of problems at Ericsson, and from it we can learn a phenomenal amount about building massively parallel concurrent programs. The fact that it runs on its own interpreter, bad.

I might have said it like this:

Erlang. Joe Armstrong’s baby was built to solve a specific set of problems at Ericsson, and from it we can learn a phenomenal amount about building highly reliable systems that can also support massive concurrency. The fact that it runs on its own interpreter, good; otherwise, the reliability wouldn’t be there and it would be just another curious but useless concurrency-oriented language experiment.

Far too many blog posts and articles that touch on Erlang completely miss the point that reliability is an extremely important aspect of the language.

To achieve reliability, you have to accept the fact that failure will occur, Once you accept that, then other things fall into place: you need to be able to restart things quickly, and to do that, processes need to be cheap. If something fails, you don’t want it taking everything else with it, so you need to at least minimize, if not eliminate, sharing, which leads you to message passing. You also need monitoring capabilities that can detect failed processes and restart them (BTW in the same posting Ted seems to claim that Erlang has no monitoring capabilities, which baffles me).

Massive concurrency capabilities become far easier with an architecture that provides lightweight processes that share nothing, but that doesn’t mean that once you design it, the rest is just a simple matter of programming. Rather, actually implementing all this in a way that delivers what’s needed and performs more than adequately for production-quality systems is an incredibly enormous challenge, one that the Erlang development team has quite admirably met, and that’s an understatement if there ever was one.

They come for the concurrency but they stay for the reliability. Do any other “Erlang-like” languages have real, live, production systems in the field that have been running non-stop for years? (That’s not a rhetorical question; if you know of any such languages, please let me know.) Next time you see yet another posting about Erlang and concurrency, especially those of the form “Erlang-like concurrency in language X!” just ask the author: where’s the reliability?

Web 2.0 and beyond: Adobe "opening" a few more bits of Flash

noreply@blogger.com (Roberto Saccon) — Thu, 01 May 2008 02:04:08 +0000

Their new initiative is called Open Screen Project and is dedicated to drive consistent rich Internet experiences across devices. It is not about open sourcing the flash player, just about opening some specifications, such as FlashCast protocol and the AMF protocol. But AMF for example has been reverse engineered long time ago, in 2003 when I contributed to JavaAMF, this protocol has already

Trapexit's Erlang Blog Filter: Multilingual Programming

Thu, 01 May 2008 00:40:05 +0000

Multilingual programming is one of my all-time favorite topics, and I feel very strongly that software developers should be adept at multiple programming languages. Developers need to be able to apply whatever language in their arsenal best suits the problem at hand, and perhaps even quickly learn a new language if what they already know doesn’t fit.

Too many developers seem to think that familiarity with one general-purpose language is good enough, but it isn’t. Knowing one language forces you to try to bend or change problems to fit whatever that language happens to be. That’s like trying to solve a problem by choosing a data structure or algorithm to use without ever considering the nature or details of the problem.

One of my favorite quotes on this topic is from Steve Yegge:

…an “X programmer”, for any value of X, is a weak player. You have to cross-train to be a decent athlete these days. Programmers need to be fluent in multiple languages with fundamentally different “character” before they can make truly informed design decisions.

Yes indeed.

Too many developers also come up with weak excuses for not learning new programming languages, most of them being just different ways of saying, “But it’s different from the language I already know!” Don’t whine about the differences — instead, learn to appreciate them and take advantage of them.

I’ve hinted at the fact that I like this topic in previous issues of my Internet Computing column when I covered the usefulness and applicability of languages such as JavaScript and E4X, Ruby (twice), and Erlang (also twice) for middleware and integration projects. My latest column, entitled “Multilingual Programming” (PDF), attempts to provide a few reasons why knowing and being able to apply multiple languages can be highly beneficial. As always, I welcome comments and feedback.

[Update: if you prefer not to read PDF, this column is now also available online in HTML.]

Muharem Hrnjadovic: muharem

Wed, 30 Apr 2008 16:34:40 +0000

Introduction

After a long break I picked up the Erlang book again and my appetite for writing some erlang code was soon kindled.

A small Python component I produced at work seemed like a good candidate for my (sequential) erlang exercises. It is a fairly simple component that removes user/password data embedded in URLs.

Just so you know where I am coming from:

my main/favourite programming language is Python
my exercises are mainly about sequential, non-distributed and non-telecoms-related problems whereas erlang’s main strength and appeal lies in the area of parallel/distributed telecoms/networking systems
I have played with erlang a little bit before (ring benchmark, XML parsing) and liked it in general although IMHO it lacks severely when it comes to the availability and quality of standard library components.

Now that my particular set of preconceptions is clear and in the open, let’s look at the stuff below

File processing with erlang’s regexp module

The initial implementation of the URL filter in erlang used its regexp library.

  1 -module(regex).
  2 -export([main/1]).
  3 
  4 isalphanum(C) when C > 47, C < 58; C > 64, C < 91; C > 96, C < 123 -> true;
  5 isalphanum(_) -> false.
  6 
  7 %% Generate a temporary file name of length N
  8 genname(0, L) -> L;
  9 genname(N, L) ->
 10     R = random:uniform(123),
 11     case isalphanum(R) of
 12         true -> genname(N-1, [R|L]);
 13         false -> genname(N, L)
 14     end.
 15 
 16 %% Returns a randomly generated temporary file path where the basename is
 17 %% of length N
 18 mktemppath(Prefix, N) -> Prefix ++ “/” ++ genname(N, []).
 19

Please note how I had to implement functionality absent from the standard library above.

 20 %% Removes passwords embedded in URLs from a log file.
 21 scrub_file(Tmpdir, F) ->
 22     %% make a temporary directory if it does not exist yet.
 23     case file:make_dir(Tmpdir) of
 24         ok -> ok;
 25         {error,eexist} -> ok;
 26         _ -> exit({error, failed_to_make_tmpdir})
 27     end,
 28 
 29     %% Move the original file out of the way.
 30     T = mktemppath(Tmpdir, 16),
 31     case file:rename(F, T) of
 32         ok -> ok;
 33         _ -> exit({error, failed_to_move_file})
 34     end,
 35 
 36     %% Now open it for reading.
 37     {_, In} = file:open([T], read),
 38     %% Open the original path for writing.
 39     {_, Out} = file:open([F], write),
 40 
 41     %% Call the function that will scrub the lines.
 42     scrub_lines(In, Out),
 43 
 44     %% Close the file handles and return the path to the original file.
 45     file:close(Out),
 46     file:close(In),
 47     T.
 48

The code that scrubs the URLs is below, the scrub_lines() function is tail recursive.

 49 %% This is where the log file is actually read linewise and where
 50 %% the scrubbing function is invoked for lines that contain URLs.
 51 scrub_lines(In, Out) ->
 52     L = io:get_line(In, ”),
 53     case L of
 54         eof -> ok;
 55         _ ->
 56             %% Does the line contain URLs?
 57             case string:str(L, “://”) of
 58                 0 -> io:format(Out, “~s“, [L]);
 59                 _ ->
 60                     case regexp:gsub(L, “://[^:]+:[^@]+@”, “://”) of
 61                         {ok, S, _} -> io:format(Out, “~s“, [S]);
 62                         {R, S, _} -> io:format(“Failed: {~p,~p}”, [R,S])
 63                     end
 64             end,
 65             %% Continue with next line.
 66             scrub_lines(In, Out)
 67     end.
 68 
 69 %% Main function.
 70 main([A]) ->
 71     {A1,A2,A3} = now(),
 72     random:seed(A1, A2, A3),
 73 
 74     %% A single argument (the name of the file to be scrubbed) is expected.
 75     F = atom_to_list(A),
 76     T = scrub_file(“tmp”, F),
 77 
 78     %% The scrubbed file content will be written to a new file that’s
 79     %% in the place of the original file. Where was the latter moved to?
 80     io:format(“~s~n“, [T]),
 81 
 82     init:stop().

The cursory benchmarks performed (on log files of varying size) using the python and the erlang code confirmed other people’s experiences with erlang’s regex performance (but see also this interesting “rebuttal”).

Log file size	Python times	Erlang times
1 MB	0m0.230s	0m1.896s
10 MB	0m1.510s	0m8.766s
100 MB	0m14.793s	1m17.662s
1 GB	2m55.012s	13m54.588s

The do-it-yourself construction

Curious to learn whether the performance can be improved by abstaining from regular expressions I came up with an alternative implementation that does not use regexp.

As you can see below the do-it-yourself construction is indeed performing slightly better at the expense of being very specialized and requiring 60% more code.

Log file size	Python times	Erlang regexp	Erlang do-it-yourself
1 MB	0m0.230s	0m1.896s	0m1.969s
10 MB	0m1.510s	0m8.766s	0m8.459s
100 MB	0m14.793s	1m17.662s	1m12.448s
1 GB	2m55.012s	13m54.588s	13m3.360s

In conclusion

Every couple of months or so I develop a euphoria towards erlang which is consistently dampened by using the language to tackle problems for which the language admittedly was not designed in first place.

I guess most people start using a language for simple programming exercises first as opposed to building something like a Jabber/XMPP instant messaging server straightaway.

I hate to repeat myself but improving the standard library (by adding common functionality and making sure it performs decently) would do a lot to attract fresh talent to the erlang community and I hear that a certain rate of influx of “fresh blood” is a necessary prerequisite for success.

Ah, and no, you were not supposed to grok the sentence above unless you read it three times

Web 2.0 and beyond: Firefox extensions for JS disabling and Python integration

noreply@blogger.com (Roberto Saccon) — Wed, 30 Apr 2008 09:07:57 +0000

My collection of Firefox extensions is mostly just the usual stuff you need for web development, such as Firebug, MeasureIt, ColorZilla, S3Fox, FlashSwitcher and a few more. After Firebug, for long time I didn't spot anything comparable spectacular. But recently I discovered some interesting extensions: QuickJava: Finally an extension which makes it dead simple to disable/re-enable Javascript (I

Caoyuan's Blog: Scala for NetBeans Screenshot#10: Working on Auto-Completion for Java

Wed, 30 Apr 2008 03:09:38 +0000

I've done some hacking work to get Java classes to be completion enabled, but it's not full functional. Any way, it's a good start point for auto-completion for Scala plugins, I hope to get more type inference work to be finished, and finally support both Scala/Java classes smart-completion.

Click on the picture to enlarge it

Erlang Eclipse IDE: Erlide 0.3.49.200804271817

vladdu@users.sourceforge.net (Vlad Dumitrescu) — Sun, 27 Apr 2008 17:54:16 +0000

* A long-time standing bug has been fixed, where the text went out of synch with the internal model and caused weird behaviour for the outline and other features.
* The indentation code is much better, I'd say it's almost done.
* Some stability issues have been fixed.

Enjoy! (0 comments)

Caoyuan's Blog: Scala for NetBeans Screenshot#9: Working on Auto-Completion

Sat, 26 Apr 2008 02:40:55 +0000

With the indexed cache of project's Class/Trait/Object, and Scala standard library's source files, the auto-completion is a bit smarter now. If the val/var is defined with type, the auto-completion can know which methods will be suggested. (Not work for java classes yet)

To get this working, you should follow these steps:

Update to newest Scala plugins (Editing version 1.0.21.1)
Delete the old-cache files which are located at your NetBeans's configuration directory (for example, .netbeans/dev/var/cache).
Download Scala standard library's source file, unzip them to $SCALA_HOME/src, per sub-folder per source jar file

Click on the picture to enlarge it

Web 2.0 and beyond: The missing feature of the Web: a DNS REST API

noreply@blogger.com (Roberto Saccon) — Sat, 26 Apr 2008 00:32:03 +0000

I have been waiting for years, that a quality DNS provider will a offer a REST API for setting DNS Records, but there is still no such a thing on the market. There is a SOAP based offering from Nettica (unfortunately I have an SOAP allergy). And there are the REST APIs some service providers are exposing for updating dynamic IPs. DNS Made Easy, one of my preferred DNS providers, told me about a

Web 2.0 and beyond: Amazon announced persistent storage for EC2

noreply@blogger.com (Roberto Saccon) — Thu, 24 Apr 2008 21:06:33 +0000

If Google App Engine does not provide enough flexibility for you, then there is some good news from Amazon: one of the missing pieces, persistent storage for EC2, has just been announced.

Web 2.0 and beyond: Google App Engine - Niall Kennedy's summary

noreply@blogger.com (Roberto Saccon) — Thu, 24 Apr 2008 21:05:21 +0000

Great summary about the Google App engine, by Niall Kennedy. He even provides some insights about the people behind it, and according to his first hand knowledge, this is just the beginning of what Google is rolling out: I met with the App Engine's team leads on Monday morning for an in-depth overview of the product, its features, and its limitations. Google has been working on the Google App

Web 2.0 and beyond: Scaling down - the least talked about feature of GAE

noreply@blogger.com (Roberto Saccon) — Thu, 24 Apr 2008 21:05:03 +0000

It launched less than a week ago and now all over the blogosphere people are discussing the Google App Engine (GAE). Most talk is about scaling up, about potential lock-ins, even if the SDK is based on open source software. Only one thing where developers seem generally to agree: with Python, Google has made a good choice (maybe those not knowing Python yet but desperately looking forward to

Web 2.0 and beyond: Google App Engine Team fixing issues quickly

noreply@blogger.com (Roberto Saccon) — Thu, 24 Apr 2008 21:04:03 +0000

Toying around a bit today on Google App Engine, I found a minor issue (not security related, very easy to work around and only affecting Mac users) in an add-on for the actual SDK. Only 32 minutes after I reported the issue they had fixed it !

Web 2.0 and beyond: It's getting cloudy - Yahoo Application Platform

noreply@blogger.com (Roberto Saccon) — Thu, 24 Apr 2008 21:03:23 +0000

Just read this on TechCrunch: ... Yahoo Application Platform (YAP) - which will be a direct competitor to Google App Engine. Users can host their independent applications on Yahoo’s bandwidth, storage, database and CPU resources. At first they’ll support SecurePHP applications only, but they’ll expand to additional languages over time. The model will be very similar to Google’s - free usage up to

Erlang Developers Home: Lists arithmetic

Wed, 23 Apr 2008 08:20:03 +0000

In Erlang we can use many method to access to lists and tuples, and some of them are very quick and easy. With ++ and -- operators you can add and subtract lists, like in the following example: Thelist=[1,2,3,4,5,6,7,8,9,10], Even = lists:filter(fun(E) -> E rem 2 == 0 end, Thelist), Odd=Thelist -- Even, Newlist = Odd ++ [ one, five ]. So Odd list will contains [1,3,5,7,9], Even list will contains [2,4,6,8,10] and Newlist will contain [1,3,5,7,9,one,five].

Pubblicato da stefko | Commenti

Tags: list, erlang, arithmetic

Web 2.0 and beyond: Cryptography API for Google Gears

noreply@blogger.com (Roberto Saccon) — Tue, 22 Apr 2008 22:38:12 +0000

Gears will provide native cryptography to web applications, at least this is what Google Summer of Code student Mike Ter Louw is planning to implement in the coming months. While it is possible to implement browser side cryptography in Javascript (e.g.: dojox.encoding), only few Ajax applications use this functionality, because it is slow and for communication purposes it only adds a very thin

Yariv's Blog: Startup School

Mon, 21 Apr 2008 07:25:41 +0000

I attended startup school on Saturday. It was a great experience and a rare opportunity to hear to a such impressive speakers share their wisdom about technology and entrepreneurship. Some of my favorite talks were by David Heinemeier Hansson, Greg McAdoo, Marc Andreesen, Paul Buchheit and Michael Arrington. I met a bunch of programmers and entrepreneurs and I also chatted briefly with DHH about 37signals and Peter Norvig about new search startups and their chances of competing with Google. Many thanks to YCombinator for organizing such a great event!

If you haven’t attended, you can see all the videos here. Highly recommended.

Erlang Training and Consulting
- News: Practical Erlang Programming Tutorial at OSCON 2008!

Mon, 21 Apr 2008 00:00:00 +0000

Erlang Training and Consulting has been selected to give a tutorial on Practical Erlang Programming at O’Reilly’s Open Source Convention in Portland, Oregon. The tutorial, which will cover sequential and concurrent Erlang programming, has been scheduled for the 22 Jul 2008. We look forward to seeing you there! For more information on OSCON and the contents of the tutorial, visit the OSCON conference site...

Web 2.0 and beyond: Flash done right and on Google App Engine

noreply@blogger.com (Roberto Saccon) — Sat, 19 Apr 2008 11:45:07 +0000

Often I criticize the usage of Flash for content centric pages, because often Flash is implemented in a way it causes a disastrous user experience (from arbitrarily resizing browser to sound which you can't turn off and fonts which you can't resize, just to mention the worst mistakes). Now I came across a new project, which advocates to do Flash the right way: gaeswf by Aral Balkan, a client and

Programming in the 21st Century: Purely Functional Retrogames, Part 2

Sat, 19 Apr 2008 06:00:00 +0000

(Read Part 1 if you missed it.)

The difficult, or at least different, part of writing a game in a purely functional style is living without global, destructive updates. But before getting into how to deal with that, anything that can be done to reduce the need for destructive updates is going to make things easier later on.

Back when I actually wrote 8-bit games, much of my code involved updating timers and counters used for animation and special effects and so on. At the time it made a lot of sense, given the limited math capabilities of a 6502. In the modern world you can achieve the same by using a single clock counter that gets incremented each frame.

Ever notice how the power pills in Pac-Man blink on and off? Let's say the game clock is incremented every 1/60th of a second, and the pills flop from visible to invisible--or the other way around--twice per second (or every 30 ticks of the clock). The state of the pills can be computed directly from the clock value:

pills_are_visible(Clock) ->
   is_even(Clock div 30).

No special counters, no destructive updates of any kind. Similarly, the current frame of the animation of a Pac-Man ghost can be computed given the same clock:

current_ghost_frame(Clock) ->
   Offset = Clock rem TOTAL_GHOST_ANIMATION_LENGTH,
   Offset div TIME_PER_ANIMATION_FRAME.

Again, no special counters and no per frame updates. The clock can also be used for general event timers. Let's say the bonus fruit appears 30 seconds after a level starts. All we need is one value: the value of the clock when the level started plus 30*60. Each frame we check to see if the clock matches that value.

None of this is specific to functional programming. It's common in C and other languages. (The reason it was ugly on the 6502 was because of the lack of division and remainder instructions, and managing a single global clock involved verbose 24-bit math.)

There are limits to how much a single clock value can be exploited. You can't make every enemy in Robotron operate entirely as a function of time, because they react to other stimuli in the world, such as the position of the player. If you think about this trick a bit, what's actually going on is that some data is entirely dependent on other data. One value can be used to compute others. This makes a dynamic world be a whole lot more static than it may first seem.

Getting away from clocks and timing, there are other hidden dependencies in the typical retro-style game. In a procedural implementation of Pac-Man, when Pac-Man collides with a blue ghost, a global score is incremented. This is exactly the kind of hidden update that gets ugly with a purely functional approach. Sure, you could return some special data indicating that the score should change, but there's no need.

Let's say that each ghost has a state that looks like this: {State_name, Starting_time}. When a ghost has been eaten and is attempting to return to the box in the center of the maze, the state might be {return_to_box, 56700}. (56700 was the value of the master clock when the ghost was eaten.) Or it might be more fine-grained than that, but you get the idea. The important part is that there's enough information here to realize that a ghost was eaten during the current frame: if the state name is "return_to_box" and the starting time is the same as the current game clock. A separate function can scan through the ghost states and look for events that would cause a score increase.

The same technique also applies to when sounds are played. It's not something that has to be a side effect of the ghost behavior handling code. There's enough implicit information, given the state of the rest of the world, to make decisions about when sounds should be played. Using the example from the preceding paragraph, the same criteria for indicating a score increase can also be used to trigger the "ghost eaten" sound.

Part 3

Caoyuan's Blog: New Scala Plugins for NetBeans are Available for Public Test, and Fortress, Erlang

Fri, 18 Apr 2008 16:21:34 +0000

>>> Updated Apr 22
Due to the incompatibly changes of NetBeans underlaying modules, Scala plugins can not be installed/updated on NetBeans 6.1 any more, you should get the latest nightly build to play with Scala plugins.
===

>>> Updated Apr 19

Fixed some broken syntax
Fixed NPE caused by brace completion
Fixed indentation of case class/object
Added formatting options ("Preference" -> "Scala" -> "Formatting")

Please update your Scala Editing plugin to version 1.0.19 which will be available after NetBeans hudson building.
===

The new written Scala plugins for NetBeans are available for public test now, which can be installed on NetBeans 6.1 RC, and latest NetBeans nightly build. To get start, please visit http://wiki.netbeans.org/Scala

The following features are ready for test:

Syntax highlighting
Auto-indentation
Brace completion
Formatter
Outline navigator
Occurrences mark for local variables and functions
Instance rename for local variables and functions
Go-to-declaration for local variables and functions
Scala project
Basic debugger

And with known issues:

Auto-completion it not fully supported yet and not smart
There is no parsing errors recovering yet
Semantic errors are not checked on editing, but will be noticed when you build project
Due to the un-consistent of Scala's grammar reference document, there may be some syntax broken issues

BTW, Fortress editing plugin is also available on "Last Development Build" update center, see the installation part of http://wiki.netbeans.org/Scala to get it installed. It's a very alpha stage plugin.

And, Erlang plugins are also available from "Last Development Build" update center too, that is, you can install and use Erlang plugins with Ruby, Scala, JavaScript on the same NetBeans IDE (6.1 RC or nightly build). Thanks to Tor's work, the indexing performance has been improved a lot.

Erlang plugin will be rewritten in the near future too.

Web 2.0 and beyond: Exploring some lesser known Ajax GUI toolkits

noreply@blogger.com (Roberto Saccon) — Tue, 15 Apr 2008 10:04:40 +0000

I have only been exposed so far to Dojo and ExtJS, and I believe both are bleeding edge technology, provide a great user experience and are widely accepted. But there are about 50 more Ajax GUI toolkits out there. And some of them occasionally appear on my Google Ads, so out of curiosity I took a quick look at some randomly chosen ones: SmartClient Ajax GUI System: Lots of widgets, but they

Yariv's Blog: Concurrency and expressiveness

Tue, 15 Apr 2008 06:36:36 +0000

Damien Katz’s article Lisp as Blub has sparked a lively debate on Hacker News on the relative merits of Erlang and other languages for building robust applications. Good points were made on all sides (except for the tired complaints about Erlang syntax — I have a suspicion that most people who complain about it haven’t done much coding in Erlang). Unfortunately, I think that a key point was lost in all the noise: all else being equal, a language with great support for concurrency and fault tolerance has a higher expressive power than a language that doesn’t. It just lets you build concurrent applications much more easily (less code, fewer bugs, better scalability, yadda yadda).

Caoyuan's Blog: Scala for NetBeans Screenshot#8: Working on Indexer

Mon, 14 Apr 2008 22:08:33 +0000

I've done some basic indexer code, that is, all source files under a project will be parsed, analyzed, then indexed (class/object/trait, functions, fields etc). But it's just a start, before I finished type inference, if you press CTRL+SPACE to invoke completion, there are a lot of indexed Class/Object/Trait/Function will be roughly shown on you :-), it's not smart, it's more like a puzzle, you should decide which one is applicable by yourself. But you can get a view of the coming completion feature.

Click on the picture to enlarge it

Simon Willison's Weblog: A quote from Damien Katz

Mon, 14 Apr 2008 15:17:39 +0000

Once you reach a certain level of activity in the system where the garbage collector can no longer keep up (and it will happen), then every line of code in your system is now a potential failure point that can leave the whole program in a bad state. Lisp has this problem. Java has this problem. Erlang does not.

- Damien Katz

Yariv's Blog: EC2 gets persistent block level storage

Mon, 14 Apr 2008 06:01:47 +0000

I just caught Amazon’s announcement of the new persistent storage engine for EC2. This is great stuff. It lets you create persistent block level storage devices ranging from 1GB to 1TB in size and attach them to EC2 instances in predetermined availability zones. This service complements Amazon’s other storage services — EC2 and SimpleDB — in providing raw block-level storage devices that are persistent, fast and local (so you don’t have to worry about SimpleDB’s eventual consistency issues). You can use these volumes for anything — running a traditional DBMS (MySQL, Postgres) is the first thing that comes to mind.

This announcement is a departure from Amazon’s tradition of announcing services only once they become available. It looks like Amazon is feeling the heat of competition from Google App Engine and is becoming more open to win over the hearts and minds of developers who are drawn to GAE for its auto-magical scalability. The ability to attach multiple terabyte-sized volumes on demand alleviates some of those concerns when deploying on Amazon’s infrastructure. I’m sure it won’t be long before someone creates an open source BigTable-like solution for applications that need massive scalability and redundancy on top of multiple persistent storage volumes (I think this would be a great application to write in Erlang, but I don’t know how well Erlang performs in applications that require heavy disc IO).

I like what Amazon is doing. By providing the basic building blocks for scalable applications, its enables startups to create their own GAE competitors (Heroku is the first one that comes to mind) on top of Amazon’s infrastructure. Smart move.

Google has the advantage of being able to provide APIs for tight integration with other Google services such as authentication and search (the latter is hypothetical as of now). We’ll see how strongly this plays in Google’s favor in the coming months.

Of course, price is still a question mark. Neither Amazon’s persistent storage service nor GAE have had their prices announced.

Another missing detail is the Amazon store service’s reliability. If a disc fails, do you lose your data? What’s the failure probability? Etc.

All this is great for developers. Competition between Amazon and Google means developers will enjoy more services and for lower prices in the coming years.

Yariv's Blog: Tag cloud in ErlyWeb howto

Mon, 14 Apr 2008 04:22:53 +0000

Nick Gerakines wrote a good tutorial on how to make tag clouds in ErlyWeb. Check it out at http://blog.socklabs.com/2008/04/tag_clouds_in_erlang_with_erly/.

Ruslan's Blog: alienoid

Mon, 14 Apr 2008 03:47:14 +0000

Recent Erlang releases (since R12B) have array module included.

Now binary search algorithm can be implemented quite efficiently with functional arrays:

-module(bsa).
-export([binsearch/2]).

binsearch(Arr, Key) ->
    binsearch(Arr, Key, 0, array:size(Arr)).

binsearch(Arr, Key, LowerBound, UpperBound) ->
    Mid = (LowerBound + UpperBound) div 2,
    Item = array:get(Mid, Arr),
    if
        UpperBound < LowerBound -> -1;
        Key < Item ->
            binsearch(Arr, Key, LowerBound, Mid-1);
        Key > Item ->
            binsearch(Arr, Key, Mid+1, UpperBound);
        true ->
            Mid
    end.

Running time for lists based binary search (just for comparison):

56> {Time, Val} = timer:tc(search, binsearch,
56>                        [lists:seq(1, 1000000), 1000000]).
{506513,  1000000}

Running time for array based binary search:

57> f().
ok
58> {Time, Val} = timer:tc(bsa, binsearch,
58>               [array:from_list(lists:seq(1, 1000000)), 1000000]).
{17,  999999}

Caoyuan's Blog: Progress of Scala for NetBeans - with a New Written Lexer and Parser

Sun, 13 Apr 2008 14:20:52 +0000

According to this post:

I talked to Jetbrains about this, and they told me that they stopped working on the Scala plugin for the time being, because - demand for Groovy/Ruby was higher - the language was moving too fast - Scala is a terribly difficult language for compiler/tool writers, and the only good way to analyze Scala programs might be through the official compiler, which didn't yet support this

It's true that "Scala is a terribly difficult language for compiler/tool writers", but I'm trying to bypass "the only good way to analyze Scala programs might be through the official compiler"

Before rewriting Scala for NetBeans, I considered some parser choices, one was Scala's native compiler, which is good for compiling/building Scala project, but not suitable for Editor. And JavaCC, ANTLR, which may be good enough, but it's not natural to express Scala's grammar.

Then I found Rats! which is used by Fortress, a very very clean, powerful parser generator. After couple of days working, I got an incremental lexer for Scala, and a parser for Scala that with Scala's grammar being naturally expressed (the grammar definition is ParserScala.rats). The benefit of a complete controllable parser is that I can now do some type inference and wholly semantic analysis freely and immediately.

Another progress is that I've decoupled the Scala project's dependency on Java.source's classpath in NetBeans, instead, GSF's classpath is used in Scala project module now. That means, I can begin the indexer for Scala's standard library and project source files.

The next steps will be type inference; smart completion with type inferred information; indexer for later refectory and usages searching; parsing error recover etc.

Programming in the 21st Century: Purely Functional Retrogames, Part 1

Sat, 12 Apr 2008 06:00:00 +0000

When I started looking into functional languages in 1998, I had just come off a series of projects writing video games for underpowered hardware: Super Nintendo, SEGA Saturn, early PowerPC-based Macintoshes without any graphics acceleration. My benchmark for usefulness was "Can a programming language be used to write complex, performance intensive video games?"

After working through basic tutorials, and coming to grips with the lack of destructive updates, I started thinking about how to write trivial games, like Pac-Man or Defender, in a purely functional manner. Then I realized that it wasn't performance that was the issue, it was much more fundamental.

I had no idea how to structure the most trivial of games without using destructive updates.

Pac-Man is dead simple in any language that fits the same general model as C. There are a bunch of globals representing the position of Pac-Man, the score, the level, and so on. Ghost information is stored in a short array of structures. Then there's an array representing the maze, where each element is either a piece of the maze or a dot. If Pac-Man eats a dot, the maze array is updated. If Pac-Man hits a blue ghost, that ghost's structure is update to reflect a new state. There were dozens and dozens of Pac-Man clones in the early 1980s, including tiny versions that you could type in from a magazine.

In a purely functional language, none of this works. If Pac-Man eats a dot, the maze can't be directly updated. If Pac-Man hits a blue ghost, there's no way to directly change the state of the ghost. How could this possibly work?

That was a long time ago, and I've spent enough time with functional languages to have figured out how to implement non-trivial, interactive applications like video games. My plan is to cover this information in a short series of entries. I'm sticking with 8-bit retrogames because they're simple and everyone knows what Pac-Man looks like. I don't want to use abstract examples involving hypothetical game designs. I'm also sticking with purely functional programming language features, because that's the challenge. I know that ML has references and that processes in Erlang can be used to mimic objects, but if you go down that road you might as well be using C.

The one exception to "purely functional" is that I don't care about trying to make I/O fit a functional model. In a game, there are three I/O needs: input from the user, a way to render graphics on the screen, and a real-time clock. Fortunately, these only matter at the very highest level outer loop, one that looks like:

repeat forever {
   get user input
   process one frame
   draw everything on the screen
   wait until a frame's worth of time has elapsed
}

"Process one frame" is the interesting part. It takes the current game state and user input as parameters and returns a new game state. Then that game state can be used for the "draw everything" step. "Draw everything" can also be purely functional, returning an abstract list of sprites and coordinates, a list that can be passed directly to a lower level, and inherently impure, function that talks to the graphics hardware.

An open question is "Is being purely functional, even excepting I/O, worthwhile?" Or is it, as was suggested to me via email earlier this year, the equivalent of writing a novel without using the letter 'e'?

Part 2

Erlang Training and Consulting
- News: Announcing the Stockholm Erlang User Group!

Fri, 11 Apr 2008 00:00:00 +0000

Following the success of the London Erlang User Group, Erlang Training and Consulting jump starts the Stockholm Erlang User Group. We will organise regular meetings allowing users to network and brainstorm, newbies to get their questions answered and enthusiasts to vent their ideas and frustrations. Presentations on Erlang related subjects will be a regular occurrence, followed by the mandatory erllounge. The events will be held at various Erlang companies and research institiutions in the Stockholm area and be sponsored by ETC and the host company. To get the latest news and regular updates on the events and happenings, join the dedicated mailing list either through the form on the Erlang Stockolm User Group page or by sending a blank email to erlangstockholm-subscribe@yahoogroups.com. We kick off the first Stockholm Erlang User Group meetig on the 22nd of April with a talk by Prof. Kostis Sagonas about the ongoing research of the HIPE team from Uppsala University. The presentation will start at 18.30 in Kreditor's offices in Stockholm. For the talk abstract, location and registration form, visit the Erlang Stockolm User Group Page.

Erlang Announce List: Erlang announce mailing list :: Erlang/OTP R12B-2 has been released

Wed, 09 Apr 2008 10:46:15 +0000

Author: Anonymous
Subject: Erlang/OTP R12B-2 has been released
Posted: Wed Apr 09, 2008 10:35 am (GMT 0)
Topic Replies: 0

Bug fix release : otp_src_R12B-2
Build date : 2008-04-09

This is bug fix release 2 for the R12B release.

You can find the README file for the release at

http://www.erlang.org/download/otp_src_R12B-2.readme

The source distribution and binary distribution for Windows can be
downloaded from

http://www.erlang.org/download/otp_src_R12B-2.tar.gz
http://www.erlang.org/download/otp_win32_R12B-2.exe

Beginning with this release, the distribution can also be downloaded
using the BitTorrent protocol. Use the following torrent files to
download the source distribution and binary distribution for Windows:

http://www.erlang.org/download/otp_src_R12B-2.tar.gz.torrent
http://www.erlang.org/download/otp_win32_R12B-2.exe.torrent

Note: To unpack the TAR archive you need a GNU TAR compatible program.

For installation instructions please read the README file that is part
of the distribution.

The on-line documentation can be found at: http://www.erlang.org/doc/
You can also download the complete HTML documentation or the Unix manual files

http://www.erlang.org/download/otp_doc_html_R12B-2.tar.gz
http://www.erlang.org/download/otp_doc_man_R12B-2.tar.gz

We also want to thank those that sent us patches, suggestions and bug
reports,

The OTP Team
--
Bj

Web 2.0 and beyond: Google App Engine - Quotes and thougts

noreply@blogger.com (Roberto Saccon) — Wed, 09 Apr 2008 10:24:27 +0000

From the many blog posts about the Google App Engine, my favorite quote comes from Dave Winer: Now, what Google announced is really exciting! I'm not kidding. It's even better than I hoped. Yes, it's only Python, but IBM's PC-DOS was only BASIC and Pascal when it first came out, and it didn't matter. Yeah, I preferred C, but I coded in Pascal because that's what you had to do to get an app

Web 2.0 and beyond: Erlang R12B-2 released - with native PNG drawing

noreply@blogger.com (Roberto Saccon) — Wed, 09 Apr 2008 10:22:31 +0000

It's a bugfix release and I had no big expectations when scanning through the release notes, but then I spotted this:--- percept-0.7 ------------------------------------------------------------ OTP-7162 Percept no longer depends on external c-libraries. The graphical rendering is now done via erlang code.Thats huge, if you are interested in generating PNG images and don't wanna have

Web 2.0 and beyond: Trying out Google App Engine

noreply@blogger.com (Roberto Saccon) — Tue, 08 Apr 2008 10:00:33 +0000

Yesterday night Google launched App Engine, a highly scalable web application platform, which has the potential to become a game changer. I was lucky to grab a developer account, which is currently tied to several limitations: only 10000 developer accounts availableapplications have to be coded in Pythononly three applications per developerbandwidth, storage and CPU usage limitationsno road map

Erlang Developers Home: XML socket in Flash with Ejebberd 2.0.0

Mon, 07 Apr 2008 11:03:02 +0000

I've recently been involved in the problem of Flash (7.0 and following) XML socket. Flash uses a "strange" kind of packet transfer in XML socket so Ejabberd 2.0.0 is not compatible with some Flash version. I've seen a patch for Ejabberd 1.1.X versions and I've adapted it to fit with ejabberd 2.0.0. Please note that this patch changes configure.ac file, but you must DO NOT run aclocal command. At the moment aclocal.m4 file contains some macro that aclocal command will overwrite! So please follow these steps to apply this patch to Ejabberd 2.0.0: patch -p0 <flash-xml-ejabberd-2.0.0.diff rm configure autoconf ./configure --enable-flash-hack make And you'll be able to use XMPP like this: <?xml version='1.0'?> <flash:stream to='example.net' xmlns='jabber:client' xmlns:flash='http://www.jabber.com/streams/flash' version='1.0'></flash:stream> The patch is available here.

Pubblicato da stefko | Commenti

Tags: flash, patch, ejabberd, xml socket

Erlang Developers Home: Ejabberd 2.0 Cookie Patch

Mon, 07 Apr 2008 09:37:55 +0000

As promised I'm releasing the cookie patch for ejabberd 2.0. The patch is quite simple and takes few minutes to check it out. To apply the patch cumulatively, simply do the following ejabberd/src/web/ $ patch < $HOME/ejabberd-2.0-cookie.patch Otherwise you could apply the patch to single files: ejabberd/src/web/ $ patch ejabberd_http.hrl $HOME/ejabberd_http_hrl.patch ejabberd/src/web/ $ patch ejabberd_http.erl $HOME/ejabberd_http_erl.patch Let me know if you got errors applying this patch. Links: ejabberd 2.0 Cumulative Cookie Patch ejabberd_http Source Cookie Patch ejabberd_http Header Cookie Patch

Pubblicato da loretoparisi | Commenti

Tags: cookie, patch, ejabberd

Dukes of Erl: Cooter to talk “Beautiful Concurrency with Erlang" at OSCON

Mon, 07 Apr 2008 10:10:59 +0000

Our buddy Cooter is going to be giving a talk at OSCON entitled

“Beautiful Concurrency with Erlang"

Congrats cooter.

Web 2.0 and beyond: Skype and PostgreSQL database

noreply@blogger.com (Roberto Saccon) — Sun, 06 Apr 2008 10:21:13 +0000

PostgreSQL is my favorite open source relational database. Some time ago I wrote some experimental code (currently unmaintained) for integrating it with erlyweb. The guys at Skype seem to like PostgreSQL as well. In regard to the current Google Skype takeover rumors (or was it just a 1st of April joke which went out of control ?) and to this article: Skype Plans for PostgreSQL to Scale to 1

Hypothetical Labs: OTP and Mochiweb

Sun, 06 Apr 2008 02:17:01 +0000

I’ve been brushing up on OTP trying to get a very basic application up and running to illustrate the power of Mochiweb, OTP and Erlang to a few friends. I’d forgotten (or suppressed) the overly complex manual process horror that is building OTP releases. After this, I’m doubly committed to spending some time with Erlware’s Sinan project. Coding this stuff by hand is way too ugly, IMHO.

Anyways, I’ve cooked up a small webserver which serves static files using mochiweb and OTP. The system, or release in OTP-speak, consists of three subsystems, er OTP applications. There is mime-typer who’s only purpose is to examine file extensions and guess at the files mime types. Then there’s content-server who uses mime_typer to read files off disk and figure out their mime types. At the top of the food chain we have web_server who uses content_server to read files off disk and serve them over HTTP. web_server is built on top of Mochi Media’s excellent mochiweb. I’ve packaged up the code and makefile here.

Building and running the code is pretty easy (I hope):

Download and install mochiweb. You must have this installed before preceding.
Download and expand otp-example.tar.gz
Edit web_server.app and change the port and docroot entries to fit your environment
Run make. If you’re running R12B-0 or R12B-1 there should be no errors or warnings
Symlink each of the subdirectories in the dist directory to Erlang’s lib directory. (Yes, this is ugly but I know of only one other way to do it which requires hacking hard-coded paths into ~/.erlang. That seemed worse than a few symlinks, so I opted for this solution)
From the otp-example directory run erl -boot file_server-1. An Erlang node will launch and automatically start all three applications.

After this, point your browser at http://localhost:YourPort/YourFileName and verify the server is serving content. Voila! A simple OTP system is born! In the next installment I’ll show how to deploy this example on multiple Erlang nodes.

Orbitz: Amanda Bynes is awesome

Sat, 05 Apr 2008 02:23:09 +0000

Not particularly Erlang related but, Amanda Bynes is simply amazing. I just watched Sydney White, while it wasn't as awesome as She's The Man, it did rule.

Amanda Bynes presents a Hollywood image that all girls can look up to as a role model.

All in all, she rocks.

Planet Trapexit - Erlang/OTP News

Caoyuan's Blog: Scala for NetBeans Screenshot#12: Better Completion with More Types Inferred

Caoyuan's Blog: Which Programming Language J. Gosling Would Use Now, Except Java?

EazyErl!: EasyErl goes Mobile Friendly

Hypothetical Labs: Busy x 10^bazillion

Torbjorn Tornkvist: The dsl_engine demo

Erlang Training and Consulting - Jobs: Experienced Server Engineer, Los Angeles, California, permanent position

Kevin Scaldeferri's Weblog: Twittering

khi's life with an exh: khigia

Caoyuan's Blog: Scala for NetBeans Screenshot#11: Go to Remote Declaration and Doc Tooltip

Programming in the 21st Century: Purely Functional Retrogames, Part 3

Trapexit's Erlang Blog Filter: A Comment on “Multilanguage Programming”

Trapexit's Erlang Blog Filter: Erlang: It’s About Reliability

Web 2.0 and beyond: Adobe "opening" a few more bits of Flash

Trapexit's Erlang Blog Filter: Multilingual Programming

Muharem Hrnjadovic: muharem

Introduction

File processing with erlang’s regexp module

The do-it-yourself construction

In conclusion

Web 2.0 and beyond: Firefox extensions for JS disabling and Python integration

Caoyuan's Blog: Scala for NetBeans Screenshot#10: Working on Auto-Completion for Java

Erlang Eclipse IDE: Erlide 0.3.49.200804271817

Caoyuan's Blog: Scala for NetBeans Screenshot#9: Working on Auto-Completion

Web 2.0 and beyond: The missing feature of the Web: a DNS REST API

Web 2.0 and beyond: Amazon announced persistent storage for EC2

Web 2.0 and beyond: Google App Engine - Niall Kennedy's summary

Web 2.0 and beyond: Scaling down - the least talked about feature of GAE

Web 2.0 and beyond: Google App Engine Team fixing issues quickly

Web 2.0 and beyond: It's getting cloudy - Yahoo Application Platform

Erlang Developers Home: Lists arithmetic

Web 2.0 and beyond: Cryptography API for Google Gears

Yariv's Blog: Startup School

Erlang Training and Consulting - News: Practical Erlang Programming Tutorial at OSCON 2008!

Web 2.0 and beyond: Flash done right and on Google App Engine

Programming in the 21st Century: Purely Functional Retrogames, Part 2

Caoyuan's Blog: New Scala Plugins for NetBeans are Available for Public Test, and Fortress, Erlang

Web 2.0 and beyond: Exploring some lesser known Ajax GUI toolkits

Yariv's Blog: Concurrency and expressiveness

Caoyuan's Blog: Scala for NetBeans Screenshot#8: Working on Indexer

Simon Willison's Weblog: A quote from Damien Katz

Yariv's Blog: EC2 gets persistent block level storage

Yariv's Blog: Tag cloud in ErlyWeb howto

Ruslan's Blog: alienoid

Caoyuan's Blog: Progress of Scala for NetBeans - with a New Written Lexer and Parser

Programming in the 21st Century: Purely Functional Retrogames, Part 1

Erlang Training and Consulting - News: Announcing the Stockholm Erlang User Group!

Erlang Announce List: Erlang announce mailing list :: Erlang/OTP R12B-2 has been released

Web 2.0 and beyond: Google App Engine - Quotes and thougts

Web 2.0 and beyond: Erlang R12B-2 released - with native PNG drawing

Web 2.0 and beyond: Trying out Google App Engine

Erlang Developers Home: XML socket in Flash with Ejebberd 2.0.0

Erlang Developers Home: Ejabberd 2.0 Cookie Patch

Dukes of Erl: Cooter to talk “Beautiful Concurrency with Erlang" at OSCON

Web 2.0 and beyond: Skype and PostgreSQL database

Hypothetical Labs: OTP and Mochiweb

Orbitz: Amanda Bynes is awesome

Erlang Training and Consulting
- Jobs: Experienced Server Engineer, Los Angeles, California, permanent position

Erlang Training and Consulting
- News: Practical Erlang Programming Tutorial at OSCON 2008!

Erlang Training and Consulting
- News: Announcing the Stockholm Erlang User Group!