Re: [fpc-pascal] Re: TFileStream and stdin - how to make this work?

2010-10-03 Thread Bernd Kreuss
On 03.10.2010 19:10, Seth Grover wrote:
> Could you use THandleStream
> (http://www.freepascal.org/docs-html/rtl/classes/thandlestream.html)?
> 
> myInputStream := THandleStream.Create(StdInputHandle);

Yea, this looks like what TIOStream internally seems to do. I have now
worked around the blocking issue by simply reading from the stream in a
separate thread.

I almost found the above myself (found something similar with google)
but I couldn't remember the name of the StdInputHandle constant i only
found a windows only example with something like STD_INPUT_HANDLE while
I was sitting on my Linux laptop at that moment.

(the final application will run on windows but i was doing some initial
experiments with TProcess and stdio while sitting at my linux machine)

Bernd
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TFileStream and stdin - how to make this work?

2010-10-03 Thread Bernd Kreuss
On 03.10.2010 16:16, Honza wrote:

> See also sockets:
> 
> http://wiki.lazarus.freepascal.org/Sockets
> 
> and pipes:
> 
> http://www.freepascal.org/docs-html/fcl/pipes/tinputpipestream.html
> 
> The TInputPipeStream has a "property NumBytesAvailable: DWord; [r]
> Number of bytes available for reading.", which may enable the polling.

I'm currently evaluating what is the easiest (least complicated) way of
communicating with a separate executable that is only used to display
some GUI forms to display some data and a few GUI elements to give input
to the main application. It is some kind of frontend to a process that
cannot have its own GUI (the other half of my code resides in a DLL and
i haven't found any *reliable* and robust way of creating a LCL GUI
directly from within this library because I have no control over the
application's main thread, all I have are function calls from the main
application on certain events that all come from different threads).

I have a (buggy) prototype that tries to create its own GUI thread in
the DLL and an ugly mess of QueueAsyncCall() to communicate with it and
a homemade event loop but it will still randomly crash ---> no idea why,
not reliable.

And I have another (already working) prototype which uses
tSimpleIPCServer and Client to communicate with a separately started
executable, this works quite nice but i thought i could make it even
easier and more compact.

Now I have a third prototype almost complete that uses TProcess to start
the exe from the dll and this is why I needed the stdio stuff. I have
now made a separate thread to listen on stdio and the synchronize()
stuff seems not so complicated as I initially thought. Overall I
currently like the TProcess/stdio method the most.

Bernd
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] How to get to Range Check Error location

2010-10-03 Thread Martin

 On 03/10/2010 21:20, Juha Manninen (gmail) wrote:

On Sunday 03 October 2010 19:48:22 C Western wrote:

Please report the bug. Yes the result is integer and in 64 bits, this
looks like a problem.

I think this is an issue I reported back in March, though I can now see
I uploaded the wrong patch for it

Sorry - meant to add: http://bugs.freepascal.org/view.php?id=16132

I reported it already earlier as issue
  #17537: Debugger: added a typecast to prevent a range check error

I added your issue as a duplicate. Our patches are different but both work
(although mine is shorter :-)

