On Thu, Sep 1, 2011 at 1:13 AM, Sven Barth wrote:
>
> I'll try to improve the unit names of the android unit and its dependencies
> a bit and then it might become the first package for FPC-JVM ;)
>
Sven, thanks for your tests. Adding hwfpo (Hello World From Pascal
Only) and simple step-by-step in
On 31 Aug 2011, at 23:13, Sven Barth wrote:
> On 31.08.2011 22:59, Jonas Maebe wrote:
>>
>> I'll do a testsuite run to see whether I introduced any bugs in the string
>> handling, but to test the Android stuff you can also use a compiler compiled
>> against another RTL for now.
Testsuite didn
On 31.08.2011 22:59, Jonas Maebe wrote:
On 31 Aug 2011, at 22:44, Sven Barth wrote:
No, the end is missing as well.
If I change the unit output path to something like "output" (something short) though,
then the "4.j" is printed. Besides that the content of the ppas file is completely
differe
On 31 Aug 2011, at 22:44, Sven Barth wrote:
> No, the end is missing as well.
> If I change the unit output path to something like "output" (something short)
> though, then the "4.j" is printed. Besides that the content of the ppas file
> is completely different in both cases... it nearly looks
On 31.08.2011 22:35, Jonas Maebe wrote:
On 31 Aug 2011, at 22:22, Sven Barth wrote:
On 31.08.2011 22:14, Jonas Maebe wrote:
Forgot to commit a file, sorry.
Nobody is perfect :)
But there seems to be another problem. When assembling the system unit I get
the following error:
=== output b
On 31 Aug 2011, at 22:22, Sven Barth wrote:
> On 31.08.2011 22:14, Jonas Maebe wrote:
>>
>> Forgot to commit a file, sorry.
>
> Nobody is perfect :)
>
> But there seems to be another problem. When assembling the system unit I get
> the following error:
>
> === output begin ===
>
> Assemblin
On 31.08.2011 22:14, Jonas Maebe wrote:
On 31 Aug 2011, at 21:55, Sven Barth wrote:
On 31 Aug 2011, at 21:36, Sven Barth wrote:
On 31.08.2011 21:21, Jonas Maebe wrote:
Fixed in svn, there was a bug in the abstract method accounting.
When compiling the RTL (make RELEASE=1 clean all) for i
Am 28.08.2011 19:59, schrieb David Welch:
>
> See attached.
>
Thanks, applied in r18927.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 31 Aug 2011, at 21:55, Sven Barth wrote:
>>
>> On 31 Aug 2011, at 21:36, Sven Barth wrote:
>>
>>> On 31.08.2011 21:21, Jonas Maebe wrote:
Fixed in svn, there was a bug in the abstract method accounting.
>>>
>>> When compiling the RTL (make RELEASE=1 clean all) for i386 I get the
>>> f
On 31.08.2011 21:49, Jonas Maebe wrote:
On 31 Aug 2011, at 21:36, Sven Barth wrote:
On 31.08.2011 21:21, Jonas Maebe wrote:
Fixed in svn, there was a bug in the abstract method accounting.
When compiling the RTL (make RELEASE=1 clean all) for i386 I get the following
error:
Fixed.
Than
On 31 Aug 2011, at 21:36, Sven Barth wrote:
> On 31.08.2011 21:21, Jonas Maebe wrote:
>> Fixed in svn, there was a bug in the abstract method accounting.
>
> When compiling the RTL (make RELEASE=1 clean all) for i386 I get the
> following error:
Fixed.
Jonas__
On 31.08.2011 21:21, Jonas Maebe wrote:
Fixed in svn, there was a bug in the abstract method accounting.
When compiling the RTL (make RELEASE=1 clean all) for i386 I get the
following error:
=== output begin ===
make[1]: Entering directory `/mnt/data/subversion/fpc-jvm/rtl/linux'
/mnt/data/
On 30 Aug 2011, at 22:59, Jonas Maebe wrote:
> On 30 Aug 2011, at 22:37, Sven Barth wrote:
>
>> On 30.08.2011 22:32, Jonas Maebe wrote:
>>>
>>> On 30 Aug 2011, at 22:26, Sven Barth wrote:
>>>
I've also found the class that defines the abstract methods. It's four
classes above androi
At 08:07 AM 8/31/2011, John Lee wrote:
Just googled 'Benjamin Rosseax regexpr' and don't find anything
that's trelevant! Where is it please?
It might help for a start to get the name right, his last name is "Rosseaux"...
http://bero.freqvibez.net/public/BESEN/BESEN.pas
hth,
Ralf
__
Just googled 'Benjamin Rosseax regexpr' and don't find anything that's
trelevant! Where is it please?
John
On 31 August 2011 15:41, Marcos Douglas wrote:
> On Wed, Aug 31, 2011 at 2:55 AM, Felipe Monteiro de Carvalho
> wrote:
> > On Tue, Aug 30, 2011 at 10:22 PM, Florian Klämpfl
> > wrote:
>
On Wed, Aug 31, 2011 at 2:55 AM, Felipe Monteiro de Carvalho
wrote:
> On Tue, Aug 30, 2011 at 10:22 PM, Florian Klämpfl
> wrote:
>> Why didn't you just give the sorokin tregexpr unit another name? This
>> way, no incompatiblities would have been introduced.
>
> Because:
>
> 1> the old regexpr.pas
On Wed, 31 Aug 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
In each case, the opposite is already so. The documentation of an
enumerated-typed property will normally link to the enumerated type.
This doesn't make sense, because the meaning of an enum member can var
On 31/08/2011, Hans-Peter Diettrich wrote:
> ...
> process_begin: CreateProcess((null), latex user.tex, ...) failed.
> make (e=2): Das System kann die angegebene Datei nicht finden.
I have never tried to build the FPC documentation under Windows, but
if I understood the above error correctly, it
Martin schrieb:
Now we have 7 identifiers, all refering to the essentially same data
type. IMO it's only excess work, to document all these elements by
themselves, when finally only the property is of interest. Instead I'd
prefer a single doc entry, for the property, that also describes the
e
michael.vancann...@wisa.be schrieb:
In each case, the opposite is already so. The documentation of an
enumerated-typed property will normally link to the enumerated type.
This doesn't make sense, because the meaning of an enum member can vary,
depending on the context (class with property). U
In our previous episode, Hans-Peter Diettrich said:
> >> On Windows even the makefile doesn't work,
> >
> > "doesn't work" is not terribly informative. Maybe you simply don't know
> > windows build systems very well.
>
> Is this more informative?
That depends on viewpoint.
> $make html
> ...
Marco van de Voort schrieb:
On Windows even the makefile doesn't work,
"doesn't work" is not terribly informative. Maybe you simply don't know
windows build systems very well.
Is this more informative?
$make html
...
process_begin: CreateProcess((null), latex user.tex, ...) failed.
make (e=
On 31/08/2011 13:17, michael.vancann...@wisa.be wrote:
On Wed, 31 Aug 2011, Martin wrote:
What I meant was:
- TEnum.One / TEnum.One /TEnum
are still each of them documented in their own xml node, exactly as
they currently are.
But in TEnum xml node would be an attribute (or a node) declar
On Wed, 31 Aug 2011, Martin wrote:
On 31/08/2011 12:46, michael.vancann...@wisa.be wrote:
On Wed, 31 Aug 2011, Martin wrote:
IMHO the location of where the enum is located is not relevant to the
requirement of (or ability to the do without) scanning the source.
Never the less, this could
On 31/08/2011 12:46, michael.vancann...@wisa.be wrote:
On Wed, 31 Aug 2011, Martin wrote:
IMHO the location of where the enum is located is not relevant to the
requirement of (or ability to the do without) scanning the source.
Never the less, this could be an interesting feature. If fpdoc cou
On Wed, 31 Aug 2011, Martin wrote:
On 31/08/2011 09:43, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Now, you could "fix" that, of course.
That would require you to copy all information which is contained in the
interface section of the pascal file to the XML file.
For exampl
On 31/08/2011 09:43, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Now, you could "fix" that, of course.
That would require you to copy all information which is contained in
the interface section of the pascal file to the XML file.
For example:
But, copying this information to
On Wed, 31 Aug 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Now, you could "fix" that, of course.
That would require you to copy all information which is contained in the
interface section of the pascal file to the XML file.
For example:
But, copying this information
On 08/31/2011 10:02 AM, Graeme Geldenhuys wrote:
I am working on some fpdoc fixes for IPF output.
I am also in the process of creating a new fpGUI release - which means
I'll generate new pre-built INF help files for all relevant frameworks
(RTL, FCL, LCL, fpGUI etc). This should be available fo
In our previous episode, Graeme Geldenhuys said:
[ Charset UTF-8 unsupported, converting... ]
> On 31/08/2011, Hans-Peter Diettrich wrote:
> > For now I only want to remove the code that skips xml files without
> > according source files. In the next step the --descr option should allow
> > for a
Marco van de Voort schrieb:
IMHO both Dodi and you should take a step back and describe problems (or
maybe even the usecase that is not possible now). Not try to argument on
vague principles.
Here's my problem:
I cannot create local documentation for LCL, with links into RTL and FCL
(...unk
On 31/08/2011, Hans-Peter Diettrich wrote:
> For now I only want to remove the code that skips xml files without
> according source files. In the next step the --descr option should allow
> for a directory, from which all files can be picked automatically.
Automation with fpdoc is not always a go
In our previous episode, Hans-Peter Diettrich said:
> > In our previous episode, Hans-Peter Diettrich said:
> >> This would be a very useful extension, indeed. Unfortunately the RTL and
> >> FCL have such irregular requirements, that much work is required to
> >> provide a usable command line for
On 31/08/2011, Marco van de Voort wrote:
>
> To avoid duplication of information (make change in pascal source of
> declaration, and have to make it in the .XML source) of course.
So we agree. :-)
> IMHO both Dodi and you should take a step back and describe problems (or
> maybe even the usecas
In our previous episode, Hans-Peter Diettrich said:
> > That's why the design is as it is and will not be changed anytime soon.
>
> I don't ask for an change of the design, I only ask for a complete
> documentation,
That is the objective.
> that includes all elements of the given xml files, eve
Graeme Geldenhuys schrieb:
On 30/08/2011, Hans-Peter Diettrich wrote:
Unfortunately fpdoc ignores all given xml files, when no corresponding
source file is given at the same time.
[...]
You are more than welcome to extend the tool if you want. I (and
probably many others) would also welcome a
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
This would be a very useful extension, indeed. Unfortunately the RTL and
FCL have such irregular requirements, that much work is required to
provide a usable command line for the compilation of the according
docume
Michael Van Canneyt schrieb:
Now, you could "fix" that, of course.
That would require you to copy all information which is contained in the
interface section of the pascal file to the XML file.
For example:
But, copying this information to the XML file would be a) duplicate and
thus redu
What is the status of the EXTDEBUG code? I know that I have to define
that to be able to use the compiler's -an option, but if enabled 2.4.4
doesn't compile. The fix is fairly trivial but if I notice this should I
be bug-reporting it?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[O
In our previous episode, Graeme Geldenhuys said:
> >> I beg to differ. Seeing the signature of a method, procedure, function
> >> etc is valuable information to a developer.
> >
> > True. But that doesn't make it important to be in every fileformat.
>
> I don't understand your statement about "eve
On 31/08/2011, Michael Schnell wrote:
>
> Might this discussion lead to us being able to create a current version
> of all inf files necessary for docview ?
I am working on some fpdoc fixes for IPF output.
I am also in the process of creating a new fpGUI release - which means
I'll generate new pr
On Wed, 31 Aug 2011, Marco van de Voort wrote:
Having a inheritance hierarchy is also very valuable, which the
current fpdoc XML format doesn't describe at all. This information is
only available when parsing the pascal source code.
No. You can also get it from the .xct's, which, for the l
On 31/08/2011, Marco van de Voort wrote:
>> I beg to differ. Seeing the signature of a method, procedure, function
>> etc is valuable information to a developer.
>
> True. But that doesn't make it important to be in every fileformat.
I don't understand your statement about "every file format". D
In our previous episode, Graeme Geldenhuys said:
> > This is the purpose of makeskel. Afterwards useful information has to be
> > added to all items, before finally meaningful documentation can be
> > generated.
>
> I personally think makeskel is a terrible idea. It generates a whole
> bunch of el
On 08/30/2011 05:17 PM, Graeme Geldenhuys wrote:
...
Graeme, as you are on this issue:
Might this discussion lead to us being able to create a current version
of all inf files necessary for docview ?
-Michael
___
fpc-devel maillist - fpc-devel@li
45 matches
Mail list logo
