On 18.04.2016 10:18, Jonas Maebe wrote:
Delphi does not support assigning procedures to variables representing
anonymous functions
It does. Both for procedure of object and plain procedure:
program Project1;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils;
type
TRefProc = reference
What are the plans on releasing 3.0.2?
We'd like to release Lazarus 1.6.2 - it would be good if it was released
with FPC 3.0.2 because of the Currency bug.
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 22.03.2016 8:01, Michael Van Canneyt wrote:
1. I change the code to raise an exception instead (as was my original
plan)
This is the way to go. False should be returned if nothing was found.
In case there are problems with starting parameters (or string list
status or whatever), an
On 11.03.2016 7:58, LacaK wrote:
Then that indeed applies for Win64 as well.
Maybe time to start thinking about 3.0.2, then.
This is not a minor bug.
IMO it is serious bug and users should be informed, that upgrading to
FPC 3.0 (on some platforms) can leads to serious problems when
@Sven: is the IfThen removal permanent? In this case I'll remove it from
CodeTools as well.
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
What a pity that you removed IfThen(). IMO it was a great addition.
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On 28.01.2016 13:30, Jonas Maebe wrote:
Mersenne twister
Should I be worried about the GPL-2 license of the Mersenne Twister that
is cited in system.inc?
I don't write GPL-software.
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 29.01.2016 14:07, Jonas Maebe wrote:
It's LGPL, not GPL.
Thanks, I again missed it. I should read more carefully. Everything is
clear now!
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Mantis is down and I want to get rid of this patch so that I can work on
other things.
The implementation of TRect.setWidth and setHeight is shifted.
Ondrej
Index: rtl/inc/typshrd.inc
===
--- rtl/inc/typshrd.inc (revision 33029)
On 28.01.2016 16:23, Anthony Walter wrote:
Here is a preferable solution:
property Controls: IControlEnumerator read GetItems;
You are already the third person suggesting it :)
Yes, it is possible. You can do it with your code. I still don't know if
there is a will to modify:
On 28.01.2016 20:02, Kazantsev Alexey wrote:
On Thu, 28 Jan 2016 22:33:39 +0400, Ondrej Pokorny <laza...@kluug.net>
wrote:
why the double-posting?
Because my example answer to your querys:
First, I don't want to publish the TEnumeratedObjects object to the
outside of TTest (e.g. you
On 28.01.2016 18:36, Maciej Izak wrote:
Another option :) from bugtracker by Kazantsev Alexey (
http://bugs.freepascal.org/view.php?id=28820#c89471 )
Yes, he was the second person suggesting it :) Maciej, why the
double-posting?
It's completely the same approach as Anthony's and Misha
To continue from http://bugs.freepascal.org/view.php?id=28820#bugnotes
TTest = class
public
property Objects[Index: Integer]: TObject read GetObject;
published
property Objects: TTestObjectEnumerator read GetObjectEnumerator;
end;
@Maciej >> But what for "write"? ;d
Your
On 27.01.2016 9:11, Maciej Izak wrote:
Just let me know what is your plan. If you wan't it in FPC RTL then it
will became part of sparta packages in Lazarus.
It has tu be duplicated in Lazarus anyway if you plan to use it in
Sparta code. The same was with AdvancedIPC unit.
The problem is
On 27.01.2016 14:05, Marco van de Voort wrote:
fpc.core.filesystem.file.utils is better I think.
+1 :D
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On 05.01.2016 11:07, Sven Barth wrote:
Type helpers now work correctly with static arrays as well :)
Just an information: I now tested Delphi 10 Seattle and it supports
helpers for dynamic arrays but not for static arrays :) It seems people
from Embarcadero forgot about them as well :)
On 05.01.2016 11:07, Sven Barth wrote:
Type helpers now work correctly with static arrays as well :)
Codetools support them now as well!
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 02.01.2016 20:41, Mathias wrote:
Does "Type Helper" only with standard types?
The class itself it compiles without errors.
But when you call, there is an error message.
See link, there the code and the problem is described. ("Illegal
qualifier")
On 03.01.2016 14:13, Sven Barth wrote:
Please report a bug with a simple example that should compile with the
error message you get at http://bugs.freepascal.org as I don't see any
difference between dynamic and static arrays in relation to type
helpers (so probably merely an oversight of
On 07.12.2015 20:56, Michael Van Canneyt wrote:
Interesting point! From this point-of-view I don't have to create the
connection layer between SimpleIPC and AdvancedIPC as me
suggested here:
http://lists.freepascal.org/pipermail/fpc-devel/2015-September/035958.html
It makes sense.
Well,
On 07.12.2015 20:00, Michael Van Canneyt wrote:
On Mon, 7 Dec 2015, Denis Kozlov wrote:
On 6 December 2015 at 08:29, Ondrej Pokorny <laza...@kluug.net> wrote:
If you don't persist in using SimpleIPC, there is also AdvancedIPC
that uses
the same approach (temporary files) across all t
On 06.12.2015 03:03, Denis Kozlov wrote:
There are alternative IPC mechanisms available in Windows (Pipes,
Sockets, DDE, etc), but that might be like opening another can of
worms. I'm still confident that we can get a fully functioning IPC
going using WM_COPYDATA, it just might get a bit more
On 11.11.2015 17:47, Michael Van Canneyt wrote:
I have several remarks:
a) Your TBaseSingleInstance class contains too many methods.
It assumes you are using advancedipc.
I refactored TBaseSingleInstance so that it doesn't depend on advancedipc.
I suggest refactoring such a way that
On 21.11.2015 12:06, Arnaud Bouchez wrote:
we consider using only FPC as main compiler for our server-side projects.
This is good news for me because I am developing a client-server
application with mORMot and FPC as well :) But I am still on the very
beginning.
Ondrej
, Ondrej Pokorny wrote:
On 29.09.2015 22:47, Michael Van Canneyt wrote:
Let's first see how Ondrej does it.
See the patch attached. A simple demo program is attached as well
(SITest.lpr).
Hello Michael,
you asked for implementing "single instance" in custapp.pp. I did it and
sent a pat
On 11.11.2015 17:47, Michael Van Canneyt wrote:
I checked the patch and applied it, so people can try it.
I have several remarks:
a) Your TBaseSingleInstance class contains too many methods.
It assumes you are using advancedipc.
I suggest refactoring such a way that advancedipc is in the
I see that Sven refactored the compiler and added texprflags. Thanks
Sven! I uploaded a new patch that takes advantage of texprflags.
/property-enumerator-4.patch/
On 31.10.2015 12:06, Jonas Maebe wrote:
* don't use the "is" operator unless there is absolutely no other way
to achieve the same
On 02.11.2015 20:52, Sven Barth wrote:
I couldn't reproduce the previous example without arguments though
(didn't have the idea to try /more/ parameters). But the one you just
showed is troubling as well... would you please add that as an
additional example to the bug report that you'll
First of all thanks Sven and Michael for the positive feedback! I was
already worried that I was completely misunderstood with the property
array enumerator extension.
About your 3 points, Sven:
On 02.11.2015 20:24, Sven Barth wrote:
The only thing we need is a new flag/whatever so that
What does the "function search_enumerator_operator" in
compiler/symtable.pas do?
Does FPC support enumerator operator overloading? If yes, how?
There doesn't seem to be any information on this topic in the docs:
http://www.freepascal.org/docs-html/3.0.0/ref/refch15.html#x207-22800015
Ondrej
On 03.11.2015 11:55, Sven Barth wrote:
>> - extend comp_expr by another boolean parameter (which is set in
for_in_loop_create) and pass that down to factor (even better: convert
the boolean parameters of comp_expr, sub_expr and factor to a set,
would be cleaner anyway, IMHO) (pro: the state
On 03.11.2015 15:42, Sven Barth wrote:
Am 03.11.2015 13:49 schrieb "Ondrej Pokorny" <laza...@kluug.net
<mailto:laza...@kluug.net>>:
>
> What does the "function search_enumerator_operator" in
compiler/symtable.pas do?
>
> Does FPC support
On 01.11.2015 21:03, Ondrej Pokorny wrote:
You cannot assign an array property to a variable. It does not exist
without the index parameter.
OK, there is a bug in ppc that allows to use an array property with *any
paramete**r(s)* (also no parameter). Delphi does not allow it.
Actually ppc
With pleasure :)
Yes it looks like if the parameter count matches, there is a compile
error (correct). If it doesn't match (there are less or more
parameters), it compiles (wrong).
Furthermore it doesn't only affect the getter but also the setter. All
possible combinations compile. See
On 02.11.2015 20:08, Sven Barth wrote:
It's not a general compiler bug, but only in relationship with helpers
(I can't trigger it if I have a class constructed that way without a
helper).
It is a general compiler bug. Not even related to a for-in or anything else.
See:
*program
On 01.11.2015 16:38, Jonas Maebe wrote:
1) do you a) forbid an enumerator specification if the class already
has an enumerator
No, it's not needed.
b) hide the existing enumerator
No, it's not needed.
or c) allow enumerating both via the property and the original class
enumerator?
There can
On 01.11.2015 16:38, Jonas Maebe wrote:
The basic issue is that you need extra context for supporting this
extension. Normally, an enumerator is searched based on the class
type. In your case, it's searched either based on the class type, or
if the class is returned from a property with an
On 01.11.2015 00:11, Jonas Maebe wrote:
On 31/10/15 21:28, Ondrej Pokorny wrote:
The argument that the tenumeratornode concept is completely different
from other nodes is correct - but if you think about the syntax you will
see that also the syntax is completely different from other pascal
On 30.10.2015 19:38, Sven Barth wrote:
On 30.10.2015 16:01, Ondrej Pokorny wrote:
just out of curiosity, I wanted to play with the debugger and try to add
http://bugs.freepascal.org/view.php?id=28820
Seems like my little hint helped :P
Yes, indeed. It's always good to know that a patch
I have thought about the problem and I have some new ideas:
On 31.10.2015 12:06, Jonas Maebe wrote:
Independent of whether it will be integrated, there are definitely a
number things that should be changed first:
* don't use the "is" operator unless there is absolutely no other way
to achieve
Thanks for the feedback!
Independent of whether it will be integrated, there are definitely a
number things that should be changed first:
* don't use the "is" operator unless there is absolutely no other way
to achieve the same effect. In the compiler, every node has a
"nodetype" field that
Hello,
just out of curiosity, I wanted to play with the debugger and try to add
http://bugs.freepascal.org/view.php?id=28820
As the first step, I want to debug the compiler while it is compiling my
simple project.
What I did:
1.) I opened "compiler\ppx86_64.lpi" from FPC trunk.
2.) I set
Got it working, wrong target directory!
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hello!
Would it be possible to apply this
http://bugs.freepascal.org/view.php?id=28578 into 3.0.0 as well? Or is
it too late?
Thanks
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 29.10.2015 17:35, Ondrej Pokorny wrote:
On 29.10.2015 17:21, Anthony Walter wrote:
Jonas, when FPC 3.0 release is ready will the Lazarus team also be
releasing a tandem version?
I ask because Ondrej's patch for this issue still isn't in SVN:
http://bugs.freepascal.org/view.php?id=22235
On 29.10.2015 17:21, Anthony Walter wrote:
Jonas, when FPC 3.0 release is ready will the Lazarus team also be
releasing a tandem version?
I ask because Ondrej's patch for this issue still isn't in SVN:
http://bugs.freepascal.org/view.php?id=22235
This is a Lazarus issue, not FPC related.
On 27.10.2015 12:24, Mark Morgan Lloyd wrote:
Up to and including 2.6.4, this works:
TRoundRobin= CLASS(TObject)
..
PUBLIC
..
(*$IFDEF HAS_TRUE YIELD *)
PROPERTY HasTrueYield: BOOLEAN DEFAULT TRUE;
(*$ELSE *)
On 27.10.2015 12:32, Ondrej Pokorny wrote:
* PROPERTY HasTrueYield DEFAULT TRUE; **
*
But then there has tobe a property to override.
What do you use
PROPERTY HasTrueYield: BOOLEAN DEFAULT TRUE;
for?
In 2.6.4 you cannot read this property. Is it useful for RTTI?
Ondrej
Hello!
In Delphi it is valid to assign a static class procedure to a procedure
variable:
program project1;
type
TMyObject = class
public
class procedure Proc; static;
end;
TProc = procedure();
class procedure TMyObject.Proc;
begin
end;
var
xProc: TProc;
begin
* xProc :=
On 17.10.2015 09:51, Maciej Izak wrote:
Just use Delphi mode. :)
Ok, that is possible. No chance to get it working in objfpc mode?
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 10.10.2015 12:41, Michael Van Canneyt wrote:
100% agreed :)
Great!
I wrote a feature request in mantis for it so that we don't forget about
it and can follow it there: http://bugs.freepascal.org/view.php?id=28820
Ondre
___
fpc-devel maillist
Oh, it would be so nice if default enumerator wasn't defined with the
"GetEnumerator" function but with the default property:
TTest = class
// ...
function GetObjectEnumerator: TTestObjectEnumerator;
property Objects[Index: Integer]: TObject read GetObject enumerator
On 10.10.2015 16:58, Michael Van Canneyt wrote:
The class does not need to have a default property to begin with, so
it is somewhere logical.
Yes, in that case a default enumerator would not be allowed, which
sounds (in contrary) logical to me: no default array property => no
enumerator. But
On 10.10.2015 12:30, Michael Van Canneyt wrote:
After a
sed s/iterator/enumerator/g
I'm all for it.
I've been looking how to implement names/objects/values enumerators in
TStrings. This would be the almost perfect solution.
But your example is not well-chosen, since the enumerator for
When we are already discussing new language features, what about
supporting iterators for array properties:
TTest = class
// ...
property Objects[Index: Integer]: TObject read GetObject *iterator
GetObjectIterator*;
property ObjectCount: Integer read GetObjectCount;
end;
This
On 08.10.2015 17:37, MohsenTi wrote:
I know this issue but with changing some of structures, I can
implement it and now I only want testing adding features to compiler
and don't care about backward compatibility,just testing.
I added some changes to compiler functions and classes like
On 08.10.2015 18:54, Sven Barth wrote:
I had the idea to implement inline-if as well. I think the syntax I
selected is derived from Oxygene, but it looks very Pascal and
shouldn't break anything:
left := if expr1 then expr2 else expr3;
Thereby expr1 returns Boolean and expr2 determines the
Hello!
I talked to Mattias about the advancedipc implementation and he noticed
that the thread ID doesn't have to be necessarily a system-wide unique
constant (which I didn't know).
Therefore I fixed advancedipc.pp:
1.) Changed GetCurrentThreadID to GetProcessID.
2.) Added a critical section
On 03.10.2015 19:21, Tomas Hajny wrote:
Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently
On 03.10.2015 19:21, Tomas Hajny wrote:
Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently
On 03.10.2015 19:21, Tomas Hajny wrote:
Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently
+Msg;
end;
begin
Index: packages/fcl-base/src/singleinstance.pp
===
--- packages/fcl-base/src/singleinstance.pp (nonexistent)
+++ packages/fcl-base/src/singleinstance.pp (working copy)
@@ -0,0 +1,419 @@
+unit singleinstance;
+
+{
+This file is part of the Free Component Library (FCL)
+
On 29.09.2015 14:42, Michael Van Canneyt wrote:
On Tue, 29 Sep 2015, Ondrej Pokorny wrote:
OK, I see your point. Yes, I think it is possible and even not that
much work to do.
I programmed "multiple instances" handling into Lazarus IDE. It's the
same like e.g. Adobe Photoshop or
)
@@ -2,7 +2,13 @@
This file is part of the Free Component Library (FCL)
Copyright (c) 2015 by Ondrej Pokorny
-Unit implementing two-way (request/response) IPC between 1 server and more
clients, based on files.
+Unit implementing two-way (request/response) IPC between 1 server
On 29.09.2015 15:42, Ondrej Pokorny wrote:
On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no
dangerous dependencies except sysutils and classes.
Michael, you added the wrong (old) unit from the bug report, not the
latest simpleipc
On 29.09.2015 15:01, Juha Manninen wrote:
On Tue, Sep 29, 2015 at 2:35 PM, Ondrej Pokorny <laza...@kluug.net> wrote:
Juha, I changed the advancedipc.pas unit (this one from the mailing list is
newer than from the bug report). I can prepare a new patch for the bug
report.
No need for
On 29.09.2015 15:35, Michael Van Canneyt wrote:
1. Using a LCL component means that you must instantiate a
form/datamodule first.
By that time, a database connection may already have been made (just
to name something), which is exactly what you want to avoid.
The check for single
)
@@ -2,7 +2,13 @@
This file is part of the Free Component Library (FCL)
Copyright (c) 2015 by Ondrej Pokorny
-Unit implementing two-way (request/response) IPC between 1 server and more
clients, based on files.
+Unit implementing two-way (request/response) IPC between 1 server
On 29.09.2015 13:50, Michael Van Canneyt wrote:
You may not think this is important, but for beginners, this can be a
tremendous aid.
The easier we make it, the better. Lazarus is a RAD environment, after
all.
Michael.
OK, I see your point. Yes, I think it is possible and even not that
On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no
dangerous dependencies except sysutils and classes.
Thanks!
Juha, if you want to implement the single IDE instance, then I would
like to ask you to implement this in
On 29.09.2015 16:09, Michael Van Canneyt wrote:
Both are OK. Use of one does not exclude use of the other.
I was going to add it in CustApp anyway as soon as I had looked at
your implementation.
I started working on the CustApp variant. It's even simpler than the LCL
component because you
n simpleipc.pas.
I attached the advancedipc.pas file.
The discussion about "multiple instances" is here:
http://bugs.freepascal.org/view.php?id=8051
Ondrej
{
*** Please use appropriate header ***
License standard LCL (GPL/LGPL ?)
Author: Ondrej Pokorny
Abstract:
Unit
On 15.09.2015 08:58, Michael Van Canneyt wrote:
On Mon, 14 Sep 2015, Ondrej Pokorny wrote:
I've developed a "single/multiple instances" feature for the Lazarus
IDE. For this feature I need an IPC. First I tried to use simpleipc
but I have struggled on bugs and missing fun
On 15.09.2015 13:22, Michael Schnell wrote:
On 09/15/2015 01:09 PM, Michael Van Canneyt wrote:
IPC = Inter PROCESS Communication.
I know that you know this, but Ondrej is talking about cthreads in one
of his message, so I tried to politely set a trigger.
-Michael
This is because Michael
301 - 374 of 374 matches
Mail list logo
