Sunday 5 December 2010

A very interesting conference of James Gosling

Happened on November 17, 2010, so it's really fresh. And the fact that Gosling has resigned from Oracle sometime ago and is still unemployed makes it free of a lot of corporate language.

One of the problem of most Fortran code is a) It's doing something really important b) The person who wrote it is probably dead.



Multicore. what can we do about it? What's the right thing to do with Hava? It feels like there's an unbounded supply of PHD thesis topics in there. The problem is that it has been a really rich source of PHD thesis topics for about 30 years.


One of the things about generics is that, you wander around the world, you talk to language designers, 15 years ago, and they would all say, Generics, really really good idea, you got to do it this way, but they all had a different version of this way.


I know that there had been some conversations between Google and Sun to do something early on, that was all just spectacularly weird(..).) Some sort of cooperation should have worked out a whole lot smoother than it did(...) It was weird. I'll leave it there.


(about CLR). They deleted all security feature to allow C pointers, because they wanted to do C. That's like the dumbest thing they have ever done. The instruction set, they added registers to it, that adds nothing, they just wanted to be different.(...) The biggest problem I have with the CLR is that they haven't put nearly as much energy on it(...) We were running at least a factor of two on almost everything. Their code generators are not very good, mostly because they were being lazy(...) Microsoft, in their harder parts, doesn't care about CLR that much because all their real meat and potatoes projects are not that. Word and such are still fundamentally big bags of C code. So they have not really had to depend on it for their own products.

Sunday 24 October 2010

Have fun with ARINC 661, XUL, Javascript, beanshell, and Java

Remember this post two years ago? Well you can also add Groovy to the list...

The Client-Server ARINC 661 framework project has been Open Sourced for 2 months now. You can get the binaries, and the sources here: http://j661.sourceforge.net/. Just a quick reminder: In the ARINC 661 standard, the Client (called User Application in the standard), handles the logic, and the Server performs the graphic rendering.

The communication protocol in ARINC 661 is specific and a bit complex (no SOAP, no REST, no CORBA, not RMI, but purely specific binary messages on top of the lower-level bus-level layer protocol). So to ease development of Java clients, the j661 project propose a generic API to handle this in the Client side.

The basic Client just allows users to send messages to the Server, but there is more than that. It is possible to script the Client behavior, and even to add a user interface for Client options (for example a Slider - called Scale in XUL, to change a value).

