Sign in Join

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

Mailing lists / lazarus / 2017-12

CHM help package (Marco van de Voort)

9 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

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

Sergey Bodrov
Show quoted text 10 lines
On Fri, Dec 08, 2017 at 03:23:06PM +0300, Sergey Bodrov via Lazarus wrote: > There is too many changes in many files, and that can't be posted as simple > diff patch. Then layer them. Make patches for the most essential bits, and then reallign your sources.

I change code formatting, many private names, add many comments and embrace whole blocks of code into try..finally. And now can't tell, which parts is most essential.

Show quoted text 10 lines
> 1. FPC package 'chm' contain file fasthtmlparser.pas, that used in some > non-CHM packages and projects. May be better move that file to some generic > package - fcl-base, for example? Afaik this was meant as a copy of that parser dedicated for chm that could evolve with the package. So if you need it more general, whip up a suitable general version.

It's just fast and simple SAX-like tags parser, no more. It not rely on any external libs/units and not dedicated to CHM.

Show quoted text 11 lines
> 2. FPC package 'chm' contain LZX compression routines in some files > - paslzx.pas, paslzxcomp.pas, paslznonslide.pas, lzxcompressthread.pas. > They not depends on other files in 'chm' and can be maintained as separate > package. What does that make possible that currently is not possible? Do we really have to spin each unit into a separate package? I don't see the point. Note also that iirc CHM lzx and e.g. CAB lzx vary in some ways. (headers?)

LZX in CHM use non-sliding window, separated to 64K blocks for fast random access. It implemented in separate file - paslznonslide.pas

But even bypassing that, what is the problem of having to instal 10 extra units (150kb) to make a CAB decompressor?

Naming and linking problems.

*Bodrov Sergey* software development, IT consulting http://www.serbod.com *Phone (Belarus):* +375(25)794-21-58 *Skype:* sergey.bodrov1 *e-mail:* , -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171210/d6849e29/attachment.html>

Reply by email

Marco van de Voort
to Sergey Bodrov
Sergey Bodrov wrote
I change code formatting, many private names, add many comments and embrace whole blocks of code into try..finally. And now can't tell, which parts is most essential.

Yes. Somebody will have to figure that mess out, preferably by somebody who has some recollection about what he has done. It is always a bad idea to do big style related operations mixing it with real fixes. Now you know why :-)

And when I had a quick peak, I scanned two whole files, and didn't find any fixes except adding "const" to some parameters, and some 2.6.x era unicode fixes that used Lazarus units, and thus can't be merged into FPC repo anyway. (using lazconvencoding or something like that).

So that would need to be cleaned up using FPC 3.0 string support first.

Show quoted text 13 lines
> > 1. FPC package 'chm' contain file fasthtmlparser.pas, that used in some > > non-CHM packages and projects. May be better move that file to some > generic > > package - fcl-base, for example? > > Afaik this was meant as a copy of that parser dedicated for chm that could > evolve with the package. So if you need it more general, whip up a > suitable > general version. > It's just fast and simple SAX-like tags parser, no more. It not rely on any external libs/units and not dedicated to CHM.

I looked again, and it is indeed very simple.

Show quoted text 14 lines
> What does that make possible that currently is not possible? Do we really > have to spin each unit into a separate package? I don't see the point. > > Note also that iirc CHM lzx and e.g. CAB lzx vary in some ways. (headers?) > LZX in CHM use non-sliding window, separated to 64K blocks for fast random access. It implemented in separate file - paslznonslide.pas > But even bypassing that, what is the problem of having to instal 10 extra > units (150kb) to make a CAB decompressor? Naming and linking problems.

The units have no name with chm in them, so I see no naming issues and FPC in general does not employ static libraries or so for linking purposes.

Reply by email

Sergey Bodrov
to Marco van de Voort

2017-12-11 16:14 GMT+03:00 Marco van de Voort via Lazarus <

Show quoted text 16 lines
: On Sun, Dec 10, 2017 at 01:25:59PM +0300, Sergey Bodrov via Lazarus wrote: > > I change code formatting, many private names, add many comments and embrace > whole blocks of code into try..finally. And now can't tell, which parts is > most essential. Yes. Somebody will have to figure that mess out, preferably by somebody who has some recollection about what he has done. It is always a bad idea to do big style related operations mixing it with real fixes. Now you know why :-)

Problem is that I first change code formatting just to make it readable, and then do fixes. Most fixes was impossible without reformatting.

Show quoted text 5 lines
And when I had a quick peak, I scanned two whole files, and didn't find any fixes except adding "const" to some parameters, and some 2.6.x era unicode fixes that used Lazarus units, and thus can't be merged into FPC repo anyway. (using lazconvencoding or something like that).

Hmm, don't remember, that I doing addiction of new includes to 'chm' units. And encoding-related operations was made in LHelp project, after HTML content readed from CHM file, but before it passed to IPro HTML viewer.

There was some compiler warnings about WideString -> AnsiString conversion, that I eliminate with UTF8Encode() from RTL

Maybe you mention file lcid_conv.pas, which contain MS Locale ID to Windows Codepage conversion and common for LHelp and chmmaker projects? Yes, chm package is a wrong place for it. I don't know, where is better place.

So that would need to be cleaned up using FPC 3.0 string support first.

What is better way to convert WideString to AnsiString without warnings?

Show quoted text 5 lines
Naming and linking problems. The units have no name with chm in them, so I see no naming issues and FPC in general does not employ static libraries or so for linking purposes.

And if that unit names will be same in different packages?

Also, is chm is really needed and used in FPC, without Lasarus?

