On 09/06/10 15:50, Marcos Douglas wrote:
On Tue, Jun 8, 2010 at 3:44 PM, Luiz Americo Pereira Camara
wrote:
Marcos Douglas escreveu:
Exactly.
Therefore I always used 'const' only at 'strings' params. I thought it
had changed, but not. ;-)
It can be useful for record parame
On Tue, Jun 8, 2010 at 3:44 PM, Luiz Americo Pereira Camara
wrote:
> Marcos Douglas escreveu:
>> Exactly.
>> Therefore I always used 'const' only at 'strings' params. I thought it
>> had changed, but not. ;-)
>
> It can be useful for record parameters also
>
If the record have strings, I think.
Marcos Douglas escreveu:
On Tue, Jun 8, 2010 at 12:55 PM, Luiz Americo Pereira Camara
wrote:
Marcos Douglas escreveu:
Hi Luiz,
On Mon, Jun 7, 2010 at 10:35 PM, Luiz Americo Pereira Camara
wrote:
Take a look at
http://lazarusroad.blogspot.com/2008/11/effect-of-using-constant
On Tue, Jun 8, 2010 at 12:55 PM, Luiz Americo Pereira Camara
wrote:
> Marcos Douglas escreveu:
>>
>> Hi Luiz,
>>
>> On Mon, Jun 7, 2010 at 10:35 PM, Luiz Americo Pereira Camara
>> wrote:
>>
>>>
>>> Take a look at
>>>
>>> http://lazarusroad.blogspot.com/2008/11/effect-of-using-constant-parameter-f
Marcos Douglas escreveu:
Hi Luiz,
On Mon, Jun 7, 2010 at 10:35 PM, Luiz Americo Pereira Camara
wrote:
Take a look at
http://lazarusroad.blogspot.com/2008/11/effect-of-using-constant-parameter-for.html
Then, this continue true how I said in other mail:
On Mon, Jun 7, 2010 at 11:59 A
Hi Luiz,
On Mon, Jun 7, 2010 at 10:35 PM, Luiz Americo Pereira Camara
wrote:
>
> Take a look at
> http://lazarusroad.blogspot.com/2008/11/effect-of-using-constant-parameter-for.html
>
Then, this continue true how I said in other mail:
On Mon, Jun 7, 2010 at 11:59 AM, Marcos Douglas wrote:
> Al
Marcos Douglas escreveu:
Well... just to I will know. A long time ago (Delphi 4) I learned:
Always use 'const' for 'strings' because this is faster. Strings will
be passed by reference. This remains true?
eg:
var str: string;
procedure Foo1(const s: string);
procedure Foo2(s: string);
Ta
Hello FPC-Pascal,
Monday, June 7, 2010, 6:41:21 PM, you wrote:
>> Yes, but removing the "const" still passes the parameter as 16 bytes,
>> and defining it as "var" creates problems when passing an interface to
>> extract the GUID instead passing the interface reference. Anyway most
>> of this pro
On Mon, Jun 7, 2010 at 12:11 PM, Jonas Maebe wrote:
>
> On 07 Jun 2010, at 16:59, Marcos Douglas wrote:
>
>> Well... just to I will know. A long time ago (Delphi 4) I learned:
>> Always use 'const' for 'strings' because this is faster. Strings will
>> be passed by reference.
>
> It can be faster t
On 07 Jun 2010, at 17:11, José Mejuto wrote:
> Wow, that looks "dangerous" at least it should produce a warning when
> used in interfaces, or as safecall is a form of stdcall (with return
> values check) replace by stdcall.
Yes, probably. The reason was that nobody knew that this calling convent
On 07 Jun 2010, at 16:59, Marcos Douglas wrote:
Well... just to I will know. A long time ago (Delphi 4) I learned:
Always use 'const' for 'strings' because this is faster. Strings will
be passed by reference.
It can be faster to pass very short strings by value instead of by
reference. That
Hello FPC-Pascal,
Monday, June 7, 2010, 4:25:59 PM, you wrote:
>> It is "silently" changed by stdcall do not ?
JM> It is completely ignored. So it is the same as the default calling
JM> convention (which is register on i386, and stdcall=register=cdecl=...
JM> on other platforms).
Wow, that looks
On Mon, Jun 7, 2010 at 11:34 AM, Jonas Maebe wrote:
>
> On 07 Jun 2010, at 16:30, Marcos Douglas wrote:
>
>> 2010/6/7 Jonas Maebe :
>>>
>>> a) in Pascal, the behaviour of const is completely undefined (the
>>> compiler
>>> can do whatever it wants)
>>
>> The compiler can do whatever is wants?!
>
>
On 07 Jun 2010, at 16:30, Marcos Douglas wrote:
2010/6/7 Jonas Maebe :
a) in Pascal, the behaviour of const is completely undefined (the
compiler
can do whatever it wants)
The compiler can do whatever is wants?!
At the implementation level, yes.
Jonas
2010/6/7 Jonas Maebe :
>
> (...)
>
> In C, "const" does not modify how a parameter is passed in any way. If a
> parameter is passed by value without "const", then it's also passed by value
> with "const". The problems are
> a) in Pascal, the behaviour of const is completely undefined (the compiler
On 07 Jun 2010, at 15:59, José Mejuto wrote:
Monday, June 7, 2010, 10:34:26 AM, you wrote:
JM> safecall is not supported (= ignored) on non-Windows platforms,
JM> because it is completely Windows-specific. Afaik, GCC does not
support
JM> any safecall calling convention on Linux either.
It
Hello FPC-Pascal,
Monday, June 7, 2010, 10:34:26 AM, you wrote:
JM> safecall is not supported (= ignored) on non-Windows platforms,
JM> because it is completely Windows-specific. Afaik, GCC does not support
JM> any safecall calling convention on Linux either.
It is "silently" changed by stdcall
On 06 Jun 2010, at 19:28, José Mejuto wrote:
I had found the problem, after a lot of debuging and trying to
understand the underlayed COM interface the bug is in the mozilla
XPCOM or in the fpc undertanding of COM interfaces in Linux. Aside the
fact that under safecall in linux fpc does not cal
Hello FPC-Pascal,
Friday, June 4, 2010, 2:50:24 PM, you wrote:
>> JM> Maybe you are executing Pascal code in threads that have not been
[...]
>> Not, well, not at least on intention but maybe is the XPCOM which is
>> If that's the case is any kind of workaround ?
JM> No, it cannot be worked aroun
Hello FPC-Pascal,
Friday, June 4, 2010, 2:50:24 PM, you wrote:
>> Not, well, not at least on intention but maybe is the XPCOM which is
>> calling pascal code from a different thread :-? XPCOM tells me across
>> the documentation to call most of its functions from the main thread,
>> but maybe th
On 04 Jun 2010, at 14:03, José Mejuto wrote:
Hello FPC-Pascal,
Friday, June 4, 2010, 10:37:42 AM, you wrote:
JM> Maybe you are executing Pascal code in threads that have not been
JM> started via the FPC rtl? (i.e., not via beginthread nor via
JM> tthread.create) That is not supported on Unix
Hello FPC-Pascal,
Friday, June 4, 2010, 2:10:22 PM, you wrote:
>> If that's the case is any kind of workaround ? Callbacks are only 4 or
>> 5 functions +/- and maybe I can create another thread (in pascal) and
>> inquiry this thread to process the data and put result in some kind of
>> shared mem
On Fri, 4 Jun 2010, José Mejuto wrote:
Hello FPC-Pascal,
Friday, June 4, 2010, 10:37:42 AM, you wrote:
And this is the backtrace. Any idea ?
JM> Maybe you are executing Pascal code in threads that have not been
JM> started via the FPC rtl? (i.e., not via beginthread nor via
JM> tthread.cre
Hello FPC-Pascal,
Friday, June 4, 2010, 10:37:42 AM, you wrote:
>> And this is the backtrace. Any idea ?
JM> Maybe you are executing Pascal code in threads that have not been
JM> started via the FPC rtl? (i.e., not via beginthread nor via
JM> tthread.create) That is not supported on Unix platfo
On 04 Jun 2010, at 00:23, José Mejuto wrote:
Thursday, June 3, 2010, 6:51:22 PM, you wrote:
JM> Since the RTL is compiled with optimisation enabled, you may
JM> be missing intermediate stack frames. You will have to recompile
JM> it without optimisations to get a full backtrace.
Done, the hal
Hello FPC-Pascal,
Thursday, June 3, 2010, 6:51:22 PM, you wrote:
JM> Since the RTL is compiled with optimisation enabled, you may
JM> be missing intermediate stack frames. You will have to recompile
JM> it without optimisations to get a full backtrace.
Done, the halt is in fpc code:
---
On 03 Jun 2010, at 18:46, José Mejuto wrote:
> I was only able to set a break over _haltproc and it catches the exit
> with this backtrace:
>
> #0 0x082da470 in SI_C21__FPC_LIBC21_HALTPROC ()
> #1 0x080779d4 in SYSTEM_SYSTEM_EXIT ()
> #2 0x080700da in SYSTEM_DO_EXIT ()
> #3 0x080700fa in SYS
Hello FPC-Pascal,
Thursday, June 3, 2010, 3:31:31 PM, you wrote:
JM> You can try putting breakpoints on FPEXIT, _haltproc and _exit (the
JM> last one only exists if libc is linked, but that's definitely the case
JM> here; note that all of them are case-sensitive). That should catch
JM> most exits
On 03 Jun 2010, at 00:02, José Mejuto wrote:
Any idea
about how to debug the reason of the sudden stop ?
You can try putting breakpoints on FPEXIT, _haltproc and _exit (the
last one only exists if libc is linked, but that's definitely the case
here; note that all of them are case-sensitiv
Hello FPC-Pascal,
Thursday, June 3, 2010, 2:26:58 PM, you wrote:
>> Did you try disabling floating point exceptions? A lot of C code
>> assumes that floating point exceptions are disabled (since that's
>> what the C library does on startup).
JM> Another possible problem can be the fact that FPC
On 03 Jun 2010, at 10:08, Jonas Maebe wrote:
On 03 Jun 2010, at 08:55, Michael Van Canneyt wrote:
When I was debugging it (linux 64 bit) , the whole application
stopped on a floating point error somewhere in mozilla's Javascript
engine; I never got
around to debugging that.
Did you try
Hello FPC-Pascal,
Thursday, June 3, 2010, 8:55:47 AM, you wrote:
MVC> Are you cooperating with Phil on this ?
Just to keep the message in thread, I re-answer this message.
After a bit more debugging I found something strange (again it could
be fpc related or not, I'm not sure). This is the firs
On 03 Jun 2010, at 10:24, Michael Van Canneyt wrote:
On Thu, 3 Jun 2010, Jonas Maebe wrote:
On 03 Jun 2010, at 08:55, Michael Van Canneyt wrote:
When I was debugging it (linux 64 bit) , the whole application
stopped on a floating point error somewhere in mozilla's
Javascript engine; I ne
Hello FPC-Pascal,
Thursday, June 3, 2010, 10:24:43 AM, you wrote:
>> Did you try disabling floating point exceptions? A lot of C code assumes that
>> floating point exceptions are disabled (since that's what the C library does
>> on startup).
MVC> Aha. And how do I do that ?
Set8087CW($133F); ?
Hello FPC-Pascal,
Thursday, June 3, 2010, 10:08:00 AM, you wrote:
>> When I was debugging it (linux 64 bit) , the whole application
>> stopped on a floating point error somewhere in mozilla's Javascript
>> engine; I never got
>> around to debugging that.
JM> Did you try disabling floating point e
Hello FPC-Pascal,
Thursday, June 3, 2010, 8:55:47 AM, you wrote:
MVC> Are you cooperating with Phil on this ?
Yes. Phil is not supporting it now so I had added some improvements.
MVC> When I was debugging it (linux 64 bit) , the whole application stopped on a
MVC> floating point error somewhere
On Thu, 3 Jun 2010, Jonas Maebe wrote:
On 03 Jun 2010, at 08:55, Michael Van Canneyt wrote:
When I was debugging it (linux 64 bit) , the whole application stopped on a
floating point error somewhere in mozilla's Javascript engine; I never got
around to debugging that.
Did you try disabli
On 03 Jun 2010, at 08:55, Michael Van Canneyt wrote:
When I was debugging it (linux 64 bit) , the whole application
stopped on a floating point error somewhere in mozilla's Javascript
engine; I never got
around to debugging that.
Did you try disabling floating point exceptions? A lot of C
Hi,
Are you cooperating with Phil on this ?
When I was debugging it (linux 64 bit) , the whole application stopped on a
floating point error somewhere in mozilla's Javascript engine; I never got
around to debugging that.
Have you seen this error too, or does the .GetServiceByContractID stop
Hello FPC-Pascal,
I'm trying to make the Gecko engine port compile in Ubuntu. It
currently works in Win32 without problems, but in Ubuntu I had found a
strange problem that could be related to fpc or not.
Mozilla XPCOM is more or less based in COM interfaces, so in simple
words, the code loads th
40 matches
Mail list logo
