Re: [fpc-pascal] Windows programming tutorials for FPC
On 11/03/2018 09:04 PM, James wrote: > So my question is, how can I use Ifilesavedialog with just FreePascal in > a console application? First off, the IFileSaveDialog is an interface, not a simple function. So, you'll need to: - Include the right units from freepascal (ActiveX and comobj IIRC) - Initialize and finalize the COM subsystem (see CoInitialize and CoUninitialize) - Use the CoCreateInstance to instantiate an IFileSaveDialog, etc.. I've never used the IFileSaveDialog myself, so have a look at https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913%28v=vs.85%29.aspx#usage That's the nice thing about the GetSaveFileNameA function: one call, and you're done :-) Now, if this function is not defined in the windows unit (which could be the case), you can either look into some other units or simply define it yourself: === code begin === Type TOpenFileNameAHookProc = function(Wnd: HWND; Msg: UINT; wParam: WPARAM; lParam: LPARAM): UINT stdcall; TOpenFileNameA = Packed Record lStructSize: DWord; hWndOwner: HWND; hInstance: HINST; lpstrFilter: PChar; lpstrCustomFilter: PChar; nMaxCustFilter: DWord; nFilterIndex: DWord; lpstrFile: PChar; nMaxFile: DWord; lpstrFileTitle: PChar; nMaxFileTitle: DWord; lpstrInitialDir: PChar; lpstrTitle: PChar; Flags: DWord; nFileOffset: Word; nFileExtension: Word; lpstrDefExt: PChar; lCustData: LPARAM; lpfnHook: TOpenFileNameAHookProc; lpTemplateName: PChar; lpEditInfo: Pointer;// Undocumented? lpstrPrompt: PChar; _Reserved1: Pointer; _Reserved2: DWord; FlagsEx: DWord; End; POpenFileNameA = ^TOpenFileNameA; Function GetSaveFileNameA(arg: POpenFileNameA): windows.bool; stdcall; external 'comdlg32' name 'GetSaveFileNameA'; === code end === -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows programming tutorials for FPC
On 11/03/2018 03:00 PM, James wrote: > That is correct, I have only ever done console programming, but now I > find I'm lost trying to do any kind of GUI programming. I have a very > simple program that works as a console application, but what I would > like to do is have it use the Windows "Save AS' Dialog to allow the user > to save the file using the windows GUI interface, so the user can > navigate through directory structures and save the file. > > > > I looked at a few tutorials and see how to make a form and put some > buttons on it, but I'm still trying to figure out how to get the save-as > box to come up and how to then use the given file name and path in the > program for the actual write operation.. Here’s my console program.. > it’s pretty simple, but I really don’t know where to even start to > convert it into a GUI program. On line 51, if the output file has not > been defined yet, I want to launch the save-as dialog, then on line 54, > assign whatever save-as returns to my OutputFileName Variable. For the simple stuff like displaying a message box or acquiring a filename, you could use the the common dialog boxes of windows (comdlg32), for example: https://docs.microsoft.com/en-us/windows/desktop/api/commdlg/nf-commdlg-getsavefilenamea I now see that this API has in fact been superseded by something different, but it should give you an idea. I do have to mention that things never stay "simple" though. Sooner rather than later you'll find yourself in a situation where you need more than just that basic functionality, and than you need to start using something different altogether (unless handling the event loop manually and fixing every last detail for every last use case of a user out there is your thing :-) ). For that purpose I would recommend the usage of some GUI toolkit: lazarus has been mentioned, similar things include fpGui and MSE, others possible exist as well. If you like to keep GUI and functionality apart from one another and have no problem with the GUI being written for a large part in a different language, have a look at Qt (possible with Qt4pas, if you insist on using pascal for the GUI). Anyway, enough on the toolkits out there, a google search will quickly yield you a lot more than I can mention in this mail :-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String message methods and the self parameter
On 06/01/18 17:35, Sven Barth via fpc-pascal wrote: > Judging from the implementation inside the RTL I'd say that this is a > bug in the documentation. String message methods work like ordinal > ones and take only one parameter. Yes, that is what it seems like. So once upon a time this feature was present, probably while the syntax was still "data: pointer" instead of "var data"? Anyway, I'll file a bug against the documentation in a couple of days or so. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] String message methods and the self parameter
Hi, When reading https://www.freepascal.org/docs-html/ref/refsu31.html#x82-1040006.5.7 I stumbled on the following text at the bottom of the page: "In addition to this mechanism, a string message method accepts a self parameter: Procedure StrMsgHandler(Data: Pointer; Self: TMyObject); Message ’OnClick’; When encountering such a method, the compiler will generate code that loads the Self parameter into the object instance pointer. The result of this is that it is possible to pass Self as a parameter to such a method. Remark: The type of the Self parameter must be of the same class as the class the method is defined in." 1. This code snippet fails to compile with the message "Message handlers can take only one call by ref. parameter" (revision 30487, $mode objfpc) 2. "[...] When encountering such a method, [...]": What are the exact criteria: the parameter name, the parameter type, ...? 3. Can anybody explain what the part "The result of this is that it is possible to pass Self as a parameter to such a method." entails? How can it be passed with DispatchStr? 4. Can somebody give an example on how to use this functionality? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Convert to int64 note
On 14/07/17 17:19, ja...@productionautomation.net wrote:
>> If you declare Last_GS as int64, you should not get the warning.
>
> I declared both Last_GS and G_End as int64, leaving Max_Program_to_Display as
> a word and still get the warning. If I also make Max_Program_to_Display
> int64, then I do not get the warning. I believe it's due to the -1. If
> Max_Program_To_Display was a 0 then subtracting 1 from it would be out of
> range from a word for that portion of the formula, even though the end result
> would fit in Last_GS
>
>> Last_GS:=G_End-(longint(Max_Program_To_Display)-1);
> This aso fixes the warning if I leave all my variables alone. If I
> understand this correctly in this case longint() is a function that returns a
> longint variable to be used in the calculation, so when it does the -1 it's
> ok it that part of the formula ends up being negative.
>
> So now my question is, which is the best method to use? My thinking with
> declaring Max_Program_To_Display as a word was that this value has no meaning
> if it is negative, and actually a word is way too generous for this value, a
> byte would be overkill. Last_GS and G_End could be very large, so that's the
> reason for the longint. So I can either declare Max_Program_to_Dispalay as a
> longint and use more memory for that variable, or use a longint() function in
> my formula and that calculation would have one more function to process, or
> turn off the warnings but then there could be a condition where I could get
> an out of range result during the computation even though the final result
> would have been in range.. but this happens sometimes so I would rather fix
> it to never happen.
>
> I'm from the old school way of thinking that programs should use as little
> memory and be as efficient as possible, after all some of my computers only
> had 4K of RAM, but I'm wondering if that has become irrelevant with modern
> computers.
> Does it really matter anymore how much memory I use up with variables?
> Maybe I should just declare all whole number variables as int64 and all
> decimal numbers as Double and not worry about how much memory I use, after
> all I have gigabytes of ram to use now, not 64K blocks of ram that each turbo
> pascal unit had to fit into. Even if I had 1 million int64 variables and 1
> million double variables, that would only end up being 18MB of memory, not
> much of dent in 1GB... and most pcs have more than 1GB of RAM.
>
> I suppose it would take longer to process all formulas with int64 and double
> variables compared to using smaller variables, but then again processor speed
> is also very fast now, so should I even be bothered with it?
>
> I'm curious what the general method is now?
There are a couple of things to take into account here:
- Your target processor and it's native integer size
- Aligned access is *much* faster than unaligned access
- If you really need to work with words of different sizes,
typecasting is your friend :-)
Now, since aligned access is so much better, it would be a very sane choice of
the compiler to align all local variables on the stack (I don't know if FPC
does this, but I strongly suspect it does). This means that a single byte will
occupy the same size as an integer. So you actually win no space on the stack.
Same goes for records and arrays, unless they are declared as 'packed' with a
{$PACKRECORDS 1} directive next to it (the 1 is the alignment). Those arrays
and records can be very handy to read/write data from/to a file, socket,
stream, shared memory, pipe, ... But are a performance killer.
So on modern processors, you probably win nothing at all regarding size.
Then, the speed of the calculations. Of course there is the fact that you
simply have less bits to process, which would suggest a speed improvement.
However a processor could simply use 64-bit arithmetic and simply mask the
output for you. I don't know what the case is there.
Mostly I use the smaller types for a variety of very basic range limitations:
when I declare something as a byte, its value can never be larger than 255,
which can come in handy at times. Think about a lookuptable for a CRC
calculation unit for example.
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] named parameter
On 27/05/17 11:26, Bernd Oppolzer wrote: > it would be nice if you could specify a default value for the new > third parameter and don't have to change all the callers that use > only two. > [snip] > procecure P (x : integer; y : boolean; c: char := ' '); > > the first two parameters are mandatory, the third is optional. > Calls to P with 2 and 3 parameters are both valid. You realize you can already do this, right? See https://www.freepascal.org/docs-html/ref/refsu64.html#x176-19800014.4.1 -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?
On 23/05/17 19:50, James Richters wrote: > *correction to directory names: > Now I got an error that it could not find graphh.inc So I copied all the .inc > files from J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph\inc to > J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph because I have no > idea how else to make it find them. Just like you now use -FuSomePath to tell the compiler where to find units, you can use -FiSomePath to tell the compiler where to look for include files. See `fpc -h`, under the section "-F Set file names and paths:" for a list of other related switches. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] List pre-defined defines
On 16/05/17 23:53, Mattias Gaertner wrote: > touch mytest > fpc -vc mytest Perhaps a one-liner: fpc -vc /dev/null ? Saves one the need to create a dummy file and remove it afterward ;-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Correct syntax for initialized constants/variables
On 27/04/17 20:49, Ralf Quint wrote: > I try to include some initialized constants/variables in an application > of mine, but somehow stumbled upon a stupid little problem that I can't > figure out myself after nights on the computer. > > I see in the reference docs (section 4.4) examples for arrays and > examples for records, but in my case, I would need to properly define an > array of records. Something like this? Type TA = Record a: Integer; End; Var SomeArray: Array[0..1] of TA = ( (a: 42;), (a: 17;) ); Note: this is written from memory, syntax might differ a little (but the error messages from the compiler should help you out in that case). -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Docs: Type A = Integer?
On 14/11/16 07:38, Michael Van Canneyt wrote: > > > On Sun, 13 Nov 2016, leledumbo wrote: > >>> Maybe this helps: >>> http://www.freepascal.org/docs-html/current/ref/refse19.html >> >> I think the OP means that type block is shouldn't be there. The page is >> talking about include directive and that type definition is not >> related in >> anyway with paragraphs below or above it. > > Indeed, in SVN it is no longer there. Ah, ok. So in the next release that issue will be fixed in the online version as well then. Thanks! -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Docs: Type A = Integer?
On 13/11/16 23:33, Mattias Gaertner wrote: > Maybe this helps: > http://www.freepascal.org/docs-html/current/ref/refse19.html Close, yet presence of that particular line in the section on the include directive is, at least for me, not yet unraveled ;-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incorrect Process startup
On 06/11/16 23:50, Steve Gatenby wrote: > run wmctrl (or other) from the TProcess / RunCommand code > the TProcess instance returns the PID for the new process > read the relevant file under /proc/PID/status - it will intermittently > show the new process is actually a copy of the caller app. > (meaning: the orig app is called Test1, I try to run wmctrl, I end up > with 2 copies of Test1 running) Actually, this is quite exactly what I would expect here. Spawning a new process on unix is actually a two step thingie: - First fork(), which duplicates the current process - The child then exec()'s, replacing its current process image with a new one (which would be the target executable in your case) It is important to note that a lot of the parent process is preserved by the child process. On such example are file descriptors, which are not closed automatically for you. It is actually via this mechanism that pipes to and from child processes can be established with relative ease. More on this subject can be found at https://en.wikipedia.org/wiki/Fork%E2%80%93exec https://linux.die.net/man/2/clone https://linux.die.net/man/2/fork https://linux.die.net/man/3/exec > I have found through experimenting: > > a pause of 100ms after running the process will fix 80% of cases. Probably because the child has exec'ed by this time, if I had to guess. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GZip - Stream decompress only in memory
On 04/09/16 18:08, Marcos Douglas wrote: > Hi, > > I have streams compressed using GZip. I get these streams from WebServices. > So, how can I decompress these streams only in memory? Perhaps have a look at zlibar. The main, and only, unit contains these functions: function CompressStream(InStream: TStream; OutStream: TStream): Integer; function ExtractStream(InStream: TStream; OutStream: TStream): Integer; I think this is what you are looking for. I don't know about file headers. At least it would form a good starting point. Good luck! -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A better way?
On 14/04/16 16:46, Ryan Joseph wrote: > I think I prefer using type casting or abstract classes more than mixing 2 > mutually exclusive classes into one unit even though they may have > dependancies on each other. Editing and navigating the files would be > confusing for one since there’s no obvious name to use for the file now. Mutually exclusive classes are mutually exclusive to classes which have dependencies on one another ;-) Or am I missing something? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?
On 03/20/2016 05:32 PM, fredvs wrote: > >> Why do you use "hn: Intege"hn: Integer" instead of "hn: TLibHandle" > Excellent question... > Because of... fpc... > > In fpc 64 bit unix : result of dynlibs.loadlibrary() is... a integer. Well, if this is the case, then you should probably report a bug. The man page of at least linux and freeBSD indicate that it should be a pointer. However, I would like to note that on linux, using revision 32828, TLibHandle is defined as a ptrint, which is correct. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?
On 03/20/2016 01:11 PM, fredvs wrote:
>> Or simply dlerror() like in the other program, should work.
> OK. here code + result of GetProcedureAddress(), maybe it could help for
> future fixes in fpc:
>
> GetProcedureAddress(hn, pchar('mp4ff_open_read');
> writeln(dlerror());
>
> ---> Result:
>
> "Invalid shared object handle 0x2fb2800"
>
Alright, ignore my previous mail, I'm lagging behind it seems ;-)
Could this be related to pointer trucation? The man page of dlopen tells
us that the return value is a pointer (hence the return value of
LoadLibrary has the same width). In your example you used an integer. Is
sizeof(Integer) = sizeof(Pointer) of your system?
If for example, you are missing the upper four bytes of the pointer, the
above message makes sense.
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?
On 03/20/2016 12:56 AM, fredvs wrote:
> Re-hello (and last for tonight).
>
> Yep, yep, yep.
>
> Replacing all GetProcedureAdress() with dlsym()
>
> DOES THE TRICK ! ;-)
Uhm, are you sure about this? I always thought GetProcedureAddress
simply calls through to dlsym. If one works and the other doesn't, this
needs some more investigation I think?
Also, in you last example, quoted here:
--
Now with DynLibs:
procedure loadmylib(lib : pchar);
var
ap1: pointer;
hn : integer;
'
begin
/// with dynlibs
hn := dynlibs.loadlibrary(Pchar(lib));
if hn <> 0 then
writeln('loadlibrary() is OK') else
writeln('loadlibrary() is NOT OK') ;
ap1 := getprocedureaddress(hn, Pchar('mp4ff_open_read');
INDICATED POSITION
if ap1 <> nil then
writeln('getprocedureaddress() is OK') else
writeln('getprocedureaddress() is NOT OK') ;
end;
--
Could you add a "writeln(dlerror());" ate the "INDICATED POSITION"?
Just curious about what is going on here...
PS: Why do you use "hn: Integer" instead of "hn: TLibHandle"? I don't know if
it can be assumed that this handle will always be an integer (think, for
example, pointer)? Just a thought.
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?
On 03/19/2016 08:53 PM, Marco van de Voort wrote: > In our previous episode, Ewald said: >>> Re-huh..., it should be a great plus if a dlerror() was implemented in fpc >>> too. >>> >>> But maybe I am missing something, maybe dlopen(), dlsym() and dlerror() can >>> be done by pascal code (and not via console, like I try). >>> >> dlopen, dlsym and dlerror are *functions*, not console commands. Well, I >> never tried the latter, but it appears they are not on your system ;-) >> >> Now, I don't know where exactly these functions are declared (in which >> unit, that is), but for debugging purposes, just add >> >> Function dlopen(filename: PChar; flags: cint): Pointer; cdecl; external; >> Function dlclose(handle: Pointer): cint; cdecl; external; >> Function dlsym(handle: Pointer; Name: PChar): Pointer; cdecl; external; >> Function dlerror: PChar; cdecl; external; >> >> Somewhere in your code before you call them. > ... or use unit dl. I knew they were in some unit somewhere ;-) Thanks for the pointer! -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?
On 03/19/2016 08:29 PM, fredvs wrote:
>> dlopen, dlsym and dlerror are *functions*, not console commands. Well, I
>> never tried the latter, but it appears they are not on your system ;-)
>> Now, I don't know where exactly these functions are declared (in which
>> unit, that is), but for debugging purposes, just add
>>Function dlopen(filename: PChar; flags: cint): Pointer; cdecl;
>> external;
>>Function dlclose(handle: Pointer): cint; cdecl; external;
>>Function dlsym(handle: Pointer; Name: PChar): Pointer; cdecl; external;
>>Function dlerror: PChar; cdecl; external;
>> Somewhere in your code before you call them.
> Ooops, thanks for answer but now I am completely loosed... ;-(
>
> So those functions can be used in fpc code?
> If so, must a library be loaded to access that functions (and what library)?
> Or are those functions defined in a fpc unit ?
See Marco's answer. So instead of using the above declarations, a simple
`Uses dl;` should do the trick.
As to how to use them, now you do something like this:
X:= GetProcedureAddress(...);
Y:= GetProcedureAddress(...);
Z:= GetProcedureAddress(...);
When one of these fails, a nil pointer is returned. dlerror will give
you more info on what failed where. So, if you know X returns nil for
some-yet-to-be-determined-reason, place the dlerror immediately after that:
X:= GetProcedureAddress(...);
WriteLn(dlerror);
Y:= GetProcedureAddress(...);
Z:= GetProcedureAddress(...);
Of course, you could choose to do something like this if you do not know
which call exactly fails:
X:= GetProcedureAddress(...);
If X = nil Then
WriteLn('Z: ', dlerror);
Y:= GetProcedureAddress(...);
If Y = nil Then
WriteLn('Y: ', dlerror);
Z:= GetProcedureAddress(...);
If Z = nil Then
WriteLn('Z: ', dlerror);
It is really nothing more than a function call, quite similar to fpGetErrNo.
> I am in the dark.
Being in the dark is positive, as one can always turn on the lights :-)
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?
On 03/19/2016 07:49 PM, fredvs wrote:
> Hello Marc.
>
> Huh, I have a dummy question...
>
> How do you use dlopen(), dlsym() and dlerror() ?
>
> On console, with ->
>
> fred@freebsd> dlopen('/root/mylib.so')
>
> Result = "Illegal command name..."
>
>> call dlerror() after the failing dlsym(). It should tell _why_ the call
>> failed.
> Re-huh..., it should be a great plus if a dlerror() was implemented in fpc
> too.
>
> But maybe I am missing something, maybe dlopen(), dlsym() and dlerror() can
> be done by pascal code (and not via console, like I try).
>
dlopen, dlsym and dlerror are *functions*, not console commands. Well, I
never tried the latter, but it appears they are not on your system ;-)
Now, I don't know where exactly these functions are declared (in which
unit, that is), but for debugging purposes, just add
Function dlopen(filename: PChar; flags: cint): Pointer; cdecl; external;
Function dlclose(handle: Pointer): cint; cdecl; external;
Function dlsym(handle: Pointer; Name: PChar): Pointer; cdecl; external;
Function dlerror: PChar; cdecl; external;
Somewhere in your code before you call them.
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Lexical Diagrams
On 01/30/2016 08:22 PM, Anthony Walter wrote: > Ewald, > > Maybe you should go to the forums and enlighten everyone. I provided > the link in my last reply. You missed the point. It is not my intention to shove my opinion down anyone's throat. I do however think that reinventing documentation (with all the bugs related to new projects) is a waste of time. Especially if the only thing that changes is the form factor. It is the content that matters. That content already exists, but needs some work here and there. So I am trying to convince you to collaborate to the existing documentation instead of writing your own. Because your own documentation will also be a one-man project, will also have its flaws and then in about five years a similar thread on some forum I'll probably not be subscribed to will state that the getlazarus documentation is in a terrible state. And voila, same discussion all over again. All that effort down the drain. And what for? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Lexical Diagrams
On 01/30/2016 08:09 PM, Anthony Walter wrote: > Ewald, > > If you read the threads on the Lazarus forums I'm not subscribed to that forum as I do not use lazarus. I use freepascal without an IDE. So by all means: enlighten me :-) > you'll see the points people are making while complaining about the > documentation, tutorials, and application developer guides, including > complaints from some of the top contributors. In a nutshell it has > been said that the wikimedia engine is bad for these things. One > complaint is that due to it's everyone can edit/create pages there is > a general lack of cohesion. Many people have vastly different writing > skills, topics are not ell organized, contributors and moderators > spend time fighting vandalism or bickering rather than on creating > quality content, there are not enough people in out community > interested in taking on their work of maintain a decent wiki. Many > examples were given, and I personally prefer a nested structure with > folders which the wikimedia engine does not provide. You are talking about the wiki here. I was talking about the programmers guide and language reference. The names may be off, but if you would have clicked that link I sent in my previous message, you would have noticed that that page is no wiki at all. > > If you are okay with the state of everything then move along. Read the pages. What is wrong with them? If something is wrong, then file a bug! Now, since something terrible has gone wrong in pointing you to the two documents I am talking about, I'll walk through the procedure with thee: - Go to www.freepascal.org - Click documentation (6th entry under general) - Select one of the docuemts, humour me and pick the language reference. - You are now here: http://www.freepascal.org/docs-html/current/ref/ref.html Now tell me (or file a report), what is so "terrible" about this? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Lexical Diagrams
On 01/30/2016 10:45 AM, Anthony Walter wrote: > I've been working on writing Javascript to generate lexical language > diagrams for the getlazarus.org <http://getlazarus.org> learning > center portal. > > With my script I'm able to render these diagrams which will be appear > under the Free Pascal language Lexical topic: > > http://cache.getlazarus.org/images/lexical-diagrams.png What's wrong with those found in the documentation? (for example: http://www.freepascal.org/docs-html/ref/refse105.html ) IMO those provide more clarity. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Lexical Diagrams
On 01/30/2016 07:21 PM, Anthony Walter wrote: > > There was/is a big discussion on the forums about the terrible state > of the documentation. Two things: - I don't think the state of the documentation is terrible. It has in fact improved vastly over the years. - By creating a secondary set of documentation the "terrible" state won't improve, now will it? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] got SIGSEGV with objfpc dialect
On 09/13/2015 03:25 PM, che fou wrote: > Atm i don't know how to report , i'll try to figure out how to Try http://bugs.freepascal.org/ -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] which GUI (noob)
On 08/05/2015 09:14 PM, Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: I think that the one thing I'd suggest to everybody is that it would be highly desirable if the dangling else fix were guaranteed to break Pascal syntax. As such end if; etc. might be a better choice If you start a different language, yes, the block system would be number one. Do away with oneline vs multiline blocks ambiguity in general. (and not just because of ELSE). Second would be a different procedure-block ending from just end; though the M2 way of end procedurename is unnecessary hard to maintain. end proc; or end function would be just fine. You mean something like Ada? while true loop if false then --whatever else --ditto end if; end loop; (although functions/procedures are terminated using `end functionname;` as well) Extra feature: inherent concurrency support. I don't know about classes or generics, those will probably be in an newer standard. But who needs those? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Basic Sockets in FreePascal
On 07/26/2015 04:49 PM, Coyo wrote: I have read on the wiki and documentation that FreePascal does not have any native support for socket handling, and that you need an external third party library to have any support for it. How about `uses sockets;` [1]? Basically it's the same as you would have in C, but all functions are prefixed `fp` (as are most other low level functions on *nix BTW). [1] http://www.freepascal.org/docs-html/rtl/sockets/index-5.html -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to use a static method as procedure variable?
On 30 Jun 2015, at 20:54, silvioprog wrote:
The code above compiles fine in Delphi (tested in XE 7), but in FPC I got the
following compiling error:
Unit1.pas(46,14) Error: Incompatible types: got class method type of
procedure({Open} Array Of Byte;out AnsiString) of object;Register expected
procedure variable type of procedure({Open} Array Of Byte;out
AnsiString);Register.
Is this a bug or I need to enable some switch?
Back in 2012 I had a similar issue. Original message can be found here:
http://lists.freepascal.org/pipermail/fpc-pascal/2012-December/035921.html
I fixed it by declaring a type that includes the hidden parameter mentioned in
that thread, so in your case:
Type
TMyProc = procedure(aClassType: TClass; ABytes: array of Byte;
out AOutput: AnsiString);
the invocation then becomes
FMyProc(ClassType, [65, 66, 67], S);
instead of
FMyProc([65, 66, 67], S);
And, of course, the assignment to FMyProc becomes more verbose and less
type-safe:
FMyProc := TMyProc(Pointer(@DoMyProc));
NOTE: This is a hack. It is not documented anywhere, but i have used this
approach since late 2012 without any problems so far. Better be careful and
write a small sanity test that checks correct operation every time you use a
new compiler.
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] loadlibrary() unsafe ?
On 06/20/2015 09:05 AM, fredvs wrote: Hello. Sorry to come back with that story... ;-( I have used inside a script LD_LIBRARY_PATH` and at end runs the espeak executable. So a Tprocess run the script. Why use a script? When you exec(), a parameter is available to set the environment variables[1]. Using a TProcess, try setting the `Environment` property before running it[2]. Hope it helps :-) [1] http://linux.die.net/man/3/exec [2] http://www.freepascal.org/docs-html/fcl/process/tprocess.environment.html -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get the permission f a file ?
On 06/17/2015 04:42 PM, fredvs wrote: But how to check if a file has executable permission (and if not, change it with fpchmod(thefile S_IRWXU);) ? stat? See: http://linux.die.net/man/2/stat http://www.freepascal.org/docs-html/rtl/baseunix/fpstat.html http://www.freepascal.org/docs-html/rtl/baseunix/stat.html -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] loadlibrary() unsafe ?
On 06/10/2015 01:20 PM, fredvs wrote:
To do run the program =
- first dynamic load portaudio with
loadlibrary('/the_path_you_want/libportaudio.so').
- run the executable via TProcess (espeak).
I must admit this is a creative way of solving this particular issue :-)
I wonder if you have tried to set the environment variable
`LD_LIBRARY_PATH` to contain `the_path_you_want` before you spawn the
other process?
See also
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html :
section 3.3.
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Finally, exceptions and so on.
On 05/14/2015 04:17 PM, Mark Morgan Lloyd wrote:
So in effect, both an exit and a raise first execute the innermost
finally, then look for procedure end or exception block repeating as
necessary.
Yes.
These are the only cases where syntax needs to be unwound in this way.
Well... There is also continue and break. The following program will
also execute the Finally statements before exiting the loop:
Code Begin
Program TestFinally;
{$mode ObjFPC}
Procedure Whatever;
Begin
WriteLn('Finally.');
End;
Begin
While True do
Try
Break
Finally
Whatever
End;
Repeat
Try
Continue
Finally
Whatever
End
Until True;
End.
Code End
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Finally, exceptions and so on.
On 05/14/2015 12:08 PM, Mark Morgan Lloyd wrote: Is there a single place in the documentation where this sort of behaviour is described and prioritised, Your first fragment is documented on http://www.freepascal.org/docs-html/ref/refse103.html At the bottom of that page: `Note that an Exit statement enclosed by a try .. finally block, will still execute the finally block.` The second fragment seems obvious at exit does not raise an exception. taking into account interfaces etc.? Why should interfaces have anything to do with exception handing (any more than strings for example)? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using Cairo lib on Linux without X
On 04/07/2015 09:13 PM, Juha Manninen wrote: FPC has the API wrapper for Cairo lib. I am studying its dependencies and maybe use it in a Linux server with no X Window installed, for generating PDFs. Cairo is advertized to support multiple output devices, including X Window, image buffers, PostScript, PDF, and SVG file output. I understand it means that X Window is required only for the X Window backend. PDF or SVG backends should not require X Window. However on my Linux Mint 17 libcairo has a dependency for libX11.so.6. Maybe libcairo always links to it, but does not use X11 functionality when XOpenDisplay fails? Just an idea... I'm no expert on the matter. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] getaddrinfo
On 03/20/2015 04:14 AM, MegaBrutal wrote: I also need some help with using the function, as it works very strangely on Linux, as it returns addrinfo structures, but the ai_addr member is always a null-pointer, which is theoretically impossible by the manual, in my understanding. As Mark suggested, perhaps a bug in the fpc implementation (fpc does not normally use lic for it's syscalls)? Try defining the function manually, using libc's equivalent and see if it produces the same result? Just a suggestion... -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Saving and reading TBlowfish crypted text
On 17 Mar 2015, at 22:32, Graeme Geldenhuys wrote: On 2015-03-17 18:49, Ewald wrote: The docs state that it is called automatically upon destruction: Correct, and I knew that. But I was explicitly looking at the code Antonio supplied. [...] This is my interpretation of what is going on with the code I have seen (I haven't actually tried to compiler and run that code). If I am wrong, feel free to correct me. No, you are quite correct. I should've looked more closely to the code supplied (the 2-letter variable names must have confused me I suppose). Sorry for the noise. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] how to use procedure of object in C
On 09 Mar 2015, at 18:43, Michael Van Canneyt wrote: You must be sure that self is passed in the correct register. I am not sure this is the case if you declare it as an extra argument. It is, as long as the `self` is the first parameter. Same goes for `Class Procedure XXX;` kind of declarations (in constrast to `Class procedure XXX; static;`). I don't know how long that is going to last however (since this hidden parameter thingy is an implementation detail of the compiler I think). So I fully agree: it would be a kindness of the compiler people to confirm this :-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC embedded ? (going slightly off-topic)
On 05 Mar 2015, at 19:57, Adriaan van Os wrote: It's a very smal project but I do need to drive one or two stepper motors. What I learnt is that that the board does the controlling and that there is a separate chip for driving the motor, e.g. for stepping and microstepping ? Stepping and microstepping can easily be implemented in the microcontroller itself, like you say. The reason you need an extra chip is the need for some power transistors arranged in a bridge configuration, something similar to the L298 or L293D, to name some popular IC's. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compile vs native
On 01/28/2015 10:01 AM, Michael Schnell wrote: On 01/27/2015 10:27 PM, Ewald wrote: - Without the target system, the application cannot be tested .. This is true, only because remote debugging is not well supported. For remote debugging a target system is needed as well? So even if remote debugging would be easy-peasy, the part you quotes still stands: no target system: no decent testing. In fact I sometimes to programs to be run on a headless system (e.g. a NAS) Here you can't install Lazarus, because you don't have a GUI. [this might be an extremely silly proposition, please forgive me] Why don't you run lazarus through ssh? Or use vnc? You easily can install fpc and compile native, though. So I ended up testing the software on a PC (as far as possible without the hardware) and finally compile it on the target system. I did not bother to install the cross compiler (the problem here is not fpc itself, but the cross-libraries that are necessary link the project for the target system). If I would be able to use Lazarus on the development system to remote-debug the target system, the effort to install the complete cross-compile infrastructure would be viable. I believe you are saying that you would like to cross-compile and debug the system remotely (which, judging from your other posts, are mostly embedded platforms?), but due to difficulties/roadblocks you are forced to compile it natively and debug it on the target system. Well, _if_ the cross-compilation works, why not just ssh in to the target system and run gdb there? Please forgive my ignorance as I do not know the exact details of your setup. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compile vs native
On 01/27/2015 09:56 PM, Brian wrote: A question to those who must maintain a Linux version and a Windows versions application. Do you tend to cross-compile from Linux or do you compile native (with separate projects) on each OS (Linux and Windows)? Native, because of two reasons: - Without the target system, the application cannot be tested thoroughly, and if one has the target system, why not build on it? - Some dependencies (such as autogenerated code) need to be compiled on the target system. It could probably be done on a linux system as well, but same argument as above... Projects are identical on both platforms though (except for a few ifdefs to access OS-specific functionality). -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OSX x86_64 make problem
On 01/16/2015 10:08 PM, Anthony Walter wrote: Details: The problem I am having is that even on a 64bit Mac, the make all command builds i386-darwin. When I try to make crossinstall OS_TARGET=darwin CPU_TARGET=x86_64 INSTALL_PREFIX=/Users/macuser/Development/Base/fpc Have you tried `make CPU_TARGET=x86_64 all` instead of `crossinstall`? That's how I just built the latest revision, 29488. Just a suggestion... -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] else and otherwise in a case statement
On 12/11/2014 11:13 PM, Howard Page-Clark wrote: On 11/12/2014 21:07, Mark Morgan Lloyd wrote: I've been doing a bulk replace of 'case..else' to 'case..otherwise' to eliminate possible ambiguities that have bitten me in the past, and have noticed something interesting under 2.6.4 on x86 Linux. How can else be ambiguous within a case statement? If one omits the trailing semicolon (the one that's commented), the else becomes ambiguous: Case Something of Value1: ; Value2: If Condition Then DoSomething (*;*) Else End; -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question about functions returning a string
On 12/01/2014 04:34 AM, leledumbo wrote: So in general, one should not use managed types in the prototype of an exported (public) function? Bingo. At least not until we have properly sharable RTL. The problem lies not with a sharable RTL. As mentioned, I do not want to /use/ these managed types in another language. I just want to pass them along :-) my thought was that it would be possible to pass along these managed types (especially string, as it is a pointer internally) to another pascal function (a callback in my case). You can still pass pointer to its first element as a PChar, treating it read-only in the caller for safety reason (though it's possible to make it writable as well, but the safety burden is propagated to the caller). Actually I was trying to avoid PChar's ;-) In the meanwhile, I've fixed my issue by not returning a string as a result, but as an out parameter: Function Bla: String; ... becomes ... Procedure Bla(out Result: String); This seems to work. How portable it is, I do not know, I guess time will be the judge and jury on that. Anyway, thanks to you all! -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question about functions returning a string
On 11/29/2014 02:46 PM, Sven Barth wrote: In general managed types (which a (Ansi)String is) are passed as parameters. That is very interesting knowledge. Thanks! So in general, one should not use managed types in the prototype of an exported (public) function? While I do know that the other language can't do anything useful with it, my thought was that it would be possible to pass along these managed types (especially string, as it is a pointer internally) to another pascal function (a callback in my case). -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question about functions returning a string
On 11/29/2014 12:41 AM, Flávio Etrusco wrote: Are you sure it's not the result that is passed in the first parameter? http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl Good question, but I don't think so. The first few lines of assembly from this function seem to read three arguments you see: 44b360:53 push %rbx 44b361:41 54push %r12 44b363:41 55push %r13 44b365:48 89 fb mov%rdi,%rbx-- first argument, %rdi 44b368:41 89 f4 mov%esi,%r12d -- second argument, %rsi 44b36b:49 89 d5 mov%rdx,%r13-- third argument, %rdx What I forgot to mention was that this is on a x86_64 architecture, so I based myself on the table found at http://wiki.osdev.org/Calling_Conventions . -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Question about functions returning a string
Hi,
Take the following function prototype (in {$mode objfpc}{$H+} for the
record):
Function SomeFunction(const Data: PChar; const Len: LongWord):
String; cdecl; public;
Looking at the dissasembly of this function, I see that is actually has
three arguments. It looks more like this from an assembler perspective:
Function SomeFunction(HiddenArgument: Pointer; const Data: PChar;
const Len: LongWord): String; cdecl; public;
Which is, well, quite fascinating really. What is it doing there? I
suspect it has something to do with the result type of the function,
being a string?
Can anybody shed some light on this?
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Again: Use of abstract classes
On 10/02/2014 05:35 PM, silvioprog wrote: Hello, Someone could inform me if there is an entry in bugtracker with references to this topic? This has already been fixed I believe. See http://lists.freepascal.org/pipermail/fpc-devel/2014-July/033930.html for more information. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
On 09/16/2014 03:41 PM, Philippe wrote: I imagine that who really want to get rid from the hint ... don´t use Pascal anyway! or do have strong test tools!!! one point is that (many?) people use with ... and compiler can make it safer. may be as described Frederic Da Vitoria ... producing error when may be confused. (but let configure it!) The issue is that when you introduce this hint, it is almost certain that someone will ask `how to disable that hint?` on this list. IMO it would be a waste of time to implement such a thing. If I were a developer (hmm, actually I am one :-) ), and I would work on a project like FPC (meaning: in my free time, not getting paid to do the job), I would invest my time in something that actually means something, like fixing a bug, optimizing the RTL for a specific target, writing documentation, etc... We are programmers after all, not end users who want to be treated with silken gloves. You've only got 10 choices really: either you like the `with` statement, or you don't. In the latter case don't use it. Remember that the original question was about functionality, what this thread has now evolved into is, in my opinion, off-topic. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
On 07/25/2014 03:04 PM, Fabio Luis Girardi wrote: The same question that I posted on bugtracker: Linux, BSD, Unix, has another threaddriver than cthreads? If no, why not make cthreads unit the default threaddriver for Unix? I read somewhere some time ago that the main reason for this was that FPC has no dependency to libc under normal circumstances. Making cthreads the default thread manager would thus add a dependency to libc. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illeagal assignment to For Loop variable in Free pascal
On 17 Jun 2014, at 13:05, mokashe.ram wrote: Hi, Could Any one help me for fixing below error in free pascal. as i am tring to excute for loop in decemental order using 'DOWNTO' but its thwoing error 'Illeagal assignment to For Loop variable 'Counter' as this is possible in TP but in Free pascal its not working so is there any workaround for this? FOR counter := 8 DOWNTO 1 DO IF filename[counter] = ' 'THEN DELETE(filename,counter,1) ELSE counter := 1; How about: Counter:= 8; While Counter = 1 do Begin If Then ... Else Counter:= 1; Counter-= 1; End; ? Perhaps there is a switch that allows assignments to for-loop counters (although I doubt it), I don't know. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thread Safety of String
On 04 Jun 2014, at 20:42, m...@rpzdesign.com wrote: For anybody who has followed this thread, there is some disagreement over the thread safety of shortstrings. And in this case, a shortstring with a clearly defined maximum length. Some have clearly said string[30] is NOT thread safe. Rich indicated below he feels they ARE SAFE. Actually, the question is: what do you mean by `thread safe`? So you mean it like: `the variable stays at the same place in memory (but not always, the variable can reside in a register for some time)`, like `accesses to this variable are atomic`, like `this variable will *always* be in memory at the same location (no prolonged life in registers for this bugger)`, or ...? Hmmm. Time for DOUBLE jeopardy. Alex Trebeck says, I am the son of Ansistring but I don't move around much. My pointer is me and I am my pointer. Hmmm, JuniorString must be a cripple philosopher then ;-) Anyway, I would be interested in the answer, as do you I suppose. I have to implement the same thread code in C++ a little later, so there are no shortstrings in C++, just QStrings. (oops, yeah, I use Qt also) Time for some nitpicking..Yay! How about: char YourString[SIZE]; It's kind of a drudgery to handle those though, so I see why you like QStrings better :-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
On 05/31/2014 12:38 PM, Sven Barth wrote: On 31.05.2014 12:10, fredvs wrote: The question here is: where did you type it? Inside the loop in thread, after each queue()... and also just before end of thread. *That* does not help. Queue put's the method pointer you provide into a queue that needs to be read by the *main thread*. It *will* fail if you use it from within a different thread especially the one which calls Queue (much worse with Synchronize, because Synchronize will *block* until CheckSynchronize was called). Couldn't have said it better ;-) the next thing to go for, is probably be to try to get this `CheckSynchronize;` integrated into java in a decent manner (applicable to most use cases, that is). Good luck with that :-) Yep, but using a java-timer is not the best way to use the library. One of the great feature of uos-unit (for fpc users), is all the queue(procedure) at begin of thread, begin/end of the loop inside the thread and at end of the thread. But for the uos-library I could use a java-timer who do a fpc-checksynchronize() at x interval, but it is not perfect because it will always loose the x interval for synchronization... There's no way around it. The only way to call CheckSynchronize is to call it from the main thread and that main thread is the one which invokes loading the library on the Java side. So the way you currently do it *is* the way. Indeed, but it is not `itegrated` into the main loop (if there is one?), the way I understand it is that he currently calls CheckSynchronize manually. This is of course a good way to test things, and it is the way to go if you're writing your own main loop; but I think most users don't write their own main loop (save for embedded developers, people writing GUI toolkits and the like). The ideal thing would be to find some java mechanism that allows him to `append` this checksynchronize to `the` main loop, some main-loop hook of sorts. That is IMHO the way to go for, but as my knowledge of java is rather limited, I cannot comment on the feasibility or practical details of this approach. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
On 30 May 2014, at 10:46, fredvs wrote: re-@ Ewald : It *must* be called in the context of the main thread (the thread that loaded the library) OOps, so do you mean that CheckSynchronize must be called by Java ? So i have to add a custom procedure in the fpc library (who will be only a fpc CheckSynchronize()) ? Is it that that you mean, calling CheckSynchronize from the main Java class (not from the main thread of the library) ? Have you got an event/main loop? If you have something like While true do Begin ... code ... End; Simply append CheckSynchronize at the end of this block: While true do Begin ... code ... CheckSynchronize; End; If you have an eventloop, but you haven't got access to the actual code of the loop, you should look for mechanisms that hook up to this loop (something like http://wiki.freepascal.org/Main_Loop_Hooks ?); how this can be done in java, I do not know. You could even try using a timer to accomplish this (it is far from ideal, but you can experiment further then ;-) ), as long as it is a timer that doesn't execute it's events in it's own different thread (if applicable). As you can see, I am rather vague on the subject, because (1) I am not a java programmer and (2) I don't know enough of your architecture to make any specific comment. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
On 05/30/2014 01:15 PM, fredvs wrote: Please read my earlier post before this one @ Ewald, i have try with : While true do Begin ... code ... CheckSynchronize; End; But this does not work... The question here is: where did you type it? Anyway, as you've already gotten it to work, there is no need to try this; the next thing to go for, is probably be to try to get this `CheckSynchronize;` integrated into java in a decent manner (applicable to most use cases, that is). Good luck with that :-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
On 05/29/2014 11:18 AM, fredvs wrote: but the timer does not execute CallvoidMethod at fptimer.ontimer... Just a guess here... To quote Sven a few mails ago: `CheckSynchronize is used to process calls to TThread.Synchronize and TThread.Queue. It *must* be called in the context of the main thread (the thread that loaded the library). TFPTimer uses Synchronize internally, [...]` But you didn't use the word `CheckSynchronize` anywhere in your mail. You need to call this method regularly in you main thread, if you don't call it, nothing will happen; you only fill up the queue that CheckSynchronize is supposed to empty. See http://www.freepascal.org/docs-html/rtl/classes/checksynchronize.html for more details on this call. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Create and use a wrapper class in java
On 27 Apr 2014, at 23:40, fredvs wrote: Hello Stephano. Did you put each class in a separate file? Yes, of course, it is the goal : = a separate wrapper class (TheWrapper.java), with all the methods defined to use the library, = and the main class (test.java) who uses that wrapper class. So, the same wrapper class way be used by other main class... But impossible to find how to do that... ;-( Just a guess here, but what command did you use to run the `main class`? Something like `java test` of rather `java TheWrapper`? From the message you get it seems to me you ran the latter. If true then try the former. Finally, instead of immediately going for the JNI approach, try to get the wrapper class working with something that simply prints something to stdout (System.Out.println() if I'm not mistaking?). Your chances of getting help with some extremely simple bit of java code are a lot better that case IMHO. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error compile library on Linux.
On 26 Mar 2014, at 23:15, fredvs wrote: Also, delete all the *.ppu and *.o of previous compile. FWIW: Removing all of them when you get weird errors always does the trick here. You can probably count yourself lucky as I once had a project with an outdated .o file that *did* link. Took me an our or so to track that one down :-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
On 14 Feb 2014, at 20:06, Fred van Stappen wrote: Hello. It seams to me that i monopolize the forum here. Please advice if it borrow you, i will stop directly... ;-) I still fight with cmem and trust me, it is a hard battle. What I have been wondering for some time now (perhaps you wrote it in a mail and I missed it): do you use the same memory manager in the library and in your test program? Also, beware when returning pointers. Consider this snippet: Procedure ReturnTheAnwer: PInteger; Var a: Integer; Begin a:= 42; Result:= @a; End; One might think at first glance that `ReturnTheAnswer^` is 42, but this is incorrect in some cases. The example here might be extremely over-simplified, but replace `a: Integer` with `mystring: String` and we're roughly at your example. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
On 14 Feb 2014, at 20:28, Fred van Stappen wrote: What I have been wondering for some time now (perhaps you wrote it in a mail and I missed it): do you use the same memory manager in the library and in your test program? Oops, indeed i forget that point... The test now are with cmem only in program, not in library. I will test with cmem into library too... That that is issue number 1: if your program wants to free something that your library allocated, both operations need to be done by the same memory manager. The example here might be extremely over-simplified, but replace `a: Integer` with `mystring: String` and we're roughly at your example. Hum, absolutely, it is the same example... So, how must i do to use PChar ? The way I use to pass strings from C/C++ libraries is to allocate a buffer, copy the contents of the string into the buffer and return the pointer to that buffer. The same method can be used here. Also don't forget to provide a second function to free these buffers (in this way your library can have a different memory manager than your application). So you might try something along the lines of: Function ConvertToPChar(str: String): PChar; Begin Result:= Getmem(Length(str) + 1); // Allocating the buffer somewhere on the heap If Length(str) 0 Then Move(str[1], Result[0], Length(str)); // The content Result[l]Length(str)]:= #0; // The null termination End; ..., where I decided to return `standard` null-terminated strings, since your library is meant to be `universal`. Next, the procedure to free buffers using the memory manager of the library: Procedure FreeBuffer(Buffer: Pointer); Begin FreeMem(Buffer); End; That's it for the library part. In your program part, don't forget to free these buffers once they are no longer needed. Also note that this is a good approach with respect to `universiality`, but if you need to pass a lot of strings to and fro you would be better off with a more pascalish version. The thing that comes to mind here is providing a function in your library that replaces the current memory manager with the one passed to it as an argument. This would allow you to simply return a string. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
On 13 Feb 2014, at 22:25, Fred van Stappen wrote: @ Tomas, in earlier topic, you give result of gdb with much more details, how did you do it ? (i used bt, like you explained, but see the result, it is with much less details than yours... bt full ? But if you don't have debug info for your library this won't help you much. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] how to pass a procedure address and execute it?
On 24 Jan 2014, at 21:20, waldo kitty wrote: On 1/23/2014 2:18 PM, waldo kitty wrote: following up on this, how do i pass parameters to doThis and doThat?? do i have to use an intermediate pre_doThis and pre_doThat which handles the calls from centralControl and then calls doThis and doThat with the necessary parameters? Simply change the type: Type TProc = Procedure(aRecord: somerec); Then you can call whichProc (in centralControl) with your argument of choice. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] how to pass a procedure address and execute it?
On 24 Jan 2014, at 22:20, waldo kitty wrote: On 1/24/2014 3:18 PM, Ewald wrote: On 24 Jan 2014, at 21:20, waldo kitty wrote: On 1/23/2014 2:18 PM, waldo kitty wrote: following up on this, how do i pass parameters to doThis and doThat?? do i have to use an intermediate pre_doThis and pre_doThat which handles the calls from centralControl and then calls doThis and doThat with the necessary parameters? Simply change the type: Type TProc = Procedure(aRecord: somerec); Then you can call whichProc (in centralControl) with your argument of choice. ahhh! that helps to explain what the compiler error was that i was seeing... so i may need two different types if each procedure called from centralControl has different parameters? Basically yes (if you mean different parameter types/ different parameter order -- the name in the procedure/function type is merely descriptive AFAIK). But if you have many procedures, I'd go for a class: TCentralControl = Class Protected Procedure Callback1; virtual; abstract; Procedure Callback2(value: TSomeRec); virtual; abstract; Function Callback3: Boolean; virtual abstract; ... and so on ... Public Procedure CentralControl(.); End; Then simply inherit from this class a few times for the different scenario's you want to cover. won't that cause a conflict if the parameters are not the same or are in different ordering or even if some procedure doesn't have parameters at all? Yes, you would need a lot of parameters if you need a lot of callbacks. if this is the case go for the OOP approach; it is perfectly suited for this kind of thing. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] how to pass a procedure address and execute it?
On 23 Jan 2014, at 20:18, waldo kitty wrote: i'm trying to use one routine (centralControl) to process data from two different routines (inputThis and outputThat)... the one routine (centralControl) needs to call one of two other routines (doThis or doThat)... how? :( First define a type to make your like easier: Type TProcType: Procedure; Next, adjust contralContol's prototype: procedure centralControl(var aValue : word; theRecord : somerec; whichProc: TProcType); And you're done:-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] CPPClass Documentation?
Hi, This morning, I saw on fpc-devel a message titled `CPPClass`, which made me wonder if this keyword means what its name implies. Sadly though, there is not much documentation on this subject (read: none I could find other than some messages in the mailing list archive). Is there anyone who could shed some light on this? (Links to documentation I missed will do :-) ) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CPPClass Documentation?
On 18 Jan 2014, at 14:49, Michael Van Canneyt wrote: CPPClass - to the best of my knowledge - does not work. An attempt to implement it was made once, but never was finished. That's why you don't find any documentation on it. Yeah, that explains it indeed. Thanks for the pointer! -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CPPClass Documentation?
On 18 Jan 2014, at 15:22, Sven Barth wrote:
On 18.01.2014 13:45, Ewald wrote:
Hi,
This morning, I saw on fpc-devel a message titled `CPPClass`, which made
me wonder if this keyword means what its name implies. Sadly though,
there is not much documentation on this subject (read: none I could find
other than some messages in the mailing list archive).
Is there anyone who could shed some light on this? (Links to
documentation I missed will do :-) )
It's a experimental feature in its infancy. Some years old already and a few
years ago a bit improved by me. So currently you can import C++ classes
(generated by GCC or CLang!) that either have static methods or non virtual
ones and call them. What currently does not work is instantiation and
destruction of such classes, using virtual methods, operator overloads and
C++ exceptions. I still plan to improve this feature further, but with all
one needs to find time...
I really hate to lengthen other people's todo lists, but don't forget
namespaces ;-) Anyway, good luck the implementation of these cool features!
For its usage you can take a look at $fpc/tests/test/cg/tcppcl{1,2}.pas with
the corresponding C++ files residing inside the obj/ subdirectory of cg/.
That helps, thanks!
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 17 Jan 2014, at 17:25, Ludo Brands wrote:
On 01/17/2014 05:09 PM, Fred van Stappen wrote:
I don't know if the Handle type in the header is defined by the C++
compiler
or by the package itself. Consult their respective documentation for more
info.
Here declaration of create instance :
// Create a new instance of SoundTouch processor.
SOUNDTOUCHDLL_API HANDLE __cdecl soundtouch_createInstance();
That routine is defined in SoundTouchDLL.cpp which is the windows dll
wrapper.
Note one detail: it is declared there as __stdcall, not as __cdecl, so perhaps
this has something to do with it?
@Fred: Also note that the type HANDLE is defined there as a pointer, so [as a
sanity test of sorts] sizeof(Handle {in pascal}) should be equal to
sizeof(HANDLE /*in C/C++*/).
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 17 Jan 2014, at 20:40, Fred van Stappen wrote: Yep, there is a brand new wrapper from trunk : Ha, then you use/compiled a different version. Since a `extern C` preserves the symbol name (that is the trick I use to link in a lot of external C++ code: just put extern C in front of the symbol). or it could be that I am completely missing something here. [for example: is the symbol `DLL_EXPORTS` defined at compile time?] -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 17 Jan 2014, at 21:14, Fred van Stappen wrote: Ha, then you use/compiled a different version. Since a `extern C` preserves the symbol name (that is the trick I use to link in a lot of external C++ code: just put extern C in front of the symbol). or it could be that I am completely missing something here. [for example: is the symbol `DLL_EXPORTS` defined at compile time?] Hum, just put extern C in front of the symbol (no capito ;-( ) What I'm trying to say is that if there is `extern C` in front of a symbol, C++ won't mangle the name. In the cpp file you attached in one of your previous mails, [assuming a C++ compiler] this is the case as per the expansion of the macro `SOUNDTOUCHDLL_API`; on one condition: that `DLL_EXPORTS` is defined. [hint: read ahead to the second part first as it might just solve your problem] Since you see mangled names, there must be an error or version mismatch somewhere in your build of the library. So I thought that perhaps you are using a compiled version of the library that still uses stdcall instead of cdecl. To get closer to the bug, try the following: - Compile with debug symbols everwhere (there is no such thing as overkill ;-) ) - Run your program in gdb and get a backtrace (`bt` on the command line of gdb), if the crash occurs at the end of the function in the library, or just after the call, then it might be a calling convention issue. If I am informed correctly (see http://stackoverflow.com/questions/3404372/stdcall-and-cdecl) then the difference between stdcall and cdecl lies in who cleans up the stack. A mismatch results in the stack being cleaned up twice or not at all. Both rather inconvenient to normal program flow. If this is the case, try changing calling conventions. PS2 : We gonna get it, im sure... [The Second Part --] Well, it seems I have found something interresting here (as already suggested by Marco); you don't define THandle in your library wrapper. THandle is defined as a longint (http://www.freepascal.org/docs-html/rtl/system/thandle.html), but you need a pointer. Try putting `Type THandle = pointer;` somewhere before the first usage of this type in your library wrapper. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 13 Jan 2014, at 17:33, Fred van Stappen wrote: Hello and many thanks to help. Here demo to show the problem (i hope). https://sites.google.com/site/fiensprototyping/dynlib_vs_windows.zip in the dynlibs version, why do you use `PChar(1)` or `PChar(2)` [or ] instead of the name of the function as the second argument in GetProcAddress()? Perhaps try `GetProcAddress(LibHandle, 'soundtouch_clear');` on line 54 and modify the rest in a similar fashion? Hope it helps. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 13 Jan 2014, at 23:06, Fred van Stappen wrote: The SoundTouch.dll uses index to call the procedures. Like that : [Ordinal/Name Pointer] [ 0] soundtouch_clear [ 1] soundtouch_createInstance [ 2] soundtouch_destroyInstance That explains why it works in windows probably, there you can specify an index to go with your exported procedures IIRC. I don't know if this is possible though on *nix. Have a look at http://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx ; there it says that if you pass in a pointer with value where the high order word is zero, it is interpreted as an ordinal value. The same does not apply to the dynlibs version. try `GetProcAddress(LibHandle, 'soundtouch_clear'); I have try that, but it does not work...` What is the result of the call (GetProcAddress)? nil? if so then try to find the names of the symbols defined in the shared object (nm comes to mind). Now, for the windows version, I don't know what underlying mechanism dynlibs uses under windows, so I'm afraid I can't really comment on that platform, except that you could try a similar approach as on linux (use symbol names instead of indices). OTOH it could (?) be that the the compiler inserts code to typecast PChar(1) to a string, which could result in an access violation (try `var a: string; a:= pchar(1);` to try it out ;-) ). -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MD5 decryption?
Once upon a time, silvioprog said: Hello, How to decrypt a MD5 in FPC?: MD5 is a hashing algorithm, not an encryption algorithm. There is more than one input for this algorithm which will generate the same hash, as opposed to a cipher. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MD5 decryption?
Once upon a time, silvioprog said: 2013/12/11 Ewald ew...@yellowcouch.org mailto:ew...@yellowcouch.org Go to: http://md5decryption.com http://md5decryption.com/ In Please input the MD5 hash that you would like to be decrypted: field, put: 7db4a8dae498d1b4686ebd1f79326602 See the result in Decrypted Text: field. Yes, I've seen the site, what they probably do is a reverse lookup in a table, but it cannot be called `decryption`. Encryption is two way: an output can be converted back to the original input. This is not the case with a hashing function. Take for example a very simple function that xor's all input bytes together (with MD5 it boils down to the same, albeit a bit more complex). If I give you the output $F0, how do you know what was the original input? The answer is you don't. It could be [$80 $70] as well as it could have been [$C0 $FF $30 $FF]... While both algorithm types (encryption and hashing) are related (the above xor example classified as a checksum, whereas xor encryption also exists), they are definitly not the same. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MD5 decryption?
Once upon a time, Michael Van Canneyt said: You should read the description. They look in a database. They don't do actual decryption. Yep, that's what I did, I even looked at the little line advertising how much records they had in their database. Most unfortunately though it cannot be called decryption. If I would advertise a bicycle as a car to you there would also be some confusion don't you think :-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] identifier not found case probelm
Once upon a time, rambo waz here said:
at the moment i have a case where each choice leads off to a procedure. ..
looks like this
repeat
writeln('Main Menu');
writeln('1. New Customer Info');
writeln('2. Withdrawal');
writeln('3. Returns');
writeln('4. Money owed by customer');
writeln('5. Quit the Program');
readln(menu_choice);
if menu_choice in [1..5]
then case menu_choice of 1: new_customer;
2: withdraw;
3: returns;
4: money_owed;
5: writeln('stop')
end
else writeln('1..5!)
until choice = 5
but when i try to run it it comes up with an error saying identifier not
found and highlights each of the case choices .. i.e. 3: returns;
.. any help ? :( :( :(
And where exactly are these functions (`returns`, `withdraw`, etc...)
defined? I can't see them either by looking at your code... Perhaps a
minimal working example would be handy?
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support
Once upon a time, Marcos Douglas said: Do you (all) use prefix in Procedures and/or Functions too? ;-) Unitname.GetHandler() ? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get empty memory quickly or... an empty file
Once upon a time, Reinier Olislagers said: However, I'm sure there must be quicker ways (e.g. less newbie code; using OS functions to quickly create empty memor, or alternatively create a sparse file and zip the file instead of the stream). Have you tried FillChar(), FillDWord(), ... I not, have a look at http://www.freepascal.org/docs-html/rtl/system/fillchar.html -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] synapser freezes on fopen(FDevice, 0_RDWR or 0_SYNC) on raspberry Pi
On 08 Jul 2013, at 12:09, Dennis Poon wrote: However, when I extract the relevant code from that example and use the normal fpc compiler (2.6.0) instead of the pparm (2.6.2) and special fp lib inside that zip, my program freezes on synapser.pas TBlockSerial.Connect at the line of fopen(FDevice, 0_RDWR or 0_SYNC). Well, I recently had a similar issue, on Mac OS X and an USB to Serial converter (which had an FTDI chipset) -- maybe this issue is similar. The fix was really quite easy, but it took me a while to find out. Assume your fpOpen() call returns a handle called `Handle`. Now add the following lines after your open call: ===Code=== Var Attr: TTermios; tcgetattr(Handle, @Attr); Attr.c_cflag:= Attr.c_cflag or CREAD or CLOCAL; // -- This is the line that fixed the issue //Do fix your other attributes here aswell, like ispeed, ospeed, etc... tcsetattr(Handle, TCSADRAIN, @Attr);// Take a look at the documentation of this call to see what constant (TCSADRAIN) you want to use. ===EOC=== Hope it helps! -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream.ReadBuffer doesn't try hard enough to read the requested bytes
On 16 Jun 2013, at 03:18, Michalis Kamburelis wrote: Ewald wrote: And what with non-blocking pipes pipes? Wait for a *some* period until you get all data? It is up to the programmer to do this INHO. If you want to get partial data (instead of waiting until all requested data is available) you should just use TStream.Read instead of TStream.ReadBuffer. Then it's indeed up to the programmer to handle this. Sorry, I misread your mail last night (it was getting late I believe), I thought you said `TStream.Read` instead of `TStream.ReadBuffer`. In this case you are probably right. Also, if you would enforce this behaviour on all kinds of streams, you might (`will`, actually) get unexpected performance drops... I don't see why you would get any performance drop. If you're lucky and a single Read call is all you need, then the speed is the same as current implementation, since the 1st check if Read(Buffer,Count)Count then will return false and we will not call Read again. Never mind, my brain was still thinking on the wrong call here. Sorry for the noise there :-) But if you work with a blocking fd (which, for example, a TFileStream uses IIRC) you will always get your data. If there is more data to be read(), but it would take time, it simply takes time. The only case where zero is returned, is IIRC (like you quoted) when the end of the `fd` (e.g. pipe, socket, file) is reached on *blocking filedescriptors*. Yes, zero is returned only if stream ends. But a result that is non-zero, but still less than requested Count, doesn't tell you if the stream ends. The whole point is whether ReadBuffer should take this into account. If the `ReadBuffer` call uses `Read` to read the data (which would be rather obvious) than yes, it would need to take this into account as it cannot know which subsystem `Read` uses. FYI: I've never had the problem of a `partial read` (e.g. SomeStream.Read(50) returning 36 or something) on linux, osx and windows; so perhaps you have exposed some bug in an obscure TStream descendant? Reproducing this behavior proved to be difficult, but I definitely observed it with TFileStream on Linux. Did it got interrupted by a signal then? Or perhaps the `Count` argument of `ReadBuffer` was greater than SSIZE_MAX? Either way, as ReadBuffer gives no information about the number of bytes actually read, it should indeed `try harder`. And, even if it would accidentally work for some streams, that's not a solution. Like I mentioned, TStream.ReadBuffer is non-virtual and must be suitable for every TStream. The question that arises here is whether all the `ReadByte`, `ReadWord`, `WriteByte`, `WriteWord`, `WriteBuffer`, ... should also `try harder`? Same issue there: no data is returned about the actual number of bytes read. Anyway, I leave that to someone who knows the internals of these classes. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream.ReadBuffer doesn't try hard enough to read the requested bytes
On 16 Jun 2013, at 01:08, Michalis Kamburelis wrote: Which means that ReadBuffer should retry calling Read, in a loop, trying to finish the reading. ReadBuffer should raise an exception only when Read returns zero (before we can gather all the Count bytes). And what with non-blocking pipes pipes? Wait for a *some* period until you get all data? It is up to the programmer to do this INHO. Also, if you would enforce this behaviour on all kinds of streams, you might (`will`, actually) get unexpected performance drops... For example: on Linux, TFileStream.Read calls fpRead which is a system call, and it definitely can return less than requested amount of bytes, and it doesn't mean that stream ended. (See e.g. Libc docs: http://www.gnu.org/software/libc/manual/html_mono/libc.html#I_002fO-Primitives : If read returns at least one character, there is no way you can tell whether end-of-file was reached. But if you did reach the end, the next read will return zero. ) So if you use TFileStream with ReadBuffer, your code is working purely by accident right now... But if you work with a blocking fd (which, for example, a TFileStream uses IIRC) you will always get your data. If there is more data to be read(), but it would take time, it simply takes time. The only case where zero is returned, is IIRC (like you quoted) when the end of the `fd` (e.g. pipe, socket, file) is reached on *blocking filedescriptors*. Note that the above is a rather sumarized explanation, but it should make the point. FYI: I've never had the problem of a `partial read` (e.g. SomeStream.Read(50) returning 36 or something) on linux, osx and windows; so perhaps you have exposed some bug in an obscure TStream descendant? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can someone please explain the linker to me?
Once upon a time, Anthony Walter said: On 13.04 this broke and I found there was no libssl.so in /usr/lib but there was a libssl.so.1.0.0 in /lib/x86_64-linux-gnu/libssl.so.1.0.0. I then created a symbolic link to that shared object in my /usr/lib folder named libssl.so and everything worked, or so I thought. When I tried to use the crypto functions again on 13.04 the linker said it couldn't link libcrypto, so it would seem that on one distro the crypto function are in libssl while in another they are in libcrypto okay I guess that happens. But the the weird thing is I created a symbolic link from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 to /usr/lib/libcrypto.so.1.0.0 and when I switch my pascal code to use external 'libcrypto.so.1.0.0' I still get the linking error stating that libcrypto could not be found. I had to create the symbolic link as /iusr/lib/libcrypto.so and then it worked. Perhaps libopenssl references libcrypto, and thus you need both in your library search path. By the way, why son't you just add your `/lib/x86_64-linux-gnu/` directory to the library path? I believe there was an command line option for fpc that did that (or you can maybe pass a similar option to the linker directly). [not tested: try adding `-Fl/lib/x86_64-linux-gnu/` to the fpc command line?] Having a thought I renamed my external to this garbage external 'libcrypto.so.1.2.asdasd' and it compiled and everything still works. So it would seem that the linker is is ignoring everything outside the word 'crypto' and requires I specifically name the files 'libcrypto.so' and 'libssl.so'. IIRC the part after `.so` is considered a version number (or indication thereof). The behaviour you are seeing is *probably* that the linker could not find `libcrypto.so.1.2.asdasd`, so it decides to use the one it found instead. Anyway, I don't know that much about `the linker` either, but this would be my guess. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Placing binary data (resources) in object files?
Once upon a time, Tomas Hajny said: On Mon, June 3, 2013 18:09, Ewald wrote: Well, you can obviously use tool bin2obj created with/for FPC and distributed with FPC releases - see fpcsrc/utils/bin2obj.pp. Seriously? I should really start looking at included tools... I've got this feeling that it will save me some time. Anyway, reinventing the weel was quite fun ;-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Placing binary data (resources) in object files?
Once upon a time, Anthony Walter said:
I am trying to come up with an embedded binary resource system and was
considering placing data in object files when I found this question on
stack overflow:
http://stackoverflow.com/questions/4158900/embedding-resources-in-exe-using-gcc
I see that it's possible to directly turn any file into an object file
and reference the memory of that as a resource in a C program using:
extern char binary_foo_bar_start[];
extern char binary_foo_bar_end[];
My question, is it possible to link extern char in free pascal in a
way similar to above? Perhaps something similar to:
var binary_foo_bar_start: pointer; external;
{$L foo.bar.o}
Or some permutation of the above?
You can pass an option directly to the link ( add -k--format=binary
-kbinary files you wish to embed -k--format=default to the fpc command
line), or you could use objcopy.
These two aproaches aren't very portable though, so it is best you write
a script or something that generates code that contains this file.
Something like this:
===php code begin===
?php
function ObjCopy($file, $name, $outputname = 0)
{
$contents = file_get_contents($file);
$size = strlen($contents);
if ($outputname === 0)
$outputname = blob_$name.o;
$invalidsymbolcharacters = array('!', '@', '#', '$', '%', '^', '',
'*', '(', ')', '_', '+', '-', '=', '[', ']', '{', '}', '\'', '\\', '',
'|', ';', ':', ',', '.', '/', '', '', '?', '`', '~');
$name = str_replace($invalidsymbolcharacters, '_', $name);
$data = '';
for ($cnt=0; $cnt $size; $cnt++)
$data.= '0x'.dechex(ord($contents[$cnt])).',';
$data = substr($data, 0, -1);
$tmpfile = #include cstddef\n;
$tmpfile.= extern \C\ const size_t _binary_{$name}_size = $size;\n;
$tmpfile.= extern \C\ const char _binary_{$name}_start[] =
{{$data}};\n;
$tmpfile.= extern \C\ const char* _binary_{$name}_end =
_binary_{$name}_start[0] + $size-1;\n;
fwrite($handle = popen(gcc -o '$outputname' -c -x c++ - -O3 -Wall
-pipe, 'w'), $tmpfile);
pclose($handle);
}
?
===php code end===
Usage: `ObjCopy('binaryinputfile', 'symol name',
'outputobjectfile.o');`. Then add `-koutputobjectfile.o` to the command
line of fpc. Next you can define your symbols in pascal as follows:
{$escapedpascalname}_start: array[0..$length-1] of cuint8; external
name '_binary_{$escapedname}_start';
{$escapedpascalname}_end: array[1-$length...0] of cuint8; external
name '_binary_{$escapedname}_end';
{$escapedpascalname}_size: array[0..0] of cuint8; external name
'_binary_{$escapedname}_size';
Where {$escapedpascalname} is the name you gave as the second argument
to the function above. `$length` is the length of the original data in
bytes. To read the size, just use `csize_t(@{$escapedpascalname}_size)`.
Note that the above is a very quick draft (kind of a quickfix for some
other project -- but is works) and thus contains errors and lacks error
checking. Use at your own risk ;-)
PS: Sorry about the php code there; I know it's not the php mailing
list, but my buildtool happens to be written in php ;-)
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Placing binary data (resources) in object files?
Once upon a time, Rainer Stratmann said: For me this seems (too) complicated to do an easy thing (including some data). That, and I don't think that ld on mac os x can handle `-b` (or --format). -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to handle External:SIGPIPE on linux
On 01 Jun 2013, at 08:51, Dennis Poon wrote:
Ewald,
Please kindly share your sample codes for both approaches.
Thanks a lot
Right, here you go:
*** fpSignal() ***
First you declare a function which is going to handle the signal (SignalHandler
in my example), then you just call
fpSignal(SIGPIPE, @SignalHandler);
An example program:
===code begin===
Program SignalTest;
Uses sysutils, baseunix;
Procedure SignalHandler(SigNo: cint); cdecl;
Begin
If SigNo = SIGPIPE Then WriteLn('Received SIGPIPE.');
End;
Begin
fpSignal(SIGPIPE, @SignalHandler);
while true do sleep(5000);
End.
===code end===
Compile using `fpc SignalTest.pas`. Whilst running it, try sending SIGPIPE to
it (`killall -PIPE SignalTest`) and it should write something to stdout.
***pthread_sigmask()***
It basically comes down to:
- Emtying a signal set
- Adding the signals you wish to block
- Calling pthread_sigmask with this set and SIG_BLOCK as arguments.
And example program:
===code begin===
Program SigmaskTest;
Uses sysutils, baseunix, pthreads;
Var
ToBeBlocked: sigset_t;
Begin
fpSigEmptySet(ToBeBlocked);
fpsigaddset(ToBeBlocked, SIGPIPE);
pthread_sigmask(SIG_BLOCK, @ToBeBlocked, nil);
while true do sleep(5000);
End.
===code end===
Compile using `fpc SigmaskTest.pas`. Whilst running it, try sending SIGPIPE to
it (`killall -PIPE SigmaskTest `) and it should continue running.
NOTE: this function will need to be called by each thread that wishes to block
this signal, except in the case where the parent thread already has this signal
blocked, as newly created threads inherit their parents sigmask (according to
http://linux.die.net/man/3/pthread_sigmask)
Hope it helps!
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error: Duplicate identifier FarPointer
Are you building with 2.7.1? If so, try building with 2.6.2. (don't ask me why, but it worked for me) On 15 May 2013, at 17:01, silvioprog wrote: Hello, Today I updated my GIT copy of FPC, and after I try to make it and install, I got this error: http://pastebin.com/90fhy34Y Until last week everything was normal. Thank you! -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to close TInetServer without except?
On 03 May 2013, at 00:15, Zaher Dirkey wrote: On Fri, May 3, 2013 at 12:51 AM, Ewald ew...@yellowcouch.org wrote: pthread_cancel() pthread_cancel() not close the handles i though. That's true, but at least it returns control to you (= the programmer), so you can close the handles manually. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to close TInetServer without except?
On 03 May 2013, at 11:30, Zaher Dirkey wrote: On Fri, May 3, 2013 at 12:18 PM, Ewald ew...@yellowcouch.org wrote: That's true, but at least it returns control to you (= the programmer), so you can close the handles manually. I am notprefer force to close any thing, that will make more bugs in your application, while it is work fine with other programmesr without using cancel it. Neither do I, but wasn't that what Silvio asked? [by saying: `The problem now is how to stop the Accept but without errors`] I admit, killing an entire thread is a bit overkill for just getting back control from accept, but I also recall that he wanted to close the application [or am I seeing ghosts?]. But if you don't want to use pthread_cancel(), use non-blocking sockets -- In my experience though, it isn't worth the code if you just want to kill the application gracefully. Anyway, I'm sure there are other ways to get this done (signals?), but these are two methods I know about. Each has it's bonuses and pitfalls. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to close TInetServer without except?
Once upon a time, Zaher Dirkey said: On Fri, May 3, 2013 at 7:22 PM, Ewald ew...@yellowcouch.org wrote: Accept but without errors You cant, Accept give you a handle of new socket or give you an error, not all is fatal error, just check what is it, if it a closed handle or shutdown. Yes, I know that. The point being that the answer to one of the OP sub-problems [the one quoted _partially_ above], can be to either use: - pthread_cancel() [overkill, I know, but nonetheless a solution] - non-blocking sockets [not very code-efficient IMHO if you only want to exit an application gracefully (high code versus ouput ratio)] - something different (one can try experimenting with shutting down the listening socket, using signals, ... but I haven't done so, so I can't give any feedback on this) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to close TInetServer without except?
On 03 May 2013, at 20:13, Marco van de Voort wrote: In our previous episode, Ewald said: The point being that the answer to one of the OP sub-problems [the one quoted _partially_ above], can be to either use: - pthread_cancel() [overkill, I know, but nonetheless a solution] - non-blocking sockets [not very code-efficient IMHO if you only want to exit an application gracefully (high code versus ouput ratio)] - something different (one can try experimenting with shutting down the listening socket, using signals, ... but I haven't done so, so I can't give any feedback on this) Select on the main socket before doing the accept? Yep, possibly the most simple and effective recipe (not much code to add, no radical changes, no overkill). Shame on me for not thinking of that ;-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to close TInetServer without except?
On 03 May 2013, at 22:56, Zaher Dirkey wrote: On Fri, May 3, 2013 at 11:47 PM, Zaher Dirkey parm...@gmail.com wrote: On Fri, May 3, 2013 at 11:27 PM, Marco van de Voort mar...@stack.nl wrote: That's the point. Don't. Use a select, it has a timeout, and accept only if select shows activity on the listened to socket. Not sure, but i believe i used it in the past and have problems with it, We can leave it to silvio to test it :P I use Select for incoming Data not for incoming client connections! It doesn't matter. A few facts: - You create a listening socket which you pass as an argument to accept(). - A socket is a file descriptor. - Select operates on file descriptors. Read the man page of select [http://linux.die.net/man/2/select] and you'll see that the exact purpose of select is to query whether or not the next IO operation is going to block. Now that we have established these two facts, I believe that using select before accept to check whether the latter will block is valid logic, wouldn't you say? PS: The exact details of this implementation I do not know, I haven't tested. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to close TInetServer without except?
On 02 May 2013, at 22:00, silvioprog wrote: Lines 277 and 278. That is, I already do that. The problem now is how to stop the Accept but without errors. Using linux (or some other unix like thingie), you could cancel the thread using pthread_cancel(), the call will then return immediately with a specific (can't remember which) error code in errno (socketerror in this case I believe). Problem with pthread_cancel is that there are quite a lot of cancelation points, see http://stackoverflow.com/questions/433989/posix-cancellation-points , so be careful with this approach. Another way would be to use a non-blocking socket to accept connections... -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to detect connection status of a socket
On 22 Apr 2013, at 15:10, Xiangrong Fang wrote: 1) fpsend() just pass data to the OS's socket layer without try to determine if the connection is still alive, right? I suppose, but there exists an error code that might come in handy: ENotConn (see http://linux.die.net/man/2/send), which is returned by send(). 2) is it normal that in BLOCK mode, recv returns 0? i.e. if I receive a 0 from fprecv(), I can say that the connection is closed by the other end (if there is no detectable socketerror), right? Yes, if recv() return 0, it mens the client disconnected. If it returns -1, errno will be set. From http://linux.die.net/man/2/recv (see `return value`): These calls return the number of bytes received, or -1 if an error occurred. The return value will be 0 when the peer has performed an orderly shutdown. Note that even in non-blocking mode, 0 means the socket is closed. If you received no data yet, you will get -1 as a return value and errno will be set to EAgain of EWouldBlock (see the link above). Does this help or am I completely talking besides the point? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Function header doesn't match error
Once upon a time, Mark Morgan Lloyd said: I wonder whether anybody could throw some light on a curious error. I've just tried to move a class definition into the interface part of a unit, so that I could easily add a class helper, but I'm getting an error borgumserverinterface.pas(927,24) Error: (3048) function header doesn't match any method of this class TzzConnection.ExecuteSQL2(TStringList,Boolean=FALSE):Boolean; If I move the class back into the implementation part there's no error. Simplified code as below: interface uses Classes, SysUtils, StrUtils, BorgUMFingerD, BorgUMCode, sqldb; type TzzConnection= class(TObject) .. public .. function ExecuteSQL2(sl: TStringList; relaxInuseCheck: boolean= false): boolean; .. implementation uses pqconnection, ibconnection, Custom, postgres3dyn, ibase60dyn, Regexpr; .. function TzzConnection.ExecuteSQL2(sl: TStringList; relaxInuseCheck: boolean= false): boolean; .. It's that final declaration that goes wrong, but I can fix it by moving the class back into the implementation part. FPC 2.6.2 on Linux x86. Just and idea: Can it be that you redefined TStringList (or boolean for that matter, but that doesn't strike me as obvious) in oneof the units you used in your implementation section? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
Once upon a time, José Mejuto said: El 28/03/2013 1:06, Ewald escribió: Sorry to just drop in on this quite late, but isn't gzip a compression algorithm and not a file format as such? gzip (the command line utility) only compresses one file and *doesn't* put this in a multi-file container. To get `multi-file gzips`, you will first want to bundle the files and compress this bundle (files - tar - gzip) or compress the files separately and then bundle them together (files - multiple separate gzipped files - tar). Or are we talking about a different gzip here? Hello, Just quoting the RFC1952 about .gz format: --- http://tools.ietf.org/html/rfc1952 2.2. File format A gzip file consists of a series of members (compressed data sets). The format of each member is specified in the following section. The members simply appear one after another in the file, with no additional information before, between, or after them. --- So I think it is legal to concatenate several .gz files and get a final .gz with several files inside. In the other hand, yes, the usual behavior in .gz is to store only one file. Yeah, you're right indeed. Sorry for the noise. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
Once upon a time, Flávio Etrusco said: On Thu, Mar 28, 2013 at 8:51 AM, José Mejuto joshy...@gmail.com wrote: Hello, Just quoting the RFC1952 about .gz format: --- http://tools.ietf.org/html/rfc1952 2.2. File format A gzip file consists of a series of members (compressed data sets). The format of each member is specified in the following section. The members simply appear one after another in the file, with no additional information before, between, or after them. --- So I think it is legal to concatenate several .gz files and get a final .gz with several files inside. In the other hand, yes, the usual behavior in .gz is to store only one file. -- Members refer to each available section according to the flags. Re-read this whole paragraph you posted and a few following you'll realize only one file is allowed in a gzip file/blob. Alright, now I am contradicting what I said earlier, but there can apparently be more than one file in a gzipped `thing`: see https://en.wikipedia.org/wiki/Gzip#File_format . It is not really all files in one container, but more like concatenating serveral of these one-file gzipped files, if you see what I mean. Anyway, I've never seen it happen, so I'm going to leave it at that before I start sounding silly ;-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
On 27 Mar 2013, at 19:54, José Mejuto wrote: El 27/03/2013 19:22, Michalis Kamburelis escribió: Google found an old thread on lazarus mailing list about this (FPC, gzip and stream) but without any solution, everything mentioned there has either the limitations of TCompressionStream/TDecompressionStream (no gzip format) or TGZFileStream (not able to work wit ObjectPascal streams). Hello, .gz is a quite simple format, but it can not be implemented as a TStream (only) descendant because in a single .gz file many files could be added so something like the class to handle .zip files should be used. Sorry to just drop in on this quite late, but isn't gzip a compression algorithm and not a file format as such? gzip (the command line utility) only compresses one file and *doesn't* put this in a multi-file container. To get `multi-file gzips`, you will first want to bundle the files and compress this bundle (files - tar - gzip) or compress the files separately and then bundle them together (files - multiple separate gzipped files - tar). Or are we talking about a different gzip here? So basically (to answer to the subject of this mail), you will only need a stream that implements this algorithm, which you could quite easily write yourself. Take a look at zlibar, it's a project that iirc implements an archive format that uses gzip. Now there are two functions in there that compress and respectively decompress a stream and return the result, also as a TStream descendant. If you cannot find this easily just say it, I've got the code (or at the very least these two functions) lying around. If I just said anything anyone has already mentioned, please forgive me, I've only just read this message and thought to elaborate a bit on it :-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] catch segfaults
Once upon a time, Xiangrong Fang said: Is it possible to use try...except to catch SIGSEGV? I don't know if it is possible, but how about using fpSignal()? See http://www.freepascal.org/docs-html/rtl/baseunix/fpsignal.html -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
Once upon a time, Mark Morgan Lloyd said: No, because the elements in a set are dictated by their position. A set that can contain anything between 0 and 256 elements occupies 8 bytes in memory with the (bit representing the) 0 element at one end and the (bit representing the) 256 element at the other, a set to contain up to (say) 257 elements would require more space and that's not supported. Probably a typo, but 8 bit * 8 bytes = 64 elements. So I suppose you mean `[...] occupies 32 bytes in memory [...]`? Just so nobody gets confused :-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetCurrentThreadID under FreeBSD vs Linux
Hello,
I had the exact same issue when writing debug info in my code. Easy to
solve I think. Just define a macro at the top of the unit like this:
{$macro on}
{$define Debug_ThreadSelf:= ptruint(GetCurrentThreadID)}
And then change all FmtStr lines to something like
FmtStr(LThreadID, '%.4d', [Debug_ThreadSelf]);
And if you don't like macro's, just change all FmtStr lines into
FmtStr(LThreadID, '%.4d', [ptruint(GetCurrentThreadID)]);
It can be that `ptruint` is defined in `unixtype`, but I don't know for
sure.
Once upon a time, on 02/08/2013 03:40 PM to be precise, Graeme
Geldenhuys said:
Hi,
Under Linux and Windows I have the following code which works fine.
var
LThreadID: string;
begin
FmtStr(LThreadID, '%.4d', [GetCurrentThreadID]);
Under FreeBSD (64-bit) that failed with a EConvertError in the unit
tests and the compiler gave a message of 'Invalid argument index in
format %.4d'
Navigating the code to see how TThreadID is defined, I found this for
FreeBSD.
TThreadRec = record end;
TThreadID = ^TThreadRec;
So TThreadID is just a pointer to a record structure. Apparently getting
a real thread ID/number is not as easy as under Linux. [Info from
Google searches]. Under FreeBSD it seems that naming each thread with a
string value is a more supported solution.
I'm not so fussed about the exact ID per thread, so the pointer value
will be fine. Windows uses a THandle and Linux uses a PtrUInt as the
types for TThreadID.
So would it be safe if I did the following in my code? For the Windows,
Linux and FreeBSD platforms at least.
FmtStr(LThreadID, '%.4d', [PtrUInt(GetCurrentThreadID)]);
I've tested the PtrUInt() cast under FreeBSD, Linux and Windows, and it
seems to work fine.
BTW:
This code is only used to supply a thread id/value to a logging function
(file, GUI, console etc) to help with debugging, or at least show which
thread wrote what debug log entries. So it's not critical code.
Regards,
- Graeme -
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