*Bodrov Sergey* software development, IT consulting http://www.serbod.com *Phone (Belarus):* +375(25)794-21-58 *Skype:* sergey.bodrov1 *e-mail:* , -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171211/fc35349b/attachment.html>

Reply by email

Marco van de Voort
to Sergey Bodrov
Sergey Bodrov wrote 6 lines
> big style related operations mixing it with real fixes. Now you know why > :-) > Problem is that I first change code formatting just to make it readable, and then do fixes. Most fixes was impossible without reformatting.

If you kept it apart in your VCS, maybe you can backport the fixes then.

But it is nearly impossible to remerge reformatted sources, the number of changes suddenly is in the hundreds instead of the signle digits.

Show quoted text 8 lines
Maybe you mention file lcid_conv.pas, which contain MS Locale ID to Windows Codepage conversion and common for LHelp and chmmaker projects? Yes, chm package is a wrong place for it. I don't know, where is better place. > So that would need to be cleaned up using FPC 3.0 string support first. > What is better way to convert WideString to AnsiString without warnings?

There is no way without surpressing warnings locally or use an RTL function that surpresses warnings.

But either way, the current way is wrong, even if it surpresses warnings. The encoding of ansistring is fully runtime defined in 3.0, and code should respect that as much as possible, while your code just assumes utf8.

Show quoted text 7 lines
> Naming and linking problems. > > The units have no name with chm in them, so I see no naming issues and FPC > in general does not employ static libraries or so for linking purposes. > And if that unit names will be same in different packages?

You don't need to have them in a different package. You can just use the units from package CHM without any downsides. Package CHM only depends on other packages that are pure pascal, so it won't pull in dependencies.

If something major comes up, this can be revisited, but I don't see a point to fragment packages ad infinitum on principle grounds only.

Also, is chm is really needed and used in FPC, without Lasarus?

The textmode IDE also uses CHM, as do various chm file generators like fpdoc and chmcmd.

Reply by email

Sven Barth
to Sergey Bodrov: 2017-12-11 16:14 GMT+03:00 Marco van de Voort via Lazarus < Problem is that I first…

Am 11.12.2017 15:15 schrieb "Sergey Bodrov via Lazarus" <

:

2017-12-11 16:14 GMT+03:00 Marco van de Voort via Lazarus <

Show quoted text 16 lines
: On Sun, Dec 10, 2017 at 01:25:59PM +0300, Sergey Bodrov via Lazarus wrote: > > I change code formatting, many private names, add many comments and embrace > whole blocks of code into try..finally. And now can't tell, which parts is > most essential. Yes. Somebody will have to figure that mess out, preferably by somebody who has some recollection about what he has done. It is always a bad idea to do big style related operations mixing it with real fixes. Now you know why :-)

Problem is that I first change code formatting just to make it readable, and then do fixes. Most fixes was impossible without reformatting.

In projects like Lazarus and Free Pascal it's "when in Rome, do as the Romans do" regarding formatting. So don't change formatting only because *you* can't work with it. And I highly doubt that the possibility of fixes depends on the formatting...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171211/b28121bd/attachment.html>

Reply by email

Sergey Bodrov
to Sven Barth

2017-12-11 19:18 GMT+03:00 Sven Barth via Lazarus <

:

Problem is that I first change code formatting just to make it readable,

Show quoted text 8 lines
and then do fixes. Most fixes was impossible without reformatting. In projects like Lazarus and Free Pascal it's "when in Rome, do as the Romans do" regarding formatting. So don't change formatting only because *you* can't work with it. And I highly doubt that the possibility of fixes depends on the formatting...

http://wiki.freepascal.org/Coding_style - "There are no formal standards" for FCL and other packages distributed with FPC. So I use Lazarus and Embarcadero coding guides.

I will do whole work again as Romans want if Romans pay me.

*Bodrov Sergey* software development, IT consulting http://www.serbod.com *Phone (Belarus):* +375(25)794-21-58 *Skype:* sergey.bodrov1 *e-mail:* , -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171212/dda330e4/attachment.html>

Reply by email

Sven Barth
to Sergey Bodrov

Am 12.12.2017 09:07 schrieb "Sergey Bodrov via Lazarus" <

:

2017-12-11 19:18 GMT+03:00 Sven Barth via Lazarus <

:

Problem is that I first change code formatting just to make it readable,

Show quoted text 8 lines
and then do fixes. Most fixes was impossible without reformatting. In projects like Lazarus and Free Pascal it's "when in Rome, do as the Romans do" regarding formatting. So don't change formatting only because *you* can't work with it. And I highly doubt that the possibility of fixes depends on the formatting...

http://wiki.freepascal.org/Coding_style - "There are no formal standards" for FCL and other packages distributed with FPC. So I use Lazarus and Embarcadero coding guides.

No formal standard does not mean that you can change code formatting as you want.
The modus operandi is to adhere to the formatting of the surrounding code.

I will do whole work again as Romans want if Romans pay me.

Patches with formatting changes are very likely to be rejected in code that belongs to the FPC project (can't speak about Lazarus here) and for the compiler itself it is even nearly assured.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171212/0b66defc/attachment.html>

Reply by email

Marco van de Voort
to Sven Barth
Sven Barth wrote 9 lines
want. The modus operandi is to adhere to the formatting of the surrounding code. I will do whole work again as Romans want if Romans pay me. Patches with formatting changes are very likely to be rejected in code that belongs to the FPC project (can't speak about Lazarus here) and for the compiler itself it is even nearly assured.

I guess it is the same as with FPC, if there is hope on some nugget and the mess is not too bad, then somebody might trawl through it. But the files I examined had hundreds of formatting hunks and very minimal and obvious changes/fixes.

Reply by email