Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2011-07

instantfpc has moved

7 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Alexander Klenin
to Mattias Gaertner
Mattias Gaertner wrote 6 lines
See here http://wiki.freepascal.org/InstantFPC From wiki: Changes to the compiler or installed units are not checked. If you install a new compiler you should clean the cache (e.g. delete the directory ~/.cache/instantfpc).

Perhaps it is obvious to you, but I'd propose to store the source hash instead of source itself,
and include compiler version in said hash. It will not solve unit dependency issue,
but still would be an improvement IMHO.

Alexander S. Klenin

Reply by email

Mattias Gaertner
to Alexander Klenin
Show quoted text 14 lines
On Sat, Jul 9, 2011 at 19:56, Mattias Gaertner wrote: > See here > http://wiki.freepascal.org/InstantFPC >From wiki: >Changes to the compiler or installed units are not checked. >If you install a new compiler you should clean the cache (e.g. delete the directory ~/.cache/instantfpc). Perhaps it is obvious to you, but I'd propose to store the source hash instead of source itself, and include compiler version in said hash. It will not solve unit dependency issue, but still would be an improvement IMHO.

If you know a fast check for the compiler version, feel free to implement it. Otherwise this should be optional.

Mattias

Reply by email

Alexander Klenin
to Mattias Gaertner
Mattias Gaertner wrote 9 lines
> Perhaps it is obvious to you, but I'd propose to store the source hash > instead of source itself, > and include compiler version in said hash. It will not solve unit > dependency issue, > but still would be an improvement IMHO. If you know a fast check for the compiler version, feel free to implement it. Otherwise this should be optional.

Is fpc -v too slow?

Alexander S. Klenin

Reply by email

Mattias Gaertner
to Alexander Klenin
Show quoted text 13 lines
On Sun, Jul 10, 2011 at 18:56, Mattias Gaertner wrote: >> Perhaps it is obvious to you, but I'd propose to store the source hash >> instead of source itself, >> and include compiler version in said hash. It will not solve unit >> dependency issue, >> but still would be an improvement IMHO. > > If you know a fast check for the compiler version, feel free to > implement it. Otherwise this should be optional. > Is fpc -v too slow?

yes

I guess you mean fpc -iW

It starts two executables, fpc and ppccpu, so it increases the time of running a simple program more than twice plus it needs more memory. On a normal Linux system this is ok, so it can be done by default.
There should be a parameter and an environment variable to disable this check.
Michael VC already suggested to add support for a config file.

Mattias

Reply by email

Michael Van Canneyt
to Mattias Gaertner
Mattias Gaertner wrote 25 lines
On Sun, 10 Jul 2011 19:04:37 +1100 Alexander Klenin wrote: > On Sun, Jul 10, 2011 at 18:56, Mattias Gaertner > wrote: >>> Perhaps it is obvious to you, but I'd propose to store the source hash >>> instead of source itself, >>> and include compiler version in said hash. It will not solve unit >>> dependency issue, >>> but still would be an improvement IMHO. >> >> If you know a fast check for the compiler version, feel free to >> implement it. Otherwise this should be optional. >> > > Is fpc -v too slow? yes I guess you mean fpc -iW It starts two executables, fpc and ppccpu, so it increases the time of running a simple program more than twice plus it needs more memory. On a normal Linux system this is ok, so it can be done by default.

You must be joking ?

I don't think this is a good idea.

One of the things I liked about instantfpc is that it is fast in case the script already was compiled.

If storing the hash to make comparison faster means that you must start 2 extra executables, it makes the end result slower, which voids the purpose of the whole hashing operation. (aka it is not very clever)

You can do the hashing in-memory, but I doubt this will give a noticeable speedup. The loading time of an executable dwarfs the comparison operation, especially for small scripts.

And if the purpose is to do dependency checking, I don't see why you would want this:

a) if the program has changed, it will be recompiled anyway.

b) if some of the installed units have actually changed behaviour which you think will influence one of your already-compiled scripts, you'll know about it and can clear the cache manually once.
in case their behaviour has not changed, there is no point in recompiling them.

Very little gain for such an invasive change.

So: please don't do this change.

What could be useful is a command-line option to clear the cache for you.

Michael.

Reply by email

Mattias Gaertner
to Michael Van Canneyt
Show quoted text 31 lines
On Sun, 10 Jul 2011, Mattias Gaertner wrote: > On Sun, 10 Jul 2011 19:04:37 +1100 > Alexander Klenin wrote: > >> On Sun, Jul 10, 2011 at 18:56, Mattias Gaertner >> wrote: >>>> Perhaps it is obvious to you, but I'd propose to store the source hash >>>> instead of source itself, >>>> and include compiler version in said hash. It will not solve unit >>>> dependency issue, >>>> but still would be an improvement IMHO. >>> >>> If you know a fast check for the compiler version, feel free to >>> implement it. Otherwise this should be optional. >>> >> >> Is fpc -v too slow? > > yes > > I guess you mean fpc -iW > > It starts two executables, fpc and ppccpu, so it increases > the time of running a simple program more than twice plus it needs > more memory. On a normal Linux system this is ok, so it can be done by > default. You must be joking ?

A bit. I was testing for reactions.

I don't think this is a good idea.

No, not even the IDE uses the above.

One of the things I liked about instantfpc is that it is fast in case the script already was compiled.

:)

Show quoted text 20 lines
If storing the hash to make comparison faster means that you must start 2 extra executables, it makes the end result slower, which voids the purpose of the whole hashing operation. (aka it is not very clever) You can do the hashing in-memory, but I doubt this will give a noticeable speedup. The loading time of an executable dwarfs the comparison operation, especially for small scripts. And if the purpose is to do dependency checking, I don't see why you would want this: a) if the program has changed, it will be recompiled anyway. b) if some of the installed units have actually changed behaviour which you think will influence one of your already-compiled scripts, you'll know about it and can clear the cache manually once. in case their behaviour has not changed, there is no point in recompiling them. Very little gain for such an invasive change. So: please don't do this change.

There is a better way:
Store file age of fpc and ppccpu.

What could be useful is a command-line option to clear the cache for you.

+1

Mattias

Reply by email