Anyway this is a good example of a valid Lazarus patch that is ignored, again.
:-(


CCed to lazarus list, as it's lazarus now.


Juha: did Marc say, he wanted it, or did you just assign it because it's 
debugger? (e.g. in the later, I don't mind taking it over)


btw: I would modify the shorter patch, and introduce a type (similar 
like there is PtrInt)

  TDbgPtrInt = 64

declared at the same location as TDbgPtr is declared => if someone 
changes TDbgPtr, then they should see (and change) the new type too.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] How to get to Range Check Error location

2010-10-03 Thread Juha Manninen (gmail)
On Sunday 03 October 2010 23:20:05 Juha Manninen (gmail) wrote:
> Anyway this is a good example of a valid Lazarus patch that is ignored,
> again.  :-(

Ok, sorry Lazarus guys, I must take this one back.
The valid patch was uploaded only today so it was not really ignored.

Now there are 2 valid patches to choose from.

Juha
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] How to get to Range Check Error location

2010-10-03 Thread Juha Manninen (gmail)
On Sunday 03 October 2010 19:48:22 C Western wrote:
> >> Please report the bug. Yes the result is integer and in 64 bits, this
> >> looks like a problem.
> > 
> > I think this is an issue I reported back in March, though I can now see
> > I uploaded the wrong patch for it
> 
> Sorry - meant to add: http://bugs.freepascal.org/view.php?id=16132

I reported it already earlier as issue 
 #17537: Debugger: added a typecast to prevent a range check error

I added your issue as a duplicate. Our patches are different but both work 
(although mine is shorter :-)

Anyway this is a good example of a valid Lazarus patch that is ignored, again. 
:-(


Juha
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Re: Delphi incompatible conditionals?

2010-10-03 Thread Marco van de Voort
In our previous episode, Mark Daems said:
> ...
> > Try longint(3) and longint(2).
> >
> 
> How should I do that? The place where the file containing the
> conditions is included doesn't allow for defining constants as it's
> the very first line in the unit code.

{$if ...   $FPCVERSION>LONGINT(3) }

See also Martin's solution, which essentially the same.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Fwd: Delphi incompatible conditionals?

2010-10-03 Thread Martin

 On 01/10/2010 17:33, Mark Daems wrote:

Hi,

I'm trying to add following conditional code to the top of a unit that
should compile in fpc and in delphi:

{$IFDEF FPC}
  {$IFNDEF ver1}
{$IF (fpc_version>2) or (fpc_version=2) and (fpc_release>3)}
  {$info FPC version>= 2.4.0 : Should work}
{$ELSE}
  {$warning FPC versions below 2.4 are not supported. However :
give it a try, you never know.}
{$IFEND}
  {$ELSE}
{$fatal FPC version 1 isn't supported at all}
  {$ENDIF}
{$ENDIF}

This seems to work well in fpc, however the delphi (7 and 2009)
compiler complains on the {$IF ...} line.
  [DCC Error] Zeos.inc(49): E2026 Constant expression expected
if you can put it after the uses clause (so you can have a const 
section, the following worked for me:

{$IFNDEF FPC}
const fpc_version=1; fpc_release=1;
{$ENDIF}
// your code below
{$IFDEF FPC}
 {$IFNDEF ver1}
   {$IF (fpc_version>2) or (fpc_version=2) and (fpc_release>3)}
 {$info FPC version >= 2.4.0 : Should work}
   {$ELSE}
 {$warning FPC versions below 2.4 are not supported. However :
give it a try, you never know.}
   {$IFEND}
 {$ELSE}
   {$fatal FPC version 1 isn't supported at all}
 {$ENDIF}
{$ENDIF}




Replacing the {$IF ...} line by
{$IF Defined(fpc_version) and ((fpc_version>2) or (fpc_version=2)
and (fpc_release>3))}
seems to solve the previous problem, however then the compiler outputs
this warning 4 times for every occurence of this code:
  [DCC Warning] Zeos.inc(49): W1023 Comparing signed and unsigned
types - widened both operands
   {$IF Defined(fpc_version) and ((fpc_version>word(2)) or 
(fpc_version=word(2)) and (fpc_release>word(3)))}


gets rid of the warnings

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Re: Delphi incompatible conditionals?

2010-10-03 Thread Felipe Monteiro de Carvalho
One solution would be putting the contents of the fpc specific ifdefs
inside a include file.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] Re: Delphi incompatible conditionals?

2010-10-03 Thread Mark Daems
> From: "Juha Manninen (gmail)" 
> To: "FPC-Pascal users discussions" 
> Date: Fri, 1 Oct 2010 20:04:18 +0300
> Subject: Re: [fpc-pascal] Fwd: Delphi incompatible conditionals?
> On Friday 01 October 2010 19:33:48 Mark Daems wrote:
>> ...
>> And it's a weird behaviour, because it's all within an {$IFDEF FPC}
>> construct. Why does delphi even try to interprete it?
>>
>> Somebody knows how to avoid the problem?
>
> Try this instead:
>
> {$IFNDEF FPC}
>  // Can be empty
> {$ELSE}
>  ...
> {$ENDIF}
>
> I got feedback for the Delphi converter in Lazarus about this same problem.
> Now the converter always adds IFNDEF instead of IFDEF to the code.
>
> Juha

Sorry Juha,
This doesn't help at all. Delphi keeps trying to interprete all {$IF
...} conditions in the file, even if it doesn't make sense because of
surrounding conditions.

> From: mar...@stack.nl (Marco van de Voort)
> To: FPC-Pascal users discussions 
> Date: Fri, 1 Oct 2010 19:52:36 +0200 (CEST)
> Subject: Re: [fpc-pascal] Fwd: Delphi incompatible conditionals?
> In our previous episode, Mark Daems said:
...
> Try longint(3) and longint(2).
>

How should I do that? The place where the file containing the
conditions is included doesn't allow for defining constants as it's
the very first line in the unit code. Even before the uses clause in
the interface section. Actually the problem is Delphi doesn't find the
constant definitions, so it's guessing the data type of fpc_version
and fpc_release.

> Still, it might be worth a report, otherwise stuff never gets fixed. And
> that goes both for FPC and Delphi :-)

This isn't an FPC bug at all. FPC handles this exactly as expected.
Unless they invent some new FPC only version checking directive
allowing for syntax like {$IFVERSION < 2.4}...{$ENDIFVERSION},
{$IFVERSION 2.4}...{$ENDIFVERSION} and {$IFVERSION
2}...{$ENDIFVERSION}
That would solve the Delphi problem completely as no {$IF} with
constants is involved anymore. Provided you can make sure all old fpc
versions get this behaviour as well. Which brings us back to ...
impossible to solve.

Thanks for trying to resolve this issue, but I think I'll add the
checks to the top of the fpc packages files. In that case only Lazarus
will see them, but people using the units directly in fpc will not get
the message...

Mark
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] Re: TFileStream and stdin - how to make this work?

2010-10-03 Thread Seth Grover
See ./packages/fcl-base/examples/asiotest.pp in the FPC source. Also,
google turned up: achenko.narod.ru/stdin2file.pas which seems to be
something like what you're looking to do.

-SG

--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.

Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] Re: TFileStream and stdin - how to make this work?

