Re: [fpc-pascal] Clueless here
Darius Blaszijk wrote:
> Hi,
>
> I have two overloaded functions. One overloaded function just rearanges
> one parameter from an array of extended to an array of ^extended and
> calls the other overloaded function. The problem is however that the 2nd
> function call crashes the app. I really have no idea why therefore I'm
> posting the code in the hope someone with more insight can help me here.
>
> So what happens is the following; the first debugmessages are ok and as
> expected. However the second debugmessages (array of PJmFloat) crash the
> application. I have attached the backtrace.
>
> Darius
>
> type
> TJmFloat = extended;
> PJmFloat = ^TJmFloat;
> TDynTJmFloatArray = array of TJmFloat;
>
> Function FitSession( Parameters : array of PJmFloat; ChiSquareFunc :
> TOFitFunc ) : IFit;
> var i: integer;
> begin
> //debug only
> for i := 0 to High(Parameters) do
> ShowMessage('array of PJmFloat ' + FloatToStr(Parameters[i]^));
>
> Result := TFit.Create( Parameters, ChiSquareFunc );
> end;
>
> function FitSession(Parameters: TDynTJmFloatArray; ChiSquareFunc:
> TOFitFunc): IFit;
> var
> Params: array of PJmFloat;
> i: integer;
> begin
> SetLength(Params, Length(Parameters));
>
> for i := 0 to High(Parameters) do
> begin
> Params[i] := AllocMem(SizeOf(TJmFloat));
> Params[i] := @Parameters[i];
Don't you want to write here
Params[i]^ := Parameters[i];
?
> end;
>
> //debug only
> for i := 0 to High(Params) do
> ShowMessage('TDynTJmFloatArray ' + FloatToStr(Params[i]^));
>
> Result := FitSession(Params, ChiSquareFunc);
> end;
> begin
> SetLength(c, 2);
> c[0] := 2;
> c[1] := 0.2;
> Fit := FitSession(c, @ChiSquareFunc);
> end;
>
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[3]: [fpc-pascal] Code example needed, please!
From: Пётр Косаревский<[EMAIL PROTECTED]>
To: FPC-Pascal users discussions
Subject: Re[2]: [fpc-pascal] Code example needed, please!
> I have code only with window messages and shared memory (if you don't want
> it, tell; otherwise I'll post some about an hour later).
I used something like that for shared memory in Delphi
ShMemFile is THandle, ShMemBuf is Pointer.
ShMemFile := CreateFileMapping(
INVALID_HANDLE_VALUE, <-- this creates file somewhere in
memory or swapfile
nil,
PAGE_READWRITE,
0,
ShMemSize, <-- set what you need
ShMemName); <-- this name will be used by the backend too!!
try to make it unique string, you can set it as command line parameter for
backend
if (ShMemFile=0) or (ShMemFile=INVALID_HANDLE_VALUE) then
begin Application.MessageBox('Shared memory error 1.','Internal
error',MB_OK); Close(); end;
ShMemBuf := MapViewOfFile(ShMemFile, FILE_MAP_ALL_ACCESS, 0, 0, 0);
if (ShMemBuf=nil) then
begin Application.MessageBox('Shared memory error 2.','Internal
error',MB_OK); CloseHandle(ShMemFile); Close(); end;
{}
ShMemP:=ShMemBuf;
Where ShMemP is pointer to array[0..ShMemSize-1] of byte, so that you can
address bytes as ShMemP^[x] (somewhat lame).
And in the backend:
The types of ShMemFile and ShMemBuf are as in Delphi
ShMemFile := OpenFileMapping(
FILE_MAP_ALL_ACCESS,
false,
ShMemName);
if (ShMemFile=0) or (ShMemFile=INVALID_HANDLE_VALUE) then
begin writeln('File open failed!'); ASS_BACK(MsgFileReady); end;
ShMemBuf := MapViewOfFile(ShMemFile, FILE_MAP_ALL_ACCESS, 0, 0, 0);
if ShMemBuf=nil then
begin writeln('File open failed!'); ASS_BACK(MsgFileReady); end;
ShMemBytes:=ShMemBuf;
Where ShMemBytes is byte pointer (so you address bytes as ShMemBytes[x]).
This code creates one chunk of shared memory of ShMemSize size. I used about
64K. Probably, anything up to gigabyte will work, but may be slow.
All these functions are described in MSDN, the only thing not nice is that you
have to guess some default values and pascal types (it's the same in Delphi
help: the examples are in C, if I remember right).
If you plan sending window messages, I can send some working code (ask). There
are examples (for Delphi) in internet on sites like
http://delphi.about.com/od/windowsshellapi/l/aa093003a.htm.
Of course, all the functions are described in MSDN.
There are simple hints: the window handle is Application.handle (you can send
it to backend, so that the dialog will not be broadcast from the beginning,
also you have to write message hookers in both programs [and create dummy
window in FPC one], if you want them to not freeze for some time, use the
functions windows.peekmessage, windows.postmessage, windows.translatemessage,
windows.dispatchmessage; if I remember right, one of them could have name
conflict with something in another unit).
If you want some little fun, broadcast WM_KILL message.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ExitProc
Michael Van Canneyt wrote: > On Thu, 29 Jun 2006, Jonas Maebe wrote: >> On 29 jun 2006, at 13:51, Carsten Bager wrote: >> >>> If I compile and run my example program and then press Crtl+C the >>> program terminates. I would expect that it terminate by calling >>> "CloseServer" procedure, but it dos not. If the program terminates >>> normally (time runs out) the "CloseServer" procedure is called as >>> expected. >>> >>> Have I misunderstood something about the ExitProc. >> >> ExitProc is only called if your program exits via the RTL. This is the >> case >> when the program exits normally, or when a run time error or unhandled >> exception occurs. >> >> ctrl-c is not caught by the FPC RTL. This means it is handled by the >> operating system, and the default action of the operating system is to >> simply >> terminate the process. The FPC RTL therefore does not get any chance to >> call >> your exitproc. >> >> I don't know whether there's a platform-independent way in the RTL to >> turn on >> the catching of ctrl-c (and converting it to an exception or run time >> error). > > Not that I am aware of... Well, unit Crt should allow it if implemented properly (i.e. compatible to TP/BP - at least IIRC)... ;-) Not that we'd have such an implementation at the moment, though. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: findfirst and findnext on non accessible files
Am Donnerstag, den 29.06.2006, 09:12 +0200 schrieb Marco van de Voort: > > On 28 Jun 06, at 23:41, Marc Santhoff wrote: > > > Am Mittwoch, den 28.06.2006, 12:17 -0500 schrieb Jeff Pohlmeyer: > > . > > . > > > What I don't understand is why the var "errno" is not set or it's value > > > is destroyed before Findfirst/-Next return. Does this value has to be > > > set explicitely by using fpseterrno()? It returns always -1 in case of > > > permission denied. > > > > My opinion is that SysUtils.FindFirst should > > return 5 in case of an error; "errno" is not > > portable, whereas SysUtils is supposed to support > > portable code. I think so, too. Since nowadays even Windows (2000/XP) has a concept of user permissions, this would be at least nice to have. > (that is not really the problem, OS errorcodes can be hauled with > getlastoserror, which is errno on *nix) I see, I did not know "getlastoserror". But it calls fpGetErrNo in term and this value is not usable: program unixerr; uses sysutils; var SR: TSearchRec; begin FindFirst (ParamStr ( 1 ), faAnyFile, SR); writeln(getlastoserror); FindClose (SR); end. $ ./unixerr /usr/X11R6/include/ 2 $ ./unixerr /usr/X11R6/include/nvu-1.0/ -1 $ ll /usr/X11R6/include/nvu-1.0/ ls: : Permission denied $ ll -F /usr/X11R6/include/ | grep / | grep nvu drwx-- 104 root wheel8192 6 Okt 2005 nvu-1.0/ That brings us back to the start. My only question right now: How can i detect if sysutils.FindFirst() or FindNext() fails lacking permissions? TIA, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Nice website
Graeme Geldenhuys wrote: > It doesn't remember that setting for me as well. The only thing I can > think of, is if the website used cookies to store the pagestyle for > the user. I am no web programmer, so don't take my word for it. :) That's a hack IMHO, and can only work for dynamic websites. The main freepascal page is static html. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Nice website
It doesn't remember that setting for me as well. The only thing I can think of, is if the website used cookies to store the pagestyle for the user. I am no web programmer, so don't take my word for it. :) Regards, - Graeme - On 6/29/06, Micha Nelissen <[EMAIL PROTECTED]> wrote: Do you also know a way for it to remember this choice for a website ? At least, it doesn't remember for me. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] Code example needed, please!
Oh. I didn't succeed with pipes. But you can use exchange via files (so that frontend will tell parameter like user in command line). Or (a worse idea) use special parameter to tell, that the frontend is calling (well, it's not separating, it's rather hiding from user). I have code only with window messages and shared memory (if you don't want it, tell; otherwise I'll post some about an hour later). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ExitProc
On Thu, 29 Jun 2006, Jonas Maebe wrote: On 29 jun 2006, at 13:51, Carsten Bager wrote: If I compile and run my example program and then press Crtl+C the program terminates. I would expect that it terminate by calling "CloseServer" procedure, but it dos not. If the program terminates normally (time runs out) the "CloseServer" procedure is called as expected. Have I misunderstood something about the ExitProc. ExitProc is only called if your program exits via the RTL. This is the case when the program exits normally, or when a run time error or unhandled exception occurs. ctrl-c is not caught by the FPC RTL. This means it is handled by the operating system, and the default action of the operating system is to simply terminate the process. The FPC RTL therefore does not get any chance to call your exitproc. I don't know whether there's a platform-independent way in the RTL to turn on the catching of ctrl-c (and converting it to an exception or run time error). Not that I am aware of... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Nice website
Graeme Geldenhuys wrote: > If you are using Mozilla Firefox, do the following... > View -> Page Style -> Nav-Left Do you also know a way for it to remember this choice for a website ? At least, it doesn't remember for me. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Nice website
Oh yeah! :) A good thing you told it; I would have never know. 2006/6/29, Graeme Geldenhuys <[EMAIL PROTECTED]>: On 6/29/06, Jesús Reyes A. <[EMAIL PROTECTED]> wrote: > Nice, but a question, why is the menu on the right side?. After years and > years of looking web pages one get uset to look at whatever the second If you are using Mozilla Firefox, do the following... View -> Page Style -> Nav-Left This will move the menu's to the left. I am no graphics artist, but I think it looks better on the right. -- Alexandre Leclerc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ExitProc
On 29 jun 2006, at 13:51, Carsten Bager wrote: If I compile and run my example program and then press Crtl+C the program terminates. I would expect that it terminate by calling "CloseServer" procedure, but it dos not. If the program terminates normally (time runs out) the "CloseServer" procedure is called as expected. Have I misunderstood something about the ExitProc. ExitProc is only called if your program exits via the RTL. This is the case when the program exits normally, or when a run time error or unhandled exception occurs. ctrl-c is not caught by the FPC RTL. This means it is handled by the operating system, and the default action of the operating system is to simply terminate the process. The FPC RTL therefore does not get any chance to call your exitproc. I don't know whether there's a platform-independent way in the RTL to turn on the catching of ctrl-c (and converting it to an exception or run time error). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] ExitProc
If I compile and run my example program and then press Crtl+C the
program terminates. I would expect that it terminate by calling
"CloseServer" procedure, but it dos not. If the program terminates
normally (time runs out) the "CloseServer" procedure is called as
expected.
Have I misunderstood something about the ExitProc.
Regards Carsten
program exitp;
Uses sysutils;{System}
var
ExitProcGem:pointer;
Procedure CloseServer;
Begin
ExitProc:=ExitProcGem;
WriteLn('Server closed.');
End;
begin
ExitProcGem:=ExitProc;
ExitProc:[EMAIL PROTECTED];
sleep(1);
WriteLn('--Close--');
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Code example needed, please!
Hello! Thank you very much for your answer. It is not that complicated as you possibly assume. It is primarily an execution of four very little programs which will run less than 1 second, each. (compiler, optimizer, linker, assembler). The primary point is that the textmode-backend is fully hidden and that its output can be shown embedded in the delphi app, nothing more. Shared memory is a little bit problematic because I want to completely separate the backend from the frontend. The backend must also work without a frontend in a command line mode, so I can only use StdIO and command line args for controlling it. | Well, I have written such a program (Delphi-FPC) not very long ago. I can't | provide it as an example (and it is not very little), but I can describe | necessary steps and provide code bits. Great! Code bits are very welcome! Ing. Rainer Hantsch ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] RE: Nice website
> This will move the menu's to the left. I am no graphics artist, but I > think it looks better on the right. > Regards, > - Graeme - Yes, website looks new and polished. I personally prefer darker-softer colors that were there before, but it is definitely great, that someone does change the design: it makes the website alive. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Code example needed, please!
> A friend of me wants to write a program which uses a GUI frontend and a > "backend", which actually does the work. > The reason is that the backend shall also be usable from the command line, > without any GUI, to make it working on more platforms without having to make > changes on it. So it will be the best to compile it in FPC for the related > OS, with a minimum of OS dependices. > My idea is to write the backend in FPC. It shall only use StdIn/StdOut and > also parse its command line options. The Frontend shall be - in a first step - > be written in Delphi or Lazarus, but because I ask here for a friend who > currently uses Delphi, this would be preferred. > My question is: > Can somebody show me a little sample program for that? Well, I have written such a program (Delphi-FPC) not very long ago. I can't provide it as an example (and it is not very little), but I can describe necessary steps and provide code bits. > It will be enough (for the Delphi-part) to open a window with a textbox and a > button. When the button is clicked, the backend shall be loaded, some text be > piped into it, and that what comes out from the backend's stdout shall be > displayed in the textbox. Nothing more. > The backend may be a plain FPC program (no delphi), reading from StdIn, making > i.e. everything to UpperCase, then write this out to its StdOut. > If somebody, please, could show me how this is done in Windows, please? > Ing. Rainer Hantsch Shame on me, but I have given up using pipes. They are not reliable in my opinion. I used (of course, you can use command line parameters and files: frontend creates "param.txt", runs "backend.exe param.txt" and waits for output.txt to be created; no need to keep in mind something system specific) windows messages (and you have to create invisible dummy window for backend) and shared memory. For your example it's possible (but it is windows specific) for frontend: to create shared memory in frontend, zero the first byte of it and start backend (with parameters, if needed). When the button is pressed, the needed parameters and data are written to shared memory and after that frontend flips the switch (changes the first byte from zero to something else). After that the frontend periodically inspects that first byte value, and when the value is zero again, reads the output from shared memory. for backend: to open shared memory (file), periodically inspect the first byte, read the parameters and data when the first byte becomes nonzero, process them, write output, change the first byte, close everything and die. If it suits your needs, I can point you to the sources in the net and/or provide my code bits. PS. I wanted to rewrite ipc unit for windows, so that this task will become less system specific, but didn't succeed: not enough time and confidence*experience; also I don't really know, how it works under linux. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Code example needed, please!
Hello! A friend of me wants to write a program which uses a GUI frontend and a "backend", which actually does the work. The reason is that the backend shall also be usable from the command line, without any GUI, to make it working on more platforms without having to make changes on it. So it will be the best to compile it in FPC for the related OS, with a minimum of OS dependices. My idea is to write the backend in FPC. It shall only use StdIn/StdOut and also parse its command line options. The Frontend shall be - in a first step - be written in Delphi or Lazarus, but because I ask here for a friend who currently uses Delphi, this would be preferred. My question is: Can somebody show me a little sample program for that? It will be enough (for the Delphi-part) to open a window with a textbox and a button. When the button is clicked, the backend shall be loaded, some text be piped into it, and that what comes out from the backend's stdout shall be displayed in the textbox. Nothing more. The backend may be a plain FPC program (no delphi), reading from StdIn, making i.e. everything to UpperCase, then write this out to its StdOut. If somebody, please, could show me how this is done in Windows, please? mfg Ing. Rainer Hantsch ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: findfirst and findnext on non accessible files
Marco van de Voort wrote: >> Marco van de Voort wrote: >> > >> > (that is not really the problem, OS errorcodes can be hauled with >> > getlastoserror, which is errno on *nix) >> >> Well, it is a problem, because not returning the error code directly in >> return value violates SysUtils.FindFirst specification and most probably >> Delphi compatibility too. . . > But in general findfirst should be ok, otoh it should mostly just report > success or fail, and not specify too much about the reasons, since that > would make findfirst possibily OS specific. Well, I'm still of different opinion. The basic set of error codes should be shared on FindFirst level (BTW as opposed to GetLastError, which clearly returns last OS error and thus is not portable). I consider at least the following to belong to this basic set (in this particular case): - No more files (18) - Path not found (3) - Access denied (5) I might have forgotten other important ones (writing this from the top of my head on the way from Frankfurt to Bonn). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: findfirst and findnext on non accessible files
> Marco van de Voort wrote: > > > > (that is not really the problem, OS errorcodes can be hauled with > > getlastoserror, which is errno on *nix) > > Well, it is a problem, because not returning the error code directly in > return value violates SysUtils.FindFirst specification and most probably > Delphi compatibility too. Depends on what we are talking about. I was replying in the context of the infinite symlink problem, which is a unix specific problem. If you are not, I might have mixed up subthreads. But in general findfirst should be ok, otoh it should mostly just report success or fail, and not specify too much about the reasons, since that would make findfirst possibily OS specific. The whole "GLOB" sublevel is not that needed anymore anyway. It was originally meant to avoid a (readdir) syscall per file read, but both freebsd and linux now already buffer at the readdir level (and Darwin, since it uses libc probably too) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: findfirst and findnext on non accessible files
Marco van de Voort wrote: >> On 28 Jun 06, at 23:41, Marc Santhoff wrote: >> > Am Mittwoch, den 28.06.2006, 12:17 -0500 schrieb Jeff Pohlmeyer: >> . >> . >> > What I don't understand is why the var "errno" is not set or it's >> value >> > is destroyed before Findfirst/-Next return. Does this value has to be >> > set explicitely by using fpseterrno()? It returns always -1 in case of >> > permission denied. >> >> My opinion is that SysUtils.FindFirst should >> return 5 in case of an error; "errno" is not >> portable, whereas SysUtils is supposed to support >> portable code. > > (that is not really the problem, OS errorcodes can be hauled with > getlastoserror, which is errno on *nix) Well, it is a problem, because not returning the error code directly in return value violates SysUtils.FindFirst specification and most probably Delphi compatibility too. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Nice website
On 6/29/06, Jesús Reyes A. <[EMAIL PROTECTED]> wrote: Nice, but a question, why is the menu on the right side?. After years and years of looking web pages one get uset to look at whatever the second If you are using Mozilla Firefox, do the following... View -> Page Style -> Nav-Left This will move the menu's to the left. I am no graphics artist, but I think it looks better on the right. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: findfirst and findnext on non accessible files
> On 28 Jun 06, at 23:41, Marc Santhoff wrote: > > Am Mittwoch, den 28.06.2006, 12:17 -0500 schrieb Jeff Pohlmeyer: > . > . > > What I don't understand is why the var "errno" is not set or it's value > > is destroyed before Findfirst/-Next return. Does this value has to be > > set explicitely by using fpseterrno()? It returns always -1 in case of > > permission denied. > > My opinion is that SysUtils.FindFirst should > return 5 in case of an error; "errno" is not > portable, whereas SysUtils is supposed to support > portable code. (that is not really the problem, OS errorcodes can be hauled with getlastoserror, which is errno on *nix) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
