[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 9-2-2013 1:49, Giuliano Colla wrote: > It turned out that the reason was simply that the default AppConfigDir > (~/.config/ ) wasn't there, and therefore in the two usual lines > > AppConfigFileName:= GetAppConfigFile(False); > ini := TIniFile.Create(AppConfigFileName); > > the second line was generating the access violation. > > Desktop specs tell where configuration data should go, but they don't > guarantee that the directory exists. Other applications take care of > creating if it doesn't exist, but its presence depends on which > applications you launch. > > Of course, once one knows, one can use ForceDirectories in the > application code, but it would be much more user friendly if > XdgConfigHome (or SysConfigDir when it will be implemented) in sysutils > took care of that. You ask for the default configuration path to put > your data in, and you get a sane and *existing* path. > It would also be nice if TIniFile.Create didn't generate an Access > Violation if the file can't be created. > > Should I open an issue on the bugtracker on this subject, or I'm the > only one to think that it's a bug/required feature? > If I were you, I'd open an issue. I agree this is a problem. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: what happened to the "contributed units" listing?
On 7 February 2013 21:23, Michael Van Canneyt wrote: > > > On Thu, 7 Feb 2013, Frank Church wrote: > >> On 7 February 2013 12:35, leledumbo wrote: >>> >>> Bye2 PHP based list, welcome fpweb + ExtJS based list :) >>> >>> >>> >>> -- >> >> >> Do we get the chance to view the code used for FPC/Lazarus >> infrastructure and learn from it and be able to update it? >> >> I don't think web development coding in FPC/Lazarus will take off if >> code samples are not freely available, especially if there are no >> commercial confidentiality issues involved. > > > All FPC code is in the SVN repository. > Are you referring to the code of all FPC/Lazarus web infrastructure coded in FPC or the general FPC web examples? > Michael. > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Fpc Access Violation if AppConfigDir doesn't exist.
Launching a Lazarus application in a freshly installed Linux system, I found a condition which may be quite confusing for a normal user: the main form was shown, the program didn't work, and there was no way to close the form, which could only be closed by a killall from command line. Launching from command line one could only see a TApplication.HandleException Access Violation, which isn't much telling for a normal user either. It turned out that the reason was simply that the default AppConfigDir (~/.config/ ) wasn't there, and therefore in the two usual lines AppConfigFileName:= GetAppConfigFile(False); ini := TIniFile.Create(AppConfigFileName); the second line was generating the access violation. Desktop specs tell where configuration data should go, but they don't guarantee that the directory exists. Other applications take care of creating if it doesn't exist, but its presence depends on which applications you launch. Of course, once one knows, one can use ForceDirectories in the application code, but it would be much more user friendly if XdgConfigHome (or SysConfigDir when it will be implemented) in sysutils took care of that. You ask for the default configuration path to put your data in, and you get a sane and *existing* path. It would also be nice if TIniFile.Create didn't generate an Access Violation if the file can't be created. Should I open an issue on the bugtracker on this subject, or I'm the only one to think that it's a bug/required feature? Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetCurrentThreadID under FreeBSD vs Linux
On 2013-02-08 17:08, Ewald wrote:
> {$macro on}
> {$define Debug_ThreadSelf:= ptruint(GetCurrentThreadID)}
I must confess I haven't used macros in FPC. Also the code I'm working
with is cross platform and cross compiler. I don't know if Delphi
supports such macros. Quick search in Delphi 7 help (lowest Delphi we
support) doesn't list $macro anywhere.
> FmtStr(LThreadID, '%.4d', [ptruint(GetCurrentThreadID)]);
>
> It can be that `ptruint` is defined in `unixtype`, but I don't know for
> sure.
OK, then what I did would suffice for now. Thanks for the feedback.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetCurrentThreadID under FreeBSD vs Linux
On 2013-02-08 20:34, Marco van de Voort wrote: >> 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 > > This is a common construct to define opague types. Sorry if my message wasn't clear. I fully understand that, and wasn't implying that FPC (FreeBSD) was wrong here. After my previous FreeBSD messages and feedback, I knew where to look for the info, and the man pages clearly said it is an opaque type. >> [Info from Google searches]. Under FreeBSD it seems that naming each >> thread with a string value is a more supported solution. > > Note that under Windows threads can be named on API level too. VS and Delphi > (2010+ iirc) will show such threads in the debugger with a familiar name. As far as I know (I could be wrong though) Linux can't name threads. And again, the code I'm working on in tiOPF is cross platform and cross compiler. As I said, the Thread ID info is only used for debugging and not something critical. There must just be some value differentiating between various threads, when they output to the logger. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetCurrentThreadID under FreeBSD vs Linux
In our previous episode, Graeme Geldenhuys said: > Under Linux and Windows I have the following code which works fine. > > var > LThreadID: string; > begin > FmtStr(LThreadID, '%.4d', [GetCurrentThreadID]); Threadids are probably opague under Posix. So while it works, it is not correct on Linux. You add implementation specific details (that it is an integer type) that might change at any time. > 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"' That's correct. > 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 This is a common construct to define opague types. > Apparently gettinga a "real" thread ID/number is not as easy as under > Linux. There is no thread id. See in GDB, you will probably see a pointer value, not a nice increasing sequential number like e.g. PID. > [Info from Google searches]. Under FreeBSD it seems that naming each > thread with a string value is a more supported solution. Note that under Windows threads can be named on API level too. VS and Delphi (2010+ iirc) will show such threads in the debugger with a familiar name. > 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 think while it is safe. Might throw warnings on some systems though (signed vs unsigned conversions, if threadid is signed; or so) > 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. I would simply name the threads using a string, and forget the whole threadid business. If only that the 64-bit pointer values can get unwieldy large and hard to read. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetCurrentThreadID under FreeBSD vs Linux
Am 08.02.2013 18:09 schrieb "Ewald" : > It can be that `ptruint` is defined in `unixtype`, but I don't know for > sure. "PtrUInt" (and "PtrInt") are declared in unit "System". Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStringList.InsertItem
On 2/8/13, Michael Van Canneyt wrote: > It could do that, feel free to provide a patch :) Done: http://bugs.freepascal.org/view.php?id=23860 Bart ___ 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
[fpc-pascal] GetCurrentThreadID under FreeBSD vs Linux
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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStringList.InsertItem
On Fri, 8 Feb 2013, Bart wrote: Hi, Consider: Procedure TStringList.InsertItem(Index: Integer; const S: string); and Procedure TStringList.InsertItem(Index: Integer; const S: string; O: TObject); 1018 Procedure TStringList.InsertItem(Index: Integer; const S: string); 1019 begin 1020 Changing; 1021 If FCount=Fcapacity then Grow; 1022 If Index It could do that, feel free to provide a patch :) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