2010-10-03 Thread Seth Grover
Could you use THandleStream
(http://www.freepascal.org/docs-html/rtl/classes/thandlestream.html)?

myInputStream := THandleStream.Create(StdInputHandle);
...

-SG

--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.

Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] How to get to Range Check Error location

2010-10-03 Thread C Western

On 10/03/2010 05:36 PM, C Western wrote:

On 10/03/2010 04:48 PM, José Mejuto wrote:

Hello FPC-Pascal,

Sunday, October 3, 2010, 9:10:34 AM, you wrote:

JMg> Lazarus Debugger code causes one range error which can be fixed
with a
JMg> typecast. FPC showed the point clearly. Issue #0017537.
JMg> TApplication.HandleException Range check error
JMg> Stack trace:
JMg> $0115AA93 line 1541 of ../debugger/gdbmidebugger.pp
JMg> $00786075
JMg> $011678C7 line 3884 of ../debugger/gdbmidebugger.pp
JMg> $00E53D13 line 1819 of ../debugger/debugger.pp
JMg> ...

Please report the bug. Yes the result is integer and in 64 bits, this
looks like a problem.



I think this is an issue I reported back in March, though I can now see
I uploaded the wrong patch for it

Sorry - meant to add: http://bugs.freepascal.org/view.php?id=16132



Colin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] How to get to Range Check Error location

2010-10-03 Thread C Western

On 10/03/2010 04:48 PM, José Mejuto wrote:

