Hello everybody.

I just discovered ptop.
Well done Michael!

Thanks to ptop, I was able to make the code of uos.pas (+- 10.000 lines) more beautiful.
Congratulation Michael, ptop can deal with the lot of {$IF DEFINED(something)} of my code.

I was not able to do it with Jedi, who refused my code.

So, once again, wow.

Now about configuration of ptop;

Is it possible to format code with comma?

For example, format this:

Uses
unit1,unit2,unit3

to get that (a space added after comma)

Uses
unit1, unit2, unit3

Jedi does it, maybe ptop does it too?

Thanks.

Fre;D

-----
Many thanks ;-)

fredvs wrote

Hello everybody. I just discovered ptop. Well done Michael!

I just ported and extended an old system.

Not currently, ptop needs to be extended for that. It should be relatively easily possible, because colon, period and so on are also treated specially. if "," is recognized, a 'spaft' option will do what you want.

Michael.

It should be relatively easily possible, because colon, period and so on

are also treated specially.

if "," is recognized, a 'spaft' option will do what you want.

Ha, ok, I will explore this.

Thanks.

Fre;D

-----
Many thanks ;-)

Hello Michael.

I have added in ptopu.pp "comma" keyword and option[t,comma]^.selected :=
[spaft];

Works like charm.

Included patched ptopu.pp
ptopu.zip
<http://free-pascal-general.1045716.n5.nabble.com/file/t339155/ptopu.zip>

Fre;D

-----
Many thanks ;-)

ehm...

This patch changes a lot more than just adding comma ?

The diff is quite big, and it's not whitespace changes...

Is that intentional, or if not, where did you get the original ptopu.pp ?

Michael.

The diff is quite big, and it's not whitespace changes... is that intentional, or if not, where did you get the original ptopu.pp

It comes from source of fpc 3.0.4.

Hum, so big?

To add a "comma" keyword,

1) Insert comma in keysymbol array.
2) Add "comma" in EntryNames.
3) Add option[t,comma]^.dindsym := ...] in procedure SetDefaultIndents.
4) Add option[t,comma]^.selected := [spaft] in Procedure SetDefaults.

So, not so much.

By the way, there is a little memory leak in original fpc 3.0.4 ptop:

Heap dump by heaptrc unit of /home/fred/ptop/ptop
31 memory blocks allocated : 2383/2424
30 memory blocks freed : 2175/2216
1 unfreed memory blocks : 208
True heap size : 393216
True free heap : 392800
Should be : 392816
Call trace for block $00007FFFF7F8A100 size 208

And this one is very well hidden, I dont see anything in ptop.pp and ptopu.pp that could do it.
Maybe from a used units?

Fre;D

-----
Many thanks ;-)

Re-hello.

In the previous zip file there is the ptopu.pp file (not ptop.pp that I did not touch).

Fre;D

-----
Many thanks ;-)

Well, there have been changes in trunk. I obviously did a diff with the trunk version, so probably that is the cause.

No worries. If it is from 3.O.4, I will make a diff from that version. I will check the memory leak.

Thanks for the effort !

Michael.

Well, there have been changes in trunk. I obviously did a diff with the trunk version, so probably that is the cause.

Ha, nice, I will study this asap.

Other thing, I did many search on internet to have the same as ptop: simple command line program-executable but for Java.
Sadly this does not exist, only plugin for tenors like Eclipse, etc all Java applets of course.

So why not a Jtop pure fpc, without any dependencies?

;)

Good night Michael.

Fre;D

-----
Many thanks ;-)

Hello everybody and especially Michael.

OK, I did find the very well hidden memory leak.

In ptop.pp it comes from Procedure TPToP.DoRun, line 140 --->  Usage(1);

And in the procedure Usage(), the last line produces the memory leak.

