Martin schrieb:
On 21/07/2012 16:55, Ivanko B wrote:
The problem now is that cracker classes can't be used in future anymore
because of the new class field ordering optimisation, so I dared to
ask.
So, is it possible to design the new feature in such way that to have
an option to
Sven Barth schrieb:
Should FPC provide a way to access private fields from any other
code?
Like recent Delphi versions allow by extended RTTI? shudder
FPC will support extended RTTI sooner or later as well.
Hopefully with better means to disable it.
Finally class helpers
Michael Van Canneyt schrieb:
The base classes expose a well-defined API. This API is a contract you
make with the developers of descendent classes.
Which you don't know when designing a base class.
Some fields are kept private to ensure that the terms of the contract
can be met. Making them
silvioprog schrieb:
I could easily do this using copy, but I'm trying (without success)
to do this at low level.
...where you get what you asked for ;-)
Why do you want to do things at low level, which can be done easily on
high level?
DoDi
___
Graeme Geldenhuys schrieb:
On 15 July 2012 19:04, Michael Van Canneyt mich...@freepascal.org wrote:
Usually these things are private for a reason. But maybe there are better
reasons for doing it different, of course then I'd like to hear them first
:)
Yes, and I just wanted to point out that
Michael Van Canneyt schrieb:
Simply specify the Delphi version, to which FPC 2.6.1 should be
compatible, then the rest is clear.
There is no such version.
2.6.1 is in many ways D7 compatible, but also has a lot of D20O9
compatible features.
I wonder what in many ways here means?
To the
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
The solution is so easy: don't mark it as deprecated.
I also have a clear opinion about Delphi compatibility: Every FPC
version must be compatible to a Delphi version. A mix of incompatible
features from different
Tomas Hajny schrieb:
On Wed, May 2, 2012 12:27, Hans-Peter Diettrich wrote:
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
The solution is so easy: don't mark it as deprecated.
I also have a clear opinion about Delphi compatibility: Every FPC
version must
Paul Ishenin schrieb:
02.05.12 18:18, Graeme Geldenhuys wrote:
So instead of jumping around with various delphi versions (a bit of D7
and a bit of 2009 etc), maybe start from the oldest delphi version
(eg: D7) and move towards the newest?
Maybe you can teach us how to do this by sending
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about may change
somehow, in the next version is of no real
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about may change
somehow, in the next version is of no real
Jonas Maebe schrieb:
Graeme Geldenhuys wrote on Wed, 25 Apr 2012:
On 25 April 2012 11:08, Ludo Brands ludo.bra...@free.fr wrote:
I understand. Just wanted to clarify that, to my knowledge, all 3rd
party
dataset descendants and some other programs using bookmarks are
affected by
a change
Jonas Maebe schrieb:
But on windows, if you specify the INSTALL_PREFIX with a trailing
\ (which afaik is a normal way to specify a directory),
I'm not aware of any standard for specifying directory names on
command lines that suggests either including or not including a
trailing directory
I wonder about much code in the RTL/FCL, that depends on String type
arguments, like:
Procedure TStream.WriteAnsiString (const S : String);
Var L : Longint;
begin
L:=Length(S);
WriteBuffer (L,SizeOf(L));
WriteBuffer (Pointer(S)^,L);
end;
This method will work only as long
Martin schrieb:
When C2 gets the opREmove, it must mot just remove it's own entry, but
also remove the entry C1 has
The meaning of opRemove is unclear. IMO it doesn't make sense in the
example code, because the owner of a component can change many times,
without meaning that the component
Paul Ishenin schrieb:
You found some bug in the compiler. Property can only be declared inside
a structure but compiler allowed to do this in a unit level.
AFAIK unit-properties are an intentional FPC extension over Delphi.
I already used it for debugging purposes, replacing global variables
ik schrieb:
I think it's a Delphi bug to act like that. You must provide a length
that is not bigger in size. It's up to you the developer.
Otherwise you might have more then one type of buffer overflows in your code !
The way Delphi solved it, is by taking the responsibility from the
Alexander Shishkin schrieb:
You also may refactor your class and define array as a pointer to array
(dont use dynamic array - they are zero initialized) and manage memory
manually ( [Get|Realloc|Free]Mem ).
IMO dynamic arrays are not initialized, at least not in Delphi. Only the
pointer is
Vincent Snijders schrieb:
Op 24 februari 2012 13:40 heeft Hans-Peter Diettrich
drdiettri...@aol.com het volgende geschreven:
IMO dynamic arrays are not initialized, at least not in Delphi. Only the
pointer is initialized (to Nil).
IMO one should not use IMO when claiming easily verifiable
Amir schrieb:
Hi,
I have a code, developed in object pascal, with many classes. The
project is working fine.
Today, I used callgrind (valgrind --tool=calgrind) to see which
function consumes the most execution time and I noticed that the most of
time in my project is consumed by fillchar
Thanks for updating some units :-)
I still feel a need for more updates, to replace e.g. WideString in e.g.
xmlread.pp.
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The extended syntax of hint tokens should be reflected in IsTokenHint.
See oldlinux.pp:
unit oldlinux deprecated 'Use Baseunix/Unix';
Perhaps it's sufficient to skip the next token after an hint, when it is
a string literal? Dunno about the concrete syntax changes...
DoDi
In an attempt to check the yet undocumented FCL units for use with FPDoc
and MakeSkel, I got an error in the created skeleton for gmp:
element name=operator (MPFloat, MPFloat): Boolean
The and chars in operator names should be escaped in the XML files.
Is this easy to fix, or should I dig
michael.vancann...@wisa.be schrieb:
I have this fixed locally, but it is not yet committed.
Thanks for the quick fix :-)
I'll check again when committed.
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
michael.vancann...@wisa.be schrieb:
In an attempt to check the yet undocumented FCL units for use with
FPDoc and MakeSkel, I got an error in the created skeleton for gmp:
element name=operator (MPFloat, MPFloat): Boolean
The and chars in operator names should be escaped in the XML
files.
After adding documentation for some items in the FPDoc Editor, I have
problems running MakeSkel or FPDoc. Both report errors in the input
file, which seem to be related to wrong or missing compiler options for
that file.
How can a documentation writer determine the required compiler options,
michael.vancann...@wisa.be schrieb:
It may be a bad example (work in progress?), but I couldn't figure out
the required compiler options for e.g. fcl-process/pipesipc.pp, in an
attempt to create the skeletons for the fcl-process package.
Why would you want to do that ?
I simply wanted to
Tomas Hajny schrieb:
The Intel x86 (and thus also Pentium) opcodes like AAD (ASCII
adjust before division), etc., suggest some dependency, but I admit
that I didn't try to analyze what results it would have with EBCDIC.
BCD values are stored as nibbles (4 bit binary values), which are
Again I found almost all of my notes removed from the LCL documentation.
If this is how my work is honored, I see no reason why I should spend
any more time with contributing to the Lazarus documentation :-(
When somebody is not happy with notes about wrong or missing
documentation in the
steve smithers schrieb:
The bit that provides code for VM/SP as opposed to say MVS, is the RTL,
so if I want to open a file, there is a routine in the RTL called OpenFile
(or whatever) that issues the VM code for open. This lives in System.pp
or Sysfile.pp or whatever it's called in the
steve smithers schrieb:
Regardless of what you may believe, FreePascal is not the first compiler to be
implemented on 370 architecture.
I.e. you can study how they create code, before you reinvent the wheel :-)
DoDi
___
fpc-devel maillist -
Mark Morgan Lloyd schrieb:
Hans-Peter Diettrich wrote:
steve smithers schrieb:
Regardless of what you may believe, FreePascal is not the first
compiler to be
implemented on 370 architecture.
I.e. you can study how they create code, before you reinvent the wheel
:-)
:-) Had occurred
Felipe Monteiro de Carvalho schrieb:
2012/2/8 Tomas Hajny xhaj...@hajny.biz:
If your intention was to keep the programs
working with Win9x, this won't help because the program containing
unresolved imports wouldn't start anyway. Is there any other reason?
Windows9x has all W functions,
rvmart...@ntlworld.com schrieb:
Where can I find details of the input to the back-end?
The node tree contains the parsed instructions, and their argument
descriptors should refer to the related variables and types (see
node.pas for an start). You'll have to implement the code generation at
Felipe Monteiro de Carvalho schrieb:
Hello,
SysUtils for Windows utilizes only A Windows APIs, while it could use
W APIs in Windows NT. The attached patch starts correcting improving
the situation.
Advantages of the patch:
* Allows for unicode file names in TStringList.LoadFromFile if you
Michael Van Canneyt schrieb:
As you know, we are very keen on backwards compatibility.
ACK.
Are you sure that if a AnsiString filename which contains
codepage-specific characters is used to open a file, it will still open
the same file after this patch is applied ?
Win32 filesystems
steve smithers schrieb:
Base / Displacement consists of a 16 bit value, the first 4 bits enumerate a
register, and the other 12 bits hold a displacement from 0 to 4095. The actual
or Effective address for each storage operand is calculated as the unsigned
addition of the value held in the base
michael.vancann...@wisa.be schrieb:
In each case: If you want to file bug reports, please use the
official sources only to
reproduce the problem.
FPDoc (trunk) exits with an AV, when I want to make the trunk RTL docs
on Win7:
make rtl.chk
Is there any mandatory option missing from the
Michael Van Canneyt schrieb:
Well, It took me about 15 lines to implement it in dglobals.pas of fpdoc.
I moved one function out of fpdocoptsxml to mkfpdoc to split the input
line.
First tests work fine. See revision 20213.
A fine solution :-)
I happen to get an AV during the Engine
I wonder how these many messages occur, even in building the libraries.
Is it only lazyness why according fixes are missing, or are there
reasons why such conversions are inevitable?
Dumb question: what's the default string type in FPC trunk? When it's
AnsiString, in which situations are
michael.vancann...@wisa.be schrieb:
One reason may be the different assumptions about the content of the
FProcessedUnits list, where either the input file part or the entire
input specification is stored. But this seems not to be the only bug :-(
The entire input spec is stored.
Only in
Paul Ishenin schrieb:
02.02.2012 17:00, Hans-Peter Diettrich пишет:
Dumb question: what's the default string type in FPC trunk? When it's
AnsiString, in which situations are UnicodeString conversions really
required, in contrast to pre-UnicodeString versions?
The default string type
Sven Barth schrieb:
Am 31.01.2012 14:42, schrieb Hans-Peter Diettrich:
I still wonder why the number of units in the imported RTL package
increases over time. Initially it contains 7 modules, and 38 modules in
the end, where the RTL currently consists of 46 units. 6 of the initial
modules
michael.vancann...@wisa.be schrieb:
Why do you need this ? You make it quite complicated.
All you need is a FindModule(Const AName,AFileHint : String) :
TPasModule call in TPasTreeContainer which must be overridden in a
descendent (such as TFPDocEngine). The default implementation returns
In an attempt to help improve fpdoc I'm blocked in understanding the
handling of imported modules. The content files are imported into the
link tree, but this tree seems not to be used in finding external
identifiers?
Instead packages are searched, where I could not yet figure out how
these
Marco van de Voort schrieb:
I've seen 2.5 usb-only HDD's crash laptops, and my experiences with other
arm devices (Sheeva, goflex are the same).
In short, no devices that don't have an own PSU.
My experience is quite different from yours. I've a couple of external
3.5 HHDs with external
Michael Van Canneyt schrieb:
On Tue, 31 Jan 2012, Hans-Peter Diettrich wrote:
In an attempt to help improve fpdoc I'm blocked in understanding the
handling of imported modules. The content files are imported into the
link tree, but this tree seems not to be used in finding external
Mark Morgan Lloyd schrieb:
Sorry, you've missed my point. I've come across systems where compilers
have to be blessed by the local security administrator before they can
mark code as executable, and there's a progressively stronger chain up
to the point where nobody except that manufacturer
steve smithers schrieb:
Finally, the suggestions about developing FreePascal/370 as an ASCII compiler
seem somewhat pointless to me. Why would anyone want to use an ASCII compiler
on an EBCDIC system? I accept fully that producing an EBCDIC version will
present problems, but if this compiler
Michael Van Canneyt schrieb:
Well, you have the sources, you can look up the actual implementation.
Then you would see that:
Please don't confuse syntax and semantics. Reading source code reveals
only *what* is done, but not *why* it's done, and what are the consequences.
* The fpdoc
Marco van de Voort schrieb:
In our previous episode, Mattias Gaertner said:
[...]
For the --input-dir there is an extra reason: the order of files is important.
Just like in the compiler, which must compile dependent units first, fpdoc
should first document dependent units. It currently does
michael.vancann...@wisa.be schrieb:
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote:
should first document dependent units. It currently does not know how
to do this by itself.
Again, what are you talking about? FPDoc doesn't require a special
order of input files, neither source nor
Marco van de Voort schrieb:
In our previous episode, Michael Van Canneyt said:
Meanwhile I have a simple example using 2 units floating around somewhere.
It took me lots of time to find it, but now I know where the cause is.
Solving it is another matter entirely.
I've been thinking about it,
Michael Van Canneyt schrieb:
Otherwise funny things will happen with duplicate identifiers.
I know. The problem will get only worse with nested type declarations,
which are next on my todo list.
One more problem introduced by uneducated Delphi developers. Must FPC
really follow all these
Michael Van Canneyt schrieb:
The LCL documentation build sorts the units alphabetically, and this
also seems to work.
Of course it produces documentation, but cross-links can and will fail
because the correct target is not found.
For cross-links to be correct, the order must be correct.
Michael Van Canneyt schrieb:
On Sat, 28 Jan 2012, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote:
should first document dependent units. It currently does not know
how to do this by itself.
Again, what are you talking about
Michael Van Canneyt schrieb:
On Sat, 28 Jan 2012, Hans-Peter Diettrich wrote:
I still don't understand this requirement, and how documentation
writers should establish the correct order :-(
Simple.
The same order as the compiler uses: it is 100% determined by the
uses clause.
How
Marco van de Voort schrieb:
In our previous episode, Michael Van Canneyt said:
The question you asked:
How is that related to documentation and the order of input files?
I've the feeling that Dodi assumes all references are fully qualified and
not just the inter-package ones?
No. I'm
michael.vancann...@wisa.be schrieb:
As I said before:
Neither --input-dir nor --descr-dir will be put in the fpdoc
implementation.
What are you talking about? They are already in fpdoc :-)
I don't see the problem of having to specify all files that are part of the
project explicitly. Make
michael.vancann...@wisa.be schrieb:
Again, what are you talking about? FPDoc doesn't require a special
order of input files, neither source nor documentation files :-)
It does, see the explanation of Marco.
Then I wonder how I ever could generate the documentation for a single unit?
The
Unfortunately I managed to supply the EasyImports.patch twice, please
drop Mantis #21168 as a dupe of #21167. Sorry for the inconvenience :-(
Starting with this patch I suggest further improvements of fpdoc. Except
for the RTL docs, which require a couple of special compiler options for
every
michael.vancann...@wisa.be schrieb:
I checked here at work, and here the SVN copy is different than at home.
So I committed a fix, please test rev. 20169.
Just tested: the dupes error has gone away :-)
Now remain the syntax errors, see Mantis #21148.
DoDi
michael.vancann...@wisa.be schrieb:
Today I had problems in the FPDocManager, where the scanner/parser
throws an exception String list does not allow duplicates. Reason
may be duplicate include paths, definitely a duplicate -dCPU32 from
both the parser and the commandline.
The sources have
Michael Van Canneyt schrieb:
On Tue, 24 Jan 2012, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
Today I had problems in the FPDocManager, where the scanner/parser
throws an exception String list does not allow duplicates.
Reason may be duplicate include paths, definitely
Today I had problems in the FPDocManager, where the scanner/parser
throws an exception String list does not allow duplicates. Reason may
be duplicate include paths, definitely a duplicate -dCPU32 from both the
parser and the commandline.
This error now also occurs when the RTL 2.6 docs are
Michael Van Canneyt schrieb:
On Mon, 23 Jan 2012, Hans-Peter Diettrich wrote:
Today I had problems in the FPDocManager, where the scanner/parser
throws an exception String list does not allow duplicates. Reason
may be duplicate include paths, definitely a duplicate -dCPU32 from
both
Paul Robinson schrieb:
This proves conclusively that only open brace { comment is acceptable
for defining macros in Free Pascal.
The scanner for comments is highly optimized (manually), resulting in
unwanted inconsistent and untested behaviour :-(
The preprocessor is broken since the time,
Sven Barth schrieb:
1.
You wrote that you use the source code of FPC 2.6.0 and copied the
compiler and rtl directories to some other workplace. I suggest
you to use a SVN checkout of the development version (you can find the
links here: http://www.freepascal.org/develop.var (at Connect to
Paul Robinson schrieb:
The new directives are first, for printing capability:
$LIST $LISTING $PRINT
These are all the same (all three would be equivalent), and control
the generation of listings of source code. Currently the compiler
does not do listings, and I think it's an important
Michael Schnell schrieb:
On 01/09/2012 10:32 AM, Marco van de Voort wrote:
An ansistring is always 8-bit.
Sorry I can't follow here.
Of course the term ANSI suggests 8 bit, but it also suggest one
visible character = 8 bit, thus non UTF.
ANSI also covers MBCS (DBCS).
If a type called
Michael Schnell schrieb:
On 01/09/2012 11:09 AM, Marco van de Voort wrote:
Whatever the name is, in all current Unicode Delphi versions and FPC
ansistring means 8-bit string exclusively.
OK so the definition of
AnsiString(CP_UTF16) in FPC and
AnsiString(1200) in Delphi means
Nothing sane
Michael Schnell schrieb:
On 01/05/2012 12:32 PM, Marco van de Voort wrote:
In our previous episode, Michael Schnell said:
I found that the length of an AnsiString(CP_UTF16) is given in terms
of bytes and not of Words. Is this like it should ?
Yes. Afaik that is not a sane combination, but
Marcos Douglas schrieb:
Delphi (now) provides Records with methods, but these lack inheritance. Why
introduce such a crippled construct, when Objects can do the same and more
(virtual methods...).
+1
But more about Object type, what do you think to use Object to group
routines instead of
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
With Lazarus on Linux, I did some simple tests with UTF strings.
I found that the length of an AnsiString(CP_UTF16) is given in terms
of bytes and not of Words. Is this like it should ?
Yes. Afaik
Michael Schnell schrieb:
On 01/05/2012 04:40 PM, Hans-Peter Diettrich wrote:
Which Delphi version supports AnsiString(CP_UTF16)???
What is the suggested way to handle UTF-16 with Delphi ?
The obvious: in newer versions use String or UnicodeString :-)
Embarcadero discourages the use
Sven Barth schrieb:
Btw in this thread it was already mentioned that Delphi doesn't define
CP_UTF16, but one easily could define it and create the above code.
Then tell us the Delphi version that accepts an AnsiString(1200). I
couldn't find any :-(
Ehm... Delphi XE DOES accept
Marcos Douglas schrieb:
Just this morning I had to move some methods out of a class, so that they
could be used without an instance. IMO it's a bad idea to bind any
general-purpose identifier to an artificial container (namespace...).
Why?
Using an identifier (unit class object, or it) is
Martin schrieb:
Note, that I am not accessing a private field of the parent class (like
in the link).
TForm1 = class(TForm)
public
FFoo: TFoo;
property Num: Integer read FFoo.FBar;
end;
When FFoo is a pointer or reference, it IMO should not be possible at
all, to select a
Marcos Douglas schrieb:
I don't see any reason why the Object type should be dropped. It's close
to C++ objects, useful in porting code. It allows for static objects,
e.g. in the stack, while TObject is bound to the heap (without tricks).
So, Object types is indicated only for compatibility?
Florian Klämpfl schrieb:
Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich:
Skybuck Flying schrieb:
-Original Message- From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access
Marco van de Voort schrieb:
In our previous episode, Michael Schnell said:
With Lazarus on Linux, I did some simple tests with UTF strings.
I found that the length of an AnsiString(CP_UTF16) is given in terms
of bytes and not of Words. Is this like it should ?
Yes. Afaik that is not a sane
Michael Schnell schrieb:
On 12/30/2011 07:09 PM, Hans-Peter Diettrich wrote:
Better question: what common capabilitiers are implemented differently
in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
That makes *what* difference?
DoDi
Sven Barth schrieb:
I thinking if the Object type will be deprecated in the future... I
hope not.
As Free Pascal still writes on its flag that it is compatible to Turbo
Pascal I doubt that it will be deprecated (also there is quite some code
in the compiler and also in some packages which
Sven Barth schrieb:
And, as somebody asked, what the advantages (performance?) using
Object instead Class?
They are basically similar to records with methods (which we now have
as well...) if you use them directly (this means: not as pointer types):
they are located on the stack and nested
Skybuck Flying schrieb:
-Original Message- From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
Skybuck Flying schrieb:
vValue := mDepth1.mDepth2.mDepth3.mValue;
You can
Skybuck Flying schrieb:
vValue := mDepth1.mDepth2.mDepth3.mValue;
You can implement such a funny hierarchy in any language. So what?
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Skybuck Flying schrieb:
2. Nested/delegated classes incur a pointer access penalty, the deeper
the nesting the higher the penalty.
Why? Nested classes are not a problem in OPL, more in C++ (multiple
inheritance!).
Nested classes are a problem because of the pointer overhead.
For example
Skybuck Flying schrieb:
My assumptions for this idea are:
1. Pointers to classes are mostly stored on the heap, in slow RAM.
What's fast RAM?
2. Nested/delegated classes incur a pointer access penalty, the deeper
the nesting the higher the penalty.
Why? Nested classes are not a problem
Skybuck Flying schrieb:
^ All of these examples are quite bad in the following way:
They become very static, which makes it pretty much impossible to change
their range at runtime.
That's by design.
These types are pretty much a left over from the days of turbo pascal, and
is a reason why
Jonas Maebe schrieb:
However current fpc 2.4.4 does not align the stack as such. I do
not know if this correct or not when reading things like:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838#c8
http://groups.google.com/group/ia32-abi/browse_thread/thread/4f9b3e5069943bf1
I tried to
Mattias Gaertner schrieb:
I understand that conflicts can arise, when the same XML file is
modified by different means. But it is not nice when the IDE then crashes.
Can you create a stacktrace?
How?
The IDE only disappears, silently, including the console window :-(
DoDi
Michael Van Canneyt schrieb:
When we look at new packages, some general tasks come into mind:
[snip]
I'd prefer that all beforementioned tasks can be accomplished by a
single program, by only giving it an project file, task, and
task-specific options.
Feel free to create this program.
michael.vancann...@wisa.be schrieb:
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Feel free to create this program. If I may give some advice: the
tasks you outline belong in a Documentation writers IDE.
To some degree, maybe. But checking for updates
Mattias Gaertner schrieb:
On Sat, 17 Dec 2011 15:41:32 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
[...]
The documentation related features could become Lazarus plug-ins, of
course, similar to or as an extension of the FPDoc Editor window. But
this already existing support makes
Michael Van Canneyt schrieb:
I have done so for years, with the existing tools, using the
Makefiles. No changes were necessary.
Can you explain that a bit more? I'm not a professional commandline
user, perhaps I'm doing something stupid?
I just do a make updatexml or make updatefclxml or
Michael Van Canneyt schrieb:
Give me a link to the directory handling topic, then I can tell you
more. Ah, found it: FileName handling routines (sysutils). At a
first glance there is nothing missing, except FileSize. Perhaps
ForceDirectories...
I don't understand. ForceDirectories exists in
When MakeSkel shall use FPDoc projects, this can be achieved by adding
something like:
procedure LoadProject(const Arg: string);
begin
ProjectName := Arg;
Project := TFPDocProject.Create(Nil); //owner component?
With TXMLFPDocOptions.Create(Project) do
try
Michael Van Canneyt schrieb:
Then the created skeletons can be added to the DescrFiles list, and
the updated project can be saved on exit.
I don't think this is good. makeskel creates a diff, you should not add
this to the list of files; instead, after it was created, it should be
merged
Michael Van Canneyt schrieb:
Consider an existing FPDoc project, which contains all input files and
all currently existing description files. When you want to create a
new skeleton for an not yet documented unit, how to achieve that?
Should the user copy the stored --input specification for
michael.vancann...@wisa.be schrieb:
Normally I use TFileStream's, which have a Size property. But I find
it nasty to open an file, when I only want to know its size. FPC (like
Delphi) lacks some basic file/directory handling functions (Size,
Remove, Rename...), at
I think you didn't look
201 - 300 of 951 matches
Mail list logo