Hello FPC-Pascal,

Sunday, October 3, 2010, 9:10:34 AM, you wrote:

JMg>  Lazarus Debugger code causes one range error which can be fixed with a
JMg>  typecast. FPC showed the point clearly. Issue #0017537.
JMg>  TApplication.HandleException Range check error
JMg>Stack trace:
JMg>$0115AA93 line 1541 of ../debugger/gdbmidebugger.pp
JMg>$00786075
JMg>$011678C7 line 3884 of ../debugger/gdbmidebugger.pp
JMg>$00E53D13 line 1819 of ../debugger/debugger.pp
JMg>  ...

Please report the bug. Yes the result is integer and in 64 bits, this
looks like a problem.



I think this is an issue I reported back in March, though I can now see 
I uploaded the wrong patch for it


Colin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re[2]: [fpc-pascal] How to get to Range Check Error location

2010-10-03 Thread José Mejuto
Hello FPC-Pascal,

Sunday, October 3, 2010, 11:41:00 AM, you wrote:

GG> On 02/10/2010, Vincent Snijders  wrote:
>>
>> True heap size : 1048576
>> True free heap : 1924768
>> Should be : 1048576
>>
>> It just says that heaptr didn't calculate the True free heap size correctly.

GG> Either way, this should then be reported as a bug - though a minor one
GG> because unfree'ed count is correct (zero).

I could be wrong, but it seems caused because heaptrc can only control
memory blocks allocated after its initialization, so any memory
allocated before can not be counted as right or wrong.

-- 
Best regards,
 José

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re[2]: [fpc-pascal] How to get to Range Check Error location

2010-10-03 Thread José Mejuto
Hello FPC-Pascal,

Sunday, October 3, 2010, 9:10:34 AM, you wrote:

JMg> Lazarus Debugger code causes one range error which can be fixed with a
JMg> typecast. FPC showed the point clearly. Issue #0017537.
JMg> TApplication.HandleException Range check error
JMg>   Stack trace:
JMg>   $0115AA93 line 1541 of ../debugger/gdbmidebugger.pp
JMg>   $00786075
JMg>   $011678C7 line 3884 of ../debugger/gdbmidebugger.pp
JMg>   $00E53D13 line 1819 of ../debugger/debugger.pp
JMg> ...

Please report the bug. Yes the result is integer and in 64 bits, this
looks like a problem.

-- 
Best regards,
 José

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TFileStream and stdin - how to make this work?

2010-10-03 Thread Honza
2010/10/3 Bernd Kreuss :
> TIOStream seems to work the same way on linux and windows (I tested only
> with wine but it worked) ...and it will block.
>
> It seems I really have to do the receiving of the data in a separate
> thread.
>
> (I wanted to avoid this because the things that must be done after
> reading the data must be done in the main thread (it's a GUI
> application) and now I have to fiddle around with synchronize & friends
> instead of a simple method call which is not nice because I also have to
> immediately answer the messages on stdout in a synchronous manner with
> information received from the GUI. Polling on idle from the GUI thread
> would have been so much more simple and elegant.)

See also sockets:

http://wiki.lazarus.freepascal.org/Sockets

and pipes:

http://www.freepascal.org/docs-html/fcl/pipes/tinputpipestream.html

The TInputPipeStream has a "property NumBytesAvailable: DWord; [r]
Number of bytes available for reading.", which may enable the polling.

-- 
bflm
freepascal-bits.blogspot.com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TFileStream and stdin - how to make this work?

2010-10-03 Thread Bernd Kreuss
On 03.10.2010 15:21, Andreas Schneider wrote:
> You could use TIOStream from the unit iostream. AFAICS that should do
> exactly what you want - i.e. opening stdin/out/err as a TStream
> descendant.
> I don't know however, if that fixes the problem you have with the
> stream blocking when nothing is to be read.

TIOStream seems to work the same way on linux and windows (I tested only
with wine but it worked) ...and it will block.

