Taoffi's blog

prisonniers du temps

Object Visibility and learning cycle… just a vision of

In everyday work, we come through new tools or new versions of tools we knew before.

The cycle of playing with and manipulating these tools’ objects to attain a reasonable level of mastering… is often daunting!

To minimize the learning cycle of tools, some helpful features have been introduced: like documentation, tooltips… etc.

Documentation is of course important, but, for me, tooltips are much more helpful. They just appear when I need them in the context of using the object or the property.

The thing is: when you manipulate an object for the first time, you really know few things about its composition and, even less, about its role in the global mechanics of the tool in question. You just know it is there, and it should be there for some reason and that you should spend some time to understand: its role, its structure, and finally how can it be useful for you (if at all it could be!)

One way to shorten this learning cycle is to let others show you how to use the tool and its object. Quite useful, but, on one hand, this occults some side of self-experience (important)… and also negatively interferes in your critical view of the tool (which is often useful for the tool’s enhancement itself)

What we do to know about (most) simple toys seems more rational: You just set something on or off (left/right or up/down…)… then put the toy on work and see... after some cycles you end up by figuring out what is the ‘best’ position for your needs (or mood!).

Another representation, which may also give an interesting slant related to this subject, is the DeepZoom technology used in maps applications where you can first see the whole world map, and then, zooming-in on the map you get more details about a given country, city, streets, buildings… etc.

A good path for reducing the time and effort needed to learn a subject or a tool would be:

  • To be able to see (explore) the global image of the subject or tool’s structure in action;
  • Be able to zoom-in on its objects and see their properties (progressively detailed according to your zoom level);
  • Be able to change the value of a give object’ property… and perceive the impact of the change on the global behavior.

This proposed path cannot of course be applied in all situations or contexts, but can be useful in many (most) cases.

We may, for instance, need to create a simulation context inside which we can ‘run’ the specific tool or object. An approach which may also be useful for product tests and benchmarking.

Some interesting works have been done on some aspects (like The Property Grid project)… More is to be done on the visualization of objects and properties by zoom level. Will try to write a sample on this in a future post.


Learning from Nature: Towards a Nucleotidic modeling - part II

Two days ago, my friend Olivier Vallée sent me an article (nytimes) talking about the emerging role of software tools in reducing costs of lawyers’ work by analyzing documents contents. This reminded me the work we did, Olivier and I, some years ago around the use of a nucleotidic approach for analyzing textual data.


So, here again to continue the subject of the earlier post!


In part I, I presented a first view of the analogies between molecular biology elements and other real world problematic. And a probable benefit of using molecular biology’s structures and be behaviors to in data modeling and software solutions architecture.

In this part, I will try to expose a simple and direct application of this approach: language modeling and analysis. There are several advantages for starting with textual analysis as a first application:

·         First, a textual object structure can easily, and somehow directly, be mapped to molecular biology elements (nucleotides, DNA strands, amino acids…);

·         Second, the textual analysis is becoming (re-becoming!) a must know (and probably lucrative as well J) technology  (see nytimes article);

Let us first try to analyze the physical (organic) structure of a textual object:

·         Characters;

·         Composing Words;

·         Composing phrases;

·         Composing paragraphs;

·         … etc;


This same physical structure can be interpreted according to other (different / parallel) logical  components:

·         Symbols (óCharacters);

·         Composing phonemes (ówords);

·         Composing expressions;

·         Composing sense (social / intellectual orientation (or mood) of the text)


Again, this parallel presentation of a same object (encountered in so many data modeling problematics) is one of the important analogies with molecular biology elements (i.e. similar, for example, to nucleotide sequences mapping to amino acids).

To illustrate another aspect of this analogy, let us take a look at the characters / words ó characters / phonemes parallel. To correctly read a phoneme, we need to locate its start-end characters. Which may overlap or be part of the ‘Words’ sequence of our text. In some way, we need to retrieve the reading frame (or phasing) of a sequence of phonemes through our nucleotidic characters structure. This phasing is independent of the characters/words sequence presentation. Which, again, brings to our mind the question of reading frames of an amino acid sequence contained in a nucleotidic sequence.


In the case of our text sequence question, characters, words, phonemes… etc. are, of course, language-dependent. However, for sake of simplicity, let us stay in the context of the English language.


Let us now take an example of how we can read a ‘mood’ sequence inside a physical text sequence (characters, words…) sequence.

