Re: [fpc-devel] threads vs widestringmanager / crash
On 20-12-2022 21:12, Sven Barth via fpc-devel wrote: So the only logical solution is to stop the offending thread from executing or not to have it call InitThread() while the initialization section of the System unit is still running. The former might have unintended consequences (e.g. not being able to debug the unit initialization) while the later might work in most cases as long as that remote thread doesn't need to execute code that relies on InitThread(). The latter may be the best solution. Skip any rtl call when a thread attaches during initialization. In normal cases this will only be triggered when a debugger attaches. It usually only forces a breakpoint, so no fully initialized rtl is needed. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] x86 TEST instruction
On 27-6-2022 04:43, J. Gareth Moreton via fpc-devel wrote: Hi everyone, I'm playing around with a peephole optimization (back to my roots!) and I've come across a relatively simple one that aims to reduce instruction size occasionally. One part involves reducing the opsize if the constant is numeric. For example: testl $17,76(%rcx) -> testb $17,76(%rcx) Or: testl $1,%ebx -> testb $1,%bl Obviously I check to make sure the constant fits into the smaller size. Is there a time when this is NOT recommended? I'm trying to remember issues with partial register or memory writes, but in this case, it's just a partial read. It's not only the constant size which has to fit, but also the other operand. So you cannot use it for testing an integer for the value of 1 Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unable to find resource
Solved
One of the changes I made was a rename of the unit where the resource is
included. And there was still one unit using the old name (and the old
ppu/o could be found)
Sorry for the noise,
Marc
On 22-4-2022 14:41, Marc Weustink via fpc-devel wrote:
OK, stash pop. You would think the problems should be the back... Yes
they are, only different:
Debug: parsing parameter 'x_service.res'
Debug: parsing parameter 'x_service.res'
Debug: parsing parameter 'x.res'
Debug: parsing parameter 'x_version.res'
x_service.res is added twice, now from the same location.
To be continued...
On 22-4-2022 10:36, Marc Weustink via fpc-devel wrote:
OK,
I stashed my changes and compiled the previous version of the software
without problems. '.\lib\x86_64-win64\x_service.res' is not linked, so
somewhere my changes have triggered it.
To be continued...
Marc
On 22-4-2022 10:09, Marc Weustink via fpc-devel wrote:
On 22-4-2022 09:55, Marco van de Voort via fpc-devel wrote:
On 22-4-2022 09:12, Marc Weustink via fpc-devel wrote:
On a project I'm working on I needed to refactor some units. After
I finished, I got a linking error about a duplicate resource. Maybe
accidentally a stale one got linked, so I removed 2 occurrences.
And now the compiler complains it cannot find the resource.
Debug: parsing parameter '.\lib\x86_64-win64\x_service.res'
Debug: parsing parameter 'C:\Users\marc\x\x_service.res'
Well that is duplicate obviously.
That was the original problem, so I removed the versions from both
locations. In the output you see that the new version is build as
'C:\Users\marc\x\x_service.res'
the '.\lib\x86_64-win64\x_service.res' is not build, hence my
question, why is it tried to link that one ?
Maybe you did some manual cmdline build that left a .res in the
working dir , and your project has a stale {$R *.res} in the .dpr ?
I do have a {$R *.res}, iirc this should link x.res (which you can
see in the files passed)
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unable to find resource
OK, stash pop. You would think the problems should be the back... Yes
they are, only different:
Debug: parsing parameter 'x_service.res'
Debug: parsing parameter 'x_service.res'
Debug: parsing parameter 'x.res'
Debug: parsing parameter 'x_version.res'
x_service.res is added twice, now from the same location.
To be continued...
On 22-4-2022 10:36, Marc Weustink via fpc-devel wrote:
OK,
I stashed my changes and compiled the previous version of the software
without problems. '.\lib\x86_64-win64\x_service.res' is not linked, so
somewhere my changes have triggered it.
To be continued...
Marc
On 22-4-2022 10:09, Marc Weustink via fpc-devel wrote:
On 22-4-2022 09:55, Marco van de Voort via fpc-devel wrote:
On 22-4-2022 09:12, Marc Weustink via fpc-devel wrote:
On a project I'm working on I needed to refactor some units. After I
finished, I got a linking error about a duplicate resource. Maybe
accidentally a stale one got linked, so I removed 2 occurrences.
And now the compiler complains it cannot find the resource.
Debug: parsing parameter '.\lib\x86_64-win64\x_service.res'
Debug: parsing parameter 'C:\Users\marc\x\x_service.res'
Well that is duplicate obviously.
That was the original problem, so I removed the versions from both
locations. In the output you see that the new version is build as
'C:\Users\marc\x\x_service.res'
the '.\lib\x86_64-win64\x_service.res' is not build, hence my
question, why is it tried to link that one ?
Maybe you did some manual cmdline build that left a .res in the
working dir , and your project has a stale {$R *.res} in the .dpr ?
I do have a {$R *.res}, iirc this should link x.res (which you can see
in the files passed)
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unable to find resource
OK,
I stashed my changes and compiled the previous version of the software
without problems. '.\lib\x86_64-win64\x_service.res' is not linked, so
somewhere my changes have triggered it.
To be continued...
Marc
On 22-4-2022 10:09, Marc Weustink via fpc-devel wrote:
On 22-4-2022 09:55, Marco van de Voort via fpc-devel wrote:
On 22-4-2022 09:12, Marc Weustink via fpc-devel wrote:
On a project I'm working on I needed to refactor some units. After I
finished, I got a linking error about a duplicate resource. Maybe
accidentally a stale one got linked, so I removed 2 occurrences.
And now the compiler complains it cannot find the resource.
Debug: parsing parameter '.\lib\x86_64-win64\x_service.res'
Debug: parsing parameter 'C:\Users\marc\x\x_service.res'
Well that is duplicate obviously.
That was the original problem, so I removed the versions from both
locations. In the output you see that the new version is build as
'C:\Users\marc\x\x_service.res'
the '.\lib\x86_64-win64\x_service.res' is not build, hence my question,
why is it tried to link that one ?
Maybe you did some manual cmdline build that left a .res in the
working dir , and your project has a stale {$R *.res} in the .dpr ?
I do have a {$R *.res}, iirc this should link x.res (which you can see
in the files passed)
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unable to find resource
On 22-4-2022 09:55, Marco van de Voort via fpc-devel wrote:
On 22-4-2022 09:12, Marc Weustink via fpc-devel wrote:
On a project I'm working on I needed to refactor some units. After I
finished, I got a linking error about a duplicate resource. Maybe
accidentally a stale one got linked, so I removed 2 occurrences.
And now the compiler complains it cannot find the resource.
Debug: parsing parameter '.\lib\x86_64-win64\x_service.res'
Debug: parsing parameter 'C:\Users\marc\x\x_service.res'
Well that is duplicate obviously.
That was the original problem, so I removed the versions from both
locations. In the output you see that the new version is build as
'C:\Users\marc\x\x_service.res'
the '.\lib\x86_64-win64\x_service.res' is not build, hence my question,
why is it tried to link that one ?
Maybe you did some manual cmdline build that left a .res in the working
dir , and your project has a stale {$R *.res} in the .dpr ?
I do have a {$R *.res}, iirc this should link x.res (which you can see
in the files passed)
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Unable to find resource
Hi, On a project I'm working on I needed to refactor some units. After I finished, I got a linking error about a duplicate resource. Maybe accidentally a stale one got linked, so I removed 2 occurrences. And now the compiler complains it cannot find the resource. The (edited) output: (9022) Compiling resource C:\Users\marc\x\x_service.rc (9028) Calling resource compiler "C:\lazarus\fpc\3.2.2\bin\x86_64-win64\windres.exe" with "--preprocessor=C:\lazarus\fpc\3.2.2\bin\x86_64-win64\cpp.exe --include C:\lazarus\fpc\3.2.2\bin\x86_64-win64\ -O res -D FPC -o C:\Users\marc\x\x_service.res C:/Users/marc/x/x_service.rc" as command line ... Debug: parsing command line parameters Debug: parsing parameter '-o' Debug: parsing parameter '-a' Debug: parsing parameter '-of' Debug: parsing parameter '-v' Debug: parsing parameter '@C:\Users\marc\x\x.reslst' Debug: parsing parameter 'C:\lazarus\lcl\units\x86_64-win64\cursors.res' Debug: parsing parameter 'C:\lazarus\lcl\units\x86_64-win64\btn_icons.res' Debug: parsing parameter 'C:\lazarus\lcl\units\x86_64-win64\dialog_icons.res' Debug: parsing parameter '.\lib\x86_64-win64\x_service.res' Debug: parsing parameter 'C:\Users\marc\x\x_service.res' Debug: parsing parameter 'x.res' Debug: parsing parameter 'x_version.res' Debug: target set to x86_64 - coff Debug: finished parsing command line parameters ... Debug: Trying to open file .\lib\x86_64-win64\x_service.res... Error: Can't open file '.\lib\x86_64-win64\x_service.res' C:\Users\marc\x\x.dpr(45,1) Error: (9029) Error while compiling resources (9015) Linking C:\Users\marc\x\x.exe C:\Users\marc\x\x.dpr(45,1) Fatal: (10026) There were 1 errors compiling module, stopping Fatal: (1018) Compilation aborted As you see, x_service.res is build in C:\Users\marc\x. So my question is where does the line '.\lib\x86_64-win64\x_service.res' come from (and I wonder how did it compile the past years) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus server back online
On 30-12-2021 23:42, Bart via fpc-devel wrote: Hi Marc, It took a bit longer than expected, but I'm happy to inform you that the Lazarus services are back online. For those interested in why it took longer, I'll explain at the end of the message. Are you aware that there is a problem with the forum? It will change any single quote inside a [code=pascal] block into a HTML-entity: It does that for all highlighters (including [code=Text]), but not for plain [code][/code] blocks. See: https://forum.lazarus.freepascal.org/index.php/topic,57672.0.html We are aware if this. On dec 21 I applied the latest security update on the forum, on dec 27 the server itself got upgraded. So its either the forum update, or a newer version of php causing this. If there is someone who noticed this between dec 21 and dec 27, we know where to look. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Lazarus server back online
Hi all, It took a bit longer than expected, but I'm happy to inform you that the Lazarus services are back online. For those interested in why it took longer, I'll explain at the end of the message. Marc On 24-12-2021 08:30, Marc Weustink wrote: Hi, On Monday 27 December 9.00 CET (8.00 GMT) the Lazarus server will be down for maintenance. This affects the following services: * Lazarus website * Lazarus mailinglists * Lazarus online package manager * Lazarus and FreePascal forum Thanks, Marc The story The server was running Ubuntu 16 LTR, so it's support ended on April this year. An attempt at that time failed since Ubuntu decided to switch to systemd-resolve which resulted in a server not even able to resolve its own name, let alone other hosts. When Googling about it, you learn that it doesn't work, it's a half backed solution, not a full DNS etc. At that time it became clear that I wouldn't be able to solve that in an evening. Luckily I could try this on a cloned server (we had to rent for another issue) so I parked the upgrade till I could spend a full day. Yesterday I found the "correct" solution to this which appeared to work. So I continued to upgrade to Ubuntu 18 and finally to Ubuntu 20 LTR. Everything seemed to work until I enabled the mailserver. It couldn't resolve any mailserver for a given domain. What the f.. 'host -t mx freepascal.org' resolves, why can't postfix resolve it. Again after some Googling, postfix needs a /etc/resolf.conf. However one step of the DNS solution was to remove the /etc/resolf.conf symlink, so I tried to restore the original link to some systemd-resolve generated one. This one pointed to their internal resolver. Still no luck since I hadn't configured systemd-resolve which DNS itself should use. After doing so, the generated resolf.conf became empty ? After more Googling I found that systemd-resolve generates another conf where you also can link to. No clue why there have to exist another version, but this one works. So this part of the server upgrade got finished around 14:00. The Lazarus mailing list and main website were back online. Another wish we had was to change the database backend of the forum. It appeared over time that when doing a search on the database, mysql blocks updates, so browsing the forum becomes unresponsive. The current version of SMF supports different databases so we decided to go for PostgreSQL (I'm using them at work for years now). Migrating MySql data to PostgreSQL seemed easy with pgLoader. The documentation about is was initially a bit sparse, but I could start a conversion with some commandline options. Unfortunately it got killed after 15 mins of import. After two more attempts it became clear, out of memory :( Reducing the memory requirements was a build time option so I didn't want to go that way. Another solution was to convert only a few tables at a time. That required however a configuration file which has more options than the command line. Most of the examples I found on the web failed, since they lack the semi colon at the end if the configuration. So the parser barfs with some abracadabra, initially not giving a clue. Fast forward, on 18:00 all but the messages table were converted. On 22:00 the messages table was converted using 9 parts. Then I realized that I didn't have a php-pgsql driver installed. After doing so, I discovered that the Lazarus main site also showed the forum maintenance message ??? Those sites are running on two different virtual servers. How can the contents of an index.php of one site have influence on the index.php of another site. What did go wrong when I installed the driver ??? After an hour investigating I decided to enable the forum first and investigate the issue later. Poof the forum results in a bunch of errors. What we didn't think of when switching backend, is that we use SMF (which is PostgreSQL capable) and TinyPortal (TP) to have the menus at the sides. And TP is full of MySQL only statements. Luckily there is someone who created all those missing functions for SMF and I created them on the database. After adjusting some TP php files (PostgreSQL requires a true boolean and not some integer <> 0), the forum started without errors. But it didn't show any boards. So there is still something wrong under the hood. Meanwhile it was 24:00 and I decided to continue using MySQL and called it a day. This morning I reverted my TP changes and put the MySQL database back online. To be continued... Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Lazarus server maintenance
Hi, On Monday 27 December 9.00 CET (8.00 GMT) the Lazarus server will be down for maintenance. This affects the following services: * Lazarus website * Lazarus mailinglists * Lazarus online package manager * Lazarus and FreePascal forum Thanks, Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] tkLString vs tkAString
On 30-11-2021 13:37, Michael Van Canneyt via fpc-devel wrote: On Tue, 30 Nov 2021, Marc Weustink via fpc-devel wrote: Hi, I ran into an issue with a piece of ported Delphi (6) code and RTTI. Part of the Delphi code was based on strings with a RTTI type tkLString where in FPC the type appeared to be tkAString. Fixing this was easy, but it made me wonder what the difference is between them. From the documentation: Source position: rttih.inc line 22 type TTypeKind = ( ... tkLString, Longstring property. tkAString, Ansistring property. So there is apparently a LongString type and an AnsiString type. However if you search (google) the documentation on LongString, you only find references to AnsiString. My question: What is the difference (if any) ? This dates from long ago... Longstring was an idea for a shortstring/ansistring kind of string - unlimited length but no reference counting. But it was never fully implemented. Ah, that explains. So technically the delphi tkLString is the fpc tkAString and the fpc tkLString does not exist. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] tkLString vs tkAString
Hi, I ran into an issue with a piece of ported Delphi (6) code and RTTI. Part of the Delphi code was based on strings with a RTTI type tkLString where in FPC the type appeared to be tkAString. Fixing this was easy, but it made me wonder what the difference is between them. From the documentation: Source position: rttih.inc line 22 type TTypeKind = ( ... tkLString, Longstring property. tkAString, Ansistring property. So there is apparently a LongString type and an AnsiString type. However if you search (google) the documentation on LongString, you only find references to AnsiString. My question: What is the difference (if any) ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Promote specific warning into error
On 24-9-2021 14:41, Michael Van Canneyt via fpc-devel wrote:
On Fri, 24 Sep 2021, Marc Weustink via fpc-devel wrote:
On 24-9-2021 14:24, Marc Weustink via fpc-devel wrote:
Hi,
Is there a way to promote a specific warning(4056) into an error ?
from the commandline I mean. I've found {$warn 4056 error} but I don't
want to put this in all sources
The command-line only allows to set this for all warnings/hints/notes.
-Se Error options. is a combination of the following:
: Compiler halts after the errors (default is 1)
h : Compiler also halts after hints
n : Compiler also halts after notes
w : Compiler also halts after warnings
I didn't see a way to do this for specific message numbers.
I think at this point your best bet is to create a small include file
that is included in all files ?
what I've done for the current project (need to check more) is -Sew and
several -vm for all warnings I'm not interested in (like deprecated,
uninitialized variables passed to SetLength() etc)
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Promote specific warning into error
On 24-9-2021 14:24, Marc Weustink via fpc-devel wrote:
Hi,
Is there a way to promote a specific warning(4056) into an error ?
from the commandline I mean. I've found {$warn 4056 error} but I don't
want to put this in all sources
Thanks Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Promote specific warning into error
Hi, Is there a way to promote a specific warning(4056) into an error ? Thanks Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM/AARCH64 work
On 6-8-2020 11:16, Sven Barth via fpc-devel wrote: Marc Weustink via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Do., 6. Aug. 2020, 09:13: ... Do you mind sharing where you found a working network driver ? I've read endless stories of instabilities with a few possible links to solutions of a few months old. From all that I got the impression that building myself would be the "quickest" way to get them. When I had setup the machine I had given up on that and simply used an Asix based USB-LAN Adapter and passed that through to the VM. Didn't try that one yet. I should have one somewhere. Though I had recently read, that now support for the network driver should be working. You should be able to get the latest drivers from the Redhat site, I think. I'll have to check that again. Yes, it a bit confusing. If you read the fedora site you may get the impression it supports only x86 or amd64. Today I downloaded the iso and the arm64 driver folders are present. I need to check if they work Thanks Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM/AARCH64 work
On 5-8-2020 23:44, Sven Barth via fpc-devel wrote: Am 05.08.2020 um 18:33 schrieb J. Gareth Moreton: P.S. While I haven't been asked to improve aarch64-linux specifically, if I'm understanding things correctly, there should be very few differences with the actual target platform in regards to calling conventions, for example. Correct, the most is equal between the platform. There are only subtle differences like this one for AArch64-Win64: https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/aarch64/ncpuset.pas?r1=44949=44948=44949 If you want, you could also install a Windows 10 On ARM64 inside a KVM on your Raspberry (with the correct guest drivers you'll get near native performance) like I have done and test around on that as well ;) Maybe you'll find the necessary time earlier than me to fix the remaining problems of the compiler not being able to cycle itself there... :/ Do you mind sharing where you found a working network driver ? I've read endless stories of instabilities with a few possible links to solutions of a few months old. From all that I got the impression that building myself would be the "quickest" way to get them. Thanks, Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] r45217 breaks Lazarus compile
On 5-5-2020 11:08, Sven Barth via fpc-devel wrote: Marc Weustink via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Di., 5. Mai 2020, 09:27: Sven Barth via fpc-devel wrote: > > TThread.NameThreadForDebugging is implemented for Windows, Linux and > Android since the weekend. Just curious, why is NameThreadForDebugging used instead of simply TThread.Name ? ForDebugging is just one of the purposes, and TThread.NameThread is double, since it is a property of a thread, what else would you give a name. As Marco said, Delphi compatibility. Sigh reading the Delphi docs now and I understand the name Also debugging *is* the *only* purpose of this. Not to mention that this is a write only functionality. There is no way to retrieve the thread's name and it's also not stored anywhere on the Pascal side. Not entirely true on windows. There are 2 ways to name a thread. The first is indeed for debugging only since it is passed to the debugger though some predefined exception. The second is recently introduced by the Get/SetThreadDescription functions. The Get function can be used by other (non debugger) applications. Some applications already set the description this way. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] r45217 breaks Lazarus compile
Sven Barth via fpc-devel wrote: TThread.NameThreadForDebugging is implemented for Windows, Linux and Android since the weekend. Just curious, why is NameThreadForDebugging used instead of simply TThread.Name ? ForDebugging is just one of the purposes, and TThread.NameThread is double, since it is a property of a thread, what else would you give a name. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] The TWMNCRButtonXXX definitios are missing
Just porting some software and foud that the Right versions of the TWMNC[L|M|R]ButtonXXX definitions are missing in messages.inc TWMNCRButtonDblClk = TWMNCHitMessage; TWMNCRButtonDown= TWMNCHitMessage; TWMNCRButtonUp = TWMNCHitMessage; Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Lazarus] Attn Michael: Issue #0036788: Bad SSL certicificate
Michael Van Canneyt via lazarus wrote: On Wed, 11 Mar 2020, Bart via fpc-devel wrote: Hi Michael, You resolved https://bugs.freepascal.org/view.php?id=36788 as unable to reproduce. However, I have exactly the same problem here: https://www.lazarus.freepascal.org/ gives me the Bad SSL certificate and if I ignore I see the "Apache2 Ubuntu Default Page". It does not redirect me to https://www.freepascal.org/ If I click on the title of this bugreport (My View page), then this immediately happens. I can only repeat: I cannot reproduce this given the instructions. Concerning bugs: I don't see a link to https://www.lazarus.freepascal.org/ anywhere. However, If I enter the URL directly in the addres bar, then I also can reproduce it. But this problem is beyond my control, I don't run the lazarus webserver. I have forwarded this mail to the lazarus mailing list, the lazarus admins must somehow solve this. It should not redirect to www.freepascal.org. www.lazarus.freepascal.org is the old url for the lazarus site, so it ends up ate the lazarus server. There were 2 errors. First only http requests were redirected and not the the https requests. Therefore you got the default page. Second www.lazarus.freepascal.org was not part of the lazarus certificate, so you got the bad certificate error. I've fixed both issues Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Capturing addresses
Jonas Maebe wrote: Hi, Does anyone know what the accepted/excepted behaviour is regarding the capture of addresses of var/out/const-by-address/constref parameters? For example: var g: longint; p: plongint; procedure test(var l: longint); begin p:=@l; end; begin test(g); end. After test() executes, p now contains the address of g (the '@' operator does not return the address of g's address on the stack; it returns the actual address of g). This means that g's address has been captured by test(). This can obviously lead to wrong/dangerous situations, e.g. if g was not a global variable, but a local variable of another procedure. That said, it is a legal expression. I would like to teach the compiler to be able to assume that addresses of variables are not captured merely because they are passed by reference. There will also be a switch to toggle this assumption, because fortunately it the behaviour is completely defined by the callee side (so if you know that a unit does this, compiling that unit appropriately is sufficient to ensure it will always work correctly). The question is: should the compiler by default assume that such addresses are not captured, or that they are captured? Does anyone know if a lot of code exists that does this? I've a lot of (interfacing) code where the address of a var is used, where the resulting pointer used locally. I don't think I've code which stores that pointer somewhere outside the procedure. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Undesirable attachment to issue #29332
Bart wrote: On Fri, Jul 12, 2019 at 12:34 PM J. Gareth Moreton wrote: I can't quite go that far unfortunately. Being a developer gives me the right to delete attachments and modify posts, but not to tamper with people's profiles. One of the managers maybe can look into it. Account is removed Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg invocation for two versions (linux)
Gennadiy Poryev wrote: thank you, but my question was more about where to put fpc.cfg so that both versions can use it properly, or, if that is not possible, where to stuff different fpc.cfg's for the same purpose? and what would be the basepath in either case? execute ppx64 -vut the last lines of the output list the patch searched for fpc.cfg In my case [0.004] Configfile search: /home/marc/.fpc.cfg [0.004] Configfile search: /home/marc/etc/fpc.cfg [0.004] Configfile search: /etc/fpc.cfg I also vaguely recall that the dir of the compiler is searched too, but isn't listed here (it might be a windows only thing or something from the past) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Paul Michell wrote: I'm currently trying to build 2.7.1 from SVN on the latest Raspbian (2014-09-09). I've previously built this with either 2.6.0 from the repository, or with Thaddy de Koning's build from March 2014. Currently, neither of these will build 2.7.1 on a Raspberry Pi. So I have also tried with the generic arm-linux release archive (fpc-2.6.4.arm-linux.tar). This installed without error and I can compile projects on the Pi with it. However, when trying to build 2.7.1 (make all) it creates a compiler binary, but fails whilst compiling fpmake. This looks similar to the bug 0024056 which is flagged as resolved. The solution suggested there is to install build-essential, but this is installed by default on Raspbian, so I think there must be something else wrong? Could anyone suggest what I could try now? last month I was able to cycle a linux/arm compiler from r28726 using linux/x86 in the compiler dir: make cycle OS_TARGET=linux CPU_TARGET=arm CROSSOPT=-CpARMV6 -CfVFPV2 -OoFASTMATH FPC=~/bin/ppc386_271 (ppc386_271 is my cycled trunk compiler, build with 2.6) I used this compiler to compile fpc (r28726) on PI using in the compiler dir.: make cycle PP=~/bin/ppcarmhf OPT=-dFPC_ARMHF (ppcarmhf is the compiler copied+renamed from the previous step) with the resulting compiler I could compile all of r28726 (make install PREFIX=~ in compiler and rtl dir) make all OVERRIDEVERSIONCHECK=1 Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Build packages 2.6.4 on arm/linux failed
Hi, I was playing with GNUroot/debian on my android pad and installed fpc 2.6.0 since 2.6.4 was not available. After that I tried to build 2.6.4 from svn. However make all stopped when building fastcgi: /usr/bin/make -C fastcgi all make[1]: Entering directory `/home/fpc-2.6.4/packages/fastcgi' /usr/bin/ppcarm fpmake.pp -n -Fu../../rtl/units/arm-linux -Fu../../packages/hash/units/arm-linux -Fu../../packages/paszlib/units/arm-linux -Fu../../packages/fcl-process/units/arm-linux -Fu../../packages/fpmkunit/units/arm-linux /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /home/fpc-2.6.4/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x88): undefined reference to `_fini' /home/fpc-2.6.4/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x90): undefined reference to `_init' fpmake.pp(30,38) Error: Error while linking fpmake.pp(30,38) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[1]: *** [fpmake] Error 1 make[1]: Leaving directory `/home/fpc-2.6.4/packages/fastcgi' make: *** [fastcgi_all] Error 2 uname -a : Linux localhost 3.1.10-gb1a9af5 #1 SMP PREEMPT Thu Aug 1 16:15:28 CST 2013 armv7l GNU/Linux Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Build packages 2.6.4 on arm/linux failed
The funny thing is that when I ignore fastcgi (and 1 or 2 other packages) every thing compiles fine. Even compiling and running lazarus. So i wondered wat is so special with fastcgi. I‘ll try OPT Sent from my ASUS Pad Florian Klaempfl flor...@freepascal.org wrote: Am 28.03.2014 21:36, schrieb Marc Weustink: Hi, I was playing with GNUroot/debian on my android pad and installed fpc 2.6.0 since 2.6.4 was not available. After that I tried to build 2.6.4 from svn. However make all stopped when building fastcgi: /usr/bin/make -C fastcgi all make[1]: Entering directory `/home/fpc-2.6.4/packages/fastcgi' /usr/bin/ppcarm fpmake.pp -n -Fu../../rtl/units/arm-linux -Fu../../packages/hash/units/arm-linux -Fu../../packages/paszlib/units/arm-linux -Fu../../packages/fcl-process/units/arm-linux -Fu../../packages/fpmkunit/units/arm-linux /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /home/fpc-2.6.4/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x88): undefined reference to `_fini' /home/fpc-2.6.4/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x90): undefined reference to `_init' fpmake.pp(30,38) Error: Error while linking fpmake.pp(30,38) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[1]: *** [fpmake] Error 1 make[1]: Leaving directory `/home/fpc-2.6.4/packages/fastcgi' make: *** [fastcgi_all] Error 2 2.6.x does not warn if it misses init files: debian recently changed the locations of the init files. So fixes probably misses r22004, r22416 and r23892. Please try to compiled with OPT=-Fl/usr/lib/arm-linux-gnueabi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Scalar value is accepted as an argument for an open array parameter
On 8-6-2012 8:18, Alexander Klenin wrote: The following code compiles both with : procedure F(const A: array of ShortInt); begin end; begin F(1); end. I think this is a bug in FPC, but if not -- it should be documented here: http://freepascal.org/docs-html/ref/refsu59.html#x157-16700014.4.5 I am willing to file an issue one way or another. Unfortunately Delphi (6) accepts this too. It took me some time at work to figure out why some code suddenly behaved weird. (I changed a integer argument to array of integer and assumed the compiler would help me to find the places where I still passed a single integer) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [Lazarus] How to iterate through a TAvgLvlTree
Felipe Monteiro de Carvalho wrote: Can I add a routine to access the AvgLvlTree as an array? To make it a better substitute to TFPList in objects which offer an indirect interface to the internal list, such as TLazAccessibleObject. My idea is defining: Index zero = Tree.FindLowest Indez Count-1= Tree.FindHighest On each access store the last accessed node and if the next call wants a node index=oldindex+1 or -1 then just use: Tree.FindSuccessor(Node) Tree.FindPrecessor(Node) Because almost always I use the array access only to iterate in a loop. Lazarus has a TMap implementations where a AvgLvlTree is used for looking up items and has a own AvgLvlTreeItem which is a double linked list so items can be iterated. Tree.FindSuccessor(Node)/Tree.FindPrecessor(Node) can cause a lot of nodes traveled. Marc Non-ordened access ofcourse would be slow because it would require a loop till the index is found. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb and stopping at the begin line
Martin wrote: Having just reported http://bugs.freepascal.org/view.php?id=19466 I started wondering (to late, should have done before the report) and googled. It appears that gdb has a feature to skip function prologue and epilogue. However I could not find any info on what info gdb uses to know what is the prologue. So it is possible that something tells gdb that the code on which no stop occurs is the proluge. :) Thats why we in lazarus query the address of a procedure first and set the breakpoint on that address. This way you always get a break on the start of the procedure (otherwise it depends on debug symbols beeing present or not (for exported functions)) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwar2 changed?
Joost van der Sluis wrote: On Wed, 2011-01-12 at 23:52 +, Martin wrote: Has dwarf 2 changed ? TCmdLineDebugger.SendCmdLn -data-evaluate-expression ^^shortstring(^POINTER($eax)^+12)^^ TCmdLineDebugger.ReadLn ^done,value=#0repeats 20 times TCmdLineDebugger.ReadLn (gdb) You do realize that this is an hack? (I partly wrote it) It looks much like I first wrote it :) Anyway, without rtl debug info this is the only way to retrieve the classname of the exception object. It could also be that the location of the exception-name has been changed by something. This hack doesn't use any debug-information. Only the definitions of a shortstring and pointer. I don't think that the exception name location is changed, it would mean that the VMT layout has changed. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
kingbiz...@gmail.com wrote: I come here humbly to ask for a new implementation, the IIF ?:, the IIF is a shortcut that make the coding a little faster, it works by returning a true or a false part of a condition, a more detailed information can be found there: http://en.wikipedia.org/wiki/%3F: *PHP and C++ implementation:* Value *=* condition *?* value if true *:* value if false; *Pascal implementation:* Value := IfThen(Condition, TruePart, FalsePart); *function IfThen(Condition: Boolean; IfTrue, IfFalse: X): X; overload; begin if Condition then Result := IfTrue else Result := IfFalse; end; * Note that there is a tiny little difference between those two. the ?: operator evaluates either the TruePart or FalsePart while IfThen will evaluate both parts first. The following will succeed var p: PInteger; i: Integer; begin p := nil; i := p nil ? p^ : 0; end; The following will fail var p: PInteger; i: Integer; begin p := nil; i := IfThen(p nil, p^ , 0); end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] parentfp changed to $parentfp
On 8-12-2010 22:53, Jonas Maebe wrote: On 08 Dec 2010, at 22:32, Martin wrote: It seems that the name of parentfp (used by neted procedures) depends on the dwarf version? -gs and -gw = parentfp -gw3 = $parentfp Is there are reason, does the $ have a meaning? It's a bug in -gw3. $ is an internal compiler convention for non-programmer visible symbol. isn't parentfp a non-programmer visible symbol ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interface scope incompatibility with Delphi
Dimitri Smits wrote: ok, answering my own mail after a small test below - Dimitri Smitssmi...@telenet.be schreef: what I DON'T do is use it like in your example, Graeme. I always assign the result to a local variable, which goes out of scope in an implicit finally block at method-exit. Haven't tried if this does (not) work in fpc though. tested with following program and 2.4.0 (can someone verify on trunk) it gives somewhat the desired result, but not completely. This IS a bug, I believe. the expected behaviour is the next output: Entering: DoSomething 1 Entering: DoSomething 2 random message 1 random message 2 Exiting: DoSomething 2 Exiting: DoSomething 1 but I got this output: Entering: DoSomething 1 Entering: DoSomething 2 random message 1 random message 2 Exiting: DoSomething 1 Exiting: DoSomething 2 it seems that the stackvariables are NOT unloaded in the correct order (ie: reverse order of declaration). It shouldn't matter in what order you fill them, but in the order they are declared. (like good practice in constructor vs destructor, but then in stack variables setup/cleanup) IMO not. Why should the order of declaration matter on how your code works ? It's just an declaration. If your code requires a specific unload order, code it that way by setting the variables to nil in the order you need. That is the only way you can make sure that interfaces will be unloaded in the correct order. In Delphi I had a issue when working with DirectSound interfaces. The order how interfaces are unloaded was important, the Delphi default way lead to a crash. Explicitly nilling the variables in the correct order solved this. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: [Lazarusdev] gdb driving me nuts = it's starting a 2nd thread for no apparent reason....
:)
On windows I create a remote thread to be able to pause execution to
enable breakpoints and such while the program is running.
See initialisation part of the gdbmi debugger. There I use a few options
to pause execution. On the NT platform the remote thread solution is the
most reliable.
Marc
On 8-11-2010 23:59, Martin wrote:
Ok, anyone with an idea..
Attached is a simple program (appologies for the many commented lines,
but all logs refer to the lines as in this source, and I didn't want to
recreate the log yet another time)
Tested with various versions of gdb dwarf debug info (and IIRc (it's
been a lot of trying) also stabs). Mainly used todays triunk of fpc, but
the same with 2.4.0 (again IIRC)
In the log:
- lines with written to the debugger
- lines with read from the debugger
debugger started with this options:
gdb -silent -i mi -nx
the app pasically is
Program Foo;
procedure Test; begin writeln(); end;
begin
Test;
Test;
Test;
end;
- the output of writeln has no significance, and can even be commented away
- breakpoint is set on the first call to Test
then hit F8 (step-over) twice
- the first F8 stops (but for the wrong reason (should be
*stopped,reason=end-stepping-range...
- the 2nd F8 cause a sigill
they apparently stop half into an instruction, which may be part of the
issue..
The biggest riddle is, why gdb says it's starting a 2nd thread?
(btw using gdb directly, same options, but piccking only the most
relevant commands from the log = not reproducible)
Below is the communication of the first F8 step-over, before that the
breakpoint was hit, and some info queried (stack, etc).
All that is send is a single -exec-next, yet a 2nd thread seems to get
started.
Strange too, the address at which it does hit the sig-trap...
TCmdLineDebugger.SendCmdLn -exec-next
TCmdLineDebugger.ReadLn ^running
TCmdLineDebugger.ReadLn *running,thread-id=1
TCmdLineDebugger.ReadLn (gdb)
TCmdLineDebugger.ReadLn =thread-created,id=2,group-id=1032
[Debugger] Notify output: =thread-created,id=2,group-id=1032
TCmdLineDebugger.ReadLn ~[New Thread 1032.0x1774]\n
[Debugger] Console output: ~[New Thread 1032.0x1774]\n
TCmdLineDebugger.ReadLn *running,thread-id=all
[DBGTGT] *
[DBGTGT] running,thread-id=all
TCmdLineDebugger.ReadLn ~[Switching to Thread 1032.0x1774]\n
[Debugger] Console output: ~[Switching to Thread 1032.0x1774]\n
TCmdLineDebugger.ReadLn
*stopped,reason=signal-received,signal-name=SIGTRAP,signal-meaning=Trace/breakpoint
trap,frame={addr=0x
771d8b2f,func=??,args=[]},thread-id=2,stopped-threads=all
TCmdLineDebugger.ReadLn =thread-selected,id=2
[Debugger] Notify output: =thread-selected,id=2
TCmdLineDebugger.ReadLn (gdb)
___
Lazarusdev mailing list
lazarus...@freepascal.org
http://idefix.wisa.be/mailman/listinfo/lazarusdev
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Graeme Geldenhuys wrote: Op 2010-10-19 10:51, Jonas Maebe het geskryf: You still have not said a single time what the actual problem is that you are having. I believe I have, but I can't remember all the errors, and I have no time to search the mail archive Just tried to compile that branch again under 64-bit linux. - Free Pascal Compiler version 2.4.3 [2010/08/02] for x86_64 ^ ^^ What if you use a released compiler as starting compiler ? (other versions are not supported) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String literals
Hans-Peter Diettrich wrote: Can we make string literals accepted with embedded whitespace between ordinal characters? Currently this is not accepted: const x: string = #1 #2 #3; and must be written as const x: string = #1#2#3; //not very readable you can use const x: string = #1 + #2 + #3; marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Conditional Breakpoints using FPC and GDB
Graeme Geldenhuys wrote: PS: Anybody know how the Duby project (Object Pascal based Debugger) is progressing, and if support for it could be added to Lazarus or MSEide? creating a debugger is not that difficult, evaluating (pascal) expressions is. And even then evaluating properties is impossible. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Conditional Breakpoints using FPC and GDB
Martin wrote: On 13/08/2010 10:14, Graeme Geldenhuys wrote: Hi, Lazarus has a dialog for conditional breakpoints, but it doesn't work. I tried everything. * set a breakpoint where condition is: TypeDecl.Name = 'TRGBTriple' Seems that gdb expects double quotes FName = abc but then it wants malloc to be defined, and complains about that. It does support string index, and bool expression: FName[0]='a' and FName[1]='b' Yeah, and this is exactly the reason why I stopped on expressions. There is no way to distinguish beween a pchar and a string string FName[1] (where FName:PChar) has a complete different meaning than FName[1] (where Fname:String) That works (in the watches windows) it works, but does it show the correct value ? [Note in Lazarus the expression isn't properly quoted before being send to gdb. So (since it has spaces) you need to double quote the entire expression, before sending it to gdb] It is quoted iirc (or did I forget it somewhere ?). Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger problem
Hans-Peter Diettrich wrote: I've installed Lazarus 0.9.28 (with FPC 2.2.4) 64 bit on Win7/64. Here gdb works. Then I built and installed FPC 2.5 (trunk) for further use. The compiled apps (64 bit) run fine, as long as I disable debugging. With debugging enabled the application hangs on start, i.e. even the console does not appear for a console app (hello world...). What if you run a gdb from the command line ? Does the debuggeroutput window show something ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Enhanced replacement for assignment operators
Alexander Klenin wrote: Code bloat/duplication is much more serious. It is usually not just SomeReallyLongVariableNameY, but something like: SomeFunctionReturningObject(param1, param2).PointArrayField[i] += FunctionReturningPointOffset(param); Try rewriting that without +=. Again, we are back at lazy typing. Somehow typing the realy long valiable name is not a problem, but declaring an extra variable is. (and with lazarus even that isn't needed) What is wrong with : MyObj := SomeFunctionReturningObject(param1, param2); MyObj.PointArrayField[i] := MyObj.PointArrayField[i] + FunctionReturningPointOffset(param) Why are you still using pascal ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger problem
Hans-Peter Diettrich wrote: Marc Weustink schrieb: What if you run a gdb from the command line ? I'm somewhat confused. There seem to exist two gdb.exe on my system, with slightly different version numbers, but I can locate only one. Typically Windows - protect the system from the user :-( After some tries: found the other (32 bit?) gdb, and renamed it. Also removed the path to FPC 2.4.0 (32 bit). make sure you use only mingw based gdb for lazarus and not a cygwin based (cygwin has a console which doesn't use stdin/out) Does the debuggeroutput window show something ? Now gdb allows to run the test program, where the other gdb (32 bit) couldn't identify the file format (64 bit). Nonetheless when I run the same program from the Lazarus IDE, no console window opens :-( You cannot debug console apps in lazarus. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger problem
Hans-Peter Diettrich wrote: Jonas Maebe schrieb: See comment 0035256 at http://bugs.freepascal.org/view.php?id=15692 for how to fix it. This was not the problem, but reading helped - I had to enable creation of gdb debug info, to make the debugger work with Lazarus. I wonder why gdb doesn't report any errors, when running it with the same exe without debug information created? Or is the debug info essential for Lazarus? AFAIK it doesn't ruiquire debuginfo to be present, however without info you only can run your app. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Enhanced replacement for assignment operators
Hans-Peter Diettrich wrote: Marc Weustink schrieb: What is wrong with : MyObj.PointArrayField[i] := MyObj.PointArrayField[i] + FunctionReturningPointOffset(param) The need for duplicating a long expression, with chances for typos :-( Choose shorter expressions and/or use ctrl+space Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OO rewrite - first round finished
Hans-Peter Diettrich wrote: Jonas Maebe schrieb: In whichever way you are used to debug: with a debugger, with writeln's, ... The compiler is no different than any other program in that respect. While I can use Lazarus to debug the compilation of a single source file, no such feature exists for Makefiles. I even don't know how to translate an error address to a source code position. In Delphi I had a jump to address... menu item... Use make all as Execute before step in Lazarus, check all 3 checks and uncheck the compiler Call on checks in the last page of the project options (Compiler options - compiler). Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (Re)compiling FPC or is there something like fpc.bpg?
Adem wrote: On 2010-07-27 1:10 PM, Joost van der Sluis wrote: I don't know what you want, Wel... it all started here [ http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg17986.html ]. In short, I was trying to test/benchmark a FPC/Lazarus generated exe against one with Delphi, but I kept having to uninstall 32-bit FPC/Lazarus when I needed to produce a 64-bit FPC/Lazarus exe. IOW, both versions wouldn't coexist under the same OS (Windows 7). If you don't use the installer but build lazarus yourself from the sources, both 32 an 64 bit version of lazarus can run side by side. No problems with that. (ok, you need to rename lazarus.exe to lazarus32.exe / lazarus64.exe) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] is that intended? private type section in classes versus visibility
Graeme Geldenhuys wrote: On 26 July 2010 22:57, Florian Klämpfl flor...@freepascal.org wrote: What makes you think so? Which compiler patches did we reject so far? Lets take some examples in the last few months alone. I had code for the RTL. Iterators come to mind - denied. Then there was a patch for a more cross-platform help type definition - denied. Then there was the discussion about adding Observer support to all container classes in the RTL. Refused again, but at least Michael saw the light and said he will add it to the RTL regardless (and time permitting). I can list a few more... and then some people still wonder why I rant about FPC sometimes. Florian asked about rejected *compiler* patches, not RTL. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need advice for refactoring
Graeme Geldenhuys wrote: On 17 July 2010 13:51, Marco van de Voort wrote: Unless other systems really take into account the complete history of both divergating branches in the merge, and not simply patch/merge, I doubt VCS matters at all Git's merge algorithm does this and is a lot more intelligent that SubVersion, and thus much less prone to conflicts. Git can even merge multiple branches at the same time into a single branch (known as octopus merge). Just a bit of useless information. I don't doubt the ability to merge, but will it result in usable/meaningfull code too ? Marc (couldn't resist) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SVN, Mac OSX, and Samba
Andrew Brunner wrote: The network I have is a file server running Ubuntu x64 with samba sharing. All clients (running Ubuntu,Windows,OSX) connect to the file share and mount it locally. The Windows and Linux boxes mount, checkout/commit/update, and unmount without problems. The Apple OSX can mount, checkout/update but cannot commit to anything. Since my fileserver exports the shares to both nfs and samba, I use nfs for linux/osx, and samba for windows. I faintly remember that I might have had some issues with samba on OSX, so I quit that exercise (since nfs is faster anyway). Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SVN, Mac OSX, and Samba
Andrew Brunner wrote: Hi there, Anyone using FPC/Lazarus to develop on a MAC OSX and having success with SVN over a LAN with Samba? I'm having a hard time getting anything to commit on my OSX box and wanted to see if someone here has solved the file locking problem that OSX 10.6 presents. Never tried Samba on OSX. I'm using nfs without any problem. A lng time ago I used Samba on linux, but that screwed up the file permissions since there was no extended atribute support. Since then I switched to nfs. Maybe an option ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Customer Done procedure for dynamic arrays
Andrew Brunner wrote: I use dynamic arrays for data structures and sometimes types. Under linux I have had no problems with transversing the list of data and calling Done on all types then calling finalize on the list itself. Under windows I just executed the same code that worked under linux but crashed under windows. TInt64Array=Array of Int64; procedure Done(var List:TInt64Array); begin Finalize(List); end; procedure Empty(var List:TInt64Array); begin SetLength(List,0); end; In the above case the two procedures worked under linux. Under Windows Done crashes. Is this a bug that needs to be reported or is the memory manager performing different under Linux than under Windows. This is a basic example. Some of my data structures involve strings and sub-arrays to other data structures or pointers thereto. To fix the problem I just use Empty instead of Done but I am looking to find out why can use Finalize on Linux but not on Windows? Why do you want to finalize it ? This is automatically done by fpc when you set the length to 0 (or when the array goes out of scope) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fcl-image: gray-alpha png issue
Hi, When fixing lazarus issue #13266 I noticed that in case of reading 8 bit gray-alpha images, the order of the gray and alpha channel are swapped. The attached patch fixes this. Marc Index: packages/fcl-image/src/fpreadpng.pp === --- packages/fcl-image/src/fpreadpng.pp (revision 14491) +++ packages/fcl-image/src/fpreadpng.pp (working copy) @@ -519,14 +519,14 @@ function TFPReaderPNG.ColorGrayAlpha8 (CD:TColorData) : TFPColor; var c : word; begin - c := CD and $FF00; - c := c + (c shr 8); + c := CD and $FF; + c := c + (c shl 8); with result do begin red := c; green := c; blue := c; -c := CD and $FF; +c := (CD shr 8) and $FF; alpha := c + (c shl 8); end; end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fcl-image: gray-alpha png issue
Marc Weustink wrote: Hi, When fixing lazarus issue #13266 I noticed that in case of reading 8 bit gray-alpha images, the order of the gray and alpha channel are swapped. The attached patch fixes this. False alarm... it appeared to be fixed in r14972. Somehow when comparing against 2.4.0 I didn't notice it was fixed. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] procedure ... message(); in Linux
Michael Schnell wrote: On 02/18/2010 02:48 PM, Sergei Gorelkin wrote:If this is possible with FPC/Linux, I should make sure that it's still possible with the NoGUIApplication package. Windows has a built-in transport for the messages, Linux doesn't. Of course there are libraries providing similar or even better functionality, but you end up depending on particular library. I do know this. This is why I need to port Martin's NoGUIApplication, which has an internal message queue, to Lazarus, I suppose with Linux, FPC (or Lazarus ? ) uses X11 as a message queue provider. Nope. On non windows widgetrsets, lazarus implements its own messagequeue which is handled in application.Idle. On some widgetsets (iirc Carbon and QT) this messagequeue is mixed with the messagequeue if that widgetset. But I was not yet able to find out how to post a message into the X11 queue (with a thread or another application) and capture this message by an FPC procedure ... message construct. (with FPC/Lazarus on Windows this does work fine using Windows messages) AFAIK, X11 has no messagequeue but is based on callbacks. If it does work with Linux/X1, I need to think how to make it work with NoGUIApplication, as well. If it does not work in Linux, anyway, I don't think I'll bother. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Semicolon before else
Aleksa Todorovic wrote: On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt mich...@freepascal.org wrote: It breaks the behavious of case: case b of 1 : something; 2 : If a then DoSomethingElse; else DoElse end; As it is now, b=2 and a=False will result in no code executed. After the patch, B=2 and a=False will result in DoElse. Have you actually tried it? I've tested those cases and they should work. Then in your patch, how do you distinguish between the else belonging to the case statement and the else belonging to the if ? Since if I followed this thread correctly, the following is allowed: if a then DoSomething; else DoSomethingElse; So we have an old style case statement: case foo of 1: DoOne; 2: if a then DoA; else DoElse; end; in this case it is clear, the else belongs to the case. Now with your patch case foo of 1: DoOne; 2: if a then DoA; else DoElse; end; should it be read as 2: if a then DoA; else DoElse; or case else DoElse; ??? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Semicolon before else
Aleksa Todorovic wrote: On Fri, Jan 29, 2010 at 12:11, Marc Weustinkmarc.weust...@cuperus.nl wrote: Aleksa Todorovic wrote: On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt mich...@freepascal.orgwrote: It breaks the behavious of case: case b of 1 : something; 2 : If a then DoSomethingElse; else DoElse end; As it is now, b=2 and a=False will result in no code executed. After the patch, B=2 and a=False will result in DoElse. Have you actually tried it? I've tested those cases and they should work. Then in your patch, how do you distinguish between the else belonging to the case statement and the else belonging to the if ? When compiler hits 'end' inside 'case', it analyzes syntax tree created for the last branch, and checks if there was semicolon before last else or not (which is clear sign if that else is part of if statement or case). So this feature is inconsistent ? Imagine I've a case like: case Foo of 1 : DoOne; 2 : If a then DoA; else DoNotA; 3 : DoThree; end; Now, due to changed requirements, 1 and 3 shout do the same, so I change the case into: case Foo of 1,3 : DoOneAndThree; 2 : If a then DoA; else DoNotA; end; This will affect the meaning of 2 too, without noticing... No thank you. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Semicolon before else
Matt Emson wrote: Stefan Kisdaroczi wrote: Am 29.01.2010 12:08, schrieb Marco van de Voort: I don't really see a need for this. Some languages are terminator, some are separator. We are also not Basic in that we try to disambiguate every possible syntax. It is just a risk without real benefit attached to it, so I'm against. +1 +1 To Be brutally honest - +1 for me too. This is very much a solution in search of a problem. If I were looking for any C/C++/C# style features to be added to the language, I would look at the following in no particular order of importance: If we want C style features we should code in C and not in pascal. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defines layout for mips
Felipe Monteiro de Carvalho wrote: I see that mips is progressing =) I added a ppmipsel.lpi file which builds a cross-compiler here, but I haven't yet managed to build the compiler from the makefiles or the rtl. For the RTL I tryed: C:\Programas\fpctrunk\rtl\linuxmake fpc_units CPU_TARGET=mipsel OS_TARGET=linux OPT='-s' make: *** No rule to make target `../mipsel/mips.inc', needed by `system.ppu'. Stop. I searched, but I didn't find what would need to be fixed to get a target for mips.inc ... any ideas? mipsel is not ready yet, even if you copy mips.inc from ../mips and you fix prt0.as and touch the right .as files and you have the crossbinutils, then still not all abstract methods of the compiler are implemented, resulting in: Free Pascal Compiler version 2.5.1 [2009/12/06] for mipsel Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for MIPSEL Compiling system.pp Fatal: Compilation aborted An unhandled exception occurred at $080AEE50 : EAccessViolation : Access violation $080AEE50 $080A2326 $080A1D1F $080A23BE $0817DC73 $0817FC5F $08180D4C $0816C6DF $080680EC $08048296 make[2]: *** [system.ppu] Error 217 So I guess we need to be patient. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dwarf debug info bugs
Paul Ishenin wrote: Hello, FPC developers' list. Today I tried drawf on windows again and found some new bugs. 1) Gdb outpus the next strings for RTL units: file=../objpas/classes/lists.inc,fullname=D:/programming/fpc/rtl/win32/../objpas/classes/lists.inc,line=600 D:/programming/fpc/rtl/win32/../objpas/classes/lists.inc does not look good :) What's wrong with it ? it is a valid path and it points to the file Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] debug information for Variant type
Jonas Maebe wrote: On 01 Dec 2009, at 13:42, Paul Ishenin wrote: Jonas Maebe wrote: Would it be enough if the type name were changed to variant? It would not be 100% safe (since variant is not a reserved word, anyone can declare a variable/type/... with the name variant), but I don't immediately see another solution. I think yes. Does the attached patch work for DWARF with Lazarus? ptype variantvar still shows tvardata, but info variantvar shows static VARIANT V;, and I don't know what the GDB MI will return for the query that Lazarus uses. the mi version of info var.. is not implemented in gdb, so lazarus uses ptype var So I guess for this case, when a TVarrec is returned we'll inspect further using info. Thanks Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] debug information for Variant type
Jonas Maebe wrote: On 03 Dec 2009, at 14:29, Marc Weustink wrote: Jonas Maebe wrote: On 01 Dec 2009, at 13:42, Paul Ishenin wrote: Jonas Maebe wrote: Would it be enough if the type name were changed to variant? It would not be 100% safe (since variant is not a reserved word, anyone can declare a variable/type/... with the name variant), but I don't immediately see another solution. I think yes. Does the attached patch work for DWARF with Lazarus? ptype variantvar still shows tvardata, but info variantvar shows static VARIANT V;, and I don't know what the GDB MI will return for the query that Lazarus uses. the mi version of info var.. is not implemented in gdb, so lazarus uses ptype var So I guess for this case, when a TVarrec is returned we'll inspect further using info. It's also possible to create another definition of tvarrec with variant as name. In that case I think I prefer a full dwarf variant :) It's just slightly less clean to implement. Also note that info var takes a regular expression, so make sure to use info var ^varname$, otherwise you'll get info about a lot of unrelated matches. :) Thanks. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] DEBUGSTART_, DEBUGINFO_ and DEBUGEND_ symbols
hi, while adding sourceline info to the Lazarus disassembler output I ran into the DEBUGSTART_unitnamehere, DEBUGINFO_unitnamehere and DEBUGEND_unitnamehere symbols. What I wonder is why DEBUGSTART and DEBUGEND are reported as functions, while DEBUGINFO is reported as datavariable (fpc 2.2.4, stabs). (gdb) ptype DEBUGSTART_UNIT1 type = function : int (gdb) ptype DEBUGINFO_UNIT1 type = data variable, no debug info (gdb) ptype DEBUGEND_UNIT1 type = function : int Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DEBUGSTART_, DEBUGINFO_ and DEBUGEND_ symbols
Jonas Maebe wrote: On 22 Nov 2009, at 18:43, Marc Weustink wrote: while adding sourceline info to the Lazarus disassembler output I ran into the DEBUGSTART_unitnamehere, DEBUGINFO_unitnamehere and DEBUGEND_unitnamehere symbols. What I wonder is why DEBUGSTART and DEBUGEND are reported as functions, while DEBUGINFO is reported as datavariable (fpc 2.2.4, stabs). DEBUGSTART and DEBUGEND are symbols in text section, while DEBUGINFO is a label in the data section. I don't know exactly how the mechanism works, but the only purpose of these symbols is to prevent debug info from being smartlinked out. They are irrelevant for the actual debugging. not really (otherwise I won't run into it ;) ) Since the exe doesn't contain NOP beweeen unit code, when disassembling, you can get the following: (gdb) disas 0x0808b0cc 0x0808b0d6 Dump of assembler code from 0x808b0cc to 0x808b0d6: 0x0808b0cc FORMS_finalize+44: ret 0x0808b0cd DEBUGEND_FORMS+0: add%al,(%eax) 0x0808b0cf DEBUGEND_FORMS+2: add%dl,0xff89(%ebp) 0x0808b0d2 TFORM1__BUTTON1CLICK+2:in $0x81,%eax 0x0808b0d4 TFORM1__BUTTON1CLICK+4:in (%dx),%al 0x0808b0d5 TFORM1__BUTTON1CLICK+5:pushf while this is correct: (gdb) disas 0x0808b0d0 0x0808b0d6 Dump of assembler code from 0x808b0d0 to 0x808b0d6: 0x0808b0d0 TFORM1__BUTTON1CLICK+0:push %ebp 0x0808b0d1 TFORM1__BUTTON1CLICK+1:mov%esp,%ebp 0x0808b0d3 TFORM1__BUTTON1CLICK+3:sub$0x9c,%esp Anyway, I now know that when I encounter a DEBUGEND function, I need to take special actions. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Graeme Geldenhuys wrote: Florian Klaempfl wrote: initialized. But be warned: with such a parameter type you can easily create memory leaks with automated types like ansistrings. Well, isn't that what heaptrc is for? No, the language should protect you from such easy to make mistakes. In theory don't want to know how a type is implemented and if it is safe to pass as parameter (unless the compiler forbids using varout for such types) Weren't you recently involved in a discussion about knowing the under-the-hood implementation of automated types and their behaviour ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test
fpc...@silvermono.co.za wrote: Hi, Just subscribed, testing system. Welcome Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Paul Ishenin wrote: Michael Van Canneyt wrote: My only worry now is to make sure that if they are implemented, that we make the design as clean as possible: e.g. No hardcoded dependencies on class or interface names. We need to count the pros and contras first regards hardcoded names and maybe 'hard coded' code. For example for me the hardcoded 'Result' identifier for all functions is a big advantage. But you are still using the function names to set the result values I suppose. So during this clean design designing we need to find a compromise between 2 approaches. Having an implicit result variable or Self variable is something completely different than having the knowledge of a class and scanning its function names and assign a function to a certain name. The first is defined by the compiler, the second is declared by you, the code writer. for example, would you argue if iterator will be any container type: object/class with the next declaration: TMyIterator = object public function StepNext: Boolean; property TheCurrentValue: Integer; iterator MoveNext = StepNext; iterator Current = TheCurrentValue; end; When 'iterator MoveNext' or 'iterator Current' are not defined then compiler uses default hardcoded identifiers 'MoveNext' and 'Current'. This is very like to how you can bind interface methods to the class methods if they are differ. Again, here you mix names and functionality. Compare it to a default propery, you declare it as: property Foo[index:integer]: String read GetFoo; default; and not as property Default[index:integer]: String read GetFoo; Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Graeme Geldenhuys wrote: 2009/10/20 Alexander Klenin kle...@gmail.com: for-in is just a syntax sugar plus standard interface for the cost common usage of iterators. So they are not mutually exclusive at all. Another flaw in the for-in concept... What will this do: for y in MyList do begin if y = XXX then MyList.Add(YYY); if y = ZZZ then MyList.Insert(1, AAA); end; With my iterator implementation I can handle this with no problems, and ever make the resulting behaviour user-selectable with parameters to the MyList.GetIterator method. This is IMO similar to using a for loop vs. using a while loop. In a for loop you are not allowed to modify the loop variable. In this case I can imagine its not allowed to modify the list. If you want to, use a while and iterators. Yes I know iterators, I use them myself too on my own lists. As said I before, I think too that tose can be combined. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: On Tue, 20 Oct 2009, Paul Ishenin wrote: Michael Van Canneyt wrote: At least one of the reasons we never did implement for-in is the absolutely horrible and totally wrong idea to use classes/interfaces for this, to which I seriously objected. Reading this I conclude you are against 'for-in' implementation in fpc. No. I can understand for y in enumerated do or For y in set do or For Y in range do Because this seems a natural extension of loops to enumerates (and even then) But not ever the class-based one. So you are not against it but you want to allow them only for the base types? Yes. IMO too I hope you understand that ppl will use them for classes anyway? Those people should be re-educated to use iterators. Exactly. This all start to look a bit to much like the VB iterator magic. Where some under the hood functions (names) were used for iterating. If you didn't declare a container with the right function names you couldn't loop. var P: Pointer; begin for P in GetComponents(Component) do TComponent(P).DoSomething; end; And what is so special in the class type? First: For a for loop, you are guaranteed that the loop logic behaves correctly. A loop is equivalent to the following: I:=StartValue; E:=EndValue; While I=EndValue do begin // loop stuff Inc(I); end; And you cannot change I manually during the loop. You don't know this with an iterator since you depend on the implementation of the iterator. The loop could loop forever then... Secondly: You promote a certain class/interface to a language feature. The compiler then depends on the presence of a certain class with some 'known' methods in the RTL. Both points are simply wrong from a language point of view. Exactly. You extend a language construct with something defined with that language (i don't know how to explain better) It is bad enough that the second point is already so for interfaces and even TObject, (a very serious design flaw by Borland) but extending this even further to include actual language features such as the for loop is 2 bridges too far as far as I'm concerned. Especially when you can have perfectly the same functionality with iterators. I can see a use for using iterators in a for loop, however they should be declared with some keyword. Something like type TListIterator = iterator(TList, init_func, next_func, check_func) function init_func: Boolean; function next_func: element type function check_func: Boolean; end; begin for element in list using TListIterator do... IMO this is more pascal than using some interface or predefined function names. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi smart-linking perspective ( Language change and implementation ... )
Marco van de Voort wrote: In our previous episode, Florian Klaempfl said: Also note that WPO can do little about published methods (since it must assume that these can all be called via RTTI). Maybe the IDE can feedback some info about used classes and methods? In time, a pascal analyser would be a good thing to have. I think analysis of smartlinking is more something for an analyzer than the compiler itself (though the compiler could generate certain datafiles obviously). This won't help lazarus. For lazarus, also the contents of the lfms is important. Yeah, I got it when I saw Jonas' reply. The IDE could list all visual components in forms in a file and hand it to the compiler. And a custom list could allow additional streaming types (for users code) All components are already sortof reported :) In order to get streamed, each component must have a member variable in the owning form. However what is needed is a list of properties touched in the lfm (setting control.caption or control.font.color for instance). Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi smart-linking perspective ( Language change and implementation ... )
Martin Friebe wrote: Marc Weustink wrote: Marco van de Voort wrote: In our previous episode, Florian Klaempfl said: Also note that WPO can do little about published methods (since it must assume that these can all be called via RTTI). Maybe the IDE can feedback some info about used classes and methods? In time, a pascal analyser would be a good thing to have. I think analysis of smartlinking is more something for an analyzer than the compiler itself (though the compiler could generate certain datafiles obviously). This won't help lazarus. For lazarus, also the contents of the lfms is important. Yeah, I got it when I saw Jonas' reply. The IDE could list all visual components in forms in a file and hand it to the compiler. And a custom list could allow additional streaming types (for users code) All components are already sortof reported :) In order to get streamed, each component must have a member variable in the owning form. However what is needed is a list of properties touched in the lfm (setting control.caption or control.font.color for instance). Unfortunately, thanks to RTTI this isn't enough. [snip] but... The IDE cannot know of any of those cases either, so it cannot generate the list. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Archer and Dwarf-3
I've been quite busy last weeks, so a bit late reply. Joost van der Sluis wrote: Hi all, I've switched back to Linux/Fedora 11 to continue testing Dwarf-3 and Archer further. (Because that's my natural habitat, Windows just slows me down - especially using GIT) So I'm on the 'official' fedora-archer-gdb version now, and recent fpc-trunk. I have a few remarks: Case sensitivity The name of dynamic arrays are case-sensitive, while the names of 'normal' arrays aren't case-sensitive. When you look at the code of dbgdwarf this makes sense, since for 'normal' arrays the dwarf-2 code is called, while for dwarf-3 some other code is executed. So it could be that the dwarf-3 code is case sensitive, but I can't see why. Besides, using objdump -w, I see no difference between the defined name of a dynamic array and a normal array. So why does gdb handles them differently? When dwarf-2 is used, all names are stored in capitals into the debug-information. For dwarf-3 they are stored as how ther are defined in the sources. Is that something new in dwarf-3? That you can supply the casing as it is in the source, but that they still can be handled case-insensitive? First some background. I introduced the -gw3 (dwarf3) mode of the compiler to experiment with my own debugger. The idea was to have a clean dwarf3 implementation according to the specs, not hindered by limitations in GDB. One of those limitations is/was case sensitivety. In dwarf you can specify in what language the code is written and if the code is case sensitive. Since I like to view symbols in the same case as they are coded, I turned off uppercase names for my dwarf23 extentions. (when you use CamelCase variables they become more readable when debugging) So normal arrays still may use the existing dwarf2 descriptions, while dynamic arrays use the new dwarf3 descriptions Printing arrays Printing the contents of an array doesn't work (print arrr). They are showed as a pchar, but using 'whatis arr' then the type is correctly given. Except that the size of dynamic arrays is bogus. (way too large) Using 'print[x]' works fine on arrays of shortint, though. But it fails on arrays of ansistrings. It always prints the value of the first member. I would say that this is a gdb bug, and not the debug-info. But that's just a guess. Outside an array, ansistrings work fine! I see some differences/errors between pchar and ansistring types. It seems that the symbols created for them are the same. Depending on the gdb function you use, both are reported the same, eihter as ^character or as ansistring. For indexing this is a huge difference, since ansistrings start to count at 1 while a ^character starts to count at 0 Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting FPC to Support OpenMoko
Henry Vermaak wrote: 2009/3/21 ik ido...@gmail.com: Hello All, Sorry for the late response. I will try the fpc port of Turbo Control soon. The file command gives me the following information: /bin/busybox: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped I do not have experience with non x86 architecture. Can anyone tell from that what is the type of ABI for arm ? you should be able to tell from the readelf -h output, and if you try this with your cross compiler: arm-linux-gcc -dM /dev/null | grep -i arm for more info, read: http://wiki.debian.org/ArmEabiPort BTW, see this thread too http://www.mail-archive.com/laza...@miraclec.com/msg22236.html Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Win32 DWARF problem (was: Debugger for FPC)
Marc Weustink wrote: If we cannot solve this, in case of DWARF2 i think we can leave those attributes out. I've tested this (by editing the .s file) and gdb still seems to work and doesn't complain anymore. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Win32 DWARF problem (was: Debugger for FPC)
Jonas Maebe wrote: On 14 Mar 2009, at 15:42, Paul Ishenin wrote: Tomas Hajny wrote: Keeping -gl instead of -gw? Sorry, leave out was not in my head dictionary :) c:\programming\fpc\bin\i386-win32\ppc386.exe -gw test.pp (gdb) break test.pp:8 invalid dwarf2 offset 4243567 In the mean time, we got basic debugging working. There's one problem left I'm not sure how to solve though. In the DWARF compilation unit header, you have to record the start and the end address of the code in that compilation unit (= object file). We currently do this by inserting a .text section at the start of the object file with a start label, and one at the end of the object file with an end label. On Win32 however, we don't put any code in a plain .text section. We put all code is sections called like .text.n_p$test_proc and .text.n__main. The linker script afterwards groups all .text* sections, but it puts the plain .text sections first. As a result, all these start and end labels end up at exactly the same location: at the very beginning of the code section of the entire application, rather than at the individual start and end addresses of the code from the individual object files. I don't immediately see how to fix this. Maybe be we can put those labels at the start and end of the al_procedures assembler lists for Windows, but I don't know whether we never put .text* sections in any other assembler lists. --- From the DRAWF2 spec -- The compilation unit entry may have the following attributes: 1.A DW_AT_low_pc attribute whose value is the relocated address of the first machine instruction generated for that compilation unit. 2.A DW_AT_high_pc attribute whose value is the relocated address of the first location past the last machine instruction generated for that compilation unit. The address may be beyond the last valid instruction in the executable, of course, for this and other similar attributes. The presence of low and high pc attributes in a compilation unit entry imply that the code generated for that compilation unit is contiguous and exists totally within the boundaries specified by those two attributes. If that is not the case, no low and high pc attributes should be produced. --- From the DRAWF# spec -- Either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a DW_AT_ranges attribute whose values encode the contiguous or non-contiguous address ranges, respectively, of the machine instructions generated for the compilation unit. A DW_AT_low_pc attribute may also be specified in combination with DW_AT_ranges to specify the default base address for use in location lists and range lists. If we cannot solve this, in case of DWARF2 i think we can leave those attributes out. And in case of DWARF3 I think we can use ranges to specify each section. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger for FPC
dmitry boyarintsev wrote: sorry! unfinished note: 2) gdb can be extended to support FPC syntax, if enougth information is provided with GDB. And ofcause, some C-programmer might be required. I'm not really sure about this. IIRC the internal design of gdb is modeled after the STABS debug format. This means that even for DWARF, it internally is translated to STABS, meaning that not all contstucts possible in DWARF are supported. Given this I have doubts that all features of FPC can be implemented in gdb. (again, IIRC) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Mantis monitoring configuration
Jonas Maebe wrote: On 03 Mar 2009, at 06:47, Flávio Etrusco wrote: what's the current status on this issue, please? http://bugs.freepascal.org/view.php?id=8803 In what sense? Do you still get emails for all bug reports, or do you not get any emails at all (even for your own bug reports)? As far as I know, the problem has been fixed, and I thought that email notifications had already been re-enabled also for the FPC project. They are not. For fpc the following cases are only enabled: * User who reported issue * User who is handling the issue * Users monitoring this issue * Users who added Bugnotes * status new (developer, manager, administrator) To Flávio Etrusco: Can you give me some bugnumbers of reports you got, which shouldn't have been sent to you ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Mantis monitoring configuration
Marc Weustink wrote: Jonas Maebe wrote: On 03 Mar 2009, at 06:47, Flávio Etrusco wrote: what's the current status on this issue, please? http://bugs.freepascal.org/view.php?id=8803 In what sense? Do you still get emails for all bug reports, or do you not get any emails at all (even for your own bug reports)? As far as I know, the problem has been fixed, and I thought that email notifications had already been re-enabled also for the FPC project. They are not. For fpc the following cases are only enabled: * User who reported issue * User who is handling the issue * Users monitoring this issue * Users who added Bugnotes * status new (developer, manager, administrator) To Flávio Etrusco: Can you give me some bugnumbers of reports you got, which shouldn't have been sent to you ? BTW, did you know you have (at least) 2 accounts ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to search units reported by gdb? (fpc and mseide devels please participate)
Jonas Maebe wrote: On 27 Feb 2009, at 16:08, dmitry boyarintsev wrote: Feel free to file a feature request what about patch? :) what units should be studied to make such patch? compiler/dbgstabs.pas P.S. AFAIK, Marc told me, that FPC does not generate DWARF line info for yet, so it's not possible to use DWARF to find files or anything else... That's incorrect. Indeed, iirc its one of the first things I added to fpc (and broke). Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf Debug Information
dmitry boyarintsev wrote: Hello AFAIK, dwarf debug info generation is not yet fully implemented for the compiler. I'm interseted in CallFrame information, so debugger, can use it to unwind the call stack. I've tried to compiled hello world program using fpc -gw3 hello.pas, and found that there's .debug_frame section. Is DWARF Call Frame information generated? Is .debug_frame wrong place to searching for it? anything else am i missing? at this moment callframes only get generated for 64bit exes. I've a pending patch which solves this. When I'm familiarized again with the current compiler sources, I'll commit. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC debug information
dmitry boyarintsev wrote: It is impossible to encode properties in stabs. In Dwarf you can in theory describe pretty much anything, but gdb does not yet support the full Dwarf specifications. I guess it would be possible already to add debug info for properties that simply map directly to a field, but other than that I'm not sure if there's much we can do at this point. property can also be read as function, is it possible to add pointer to the functions, as well? A property is not only reading but might be writing also (or only). Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC debug information
dmitry boyarintsev wrote: i know Marc, but the purpose is to make expression evaluation. while setting property is procedure, i can't think of any expression that uses it. But of couse, it might be usefull to know how to set properties (directly member of class, or a method) i guess, that property information is also available at .ppu files Unfortunately, a debugger doesn't have that information. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assign constant text to widestring
Michael Schnell wrote: Ultraedit might fool you here. Id edits either ansi or usc2. If you have a utf8 encoded file, it will show the contents in hex as being ucs2 That might be. But it would even virtually insert a BOPM ?!?!?!? Why should it do this when using the hex editor ? Since it converts the UTF8 file internally to UCS2 on read before editing. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assign constant text to widestring
Michael Schnell wrote: Since it converts the UTF8 file internally to UCS2 on read before editing. Seems really silly to me. No it's not. This way you have internally only to support 2 editors. One with bytechars and one with wordchars (ignoring surrogates and other stuff) But the file length really indicated that it's utf8 coded and when looking at the file with WinCommander's hex viewer it's utf-8. So I suppose that you are right and the nasty trick is Ultraedit's. Yes, since auto conversion by the OS i find very unlikely (yes I once tripped over this with ultraedit too) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Marco van de Voort wrote: In our previous episode, Ivo Steinmann said: fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Why not creating a new kind of managed class, that is refcounted, initialized, finalized, etc... like String type? I never liked string-types as classes. They feel like cheap imitations of a real string type. OK, then we name it objects (or records with methods) Before you know it you are messing with special stringbuilder classes and special syntax to keep a semblance of performance. Moreover I don't really see what this solves. It solves the case that you want to have records/objects with non standard inatialisation/finalisation code. Refcounted assignments etc. If this were possible, I would have used in for the utf enconding of strings and for the wincontrol.handle/reference in lazarus. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to make the compiler message PPU Invalid Version a fatal error.
Mattias Gaertner wrote: On Wed, 13 Aug 2008 23:12:25 +0200 (CEST) Daniël Mantione [EMAIL PROTECTED] wrote: [...] The text mode IDE can display statisics while compiling. Why can't Lazarus? There is the compiler unit, which *is* available, and this is the only officially supported compiler interface. We are not against other officially supported interfaces, but parsing messages is definately not an offical interface and recommended against. It is not the first time we have this discussion, we discussed possible protocols before. Can you give a link? http://lists.freepascal.org/lists/fpc-devel/2006-May/007788.html Thanks. The thread did not discuss all problems, but it has one good idea: We need a machine readable output format for fpc. Any progress? IIRC, we once had the idea to feed the compiler an error message file with only error numbers as error messages so parsing would be easier. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
Marco van de Voort wrote: Marco van de Voort wrote: Inoussa OUEDRAOGO wrote: - TAVLManagedTree that uses a node mem manager provided in the constructor. The developer using this one is _aware_ of the thread safety issue and can then provide a thread safe node mem manager for an instance exposed What is exactly the add-on value for the node mem manager? I can only think of heap fragmentation and reduction of creation overhead. Yes, but fpc's memory manager also already does this (at least if the allocation size is less than 512 bytes or so). But fpc's memory manager won't be always used. There is cmem, and a future sharemem as options too. And sharemem-likes are known to be slow. The memmanager might also do this might be a reason to not enable it by default, but not a reason to eliminate the possibility all together. I'm pro having a manged and an unmanaged avltree. One (big) disadvantage of the current implementation (with a shared node manager for all trees) is that you cannot add custom derived treenodes since they will be released in the pool too. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetAppConfigDir confusion
Ales Katona wrote: It seems that currently, GetAppConfigDir performs rather incosistently. On Unix, it returns path with trailing pathdelim, on windows it returns path with random trailing path delim (depends on which branch, see code). What should it be then? :) This is exactly the reason why I at work created the utility function: function ConcatinatePath(const Elements: array of string): String so it will take cate if a delim exist or not for the individual parts. (especially when users may define a dir) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Graeme Geldenhuys wrote: Hi, - snip -- Include(WindowAttributes, waStayOnTop); // == doesn't compile with FPC 2.3.1 WindowAttributes:=WindowAttributes +[waStayOnTop]; // == this does - end -- As far as I understood, the above two lines should do exactly the same thing and I have been using Include() since Delphi 5 days and FPC 2.0.2. Now in FPC 2.3.1 it doesn't work any more. I get the following error. You cannot pas properties in var parameters. (Imagine WindowAttributes had a Getter and didn't read directly from FWindowAttributes) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tiburon compatibility
Leonardo M. Ramé wrote: Apparently the new Delphi version (Tiburon) will change the way strings are handled by the rtl and the compiler, this changes affects Unicode characters specially. Surely the code created with the new Delphi version shouldn't compile with FPC. Why shouldn't ? Is somebody addressing the changes to make them compatible with future versions of FPC, or this will be the finish of compatibility between the two compilers? Ehm... afaik, tiburon is not released yet, so how should we know what the incompatibilities are ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ExtractFileDrive is broken under Linux
Micha Nelissen wrote: Graeme Geldenhuys wrote: :/tmp$ ls -l drwxr-xr-x 3 graemeg graemeg 4096 2008-05-21 11:43 app -rw-r--r-- 1 graemeg graemeg0 2008-05-21 13:14 c:\myfile.txt -rw-r--r-- 1 graemeg graemeg0 2008-05-21 13:12 c:myfile.txt -rw--- 1 graemeg graemeg 607 2008-05-21 11:48 code-1.pp -rw--- 1 graemeg graemeg 607 2008-05-21 11:48 code.pp That's nuts! :-) Why? Because it does what you ask? :-) on unix you can even create weirder filenames: [EMAIL PROTECTED] ~]$ ls -lbQ total 1348 -rw-rw-r-- 1 marc marc 0 2008-05-21 22:37 -rw-rw-r-- 1 marc marc 0 2008-05-21 22:31 \n drwxr-xr-x 2 marc marc4096 2008-03-18 00:11 bin ... in the early days accessing ftp warez sites having dirs starting with #0 was fun :) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fix for SwapEndian
Jonas Maebe wrote: On 29 Apr 2008, at 17:00, Michael Schnell wrote: I think shr is supposed to work sign-extending with signed types. The above statement may cause some confusion, so people who think that shr means shift arithmetic right, please read the comment added tohttp://bugs.freepascal.org/view.php?id=10545 OOPs !?!?!?! They say: SHR is /always/ unsigned in TP/FPC/Delphi. This would mean that the patch the OP mentioned should not be necessary No, it doesn't. The reason is explained in the comment. The stuff about first converting and then shifting seems quite queer (unless the types left and right are different which imposes queer behavior in C, too). In Pascal, calculations are usually performed using the native integer type, regardless of the left and right types (there are some exceptions, but not many). That is not true for C. Sorry, didn't realize that when I wrote those. (maybe still some 16 bit artifact) The reason that some of them are dups of swap is that imo the only usefull implementation of swap is the word version. This was valid enoug for me to implement all in a same way/name. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TComponent.Tag type
Graeme Geldenhuys wrote: This has been discussed before: http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg05895.html It could be problematic if a Tag is streamed and read on different platforms. It would better to introduce a new (non streamable) SizeInt property. In fpGUI I introduced the following... public property TagPointer: Pointer read FTagPointer write FTagPointer; Non-streamable, but handy. Would that work? At work I completely abanonded putting pointers in tags, but I use a Map like object inbetween: on create: SomeObject.Tag := GetnextTagSequence; ObjectMap.Add(someObject.Tag, someObject); on use: if ObjectMap.GetData(someObject.Tag, someObject) then someObject.dosomething On destroy of SomeObject is is removed form the map. Advantage is that if the tag is passed to different routines, if the map cant find the object, it is destroyed, so you never reference a destroyed object. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] QEMU for 64-bit FPC testing?
Graeme Geldenhuys wrote: Hi I don't own a 64bit pc. With the wonderful world of emulators and virtual pc products like VirtualBox, VMWare and Virtual PC 2007 I thought, why can't my 32bit Intel P4 emulate a 64bit CPU via software. If it works, that would be cool. :) If it works it might be slow, but I don't care, it's simply for testing purposes. Yes, before I had a XP64 machine I ran a XP64 in qemu on a 2.8GHz P4 XP32 machine. The emulated XP64 was dog slow (I used the buildin qemu-vnc as display). It takes minutes to open a dialog or so. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LockFree Queue algorithm
Dariusz Mazur wrote: Florian Klaempfl pisze: DarekM schrieb: Florian Klaempfl pisze: An if is unimportant, more important is the number of locked operations, especially on multi core systems they might eat hundreds of clock cycles. There are atomic operations, the should not eat much more than ordinal INC or ADD, If course they are. They require no more a bus lock as in 486 times but a synchronization of all caches for this particular memory location. We don't need wait to synchronize caches. It will be done by hardware. ehm... according to your pdf: For the P6 family processors, locked operations serialize all outstanding load and store operations (that is, wait for them to complete). This rule is also true for the Pentium 4 and Intel Xeon processors, with one exception. Load operations that reference weakly ordered memory types (such as the WC memory type) may not be serialized. And i think synchronize cache with ram don't eat hundreads clock cycles. I think it does, why else do we need cache ? And CMPXCHG has automatic locking asserted, as normal instruction can't persist so long (Intel don't mention about this) This is also use to implement semaphores (suggest from Intel) , thus should be save and fast. first, yes, second, thats relative. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in revision 9781/2
Daniël Mantione wrote: Op Sat, 19 Jan 2008, schreef Jonas Maebe: On 19 Jan 2008, at 15:54, Peter Vreman wrote: This call and pop is old-style PIC and not good for new cpus because it breaks the call-stack. Please use the new style that calls a function (fpc_geteipasebx). This also generated by the compiler. See i386/cgcpu.pas and search for g_maybe_got_init. I recently read that on the more recent processors, call/pop is slightly faster again (I suppose they detect a call to next instruction and don't add it to the internal call stack or so). http://lists.apple.com/archives/perfoptimization-dev/2007/Nov/msg5.html Intel cpu's since Pentium M and AMD cpu's since Barcelona indeed have a stack analyzer. I'm still going to switch back to the fpc_geteipasebx helper since the extra call/ret penalty on those processors is small while the penalty of a broken call stack is large. Just for my information, this callstack, is it tracked by the CPU or generated by FPC. I somehow fail to see why a callpop will affect the callstack in case it is generated. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New -Xg option in the last 9778 revision
Michael Van Canneyt wrote: On Fri, 18 Jan 2008, Peter Vreman wrote: I suggested using Lazarus and the OP said he had great doubts because the size of the exe of his test program is 10 times the size of that compiled by Borland. Anyone who writes such texts doesn't look further than his nose. Experience shows they will just hit the next thing which makes Lazarus unusable. Don't expect such idiots to become Lazarus users. That is partly true. The problem is that setting -Xs doesn't help if there is also -g in the command line. So people think that the compiler strips the executable, but in fact the binary is unstripped. The easiest way to solve this is with a check in Lazarus. When the strip checkbox is checked a note shall be shown and asked to disable the debuginfo to make the option work. The real solution is what a lot of people already asked for. Multiple build modes like Visual C++ also has. I think this is indeed the best, and should be not so hard to implement; At least the check would be already a hint to users. :) We thought about this some years ago. It is not as trivial as it seems. Initial problem was to present all possible options to the user. The tree based optiondialogs might help with this. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New -Xg option in the last 9778 revision
Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Marc Weustink: Michael Van Canneyt wrote: On Fri, 18 Jan 2008, Peter Vreman wrote: I suggested using Lazarus and the OP said he had great doubts because the size of the exe of his test program is 10 times the size of that compiled by Borland. Anyone who writes such texts doesn't look further than his nose. Experience shows they will just hit the next thing which makes Lazarus unusable. Don't expect such idiots to become Lazarus users. That is partly true. The problem is that setting -Xs doesn't help if there is also -g in the command line. So people think that the compiler strips the executable, but in fact the binary is unstripped. The easiest way to solve this is with a check in Lazarus. When the strip checkbox is checked a note shall be shown and asked to disable the debuginfo to make the option work. The real solution is what a lot of people already asked for. Multiple build modes like Visual C++ also has. I think this is indeed the best, and should be not so hard to implement; At least the check would be already a hint to users. :) We thought about this some years ago. It is not as trivial as it seems. Initial problem was to present all possible options to the user. The tree based optiondialogs might help with this. The FPC IDE has had it for years. All user interface support you need is the Options-Mode menu. For the rest the handling all internal; the IDE uses an array of options, one for each build mode, each with its own defaults. Yeah... and we want something less static and more configurable, default options, release/debug/whatever build, target dependent etc.etc.etc. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Debug Info proposal
Fabio Dell'Aria wrote: Can you tell we more about the iirc gdb please? IIRC - If I Recall Correctly This is about plain gdb, since fpide uses gdblib I don't know if it counts foir that too. Anyway, on my fedora core, I've the option to install a somelib-debuginfo package. This package installs /usr/lib/debug/usr/lib/libname.so.x.y.z.debug and /usr/src/debug/packagename-version/*.c I didn't read the gdb info again, but from what I recal, gdb automagically searches for any path+lib loaded in /usr/lib/debug if this path+lib.debug exists. If so, it uses that as symbol source. Further, it looks in /usr/src/debug/ for sources. This is why I wondered about the statement that the debugger doesn't support it. Marc 2008/1/13, Marc Weustink [EMAIL PROTECTED]: Daniël Mantione wrote: Op Sat, 12 Jan 2008, schreef Fabio Dell'Aria: OK, but why do not add the debug info in an external file (conform to stabs/dwarf specification)? Because the debugger doesn't support this; the compiler can do it, but, without debugger support it is useless. ?? iirc gdb (at least on linux) supports this. This is how I debug gdk libs. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://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] Debug Info proposal
Daniël Mantione wrote: Op Sat, 12 Jan 2008, schreef Fabio Dell'Aria: OK, but why do not add the debug info in an external file (conform to stabs/dwarf specification)? Because the debugger doesn't support this; the compiler can do it, but, without debugger support it is useless. ?? iirc gdb (at least on linux) supports this. This is how I debug gdk libs. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FP 2.4 questions
Mattias Gaertner wrote: On Wed, 2 Jan 2008 11:08:27 +0100 (CET) [EMAIL PROTECTED] (Marco van de Voort) wrote: Then I don't get why people refuse that lazarus is recompiled and see dyn. loaded packages as _the_ solution to this problem :) Is there another solution that makes it possible to compile and test a (future) visual component before installing it and with a simple click-click action add it to the component library (even if this involves waiting some minutes). No. Not even Delphi has that. The property editors and component registrations must be known to the visual environment. It depends on how much IDE stuff the package needs. Property Editors can be tested without the IDE by using the RTTI controls. New codetools features can be tested without the IDE. Some IDE parts can be tested with the SimpleIDEIntf package components/simpleideintf/simpleideintf.lpk. This package simulates a simple IDE to allow testing IDE experts at command line. It fills several objects and functions of the IDEIntf. Experts and Component Editors need the whole IDE. Properties (and I think component editors too) can also be tested with the ObjectInspector example. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
