Sven Barth schrieb:
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record
Jonas Maebe schrieb:
On 13 Oct 2011, at 15:02, Paul Ishenin wrote:
Then use {$codepage UTF8} only. This directive treats all ansistring
constants in UTF8 codepage. So the next code:
{$codepage UTF8}
var
s: ansistring;
begin
s := 'utf8 string';
WriteLn(StringCodePage(s));
end.
will output
Michael Schnell schrieb:
When I have a variable of type AnsiString, and assign an string to it,
then its encoding is reported as 1252 (my system codepage). On Paul's
machine it will have a different encoding, I assume?
Via personal consulting ( :) ) I learned that the multiple new Pascal -
Paul Ishenin schrieb:
12.10.2011 16:03, Michael Schnell wrote:
I suppose a variable of the type String is pre-loaded with the
predefined System encoding ID.
If you mean AnsiString then it is loaded with encoding 0 which means
default system codepage. It will get the real encoding number
Sven Barth schrieb:
Am 11.10.2011 23:09, schrieb Hans-Peter Diettrich:
In short, see it as if text now has a mandatory encoding attached. If
the
runtime doesn't know the type, then it is not text, but binary, and you
should treat it as such.
Can you give an example, how the runtime can
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
Please explain what you mean by unicode and what by ansi in your
statement. Without nuancing that, your statement is pretty much meaning
less.
AFAIR Delphi changed the string type to Unicode (UTF-16) in D2009, i.e
Michael Schnell schrieb:
I understand that some day (when the official release comes up) String
will be a new String type and thus ANSIString obsolete and just an alias.
No. string is an alias (generic type), all other string types are
distinct types.
So target encoding ID 0 means that :=
Michael Schnell schrieb:
On 10/12/2011 10:35 AM, Sven Barth wrote:
No. In Delphi String = UnicodeString, but AnsiString still exists as
a one-byte (or multi-byte) string type (the new string type or code
page aware string type).
Sorry, but I don't understand.
According to the TAnsiRec,
Alex Shishkin schrieb:
1) Why UTF8String made incompatible with AnsiString(CP_UTF8)
( UTF8String = type AnsiString(CP_UTF8); )? Why not an alias?
An alias allows to assign strings of *any* encoding, with possibly fatal
consequences. A strict UTF8String type allows for implicit conversion,
Alex Shishkin schrieb:
But the question remains: what is
AnsiString(CP_NONE)?
CP_NONE is not a codepage, it's listed under Clipping Capabilities.
If it is special too, why not just alias and if not what is it?
CP_ACP (0) is the placeholder for the system Ansi CodePage.
DoDi
Michael Schnell schrieb:
On 10/12/2011 02:28 PM, Sven Barth wrote:
There will be a conversion.
Meaning:
- when it is a var parameter, am error message is issued.
- when it is a value parameter: conversion is called
- type cast will do a conversion
Correct, so far.
- assignment will do
Alex Shishkin schrieb:
12.10.2011 16:34, Hans-Peter Diettrich пишет:
Alex Shishkin schrieb:
1) Why UTF8String made incompatible with AnsiString(CP_UTF8)
( UTF8String = type AnsiString(CP_UTF8); )? Why not an alias?
An alias allows to assign strings of *any* encoding, with possibly fatal
Michael Schnell schrieb:
In fact the var parameter case is most interesting regarding new strings.
While in the other cases the system can decide at runtime what do do
(with respect to the encoding ID (s) ), with a var parameter the type
names might be used to generate an error message at
Sven Barth schrieb:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/astrings.inc?revision=19444view=markup
I don't understand the use of encoding 0 and CP_NONE in FPC. Can
somebody explain?
Furthermore I suspect that the implementation of
Function Pos(Const Substr :
Graeme Geldenhuys schrieb:
On 12/10/2011 11:47, Martin Schreiber wrote:
idea. Have a look at Firemonkey and you know what I mean. ;-)
For those unfamiliar with Firemonkey, would you mind explaining further.
...but over all, I do agree with your statement, that FPC shouldn't
follow Delphi
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
variable names etc can all contain Unicode text in there names. So yes,
Unicode is required throughout the Object Pascal language, and
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=19444view=markup
I don't understand the use of encoding 0 and CP_NONE in FPC. Can
somebody explain
Luiz Americo Pereira Camara schrieb:
When this time comes, this is what i see:
1- Most of LCL must be code page agnostic, so not use
UTF8String/AnsiString directly (keep String)
I'd use another type, e.g. LCLstring, which can be set independently
from any other automatisms.
2- It should
Martin schrieb:
In my case that is in synedit. Even if I changed every string in
synedit, it would still be used from the IDE and many user apps, with
just string. So then the text would be corrupted at that point.
Text corruption can occur only when the stored encoding does not match
the
Martin schrieb:
just for how to do
procedure foo(x: utf8string); begin end;
var a: string; //ansistring, but contains already utf8
The encoding will be stored or converted when a string is assigned to
that variable. When the FPC implementation is finished, it should be
impossible to have
Jonas Maebe schrieb:
On 10 Oct 2011, at 22:11, Luiz Americo Pereira Camara wrote:
1- Most of LCL must be code page agnostic, so not use
UTF8String/AnsiString directly (keep String)
There is no difference between ansistring and string in {$mode
delphi} and {$mode objfpc}.
You obviously
Jonas Maebe schrieb:
On 11 Oct 2011, at 00:06, Luiz Americo Pereira Camara wrote:
On 10/10/2011 17:56, Jonas Maebe wrote:
On 10 Oct 2011, at 22:11, Luiz Americo Pereira Camara wrote:
1- Most of LCL must be code page agnostic, so not use
UTF8String/AnsiString directly (keep String)
There is
Luiz Americo Pereira Camara schrieb:
Yes and as i said is a no-no (in my humble opinion) for Lazarus to
change from String to UTF8String or LazString. There are tons of code /
components under Lazarus/LCL ecosystem that would need such change. Also
porting Delphi VCL components would be a lot
Martin schrieb:
Now my question.
Is there (or going to be) an encoding, that is unknown and will never
be converted. but can be assigned to any of the types?
Delphi has no such encoding, it suggests to use TBytes for that purpose
(or the like, dunno remember the name).
An unknown encoding
Marco van de Voort schrieb:
But now we keep using sysutils, and the rest of the RTL. If there is
anything that I want to avoid is telling 15 times a day how people must
change their delphi code to suit FPC.
Such situation is effectively the end of compatibility, the end of sold
components
Martin schrieb:
On 11/10/2011 02:46, Marco van de Voort wrote:
In our previous episode, Martin said:
Now my question.
Is there (or going to be) an encoding, that is unknown and will never
be converted. but can be assigned to any of the types?
Afaik, there is no such thing in Delphi.
Slight
Michael Schnell schrieb:
On 10/11/2011 12:23 AM, Martin wrote:
Utf8ToLower is, (and should) be declared expecting a Utf8String.
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
Because it expects and UTF8 argument, and provides an UTF8 result, so
that no
Michael Schnell schrieb:
On 10/10/2011 11:11 PM, Martin wrote:
But that will always just push the issue to another location.
Somewhere the change from string to utf8string must be made.
??? The new string paradigm is all about changing from utf8string (and
other such types) to string. Isn't
Sven Barth schrieb:
Nevertheless Jonas' statement is correct, because (currently) String =
AnsiString and thus they are the same (and both can currently use code
pages).
Really? This were absolutely incompatible with Delphi!
And it would be as inefficient as using Variant for everything :-(
Michael Schnell schrieb:
On 10/11/2011 11:20 AM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
Because it expects and UTF8 argument, and provides an UTF8 result, so
that no further conversions
Michael Schnell schrieb:
On 10/11/2011 11:30 AM, Paul Ishenin wrote:
11.10.2011 16:52, Michael Schnell wrote:
In fact I still don't understand the difference between a type called
RawByteStringand a basic new String that happens to be set to the
encoding RawByte.
Encoding RawByte as well as
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
components under Lazarus/LCL ecosystem that would need such change. Also
porting Delphi VCL components would be a lot harder.
IMO Lazarus (and FPC) should follow the Delphi way, with strictly
separate Unicode
Marco van de Voort schrieb:
Note that many places that are runtime typed (like tstringlist.loadfromfile)
get a encoding parameter, so that the loading code can convert the encoding
of the file (in encoding parameter) to whatever stringtype tstringlist uses
(typically utf8 or utf16 or default)
Sven Barth schrieb:
Am 11.10.2011 11:35, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
Nevertheless Jonas' statement is correct, because (currently) String =
AnsiString and thus they are the same (and both can currently use code
pages).
Really? This were absolutely incompatible
Michael Schnell schrieb:
On 10/04/2011 10:59 AM, Michael Van Canneyt wrote:
Yes. Each string will have a codepage identifier associated with it.
if, during an assign operation, a difference exists, a conversion will
occur.
(there are of course some exceptions)
GREAT !
Not really :-(
I
Jonas Maebe schrieb:
It does. But also assumes that all registers are used in assembler
blocks, unless the programmer specifies otherwise.
But a:=a+1; does not imply any register usage, and the variable is a
global one?
DoDi
___
fpc-devel
Michael Van Canneyt schrieb:
Then the docs should reflect that properly (item 4.3.30 u : Format
underlined)
?? Ok, that is strange. Before replying I checked the sources, and there
simply is no support for it ?
I will investigate anyway. Either the docs must be adapted, or there is
a
It looks as if fpdoc stops processing paragraphs on u, discarding the
remainder until /p.
See LCL docs on StdCtrls.TCustomComboBox and TCustomLabel.FocusControl.
Should I report an error?
DoDi
___
fpc-devel maillist -
Michael Van Canneyt schrieb:
On Tue, 27 Sep 2011, Hans-Peter Diettrich wrote:
It looks as if fpdoc stops processing paragraphs on u, discarding
the remainder until /p.
See LCL docs on StdCtrls.TCustomComboBox and TCustomLabel.FocusControl.
Should I report an error?
No, since underline
Andrew Brunner schrieb:
On Fri, Sep 23, 2011 at 7:28 AM, Martin Schreiber mse00...@gmail.com wrote:
On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote:
Recently strings behavior was changed, they are now codepage-aware. The
compiler can now implicitly convert strings from one encoding
Skybuck Flying schrieb:
I think the Delphi language has a little problem when it comes to
properties.
I consider C/C++ to be a value language or maybe even a const language
where addresses of classes and fields are constant or hard coded into
instructions.
While Delphi is more of a reference
Skybuck Flying schrieb:
Hello,
I want to write code as follows and I will simplify it here to illustrate
the problem.
Let's say I want to kinds of records: TrecordA and TrecordB.
I want to be able to convert types of TrecordA to TrecordB but I also want
to be able to convert types of TrecordB
Flávio Etrusco schrieb:
IMHO you are seeking the problems in the tools, while the problem is PEBKAC
I partly agree it's PEBKAC, but why make it easy to get wrong when you
can avoid it? Isn't that the point of Pascal?
Many people think that Pascal is an educational (toy) language, and
Luiz Americo Pereira Camara schrieb:
On 17/9/2011 11:46, Hans-Peter Diettrich wrote:
Luiz Americo Pereira Camara schrieb:
The codepage of a RawByteString at runtime will keep the previous
CodePage (65001 for UTF8, 1200 for UTF16) as opposed to change to the
RawbyteString CodePage (65535
DaWorm schrieb:
On Sun, Sep 18, 2011 at 12:01 PM, Sven Barth
pascaldra...@googlemail.com wrote:
On 18.09.2011 17:48, DaWorm wrote:
But isn't it O(n^2) only when actually using unicode strings?
All MBCS encodings, with no fixed character size, suffer from that problem.
Wouldn't you also be
Luiz Americo Pereira Camara schrieb:
Can you give me a link? I checked the XE documentation and RTL, and
could not find that RawByteString can hold UTF-16, and my test
confirms that:
http://edn.embarcadero.com/article/38980
You may read also:
Luiz Americo Pereira Camara schrieb:
Thanks, but that's nothing new to me in general, and the RawByteString
handling doesn't work as documented.
procedure ShowCodePage(const S: RawByteString);
begin
Form1.Caption := IntToStr(StringCodePage(S));
end;
Strange
What value you get passing and
Luiz Americo Pereira Camara schrieb:
The codepage of a RawByteString at runtime will keep the previous
CodePage (65001 for UTF8, 1200 for UTF16) as opposed to change to the
RawbyteString CodePage (65535) as a though previously
Delphi defines RawByteString=AnsiString, so there is no room for
Michael Schnell schrieb:
On 09/15/2011 07:39 PM, Hans-Peter Diettrich wrote:
Only when an application must *interpret* strings in foreign languages,
With UTF-8 German is such a foreign language :(
That's why European users will be happier with UTF-16 (meaning UCS2).
An UCS2String type
Michael Schnell schrieb:
Is migrating to multiple string types (each denoting a certain encoding)
and migrating to cpstrnew (a single string type with dynamical encoding)
a contradiction or can it be consolidated ?
What is supposed to happen to the nasty legacy types called String and
Char
Graeme Geldenhuys schrieb:
On 16/09/2011 11:48, Felipe Monteiro de Carvalho wrote:
What about stuff like this in classes:
TReader = class(TFiler)
function ReadString: string;
function ReadWideString: WideString;
function ReadUnicodeString: UnicodeString;
I'm clearly not
Michael Schnell schrieb:
On 09/15/2011 09:01 PM, Hans-Peter Diettrich wrote:
FPC also allows to use Complex values - but nobody is forced to use
such numbers
German (and French end, ...) Lazarus programmers are Forced to deal with
Unicode if the accept user input. (Newer versions
Martin schrieb:
On 16/09/2011 02:49, Hans-Peter Diettrich wrote:
Martin schrieb:
On 15/09/2011 19:52, Hans-Peter Diettrich wrote:
Graeme Geldenhuys schrieb:
On 14/09/2011 19:17, Hans-Peter Diettrich wrote:
How many users will have to deal with chars outside the Unicode BMP?
Any app
Graeme Geldenhuys schrieb:
There shouldn't be anything complicated for the developer or
enduser. UnicodeString under Linux and Mac should be UTF-8, under
Windows it should be UTF-16.
You're a bit inconsequent ;-)
UTF-8 is much more complicated to handle by the user, than
Michael Schnell schrieb:
On 09/15/2011 09:57 AM, Graeme Geldenhuys wrote:
What the hell has experience got to do with the preference between
UTF-8 and UTF-16?
In fact users want to deal with decently coded characters and not with
cryptic bytes some of which together are representing a
Graeme Geldenhuys schrieb:
On 14/09/2011 17:02, Hans-Peter Diettrich wrote:
Many users still want simple string handling, with direct mapping
between logical and physical chars (SBCS). This is not possible at all
with UTF-8, while UTF-16 works fine with the BMP, at least.
What rubbish
cobines schrieb:
2011/9/15 Michael Schnell mschn...@lumino.de:
Of course. But generations of Pascal programmers have been trained to do
MyChar := MyString[1];
Such people should retrain if they want to switch to Unicode using
some instructions how to convert your application. If they do not
cobines schrieb:
2011/9/15 Michael Schnell mschn...@lumino.de:
In fact users want to deal with decently coded characters and not with
cryptic bytes some of which together are representing a character. (e.g.
when doing MyChar := MyString[1]; )
I think of Unicode text as a stream of Unicode
cobines schrieb:
2011/9/15 Michael Schnell mschn...@lumino.de:
If thy use Lazarus they are forced to use Unicode unless they wand to stick
with a very old version.
Then this is a problem of Lazarus. They want to make applications with
Lazarus (which is always UTF-8?) and they are unaware of
Martin schrieb:
On 15/09/2011 10:38, Michael Schnell wrote:
On 09/15/2011 11:06 AM, Graeme Geldenhuys wrote:
and to show you AGAIN how flawed your direct index access to a
character example is.
It's not my intend to use it. I'll never use it as I do know that it
is bound to create problems.
Michael Schnell schrieb:
On 09/14/2011 05:19 PM, Hans-Peter Diettrich wrote:
Can you specify, *which* strings ever *require* platform specific
encoding?
If not strings, Chars do:
MyString := 'Öse';
MyChar := MyString[1];
So what?
(which platform function would require such coding?)
DoDi
Graeme Geldenhuys schrieb:
On 14/09/2011 19:17, Hans-Peter Diettrich wrote:
How many users will have to deal with chars outside the Unicode BMP?
You are very narrow minded! It depends on the application you are
developing. Lets take a Science application as an example. Many
Marco van de Voort schrieb:
Unicode users have no use for an char type, instead they have to use
substrings for every logical character. A Unicode BMP user could be happy
with a 2-byte char, of course, at his own (low) risk.
Probably. But while a good point for a application builder based in
Martin schrieb:
On 15/09/2011 19:52, Hans-Peter Diettrich wrote:
Graeme Geldenhuys schrieb:
On 14/09/2011 19:17, Hans-Peter Diettrich wrote:
How many users will have to deal with chars outside the Unicode BMP?
Any app that loads a text from disk.
Again: please answer my question first
Marco van de Voort schrieb:
FPC also allows to use Complex values - but nobody is forced to use such
numbers without any good reason and technical (mathematical) background.
The same for the use of astral Unicode characters, IMO.
IMHO you are right, but the big difference is of course that
Graeme Geldenhuys schrieb:
RTL is a mere *display* feature, the chars still are stored from first to
My problem is not the implementation, but the fact that I can't read
or understand any right-to-left languages. :)
Don't worry, a compiler also doesn't understand any but his own
language,
Graeme Geldenhuys schrieb:
On 15 September 2011 20:52, Hans-Peter Diettrich wrote:
When I want a program for German or French users, I'll hire an coder with
experience in those *languages*, not with experience only in Unicode.
Why? We simply hired average people (not programmers) to translate
Felipe Monteiro de Carvalho schrieb:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
One with unicode string, one with ansistring. They will have the same code,
but will be compiled twice, each time with a different compiler define to
decide which version it
Graeme Geldenhuys schrieb:
If FPC has true unicode support, then all functions should work correct
with just the UnicodeString type. That type's encoding is based on the
native encoding of each platform. NO performance hit required.
Can you specify, *which* strings ever *require* platform
Michael Schnell schrieb:
On 09/14/2011 11:05 AM, Marco van de Voort wrote:
First and for all. Backwards compat dropping is not going to happen.
It already has and supposedly can't be avoided. Take a look of what
Lazarus was forced to make out of the identity of ANSIString and
UTF8String
Graeme Geldenhuys schrieb:
As for the text-to-braille functionality, that is outside the scope of
the FPC and RTL. But common sense should prevail, use RTL string
functions to implement your conversion - don't assume 1 byte = 1
character. A unicode aware string iterator could be implemented to
Sven Barth schrieb:
But the debugger can ask the OS to write protect a page or to enable a
page guard (which triggers on write access) and then the corresponding
signal/exception can be catched. This reduces the checks necessary from
the complete process memory down to only the page size.
Flávio Etrusco schrieb:
Right, property getters can have side effects, like all procedures. That's
why I already suggested an hint on property declarations, telling which data
item should be displayed for the property.
Yes. Delphi has/had an option to enable function calls/side effects on
Michael Schnell schrieb:
GDB is built for supporting multiple languages. E.g., its ADA support
has been much better than its C++ support for a long time (although
C++ support is getting fairly good nowadays too).
Unfortunately it seems to be hard (or close to impossible) to work with
the g*
Graeme Geldenhuys schrieb:
On 13/09/2011 01:43, DaWorm wrote:
I don't understand why a property with a getter could ever be ran by a
debugger. If I have a property called NextValue, implanted by a method
Yes, yes, but I am a big boy and know what I am doing, so I do NOT want
the debugger to
Michael Schnell schrieb:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU provides support for this.
It's not the CPU, it's
Jeppe Græsdal Johansen schrieb:
Hardware support for writes to arbitrary memory addresses is
restricted to very few addresses, not really useful.
How many times do you think you need more than 1-2 watchpoints? Lots of
breakpoints I can understand, but I've never found many uses for
Skybuck Flying schrieb:
end
until a b;
^ This code should produce an error becomes end is not ended with a
semicolon – ;
Please understand Pascal first, before you try to modify it.
DoDi
___
fpc-devel maillist -
Martin schrieb:
More than that, Lazarus is not the only way to use the info, people use
other IDEs or gdb directly = all that needs to be considered.
You can't have one tool for everybody and everything. A debugger can not
(and must not) know about all languages. Language specific support
Graeme Geldenhuys schrieb:
Just the other day I had to use Delphi 7 again to do some maintenance on
one of our older products. That's when I again came to the realization
what dismal state FPC's debugging support is at - it's like travelling
back in time to the early 80's where using writeln()
Graeme Geldenhuys schrieb:
If anybody with the know how is interested in implementing a Object
Pascal based debugger (or extending Duby specifically for use with FPC),
please let me know. I am more than willing to pay a few hundred US
dollars (or Euros) towards this bounty.
I'd add another
Martin schrieb:
You can't have one tool for everybody and everything. A debugger can
not (and must not) know about all languages. Language specific support
IMO should reside in another layer (IDE, plugin...) between the
debugger and the user.
Never said that. My statement was about pascal
Martin schrieb:
On 12/09/2011 11:06, Hans-Peter Diettrich wrote:
IMO debugging support was one of the reasons, why Kylix was based on
Wine, and the cross-platform versions of Delphi use remote debugging
only. For that implementation a tiny (remote) debugger interface is
sufficient
Michael Schnell schrieb:
On 09/12/2011 12:18 PM, Hans-Peter Diettrich wrote:
I'd add another 100€ for reasonable debugging support in Lazarus :-)
Could you generate a wish-List ?
For now: see my notes on Graeme's wish list.
I haven't been debugging for a while, because it mostly ended up
Graeme Geldenhuys schrieb:
Here is what I would consider a debugger:
- command line interface at least
Me: GUI interface at least.
Where GUI is not a special property of the interface, only a set of
(callback) procedures that allow to implement desired language-specific
display features,
Paul Ishenin schrieb:
12.09.2011 19:00, Martin Schreiber wrote:
True. And maintaining all platforms is a fulltime job too. And a FPC
only debugger can not debug linked c libraries which we can do
currently with gdb. And think of the remote debugging options gdb
provides with many targets.
As
DaWorm schrieb:
I don't understand why a property with a getter could ever be ran by a
debugger. If I have a property called NextValue, implanted by a method
called GetNextValue, that increments a field, stores it in a database,
and returns the new value, I absolutely do not want the debugger
Thanks for the improvements in the last updates, but...
How do I obtain the latest documentation on FPDoc?
For records with variant parts, no short descriptions are shown for the
members in the variant part. Parameters for overloaded methods are
already supported, so this extension should not
Michael Van Canneyt schrieb:
How do I obtain the latest documentation on FPDoc?
make fpdoc.pdf in docs.
No Latex support here (Win7)
For records with variant parts, no short descriptions are shown for
the members in the variant part. Parameters for overloaded methods are
already
Michael Van Canneyt schrieb:
I'm a user of fpdoc, not a maintainer, have no idea of the internals.
In that case, please do not say things like
'this extension should not be too hard to implement'
But please, file a bug report so we won't forget.
This whole threads is about bugs and
Skybuck Flying schrieb:
Nano would be:
One integer type, one string type, branch support, loop support, basic
support, object orientation support, property support, array support,
virtual methods support.
You'll have much trouble in *removing* existing features from FPC,
affecting parser,
Hans-Peter Diettrich schrieb:
It looks like FPDoc links to an inherited item (method), when only a
short description is provided for an overridden method. Is this intended
behaviour? (see Controls.TDragControlObject)
I also have the impression that FPDoc does not (always) overwrite
existing
It looks like FPDoc links to an inherited item (method), when only a
short description is provided for an overridden method. Is this intended
behaviour? (see Controls.TDragControlObject)
The short description is shown e.g. in the class declaration, but the
link from there goes to the
Since a few weeks I cannot rebuild fpc any more, using fpc 2.5.1.
make clean all fails with the always same error message(s):
fgl.pp(136,38) Error: Generics without specialization cannot be used as
a type for a variable
[...]
What's wrong?
DoDi
Sven Barth schrieb:
Am 08.09.2011 14:39, schrieb Hans-Peter Diettrich:
Since a few weeks I cannot rebuild fpc any more, using fpc 2.5.1.
make clean all fails with the always same error message(s):
fgl.pp(136,38) Error: Generics without specialization cannot be used as
a type for a variable
Michael Van Canneyt schrieb:
Have a look at the lcl grids How to... topic, and try to find out
where a passage
#text var #text
might violate any fpdoc assumption.
For starters, you can't have a ul in a table cell.
That's allowed:
tr
tdTitleStyle/td
Felipe Monteiro de Carvalho schrieb:
I just added fpvectorial to Makefile.fpc ... I would be very happy if
a gentle soul could rebuild the makefile =) I always have trouble with
that...
Also graph and systhreads should be added to the rtl docs, and sqldb to
the fcl.
DoDi
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
Also graph and systhreads should be added to the rtl docs, and sqldb to
the fcl.
systhreads?
Sorry: systhrds (see fpcdocs directory)
DoDi
___
fpc-devel maillist
Michael Van Canneyt schrieb:
Argh, such constructs are really hard to find :-(
Not really, the error message tells you where to look.
Have a look at the lcl grids How to... topic, and try to find out
where a passage
#text var #text
might violate any fpdoc assumption.
Even if I could
Currently I'm working on the LCL documentation, on Win7, using
Lazarus\docs\html\build_lcl_docs.lpr on Win7. Here I ran into some problems:
There's something wrong with table row spacing, in all fpdoc generated
HTML files. All fpdoc generated tables (lists of types, classes...) have
excess
401 - 500 of 951 matches
Mail list logo