It seems I really have to do the receiving of the data in a separate
thread.

(I wanted to avoid this because the things that must be done after
reading the data must be done in the main thread (it's a GUI
application) and now I have to fiddle around with synchronize & friends
instead of a simple method call which is not nice because I also have to
immediately answer the messages on stdout in a synchronous manner with
information received from the GUI. Polling on idle from the GUI thread
would have been so much more simple and elegant.)

Bernd
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TFileStream and stdin - how to make this work?

2010-10-03 Thread Andreas Schneider

On Sun, 03 Oct 2010 15:05:10 +0200, Bernd Kreuss
 wrote:
> Hi,
> 
> this might be a stupid question but I find myself again struggling with
> file IO and stdin/stdout. I am trying to do the following:
> 
> StdIn := TFileStream.Create('/dev/stdin', fmOpenRead);
> 
> and later on i want to poll whether there is something to read. I want
> to try reading binary data that will be piped to my application and i
> need to poll (non blocking!) and in case of incoming data read the first
> byte to determine the type of message that has arrived and then read the
> rest.
> 
> The Stream seems to be able to read when there is something to read on
> stdin but I cannot find any way to actually test whether the ReadByte()
> will block (nothing to read) or whether there is data available.
> 
> the properties size and position both are always $ and
> the stream has no eof property.
> 
> Can this be done at all? And is my way of opening the stream correct?
> What would be a more platform independent way of opening the stdin as a
> stream to read binary data or is there a different and better way to do
> this, maybe a stream is not the correct thing for this at all? How do I
> poll and read binary data from stdin?
> 
> Bernd

You could use TIOStream from the unit iostream. AFAICS that should do
exactly what you want - i.e. opening stdin/out/err as a TStream
descendant.
I don't know however, if that fixes the problem you have with the
stream blocking when nothing is to be read. If nothing else helps I
guess you could use a thread to read the data from stdin, then it
shouldn't matter if it blocks.

Best regards,
Andreas.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TFileStream and stdin - how to make this work?

2010-10-03 Thread Honza
2010/10/3 Bernd Kreuss :
> this might be a stupid question but I find myself again struggling with
> file IO and stdin/stdout. I am trying to do the following:
>
> StdIn := TFileStream.Create('/dev/stdin', fmOpenRead);
>
> and later on i want to poll whether there is something to read. I want
> to try reading binary data that will be piped to my application and i
> need to poll (non blocking!) and in case of incoming data read the first
> byte to determine the type of message that has arrived and then read the
> rest.
>
> The Stream seems to be able to read when there is something to read on
> stdin but I cannot find any way to actually test whether the ReadByte()
> will block (nothing to read) or whether there is data available.
>
> the properties size and position both are always $ and
> the stream has no eof property.
>
> Can this be done at all? And is my way of opening the stream correct?
> What would be a more platform independent way of opening the stdin as a
> stream to read binary data or is there a different and better way to do
> this, maybe a stream is not the correct thing for this at all? How do I
> poll and read binary data from stdin?

I don't think it's possible to succeed in this using TFileStream.
Additionally, the stdin thing on *nix is IMO designed to be normally
used in a blocking manner.

OTOH, it's likely, that on *nix you can find some syscall/libc
functionality, which will provide the "file descriptor is ready for
reading" information. But you asked for platform independence and I
don't know much about Windows. Neither if there is or is not something
like that being cross platform somewhere in the RTL/FCL already.

-- 
bflm
freepascal-bits.blogspot.com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] TFileStream and stdin - how to make this work?

2010-10-03 Thread Bernd Kreuss
Hi,

this might be a stupid question but I find myself again struggling with
file IO and stdin/stdout. I am trying to do the following:

StdIn := TFileStream.Create('/dev/stdin', fmOpenRead);

and later on i want to poll whether there is something to read. I want
to try reading binary data that will be piped to my application and i
need to poll (non blocking!) and in case of incoming data read the first
byte to determine the type of message that has arrived and then read the
rest.

