On Thu, 13 Aug 2015 10:50:45 +0300
FreeMan freema...@delphiturkiye.com wrote:
[...]
lazbuild --quiet --max-process-count=8 --pcp=/Users/freeman35/.lazarus
--build-all --skip-dependencies --build-ide= --ws=qt --cpu=x86_64
--compiler=ppcx64
Note:
--max-process-count=8 has no effect here,
On 13.08.2015 11:04, Mattias Gaertner wrote:
lazbuild --quiet --max-process-count=8 --pcp=/Users/freeman35/.lazarus
--build-all --skip-dependencies --build-ide= --ws=qt --cpu=x86_64
--compiler=ppcx64
In case of an error, you should replace --quiet with --verbose
--verbose.
with fpc svn r31319
On Thu, 13 Aug 2015 10:50:45 +0300
FreeMan freema...@delphiturkiye.com wrote:
I'll update fpc r31319 fpc r49661 still same, I mean IDE still lock
while startup
When I try run lazbuild from terminal, its freezing after 5.line
verbose. Maybe can helpfull. I add trace info too. I'll test with
On 13.08.2015 11:04, Mattias Gaertner wrote:
Does the problem happen with the release compiler 2.6.4 too?
Mattias
I did and not error, IDE compiled and started with fpc 2.6.4
But I can not use lazbuil, this error creted, this is normal 'cos I'm
using utf8
Am 2015-08-09 um 14:31 schrieb Jürgen Hestermann:
I just had a closer look at the function UTF8CharacterLength in unit LazUTF8.
To me it looks as if it can be improved (made faster) because it checks too
many things.
According to https://de.wikipedia.org/wiki/UTF-8 the number of bytes of an
El 12/08/15 a les 16:37, Luca Olivetti ha escrit:
Definitely a regression: I just had to modify an old program (where this
feature worked) and it doesn't work anymore :-(
At least the workaround seems to do the job.
It's not a regression, it's probably always been there, but I manually
I'll update fpc r31319 fpc r49661 still same, I mean IDE still lock
while startup
When I try run lazbuild from terminal, its freezing after 5.line
verbose. Maybe can helpfull. I add trace info too. I'll test with fpc 2.6.4
lazbuild --quiet --max-process-count=8 --pcp=/Users/freeman35/.lazarus
Am 2015-08-13 um 13:01 schrieb Mattias Gaertner:
On Thu, 13 Aug 2015 12:38:00 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Am 2015-08-13 um 11:55 schrieb Mattias Gaertner:
A string always ends with a #0, so checking byte by byte makes sure you
stay within range.
Not quite
Am 2015-08-13 um 13:29 schrieb Michael Van Canneyt:
On Thu, 13 Aug 2015, Jürgen Hestermann wrote:
Am 2015-08-13 um 12:59 schrieb Michael Van Canneyt:
On Thu, 13 Aug 2015, Jürgen Hestermann wrote:
Determining the character length of a invalid UTF-8 string is quite useless.
Because it's
There is a comment for UTF8CompareText in LazUTF8 which is contradictorily:
// Returns: 0 if S1 S2, 0 if S1 = S2, 0 if S2 S1.
But S1 S2 is the same as S2 S1.
In the first case the result should be 0 and in the second one 0.
It cannot even be retrieved from the code how it realy works
Am 2015-08-13 um 11:55 schrieb Mattias Gaertner:
A string always ends with a #0, so checking byte by byte makes sure you
stay within range.
Not quite true:
if ((ord(p^) and %) = %1110) then
begin // could be 3 byte character
if ((ord(p[1]) and %1100) =
On Thu, 13 Aug 2015, Jürgen Hestermann wrote:
Am 2015-08-13 um 11:55 schrieb Mattias Gaertner:
If you know that you have a valid UTF-8 string you can simply use the
first byte of each codepoint (as you pointed out). So, for that case a
faster function can be added.
Maybe UTF8QuickCharLen or
On Thu, 13 Aug 2015, Jürgen Hestermann wrote:
Am 2015-08-13 um 12:59 schrieb Michael Van Canneyt:
On Thu, 13 Aug 2015, Jürgen Hestermann wrote:
Determining the character length of a invalid UTF-8 string is quite
useless.
Because it's not about getting a correct result then, but about
Am 2015-08-13 um 12:15 schrieb Mattias Gaertner:
On Thu, 13 Aug 2015 11:52:26 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
There is a comment for UTF8CompareText in LazUTF8 which is contradictorily:
// Returns: 0 if S1 S2, 0 if S1 = S2, 0 if S2 S1.
But S1 S2 is the same as
On Thu, 13 Aug 2015 11:52:26 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
There is a comment for UTF8CompareText in LazUTF8 which is contradictorily:
// Returns: 0 if S1 S2, 0 if S1 = S2, 0 if S2 S1.
But S1 S2 is the same as S2 S1.
It should be 0 if S1 S2. I changed the
On Sun, 9 Aug 2015 14:31:44 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
I just had a closer look at the function UTF8CharacterLength in unit LazUTF8.
To me it looks as if it can be improved (made faster) because it checks too
many things.
According to
It seems that if I change something within a function that is declared inline
and I then use run/compile in Lazarus it does not rebuild this function.
I have to use run/build to see my changes in the program.
Is this a known issue?
--
___
Lazarus
On Thu, 13 Aug 2015 12:38:00 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Am 2015-08-13 um 11:55 schrieb Mattias Gaertner:
A string always ends with a #0, so checking byte by byte makes sure you
stay within range.
Not quite true:
if ((ord(p^) and %) =
Am 2015-08-13 um 12:59 schrieb Michael Van Canneyt:
On Thu, 13 Aug 2015, Jürgen Hestermann wrote:
Determining the character length of a invalid UTF-8 string is quite useless.
Because it's not about getting a correct result then, but about not crashing
due to invalid memory access.
But
Am 2015-08-13 um 13:01 schrieb Mattias Gaertner:
On Thu, 13 Aug 2015 12:38:00 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Am 2015-08-13 um 11:55 schrieb Mattias Gaertner:
A string always ends with a #0, so checking byte by byte makes sure you
stay within range.
Not quite
On Thu, 13 Aug 2015 13:23:28 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
[...]
if ((ord(p^) and %) = %1110) then
begin // could be 3 byte character
if ((ord(p[1]) and %1100) = %1000) and
((ord(p[2]) and %1100) = %1000) then ...
On Thu, 13 Aug 2015 14:05:19 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
[...]
Still I think it would be better to give back 3 in case the byte actually
means 3 because 1 byte does not form a valid UTF-8 character.
If I rely on this result I would try to use this 1 byte as a valid
Am 2015-08-13 um 14:19 schrieb Mattias Gaertner:
On Thu, 13 Aug 2015 14:05:19 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Still I think it would be better to give back 3 in case the byte actually
means 3 because 1 byte does not form a valid UTF-8 character.
If I rely on this
On 2015-08-13 18:59, Martin Frb wrote:
It should look at the extension (the configured extensions are on the
color page of the IDE options)
It might (I am not sure) store info in the session (lps, lpi).
Ah, the problem was in the .lps file. For some reason I had loads of
files with
Hi All,
I just updated my windows (ugh) version of Lazarus to 1.4. Everything
seems to be working fine except breakpoints are not breaking. They are
listed in the breakpoints window with the break property set true, but
execution goes wizzing by them without stopping.
Any ideas on what
On 08/13/2015 12:27 PM, Donald Ziesig wrote:
Hi All,
I just updated my windows (ugh) version of Lazarus to 1.4. Everything
seems to be working fine except breakpoints are not breaking. They
are listed in the breakpoints window with the break property set true,
but execution goes wizzing by
On 13/08/2015 17:27, Donald Ziesig wrote:
Hi All,
I just updated my windows (ugh) version of Lazarus to 1.4. Everything
seems to be working fine except breakpoints are not breaking. They
are listed in the breakpoints window with the break property set true,
but execution goes wizzing by
On 2015-08-13 17:12, Martin Frb wrote:
IIRC HL is chosen according to file extension .pp or .pas
Do your files have those extension?
For the project I'm working on they are all .pp file extensions.
More specific, these units are pure code units (declaring unit tests),
so no Forms or other
On 13/08/2015 18:03, Graeme Geldenhuys wrote:
On 2015-08-13 17:12, Martin Frb wrote:
IIRC HL is chosen according to file extension .pp or .pas
Do your files have those extension?
Also, as I mentioned these units compile just fine, so no syntax issues.
Forcing Free Pascal syntax highlighting
Am 13.08.2015 12:48 schrieb Jürgen Hestermann juergen.hesterm...@gmx.de:
It seems that if I change something within a function that is declared
inline
and I then use run/compile in Lazarus it does not rebuild this function.
I have to use run/build to see my changes in the program.
Is this a
On 13/08/2015 16:50, Graeme Geldenhuys wrote:
I then have to manually select the popup menu and select Object Pascal
as the highlighter and it works fine again. Closing the unit and opening
it again doesn't solve the problem. It always happens with specific
units too - I can reproduce the issue
Hi,
I'm running Lazarus 1.5 r48959 FPC 2.6.4 x86_64-linux-gtk 2, and every
day I get this issue a couple of times - not always. I open a unit, but
Lazarus simply doesn't apply any syntax highlighting. No idea why.
There isn't any object pascal syntax errors as the units compile just fine.
I
32 matches
Mail list logo
