hard to implement feature - "include directive" which allows to use
macroses and constants from .pas, .h and .cpp files.
--
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-b
y for Clone and fpc_Addref for Copy is misleading.
I know Florian insisted on Copy and Clone names but still for my taste
it would be the best to have conformity between compiler and RTL.
--
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-
03.02.2014 9:42, Martin Frb пишет:
It also appears that the "." takes precedence over @
@Object.Foo
is equal to
@(Object.Foo)
well otherwise it could not compile
In this case "." is not operator.
Best regards,
Paul Ishenin
__
damage trunk and destroy Paul's dreams :)
I have nothing against if you think there are no risks to delay the
release for more than a year.
Let's see how well I fare; 2.8.0 is not for next month anyway. First
get 2.6.4 out of the door.
Best regards,
Pa
s having the unicode string support if none of the classes
or units make use of it ? No-one will test it or even be able to test
it because none of the base classes/routines are adapted to it.
We have string, file and console routings for use and testing.
Best r
huge changes we have in trunk as is
(maybe together with resourcestring solution). Then with the following
minor releases we improve dotted unit names support (like default
namespaces) together with experiments for ansi/unicode RTL.
Best regards,
Paul Is
g the unicodestring move and check whether something minor can be
added to FPC.
All major changes like the new TStringList class based on UnicodeString
should wait for 2.8 release.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-
regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
06.10.13, 3:08, Martin пишет:
On the other hand
var a: longint;
generates the same. Why?
Because Integer is an alias - inside compiler only the symbol is
different for thise case and the definition is the same.
Best regards,
Paul Ishenin
___
fpc
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
04.08.13, 20:20, Sven Barth пишет:
Then I just need to wait until you've done the 635364 other items on
your list. Sounds doable :P
This is not doable even if Florian will do 10 items per day. The life is
not as long as we wish.
Best regards,
Paul Is
(UnicodeChar is tkWChar).
I also don't know why we have it. Compiler does not use it.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
29.05.2013 14:06, Michel Catudal пишет:
The one that I compiled before the code was broken
To answer on your question I need to know paticular compiler version.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
e RTL.
What starting compiler do you use?
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
don't need RTTI unit then it will be much more simplier to
implement your requirements.
Attributes are half ready in a branch. RTTI for non-published elements
(together with $RTTI directive) is not a very hard task.
Best regards,
Paul Ishenin
___
asked Maciej Izak
what he wants from extended RTTI. Maybe this is a small subset which is
not very hard to implement.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc
lease tell what exactly you are waiting for?
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
17.05.2013 8:59, Paul Ishenin пишет:
Yes. The RTTI for that type seems to be completely messed up in
current trunk. Probably caused by r24458.
Dynamic arrays were not touched by this revision. I only changed RTTI
for non-dynamic array types.
Heh. But in the Martic example was "array[..
trunk.
Probably caused by r24458.
Dynamic arrays were not touched by this revision. I only changed RTTI
for non-dynamic array types.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman
13.05.13, 18:36, Martin пишет:
Makes sense, since it does not work for properties, but only for fields.
The access to record fields is intended though?
Yes.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
le of how to deal with this new RTTI and some more
information by the following link:
http://wiki.lazarus.freepascal.org/User_Changes_Trunk#RTTI_changes
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
out ACharLength : Integer) : UCS4Char; overload;
At the same time even without UTF8 overloads compiler will insert
implicit conversion from UTF8String to UnicodeString when you pass it to
that functions. So UTF8 overloads can only increase spead by removing 1
implicit conversion.
Best regard
ning Demand
without assigning Patches has almost no effect :)
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
; overload;
function ConvertToUtf32(const AHighSurrogate, ALowSurrogate : UnicodeChar)
: UCS4Char; overload;
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
d packages built with -Cr. It
has more failures than a regular build.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
you?
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
er mail of Michael I already look at this more tolerant now. So
please let's stop this endless dispute about nothing. We have different
vision and this is good after all.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.free
05.03.13, 17:55, Sven Barth wrote:
@Paul: see? :)
I see you, Graeme, Michael and probably some more 5-6 developers.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
Okay.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ander who had failed to port his project
to FPC + Laz because of many incompatilities in both projects.
I remember Fib+ developer who stoped his effort to port component to FPC
after some found incompatibilities.
There is nothing good in incomp
arus components.
Mode ObjFPC is not for Delphi compatiblity. It's there to implement a
cleaner variant of the (Object) Pascal language (and Michael wrote), and
if that means higher maintenance burden, so be it.
That cleaner variants split pascal for nothing - to make 3-5 developers
happy.
contact with some delphi team members on their forum on twitter
and on some blogs but without result.
Regards FPC, I would indeed remove FPC mode. Those who need it can use
FPC 2.6. I would also minimize the difference between objfpc and delphi
modes.
Best regards,
Paul Ishenin
gainst 2 implementations of 1 feature: one to
be delphi compatible, one to satisfy few people from pascal community.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
x27;m totally agree. 2 implementations complicates the compiler and
complicates the use of the compiler. Component developers and those who
plant to port their delphi projects will not use objfpc mode if it will
not be delphi compatible.
Best regards,
Paul Is
extensions.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
12.02.2013 18:58, Nicola wrote:
Rec1.a := 123;
Log('with: ' + IntToStr(Data.Rec1.a));// !!FAIL!!, it
shows 0
Non JVM compiler outputs 123. So indeed a JVM compiler bug.
Best regards,
Paul Ishenin
___
fpc-deve
t.PrintSize:
class procedure TLongIntHelper.PrintSize;
begin
WriteLn(SizeOf(LongInt));
end;
static methods don't have a magic Self variable.
In any case I suggest to look for test which had been commited together
with Sven patch.
Best regards,
Paul Ishenin
__
pilation aborted
>
> The compiler is freshly generated from the SVN
>
> Does the compiler expect special options to invoke the record helper
feature?
Did you add "{$mode objfpc}" to your program?
Look at the compile string argument: -Mobjfpc
Best regards,
Paul Isheni
iler is freshly generated from the SVN
Does the compiler expect special options to invoke the record helper
feature?
Nothing. On objFPC mode which you use they are enabled by default. It is
something with your compiler. Mine compiles your code.
Best regards,
Paul Ishenin
___
will not be a type,
so you'll have to force a type by constructor:
s := TPoint(x,y).ToString;
or, as it is currently, by a special function:
s := Point(x,y).ToString;
or with a record constructor:
TPoint.Create(X, Y).ToString;
Best regards,
Paul Is
06.02.13, 19:29, Michael Schnell пишет:
but I feel
point.x := x;
point.y := y;
s := point.ToString;
is most clear.
This is what you can already do in FPC 2.6.0 with advanced records
feature active.
Best regards,
Paul Ishenin
___
fpc
29.01.13, 17:23, Hans-Peter Diettrich пишет:
Paul Ishenin schrieb:
At least it's more fun to implement
something very new, instead of working on incomplete parts (loadable
libraries, targets) which had been delayed due to problems. The same
situation in Lazarus and in many open source pro
pen source projects BTW.
Where are your patches for loadable libraries and new targets?
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
28.01.13, 21:51, Michael Van Canneyt пишет:
Enough bickering; it is useless. We will not agree, no matter how many
arguments are presented: simply because the arguments are of a
metaphysical/human/whatever nature, and not technical.
Agreed.
Best regards,
Paul Ishenin
write big programs in
javascript and the anonymous methods easily confuse the javascript
debuggers.
You can use named methods too wihout drawbacks. Of course one of the
benefits of anonymouse methods is javascript is access to local
variables. And I don't notice that chrome debugger is confus
ing to say that this is one of these things where Delphi could
simply have re-instated the TP-style objects. The compiler compiled them
anyway already.
There was no need to burden records with methods in an attempt to make
them 'object-like'
nymouse methods in pascal - I use them in javascript when
I need to perform something asynchronosly.
I use avanced record syntax because it makes code more understandable.
I scarry to use generics but that simple because they have many bugs.
Best regards,
Paul Ishenin
__
ase type for such a small
task as returning a key in for-in loop.
And (for Michael) I don't see any beauty in this. Imo, initial index
extension is much more beauty than suggested here (a,b,c) := d;
constructions.
Best regards,
Paul Ishenin
___
fp
26.01.13, 6:57, Alexander Klenin пишет:
Why to invent a new solution if Delphi already have one:
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/anonymousmethods_xml.html
Best regards,
Paul Ishenin
need to add for Delphi's generics support...
This for-in-index is a peace of cake to parse in comparison.
I confirm. When I tried think how to add delphi like generic parse to
language I also had this nightnares. As result I simple stoped to work
on them.
Best r
when operators for simple types are present in the language
it is too late to care about explicitly declarative language. It is
simple not explicit anymore.
And index (or better to call it key) extension for for-in loop will not
make it less explicit for sure.
Best regards,
Paul Ishenin
sion for
ObjP dialect and in general?
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
x variable.
- If not then the for loop can only behave as current for in loops.
Of course.
Then I also have nothing against this feature. If it is controllable by
enumrator to allow/reject this then it is ok.
Best regards,
Paul Ishenin
___
fpc-deve
application bundles as I know, so they
can be edited by external programs too.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
). Delphi now stores ResourceStrings as UnicodeString type. I
think FPC will follow this in m_default_unicodestring modeswitch.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman
gards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
production code already uses it, then the production code writers must
have taken a risk for change knowing that this was a not yet released
feature.
This is exactly my minds.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel
ink that should be something generics related since Sven is
working on them last time (as well as on record helpers for simple types).
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/ma
rely on it in LCL:
var
Data: array[0..2] of Integer;
begin
WriteLn(MemSize(@Data[0]));
end.
Without heaptrc on 32bit windows:
4294967284
With heaptrc:
0
--
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepasca
t got "Intf2"
Did you try with "C.GetIntf as Intf2"? That should be the correct way to
do this...
Yes, but it does not work.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepa
I'm asking because without -CR the code compiles and with it gives an
error Error: Class or COM interface type expected, but got "Intf2"
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.fr
21.08.12, 23:21, Sven Barth пишет:
There must also be a function to return the number of bytes.
Does someone know the name?
Length(s) * SizeOf(s[1])
It has the name ByteLength()
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel
strings are still ansi strings even in delphi
unicode mode.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ecause your constant is encoded
in utf8.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
rence to a class then look at how it
is done with tobjectdef.childof or tobjectdef.extendeddef.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ng it.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
05.05.2012 14:23, Paul Ishenin wrote:
Probably this happen because of some bug fix because I have the same
error in delphi:
htest.pas(44)
Test.lpr(41) Error: E2003 Undeclared identifier: 'CLSInfo'
Test.lpr(42) Error: E2003 Undeclared identifier: 'ACLInfo'
Test.lpr(49)
Undeclared identifier: 'CLSInfo'
Test.lpr(42) Error: E2003 Undeclared identifier: 'ACLInfo'
Test.lpr(49)
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
backwards compatibility are documented at:
http://wiki.freepascal.org/User_Changes_2.6.0
...
Details about these new features can be found at
http://wiki.freepascal.org/FPC_New_Features_2.6.0
Best regards,
Paul Ishenin
___
fpc-devel maillist -
will sit then and criticize them.
If you don't like the dish - cook yourself.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
02.05.2012 15:00, Hans-Peter Diettrich wrote:
To the user this means "not compatible with D7 nor D2009" :-[
It is both compatible with D7 and some D2009 features.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.free
04.04.2012 17:08, kyan написал:
Delphi doesn't support qword at all, so there is no Delphi behaviour to
be compatible with in that case. Or at least it didn't when the above
was implemented. Does it now?
No, it does not.
Delphi XE has a UInt64 type. From the documentation:
UInt64 represents
04.04.2012 16:34, Jonas Maebe wrote:
Delphi doesn't support qword at all, so there is no Delphi behaviour to
be compatible with in that case. Or at least it didn't when the above
was implemented. Does it now?
No, it does not.
Best regards,
Pa
20.03.12 19:02, Jonas Maebe написал:
That's of course a very old version of gdb (some fork based on 6.3.50),
so maybe it's a regression.
As I remember this was fixed in fpc trunk only?
Best regards,
Paul Ishenin
___
fpc-devel maillist -
y - to show the visibility in inspect window for example. More
you know - better.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
property_dec;
begin
...
message(parser_e_resourcestring_only_sg);
This should give an error about resource strings when you have a deal
with a property.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
level.
If this is not some FPC feature unknown to me I will fix it.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
error.
But when trying to read the property
UnitFoo.pas(999,3) Error: Wrong number of parameters specified for call
to "FunctionFromOtherUnit"
Can you submit a more complete example?
Best regards,
Paul Ishenin
___
fpc-devel maillist -
codepage}).
In Delphi resourcestrings are unicodestrings but this is not so in FPC
because team still not decided about the default string type.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.o
e replaced by (or retyped into) UnicodeString now? IMO
only the Windows COM libraries require real WideString (BSTR) arguments,
while the ordinary "W" API should be happy with pointers to UnicodeStrings.
I agree that better to review fcl-xml code and at least replace
WideStrings with U
20.12.2011 10:47, Felipe Monteiro de Carvalho пишет:
On Tue, Dec 20, 2011 at 1:00 AM, Paul Ishenin wrote:
Final methods can't be overriden in the descendants. But what are final
fields for?
I think they are the way to write a constant in Java. Because they
have no procedural elements,
18.12.2011 20:45, Jonas Maebe wrote:
And final fields.
Final methods can't be overriden in the descendants. But what are final
fields for?
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
application (though Lazarus first
needs to learn about the "unicodestrings" modeswitch,
What's that?
A modeswitch introduced in the JVM branch to turn the string type to
unicodestring (similar to {$H+} turns string to ansistring).
Best regard
l but full example to the bug tracker?
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
application.
Btw, this article may be very useful for the task you are doing:
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=1392
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
WideString=UnicodeString?
I don't remember exactly but it is seems to me that delphi also uses
unicodestring for WideStrings on osx.
If this is ideed so it will be easy to check.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-
they should affect you? Do you any ansistring type
except 'AnsiString' in your applications?
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
e new ansistring type.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
23.10.2011 20:01, Paul Ishenin пишет:
23.10.11 19:49, 4iter пишет:
Hi!
Fatal: Compilation aborted
..
Maybe fixit it with #ifdef ?
How to define this ifdef?
Maybe it could be fixed either by dynamic loading or weakexternal
directive?
I tried to
ently uses GNU libiconv. So a weak symbol is
probably the best solution.
Does weaksymbol works on all platforms where cwstrings is used (I know
that it is not implemented on windows at least but there we don't need
cwstrings too)?
Best regards,
Pa
23.10.11 19:49, 4iter пишет:
Hi!
Fatal: Compilation aborted
..
Maybe fixit it with #ifdef ?
How to define this ifdef?
Maybe it could be fixed either by dynamic loading or weakexternal directive?
Best regards,
Paul Ishenin
stopping
Fatal: Compilation aborted
...
Are you using the latest released FPC = fpc 2.4.4 to build the trunk? If
not please build with it. Building trunk compiler by an earlier version
of trunk compiler is not supported.
Best regards,
Paul Ishenin
__
ments
instead of RawByteString and therefore the conversion will be made
before the byte compare.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
le
always contains strings encoded in the DefaultSystemCodePage? If you
assign e.g. a string(866) variable to a plain ansistring variable,
then such a conversion is also done, no?
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.free
13.10.2011 16:30, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 10:26 AM, Paul Ishenin wrote:
It will affect as well as compiler directive you suggested to add.
No, the directive is per source code file. 3rd party libraries do not
need to use it.
Then use {$codepage UTF8} only
13.10.2011 16:14, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 9:44 AM, Paul Ishenin wrote:
The later can be made by call SetMultiByteConversionCodePage(CP_UTF8) at the
program start.
From my comment on the bug report:
Won't SetMultyByteConversionCodePage inadvertedly a
SetMultiByteConversionCodePage(CP_UTF8) at
the program start.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
13.10.2011 14:57, Hans-Peter Diettrich пишет:
Paul Ishenin schrieb:
13.10.2011 9:13, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/astrings.inc?revision=19444&view=markup
I don't understand the use of encoding 0 and C
1 - 100 of 499 matches
Mail list logo
