[fpc-pascal] Writing to a drive which may be spun down

[Brian]

Hi all,

Running Ubuntu 18 LTS, I have a console-mode number-cruncher which
writes occasional output files. It works just fine if the output is
directed to a drive which is permanently spun up, but can fail if the
output is directed to a USB drive (by which I mean a USB-connected 8TB
external drive, not one of the keydrives). I've followed things
through with the debugger, and it seems that the problem occurs when
the drive has powered itself down due to lack of accesses. The assign
and rewrite work OK, but then the first attempt to write to the file
fails with a 'No such file' error. Putting a large (30 second!) delay
before the first write means everything works OK, presumably because
the drive gets time to spin up again.

My question: Is there a standard method for handling this situation,
i.e. making sure that a drive has not spun down, or is it just a case
of writing a wrapper round the write function and handling the 'No
such file' error with a wait and a retry?

Thanks,

Brian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] get_caller_frame

[Sven Barth via fpc-pascal]

Am 20.11.2019 um 23:52 schrieb Ryan Joseph via fpc-pascal:



On Nov 20, 2019, at 1:56 AM, Sven Barth via fpc-pascal 
 wrote:

It returns the address of the caller's frame pointer. See also 
https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html

It's mainly used in context of raising exceptions with the help of a second 
function. See here: 
https://freepascal.org/docs-html/current/ref/refse112.html#x227-24900017.1


I guess I don't know what a frame pointer is. I thought it meant a pointer to 
the current stack frame and so I was curious if the RTL could include a way to 
copy the stack with the pointer and restore it later. Is that not how it works?
No. On x86 it's essentially the content of the EBP/RBP register which is 
(assuming no optimizations are done) essentially the ESP/RSP register of 
the calling function. This is only used by the exception handling to 
have the exception appear to be raised somewhere else.


The exception handling itself does not need it. The generic mechanism 
for example is a stack of exception frames (both except- and 
finally-blocks) and the exception handling code calls the handlers from 
top to bottom (thus executing explicit destructors (bla.Free) and 
implicit reference count decreases) before restoring the state using 
LongJmp (which also restores the original stack pointer register). The 
SEH and PSABIEH mechanisms that FPC supports work in a similar way (e.g. 
the SEH on Win32 is a single linked list).


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Add API to official documentation search

[Ryan Joseph via fpc-pascal]

> On Nov 20, 2019, at 5:25 AM, Anthony Walter via fpc-pascal 
>  wrote:
> 
> You said, "but its got bugs and I haven't been able to contact the developer 
> to fix them"
> 
> What are the bugs you want fixed? 

There you are. ;) There are stray tags which are messing things up. For example:

https://docs.getlazarus.org/?method=codesearch=xml=List

notice all the  tags that are breaking up the titles.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] get_caller_frame

[Ryan Joseph via fpc-pascal]

> On Nov 20, 2019, at 1:56 AM, Sven Barth via fpc-pascal 
>  wrote:
> 
> It returns the address of the caller's frame pointer. See also 
> https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html
> 
> It's mainly used in context of raising exceptions with the help of a second 
> function. See here: 
> https://freepascal.org/docs-html/current/ref/refse112.html#x227-24900017.1
> 

I guess I don't know what a frame pointer is. I thought it meant a pointer to 
the current stack frame and so I was curious if the RTL could include a way to 
copy the stack with the pointer and restore it later. Is that not how it works?

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] get_caller_frame

[Florian Klämpfl]

Am 20.11.19 um 07:56 schrieb Sven Barth via fpc-pascal:
Ryan Joseph via fpc-pascal > schrieb am Mi., 20. Nov. 2019, 
04:36:


I came across get_caller_frame  in some unrelated code and I was
just curious about this so I wanted to ask.

What does get_caller_frame return exactly? Is this a pointer to a
stack frame that could be copied to the heap? I'm still interested
in how we could add some form of coroutine like behaviors to pascal
and so I was wondering if we could copy/restore the current stack
pointer so that SetJmp and LongJmp would not blow things up.


It returns the address of the caller's frame pointer. See also 
https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html


It's mainly used in context of raising exceptions with the help of a 
second function. See here: 
https://freepascal.org/docs-html/current/ref/refse112.html#x227-24900017.1


For the record: the reliability of this function is limited, in 
particular in combination with optimization.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Add API to official documentation search

[Anthony Walter via fpc-pascal]

You said, "but its got bugs and I haven't been able to contact the
developer to fix them"

What are the bugs you want fixed?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal