[Lazarus] I desperately need some ideas of reducing edit, compile, debug cycle

[Martin]

On 27/11/2010 11:01, Frank Church wrote:
>
>
> On 26 November 2010 20:55, Martin <lazarus at mfriebe.de 
> <mailto:lazarus at mfriebe.de>> wrote:
>
>     On 26/11/2010 19:56, Frank Church wrote:
>
>
>         One thing that has always gottem to me when using Delphi and
>         now Lazarus is the tedious edit, compile, debug cycle. It has
>         been growing worse of late that now I am beginning to dread
>         the whole process any time I have to make some changes,
>         especially when they are just minor GUI changes.
>
>     ....
>
>
>         Quite simply I am thinking of a way to create the application
>         in parts, so that the parts containing the new functionality
>         can be developed separately as standalone programs, perhaps
>         even console programs.
>
>         This raises the question of how procedure parameters and
>         results can be passed, and these are the options that have
>         initially come to mind.
>
>         1. Find a way to automatically translate simple variables,
>         record structures, or objects into text and pass them via the
>         command line or pipes. Perhaps JSON, XML or simple name-value
>         pairs can be used here. Designing the parameters as
>         TPersistent objects that are streamed into text form may be a
>         better option here.
>
>         2. Rather than using the command line, make them network
>         services and pass the parameters that way, or may make them
>         RESTful/XML-RPC  with all the new webby stuff( I am getting
>         into some of that stuff now)
>
>         3. Design them as DLLs initially - I suspect that will bring
>         along a different set of problems.
>
>         Once they are well tested I can incorporate them into the main
>         executables.
>
>
>     Yes splitting your project into parts is a good idea. Quite simple
>     use packages.
>
>     Then you still have one application, you still can pass data
>     around in the normal pascal way.
>
>     Each package can be tested with a small simple runner application,
>     or even better a fully automated testcase.
>     Testcase are especially useful, if you can extract the functional
>     layer from the visual layer.
>
>     So instead of writing something big into
>     TForm.SaveDocumentButtonClick, you just have "TheDocument.Save" in
>     there
>      => all functionality goes into a none visual object TheDocument
>     (or whatever it is in your case).
>     - this object takes instruction, if the user clicks something
>     - it can be asked what to display.
>     - it can be given callbacks, if it requires to notify the visual
>     layer.
>      for example it can have "OnTitleChange" => which is linked to a
>     method changing the forms Caption (Title)
>     ....
>
>     Martin
>
>
>     --
>
>
>
> Thanks for the reply, Martin.
>
> Are there some code examples which use this approach, especially the 
> package based one?

I don't know of any examples, but I guess there must be.
It's the same as what Michael Van Canneyt said: "separate the business 
and gui logic". (you can google this phrase)

In the simplest case:
create a new class (in it's own package) that reflects your form, that 
has a method for every method that currently exists in your form. Then 
move all the code (and remove all reference to the form itself). All 
values are transferred to begin with, all actions applied at the end, or 
by callback.
Of course such a separation will have much better results if you 
refactor the code more than just copy it in a new class.

>
> Will it also reduce the size of the debugging exe or speed up its 
> creation?

The Size stays the same, therefore also the speed.
But that doesn't matter, because you will create this exe far less 
often. (could be up to 90% less often)

Let me give you an example. I work on SynEdit.

If I changed something then in order to test it I had to rebuild SynEdit 
and the IDE. And as you know you need to test often before everything 
works fine. So I had to rebuild very very often, that has a big impact.
SynEdit already was a package. So I was spared the step of creating one.

I created a test case though. It's still very small, but it helps. If I 
change something, I run t in the testcase. So all I do is rebuild the 
package SynEdit (that will only rebuild the files I changed, so I 
compile 3 or 4 files on average). And compile the testcase. that is a 
very small and simple application, and is done very very fast too.

I could have just thrown a SynEdit on an empty form and compile this. 
That would be as fast as the testcase. Then I could try out every 
feature by hand.
But as the amount of features grow (and as each can break on every 
change), I would have to test more and more scenarios. Doing so by hand 
is increasingly time consuming.

The testcase does it fully automated. It does not only test the new 
feature, it alerts me if I break another one.

The GUI itself, the visual interaction, te mouseclick, and canvas 
drawing, are things that are hard to test in automated testcase 
(possible but harder).

But what I test, is that the data on which all those actions are done, 
is correctly calculated, and provided. And that reduces the amount of 
work I have to do on those GUI/frontend code.

>
> Sometimes I see only one file compiled, then it goes to the linking 
> phase, but it doesn't seem to reduce the exe size or the speed of its 
> creation.

See above. the size of the final exe and the compilation time for that 
does not matter.

If I change SynEdit, I use the testcase. I may have to recompile th 3 or 
4 units affected by my change several dozend times, and rebuild the 
testcase (another handful units that are recompiled). But thats about  
one dozend unts, and one small test app. The big IDE I build maybe 2 or 
3 times, wher as without the testcase I would have build it several 
dozen times.

The trick is to find code that can be tested easily, and to extract it 
into it's on package, and classes.

Martin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20101127/f0dc37b7/attachment-0003.html>