TProcess command, so everything was
tested.
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.freepasca
> > 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 help
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?
>
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
"SomeRec
> > 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?
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 open
[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.
__
HexFormatSettings2, true) =
[$0.0^0.0_0.A^B.C--D.E^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:5
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
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 to
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 (pr
> 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 r
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
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
ake[2]: *** [carbon_all] Error 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
e of Xlib for new
> developments, 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 wha
type of buffer overflows in your
> code !
>
> The way Delphi solved it, is by taking the responsibility from the
> developer, and made the code a bit slower.
> And as I said, I don't think it's a good idea
+1 ... @lacak, better fix your code. I don't like to be del
has gcc 4.0.1 and does 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 th
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 pl
of anything.
How ?
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/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 Car
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
art) and Linux' MONOTONIC_RAW time (or
> however it is called exactly). So I don't see why this should rule out
> OS time API calls...
No, MONOTONIC_RAW is introduced in 2.6.26 afair, so it won't run on older
kernels.
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
unit... but which name?
fpGetTickCount, fpGetTickCount64 ?
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
rects in region and you must calculate lower
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.
s painting (QPainter)
ClipRect = bounding rect of clip region (region can have more than 1 rect eg.
poly region).
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
will be removed from kernel, till then
gettimeofday() returns same as clock_gettime(CLOCK_REALTIME), when it's
removed 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
program and changed the
> timezone to Greenland (-3h). The output was the following:
>
> === output begin ===
>
> 03.11.2011 21:16:33
> Please change the timezone and then press enter
>
> 03.11.2011 17:17:10
> Done
>
> === output end ===
>
> So your lin
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 cou
c clock 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 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:
> > > >
> &
have in a separate thread. 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
ich I have with my
implementation of Now() by using syscall clock_gettime(CLOCK_REALTIME).
After Michal patched current trunk , gettimeofday have same timing.
Overhead of Now() is now fixed in trunk.
Don't know 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
On Wednesday 02 of November 2011 16:12:49 you wrote:
> On Wed, 2 Nov 2011, zeljko wrote:
> > 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:
> >>>> Y
ho cares ...
3.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_get
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.
> &g
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,
4870 ms
**Libc gettimeofday()+localtime_r() with 1000 calls = 5085 ms
***RTL Now() with 1000 calls = 7659 ms ?!?!?!? Slowest !?!?
Simple program is attached. Maybe I've added something wrong, but you can
correct me if I'm wrong.
zeljko
program unixclocks;
{$mode o
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 i
8 will be out at least in one year
(but DST will change until then ;))) )
Another question: if I call ReReadTimeZone, it'll just do what it's name says,
next Now() call will return correct result ?
Thanks for your time over this problem.
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, w
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
xtTime := True;
That will mean read 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 u
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
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 yo
and external clock
settings.
Also, look into the clock_getres() 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
rk correct, or please document it as weak and buggy (for linux).
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, so maybe that's mai
Don't know what to do ... I must fix this asap somehow ... even 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
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
> > week
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
> > week
Also 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
ne tries to load "iconv.dylib" while on osx the library name
> is "/usr/lib/libiconv.dylib":
>
> iconvlib:=LoadLibrary(libiconvname+'.'+SharedSuffix);
>
> Now I don't understand how it works with the static linking if
> "libiconvname"
ion in r17642
Is this merged in 2.4.5 ?
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
aik I didn't make acrobations with this
> > under kylix (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
_
's no file 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 pa
want to compile.
[linda@houston doc]$ ppc386
Free Pascal Compiler version 2.4.3 [2010/12/18] for i386
Copyright (c) 1993-2010 by Florian Klaempfl
Any hints ?
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
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
Quoting Luiz Americo Pereira Camara :
Mattias Gaertner escreveu:
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko wrote:
One note: IntersectRect in lazarus worked OK until we decided to
use Types.IntersectRect, old implementation from GraphType looks
much better than current fpc one
Quoting Mattias Gaertner :
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko 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 *not* by reference - due to long-term Delph
OK until we decided to use
Types.IntersectRect, old 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
On Tuesday 26 October 2010 15:13, Felipe Monteiro de Carvalho wrote:
> On Tue, Oct 26, 2010 at 3:14 PM, zeljko 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
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) ..
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
Hi all,
Someone reported bug in gtk2lcl which crashes lazarus ide. I've found that
intersectRect usage from types (from r 27870) makes that.
So imagine next code:
var
R, SrcRect: TRect;
begin
R := Rect(0, 0, 22, 22);
SrcRect := Rect(0, 0, 24, 24);
Types.IntersectRect(R, SrcRect, R);
e
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&
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
> >
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&
s
sign but brackets.
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 Ri
him on #lazarus-dev irc channel :)
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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/vi
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 :)
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
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
> >
piling module, stopping
Fatal: Compilation aborted
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.
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
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 mail
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 mail
77 matches
Mail list logo
