Re: [fpc-devel] FPC-JVM: Status report on Android
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 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 same as before, so the debug information wasn't the solution there... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics in FPC have many problems
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 when compiling the RTL with the newly compiled compiler. As I said: compiling fgl is currently broken. I'd suggest you to do the following: Replace fgl.pp in rtl/objpas/ with an empty unit of the same name (empty here means containing unit fgl; interface implementation end.). You can't use the basic generic classes then, but for tests they aren't necessary. ^^ Then issue the following commands (I assume you start in the base directory of the checkout): === commands begin === cd compiler make cycle cd ../rtl make clean all === commands end === You'll have a new compiler as compiler/ppc386 (assuming you're on a x86 system; it will be named approbiately for other systems) and a compiled RTL in rtl/units/PLATFORM-OS (e.g. rtl/units/i386-linux). You can then compile programs with the following command (I assume FPCDIR to be set to the checkout's base directory, and the current platform to be i386-linux ): === command begin === $FPCDIR/compiler/ppc386 -n -Fu$FPCDIR/rtl/units/i386-linux [OTHER-OPTIONS] yourtest.pas === command end === Also, I wrote a few of pretty clean test cases in Delphi 2010 Today when I had some downtime from my other work. I'd be interested in integrating them cleanly into your tests and helping the fpc community any way I can. If you write them in a way that they adhere to the same basic pattern as other tests in FPC then they can easily be integrated (just take a look at the existing generic tests to see what I mean). I you have questions regarding this, please feel free to ask :) Finally, I think I looked at your change log. I guess the last check in you did was on July 16? I I reading that right? The SVN branch is a bit behind of my local GIT one, but not that much. I didn't have much time the last few weeks (and the coming weeks as well) as I'm working on my bachelor thesis :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 expression evaluation etc. FPC itself uses registers only for the actual code generation, depending on how many registers are available on the target machine. I don't see what you mean here. While of course FPC does acknowledge the count and kind of registers with targets like ARM or X86 or X86-64, Sven reported that his port for Java targets creates register-ignorant (stack based) code for standard (SUN) virtual Java machines and the dex-converter by Google converts this to 16-bit-wide Dalvik code which introduces Register notation. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 compiler can decide which registers to use for expression evaluation etc. FPC itself uses registers only for the actual code generation, depending on how many registers are available on the target machine. I don't see what you mean here. While of course FPC does acknowledge the count and kind of registers with targets like ARM or X86 or X86-64, Sven reported that his port for Java targets creates register-ignorant (stack based) code for standard (SUN) virtual Java machines and the dex-converter by Google converts this to 16-bit-wide Dalvik code which introduces Register notation. Honor to whom honor is due: the port is completely Jonas' work. I haven't modified a single line of code to get code working on Android. I just recompiled it once to disable debug information :D Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 same as before, so the debug information wasn't the solution there... 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. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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... What kind of error do you get? The same as before, so the debug information wasn't the solution there... 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 already, because I'm calling ppcjvm with -n option. Or does the compiler look in its own directory first before it uses the user config file? The problem seems to be something else and I'll find it sooner or later... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 general one, from which a compiler can decide which registers to use for expression evaluation etc. FPC itself uses registers only for the actual code generation, depending on how many registers are available on the target machine. I don't see what you mean here. 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. I tried to explain the same thing with my example of JIT compilers, which perform exactly the same task starting from exactly the same Java byte code. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 already, because I'm calling ppcjvm with -n option. Or does the compiler look in its own directory first before it uses the user config file? No, -n prevents loading any default configuration files. The problem seems to be something else and I'll find it sooner or later... There's a byte code verifier for dex files at http://dedexer.sourceforge.net/ (search for -r), maybe it can give a clearer diagnostic. 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. These additional restrictions should make it impossible to, say, pass a value outside the range [-128, 127] to a function that takes a byte as an argument. FPC won't sign extend byte values when passing them to functions (the JVM itself only supports signed types). I'll fix that. It shouldn't affect the code you are getting an error about though, since that is about boolean vs int. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 which registers to use for expression evaluation etc. FPC itself uses registers only for the actual code generation, depending on how many registers are available on the target machine. I don't see what you mean here. While of course FPC does acknowledge the count and kind of registers with targets like ARM or X86 or X86-64, Sven reported that his port for Java targets creates register-ignorant (stack based) code for standard (SUN) virtual Java machines and the dex-converter by Google converts this to 16-bit-wide Dalvik code which introduces Register notation. 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 registerless VM, the register allocator never is invoked. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] another make install issue
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 -FuC:/FPC/SVN/trunc/rtl/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/hash/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/paszlib/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/fcl-process/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/fpmkunit/units/i386-win32 -o -FE. -o -FUunits/i386-win32 -o -di386 -o -dRELEASE --compiler=C:/FPC/SVN/trunc/compiler/ppc386.exe --prefix=c:\FPC\trunk\ --unitinstalldir=c:\FPC\trunk\/units/i386-win32/fcl-base -ie The installer encountered the following error: Failed to create directory c:\FPC\trunk \bin\ It appears that 2 issu8es play together. 1) the windows path delim is not translated 2) the \ followed by a space is interpreted as escaped space, and included in the path I will try without the trailing \ But imho that shouldn't fail, it's a perfectly legal path (afaik) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Try make.exe install INSTALL_PREFIX=c:\\FPC\\trunk COPYTREE=echo UPXPROG=echo It's a perfectly legal and valid path, but you've forgotten that make is a tool made mostly by C-programmers ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 course I see and know. I just stated that the converter obviously in fact does this. Thanks again, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 registerless VM, the register allocator never is invoked. I see. Seemingly, if the target is Dalvik, the non-FPC-internal to-dex-converter does this on it's own. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] make clean problem with 2.6 fixes bracnh
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 execute another
make clean
and that always fails. It appears to dislike the fpmake.exe in fcl-web,
but that was created by the above (I did delete it before I started the
overall process, so it was definetly reated by the above)
The error I get:
{ .\fpmake.exe distclean --localunitdir=../.. --globalunitdir=..
--os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o
-FuC:/FPC/SVN/fix_2_6/rtl -o -FuC:/FPC/SVN/fix_2_6/packages/hash -o
-FuC:/FPC/SVN/fix_2_6/packages/paszlib -o
-FuC:/FPC/SVN/fix_2_6/packages/fcl-process -o
-FuC:/FPC/SVN/fix_2_6/packages/fpmkunit -o -FE. -o -FUunits/i386-win32
-o -di386 -o -dRELEASE --compiler=c:/FPC/SVN/ppc386_2_4_4.exe; if [ $?
!= 0 ]; then { echo Something wrong with fpmake exectable. Remove the
executable and call make recursively to recover.; C:/FPC/SVN/trunk_build/
rm.exe -f .\fpmake.exe; make fpc_cleanall; }; fi; }
'{' is not recognized as an internal or external command,
the part of the fcl-web makefile that is probably responsibel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] make clean problem with 2.6 fixes bracnh
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.exe install INSTALL_PREFIX=c:\FPC\fix_2_6_0 COPYTREE=echo
UPXPROG=echo
Then the makefile should execute another
make clean
and that always fails. It appears to dislike the fpmake.exe in
fcl-web, but that was created by the above (I did delete it before I
started the overall process, so it was definetly reated by the above)
The error I get:
{ .\fpmake.exe distclean --localunitdir=../.. --globalunitdir=..
--os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o
-FuC:/FPC/SVN/fix_2_6/rtl -o -FuC:/FPC/SVN/fix_2_6/packages/hash -o
-FuC:/FPC/SVN/fix_2_6/packages/paszlib -o
-FuC:/FPC/SVN/fix_2_6/packages/fcl-process -o
-FuC:/FPC/SVN/fix_2_6/packages/fpmkunit -o -FE. -o -FUunits/i386-win32
-o -di386 -o -dRELEASE --compiler=c:/FPC/SVN/ppc386_2_4_4.exe; if [ $?
!= 0 ]; then { echo Something wrong with fpmake exectable. Remove
the executable and call make recursively to recover.;
C:/FPC/SVN/trunk_build/
rm.exe -f .\fpmake.exe; make fpc_cleanall; }; fi; }
'{' is not recognized as an internal or external command,
the part of the fcl-web makefile that is probably responsibel
ifeq ($(FPMAKE_BIN_CLEAN),)
distclean:$(addsuffix _distclean,$(TARGET_DIRS)) fpc_distclean
else
distclean:
{ $(FPMAKE_BIN_CLEAN) distclean --localunitdir=../..
--globalunitdir=.. $(FPC_TARGETOPT) $(addprefix -o ,$(FPCOPT))
--compiler=$(FPC); if [ $$? != 0 ]; then { echo Something wrong with
fpmake exectable. Remove the executable and call make recursively to
recover.; $(DEL) $(FPMAKE_BIN_CLEAN); $(MAKE) fpc_cleanall; }; fi; }
-$(DEL) $(LOCALFPMAKE)
endif
It has the leading {
Note that I am only running ake clean, not make distclean?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] make clean problem with 2.6 fixes bracnh
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.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] another make install issue
On Tue, Aug 30, 2011 at 6:49 AM, Martin laza...@mfriebe.de 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 -o -O2 -o -n -o -FuC:/FPC/SVN/trunc/rtl/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/hash/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/paszlib/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/fcl-process/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/fpmkunit/units/i386-win32 -o -FE. -o -FUunits/i386-win32 -o -di386 -o -dRELEASE --compiler=C:/FPC/SVN/trunc/compiler/ppc386.exe --prefix=c:\FPC\trunk\ --unitinstalldir=c:\FPC\trunk\/units/i386-win32/fcl-base -ie The installer encountered the following error: Failed to create directory c:\FPC\trunk \bin\ It appears that 2 issu8es play together. 1) the windows path delim is not translated 2) the \ followed by a space is interpreted as escaped space, and included in the path I will try without the trailing \ But imho that shouldn't fail, it's a perfectly legal path (afaik) I had this problem too -- using fcl-web -- so, I created a hack to compile the FPC 2.5.1 (branches_2_6): if %myVERSION% equ 2.5.1 ( cd %myFPC%\packages\fastcgi\ del /s fpmake.exe *.ppu *.o cd %myFPC%\packages\fcl-web\ del /s fpmake.exe *.ppu *.o ) ...before 'make install'. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPDoc sources
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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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: TFormatSettings ):String; This information is not in the XML -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] make clean problem with 2.6 fixes bracnh
On Tue, Aug 30, 2011 at 7:57 AM, Martin laza...@mfriebe.de 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 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 execute another
make clean
and that always fails. It appears to dislike the fpmake.exe in fcl-web,
but that was created by the above (I did delete it before I started the
overall process, so it was definetly reated by the above)
The error I get:
{ .\fpmake.exe distclean --localunitdir=../.. --globalunitdir=..
--os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o
-FuC:/FPC/SVN/fix_2_6/rtl -o -FuC:/FPC/SVN/fix_2_6/packages/hash -o
-FuC:/FPC/SVN/fix_2_6/packages/paszlib -o
-FuC:/FPC/SVN/fix_2_6/packages/fcl-process -o
-FuC:/FPC/SVN/fix_2_6/packages/fpmkunit -o -FE. -o -FUunits/i386-win32 -o
-di386 -o -dRELEASE --compiler=c:/FPC/SVN/ppc386_2_4_4.exe; if [ $? != 0
]; then { echo Something wrong with fpmake exectable. Remove the executable
and call make recursively to recover.; C:/FPC/SVN/trunk_build/
rm.exe -f .\fpmake.exe; make fpc_cleanall; }; fi; }
'{' is not recognized as an internal or external command,
the part of the fcl-web makefile that is probably responsibel
ifeq ($(FPMAKE_BIN_CLEAN),)
distclean: $(addsuffix _distclean,$(TARGET_DIRS)) fpc_distclean
else
distclean:
{ $(FPMAKE_BIN_CLEAN) distclean --localunitdir=../.. --globalunitdir=..
$(FPC_TARGETOPT) $(addprefix -o ,$(FPCOPT)) --compiler=$(FPC); if [ $$? !=
0 ]; then { echo Something wrong with fpmake exectable. Remove the
executable and call make recursively to recover.; $(DEL)
$(FPMAKE_BIN_CLEAN); $(MAKE) fpc_cleanall; }; fi; }
-$(DEL) $(LOCALFPMAKE)
endif
It has the leading {
Note that I am only running ake clean, not make distclean?
You're right. The same problem here.
I created a hack, in my script, to compile the FPC 2.5.1 (branches_2_6):
if %myVERSION% equ 2.5.1 (
cd %myFPC%\packages\fastcgi\
del /s fpmake.exe *.ppu *.o
cd %myFPC%\packages\fcl-web\
del /s fpmake.exe *.ppu *.o
)
Marcos Douglas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] make clean problem with 2.6 fixes bracnh
On Tue, Aug 30, 2011 at 8:41 AM, Paul Ishenin webpi...@mail.ru 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 maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 for a moment, you'll understand why this is simply not possible. I'm surprised you even ask this question. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 possible. It is easily possible, of course. When I want documentation created from source files, then I use something like PasDoc. When I create xml files for fpdoc, I expect that these form the base of the documentation. Everything else is unlogical :-( What can I say ? You have a strange sense of logic. 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 has 2 consequences: 1. As you can see, the description files do not contain any structural information (type info, function info), just identifiers. The structural information is read from the primary location: the pascal sources. 2. Doing this means ALL identifiers are allways present in the documentation, and the ones for which documentation happens to be available are documented. If it were any other way, we wouldn't need source code or XML, we could just use Open Office or Word, that would be equally useful. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 should not have to decide this in the first place. The tool documents pascal code. Hence it must read the code. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 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-insensitive documentation. That falls outside the scope of the fpdoc project. It simply generates documentation based on what information you give it. Of course this process could greatly be enhanced by the help of any IDE that knows about fpdoc. Simply ask the IDE (which already knows the source code files it manages, paths and include paths) to generate a fpdoc build script for your current project or package or library, or it could execute the fpdoc application directly. The IDE can extract from its project settings all the required information to pass to fpdoc. In fact, this sounds like such a good idea [even if I had to say it myself], I'll be adding it to my experimental IDE. Furthermore, when fpdoc requires package names, why can't it read the source files from the package files, fpdoc's reference to packages is not the same thing as Lazarus packages. In fpdoc terms, it is just a way to group a set amount of documentation together. Not everybody that use FPC uses Lazarus IDE - so there simply can't be such a cross-project dependency. and then look for xml files of the same names in the xml directory of the package? I would suggest you implement such a feature for Lazarus IDE as I described above, or file a feature required for the Lazarus project. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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. No comment :-( The tool documents pascal code. Hence it must read the code. Even if fpdoc is *designed* to document Pascal code, this doesn't imply that it can't be fine with the user supplied xml files. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 documentation can be generated. If it were any other way, we wouldn't need source code or XML, we could just use Open Office or Word, that would be equally useful. Documentation of course needs a structure, and that structure is fully contained in the xml files. There exists no need for adding further information from the source code, that's more eye candy than essential information. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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-insensitive documentation. That falls outside the scope of the fpdoc project. It simply generates documentation based on what information you give it. No need to complain, *if* it were so :-( Unfortunately fpdoc ignores all given xml files, when no corresponding source file is given at the same time. Does a documentation tool serve the user, or has the user to serve the tool??? Of course this process could greatly be enhanced by the help of any IDE that knows about fpdoc. Simply ask the IDE (which already knows the source code files it manages, paths and include paths) to generate a fpdoc build script for your current project or package or library, or it could execute the fpdoc application directly. The IDE can extract from its project settings all the required information to pass to fpdoc. 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. I would suggest you implement such a feature for Lazarus IDE as I described above, or file a feature required for the Lazarus project. The Lazarus IDE already includes the FPDoc Editor, which allows to document every identifier in the sources :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 ./fixdocs.sh ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 debug information.
I have done that already, because I'm calling ppcjvm with -n option.
Or does the compiler look in its own directory first before it uses
the user config file?
No, -n prevents loading any default configuration files.
I meant without the -n, the default variant. Sorry for being unclear
here ^^
The problem seems to be something else and I'll find it sooner or
later...
There's a byte code verifier for dex files at
http://dedexer.sourceforge.net/ (search for -r), maybe it can give a
clearer diagnostic.
I'll take a look at the verifier.
In the meantime I've done my previously mentioned additional testing:
1. instantiate an android.app.Activity class inside Pascal code: works
2. derive a Pascal class from android.app.Activity (as is the case with
the full Pascal example) and instantiate that: fails
The error message still happens during instantiation of the class, but
the message looks a bit different then the other one:
=== log begin ===
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/TTestActivity;
D/dalvikvm( 375): VFY: replacing opcode 0x22 at 0x
D/dalvikvm( 375): VFY: dead code 0x0002-0018 in
Lorg/freepascal/android/TTestClass;.getTextView
(Landroid/app/Activity;)Landroid/widget/TextView;
D/AndroidRuntime( 375): Shutting down VM
W/dalvikvm( 375): threadid=1: thread exiting with uncaught exception
(group=0x40015560)
E/AndroidRuntime( 375): FATAL EXCEPTION: main
E/AndroidRuntime( 375): java.lang.InstantiationError:
org.freepascal.android.TTestActivity
E/AndroidRuntime( 375): at
org.freepascal.android.TTestClass.getTextView(androidfpc.pas)
E/AndroidRuntime( 375): at
com.example.helloandroid.HelloAndroid.onCreate(HelloAndroid.java:16)
E/AndroidRuntime( 375): at
android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
E/AndroidRuntime( 375): at
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1611)
E/AndroidRuntime( 375): at
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1663)
E/AndroidRuntime( 375): at
android.app.ActivityThread.access$1500(ActivityThread.java:117)
E/AndroidRuntime( 375): at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:931)
E/AndroidRuntime( 375): at
android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 375):at android.os.Looper.loop(Looper.java:123)
E/AndroidRuntime( 375): at
android.app.ActivityThread.main(ActivityThread.java:3683)
E/AndroidRuntime( 375): at
java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 375): at
java.lang.reflect.Method.invoke(Method.java:507)
E/AndroidRuntime( 375): at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
E/AndroidRuntime( 375): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
E/AndroidRuntime( 375):at dalvik.system.NativeStart.main(Native Method)
W/ActivityManager( 62): Force finishing activity
com.example.helloandroid/.HelloAndroid
W/ActivityManager( 62): Activity pause timeout for
HistoryRecord{406742f0 com.example.helloandroid/.HelloAndroid}
I/Process ( 375): Sending signal. PID: 375 SIG: 9
I/ActivityManager( 62): Process com.example.helloandroid (pid 375) has
died.
=== log end ===
The derived class is (on the Pascal side) a completely empty class. Just
the class declaration is there. I'll test with a declared constructor.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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/TTestActivity;
It says that the VM is instantiating an abstract class. Does the
TTestActivity.j file contain abstract in the .class line near the top? The
compiler will automatically add this keyword if a class contains one or more
(possibly inherited) abstract methods (it's required by the JVM).
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Including Sorokin's TRegExpr in FPC
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 was RegEx.pp so probably many users won't be affected. Why didn't you just give the sorokin tregexpr unit another name? This way, no incompatiblities would have been introduced. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Including Sorokin's TRegExpr in FPC
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_oldregexpr.pp The main file from Joost Reg Expresions was RegEx.pp so probably many users won't be affected. Why didn't you just give the sorokin tregexpr unit another name? This way, no incompatiblities would have been introduced. Add: because there is also Benjamin Rosseax regexpr unit. If this one is added as well, sorokins will be renamed to old2regexpr? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 class
Lorg/freepascal/android/TTestActivity;
It says that the VM is instantiating an abstract class. Does the TTestActivity.j file contain
abstract in the .class line near the top? The compiler will automatically
add this keyword if a class contains one or more (possibly inherited) abstract methods (it's
required by the JVM).
Indeed it does. In the .j as well as the disassembled .dex file:
=== part of TTestActivity.j begin ===
.bytecode 49.0
.source androidfpc.pas
.class abstract public org/freepascal/android/TTestActivity
.super android/app/Activity
=== part of TTestActivity.j end ===
=== part of TTestActivity.dex begin ===
.class public abstract org/freepascal/android/TTestActivity
.super android/app/Activity
.source androidfpc.pas
=== part of TTestActivity.dex end ===
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 (and crosscheck that with the
documentation).
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 (and crosscheck that with the documentation). If you create an instance of that class in FPC code and compile with -vw, the compiler should list the abstract methods. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 overridden correctly by the
subclasses (and crosscheck that with the documentation).
If you create an instance of that class in FPC code and compile with -vw, the
compiler should list the abstract methods.
There seems to be none :(
=== output begin ===
[sven@artemis helloandroid]$ ppcjvm -n
-Fu/mnt/data/subversion/fpc-jvm/rtl/units/jvm-java/ -FEbin/classes
-Fu../../androidlib/lib
-FD/home/sven/downloads/dev/freepascal/fpcjvmlinux-snapshot1/bin -XP -vw
src/androidfpc.pas
Generated: bin/classes/org/freepascal/android/TTestClass.class
Generated: bin/classes/org/freepascal/android/androidfpc.class
Generated: bin/classes/org/freepascal/android/TTestActivity.class
=== output end ===
The unit looks like this:
=== source begin ===
unit androidfpc;
{$mode objfpc}{$H+}
{$modeswitch unicodestrings}
{$namespace org.freepascal.android}
interface
uses
android;
type
TTestActivity = class(AAActivity)
public
constructor create;
end;
TTestClass = class(TObject)//(JLObject)
function getText: UnicodeString;
function getTextView(aActivity: AAActivity): AWTextView;
end;
implementation
constructor TTestActivity.create;
begin
inherited create;
end;
function TTestClass.getText: UnicodeString;
begin
Result := 'Hello World through FPC TObject';
end;
function TTestClass.getTextView(aActivity: AAActivity): AWTextView;
var
js: JLString;
test: AAActivity;
begin
test := TTestActivity.Create;
if test.isTaskRoot then
js := 'Hello World! Activity is task root'
else
js := 'Hello World! Activity is not task root';
Result := AWTextView.Create(aActivity);
Result.setText(js);
end;
end.
=== source end ===
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 serve the tool??? You are more than welcome to extend the tool if you want. I (and probably many others) would also welcome an alternative to Makefile usage for building fpc's docs. I loathe Makefiles. FCL have such irregular requirements, that much work is required to provide a usable command line for the compilation of the according documentation. Lazarus IDE already contains all that information, so it's just a matter of extracting the paths and writing the fpdoc command line options to a batch file. The Lazarus IDE already includes the FPDoc Editor, which allows to document every identifier in the sources :-) I wasn't referring to editing documentation, but rather managing a documentation project. Just like you use an IDE to manage a source code project, so too one could use a tool to manage a fpdoc documentation project. In fact, I remember seeing something like that already. A quick search shows that fpde (included with FPC, but for GTK1 only), and Lazarus's lazde tool have this functionality already. See the Build dialog. You can specify the output format, source and include directories, some fpdoc parameters etc.. You can load and save a documentation project. I have no idea if it is fully implemented, but would imagine it is a bit outdated compared to fpdoc features. I can't compile either fpde or lazde projects at the moment. Maybe you have better luck. eg: /opt/fpc-2.4.3/src/utils/fpdoc/fpde/ or lazarus/doceditor/ -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 it really hard to find out what is and what isn't documented. It also generates lots of unnecessary elements - obfuscating the xml and documentation more. contained in the xml files. There exists no need for adding further information from the source code, that's more eye candy than essential information. I beg to differ. Seeing the signature of a method, procedure, function etc is valuable information to a developer. Not all IDE's or programming editors support parameter hints, or some developers prefer to keep such feature disabled to speed up the editor/ide. So having such information [method signatures] available in the help is very useful. 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. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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.common.Context). I yet need to check whether all methods are overridden correctly by the subclasses (and crosscheck that with the documentation). If you create an instance of that class in FPC code and compile with -vw, the compiler should list the abstract methods. There seems to be none :( Can you make the android unit available for download somewhere? Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
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 added to all items, before finally meaningful documentation can be generated. If it were any other way, we wouldn't need source code or XML, we could just use Open Office or Word, that would be equally useful. Documentation of course needs a structure, and that structure is fully contained in the xml files. No it is not. I think you should have a good look at the XML files before writing statements like that. Take an enumerated: TMyEnum = (One, Two) It ends up in the XML file as 3 identifiers: element name=TMyEnum element name=TMyEnum.One element name=TMyEnum.Two All pascal information is lost. Only names exist, without any relations and no type info whatsoever. From the above XML information you could document equally well a record tmyenum = record one,two : integer end; a procedure, procedure tmyenum (one,two : string); an enum TMyEnum = (One, Two) A class: TMyEnum = Class Function One; Property Two end; so from this information, you could never reconstruct the pascal structures it is supposed to document. (and which of course should reside in the docs) 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: element name=TMyEnum type=enumeration element name=TMyEnum.One type=enumerationelement Parent=TMyEnum element name=TMyEnum.Two type=enumerationelement Parent=TMyEnum But, copying this information to the XML file would be a) duplicate and thus redundant information. b) require more work as soon as anything changes in the interface section. and therefor would be - in my eyes - extremely bad design. That's why the design is as it is and will not be changed anytime soon. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Including Sorokin's TRegExpr in FPC
On Tue, Aug 30, 2011 at 10:22 PM, Florian Klämpfl flor...@freepascal.org 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 even support most POSIX, so it didn't look very useful? 2 Most of Joost's code is in regex.pp which was not changed, not in oldregexpr.pp 3 Compatibility with Delphi projects which use regexpr.pas where it means Sorokin's RegExpr (I've already found a couple of those only in projects which I develop, I don't know if it was included in Delphi, but I think it is possible because I found some projects which use it but don't have it in the sources) 4 Beginners would most likely try to use regexpr.pas which has the most simple name, they are better off trying to use the Sorokin version. 5 Benjamin Rosseax regexpr is a new invention, not something well stablished and widely used like the Sorokin unit (even Lazarus uses the Sorokin version), so I recommend naming it something like benjaminregexpr or something like that. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