The Stream seems to be able to read when there is something to read on
stdin but I cannot find any way to actually test whether the ReadByte()
will block (nothing to read) or whether there is data available.

the properties size and position both are always $ and
the stream has no eof property.

Can this be done at all? And is my way of opening the stream correct?
What would be a more platform independent way of opening the stdin as a
stream to read binary data or is there a different and better way to do
this, maybe a stream is not the correct thing for this at all? How do I
poll and read binary data from stdin?

Bernd
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Build scripts for Freepascal and Lazarus compilation from source

2010-10-03 Thread Frank Church
On 3 October 2010 10:48, Honza  wrote:

> 2010/10/3 Frank Church :
> > I have posted an article and some code on some bash scripts I have
> developed
> > to install FPC and Lazarus from source at
> >
> http://devblog.brahmancreations.com/content/build-scripts-for-installing-freepascal-and-lazarus-from-source
> .
> >
> > Any comments and tips are well come.
>
> Oops:
>
> Access denied
> You are not authorized to access this page.
>
>
I've fixed it now.

A few minor improvements are coming.

--
> bflm
> freepascal-bits.blogspot.com
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>



-- 
Frank Church

===
http://devblog.brahmancreations.com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build scripts for Freepascal and Lazarus compilation from source

2010-10-03 Thread Honza
2010/10/3 Frank Church :
> I have posted an article and some code on some bash scripts I have developed
> to install FPC and Lazarus from source at
> http://devblog.brahmancreations.com/content/build-scripts-for-installing-freepascal-and-lazarus-from-source.
>
> Any comments and tips are well come.

Oops:

Access denied
You are not authorized to access this page.

-- 
bflm
freepascal-bits.blogspot.com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] How to get to Range Check Error location

2010-10-03 Thread Graeme Geldenhuys
On 02/10/2010, Vincent Snijders  wrote:
>
> True heap size : 1048576
> True free heap : 1924768
> Should be : 1048576
>
> It just says that heaptr didn't calculate the True free heap size correctly.

Either way, this should then be reported as a bug - though a minor one
because unfree'ed count is correct (zero).


-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net:8080/fpgui/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] Build scripts for Freepascal and Lazarus compilation from source

2010-10-03 Thread Frank Church
I have posted an article and some code on some bash scripts I have developed
to install FPC and Lazarus from source at
http://devblog.brahmancreations.com/content/build-scripts-for-installing-freepascal-and-lazarus-from-source
.

Any comments and tips are well come.

-- 
Frank Church

===
http://devblog.brahmancreations.com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get to Range Check Error location

2010-10-03 Thread Juha Manninen (gmail)
On Saturday 02 October 2010 17:47:27 José Mejuto wrote:
> The assembly window in Lazarus is shown when no backtrace line is
> available to point the cursor in, so open callstack "View -> Debug ->
> Callstack" and you will see that there is no available backtrace,
> maybe except the fpc sources without debug information (you will see
> some, usually 3, function names). The backtrace is often damaged when
> memory corruption happends and usually calling a non initialized
> object and not nil of course (as freed objects with heaptrc are
> signaled with a magic number).

Right. I finally found some errors.

One was a real error in my code, freeing an object twice, which happened 
seldom. For some reason Lazarus could not take me to its source line either. 
FPC output showed the place one level up in the call stack.

Lazarus Debugger code causes one range error which can be fixed with a 
typecast. FPC showed the point clearly. Issue #0017537.

TApplication.HandleException Range check error
  Stack trace:
  $0115AA93 line 1541 of ../debugger/gdbmidebugger.pp
  $00786075
  $011678C7 line 3884 of ../debugger/gdbmidebugger.pp
  $00E53D13 line 1819 of ../debugger/debugger.pp
...

I think this is a Lazarus specific problem but I always get RunError(216) 
window when there is a range error. Sometimes I get a SIGSEGV window, too, 
while there is only a range error.

Juha
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal