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 had something like 20 lines of code and it's
own description said it doesn't eve
On 30 Aug 2011, at 10:34, Jonas Maebe wrote:
> Also, at http://www.netmite.com/android/mydroid/dalvik/docs/verifier.html I
> noticed one forbidden thing that FPC currently does: "The Dalvik verifier is
> more restrictive than other VMs in one area: type safety on sub-32-bit
> integer widths. T
On Tue, 30 Aug 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
Since the purpose of fpdoc is to document things from pascal source code,
for me it follows that it must read the source code first.
This is the purpose of makeskel. Afterwards useful information has to be
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 android.app.Activity in the inheritance tree
>>> (android.com
On 30/08/2011, Hans-Peter Diettrich wrote:
>
> 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 elements making i
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.
Isn't that exactly what I said... fpdoc only uses what you supply to it.
> Does a documentation tool serve
> the user, or has the user to
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 android.app.Activity in the inheritance tree (android.common.Context). I
yet need to check whether all methods are overridd
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 android.app.Activity in the inheritance tree
> (android.common.Context). I yet need to check whether all methods are
> overridden correctly by the subclasses (an
On 30.08.2011 22:11, Jonas Maebe wrote:
On 30 Aug 2011, at 21:59, Sven Barth wrote:
I/ActivityManager( 62): Start proc com.example.helloandroid for activity
com.example.helloandroid/.HelloAndroid: pid=375 uid=10034 gids={1015}
W/dalvikvm( 375): VFY: new-instance on interface or abstract cl
Am 30.08.2011 22:22, schrieb Florian Klämpfl:
> Am 29.08.2011 13:18, schrieb Felipe Monteiro de Carvalho:
>> I added Sorokins RegExpr to packages in rev 18891 introducing the
>> following incompatibility:
>>
>> http://wiki.lazarus.freepascal.org/User_Changes_Trunk#regexpr.pp_was_renamed_to_oldregex
Am 29.08.2011 13:18, schrieb Felipe Monteiro de Carvalho:
> I added Sorokins RegExpr to packages in rev 18891 introducing the
> following incompatibility:
>
> http://wiki.lazarus.freepascal.org/User_Changes_Trunk#regexpr.pp_was_renamed_to_oldregexpr.pp
>
> The main file from Joost Reg Expresions
On 30 Aug 2011, at 21:59, Sven Barth wrote:
> I/ActivityManager( 62): Start proc com.example.helloandroid for activity
> com.example.helloandroid/.HelloAndroid: pid=375 uid=10034 gids={1015}
> W/dalvikvm( 375): VFY: new-instance on interface or abstract class
> Lorg/freepascal/android/TTestA
On 30.08.2011 10:34, Jonas Maebe wrote:
On 30 Aug 2011, at 10:16, Sven Barth wrote:
Am 30.08.2011 10:10, schrieb Jonas Maebe:
Maybe you have to explicitly add "-g-" to the OPT string when compiling
the RTL (and your programs), since the default config file shipped with
the snapshot enables d
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
> documentation.
Like "./fixd
Graeme Geldenhuys schrieb:
The requirement for perfectly compilable source files, with all options
and include files, stands in contrast to building mere documentation.
Since fpdoc offers no means to add target specific documentation in the
xml files, it should be able to build target-insensitiv
michael.vancann...@wisa.be schrieb:
Since the purpose of fpdoc is to document things from pascal source code,
for me it follows that it must read the source code first.
This is the purpose of makeskel. Afterwards useful information has to be
added to all items, before finally meaningful docum
michael.vancann...@wisa.be schrieb:
This information is not in the XML
Right, but why doesn't fpdoc leave it to the user, which files should
be scanned for detailed information, and for which the description is
enough?
Because the user should not have to decide this in the first place.
N
On 30/08/2011, Hans-Peter Diettrich wrote:
>
> It is easily possible, of course. When I want documentation created from
> source files, then I use something like PasDoc.
That is exactly what fpdoc does too... generates documentation based
on source files.
> The requirement for perfectly compilab
On Tue, 30 Aug 2011, Hans-Peter Diettrich wrote:
Felipe Monteiro de Carvalho schrieb:
This information is not in the XML
Right, but why doesn't fpdoc leave it to the user, which files should be
scanned for detailed information, and for which the description is enough?
Because the user s
On Tue, 30 Aug 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
IMO fpdoc should always create output from the given xml files, regardless
of whether according source files are also given.
If you think logically for a moment, you'll understand why this is simply
not
michael.vancann...@wisa.be schrieb:
IMO fpdoc should always create output from the given xml files,
regardless of whether according source files are also given.
If you think logically for a moment, you'll understand why this is
simply not
possible.
It is easily possible, of course. When I
Felipe Monteiro de Carvalho schrieb:
This information is not in the XML
Right, but why doesn't fpdoc leave it to the user, which files should be
scanned for detailed information, and for which the description is enough?
DoDi
___
fpc-devel maillis
On Tue, 30 Aug 2011, Hans-Peter Diettrich wrote:
Why does fpdoc require input files, when the description is contained in xml
files (desc)?
IMO fpdoc should always create output from the given xml files, regardless of
whether according source files are also given.
If you think logically f
On Tue, Aug 30, 2011 at 8:41 AM, Paul Ishenin wrote:
> 30.08.2011 18:57, Martin wrote:
>
> I also have this problem quite often. I usually search for fpmake.exe and
> delete it (thanks Marco for the hint).
+1
Thanks Marco.
Marcos Douglas
___
fpc-devel
On Tue, Aug 30, 2011 at 7:57 AM, Martin wrote:
> Sorry, my mailer choose to send this while I was still typing
>
> On 30/08/2011 11:55, Martin wrote:
>>
>> very weird issue;
>>
>> I have a batch fiel, that does (sucesfull):
>>
>> make.exe clean distclean
>> make.exe all LINKSMART=1 CREATES
See: http://www.freepascal.org/docs-html/rtl/sysutils/format.html
In this part:
Declaration
Source position: line 0
function Format(
const Fmt: String;
const Args: array of Const
):String;
function Format(
const Fmt: String;
const Args: array of Const;
const FormatSettings: TFor
Why does fpdoc require input files, when the description is contained in
xml files (desc)?
IMO fpdoc should always create output from the given xml files,
regardless of whether according source files are also given.
DoDi
___
fpc-devel maillist -
On Tue, Aug 30, 2011 at 6:49 AM, Martin wrote:
>
> The following line to install fpc used to work:
> make.exe install INSTALL_PREFIX=c:\FPC\trunk\ COPYTREE=echo UPXPROG=echo
>
> But now leads to:
> .\fpmake.exe install --localunitdir=../.. --globalunitdir=.. --os=win32
> --cpu=i386 -o -Ur -o -Xs
30.08.2011 18:57, Martin wrote:
I also have this problem quite often. I usually search for fpmake.exe
and delete it (thanks Marco for the hint).
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepa
Sorry, my mailer choose to send this while I was still typing
On 30/08/2011 11:55, Martin wrote:
very weird issue;
I have a batch fiel, that does (sucesfull):
make.exe clean distclean
make.exe all LINKSMART=1 CREATESMART=1 OPTIMIZE=1 OPT="-gl -O3
-Or -CpPENTIUMM -OpPENTIUMM"
make.ex
very weird issue;
I have a batch fiel, that does (sucesfull):
make.exe clean distclean
make.exe all LINKSMART=1 CREATESMART=1 OPTIMIZE=1 OPT="-gl -O3 -Or
-CpPENTIUMM -OpPENTIUMM"
make.exe install INSTALL_PREFIX=c:\FPC\fix_2_6_0 COPYTREE=echo
UPXPROG=echo
Then the makefile should exec
On 08/30/2011 12:19 PM, Hans-Peter Diettrich wrote:
The FPC internal representation (code tree nodes) has no notion of
registers. This is (also) due to the fact, that a register allocator
can work reasonably only after the entire code of a subroutine is
known. When the target is a registerles
On 08/30/2011 10:25 AM, Jonas Maebe wrote:
He means that converting a stack based program representation (whether
it's compiler-internal or Java byte code is irrelevant) of a program
to a flat register file based program representation has been a solved
problem since a long time ago.
Of cours
On 30/08/2011 10:53, Jeppe Græsdal Johansen wrote:
Den 30-08-2011 11:49, Martin skrev:
The following line to install fpc used to work:
make.exe install INSTALL_PREFIX=c:\FPC\trunk\ COPYTREE=echo
UPXPROG=echo
But now leads to:
.\fpmake.exe install --localunitdir=../.. --globalunitdir=..
--
Den 30-08-2011 11:49, Martin skrev:
The following line to install fpc used to work:
make.exe install INSTALL_PREFIX=c:\FPC\trunk\ COPYTREE=echo
UPXPROG=echo
But now leads to:
.\fpmake.exe install --localunitdir=../.. --globalunitdir=..
--os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o
-
The following line to install fpc used to work:
make.exe install INSTALL_PREFIX=c:\FPC\trunk\ COPYTREE=echo UPXPROG=echo
But now leads to:
.\fpmake.exe install --localunitdir=../.. --globalunitdir=.. --os=win32
--cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o
-FuC:/FPC/SVN/trunc/rtl/units/i386-win32
Michael Schnell schrieb:
On 08/29/2011 05:58 PM, Hans-Peter Diettrich wrote:
That is why I am astonished that converting Java-Bytecode to Dalvik
code should be an easy task.
A stackbased internal or intermediate representation is the most
general one, from which a compiler can decide whic
On 30 Aug 2011, at 10:16, Sven Barth wrote:
Am 30.08.2011 10:10, schrieb Jonas Maebe:
Maybe you have to explicitly add "-g-" to the OPT string when
compiling
the RTL (and your programs), since the default config file shipped
with
the snapshot enables debug information.
I have done that
On 30 Aug 2011, at 09:59, Michael Schnell wrote:
On 08/29/2011 05:58 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
That is why I am astonished that converting Java-Bytecode to
Dalvik code should be an easy task.
A stackbased internal or intermediate representation is the most
Am 30.08.2011 10:10, schrieb Jonas Maebe:
On 30 Aug 2011, at 09:16, Sven Barth wrote:
Am 29.08.2011 23:06, schrieb Jonas Maebe:
Ok... creating an Android class (in this case
android.widget.TextView) from within my FPC class works, but the
full FPC variation still doesn't want to start...
On 30 Aug 2011, at 09:16, Sven Barth wrote:
Am 29.08.2011 23:06, schrieb Jonas Maebe:
Ok... creating an Android class (in this case
android.widget.TextView) from within my FPC class works, but the
full FPC variation still doesn't want to start...
What kind of error do you get?
The sam
Am 30.08.2011 09:59, schrieb Michael Schnell:
On 08/29/2011 05:58 PM, Hans-Peter Diettrich wrote:
That is why I am astonished that converting Java-Bytecode to Dalvik
code should be an easy task.
A stackbased internal or intermediate representation is the most
general one, from which a compi
On 08/29/2011 05:58 PM, Hans-Peter Diettrich wrote:
That is why I am astonished that converting Java-Bytecode to Dalvik
code should be an easy task.
A stackbased internal or intermediate representation is the most
general one, from which a compiler can decide which registers to use
for ex
Am 30.08.2011 03:06, schrieb Anthony Walter:
Tonight I tried to "make all" from your branch and wasn't able to build.
This is a the output I got:
http://pastebin.com/GQh5XA2w
I am guessing your build requires a working version of your fpc binary
to build itself.
The errors you see are already
Am 29.08.2011 23:06, schrieb Jonas Maebe:
On 29 Aug 2011, at 22:42, Sven Barth wrote:
On 29.08.2011 22:22, Sven Barth wrote:
Without debug information it works. Next step: creating one of the
Android classes from within FPC compiled code. :)
Ok... creating an Android class (in this case and
45 matches
Mail list logo
