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
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 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?
I
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 memb
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;
&quo
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
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 us
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
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
http://lists.freepascal.org/mailman/listinfo/fpc-dev
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 i
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 p
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
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 chang
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" o
Mattias Gaertner schrieb:
On Sat, 17 Dec 2011 15:41:32 +0100
Hans-Peter Diettrich 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 it *harder* to add
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 f
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. If
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 th
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 wit
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
LoadOptionsFromFile(Pro
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 i
Andrew Brunner schrieb:
I got it to work by declaring the Callback Event Type in the
Storage.Folders area and declared that type in the other unit which
linked just fine.
It appears that the references cannot be located from outside that namespace.
That's why I wonder what namespaces are *goo
michael.vancann...@wisa.be schrieb:
I repeat: you didn't search very well.
Yes, I was not lucky enough :-(
IMO a separation into topics "File handling" (FILE based) and "File
management" (by filename) would be a good idea. Now I also found an
topic "General File handling routines", but it
Marco van de Voort schrieb:
Search for rename and file in the chm help:
Thanks, slowly I understand how a chm can be searched :-)
This should be explained somewhere, too (using Help)
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
ht
Tomas Hajny schrieb:
Basic functionality for working with files is available in units System,
SysUtils and Dos - see e.g.
http://wiki.freepascal.org/Unit_categorization.
Searching for "file" in that page doesn't reveal any helpful
information. Perhaps it's me, but I rarely can find something
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 ver
Tomas Hajny schrieb:
I wonder how to obtain the size of an file on disk. The only function I
could find so far is FileSize, which requires an open File, but nothing
for an file name :-(
ATM FileSize(TEXT) would help, too, but FileSize only accepts an FILE,
not TEXT :-(
What exactly do you
Michael Van Canneyt schrieb:
BTW is it really required to add "-Fi.", so that the parser finds
include files in the current directory (of the unit file)?
To my knowledge, it should not be necessary ?
MakeSkel currently complains about missing "dw_htmlchm.inc", when
creating the skeletons fo
Michael Van Canneyt schrieb:
FindFirst may be usable, but is very clumsy for this simple request.
Nevertheless, it is the only option.
For example FileAge also calls FindFirst.
Then it shouldn't be a problem to add an according FileSize function to
the RTL?
DoDi
Michael Van Canneyt schrieb:
Now I'll try to further extend MkSkel by using FPDoc projects, so that
the correct input specifications are used, including all compiler
options. Then it will be easy to check the RTL and other packages for
updates, and to create the skeletons for all contained uni
I wonder how to obtain the size of an file on disk. The only function I
could find so far is FileSize, which requires an open File, but nothing
for an file name :-(
ATM FileSize(TEXT) would help, too, but FileSize only accepts an FILE,
not TEXT :-(
FpFStat() seems unavailable on Windows :-(
I just tried to extend the programs in the fpdoc folder, morphing the
program files into unit files by conditional compilation:
{$IFDEF DoDi}
unit ...;
interface
{$ELSE}
program ...;
{$ENDIF}
etc., no problem so far.
Then I wrote my own MkSkel program, using MakeSkel as a unit. Also fine :-)
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
FPDoc doesn't find targets for these links:
math.TRoundToRange - range types never become part of the documentation!
type TRoundToRange = -37..37;
I suspect that fpdoc wants an type name after the "
FPDoc doesn't find targets for these links:
math.TRoundToRange - range types never become part of the documentation!
type TRoundToRange = -37..37;
I suspect that fpdoc wants an type name after the "=", which here
doesn't exist. Applies to all range types, not only this one.
system.Power - m
Michael Van Canneyt schrieb:
The LCL problem is not related to new syntax, all units parse without
errors. But document creation crashes on screen.inc
FontEnumProc = function (var ELogFont:TEnumLogFont; var
Metric:TNewTextMetric;
FontType:longint; Data:LParam):longint; extdecl;
What ex
Michael Van Canneyt schrieb:
The addition of the win and win32 includes IMO was not a good decision,
instead the parser should use the Linux target (as you assume) instead
of the actual platform.
I don't think the parser is the problem.
The problem are the (platform dependent) arguments, pas
Michael Van Canneyt schrieb:
At least TSystemTime is declared there, used in GetLocalTime (Win32
platform). Dunno about other types or constants, used in other Win32
RTL and FCL units (winsocks...).
If you'd check carefully TSystemTime is declared and documented in
sysutils.
Not in the win
Jonas Maebe schrieb:
On 09 Dec 2011, at 13:47, Michael Van Canneyt wrote:
I know nothing about OS/2-eCS, but the same arguments as for Go32V2
apply as far as I am concerned. If all these platforms can guarantee
returning correct UTC time, I do not see why we would not introduce it.
Afaik th
Sven Barth schrieb:
Just as a sidenote: unit "Dos" is platform independant (every (full)
target has one and the common parts reside in dos.inc and dosh.inc in
%fpcdir%\rtl\inc)
Ah, thanks.
Then Go32v2 is the (MS?)Dos platform?
Looks now as if platforms reside in the rtl subdirectories, exce
Michael Van Canneyt schrieb:
2. Placy a dummy routine which returns 'now' in sysutils.inc
{$IFNDEF FPC_HAS_NOWUTC}
function NowUTC : TDateTime;
begin
Result:=Now;
end;
{$ENDIF}
IMO the dummy routine should return some error value, e.g. zero or NaN,
that makes it clear to the user that some
Michael Van Canneyt schrieb:
And as long as it is not 100% documented, it will not be added.
In other words, the windows unit will probably never make it in the
official docs.
At least TSystemTime is declared there, used in GetLocalTime (Win32
platform). Dunno about other types or constants,
Makeskel expects another(?) semicolon after win\wininc\func.inc:
function GetRandomRgn(aHDC: HDC; aHRGN: HRGN; iNum: WINT): WINT;
stdcall; external 'gdi32';
function ...
Perhaps it cannot parse the "external" directive?
FPDoc seems to suffer from the same problem, it creates an all-empty
des
Felipe Monteiro de Carvalho schrieb:
Yes, in the case of the rectangle drawing I think it was a typo by who
implemented the current rectangle in fcl-image, I have done various
similar typos in my coding and they don't mean I really wanted to
redefine rectangle.
But the TCanvas line is trully co
Marco van de Voort schrieb:
That's a known issue. IIRC a workaround was to compile fpdoc without
optimization.
Sorry, that didn't help :-(
So what was your commandline to build the checkout ?
Argh, I did updates regularly, but forgot to rebuild the compiler etc. :-(
But rebuilding only rem
michael.vancann...@wisa.be schrieb:
Currently the following steps are required to build the project file
and the docs:
1. make -n > mydocs.bat
2. edit mydocs.bat to make fpdoc create an project file
3. mydocs.bat
4. edit the mydocs.xml project as required
5. fpdoc mydocs.xml
2+3 could be omit
Marco van de Voort schrieb:
But when I tried to build the LCL, fpdoc crashes badly in
THTMLWriter.AppendProcType (SIGSEGV). I tried to catch this error by
try-except, but then Windows kills fpdoc. Running from the commandline
at least reveals the Element as "FontEnumProc".
I'll have to resear
michael.vancann...@wisa.be schrieb:
Yes, but changing this will break existing code ?
Such code can be considered broken, deserves an fix anyhow.
Yes, it cannot do both at the same time, unless we add a property
PaintLikeTCanvas or something like that.
Hm. I would reverse the property. "Us
Marco van de Voort schrieb:
In our previous episode, Sven Barth said:
The -v option should become more verbose, just for hunting such bugs.
And the messages should go to stdout instead of stderr, at least on
Windows (with poor redirection capabilities).
StdErr redirection works in Windows the s
michael.vancann...@wisa.be schrieb:
Does there exist a chance (trick) to use the input files of a different
installation, without copying the description files?
If you use the make command to generate the docs, simply pass the
FPCSRCDIR command line parameter.
eg: make rtl.chk fcl.chk FP
Michael Van Canneyt schrieb:
Wait, did you try this on FPC trunk sources ? That won't work.
2.6.0 sources should be OK.
I could build RTL and FCL docs from 2.4.2 without major problems (the
trunk Makefile was not fully compatible with the old directory structure).
But when I tried to build
Michael Van Canneyt schrieb:
Wait, did you try this on FPC trunk sources ? That won't work.
2.6.0 sources should be OK.
Ah!
Does there exist a chance (trick) to use the input files of a different
installation, without copying the description files?
I'll try --descr-dir, because --input-dir
michael.vancann...@wisa.be schrieb:
Hm. It should work correctly; At least, it did so in the past. I will need
to check this.
The platform also seems to be involved. When I changed the
win32\classes.pp into unix\classes.pp, many classes disappear entirely
from the docs (TFileStream, TStrings
Felipe Monteiro de Carvalho schrieb:
On Wed, Dec 7, 2011 at 11:27 AM, Hans-Peter Diettrich
wrote:
IMO the fastest implementation paints everything to a bitmap, then masks the
painting with the region. This should be faster than clipping every single
drawing primitve.
Please prove with test
In my current tests I found empty classes (no members listed), e.g.
Classes.TFPList. The Declaration shows:
Source position: classesh.inc line 170
type TFPList = class end;
This line reads in the source code as
TFPList = class;
with the declaration following in line 188 ff.
TFPList = cl
Felipe Monteiro de Carvalho schrieb:
On Wed, Dec 7, 2011 at 9:28 AM, zeljko wrote:
Note that xxx_boundingRect() functions of qt are marked as slow (I guess
it's case when you deal with eg 1000 rects in region and you must calculate
lower TopLeft and high BottomRight) in their docs, I hope that
Hans-Peter Diettrich schrieb:
BTW, I couldn't find Imports used in building the documentation any
more. Did I miss something?
Sorry, the reference was not found because mkfpdoc is missing from the
fpdoc project files - please add it.
Michael Van Canneyt schrieb:
You can just remove the tags from the project file, or
manipulate the options with the tool I made earlier.
Still waiting for a description of your tool.
BTW, I couldn't find Imports used in building the documentation any
more. Did I miss something?
DoDi
Michael Van Canneyt schrieb:
I still miss a "required package" option (variation of --import?),
describing the packages whose content files are required to build a
dependent package documentation. Since the location of these packages
can differ on every machine, the user should be alerted when
Michael Van Canneyt schrieb:
All I did now was add some options for its manipulation,
based on the problems Hans was experiencing when he tried to build the
FPC docs.
Right, I'm impressed that almost all of my wishes have been implemented
now. I was quite pessimistic after the first reaction
Michael Van Canneyt schrieb:
Waiting for a commit of these extensions, and for a description of
your mkfpdocproj tool...
Everything was already committed in rev. 19755.
Now it has arrived here, and it really looks great :-)
One comment on ParseOption:
else if s = '--show-private' then
Graeme Geldenhuys schrieb:
On 4 December 2011 16:17, Hans-Peter Diettrich wrote:
I thought about such a simplification, too, but you'll get some objections:
I believe I already have. ;-)
How then do you want to document files for different platforms?
(needs to supply different sourc
Michael Van Canneyt schrieb:
I did several things:
1. Enable various log levels in parser and scanner. It uses an event
handler.
(writing to terminal is not possible)
2. Route all this logging through the TPasContainer.
I tried to remove all direct writes from all backends and other
pl
Graeme Geldenhuys schrieb:
On 4 December 2011 20:09, Hans-Peter Diettrich wrote:
Currently fpdoc stores many options in the project files, but this can cause
problems. Once a boolean option is stored as True, e.g.
it cannot be turned off by a different commandline option :-(
I know this
Currently fpdoc stores many options in the project files, but this can
cause problems. Once a boolean option is stored as True, e.g.
it cannot be turned off by a different commandline option :-(
This raises the question, which options should be stored in project
files at all, or how the stor
Graeme Geldenhuys schrieb:
On 3 December 2011 17:26, Marco van de Voort wrote:
And the contents in the XML is _NOT_ dependent where exactly those files
are, as long as fpdoc can find them.
Exactly my point. fpdoc cannot generate documentation without knowing
where the the *.xml _and_ *.pas f
michael.vancann...@wisa.be schrieb:
Speed is also an option. If we start allowing macros, then as an end result
the macros must be processed in the whole XML file. The documentation
XML is rather big; the project file is small.
In true unix philosophy, I think it is better to have many small
Tomas Hajny schrieb:
When ever required, the platform or widgetset specific *units* deserve
their own documentation (sources) in the first place. Then it's only a
minor effort to create specialized fpdoc projects, which use the right
units and create the documentation for them. Every user then
Michael Van Canneyt schrieb:
You remember my -n and -v options?
Absolutely, and I'll gladly accept patches implementing those 2 things
in fpdoc.
If you could separate those out from your other work, that would be much
appreciated. If not, send whatever you have, and I'll try to extract it
m
Michael Van Canneyt schrieb:
I split the tool so the class that does the actual work can be
integrated in e.g. a GUI tool for quick manipulation of project files.
I expect and hope the tool will solve most - if not all - of the
problems you experienced as well.
A first note:
A commandline
Michael Van Canneyt schrieb:
One objection is for instance that your proposal will cause all XML
files to be loaded both when FCL and RTL documentation are created.
Already included: all XML files are discarded, when they don't
contribute to the current package :-)
Because of the loose coup
Sven Barth schrieb:
Out of curiosity: How could/would one create one documentation of source
which supports multiple platforms, but where there are identifiers that
are only available for some platforms? (like our RTL)
Right, that's a problem - but how many identifiers are really affected?
I
Michael Van Canneyt schrieb:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform
attribute, so that problems arising from multiple (platform sp
I'm not yet familiar with the new string model, and compiling fpdoc
results in a lot of Unicode conversion warnings.
When somebody tries to eliminate these warnings, DOMString deserves a
closer look - should it become an UnicodeString instead of WideString?
BTW Where can I learn more about th
Michael Van Canneyt schrieb:
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
I'm just about to create a Windows version of the RTL docs. In contrast
to the assumption, that one XML file could hold descriptions of multiple
modules, I tes
Graeme Geldenhuys schrieb:
I'm not sure how the Makefiles in the FPC_Docs repository generates
fpdoc parameters, but I found that I only need to specify the search
paths in the first --input parameter.
This doesn't look correct to me, at least not for the trunk fpdoc and
the RTL documentation
Michael Van Canneyt schrieb:
The patch changes nothing to the content of the docs, it just makes sure
that the parser finds all files on Windows.
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
The patch changes nothing about this.
Ri
FPDoc issues many warnings about unknown link targets. Some of these
seem to result from intrinsic types, e.g. for PSmallInt the target
SmallInt does not exist. It doesn't look good when the docs do not
include the most basic types, like Boolean, Byte, Char, Pointer etc. :-(
The same problem w
michael.vancann...@wisa.be schrieb:
Perhaps linux/sockets.pp should be replaced by win/sockets.pp?
Or should the Makefile supply the Linux/Unix include directories,
instead those of the current platform (Windows)?
The latter. The paths must be appended, but I already committed a fix for
thi
Felipe Monteiro de Carvalho schrieb:
On Wed, Nov 30, 2011 at 9:14 PM, Hans-Peter Diettrich
wrote:
Now you hear some, most probably from the first user of fpdoc on Windows ;-)
If you were, then this file would not exist:
Examples which *happen* to work are not a proof for the absence of
See Mantis #20786 for details.
The first problem was the use of single quotes in the generated fpdoc
commandline, which are not handled properly by the Windows shell. I
fixed this manually, by editing the Makefile.
Next I get the following error messages:
../rtl/unix/sockets.pp(20,15): Could
michael.vancann...@wisa.be schrieb:
You should understand the problems of Windows users. Until now they
cannot produce local documentation, due to several bugs in the
Makefiles, fpdoc and related tools. This is a bad situation for
documentation writers, which cannot test their work thoroughly.
Sven Barth schrieb:
I'm not sure how far non-rectangular clipping regions are supported by
all widgetsets, and wouldn't rely on such a capability.
You are aware that TFPCustomCanvas can be used for widgetset independant
canvases as well? Also Felipe said that he'll need it for his
fpvectoria
michael.vancann...@wisa.be schrieb:
(so rtl/xxx/yy.html referencing fcl/zzz/ooo.html is done by generating a
link to ../../fcl/zzz/ooo.html )
But this is an html format problem, not a fpdoc problem.
I thought the cross-references are done based on the location of the cxt
file, and all links
Felipe Monteiro de Carvalho schrieb:
I am facing a problem with clipping in TFPCustomCanvas because it has
these properties:
property ClipRect : TRect read GetClipRect write SetClipRect;
property Clipping : boolean read GetClipping write SetClipping;
Which obviously is not extensible f
michael.vancann...@wisa.be schrieb:
It seems to me you are reading too much in fpdoc. fpdoc takes some input
files and produces output. No more, no less.
All the questions you ask have more to do with 'how do I organize my
work with fpdoc' rather than with 'how should fpdoc function'.
You sh
Michael Van Canneyt schrieb:
That would conflict with the GUI TApplication instance, so I really
don't see the point of this exercise.
Then another error in the logic exists: CreateDocumentation should be
a method of TFPDocProject, not of TFPDocAplication.
Why ? TFPDocProject is just storag
In my review of the fpdoc project option some questions popped up. The
most important question: should fpdoc be usable for creating online help
only, or should it also allow users to create offline documentation on
their local machine? When a user can create documentation files for
local use, t
michael.vancann...@wisa.be schrieb:
When this were the *only* code in the fpdoc program file, another
project could create a derived class, with a possibly specialized Run
method, without touching the declaration or implementation of
TFPDocApplication.
That would conflict with the GUI TAppli
Tomas Hajny schrieb:
The current limit of the default MS Windows shell is 8 kB according to
information found on Microsoft pages (among others). Are those 4890
characters mentioned above Unicode (UTF-16) characters (thus breaking the
limit)? Anyway, it might be possible to use a different comman
Sven Barth schrieb:
I'm not a huge fan of the style used in the compiler, but am I
complaining?
Did I?
I'm even trying to concentrate as good as possible to
adhere to the style used there,
Where's the code formatter, that would eliminate all such discussions?
so that the changes I want to
michael.vancann...@wisa.be schrieb:
2. Try to separate things. You coded a change in package selection
handling, please don't mix this with the change for writing a package
file. It makes it more difficult to debug when bugs arise.
How can I create patches for different topics, when the whole
michael.vancann...@wisa.be schrieb:
A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the
long command lines created by the scripts (4890 chars for rtl.chk).
This is a problem of windows, yes.
Argh :-(
Try
michael.vancann...@wisa.be schrieb:
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles, used to build the documentation for the
standard
Hans-Peter Diettrich schrieb:
Unfortunately there remain some problems, e.g. the FPC documentation
cannot be created on Windows, what is one reason for the extended
project option, but doesn't allow me to debug this feature with real
life projects (RTL...).
A "make -n rtl.chk
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles, used to build the documentation for the standard
libraries. See Mantis #20769.
Unfortunately there remain some problems, e.g. the FPC docu
Florian Klämpfl schrieb:
Anti virus?
This was my first guess as well, but deactivating online-scanning didn't
help. So I uninstalled BitDefender completely, and now it worked :-)
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
On Win7 I encounter the following fatal error on "make clean all" of
trunk (19693):
D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe -f ./pp.exe ppc386.exe
D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe: cannot remove
`ppc386.exe': Permission denied
There exists a pp.exe in the current (compiler)
DaWorm schrieb:
Perhaps a little extra compiler magic could be used? If the base
definition of a string (the hidden stuff before the data) contains not
only a field with the encoding, but a flag indicating the disposition of
the encoding, then when a string type is aliases, that disposition co
Michael Schnell schrieb:
As already said, my request at this time is not considering
implementation before agreeing on a decently clear definition of what
should be provided and what is supposed top happen when.
IMO such a separation is of no use. If you want an new string type, then
make it
301 - 400 of 1016 matches
Mail list logo
