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.
Thursday, November 26, 2015
Thursday, November 19, 2015
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.
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.
Wednesday, November 11, 2015
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.
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.
Thursday, November 5, 2015
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.
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.
Subscribe to:
Posts (Atom)