The mood (social sense) of a text can be detected through the interpretation (or translation) of specific (predefined) expressions sequence(s).

For example:

“That’s great” can be interpreted differently from “hey… fantastic”

Or “Hello”, differently from “Hi”…

Or “L” differently from “J

… etc.


Social expression of a text sequence is also, in some way, related to its internal phoneme sequence. Text phonemes actually produce a sequence of sounds that give a particular internal ‘music’ to the text. Which participates, in the end, in transmitting the specific social sense of the initial text sequence. That is probably an important aspect of poetry (?)


I will provide a practical coded example in a future post.

Throw, but only ‘exceptional’ exceptions!

I find the Try/Catch mechanism fascinating! This is probably due to some events I lived in the (not so far) History! (see below)

The thing is, when I see any of its related keywords: try, catch, finally and, specially, throw… I feel some kind of nervousness or unease!

Unfortunately, for me, more and more source code tries, catches and throws exceptions. It seems sometimes easier to throw an exception while simply an object ‘status’ would be required.

Some history

I remember an intriguing piece of code (2 or 3 C language macros) that was one of the first research I encountered about implementing a dynamic error capturing (now called ‘exception handling’). I kept this code for years (in my ‘code-museum’!) but ended up by losing it through the long journey of OS, compilers and IDEs changes!

Fortunately, I found someone (Francesco Nidito) who still (beautifully) talks about this nearly same macros (you can have a more detailed look here). His article is exactly about the solution that I first saw in the 80s, with some interesting additions (mixed with a good dose of humorJ).


If you used C language before, you know the impact (and importance) of ‘preprocessing’. This is the step where the compiler expands the expressions before going further in the compilation process.

For example, if you define a macro:


#define SAY_HELLO   int    x;\

                    for( x = 0; x < 10; x++)\



In the preprocessing step, the compiler will replace each SAY_HELLO occurrence by the lines of code above.


longjmp And setjmp

Before diving in the historical macros, to better understand their work, we should first have a look at those two (strange) C language functions: longjmp and setjmp (declared in setjmp.h header file):


int setjmp(jmp_buf env);

void longjmp(jmp_buf env, int val);


The documentation says:


The setjmp function saves a stack environment, which you can subsequently restore, using longjmp. When used together, setjmp and longjmp provide a way to execute a non-local goto. They are typically used to pass execution control to error-handling or recovery code in a previously called routine without using the normal calling or return conventions.

A call to setjmp saves the current stack environment in env. A subsequent call to longjmp restores the saved environment and returns control to the point just after the corresponding setjmp call. All variables (except register variables) accessible to the routine receiving control contain the values they had when longjmp was called.

It is not possible to use setjmp to jump from native to managed code.

Note   setjmp and longjmp do not support C++ object semantics. In C++ programs, use the C++ exception-handling mechanism.

The basic Try/Catch macros

Using the magic that can be done by setjmp and longjmp, the following bizarre macros are the basis of a try/catch mechanism:


#define TRY            do{ jmp_buf ex_buf__; if( !setjmp(ex_buf__) ){

#define CATCH          } else {

#define ETRY           } }     while(0)

#define THROW          longjmp(ex_buf__, 1)


So, now you may write




       DoSomething(“with this string”);




       printf(“some error happened!”);


ETRY         /* end of try/catch! */


At compile-time, this would be expanded to the following code:


do{ jmp_buf ex_buf__; if( !setjmp(ex_buf__) ){


       DoSomething(“with this string”);


} else {


       printf(“some error happened!”);


} }   while(0)           /* end of try/catch! */



What does it mean?

Let’s try to read the macros meaning:

TRY, ends with an ETRY. That is do{ xxxx } while(0) (which means: do xxxx only ONCE)

TRY starts by saving the current caller’s stack into a ‘jmp_buf’ variable. If saving the current caller stack succeeds, the next instructions (code block of ‘try’) are executed. Otherwise, the catch block instructions are executed instead.

THROW executes a non-local GOTO (by calling longjmp) which returns execution to the previous caller of the stack saved into the jmp_buf with a return value of 1 (of course, longjmp can be called with a different return value).


Anything new?

Of course, our C++, C# and VB Try/Catch mechanism is a little more elaborate than the one exposed here. The foundations remain the same. And, in fact, nothing had fundamentally changed in this area since: any try/catch block executes, at least, this fearful acrobatic setjmp / longjmp.


It may be useful to remember this before writing your next try/catch block!