Procedure TPToP.Usage(ECode : Word);
begin
  Writeln ('ptop : Usage : ');
  Writeln ('ptop [-v] [-i indent] [-b bufsize ][-c optsfile][-l linesize]
infile outfile');
  Writeln ('     converts infile to outfile.');
  Writeln ('     -c : read options from optsfile');
  Writeln ('     -i : Set number of indent spaces.');
  Writeln ('     -l : Set maximum output linesize.');
  Writeln ('     -b : Use buffers of size bufsize');
  Writeln ('     -v : be verbose');
  writeln ('ptop -g ofile');
  writeln ('     generate default options file');
  Writeln ('ptop -h : This help');
  halt(Ecode); //////////// ------> This produces a memory leak
end;

So the big question is: What is the purpose of "halt(Ecode)" and would it be a crime to remove it?

Thanks.

Fre;D

-----
Many thanks ;-)

Hello.

OK, I opted for changing in procedure Tjtop.Usage(ECode: word);
  halt(Ecode); //------> This produces a memory leak

with

 terminate; // ------> No nore memory leak.

There is a Github site forked from original ptop.
It include ptop with extended comma feature.

Also was added jtop, a beautifier for Java based on ptop.

https://github.com/fredvs/xtop

Fre;D

-----
Many thanks ;-)

On 2020-02-23 15:26, fredvs via fpc-pascal wrote:

Hi,

This makes no sense from my point of view. Halt finishes execution of the program. At that point, all memory previously allocated to that program should be returned to the operating system (at least standard operating systems do so), thus the leak may make no difference. The difference between your version and the original one is that the original finishes the program with some error code thus allowing some error checking in case the program was called from some script, etc., whereas your version finishes with a result of 0 even if the processing encountered some errors.

Tomas

Hello Tomas and thanks for the infos.

Hum, ok, so I give you the hand to find why the original code finishes the program with some memory leak.

Fre;D

-----
Many thanks ;-)

Tomas Hajny-2 wrote

No, I dont think so, all error code are still there. Even more, if the user dont use a filename as parameter, help-messages are displayed.

And also I dont see what it could have to do with the memory leak.

Anyway, ptop is a great program.

Sorry for the noise.

Fre;D

-----
Many thanks ;-)

fredvs via fpc-pascal schrieb am Mo., 24.
Feb. 2020, 02:10:

You are wrong. Halt() sets the error code provided as parameter. Terminate by itself does not.

And also I dont see what it could have to do with the memory leak.

Terminate leads to the destructor being called while Halt exists the program in a hard way. But as Tomas wrote, when a program terminates all memory is returned to the OS so that is not really a problem.

Regards,
Sven

AM Sven Barth wrote

You are wrong. Halt() sets the error code provided as parameter. Terminate by itself does not. Terminate leads to the destructor being called while Halt exists the program in a hard way. But as Tomas wrote, when a program terminates all memory is returned to the OS so that is not really a problem.

If you really dislike the memory leak (since it's not "nice programming"), maybe you can set ExitCode before calling terminate? (Untested idea (TM))

If you really dislike the memory leak (since it's not "nice programming"), maybe you can set ExitCode before calling terminate? (Untested idea (TM))

Hello Bart.

Thanks for that constructive and respectful answer that gives solution.

Indeed, I **really** dont like programs that generate memory leak and all the bla-bla that try to to convince me that it is not important, that the OS will remove it, ... etc dont work on me.

I will test your idea.

Thanks.

Fre;D

-----
Many thanks ;-)

Hello Bart.

OK, I did try your idea, changing the original code with this (see 2 last lines):

procedure TPToP.Usage(ECode: word);
begin
  writeLn('ptop : Usage : ');
  writeLn('ptop [-v] [-i indent] [-b bufsize ][-c optsfile][-l linesize]
infile outfile');
  writeLn('     converts infile to outfile.');
  writeLn('     -c : read options from optsfile');
  writeLn('     -i : Set number of indent spaces.');
  writeLn('     -l : Set maximum output linesize.');
  writeLn('     -b : Use buffers of size bufsize');
  writeLn('     -v : be verbose');
  writeLn('ptop -g ofile');
  writeLn('     generate default options file');
  writeLn('ptop -h : This help');
  ExitCode := ECode; // this change instead of halt(ECode);
  Terminate;               // this change instead of halt(ECode);
end;

Is it what you are thinking?
Indeed, no more memory leak and error preserved with this.

Heap dump by heaptrc unit of ptop
29 memory blocks allocated : 2242/2280
29 memory blocks freed : 2242/2280
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072

Fre;D

-----
Many thanks ;-)