Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
On 01/23/2013 10:20 AM, Thomas Schatzl wrote:
program test;
uses cmem, dynlibs;
begin
writeln('Hello');
end.
Compile with:
ppcarm -Fl/opt/arm-none-linux-gnueabi/lib test.pas
Hi Tomas.
I tested your code and compiler line on my device and it behaves as I
expected:
[/share/Public/heizarm] # ppcarm -Fl/opt/arm-linux-gnueabi/lib test.pas
Free Pascal Compiler version 2.6.0 [2011/12/27] for arm
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Linux for ARMEL
Compiling test.pas
Assembling test
Linking test
/share/Public/root/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In
function `_haltproc_eabi':
(.text+0x88): undefined reference to `_fini'
/share/Public/root/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In
function `_haltproc_eabi':
(.text+0x90): undefined reference to `_init'
test.pas(4,18) Error: Error while linking
test.pas(4,18) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
[/share/Public/heizarm] # cp /opt/arm-none-linux-gnueabi/lib/c
Obviously something in my installation is different.
/opt/arm-linux-gnueabi/lib is exactly the location where I copied crti.o
from.
I still don't see the difference between copying the file to the current
dir and using -Fl to add that dir to the library search path.
Up till now I used the gnu linker only with embedded projects in C
language via cross-compiling and without dynamic link libraries.
So I of course am lacking a lot of knowledge, but you might be inclined
to fill some gaps.
I understand that
a) the linker does not open all files in a search directory and try to
find resolutions for open (non weak) externals
b) the linker only opens the .o and .a files it is told to use (e.g. in
a linker script file - this is what I used in the said C projects)
c) if one of the denoted files is not found in any of the search
directories, the linker aborts with an error message.
Regarding my inability to link your testing program, and my other tests:
1) rather obviously the file crti.o is not a viable file to be used, as
(i) the linker will never see it unless explicitly denoted (e.g. by {$L
crti.o ) and this is not done in your successful test on your machine
and (ii) my testing programs immediately when I include it,
2) I suppose in your environment not crti.o, but some library (.a file
or maybe some other file somehow specified) is used to resolve the _init
and _finit externals.
3) I understand that for this, that library somehow needs to be
specified, as I believe the linker will not on it's own go out and
search and open files that might provide these globals.
4) Thus in your environment somehow such a library file is specified.
Maybe it's done in fpc.cfg, which in my environment has not been
obtained in a really decent way ant the syntax of which I fail to
understand well enough. (The file did not come with the 2.6.0 TAR
distribution, so it is inherited from the Debian 2.2 stuff ).
5) In dl.pp (That I understand you test program implicitly pulls), there
is the line {$linklib c}. I don't really understand what exactly this is
suppose to mean. I would _assume_ that it might be an instruction to the
linker to use the library file c.a but I believe there is no file with
such name. So there might be some compiler magic that constructs a
different instruction to the linker.
-Michael
FYI: This is the content of /opt/arm-linux-gnueabi/lib on this machine:
[/opt/lib] # ls -l
drwxr-xr-x2 adminadminist 4096 Jan 3 11:36 armv4t/
-rwxr-xr-x1 adminadminist 7132 Feb 14 2012 e2initrd_helper*
drwxr-xr-x3 adminadminist 4096 Jan 3 11:36 gcc/
drwxr-xr-x3 adminadminist 4096 Jan 3 11:10 gio/
drwxr-xr-x3 adminadminist 4096 Jan 3 11:10 glib-2.0/
drwxr-xr-x4 adminadminist 4096 Jan 3 15:18 groff/
drwxr-xr-x5 adminadminist 4096 Jan 21 22:52 ipkg/
-rw-r--r--1 adminadminist 4407522 Feb 14 2012 libbfd.a
-rwxr-xr-x1 adminadminist 937 Feb 14 2012 libbfd.la*
lrwxrwxrwx1 adminadminist 13 Jan 3 11:10 libblkid.so -
libblkid.so.1*
lrwxrwxrwx1 adminadminist 15 Jan 3 11:10 libblkid.so.1 -
libblkid.so.1.0*
-rwxr-xr-x1 adminadminist41080 Feb 14 2012 libblkid.so.1.0*
-rw-r--r--1 adminadminist 209 Feb 14 2012 libc.so
-rw-r--r--1 adminadminist20912 Feb 14 2012 libc_nonshared.a
lrwxrwxrwx1 adminadminist 15 Jan 3 11:10 libcom_err.so -
libcom_err.so.2*
lrwxrwxrwx1 adminadminist 17 Jan 3 11:10 libcom_err.so.2
- libcom_err.so.2.1*
-rwxr-xr-x1 adminadminist 8828 Feb 14 2012 libcom_err.so.2.1*
-rwxr-xr-x1 adminadminist 721164 Feb 15 2012 libdb-4.2.so*
lrwxrwxrwx1 adminadminist 12 Jan 3 11:24 libdb-4.so -
libdb-4.2.so*
lrwxrwxrwx1 adminadminist 12 Jan 3 11:24 libdb.so
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
On Thu, Jan 24, 2013 at 11:07:25AM +0100, Michael Schnell wrote:
FYI: This is the content of /opt/arm-linux-gnueabi/lib on this machine:
[/opt/lib] # ls -l
is not the same as the path you added with -Fl. And there
is no crti.o here. There isn't even an arm-linux-gnueabi directory
here, so why did you add that path if it doesn't even exist?
Find crti.o on the device and add that path to -Fl.
drwxr-xr-x2 adminadminist 4096 Jan 3 11:36 armv4t/
-rwxr-xr-x1 adminadminist 7132 Feb 14 2012 e2initrd_helper*
drwxr-xr-x3 adminadminist 4096 Jan 3 11:36 gcc/
drwxr-xr-x3 adminadminist 4096 Jan 3 11:10 gio/
drwxr-xr-x3 adminadminist 4096 Jan 3 11:10 glib-2.0/
drwxr-xr-x4 adminadminist 4096 Jan 3 15:18 groff/
drwxr-xr-x5 adminadminist 4096 Jan 21 22:52 ipkg/
-rw-r--r--1 adminadminist 4407522 Feb 14 2012 libbfd.a
-rwxr-xr-x1 adminadminist 937 Feb 14 2012 libbfd.la*
lrwxrwxrwx1 adminadminist 13 Jan 3 11:10 libblkid.so
- libblkid.so.1*
lrwxrwxrwx1 adminadminist 15 Jan 3 11:10
libblkid.so.1 - libblkid.so.1.0*
-rwxr-xr-x1 adminadminist41080 Feb 14 2012 libblkid.so.1.0*
-rw-r--r--1 adminadminist 209 Feb 14 2012 libc.so
-rw-r--r--1 adminadminist20912 Feb 14 2012 libc_nonshared.a
lrwxrwxrwx1 adminadminist 15 Jan 3 11:10
libcom_err.so - libcom_err.so.2*
lrwxrwxrwx1 adminadminist 17 Jan 3 11:10
libcom_err.so.2 - libcom_err.so.2.1*
-rwxr-xr-x1 adminadminist 8828 Feb 14 2012 libcom_err.so.2.1*
-rwxr-xr-x1 adminadminist 721164 Feb 15 2012 libdb-4.2.so*
lrwxrwxrwx1 adminadminist 12 Jan 3 11:24 libdb-4.so
- libdb-4.2.so*
lrwxrwxrwx1 adminadminist 12 Jan 3 11:24 libdb.so -
libdb-4.2.so*
lrwxrwxrwx1 adminadminist 11 Jan 3 11:10 libe2p.so -
libe2p.so.2*
lrwxrwxrwx1 adminadminist 13 Jan 3 11:10 libe2p.so.2
- libe2p.so.2.3*
-rwxr-xr-x1 adminadminist22796 Feb 14 2012 libe2p.so.2.3*
lrwxrwxrwx1 adminadminist 14 Jan 3 11:10 libext2fs.so
- libext2fs.so.2*
lrwxrwxrwx1 adminadminist 16 Jan 3 11:10
libext2fs.so.2 - libext2fs.so.2.4*
-rwxr-xr-x1 adminadminist 163556 Feb 14 2012 libext2fs.so.2.4*
lrwxrwxrwx1 adminadminist 12 Jan 3 10:29 libform.so
- libform.so.5*
lrwxrwxrwx1 adminadminist 14 Jan 3 10:29 libform.so.5
- libform.so.5.7*
-rwxr-xr-x1 adminadminist44884 Dec 24 06:48 libform.so.5.7*
lrwxrwxrwx1 adminadminist 13 Jan 3 15:19 libformw.so
- libformw.so.5*
lrwxrwxrwx1 adminadminist 15 Jan 3 15:19
libformw.so.5 - libformw.so.5.7*
-rwxr-xr-x1 adminadminist52232 Dec 22 00:32 libformw.so.5.7*
lrwxrwxrwx1 adminadminist 13 Jan 3 11:36 libgcc_s.so
- libgcc_s.so.1
-rw-r--r--1 adminadminist 238932 Feb 15 2012 libgcc_s.so.1
lrwxrwxrwx1 adminadminist 16 Jan 3 11:24 libgdbm.so
- libgdbm.so.3.0.0*
lrwxrwxrwx1 adminadminist 16 Jan 3 11:24 libgdbm.so.3
- libgdbm.so.3.0.0*
-rwxr-xr-x1 adminadminist18660 Feb 18 2012 libgdbm.so.3.0.0*
lrwxrwxrwx1 adminadminist 23 Jan 3 11:24
libgdbm_compat.so - libgdbm_compat.so.3.0.0*
lrwxrwxrwx1 adminadminist 23 Jan 3 11:24
libgdbm_compat.so.3 - libgdbm_compat.so.3.0.0*
-rwxr-xr-x1 adminadminist 6188 Feb 18 2012
libgdbm_compat.so.3.0.0*
-rwxr-xr-x1 adminadminist 1063 Feb 14 2012 libgio-2.0.la*
lrwxrwxrwx1 adminadminist 22 Jan 3 11:10
libgio-2.0.so - libgio-2.0.so.0.2000.4*
lrwxrwxrwx1 adminadminist 22 Jan 3 11:10
libgio-2.0.so.0 - libgio-2.0.so.0.2000.4*
-rwxr-xr-x1 adminadminist 415536 Feb 14 2012
libgio-2.0.so.0.2000.4*
-rwxr-xr-x1 adminadminist 986 Feb 14 2012 libglib-2.0.la*
lrwxrwxrwx1 adminadminist 23 Jan 3 11:10
libglib-2.0.so - libglib-2.0.so.0.2000.4*
lrwxrwxrwx1 adminadminist 23 Jan 3 11:10
libglib-2.0.so.0 - libglib-2.0.so.0.2000.4*
-rwxr-xr-x1 adminadminist 842160 Feb 14 2012
libglib-2.0.so.0.2000.4*
-rwxr-xr-x1 adminadminist 1033 Feb 14 2012 libgmodule-2.0.la*
lrwxrwxrwx1 adminadminist 26 Jan 3 11:10
libgmodule-2.0.so - libgmodule-2.0.so.0.2000.4*
lrwxrwxrwx1 adminadminist 26 Jan 3 11:10
libgmodule-2.0.so.0 - libgmodule-2.0.so.0.2000.4*
-rwxr-xr-x1 adminadminist 9960 Feb 14 2012
libgmodule-2.0.so.0.2000.4*
-rwxr-xr-x1 adminadminist 1028 Feb 14 2012 libgobject-2.0.la*
lrwxrwxrwx1 adminadminist 26 Jan 3 11:10
libgobject-2.0.so - libgobject-2.0.so.0.2000.4*
lrwxrwxrwx1 adminadminist 26 Jan 3 11:10
libgobject-2.0.so.0 - libgobject-2.0.so.0.2000.4*
-rwxr-xr-x1 admin
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
On 01/24/2013 11:17 AM, Henry Vermaak wrote: And there is no crti.o here. There isn't even an arm-linux-gnueabi directory here, so why did you add that path if it doesn't even exist? I'll recheck as soon as I have access to the box. From the top of my head I remember that in fact the directory Thomas instructed me to include in the compiler command line does exit. Thanks for the hint, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Am 24.01.2013 11:07, schrieb Michael Schnell: 4) Thus in your environment somehow such a library file is specified. Maybe it's done in fpc.cfg, which in my environment has not been obtained in a really decent way ant the syntax of which I fail to understand well enough. (The file did not come with the 2.6.0 TAR distribution, so it is inherited from the Debian 2.2 stuff ). While unrelated to your problem: the syntax of the fpc.cfg file is simple. It's main content is just the same options that can be given on the command line of the compiler. Instead of seperating them by spaces they are seperated by newlines though. Additionally the config file allows conditional configuration by using define, ifdef and co (similar to Pascal code). For this certain defines of the compiler are available as well (like the selected target and whether this is a cross compilation). Also you can use variables through $name with which you can insert the contents of internal compiler variables (like $fpcversion = 2.7.1) or of environment variables. On Windows systems you can also have access to the CSIDL_... paths (though just now I don't remember how exactly you can access them...). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Thanks for the clarification. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
On 01/24/2013 02:08 PM, Thomas Schatzl wrote:
Looking back, so it want's some _init and _fini...
In your mail titled [fpc-devel] Install fpc and Friends on a non-Debian
ARM-Linux Device you state:
I found, that _fini and _init *should* be provided by crti.o which is
not included in the packages I installed. And I don't know how to find
out which package might provide it.
In the Internet, I found the hint to use crti.o. But now I don't believe
that this is a valid advice.
The _init and _fini you need are the ones from libdl.so.
I am very inclined to believe that you are right, but seemingly in my
project libdl.so is not linked in (I hope to find out, how an .so is
linked at compile time, how it is made known to the linker in your
environment and why it does not work in my environment, so I'm eagerly
reading on)
Can you explain how you got to the impression that you need a
crti.o that provides _init and _fini? Just curious.
Just using Google I found this advice in some forums.
If you happen to finally find and specify the correct path to the
correct libdl.so it will definitely work.
I'll try this. But I still fail to understand how the linker is supposed
to know that it should look into this file.
There is no bug in fpc.
I hoped this and that is why I did not file a Mantis entry right away.
Obviously something in my installation is different.
/opt/arm-linux-gnueabi/lib is exactly the location where I copied crti.o
from.
I still don't see the difference between copying the file to the current
dir and using -Fl to add that dir to the library search path.
Because it's the wrong _init and _fini.
Yep. In other words: crti.o is the wrong file. (even though (IIRC) it is
in the dir you told me to provide in -Fl
It tries the ones you add with {$linklib}
That is what I understand, but the line I saw in the unit in question
(dl.pp) confusingly is {$linklib c} and there is no c.whatever file that
is supposed to be linked in..
2) I suppose in your environment not crti.o, but some library (.a file
or maybe some other file somehow specified) is used to resolve the _init
and _finit externals.
libdl-version.so
I see. The name in fact is speaking regarding it is pulled by dl.pp.
But the compiler magic creating linker please look at
libdl-version.so, and do what is necessary for dynamic library
support from {$linklib c} is far beyond my understanding.
3) I understand that for this, that library somehow needs to be
specified, as I believe the linker will not on it's own go out and
search and open files that might provide these globals.
Already done via {$linklib dl}.
Ahhh. But yet I did not yet see this line. (I just found {$linklib c}).
Ill take another look
This searches for libdl.so in the a)
default paths hardcoded into fpc and b) everything specified by -Fl.
I suppose the current directory and instructions from fpc.cfg are
additional options.
4) Thus in your environment somehow such a library file is specified.
Maybe it's done in fpc.cfg, which in my environment has not been
obtained in a really decent way ant the syntax of which I fail to
understand well enough. (The file did not come with the 2.6.0 TAR
distribution, so it is inherited from the Debian 2.2 stuff ).
You can create one using the install.sh script?
Which install.sh ? I used the one in the TAR fpc distribution and it did
not say it created one and I did not find it one the newly created
installation dir that I provided as the script asked me. Maybe it
overwrote the one in /etc without notice. I'll take another look.
No, per shared library naming convention a lib prefix is added.
I see: {$linklib dl} is translated to libdl-version.so This does make
sense. But in the svn Trunk version of dl.pp there in fact is {$linklib
c} this should be translated to libc-version.so. I don't know how this
is related and maybe {$linklib dl} just is found somewhere else.
Anyway if {$linklib dl} is in the source, a file not found error
message be issued if libdl-version.so is not found, but instead we
just see the the unresolved external messages.
.a files are used to link a library statically. Not needed here, and you
don't use $linklib with them.
I understand (just curious: is there another {$??? } instruction for
static libraries ?
hth+sorry,
I am very happy with all the valuable information I got.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Hi,
On Thu, 2013-01-24 at 16:13 +0100, Michael Schnell wrote:
On 01/24/2013 02:08 PM, Thomas Schatzl wrote:
Looking back, so it want's some _init and _fini...
2) I suppose in your environment not crti.o, but some library (.a file
or maybe some other file somehow specified) is used to resolve the _init
and _finit externals.
libdl-version.so
I see. The name in fact is speaking regarding it is pulled by dl.pp.
But the compiler magic creating linker please look at
libdl-version.so, and do what is necessary for dynamic library
support from {$linklib c} is far beyond my understanding.
Actually {$linklib x} searches for libx.so . But libx.so (without
version) is typically symlinked to the actual one.
3) I understand that for thut notice. I'll take another look.
If you untar the fpc-whatever file there should be an install.sh *if*
you downloaded what I think is the tar fpc distribution.
is, that library somehow needs to be
specified, as I believe the linker will not on it's own go out and
search and open files that might provide these globals.
Already done via {$linklib dl}.
Ahhh. But yet I did not yet see this line. (I just found {$linklib c}).
Ill take another look
The {$linklib c} is in addition to the external reference to libdl in
the function interfaces.
E.g.
function dlclose(Lib : Pointer) : Longint; cdecl; external libdl;
and libdl is a constant containing the 'dl' string. Again the usual
rules for name expansion apply here.
You may want to look at fpc manuals how to use external libraries and
what options there are.
This searches for libdl.so in the a)
default paths hardcoded into fpc and b) everything specified by -Fl.
I suppose the current directory and instructions from fpc.cfg are
additional options.
4) Thus in your environment somehow such a library file is specified.
Maybe it's done in fpc.cfg, which in my environment has not been
obtained in a really decent way ant the syntax of which I fail to
understand well enough. (The file did not come with the 2.6.0 TAR
distribution, so it is inherited from the Debian 2.2 stuff ).
You can create one using the install.sh script?
Which install.sh ? I used the one in the TAR fpc distribution and it did
not say it created one and I did not find it one the newly created
installation dir that I provided as the script asked me. Maybe it
overwrote the one in /etc without notice. I'll take another look.
If you untar the fpc-whatever file there should be an install.sh *if*
you downloaded what I think is the tar fpc distribution.
It would be nice, that if you have more questions about this, and you
think it's interesting, define tar fpc distribution after all. I.e.
give an exact location where you got it from. I seems to me I already
asked multiple times for you to tell us, and we still don't know
exactly.
No, per shared library naming convention a lib prefix is added.
I see: {$linklib dl} is translated to libdl-version.so This does make
sense. But in the svn Trunk version of dl.pp there in fact is {$linklib
c} this should be translated to libc-version.so. I don't know how this
is related and maybe {$linklib dl} just is found somewhere else.
dl and its functions are special. They are typically actually
implemented in the loader (ld-linux.so) according to some websites.
ld-linux.so is more or less a fake shared library, so you cannot link to
it in the normal way.
Libdl (and always?) libc both export these symbols. But they are only
forwards to ld.so in the end I read somewhere.
E.g. do objdump -t libdl, and at least here, for e.g. dlopen it
indicates that it's a forward to the libc function.
For several reasons, compatibility is one, libdl still exists. You can
also simply use the c library in some cases it seems. Apparently the
original author of the arm/linux port found eons ago that on his
arm/linux there was no particular libdl or it did not work without the
{$linklib c}, so he added the define. Maybe it just hid a bug that was
fixed later and the linklib c forgotten. Don't read too much into some
code from r6355, especially it has a comment arm-linux seems to require
this going with it.
You can also see in dl.pp, that the functions dl provides is in
different libraries on different platforms.
Anyway if {$linklib dl} is in the source, a file not found error
message be issued if libdl-version.so is not found, but instead we
just see the the unresolved external messages.
FPC is not responsible for gnu ld error messages. Ask them what they
thought when implementing this. You could probably also get more
detailed information about the linking process in linux with ELF files
there too.
Thomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPJSONRTTI: Case insensitive.
Hello,
I have this JSON:
{ id: 1, name: Silvio Clécio }
And my object is:
TPerson = class
private
FID: Int64;
FName: string;
published
property ID: Int64 read FID write FID;
property Name: string read FName write FName;
end;
But, FPJSONRTTI don't find the fields, except if I change my class to:
property id: Int64 read FID write FID;
property name: string read FName write FName;
Or my JSON to:
{ ID: 1, Name: Silvio Clécio }
So, how to I find all fields but in case insensitive? (like TypInfo
functions)
Thank you!
ps. Marshal of Delphi is case insensitive.
ps2. So, I send this my questions only to fpc-devel or fpc-pascal? :/
--
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] for-in-index loop
Hi FPC team, There is good proposed extension of for-in loop on fpc wiki: get enumerator Position if available http://wiki.freepascal.org/for-in_loop#Proposed_extensions. From my point of view it's essential part of iterators. Especially for data structures which store pairs of key and value associated with key. I want to implement this extension. Moreover I started implementation to explore fpc internals. Current /(not finished)/ result available on github. https://github.com/vkevroletin/freepascal/tree/key-value-iterator My motivation is simple: I'm a student. My teacher is Alexander S. Klenin who should be well known to fp? developers. And I want to implement some feature of fpc as my graduate work. Through improvement of for-in loop is not enough for good graduate work but it is good initial step towards other big contribution. So is get enumerator Position if available http://wiki.freepascal.org/for-in_loop#Proposed_extensions good idea? Thanks, Vasiliy Kevroletin P.S. links for people who dislike computer mouse: proposed extension - http://wiki.freepascal.org/for-in_loop#Proposed_extensions my branch on github - https://github.com/vkevroletin/freepascal/tree/key-value-iterator ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPJSONRTTI: Case insensitive.
On Thu, 24 Jan 2013, silvioprog wrote:
Hello,
I have this JSON:
{ id: 1, name: Silvio Clécio }
JSON is JavaScript and JavaScript *is* case sensitive.
But you can use TJSONObject.IndexOfName with CaseInsentive to True:
Function IndexOfName(const AName: TJSONStringType; CaseInsensitive :
Boolean = False): Integer;
Line 450 of fpjsonrtti could be changed to set this to True, but it will have a
bad impact on performance.
Maybe we can have a property for this.
You should fix your incoming JSON instead.
Michael.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
Apologies for revisiting an old thread.
michael.vancann...@wisa.be wrote:
Will global variables and static global arrays be always
initialized to
zero?
Yes.
Are there cases where locals are set to a sane initial state, e.g. for
strings and dynamic arrays? What about (references to) objects?
Managed types are normally initialized. That means Ansistrings,
UnicodeString, and COM interfaces and dynamic arrays (maybe I forget some)
Classes and objects are not. I am not sure about widestrings on Windows.
Looking at this code:
function WagnerFischerBestMatch(const pattern: string; stringList:
TStringList): integer;
var scratch: StringArray; // array of string;
i: integer;
begin
for i := 0 to stringList.Count - 1 do
scratch += stringList[i];
where + has been defined to append an element to the array, I get a
warning that scratch hasn't been initialised. Similarly
function singleRadioGroup(items: TMenuItem): string;
var i: integer;
gi: integer= 0;
name, firstName, checkedName: string;
begin
..
if firstName = '' then
In view of what you said about managed types, is it safe to assume that
the error message is spurious? I'm a little reluctant to add an explicit
e.g. SetLength(scratch, 0) or to break the string declarations onto
separate lines simply to suppress a warning, when it isn't necessary for
correctness.
I note the fairly recent introduction of {%H- } to tell Lazarus to
filter out specific warnings.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Fri, Jan 25, 2013 at 4:45 AM, Michael Van Canneyt mich...@freepascal.org wrote: Enumerators are not iterators. Eh... actually, they are? Why do you think otherwise? If you want a full-fledged iterator, you should use classes. Enumerators *are* classes, except for built-in ones. The for syntax is not meant for that. That's debatable. There is no for-index support in Java, but there is in most (all?) other modern languages -- Python, PHP, Ruby, etc. I suggest that Java is inferior in this regard. If you want full fledged iterators, use classes. Please provide example of your suggesion for the case in the wiki. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Den 23-01-2013 00:54, vrt277 skrev: Hi FPC team, There is good proposed extension of for-in loop on fpc wiki: get enumerator Position if available http://wiki.freepascal.org/for-in_loop#Proposed_extensions. From my point of view it's essential part of iterators. Especially for data structures which store pairs of key and value associated with key. I want to implement this extension. Moreover I started implementation to explore fpc internals. Current /(not finished)/ result available on github. https://github.com/vkevroletin/freepascal/tree/key-value-iterator My motivation is simple: I'm a student. My teacher is Alexander S. Klenin who should be well known to fp? developers. And I want to implement some feature of fpc as my graduate work. Through improvement of for-in loop is not enough for good graduate work but it is good initial step towards other big contribution. So is get enumerator Position if available http://wiki.freepascal.org/for-in_loop#Proposed_extensions good idea? Thanks, Vasiliy Kevroletin P.S. links for people who dislike computer mouse: proposed extension - http://wiki.freepascal.org/for-in_loop#Proposed_extensions my branch on github - https://github.com/vkevroletin/freepascal/tree/key-value-iterator I think the idea is good if the feature is implemented as optional. That way: - If the enumerator class implements a CurrentIndex method then the for loop can have an index variable. - If not then the for loop can only behave as current for in loops. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Am 24.01.2013 20:36, schrieb Alexander Klenin: That's debatable. As long as there is only some few line idea, there cannot debated much. Just an example: what happens with i if I start to delete from s during the for loop? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Fri, Jan 25, 2013 at 7:18 AM, Jeppe Græsdal Johansen jjoha...@student.aau.dk wrote: I think the idea is good if the feature is implemented as optional. That way: - If the enumerator class implements a CurrentIndex method then the for loop can have an index variable. - If not then the for loop can only behave as current for in loops. Of course. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
In our previous episode, Florian Kl?mpfl said: As long as there is only some few line idea, there cannot debated much. http://www.freepascal.org/faq.var#extensionselect ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Fri, Jan 25, 2013 at 7:30 AM, Florian Klämpfl flor...@freepascal.org wrote: Am 24.01.2013 20:36, schrieb Alexander Klenin: That's debatable. As long as there is only some few line idea, there cannot debated much. It is more: an idea with implementation and tests ;) Just an example: what happens with i if I start to delete from s during the for loop? Exactly the same thing as in the current for-in loop: either a range check error of nothing, depending on what you delete. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Fri, Jan 25, 2013 at 7:34 AM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Florian Kl?mpfl said: As long as there is only some few line idea, there cannot debated much. http://www.freepascal.org/faq.var#extensionselect Yes, current discussion is based on that guideline. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Am 24.01.2013 21:35, schrieb Alexander Klenin: On Fri, Jan 25, 2013 at 7:30 AM, Florian Klämpfl flor...@freepascal.org wrote: Am 24.01.2013 20:36, schrieb Alexander Klenin: That's debatable. As long as there is only some few line idea, there cannot debated much. It is more: an idea with implementation and tests ;) Just an example: what happens with i if I start to delete from s during the for loop? Exactly the same thing as in the current for-in loop: either a range check error of nothing, depending on what you delete. How do you ensure this if I delete a char already processed? Will i be adjusted? Or will the loop continue to run with an invalid i? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Am 24.01.2013 22:26, schrieb Alexander Klenin: On Fri, Jan 25, 2013 at 7:56 AM, Florian Klämpfl flor...@freepascal.org wrote: Just an example: what happens with i if I start to delete from s during the for loop? Exactly the same thing as in the current for-in loop: either a range check error of nothing, depending on what you delete. How do you ensure this if I delete a char already processed? Will i be adjusted? Or will the loop continue to run with an invalid i? Depends on whom you mean by you. You: the designers of this extension. If you mean the programmer who uses the feature, then the answer is the usual one -- by thinking. Or a good possibilty to create hard to find bugs. If you mean the compiler, then the answer is also the usual one -- you can not. Consider these examples: for i := 1 to Length(s) do begin Writeln(i, ' ', s[i]); DeleteSomePartOfS; end; i := 1; for c in s do begin Writeln(i, ' ', c); DeleteSomePartOfS; i += 1; end; for c in s index i do begin Writeln(i, ' ', c); DeleteSomePartOfS; end; in all three cases, the effect will be more-or-less the same. In the first two cases the programmer knows that he does something strange, actually he can even adjust i if needed. In the last he might expect that i is always correct because it is a language construct and he has no change to fix i. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Am 24.01.2013 21:41, schrieb Alexander Klenin: On Fri, Jan 25, 2013 at 7:34 AM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Florian Kl?mpfl said: As long as there is only some few line idea, there cannot debated much. http://www.freepascal.org/faq.var#extensionselect Yes, current discussion is based on that guideline. ... or based on that what this guideline does not cover. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Fri, Jan 25, 2013 at 8:44 AM, Florian Klämpfl flor...@freepascal.org wrote: Am 24.01.2013 22:26, schrieb Alexander Klenin: in all three cases, the effect will be more-or-less the same. In the first two cases the programmer knows that he does something strange, actually he can even adjust i if needed. In the last he might expect that i is always correct because it is a language construct and he has no change to fix i. Well, it so happens that the current implementation does what you wish -- i.e. it guarantees that the loop will work regardless of the changes to s. However, in my opinion that it is an overkill, and careless changing the iterated object during the iteration *should* lead to exceptions, since it is a programmer error. Anyway, this question should be discussed separately from the for-in-index extension, since it affects the behaviour of existing code. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/24/13 19:36, Alexander Klenin wrote: Enumerators are not iterators. Eh... actually, they are? Why do you think otherwise? Enumerators are limited in functionality. Iterators are the full-blown thing. Common Iterator API is something like Next, Prev, Reset, HasNext, HasPrev etc. Enumerators normally just advance and only in one direction. This is how it is in many frameworks. Even Java's documentation describes it like that - see the bottom of the page for Iterator. http://docs.oracle.com/javase/6/docs/technotes/guides/collections/reference.html Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Fri, Jan 25, 2013 at 9:36 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
If you want full fledged iterators, use classes.
Please provide example of your suggestion for the case in the wiki.
I don't need to provide *anything*.
Of course you do not, this is why I said please :)
However, it is impossible to have a meaningful discussion without such
an example,
so could you please indulge me?
Out in the real world, you'll need to prove that this actually is useful and
will be used a lot.
For in is debatable by itself. It is syntactical sugar, it provides
nothing that for a:=b to c does not give.
The whole concept of high-level programming language is to add syntax
sugar to the assembly/machine code.
So the question is, indeed, how often this particular sugar would be used.
As an example, I have made a quick survey of TAChart code, since it is
familiar for me and easily available
for everybody here.
TAChart (with demoes) contains about 410 for loops.
Of those, 82 are already converted to for-in. Of the rest, about 200
are iterating over whole containers --
others are partial iteration, coordinate iteration, etc.
Of these 200, there are three reasons for not using for-in:
1) Oversight. I convert code are I work on it, so some loops just wait
their turn.
2) Modifying the container (I have another extension proposal for
these -- for var i in a syntax).
3) Requiring loop index -- those are the ones we are interested now.
After a quick look, I estimate about 30 such places.
So from the above study we can estimate that 5-7% of all for loops,
and 20-30% of for-in loops would benefit from the proposed extension.
Now you propose to extend this sugar syntax with something even more
exotic, which I have not even encountered in other languages.
PHP:
foreach($array as $index = $value)
...
Python:
for i, item in enumerate(seq):
...
Ruby:
set.each do |item,value|
...
end
Go:
for index, value := range someCollection {
...
}
Objective C:
[items enumerateObjectsUsingBlock:^(id item, NSUInteger idx, BOOL *stop)
{
…
}];
JavaScript:
array.forEach(function(value, index) {
...
});
Java indeed does not have it.
Perl where every possible idea of every
contributor that popped up on a blue monday was implemented and incorporated.
Why do you think so? Just look at the in perl-porters mail archive --
they are very far from implement every possible idea, I assure you.
Go and propose your idea to the gcc team as an extension to C. let's see how
far you get...
C is not a reasonable comparison, since it is much lower level language.
I could also go and propose to include classes, sets, strings -- they
all do not make sense in C.
Now, C++ is a much better comparison target.
Unfortunately, current pace of evolution for C++ language is incredibly slow.
It only for for-in last year, in the latest version of the standard.
I think it is reasonable to assume that next version of C++ might
include for-in-index syntax.
Unfortunately, I also think it is reasonable to estimate the timeframe
for that version as 5-7 years at least.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Fri, Jan 25, 2013 at 10:13 AM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 01/24/13 19:36, Alexander Klenin wrote: Enumerators are not iterators. Eh... actually, they are? Why do you think otherwise? Enumerators are limited in functionality. Iterators are the full-blown thing. Common Iterator API is something like Next, Prev, Reset, HasNext, HasPrev etc. Enumerators normally just advance and only in one direction. This is how it is in many frameworks. Even Java's documentation describes it like that - see the bottom of the page for Iterator. http://docs.oracle.com/javase/6/docs/technotes/guides/collections/reference.html I see. However, I also see: http://docs.oracle.com/javase/6/docs/api/java/util/Enumeration.html New implementations should consider using Iterator in preference to Enumeration. So in Java, enumerator is basically just a deprecated term for older and weaker version of iterator. In the case of Pascal, I would rather say that enumerators are iterators implementing a special interface, which allow them to be used with a specific syntax. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/24/13 23:26, Alexander Klenin wrote: If you want full fledged iterators, use classes. Please provide example of your suggestion for the case in the wiki. I don't need to provide *anything*. Of course you do not, this is why I said please :) However, it is impossible to have a meaningful discussion without such an example, so could you please indulge me? Do you want examples of Iterator classes? If so, I have a such implementations I have used for years, and can iterate just about any collection object without issue. Getting such an Iterator instance is as single line of code. If that is what you are talking about, I can email you a copy. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Fri, Jan 25, 2013 at 10:38 AM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 01/24/13 23:26, Alexander Klenin wrote: If you want full fledged iterators, use classes. Please provide example of your suggestion for the case in the wiki. I don't need to provide *anything*. Of course you do not, this is why I said please :) However, it is impossible to have a meaningful discussion without such an example, so could you please indulge me? Do you want examples of Iterator classes? If so, I have a such implementations I have used for years, and can iterate just about any collection object without issue. Not quite. I am aware of various iterator implementations, including yours. What I wanted is an example of implementation Michael suggested, because he said that his variant is better then mine, so a wanted to look at it to compare. Do I understand correctly that you are speaking about this article: http://opensoft.homeip.net/articles/iterator_pattern.pdf ? As far as I understand, since iterators described in the article do not have the concept of a current item, they also do not have concept of an index, and hence are not relevant in the context of this discussion. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Hi all, I want to clarify what *feature will be optional* and will not break compatibility. I suppose what back compatibility is required for all minor changes. *I was thinking it's always by default :)* *Michael Van Canneyt*, FPC is not the playground for every possible idea out there. If someone wants to implement some weird syntax: please; use FPC to try and test it, create your dissertation, whatnot. May be you understood what I'm from university in wrong way. It does *not*mean what I need to quickly do any changes anywhere. It means what I have resources *(time, motivation, direct support of very good programmer) *to improve good open project. Work will not have any good value for me if results of work will not have any good value for other people. For in is debatable by itself. It is syntactical sugar, it provides nothing that for a:=b to c does not give. Now you propose to extend this sugar syntax with something even more exotic, which I have not even encountered in other languages. 1. Syntax is subject of discussion and can be changed. 2. Freepascal already have for-in syntax sugar. Why not to make it more flexible? Request of this what for-in-index is on fpc wiki. Some other pascal programmers told in this thread what this is good feature. Evolution of other popular programming languages shows what for-in-index loop have real value *(describes by Alexander S. Klenin)*. Implementation of for-in-index will be basad on existing for-in loop. Thus feature will have almost same behavior as for-in loop. All implementation problems described in this thread relate to existing for-in loop. They are not relevant to discussion of for-in-index loop. I understand why you don't want to support bad features. But I don't understand why reasonable extension of existing feature (which will not break compatibility and which exists in other languages) is bad ? :) Best regards, Vasiliy Kevroletin 2013/1/25 Paul Ishenin i...@kmiac.ru 25.01.2013 4:32, Alexander Klenin пишет: On Fri, Jan 25, 2013 at 7:18 AM, Jeppe Græsdal Johansen jjoha...@student.aau.dk wrote: I think the idea is good if the feature is implemented as optional. That way: - If the enumerator class implements a CurrentIndex method then the for loop can have an index variable. - If not then the for loop can only behave as current for in loops. Of course. Then I also have nothing against this feature. If it is controllable by enumrator to allow/reject this then it is ok. Best regards, Paul Ishenin __**_ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-develhttp://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
25.01.2013 11:47, Василий Кевролетин пишет: May be you understood what I'm from university in wrong way. It does *not* mean what I need to quickly do any changes anywhere. It means what I have resources /(time, motivation, direct support of very good programmer) /to improve good open project. Work will not have any good value for me if results of work will not have any good value for other people. That's good that you have resources and motivation. The question is where to apply them. I understand why you don't want to support bad features. But I don't understand why reasonable extension of existing feature (which will not break compatibility and which exists in other languages) is bad ? :) You need to look at another Michael mail where he claims that he was against for-in loop feature when it had going to be implemented. So no suprise that he is against extending it now. Michael, please don't demotivate our potential compiler developers :) Let's look how suggested feature makes compiler worse. Some answers I already know, some needs to be clarified: 1. Does it adds new (semi-)reserved words? No, index is already a semi-reserved word which is used for property declaration. So scanner will not be changed. 2. Does it influence other features than for-in loop? As I see, other parts of compiler will not be changed. 3. Will it add much code which is needs to be supported? I don't know but expect it will add not much. Vasiliy, can you put your patch somewhere to look at overall compiler change? 4. Jonas, can you tell about for-in loop for objective-pascal dialect? I know it implementation depends on some Objective-C classes. Do they support current index/key return? Do you against 'index' extension for ObjP dialect and in general? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
