Re: [Lazarus] CHM help package
2017-12-11 21:34 GMT+03:00 Werner Pamler via Lazarus < lazarus@lists.lazarus-ide.org>: > > And Sergey, you should explain which features are new? What do I have to > do to see the new features in lhelp? - 'Copy raw souce' in page context menu. - full-text search works properly - RPC calls from Lazarus handled instantly - codepage conversions (not anywhere, it still need testing) - maybe some features related to multiple opened CHM files now works - global topics list, context search many missed features from http://wiki.freepascal.org/chm related to HTML Viewer. -- *Bodrov Sergey* software development, IT consulting http://www.serbod.com *Phone (Belarus):* +375(25)794-21-58 *Skype:* sergey.bodrov1 *e-mail:* ser...@gmail.com, oxot...@yandex.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package
2017-12-11 21:57 GMT+03:00 Werner Pamler via Lazarus < lazarus@lists.lazarus-ide.org>: > Am 11.12.2017 um 18:32 schrieb Werner Pamler via Lazarus: > >> I cloned your repo on my HD, and went through it step by step while >> always trying to build lhelp, I could remove everything from the folder chm >> except for these units: chmfifimain, chmreader, chmsitemap, chmtypes (and >> chmobjinstance.inc). I think it is possible to extract the essential >> changes from these units to get at least the new reading functionality. I >> can try this - but: before beginning I'd like to get positive feedback from >> fpc devs that this will be merged (I have some old patches hanging around >> there, and it is not always motivating to submit fpc patches). >> > There is no special new reading functionality, only bugfixes and code improvements. I spend many hours just to understand how it works and how it must work properly. It's not trivial without proper documentation. > As for the unit lcid_conv: This fits into Lazarus' LazUtils, and should go >> there independently of how this story ends here. I have commit rights to >> Lazarus and can put it there. Any objections? >> > I don't know, where is better place for such file. Locale ID is MS Windows specific, so maybe it better place to some windows - related unit or LazUtils? > Sergey, I loaded a chm having codepage iso-8859-1 into your modified > lhelp. It crashes in TIpChmDataProvider.DetectHtmlCodepage when trying to > convert the string 88591 to a Word. Also, this codepage (as well as the > other iso's) are not considered in lclid_conv. iso-8859-1 encoding have not relation to MS Locale ID. It HTML-specific, and must handled by HTML viewer. I do dirty hack with HTML codepage coversion just because don't ready to make fixes in TIpHtmlPanel. -- *Bodrov Sergey* software development, IT consulting http://www.serbod.com *Phone (Belarus):* +375(25)794-21-58 *Skype:* sergey.bodrov1 *e-mail:* ser...@gmail.com, oxot...@yandex.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] "Character" -> "Codepoint" in LazUTF8 function names
On 2017-12-11 20:11, Juha Manninen via Lazarus wrote: I changed "Character" to "Codepoint" in some LazUTF8 function names in r56692. Please take a look. "Codepoint" is more accurate and hopefully reduces confusion. I haven't looked at the code changes, but fully agree with the sentiment. Getting the terminology correct is already a great leap forward in the right direction. Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package
On Mon, Dec 11, 2017 at 10:27:33PM +0100, Werner Pamler via Lazarus wrote: > And chmfifimain seems to have a memory leak in "destructor > TChmSearchWriter.Destroy;" which does not call "inherited" -- see > attached patch. > Index: chm/src/chmfiftimain.pas > === > --- chm/src/chmfiftimain.pas (revision 37715) > +++ chm/src/chmfiftimain.pas (working copy) > @@ -392,6 +392,7 @@ > > begin > freeandnil(FActiveLeafNode); > + inherited; > end; Done. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package
Am 11.12.2017 um 20:53 schrieb Marco van de Voort via Lazarus: On Mon, Dec 11, 2017 at 06:32:45PM +0100, Werner Pamler via Lazarus wrote: I cloned your repo on my HD, and went through it step by step while always trying to build lhelp, I could remove everything from the folder chm except for these units: chmfifimain, chmreader, chmsitemap, chmtypes (and chmobjinstance.inc). I walked through chmreader, and found one minor fix, a comparison of a filename parameter with an extension should be lowercase. Fixed in r37714 And chmfifimain seems to have a memory leak in "destructor TChmSearchWriter.Destroy;" which does not call "inherited" -- see attached patch. Index: chm/src/chmfiftimain.pas === --- chm/src/chmfiftimain.pas(revision 37715) +++ chm/src/chmfiftimain.pas(working copy) @@ -392,6 +392,7 @@ begin freeandnil(FActiveLeafNode); + inherited; end; -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Highlight matching brackets
On Mon, Dec 11, 2017 at 10:13 PM, Martin Frb via Lazarus wrote: > Just checked, Contextmenu > Find > Rename Identifier > It now is enabled, if you are at the end of the identifier. > But it is disabled, if you are at the start of the identifier. > So both parts of the commit are wrong. Yes. I reverted it in r56695. The change is already in 1.8 so I will mark this one to be merged to fixes_1_8. Maybe Dmitry D. Chernov is reading. We need a better patch. ... or maybe Martin can say right away how to fix it. I have no time to debug it now. In r56366 I fixed a similar issue in codetools when cursor is in uses section, at the end of a unit name. For the sake of symmetry it would be nice to have this fixed, too. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Highlight matching brackets
On 11/12/2017 20:05, Martin Frb via Lazarus wrote:
It should only change CaretAtIdentOrString, but I am failing to see
how that works (did not debug, just looked at it, so I might be wrong)
In the line |=caret
a:=foo|(
It would have seen the "(", and returned false.
But with the patch, I would expect
a:=|foo(
to see the ":=" ?
So it just reverses the issue?
Just checked, Contextmenu > Find > Rename Identifier
It now is enabled, if you are at the end of the identifier.
But it is disabled, if you are at the start of the identifier.
So both parts of the commit are wrong.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] "Character" -> "Codepoint" in LazUTF8 function names
I changed "Character" to "Codepoint" in some LazUTF8 function names in r56692. Please take a look. "Codepoint" is more accurate and hopefully reduces confusion. It was discussed in forum and I agree with the importance of using correct terms. http://forum.lazarus.freepascal.org/index.php/topic,39045.msg268541.html#msg268541 With Unicode the term "Character" is very ambiguous. Existing code that uses those functions now throws "deprecated" warnings. Sorry for the inconvenience. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Highlight matching brackets
On 11/12/2017 19:49, Juha Manninen via Lazarus wrote:
On Mon, Dec 11, 2017 at 9:34 PM, Martin Frb via Lazarus
wrote:
Most likely (not verified)
Revision: 56398
Message:
SynEdit: Enable operations for an identifier also when caret is at its end.
Patch from Dmitry D. Chernov.
Ah, that is reported already.
https://bugs.freepascal.org/view.php?id=32803
There were 2 identical block changed. Maybe only one of them should be changed.
I try to look at it soon ...
Juha
the change in GetHighlighterAttriAtRowColEx is wrong.
It should only change CaretAtIdentOrString, but I am failing to see how
that works (did not debug, just looked at it, so I might be wrong)
In the line |=caret
a:=foo|(
It would have seen the "(", and returned false.
But with the patch, I would expect
a:=|foo(
to see the ":=" ?
So it just reverses the issue?
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package
On Mon, Dec 11, 2017 at 06:32:45PM +0100, Werner Pamler via Lazarus wrote: > I cloned your repo on my HD, and went through it step by step while > always trying to build lhelp, I could remove everything from the folder > chm except for these units: chmfifimain, chmreader, chmsitemap, chmtypes > (and chmobjinstance.inc). I walked through chmreader, and found one minor fix, a comparison of a filename parameter with an extension should be lowercase. Fixed in r37714 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Highlight matching brackets
On Mon, Dec 11, 2017 at 9:34 PM, Martin Frb via Lazarus wrote: > Most likely (not verified) > Revision: 56398 > Message: > SynEdit: Enable operations for an identifier also when caret is at its end. > Patch from Dmitry D. Chernov. Ah, that is reported already. https://bugs.freepascal.org/view.php?id=32803 There were 2 identical block changed. Maybe only one of them should be changed. I try to look at it soon ... Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Highlight matching brackets
On 11/12/2017 19:28, john landmesser via Lazarus wrote:
issue occured after:
Lazarus 1.9.0 r56216M FPC 3.0.2 x86_64-linux-gtk2
Am 11.12.17 um 20:04 schrieb Vojtěch Čihák via Lazarus:
I can confirm. It is also broken for [] and {}. I observed that it
depends on previous character:
Most likely (not verified)
Revision: 56398
Message:
SynEdit: Enable operations for an identifier also when caret is at its
end. Patch from Dmitry D. Chernov.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Highlight matching brackets
issue occured after:
Lazarus 1.9.0 r56216M FPC 3.0.2 x86_64-linux-gtk2
Am 11.12.17 um 20:04 schrieb Vojtěch Čihák via Lazarus:
I can confirm. It is also broken for [] and {}. I observed that it
depends on previous character:
ControlStyle:=ControlStyle+[csNoDesignVisible]; //works
ControlStyle:=ControlStyle+ [csNoDesignVisible]; //does NOT work
i.e. when previous char is "red" +-*/@() etc. it works, while
abcde...ABCDE... or *space* doesn't. Also with UTF chars it doesn't
work (ěščřžýáí)
V.
__
> Od: John Landmesser via Lazarus
> Komu: Lazarus@lists.lazarus-ide.org
> Datum: 11.12.2017 19:33
> Předmět: [Lazarus] Highlight matching brackets
>
i think there is something wrong?!
Lazarus svn
Lazarus 1.9.0 r56691M FPC 3.0.4 x86_64-linux-gtk2
should highlight Brackets as () but it highlights single quotes '
that happens for WinXP too!
sceenshot of settings (right) and IDE (left)
.. could not send the sreenshot, it's over 100 kb!!
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Highlight matching brackets
I can confirm. It is also broken for [] and {}. I observed that it depends on
previous character:
ControlStyle:=ControlStyle+[csNoDesignVisible]; //works
ControlStyle:=ControlStyle+ [csNoDesignVisible]; //does NOT work
i.e. when previous char is "red" +-*/@() etc. it works, while abcde...ABCDE...
or *space* doesn't. Also with UTF chars it doesn't work (ěščřžýáí)
V.
__
Od: John Landmesser via Lazarus
Komu: Lazarus@lists.lazarus-ide.org
Datum: 11.12.2017 19:33
Předmět: [Lazarus] Highlight matching brackets
i think there is something wrong?!
Lazarus svn
Lazarus 1.9.0 r56691M FPC 3.0.4 x86_64-linux-gtk2
should highlight Brackets as () but it highlights single quotes '
that happens for WinXP too!
sceenshot of settings (right) and IDE (left)
.. could not send the sreenshot, it's over 100 kb!!
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package
Am 11.12.2017 um 18:32 schrieb Werner Pamler via Lazarus: I cloned your repo on my HD, and went through it step by step while always trying to build lhelp, I could remove everything from the folder chm except for these units: chmfifimain, chmreader, chmsitemap, chmtypes (and chmobjinstance.inc). I think it is possible to extract the essential changes from these units to get at least the new reading functionality. I can try this - but: before beginning I'd like to get positive feedback from fpc devs that this will be merged (I have some old patches hanging around there, and it is not always motivating to submit fpc patches). As for the unit lcid_conv: This fits into Lazarus' LazUtils, and should go there independently of how this story ends here. I have commit rights to Lazarus and can put it there. Any objections? Sergey, I loaded a chm having codepage iso-8859-1 into your modified lhelp. It crashes in TIpChmDataProvider.DetectHtmlCodepage when trying to convert the string 88591 to a Word. Also, this codepage (as well as the other iso's) are not considered in lclid_conv. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package
Am 11.12.2017 um 18:32 schrieb Werner Pamler via Lazarus: I think it is possible to extract the essential changes from these units to get at least the new reading functionality. I can try this [,.,] And Sergey, you should explain which features are new? What do I have to do to see the new features in lhelp? -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Highlight matching brackets
i think there is something wrong?! Lazarus svn Lazarus 1.9.0 r56691M FPC 3.0.4 x86_64-linux-gtk2 should highlight Brackets as () but it highlights single quotes ' that happens for WinXP too! sceenshot of settings (right) and IDE (left) .. could not send the sreenshot, it's over 100 kb!! -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package
I cloned your repo on my HD, and went through it step by step while always trying to build lhelp, I could remove everything from the folder chm except for these units: chmfifimain, chmreader, chmsitemap, chmtypes (and chmobjinstance.inc). I think it is possible to extract the essential changes from these units to get at least the new reading functionality. I can try this - but: before beginning I'd like to get positive feedback from fpc devs that this will be merged (I have some old patches hanging around there, and it is not always motivating to submit fpc patches). As for the unit lcid_conv: This fits into Lazarus' LazUtils, and should go there independently of how this story ends here. I have commit rights to Lazarus and can put it there. Any objections? -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package (Marco van de Voort)
Am 11.12.2017 15:15 schrieb "Sergey Bodrov via Lazarus" < lazarus@lists.lazarus-ide.org>: 2017-12-11 16:14 GMT+03:00 Marco van de Voort via Lazarus < lazarus@lists.lazarus-ide.org>: > 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release 1.8
El 11/12/17 a les 16:14, Michael Van Canneyt ha escrit:
On Mon, 11 Dec 2017, Luca Olivetti wrote:
El 11/12/17 a les 13:43, Michael Van Canneyt ha escrit:
[*] I don't know if freeing a thread in OnTerminate is allowed. FPC
documentation here
https://www.freepascal.org/docs-html/rtl/classes/tthread.onterminate.html
says nothing about it, but
the example here (mentioned in the bug report)
http://docwiki.embarcadero.com/CodeExamples/Tokyo/en/TThreadYield_(Delphi)
seems to imply that it should.
It is definitely not allowed in FPC, and I will document it as such.
Ouch, that's not delphi compatible then (unless the example is flawed).
In any case it's better to be not compatible and clearly documented
than vaguely documented and maybe (just maybe) compatible (i.e. I
don't really care about delphi compatibility since I don't use it, but
sometimes you have to rely on delphi examples/documentation).
The following is clearly nonsense:
FThread.FreeOnTerminate := False; // Free FThread in the OnTerminate
proc. This will set Terminated to true
Terminated is already True in OnTerminate.
So I think the example is flawed.
From the TThread implementation:
if (FThreadID = GetCurrentThreadID) then
begin
if not(FFreeOnTerminate) and not FFinished then
raise EThreadDestroyCalled.Create('A thread cannot destroy
itself except by setting FreeOnTerminate and leaving!');
I think we cannot be more clear than that :)
Not really: OnTerminate is called in the context of the main thread, so
FThreadId is different than GetCurrentThreadId.
Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release 1.8
On Mon, 11 Dec 2017, Luca Olivetti wrote:
El 11/12/17 a les 13:43, Michael Van Canneyt ha escrit:
[*] I don't know if freeing a thread in OnTerminate is allowed. FPC
documentation here
https://www.freepascal.org/docs-html/rtl/classes/tthread.onterminate.html
says nothing about it, but
the example here (mentioned in the bug report)
http://docwiki.embarcadero.com/CodeExamples/Tokyo/en/TThreadYield_(Delphi)
seems to imply that it should.
It is definitely not allowed in FPC, and I will document it as such.
Ouch, that's not delphi compatible then (unless the example is flawed).
In any case it's better to be not compatible and clearly documented than
vaguely documented and maybe (just maybe) compatible (i.e. I don't really
care about delphi compatibility since I don't use it, but sometimes you have
to rely on delphi examples/documentation).
The following is clearly nonsense:
FThread.FreeOnTerminate := False; // Free FThread in the OnTerminate proc.
This will set Terminated to true
Terminated is already True in OnTerminate.
So I think the example is flawed.
From the TThread implementation:
if (FThreadID = GetCurrentThreadID) then
begin
if not(FFreeOnTerminate) and not FFinished then
raise EThreadDestroyCalled.Create('A thread cannot destroy itself
except by setting FreeOnTerminate and leaving!');
I think we cannot be more clear than that :)
Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release 1.8
El 11/12/17 a les 13:43, Michael Van Canneyt ha escrit: [*] I don't know if freeing a thread in OnTerminate is allowed. FPC documentation here https://www.freepascal.org/docs-html/rtl/classes/tthread.onterminate.html says nothing about it, but the example here (mentioned in the bug report) http://docwiki.embarcadero.com/CodeExamples/Tokyo/en/TThreadYield_(Delphi) seems to imply that it should. It is definitely not allowed in FPC, and I will document it as such. Ouch, that's not delphi compatible then (unless the example is flawed). In any case it's better to be not compatible and clearly documented than vaguely documented and maybe (just maybe) compatible (i.e. I don't really care about delphi compatibility since I don't use it, but sometimes you have to rely on delphi examples/documentation). Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package (Marco van de Voort)
On Mon, Dec 11, 2017 at 05:15:36PM +0300, Sergey Bodrov via Lazarus wrote: > > 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. > 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. > > 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package (Marco van de Voort)
2017-12-11 16:14 GMT+03:00 Marco van de Voort via Lazarus < lazarus@lists.lazarus-ide.org>: > 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. > 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? > 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:* ser...@gmail.com, oxot...@yandex.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package (Marco van de Voort)
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 :-) 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. > > > 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. > > 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CHM help package
On Sat, Dec 09, 2017 at 06:54:42PM +, Graeme Geldenhuys via Lazarus wrote: > On 2017-12-09 17:33, Marco van de Voort via Lazarus wrote: > > yada,yada,yada git plug > > Oh just fuck off Marco! Not everything I say is meant to piss you off > or even directed at you. Please add me to your email ignore list and be > done with it. Or,... you could be a bit more selective to what you reply to. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release 1.8
On Mon, 11 Dec 2017, Luca Olivetti via Lazarus wrote: El 09/12/17 a les 11:57, Luca Olivetti via Lazarus ha escrit: I know I'll have to upgrade to fpc 3 someday, but what worries me about it is my (and other 3rd party units) use of ansistrings as binary buffers. I did some quick tests some time ago an nothing seemed broken, but I'm somewhat reluctant since my software has to run unattended 24/7 (or more like 24/5). I've done some tests with 3.0.4 and it turns out I'm bitten by the extensive changes in tthread: freeing a thread in its OnTerminate[*] randomly (i.e. not every time) produces a sigsev (under win32). With 2.6.4 it didn't happen (though freeing a thread in OnTerminate had another problem undes Linux, see https://bugs.freepascal.org/view.php?id=32759) [*] I don't know if freeing a thread in OnTerminate is allowed. FPC documentation here https://www.freepascal.org/docs-html/rtl/classes/tthread.onterminate.html says nothing about it, but the example here (mentioned in the bug report) http://docwiki.embarcadero.com/CodeExamples/Tokyo/en/TThreadYield_(Delphi) seems to imply that it should. It is definitely not allowed in FPC, and I will document it as such. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release 1.8
El 09/12/17 a les 11:57, Luca Olivetti via Lazarus ha escrit: I know I'll have to upgrade to fpc 3 someday, but what worries me about it is my (and other 3rd party units) use of ansistrings as binary buffers. I did some quick tests some time ago an nothing seemed broken, but I'm somewhat reluctant since my software has to run unattended 24/7 (or more like 24/5). I've done some tests with 3.0.4 and it turns out I'm bitten by the extensive changes in tthread: freeing a thread in its OnTerminate[*] randomly (i.e. not every time) produces a sigsev (under win32). With 2.6.4 it didn't happen (though freeing a thread in OnTerminate had another problem undes Linux, see https://bugs.freepascal.org/view.php?id=32759) [*] I don't know if freeing a thread in OnTerminate is allowed. FPC documentation here https://www.freepascal.org/docs-html/rtl/classes/tthread.onterminate.html says nothing about it, but the example here (mentioned in the bug report) http://docwiki.embarcadero.com/CodeExamples/Tokyo/en/TThreadYield_(Delphi) seems to imply that it should. For the time being I'm using FreeOnTerminate:=true and avoid freeing the thread in OnTerminate (though there are other changes required to my code and "fixing" working code is always an issue). I checked the user changes pages for 3.0.0, 3.0.2 and 3.0.4 and there's no mention of changes in threads (the only one is this one http://wiki.freepascal.org/User_Changes_3.0#cthreads:_critical_sections_and_recursive_mutex_support and doesn't apply here). Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] issue with %RunCommand
Hello, in Lazarus 1.6.2 I was using the following line to run qemu when I
trigger "Run":
{%RunCommand qemu-system-x86_64.exe -m 512 -smp 2 -drive
format=raw,file=ToroHello.img}
However, I am not getting the same behavior in Lazarus 1.8, instead, qemu
is opened in background so I am not able to see the windows.
Am I doing something wrong?
Matias
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Note to new high-DPI icons
Am 10.12.2017 um 11:39 schrieb Werner Pamler via Lazarus: I contacted Ally and asked him to modify these icons. Done in r56689 (incl the TToggleBox). Still not perfectly visible on black background, but visible at least... If you want the text brighter you should create your own png icons (the svg sources are on ccr/image_sources), overwrite the existing ones in (lazarus)/images/components, recreate the res file by executing the corresponding script in (lazarus)/images and rebuild the IDE. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Note to new high-DPI icons
Am 11.12.2017 um 07:39 schrieb Sergey Bodrov via Lazarus: But can icons for TButton and TToggleBox be more visually different? I contacted Ally (the author of the palette icons) about this, too. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
