Friday, December 18, 2015

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?

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.

Thursday, November 26, 2015

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.

Thursday, November 19, 2015

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.

Thursday, November 5, 2015

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.

Thursday, October 29, 2015

Enters Travis CI. This useful tool reminded me that integration tests are not enough. I had broken my unit tests. Not good!

OK, let's fix that. I thought it would be fast. It was not (indeed, it is not over).

I needed to work quite a lot this week. Eiffel allows "expanded classes"; that is, value object classes. That is very useful but almost as easily testable as singletons.

I kept those classes… as simple façades. The release code automatically wires the façade with its underlying implementation. The test code, on the other hand, allows to set a test implementation; in other words, a mock.

My last words are for Eiffel afficionados, based on my freshest experience.

I had lost the idea that Liberty Eiffel's insert keyword (equivalent to ECMA's ugly inherit {NONE}), brought a whole interface to the class. Not what I wanted.

So, my advice: you should not insert a class if you don’t want to
expose its features in your interface. Use an attribute instead. Using export {} is an alternate
solution, albeit not pretty because you'd need to also insert ANY to keep valid export clauses for standard features.

Wednesday, September 9, 2015

This blog entry is not really structured. I write it at the same time that I read and modify Gate's source to introduce the channels (see my previous entry).

While working on Gate's code, I found an interesting thing.
The whole client-server communication is centralized on the "server" side, which implements… The server itself, of course, but also a "proxy" that is able to talk with it.

Great! It means that extracting the communication protocol itself will only involve changes in the server package. No shotgun surgery in the whole project.

The currently implemented protocol is go's RPC client, which works via HTTP. Not a bad choice; but I really would like to propose at least one alternate implementation, using ZMQ.

So the first thing is: move the current implementation out of the server implementation (which should concentrate on just implementing server stuff, not protocol), and out of its proxy implementation.

Well… the role of the proxy is only to send things to the server; but I like the symmetry, similar to ISO's stack: one layer talks to its counterpart at the same level. Hence, the server talks with its proxy, and each one should contain a "channel" object; each channel object should be able to talk to another channel object.

Thursday, September 3, 2015

I needed to read again Gate's code to see how much Pwd diverged from it. Remember: Gate was a Pwd port, written some time ago, but not really maintained; whereas Pwd continued to evolve.

The most striking differences are:

Pwd supports named pipes and low-level sockets as client-server channels. (There was also a ZMQ attempt, not finished.) On the other hand, Gate only supports RPC on HTTP. I need to extract the "channels" behaviour, maybe with another naming since "channel" is a native Go concept. Then, I may want to implement a ZMQ "channel".

Pwd started to support a web interface, never finished. Gate could use one, too — but only if I intend to finish it (i.e. not now).

Otherwise, the porting was quite fidel to the original. Maybe too much; the server start and synchronization method uses the same kind of algorithm: start the server process, and try to open a socket until it answers and abort if it takes too long. Not pretty! That's why I want to use ZMQ instead: it should better hide those gory details.

It is written in Go, and I need to update my skill in that language, because I am interested in knowing more than one OO language and culture.

Eiffel, and especially Liberty Eiffel, is as good as dead. I still dream of reviving it — although I love the language, I am afraid that won't happen; in the last few years, nobody has taken time to build the needed community (me included, mea maxima culpa).

I need a more solid design, and I intend to rewrite Gate with that aim in mind

I need to write blog posts and that is a good opportunity :-)

So, if you are interested in some language learning and some (useful) software building… Stay tuned.

JSON is well and good, but it has one shortcoming: the management of object references. When you have to serialize an object graph, with object cycles, JSON is lost.

My client needed to serialize such a graph. So I wrote a JSON extension, dubbed "JSON/R" (JSON with references).

I wanted the parser to stay as pretty as the standard JSON's (see a previous article), with the same property: a parser with no backtrack.

I added two concepts: "heap" and "reference".

A "heap" is just an array with different brackets (< and >); its usage is that the objects in it are "referenced" by their position in the array. By convention, the root object of the graph is the first one, in other words, $0.

A "reference" is an index into the heap: noted $<integer>.

I should write a free parser too. The concept is basic enough to be quite useful.

Dictionaries ("objects" in JSON parlance), which simply are bunches of values indexed by string keys.

That's all. And that's enough.

I fell in love with JSON a few years ago. The reasons are both functional and technical.

Functionally, JSON is the result of what XML failed to be: a simple data exchange format with a straightforward ecosystem (no DTD, schema, validation, tools over layers and layers of tools and libraries), no frivolities (e.g. no data vs. attribute wars).

Technically, the JSON parser is also very simple. Its grammar is a straightforward descending grammar with no rollbacks. It means that at each point in the JSON text, given the past and current letter, you know exactly what may follow. If it fails: syntax error, out.

Since I love that format I had to build my own parser library: YacJP. That library allows to read and write JSON data using any kind of UTF-8 character streams, including simple C strings, file descriptors, and POSIX files.

It was the first of a few projects that followed in the same "object-like" style.

Monday, March 2, 2015

That tool helps filter standard Linux logs. Since I have my own (small) server, I need that kind of tool.

My server is really small: a Cubieboard, with a Debian distro. It has an internet façade so I must at least cursolily read its logs. That's, hem, tedious. I am not at ease with the admin side of machines.

Back to the topic: Cubieboard is good, but it is not fast. Petit is written in Python; I needed something faster. So I wrote ExP, a Petit clone in plain C.

Well, "plain" is not really accurate. I am an object hacker deep inside. My C code is written in a modular fashion with a lot of encapsulation (static functions) and interfaces (structs with functions).

I find that way of programming usually enough to implement a basic OO design; the remaining of the object paradigm is usually useful in very few cases. When I need that, I switch to Eiffel, but most people won't follow there. Oh, well...