Hi all,
I've already filled up an issue
http://bugs.freepascal.org/view.php?id=15586 which shows the problem.
It cannot link application with 255 lfms (mac only - win32 linux are ok).
fpc-2.4.1 r14802
Anyone ?
zeljko
___
fpc-devel maillist - fpc
Hi all,
I've already filled up an issue
http://bugs.freepascal.org/view.php?id=15586 which shows the problem.
It cannot link application with 255 lfms (mac only - win32 linux are ok).
fpc-2.4.1 r14802
Anyone ?
zeljko
___
fpc-devel maillist - fpc
On Monday 25 January 2010 15:40, zeljko wrote:
Hi all,
I've already filled up an issue
http://bugs.freepascal.org/view.php?id=15586 which shows the problem.
It cannot link application with 255 lfms (mac only - win32 linux are
ok). fpc-2.4.1 r14802
Sorry about double posting (I wasn't
I've also attached test.reslist which is used by fpcres, so you can see there
that res7.lfm is at 254th line (254th resource of linked app)
thanks
zeljko
res260.lfm
res259.lfm
res258.lfm
res257.lfm
res256.lfm
res255.lfm
res254.lfm
res253.lfm
res252.lfm
res251.lfm
res250.lfm
res249.lfm
res248.lfm
On Monday 25 January 2010 18:45, Giulio Bernardi wrote:
Il 25/01/2010 18.40, zeljko ha scritto:
lindas-computer:~/genres Linda$ ppc386 test.pas
Free Pascal Compiler version 2.4.1 [2010/01/24] for i386
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Darwin for i386
Compiling
Hi,
I've created patch test program for long time issue
http://bugs.freepascal.org/view.php?id=13722
Would be nice if someone can review and apply if patch is ok (patch test
uploaded).
tnx
zeljko
___
fpc-devel maillist - fpc-devel
On Monday 06 September 2010 12:20, zeljko wrote:
Hi,
I've created patch test program for long time issue
http://bugs.freepascal.org/view.php?id=13722
Would be nice if someone can review and apply if patch is ok (patch test
uploaded).
Michael commited :) nice ... Is there any way to see
On Monday 06 September 2010 13:25, Michael Van Canneyt wrote:
On Mon, 6 Sep 2010, zeljko wrote:
On Monday 06 September 2010 12:20, zeljko wrote:
Hi,
I've created patch test program for long time issue
http://bugs.freepascal.org/view.php?id=13722
Would be nice if someone can review
channel :)
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
.
thanks
zeljko
Index: tests/test/tstrreal4.pp
===
--- tests/test/tstrreal4.pp (revision 15946)
+++ tests/test/tstrreal4.pp (working copy)
@@ -1,34 +1,35 @@
program tstrreal4;
{ test for issue #13722 by Zeljan Rikalo}
-uses SysUtils
On Tuesday 07 September 2010 14:19, Marco van de Voort wrote:
In our previous episode, zeljko said:
Test haven't passed, so I fixed problem (was in currency negative
format). Changes:
1.Use clocale under UNIX so various locales can be tested
2.Don't hardcode DecimalSeparator, now it's
On Tuesday 07 September 2010 14:15, Jonas Maebe wrote:
On 07 Sep 2010, at 14:05, zeljko wrote:
Test haven't passed, so I fixed problem (was in currency negative
format).
Changes:
1.Use clocale under UNIX so various locales can be tested
2.Don't hardcode DecimalSeparator, now it's
On Tuesday 07 September 2010 14:19, Marco van de Voort wrote:
In our previous episode, zeljko said:
Test haven't passed, so I fixed problem (was in currency negative
format). Changes:
1.Use clocale under UNIX so various locales can be tested
2.Don't hardcode DecimalSeparator, now it's
),0);
IntersectRect:=false;
end
else
IntersectRect:=true;
end;
So MAIN question is:
1.My example shows misusage of IntersectRect
2.FPC Types.IntersectRect() have bug
thanks,
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Tuesday 26 October 2010 14:02, Felipe Monteiro de Carvalho wrote:
IMHO it is
2.FPC Types.IntersectRect() have bug
And it's very ugly :)
I've grepped complete lazarus tree for such misusage of IntersectRect, but
found only same problematic code in gtk dir and fixed that.
zeljko
On Tuesday 26 October 2010 14:02, Felipe Monteiro de Carvalho wrote:
IMHO it is
2.FPC Types.IntersectRect() have bug
No, I've opened an issue and Jonas closed with good explanation - we had
misusage of IntersectRect in gtk/gtk2 interfaces (I've fixed both) ... so not
bug.
zeljko
On Tuesday 26 October 2010 15:13, Felipe Monteiro de Carvalho wrote:
On Tue, Oct 26, 2010 at 3:14 PM, zeljko zel...@holobit.net wrote:
No, I've opened an issue and Jonas closed with good explanation - we had
misusage of IntersectRect in gtk/gtk2 interfaces (I've fixed both) ... so
not bug
implementation from GraphType looks much better than
current fpc one.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Quoting Mattias Gaertner nc-gaert...@netcologne.de:
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko zel...@holobit.net wrote:
On Tuesday 26 October 2010 16:57, Sergei Gorelkin wrote:
Well, maybe. For me, it is rather hard to think about the
opposite - that a
const may be passed
Quoting Luiz Americo Pereira Camara luiz...@oi.com.br:
Mattias Gaertner escreveu:
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko zel...@holobit.net wrote:
One note: IntersectRect in lazarus worked OK until we decided to
use Types.IntersectRect, old implementation from GraphType looks
much
does not seem to be set
thread.inc(464,11) Warning: Function result does not seem to be set
thread.inc(470,11) Warning: Function result does not seem to be set
thread.inc(511,10) Warning: Function result does not seem to be set
zeljko
___
fpc-devel maillist
path inside filename or even
written to sr.PathOnly.
until FindNext() = 0;
end;
So, is it different from dcc ? afaik I didn't make acrobations with this under
kylix (remember each level of dir) because filename already contained path.
Anyone ?
zeljko
(remember each level of dir) because filename already
contained path. Anyone ?
You must always remember the directory.
I do this since day 1.
ok, thanks.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman
On Thursday 02 of June 2011 22:36:53 Florian Klämpfl wrote:
Am 01.06.2011 22:07, schrieb Michalis Kamburelis:
Hi,
In my tests, FPC 2.4.4 has much slower CompareMem than FPC 2.4.2, at
least for some cases:
I've commited an improved version in r17642
Is this merged in 2.4.5 ?
zeljko
+'.'+SharedSuffix);
Now I don't understand how it works with the static linking if
libiconvname variable is iconv?
Because ld knows about real libiconv ?
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman
this confirms something what happens sometimes when ntpd changes time ...
Any hints ? What to do ? Any workaround ?
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Monday 31 of October 2011 20:17:46 you wrote:
On Mon, 31 Oct 2011, zeljko wrote:
Hi,
I have daemon which uses Now() for getting current date/time, but
something is wrong, time on server changed from 03:00 to 02:00 this
weekend, but daemon's Now() was on old time ... until now
On Monday 31 of October 2011 20:17:46 you wrote:
On Mon, 31 Oct 2011, zeljko wrote:
Hi,
I have daemon which uses Now() for getting current date/time, but
something is wrong, time on server changed from 03:00 to 02:00 this
weekend, but daemon's Now() was on old time ... until now
with using my
own Now() implementation by calling libc ... don't know ... this pissed me off
totally.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
believe that kernel have only gettimeofday() and that kernel don't
know accurate datetime. There's more functions in kernel which can give you
accurate result. gettimeofday() is deprecated, so maybe that's main reason why
it fails to give correct result with daylight changes.
zeljko
() function.
So should I open an issue about this ?
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tuesday 01 of November 2011 11:01:32 Sven Barth wrote:
On 01.11.2011 09:41, zeljko wrote:
I don't believe that kernel have only gettimeofday() and that kernel
don't know accurate datetime. There's more functions in kernel which can
give you accurate result. gettimeofday() is deprecated
On Tuesday 01 of November 2011 11:25:22 Henry Vermaak wrote:
On 01/11/11 10:01, Sven Barth wrote:
On 01.11.2011 09:41, zeljko wrote:
I don't believe that kernel have only gettimeofday() and that kernel
don't know accurate datetime. There's more functions in kernel which can
give you
tzdatadb in next call of fpgettimeofday() and then correct
time if needed and set FPReadTZDataNextTime to false.
In that case rtl stays clear and fast and it re-reads tzdata only when it's
called from application.
Not best solution , but can help a lot until final solution is found.
zeljko
On Tuesday 01 of November 2011 13:51:19 Michael Van Canneyt wrote:
1. First off, we must correctly take into account DST. That should fix
Zejlko's problem.
Am I the only one who produces 24/7 services with fpc in the world (and
around) ? ;)
zeljko
On Tuesday 01 of November 2011 15:30:43 Hans-Peter Diettrich wrote:
zeljko schrieb:
Am I the only one who produces 24/7 services with fpc in the world (and
around) ? ;)
You seem to be the only one who provides such services based on *local*
time, with 23..25 hours per day ;-)
Lucky me
just do what it's name says,
next Now() call will return correct result ?
Thanks for your time over this problem.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tuesday 01 of November 2011 19:32:30 you wrote:
zeljko schrieb:
Now() must return exactly what it's name says. Anything of that is
bug.
Okay, so what's the *exact* definition of Now()?
Is a local calendar system taken into account?
It should return exactly same information as you
.
zeljko
program unixclocks;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes, SysUtils,
unix, baseunix, Libc, SysCall, unixutil;
const
CLOCK_REALTIME = 0;
CLOCK_MONOTONIC = 1;
CLOCK_MONOTONIC_RAW = 4;
CLOCK_REALTIME_COARSE = 5
On Wednesday 02 of November 2011 14:55:36 michael.vancann...@wisa.be wrote:
On Wed, 2 Nov 2011, michael.vancann...@wisa.be wrote:
On Wed, 2 Nov 2011, zeljko wrote:
On Wednesday 02 of November 2011 11:23:10 michael.vancann...@wisa.be
wrote:
On Wed, 2 Nov 2011, Jonas Maebe wrote:
Marco van
On Wednesday 02 of November 2011 15:47:46 you wrote:
On Wed, 2 Nov 2011, zeljko wrote:
On Wednesday 02 of November 2011 14:53:05 you wrote:
You must do also a localtime_r after this call.
clock_gettime returns the same time as gettimeofday.
But point IS in comparing clock_gettime() vs
.Issue can be resolved in that case, Now() behaviour isn't changed, it's only
faster.
4.If kernel clock_gettime() is really twice slower than gettimeodday, then use
gettimeofday until it's completely removed from some future kernel, if not ,
change it to use clock_gettime(CLOCK_REALTIME).
zeljko
anything about windows...maybe it should be reviewed for
unnecesarry calls.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
. It is important to know for me what problems
do you have with the new ansistring type.
Maybe it's not problem *now*, but looking into mailing list ppl have a lot of
problems, so I think that fear is only problem (at least for me).
zeljko
___
fpc-devel maillist
On Thursday 03 of November 2011 08:43:55 Martin Schreiber wrote:
On Thursday 03 November 2011 08.04:17 Martin Schreiber wrote:
On Thursday 03 November 2011 07.44:47 zeljko wrote:
The results with 10'000'000 calls:
FPC Now() MSEgui nowutc() MSEgui nowlocal()
Linux
on some platform , now() can be
returned anytime.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Thursday 03 of November 2011 09:41:05 zeljko wrote:
I guess that there's no GetTickCount in RTL.
Is it possible to add it there ?
Why ?
Because current GetTickCount in lazarus uses Now() which is movable
backward/forward by ntpd under unixes, and that could be a huge problem
? On linux it does not work without re-reading tzdata.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
from kernel fpc should be updated and that's it.
Problem is that older versions of fpc won't work with such kernel.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
than 1 rect eg.
poly region).
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
TopLeft and high BottomRight) in their docs, I hope that we'll have faster
ones :)
zeljko
box matches the region rectangle. It comes with a class for
rectangular region clipping which is the trivial case for backwards
compatibility.
___
fpc-devel
?
fpGetTickCount, fpGetTickCount64 ?
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
it won't run on older
kernels.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Friday 09 of December 2011 15:42:20 Marco van de Voort wrote:
FreeBSD has it. But OS X hasn't it seems, not even in recent versions.
Yes, there's many posts and arguing from OSX developers about this.
zeljko
___
fpc-devel maillist - fpc-devel
On Friday 09 of December 2011 16:10:54 Sven Barth wrote:
Am 09.12.2011 15:37, schrieb zeljko:
On Friday 09 of December 2011 14:52:56 Sven Barth wrote:
Am 09.12.2011 13:30, schrieb Michael Schnell:
On 12/09/2011 01:17 PM, Felipe Monteiro de Carvalho wrote:
I would like to define
?
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tuesday 20 of December 2011 09:52:20 Sven Barth wrote:
Am 19.12.2011 10:02, schrieb Den Jean:
On Monday 19 December 2011 08:04:30 zeljko wrote:
How ?
The binding now aligns the stack before calling the Qt libraries
Would you please post an example how exactly you aligned the stack
not have all these options.
It has mstackrealign but not the -mincoming-stack-boundary=num
I'll test with Snow Leopard (gcc-4.2) today.
Anyway -mstackrealign means nothing on 64bit platforms afaik (will test once
more again under Fedora 64bit), and it works there w//o problems.
zeljko
it's a good idea
+1 ... @lacak, better fix your code. I don't like to be delphi compatibile
with such things.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
, and suggests the usage of XCB instead. What's the
situation of fpc in respect of XCB?
It would be frustrating to start from scratch with h2pas, to discover
that someone else has already done all what's required!
And what about older X installations ?
zeljko
2
make[1]: *** [interfaces] Error 2
make: ***
I think you're asking on wrong list.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Sunday 24 of February 2013 13:35:12 Marco van de Voort wrote:
Hello,
Finally, FPC 2.6.2 has landed. FPC 2.6.2 is an update to 2.6.0 that
contains most library progress in 2012 and some crucial
compiler fixes, as well as a few new targets.
Great ! Thank you :)
zeljko
.
but nothing beats testing in the wild, so I would appreciate it if people
could test it and provide feedback.
Great feature :)
Thanks Michael
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman
BitHelpers are quite mature now and I would like to see them as part of
FreePascal. If devs agree to that, then I would like to discuss what is the
best way to include them. As mentioned at
https://forum.lazarus.freepascal.org/index.php/topic,41672.msg409880.html#msg409880,
Thaddy would like
In example bellow, both record field ID.PGN and type helper for that record
field ID.PGN.PS point to the same memory location in a bitpacked record not
aligned to a byte. ID.PGN can be modified correctly. ID.PGN.PS can not be
modified correctly. If a field in a bitpacked record can work well
> I had a look.
Thanks, I really appreciate it.
> Since this is currently linux-only, and there are several units, I would opt
> to make this a separate
> package.
>
> The directory structure to use should be clear, I suppose:
>
> can
> can/src
> can/examples
Understood.
> Is there any
Hello everyone,
I have implemented SocketCAN wrappers for FreePascal which I would like to contribute. Before creating a patch for Mantis, could someone please take a look at it's current form and advise me on further steps, changes and improvements that I should eventually do? I would like it
^F.F_F.F^F.F]
MyQword.ToHexString(MyHexFormatSettings2, false) =
[$A^B.C--D.E^F.F_F.F^F.F]
Compatibility with old behaviour of ToBinString and ToHexString is kept.
Please review the patch.
> Sent: Thursday, July 08, 2021 at 9:51 AM
> From: "Michael Van Canneyt"
> To: &q
As discussed at
https://forum.lazarus.freepascal.org/index.php/topic,55397.0.html, this
compiles and works well:
{$MACRO ON}
{$if SizeOf(byte) = 1}
WriteLn('SizeOf(byte) = ', SizeOf(byte));
{$endif}
however this does not compile:
{$MACRO ON}
{$define TMyOrdinalType := byte}
I have already opened and issue for Lazarus FPDOC Editor, but now I am not sure
if that should be fixed in FPDOC Editor or Makeskel tool so I would appreciate
an advice so that I can change bug report if needed.
Basically, FPDOC Editor in Lazarus does not recognize record helper method
> > I have already opened and issue for Lazarus FPDOC Editor, but now I am not
> > sure if that should be fixed in FPDOC Editor or Makeskel tool so I would
> > appreciate an advice so that I can change bug report if needed.
> >
> > Basically, FPDOC Editor in Lazarus does not recognize record
Sorry, wrong list. Forwarded to fpc-other instead.
> Sent: Monday, March 28, 2022 at 11:43 AM
> From: "Zeljko Avramovic via fpc-devel"
> To: fpc-devel@lists.freepascal.org
> Cc: "Zeljko Avramovic"
> Subject: [fpc-devel] Issue in FPDOC Editor or Makeskel?
[Probably for @mvancanneyt]
I have just submitted patches for syshelpers here:
https://gitlab.com/freepascal.org/fpc/source/-/issues/39268#note_810963784
It's a closed thread and I can not reopen it, so maybe it would be better if I
open a new issue? If yes then please say so.
Done.
https://gitlab.com/freepascal.org/fpc/source/-/issues/39541
> > I have just submitted patches for syshelpers here:
> > https://gitlab.com/freepascal.org/fpc/source/-/issues/39268#note_810963784
> >
> > It's a closed thread and I can not reopen it, so maybe it would be better
> > if I
> > https://gitlab.com/freepascal.org/fpc/source/-/issues/39541
>
> Thank you. I already applied 2 patches, I still need to commit the examples.
Nice. Thanks! Please close the issue when you are done.
Btw, I guess that I should create syshelpers.xml for new doc related to just
syshelpers unit?
75 matches
Mail list logo
