Fanfare!

Ladies and gentleman,

Let the Ringmaster introduce his new soon-to-be famous Circus!

Circus is the successor of pwd; but it is written in C. I want to use standard and proven technologies!

It is very new for the moment. The code is being built, don't hesitate to come and participate. Red nose mandatory!

Happy new year!

Down from the tower.

OK. That's one time too many. Or even, quite too many times too many.

My beloved Eiffel compiler is really not production ready. It is the right tool to test ideas, but it is too brittle. The compiler was a very good one 15 years ago; but it did not evolve and is now quite behind the times.

Hacking on that compiler cannot stay a priority anymore. Let's face it, I am not up to the challenge. I feel like Atlas, trying to carry the thing on my frail shoulders.

Each time I try to make pwd evolve, I need to fix the compiler, or some standard library.

That needs far too much work and my patience is quite over.

I need my password manager. And I need it now. I want to use the man power I own (i.e. one our two hours per day, max) to make the best password manager ever. And no, I don't want to use a standard one, at least because it is the software I want to completely control.

So I will start anew.

My needs:

• Using standard technologies, so that others can contribute. I will use the lingua franca of free software: C.
• Using as many standard libraries as possible.
• Using an event-driven model, because I want to avoid threading issues. Not decided yet: zmq, libuv?
• Whenever relevant, build reusable libraries. That begins with libcad and yacjp.
• Good security, especially cryptography-wise. I still want to be able to exchange passwords between my server and a web client. I need layers of security above https which is the bare minimum.

I also need a name. Ideas are welcome :-)

I think I will not write again in this blog before next year. So merry Christmas to all, have a good time with your loved ones, and happy hacking!

PS– That does not mean that I completely forsake Liberty; I will gladly help people whenever such help is wanted. But hey! Judging from the current mail flow, it should not take a lot of my time. And that's an understatement.

Key properties

Hard times seem to be behind. Cross fingers.

Now that pwd works with a new format (JSON), I can start to implement a few enhancements I wanted to do.

The first is a bunch of key "properties": attach extra information to each key. For the moment, three properties are implemented: username, url, and tags.

I am quite proud of the tags system. It was really missing. It will help segregate keys on user criteria.

This is not yet over. I need more work on accessing and changing the key properties in the console and maybe the menu clients, and in the webclient.

MOre happy hacking to come.

Bug in the compiler.

JSON is ready in pwd. It should work. It will work.

Liberty Eiffel has a bug in the implementation of a quite brand new feature: the keyword "then" can now be used at the end of a function definition to assign an expression to Result, to be returned to the function caller. It helps writing short functions.

See Eiffel as an expression language.

The management of this expression is buggy; I am fixing it.

More next week.

Garbage collection

In Liberty Eiffel, when using the SmartEiffel garbage collector, a last collection is performed just before exit.

The standard Liberty Eiffel library uses the "dispose" method of disposable objects for contract checking; in particular, to check that resources that should be closed are closed.

Looks good? Yeah.

Except.

Now with mocks, contracts have to be checked too. But the latest garbage collection happens out of any scenario. It happens, well… Later; when the program is about to exit, when the test program has checked that every method that should have been called was indeed called, and so on. The test is over, we may safely exit.

And then, comes the GC, that calls dispose, that checks contracts, that calls… mocked methods! Weren't we finished?

As you can imagine, that does not end well. When not guided by a scenario, mocks don't know how to properly answer to a query.

Only one solution then: when using mock objects, that last GC should not happen, and that is that. After all, the SmartEiffel GC is the only GC I know that performs a GC on exit. BDW does not allow it.

So now the Liberty Eiffel mock framework disables the GC on exit.

Lo and behold, after almost a month, pwd tests pass again!

Happy coding indeed.

Design by Contract

Design by Contract is a fundamental aspect of the Eiffel language.

Methods have pre- and post-conditions; classes have invariants. Those contracts are checked even for heir classes.

This has a very important impact: mocks have contracts too.

Contract checking may be partially or completely removed; this way, Liberty Eiffel is able to generate executables with very high performance.

But when testing, one wants to check all modes. With, and without contracts.

So the tests must be properly equipped. That's what I learned this week: when using mocks in Eiffel, don't forget to bring answers to contract methods.

Mocks

This week is about mocks.

A few years ago I wrote a "mocker" tool for Liberty Eiffel.

In the case of pwd I need to mock actual classes from the library, where deferred methods (i.e. abstract features) are defined in one or more parent classes, with some implemented at different levels of the tree, and so on.

The "mocker" tool, with its simplistic approach (purely syntactical), was not up to the task.

So be it: I needed to write a new tool. One that could handle the whole semantics of an Eiffel class.

Liberty Eiffel already has similar tools; in particular, the "short" tool allows to display the complete interface of a class.

Lo and behold, the mock tool, now based on the Liberty Eiffel engine. It took me the whole week to write it.

But now that it works, I can come back to pwd and further my webclient tests.

The target is still acquired. Stay tuned.