Re: [fpc-devel] darwin - rtl include files

2006-05-17 Thread Michael Van Canneyt
On Tue, 16 May 2006, Micha Nelissen wrote: On Tue, 16 May 2006 16:11:43 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: IMHO: Eventually, you'll have to switch to parsing the .ppu files for some parts. Do .ppu files tell in what source file and what line a

Re: [fpc-devel] smrtlinking on arm-wince

2006-05-17 Thread Oro06
How can I check this? binutils is our friend :) I think the problem is not as much the imported functions from the windows unit, although that is interesting too, but more the used functions / procedures and methods from the classes unit. Do you know how I can check, that things are

Re: [fpc-devel] darwin - rtl include files

2006-05-17 Thread Michael Van Canneyt
On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system? Most people use precompiled FPC

Re: [fpc-devel] darwin - rtl include files

2006-05-17 Thread Vincent Snijders
Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system?

Re: [fpc-devel] darwin - rtl include files

2006-05-17 Thread Jonas Maebe
On 16 mei 2006, at 21:50, Micha Nelissen wrote: between minor OS revisions). Libc is also guaranteed to be forward compatible (i.e., the situation that a program will not run anymore So an application linked against any future version of libc is guaranteed to work also against the current

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread Peter Vreman
On 16 May 2006, at 20:32, Michael Van Canneyt wrote: 1. It's heap based. There is a lot of memory manager overhead. 2. The implicit try...finally in each procedure that uses them introduces a memory penalty and a speed penalty. So I would really advise against this change. There is no

[fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)

2006-05-17 Thread Graeme Geldenhuys
This is a follow-up on Bug #4738. I did more testing and have a clearer idea of why it throws an EVariantError exception. GetPropValue doesn't handle enumerated types correctly when GetPropValue gets called with the 3rd parameter (PreferStrings) set to True (the default). GetPropValue returns

Re: [fpc-devel] darwin - rtl include files

2006-05-17 Thread Mattias Gaertner
On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals

Re: [fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)

2006-05-17 Thread Michael Van Canneyt
On Wed, 17 May 2006, Graeme Geldenhuys wrote: This is a follow-up on Bug #4738. I did more testing and have a clearer idea of why it throws an EVariantError exception. GetPropValue doesn't handle enumerated types correctly when GetPropValue gets called with the 3rd parameter (PreferStrings)

Re: [fpc-devel] darwin - rtl include files

2006-05-17 Thread Michael Van Canneyt
On Wed, 17 May 2006, Mattias Gaertner wrote: On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical

Re: [fpc-devel] darwin - rtl include files

2006-05-17 Thread Daniël Mantione
Op Wed, 17 May 2006, schreef Michael Van Canneyt: source locations? According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips, code completion) - View actual sources. For the first, the .ppu is enough. In Delphi 'Find declaration'

Re: [fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)

2006-05-17 Thread Graeme Geldenhuys
Hi Michael, I do understand that variants are slow, but unfortunately I can't get rid of them. I use the tiOPF framework and in the framework we created a generic Assign method in our base class used for all objects. The Assign uses RTTI extensively with variants to handle all datatypes,

Re: [fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)

2006-05-17 Thread Michael Van Canneyt
On Wed, 17 May 2006, Graeme Geldenhuys wrote: Hi Michael, I do understand that variants are slow, but unfortunately I can't get rid of them. I use the tiOPF framework and in the framework we created a generic Assign method in our base class used for all objects. I thought it came from

Re: [fpc-devel] darwin - rtl include files

2006-05-17 Thread Peter Vreman
On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that

Re: [fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)

2006-05-17 Thread Joost van der Sluis
Variants are not required for this. Variants are for (excuse me the term) lazy coders... I assure you that implementing variants is not for lazy coders. ;) Joost. ps: not that you don't know that ___ fpc-devel maillist -

Re: [fpc-devel] darwin - rtl include files

2006-05-17 Thread Mattias Gaertner
On Wed, 17 May 2006 10:58:46 +0200 (CEST) Peter Vreman [EMAIL PROTECTED] wrote: On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17

[fpc-devel] Re: GetPropValue and enumerated types (Bug #4738 follow-up)

2006-05-17 Thread Graeme Geldenhuys
Is there any way to add extra notes to the original bug report, otherwise whoever looks at that bug report will never know about this post and the easier example? Graeme. On 17/05/06, Graeme Geldenhuys [EMAIL PROTECTED] wrote: This is a follow-up on Bug #4738. I did more testing and have a

[fpc-devel] make install into a cross-compiled unit hierarchy.

2006-05-17 Thread J. Peter Mugaas
I have a problem installing a third-party package using the fpcmake build system. I built a cross-compiler for WinCE including a complete RTL for arm-wince. I now want to install a third-party package into an arm-wince unit hierarchy on a WindowsXP system. Make is assuming that you need

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread L505
The SysUtils unit misses some performance tweaks that the Dos unit has. Especially for the FindFirst/FindNext part. But this has low prio for the current developpers so it hasn't been analysed and fixed yet. What do you guys thing about the idea to implement what DEC Pascal and Extended

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread Jonas Maebe
On 17 mei 2006, at 19:59, L505 wrote: What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related ShortStrings to be MediumString[1000] instead of ShortString[255]. For some

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread Vincent Snijders
Jonas Maebe wrote: On 17 mei 2006, at 19:59, L505 wrote: What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related ShortStrings to be MediumString[1000] instead of

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread L505
On 17 mei 2006, at 19:59, L505 wrote: What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related ShortStrings to be MediumString[1000] instead of ShortString[255].

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread Jonas Maebe
On 17 mei 2006, at 20:19, L505 wrote: We wouldn't have to use sysutils yet.. we could make a custom Dos unit which used longstrings instead of short strings, but keep the old Dos unit for compatibility.. This still means that someone has to finish and test longstring support in the

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread L505
We wouldn't have to use sysutils yet.. we could make a custom Dos unit which used longstrings instead of short strings, but keep the old Dos unit for compatibility.. This still means that someone has to finish and test longstring support in the compiler, and create this longstring Dos

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread Daniël Mantione
Op Wed, 17 May 2006, schreef L505: On 17 mei 2006, at 19:59, L505 wrote: What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related ShortStrings to be

RE: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread peter green
I'm happy with current compiler because all I have to do is change several of my paths to a bit of a shorter path - it's not a big deal if you know this is an issue that you have to deal with. So now that the bug is known, I could live with it for really another 10 years. The important

RE: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread peter green
Well, dos.exec of course requires the entire command line as a shortstring. This is no problem for Dos because Dos has a maximum path length of 128 chars. so with 2 max length paths plus some options in the command line your screwed with shortstrings?

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread Marco van de Voort
an issue that you have to deal with. So now that the bug is known, I could live with it for really another 10 years. The important part is knowing this bug so I can work around it - if I hadn't figured this out I would have blamed all my problems on myself. yep silent string

RE: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread Daniël Mantione
Op Wed, 17 May 2006, schreef peter green: Well, dos.exec of course requires the entire command line as a shortstring. This is no problem for Dos because Dos has a maximum path length of 128 chars. so with 2 max length paths plus some options in the command line your screwed with

Re: [fpc-devel] dominant short strings in compiler source

2006-05-17 Thread L505
Well, dos.exec of course requires the entire command line as a shortstring. This is no problem for Dos because Dos has a maximum path length of 128 chars. so with 2 max length paths plus some options in the command line your screwed with shortstrings? Could happen, but also it might