new code in 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
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 missin
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 V
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 custapp.pp
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 muc
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 Photosho
)
@@ -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 and
)
@@ -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 and
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 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 a new patch if it did not
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 ins
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 ca
If (Result<>'') then
Result:=Result+sLineBreak;
-Result:=Result+Msg;
+Result:=Result+Msg;
end;
begin
Index: packages/fcl-base/src/singleinstance.pp
===
--- packages/fcl-base/src/singleinstance.pp (nonexistent)
+++ packages/fcl-base/src/singleinstance.pp (wo
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 search
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 search
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 search
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 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
pstatmn
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 ty
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 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
TCom
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
GetObjectEnum
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 th
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 := @TM
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
http://lists.freepascal.org/cgi-bin/mailman/listinfo
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 *)
PROP
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!
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
http://lists.freepascal.org/cgi-bin/mailman/listinf
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
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.ph
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 r
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
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
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 ca
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 t
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 17.10.2015 12:19, Jonas Maebe wrote:
On 17/10/15 10:14, Ondrej Pokorny wrote:
Ok, that is possible. No chance to get it working in objfpc mode?
It's a known bug since quite a long time, but nobody got around to
fixing it yet. There's a report for it on the bug tracker.
I fixe
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 "enu
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 n
On 17.10.2015 12:19, Jonas Maebe wrote:
On 17/10/15 10:14, Ondrej Pokorny wrote:
Ok, that is possible. No chance to get it working in objfpc mode?
It's a known bug since quite a long time, but nobody got around to
fixing it yet. There's a report for it on the bug tracker.
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
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 arraypropbug;
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 attac
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 hopeful
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
*crea
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 i
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 15:42, Sven Barth wrote:
Am 03.11.2015 13:49 schrieb "Ondrej Pokorny" <mailto:laza...@kluug.net>>:
>
> What does the "function search_enumerator_operator" in
compiler/symtable.pas do?
>
> Does FPC support enumerator operator overloadin
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
, 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
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
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
_
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 ad
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 c
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 wrote:
If you don't persist in using SimpleIPC, there is also AdvancedIPC
that uses
the same approach (temporary files) across all targets and so it
be
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&you
suggested here:
http://lists.freepascal.org/pipermail/fpc-devel/2015-September/035958.html
It makes sense.
Well
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")
http://www.lazarusforum.de/viewtopic.php?f=1
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 min
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
http://lists.freepascal.org/cgi-bin/mailman/li
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
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 tha
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
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 problem
@Michael:
Ondrej, if you make it an interface,
TTest = class
public
property Objects[Index: Integer]: TObject read GetObject;
published
property Objects: IEnumerator read GetObjectEnumerator;
end;
Then the compiler will know how to free it.
--
Yes, true. The same is for enume
Regarding: http://bugs.freepascal.org/view.php?id=29526 (because I
cannot answer on closed issues).
>> Also: the entire state of the random number generator consists of
regular global variables, so it is not safe to use it from multiple
threads in parallel.
Would it make sense to you to make
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:
TWinCon
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 Strong
On 28.01.2016 20:02, Kazantsev Alexey wrote:
On Thu, 28 Jan 2016 22:33:39 +0400, Ondrej Pokorny
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 could call Free
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
h
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
http://lists.freepascal.org/cgi-bin/mailm
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)
++
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
@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
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
curr
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 exceptio
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
http://lists.freepascal.org/cg
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
On 12.04.2016 9:22, Michael Van Canneyt wrote:
I also think so, we've already been merging the necessary fixes to
fixes_3_x
Could you please include http://mantis.freepascal.org/view.php?id=28578
(r31434) into 3.0.2 as well?
Ondrej
___
fpc-devel
On 29.05.2016 10:33, Michael Van Canneyt wrote:
We're set to create the branch at the end of May, which is about now.
The last merges have been performed. I assume Marco will tag somewhere
this
week, and then building starts.
Great!
Do you have a merge list on the net somewhere (like Lazarus
On 20.05.2016 11:21, Ondrej Pokorny wrote:
On 12.04.2016 9:22, Michael Van Canneyt wrote:
I also think so, we've already been merging the necessary fixes to
fixes_3_x
Could you please include
http://mantis.freepascal.org/view.php?id=28578 (r31434) into 3.0.2 as
well?
Could you p
On 31.05.2016 7:59, Marco van de Voort wrote:
In our previous episode, Ondrej Pokorny said:
Could you please include http://mantis.freepascal.org/view.php?id=28578
(r31434) into 3.0.2 as well? (Or confirm that it won't be merged.)
Done.
Thank you!
O
Hello!
One of my projects doesn't compile with current FPC trunk. I get this error:
MyProj.lpr(23,1) Error: Undefined symbol:
SYSTEM_::=::\_DELETE$RAWBYTESTRING$LONGINT$LONGINT
It used to compile fine. Also other projects compile. Does anybody have
an idea what I am doing wrong or what shoul
On 17.06.2016 14:27, Sven Barth wrote:
Are you sure all units you use were rebuild?
I did a clean&build and it helped! Thank you!
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/f
On 21.07.2016 10:37, Denis Kozlov wrote:
I've uploaded a patch to mantis:
http://bugs.freepascal.org/view.php?id=30394
Why does your client ignore mailing list threads? (Or why does my
Thunderbird email client ignore threads on messages sent from you?)
Ondrej
__
On 21.07.2016 11:19, Denis Kozlov wrote:
On 21 July 2016 at 10:04, Ondrej Pokorny <mailto:laza...@kluug.net>> wrote:
Why does your client ignore mailing list threads? (Or why does my
Thunderbird email client ignore threads on messages sent from you?)
I use latest Thunderbir
CriticalSection function names differ from Delphi:
Delphi - FPC
InitializeCriticalSection <> InitCriticalSection
EnterCriticalSection "=" EnterCriticalsection
LeaveCriticalSection "=" LeaveCriticalsection
DeleteCriticalSection <> DoneCriticalsection
Is there any reason for it? Is there a will to
Hello!
What is the correct way to set a published dynamic array property in
FPC? In Delphi, you use SetDynArrayProp.
Is SetObjectProp safe (packages\fcl-web\src\base\restbase.pp uses this
approach)? See the attached project.
Ondrej
program TypInfoTBytes;
uses
Classes,
SysUtils,
TypI
On 28.11.2016 17:37, Ondrej Pokorny wrote:
Is SetObjectProp safe?
OK, no it is not - it doesn't increment the reference count for
properties without a setter:
property Data: TBytes write FBytes;
Ondrej
___
fpc-devel maillist - fpc-
Hello,
I have the following code
program FPCcast;
type
TMyClass1 = class
end;
TMyClass2 = class(TMyClass1);
var
O: TMyClass1;
begin
O := TMyClass1.Create;
TMyClass2(O).Free; // << 219-runtime error if compiled with -CR
end.
If I compile it with "-CR", I get a 219-runtime error whe
On 30.12.2016 11:27, Jonas Maebe wrote:
Yes, this is by design. The above code is invalid and relies on
implementation details to work. E.g. with a JVM or CIL backend, the
code would be rejected by the bytecode verifier too.
Thank you Jonas for clarification. It may be worth to document it -
Hello,
I have a simple FPC program:
---
program GermanTest;
{$codepage utf8}
begin
Writeln('ÄäÖöÜüß');
end.
---
If I run it in the console, I see correct characters:
BUT when I redirect the output to a file with ">" :
GermanTest.exe > GermanTest.txt I get corrupted characters "Ž„™”š�á"
(s
On 03.05.2017 9:07, Petr Kristan wrote:
Try:
Writeln(UTF8ToSys('ÄäÖöÜüß'));
No, it doesn't help.
I debugged into the issue and found out that the exported file was in
DOS-850 encoding (the same as the console lived in). Delphi changes the
output encoding to "DefaultSystemCodePage" if Ou
On 02.05.2017 19:20, Michael Van Canneyt wrote:
Changed the bugtraq:url. Revision 36062.
Off-topic:
I now switched from mantis.freepascal.org to bugs.freepascal.org and had
to block the running cheetah icon again.
Remember the good webpage designer (generally speaking UI designer)
rule: Do
Michael, because I cannot comment on a closed issue report I post my
answer to https://bugs.freepascal.org/view.php?id=31746#c100091 here:
> I don't think what you write is correct. As far as I can see in the
code of Delphi Berlin: Delphi uses always the defaultsystemcodepage for
text files, r
Hello!
For the Lazarus IDE I need to call the stored function from a property.
I was able to get the pointer of a static procedure and call it:
function GetStoredFunction(APropInfo: PPropInfo; AInstance:
TPersistent): CodePointer;
var
StoredProcType: Byte;
begin
StoredProcType := ((APropI
On 17.05.2017 18:13, Ondrej Pokorny wrote:
My question is, how can I call a virtual stored procedure from PropInfo?
Digging through the code, I found it:
function GetStoredFunction(APropInfo: PPropInfo; AInstance:
TPersistent): CodePointer;
var
StoredProcType: Byte;
xT: Pointer;
begin
On 02.07.2017 18:20, Jonas Maebe wrote:
Range checking code is generated for operations involving enums if,
according to the type system, the enum can be out of range. Just like
with integer sub-range types.
Allow me a stupid question: how to convert an integer to enum with range
checking? A
On 02.07.2017 18:28, Jonas Maebe wrote:
On 02/07/17 18:26, Ondrej Pokorny wrote:
Allow me a stupid question: how to convert an integer to enum with
range checking?
The current possibilities and possibly improvements have been
mentioned elsewhere in this thread already
* http
On 02.07.2017 18:49, Jonas Maebe wrote:
No, there is no built-in checked conversion from integer to arbitrary
enumeration types. That's why I suggested in the bug report that
started this thread to file a feature request for such a conversion.
Very good :)
Are there any disadvantages of the e
1 - 100 of 384 matches
Mail list logo