There are three parts which are necessary to script the Client:

  • The graphics part is rendered by one or several XUL script files

  • The controller is performed by Javascript (by using Rhino

  • The logic is performed by beanshell or Groovy



One cool side-effect of using XUL is that users are able to debug their scripts using Firefox.

How is it working? When clicking a button, or performing any user action on the XUL script, the associated XUL widget fire the appropriate JavaScript command (nothing special here). What begins to change a little is the fact that JavaScript is allowed to execute Beanshell or Groovy code, which in return can communicate with the Server using the ARINC 661 protocol.

Let's use an example (check the Scripting tutorial for the j661 project if you want more informations):


<button id="identifier" label="Hide Triangle" disabled="false"
oncommand="triangleHidden()" />


If the user click on the button, it will fire the triangleHidden() method on JavaScript. In this case, this method is directly written inside the XUL script (it could also have been defined in a external JavaScript file):

function triangleHidden() {
changeTriangleVisibility();
}

As there is no changeTriangleVisibility() method in JavaScript, it will look for a method with this name in Beanshell (in our case). The Beanshell script has been referenced in our XUL script in this way:

<script type="text/bsh" src="testScript2.bsh" />


And the Beanshell script contains the following code:

tatefullAPI api;
XULScriptContext ctx;
int LAYER_ID = 56;
int TRIANGLE_ID = 100;
boolean visible = true;
init(StatefullAPI theApi, XULScriptContext theCtx) {
api = theApi;
this.ctx = theCtx;
}
run() {
}
changeTriangleVisibility() {
visible = !visible;
api.setWidgetParameter(LAYER_ID, TRIANGLE_ID, ARINC661.A661_VISIBLE,
visible);
api.sendLayerMessage(LAYER_ID);
}


All of ARINC 661 messages can be handled like this.

Sunday 19 September 2010

An ARINC 661 tutorial: communication (2)

In July I posted a first tutorial on ARINC 661 communications protocols. It was still a little theoretical, but today we will be able to putn= it into application. if you want =play a little with ARINC 661 protocol while following this tutorial, you can download the last version of the Open Sourced j661 project here. Just unzip the archive anywhere. You only need to have a Java 6 JDK available on your machine.

First we will open an ARINC 661 Definition File, for example this very simple one:

<?xml version="1.0" encoding="UTF-8" standalone="no" >
<a661_df name="default" library_version="0" supp_version="2">
<model>
<prop name="ApplicationId" value="1" />
</model>
<a661_layer name="MyLayer" >
<model>
<prop name="MinWidgetIdent" value="1" />
<prop name="MaxWidgetIdent" value="65535" />
<prop name="LayerId" value="1" />
<prop name="ContextNumber" value="0" />
<prop name="Height" value="10000" />
<prop name="Width" value="10000" />
</model>
<a661_widget name="panel" type="A661_PANEL">
<model>
<prop name="WidgetIdent" value="1" />
<prop name="Enable" value="A661_TRUE" />
<prop name="Visible" value="A661_TRUE" />
<prop name="PosX" value="0" />
<prop name="PosY" value="0" />
<prop name="SizeX" value="10000" />
<prop name="SizeY" value="10000" />
<prop name="StyleSet" value="0" />
</model>
<a661_widget name="label" type="A661_LABEL">
<model>
<prop name="WidgetIdent" value="2" />
<prop name="Anonymous" value="A661_FALSE" />
<prop name="Visible" value="A661_TRUE" />
<prop name="PosX" value="3527" />
<prop name="PosY" value="3721" />
<prop name="SizeX" value="2978" />
<prop name="SizeY" value="1000" />
<prop name="RotationAngle" value="0.0" />
<prop name="StyleSet" value="0" />
<prop name="MaxStringLength" value="20" />
<prop name="MotionAllowed" value="A661_TRUE" />
<prop name="Font" value="t2" />
<prop name="ColorIndex" value="red" />
<prop name="Alignment" value="A661_CENTER" />
l&t;prop name="LabelString" value="HELLO WORLD" />
</model>
</a661_widget>
</a661_widget>
</a661_layer>
</a661_df>


(This file is included in the distribution of the j661 Server).

We will first start a Server and load this file (see this tutorial in the project wiki to know how to do it). You should see this:


The we will do the same with the Client. The Client window should look like this:


To look at the content of the messages from the Client to the Server, right-click on the log area at the bottom of the Server window, and click "Log Buffer Events". We will now be able to dump the content of the communication from Client to Server.

Make sure you connected both the Client and the Server. For now we will just change the Color of the "HELLO WORLD" label at the middle of the Layer.:

  • Change the value of the "A661_COLOR_INDEX" in the upper right window for the label, for example to green. This represent a A661_CMD_SET_PARAMETER command

  • Then add this command to the message by clicking "Add"

  • Now send the message to the Server


Of course, the color of the label has now changed to green (what did you expect?), but what is interesting is the hexadecimal dump in the log area:

B0 01 0000 00000018 CA02 000C 0002 0000 B160 06 00 D0 000000

We will now decode together this message content:

  • B0 is the code for the begin block in the message

  • 01 is the Layer identification (1 here)

  • 0000 We now have an ushort for the context number

  • 00000018 (or 24 in decimal) is the length of the block in bytes, including the header

  • CA02 is the code for the A661_CMD_SET_PARAMETER command

  • 000C is the size of the A661_CMD_SET_PARAMETER command

  • 0002 is the widget identification, here the label identification is 2

  • 0000 we now have a padding of an ushort, to align to 32 bit

  • B160 is the code for the A661_COLOR_INDEX property

  • 06 is the index corresponding with the green Color (beware that the association between the value and the color is CDS-dependant)

  • 00 is there to to align to 32 bit

  • D0 is the code for the end block in the message

  • 000000 The last 24 bits are there to align to 32 bit



In the case of the j661 Server, this bytes are sent through an UDP port, but this content (normalized by the standard), can be sent through any low-level protocol (TCP, ARINC 429, AFDX), etc...

Friday 10 September 2010

ARINC 661 project: First tutorial

I am still uploading documentation and working on the wiki for the j661 The project here: http://j661.sourceforge.net/. This project provides a generic ARINC 661 Server, a generic ARINC 661 Client (UA), and a Definition File editor.

The first tutorial explains how to configure the Editor, opening a Definition File, doing some modifications, and saving the result.

Sunday 5 September 2010

ARINC 661 project Open Sourced

The ARINC 661 Server project I talked about some time ago is now Open Sourced under a GPL V2 License, with a Dassault Aviation (my employer) copyright. The project is up and running here: http://j661.sourceforge.net/

In fact the project is more than only an ARINC 661 Server (CDS). It also provide a generic ARINC 661 CLient (UA), and a Definition File editor.

I will upload more documentation for this project on the next days. Stay also tuned here for tips on this tutorial.

Monday 12 July 2010

An ARINC 661 tutorial: communication

A recent comment on my blog leads me to the necessity of continuing my list of tutorials about ARINC 661 development. Today will be about communication. hmm at least it will be the first of a list of posts on the subject, because if ARINC 661 XML definition is easy to grasp, I can't say the same thing about communications in the ARINC 661 world.

Don't be afraid. It's not because it's particularly complicated, but just because it's a binary communication protocol, so looking at the message can be a little cryptic.

Let's first say that ARINC 661 communication goes both ways: User Applications can ask for widgets (or even Layers) modifications, and the CDS Server will notify the relevant UA of any User event only on the Definition File it manages (remember the part about ApplicationI in my Hello World tutorial). Now you understand why this ApplicationId tag is very important.

Another important thing is that the standard does not mandate any transport protocol. The ARINC 661 communication protocol is just living on any transport protocol we choose. For example, ARINC 661 messages can be transmitted on the very simple UDP protocol, or TCP, or even complex avionics protocols like AFDX for example. On another point of view, one can encapsulate the ARINC 661 messages binary content, for example to add a checksum function to the transmission. ARINC 661 is agnostic on the way datas are transmitted. The only thing that matters is that you have to find somewhere on the network (in a way understood both by the UA and the CDS) the same array of datas.

Before going into the gory binary details, let's categorize what can goes from/to User Applications and CDS. ARINC 661 messages are composed of several binary blocks juxtaposed together called run-time commands (for UA to CDS communication) or Request/Notifications (from CDS to UA communication).

From UA to CDS:

  • A661_CMD_SET_PARAMETER: This is the basic command to change the value of one parameter of one widget in the widgets tree (for example, in the my Hello World tutorial, we would be able to change the color of the A661_LABEL widget, or it's text content, etc...).

  • A661_CMD_UA_REQUEST: A request from UA to CDS, about a Layer in general (for example activate or inactivate a layer, or render the Layer visible if it was not visible before)


From CDS to UA:

  • A661_NOTIFY_WIDGET_EVENT: To notify the UA that a user event has occurred on a widget

  • A661_NOTIFY_LAYER_EVENT: To notify the UA that an event has occurred on a Layer

  • A661_NOTIFY_EXCEPTION: To notify the UA of any exception occurring for the CDS



Do you want more? More on this in a few days, it's a promise!!

Sunday 23 May 2010

I Hate Mountains will soon be your nightmare

Yes, from the creators of Portal Prelude, this very ambitious campaign will be available in one week now.

Now it took ages for them to create this campaign (which should be awesome by the way). The team leader explained blog after blog how much Valve screwed developers.

hmm.

If you want my point of view (and even if you don't want it, it's my blog, so I do as I please), they were VERY ambitious, and they asked for mod interfaces Valve would never have thought about. I bet they had problems. To quote some of their rants (about Valve):

  • "On Portal prelude: We are aware that there is some problems running the game with the free version of Portal on Windows but there's nothing we can do. Do yourself a favor and ask Valve instead, because it's their entire fault. basically there seems to be a problem on the free version of Portal Valve distributed since some days, and their mod is not working anymore since then". So, Valve give Portal for free since one week, and they bash them because since then, their mod is not working anymore?

  • "Oh great, the release of The Passing broke our intro camera because they thought it would be funny to modify L4D1 animations. This is great.". And so? They should not modify anything so your still not released work should work?

  • "What the fuck is wrong with this game, where the hell is my drawer? ": And you never thought you could have make a mistake, my friend? Once in your life?

  • "I don't see where you've seen that there's not so many companies who share their tools with the general public. Today, most (if not all) of the major companies share their tools with the general public as a
    business move. Google, Twitter, Facebook, Epic Games, Paypal, eBay, Amazon, Microsoft, Salesforce, etc. I worked with the tools of all these companies, and the vast majority was top notch, perfectly working, fully documented and behaving as expected
    ". Really? Every time I use Microsoft development tools and APIs, I have to rely to internet forums to make it work well. Unfortunately, a lot of people have the same problems as me.. Google Android API is still a bit under-documented (to say the least). Due to the fact it has a long history, Win32 is really a mess. MFC architecture makes it really VERY difficult to use, and totally cryptic (nothing's logical there). XUL is very poorly documented. This list can goes on an on, and some of these libraries are not free. Basically, if you want to use an API (especially if you don't have access to the sources), you should be prepared to some problems. That's how life's goes on. But that does not make them unusable.

  • "This is an horrible process that involves the terrible Faceposer tool."


Now about non-valve things

  • "FluxBB creators obviously know nothing about creating easily skinnable style sheets"

  • "Dammit, the Twitter plugin on our website isn't updating anymore. What did I do wrong this time? Boy, Wordpress seems so unstable."


That did not prevent them to use the free audio Valve gave them (as for other mappers) for their campaign, like for example "I Hate Mountains".

You get the big picture. And don't say I'm not knowing anything about software development, I've done and I'm still doing a lot, using all kinds of libraries.

So, OK, Valve's SDK could be better documented (still there's the Valve Developer Community, which is free, contrary to MSDN (and don't say that MSDN is clear, it's also a mess, and it cost a lot). But I bet that a lot of people who have problems with the Source SDK won't write in the wiki.

However, enough with this. While I don't like very much the attitude of some of the I Hate Mountains team, I'm sure they are very good at mapping, and that their campaign will be great. They just need to learn a little more humility sometimes.

Monday 17 May 2010

On google docs

We see a lot of buzz about google docs everywhere on the web these days. There's even a well-known blogger on zdnet writing that Open Office is Dead, because google docs web applications work so well.

Well I have tried to use google docs very recently, and the results were so bad that I will not go back:

  • Compatibility of google docs with Office format is abysmal. It just does not work at all, even for very simple documents. Converting a short and very simple Word document in google docs took ages, and the resulting document lost a lot of markers and tags. Converting back the same document to word did not work at all. The resulting document could even not be opened in the last Word version. End of story. It seems that google docs lives in it's own little world, but it really is not enough for an office suite

  • On the other hand, conversion from and to MS Office format work very well in open Office, even for huge and very complex documents. I lately had problems with a huge Word document at work which took ages to work with in Word (even Word 2007). I opened it on Open Office at home, lost nothing (same document), worked on it without problems, and then converted it back to Word. Again I lost nothing and all worked very well

  • I don't see the point in needing to have constant internet access to work on a document



Seems that google still has a lot of work to do to have a competing Office suite. But they also seem to work on too many things at the same time.

Sunday 14 February 2010

ExoPC: a real PC tablet?

There is a lot of buzz nowadays about exoPC, a future tablet PC which will be available on March according to their developers. Of course, this tablet benefited from a LOT of buzz on the web, because it was announced just after the iPad. It is announced at the same price as the iPad 32 Go, is powered on Windows 7, is capable of USB connectivity, and is also base on a multitouch technology.

Whaow great!!

hmm, let's look at it a little more closely:

  • Autonomy: 4 hours vs 10 hours for the iPad, 4 hours is not a lot, but it's understandable, as it uses Windows 7, an admittedly good OS, but not designed for mobile usage. Battery life for Windows 7 is even reportedly not very good, probably because it is designed to use "costly" services such as Aero, and relies originally on DirectX 9 for graphics on regular PC usage

  • Weight: 820g vs 680 g for the equivalent iPad model

  • Thickness: 2.1 cm vs 1.3 cm for the iPad. I understand that, because the use of Windows 7 makes them need to have a ventilator on-board!!!

  • Power: Processor is 1.6 Ghz vs 1 Ghz for iPad, but the absence of a GPU (integrated Intel graphics on-board, probably to reduce price and avoid further reduction of battery life from 4 hours to 1 hours only) is a very bad news for multimedia usage, which is the primary usage for this type of product. Comparisons on the same 3D games between Nexus One and iPhone 3GS were interesting because they showed that despite Nexus One having a more powerful CPU (1 GHz vs 600 Mhz), iPhone was more than twice faster than Nexus One in all configurations.

  • Multitouch: hmm, multitouch development is not finished yet for exoPC. What? less than one month before the product is available? By the way, even if it can optionally handle touch screens, Windows 7 is not known to be the king of touch screens or even multitouch technology



Now for non technological impressions:

  • First it seems that all the demos that were shown were sent to blogs and Internet news sites directly by the designers themselves. Does not seem very neutral. And you will never see any journalist using the tablet anywhere on the web

  • The company which develop and will distribute exoPC is a Canadian company (Quebec). Great, but it's president is a car dealer (!!!)

  • When questioned about references for the exoPC company, Jean-Baptiste Martinoli, the man at the origin of the product, gives the name of mioplanet, another small Canadian company. He says: "it enjoys a significant technological heritage including the structure Mioplanet, another company of Rimouski, a very discreet company that delivered innovative solutions worldwide for clients such as HP or Microsoft for nearly 10 years". Problem is that the president of Mioplanet his... himself. This kind of auto-referencing is something which makes me very cautious. And no names for other companies which could be business partners for exoPC has ever been produced

  • The product is said by the designer to be presented at CeBIT next month ("Next month, Microsoft will present our product at CeBIT in Germany, one of the largest hi-tech fairs in Europe. And it will do the same during a major speech (keynote) next month in Tokyo"). However, if you search for exoPC on the CeBIT web site, you return nothing...



I bet that this product does not really exist my friends.