Sunday, 9 January 2011

Mr Courmont, do you really need to do this?

Mr Remi Courmont, contributor to the VLC media player, thinks that he knows that Apple removed the Mobile VLC app from the appstore because they supposedly "cannot stand software distributed under the GPL on its stores". Mr Remi Courmont think he knows that the AppStore license expressly makes it impossible to distribute GPL software on the AppStore. Mr Courmont thinks that he knows a lot, but he seems to know very little, except of course for his own apparent hate of Apple.

Mr Remi Courmont wanted the app to be removed to prove his point, even if some of his fellow developers thought a little different than himself. His comment on the twitter feed for the VIDEOLAN project was: "I'm not going to pity the owner of iDevices, and not even the mobileVLC developers who doubtless wasted a lot of their time".

Mr Courmont, you seems to be full of it, you know. Asking is something, but spreading FUD without really knowing anything about what you are speaking, and putting a gun on the neck of Apple, but also other VLC developers, and also those who developed the mobileVLC app, is not a very pretty thing to do.

But above all, Mr Courmont can't deny he is working for Nokia. Do you really think that he can convince that it had no impact on what he did?

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!!