Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
No. Anyway, I change the colum names (id,name to col1, col2) The error is: "Cannot insert the value NULL into column 'col', table tempdb.dbo.#t..." This error has nothing to do with FPC or SQLDB. Your SQL statement is trying to insert NULL in a required field. No Michael, see the example I wrote before. Create table: create table #t (col1 int, col2 varchar(60)) OBS: No column is required. This INSERT works: insert into #t values (1, 'bla bla bla') This INSERT do NOT works: insert into #t (col2) values ('bla bla') Marcos, can you please test with explicitly allowed nulls: create table #t (col1 int NULL, col2 varchar(60) NULL) (MS SQL Server nullability is controled by database setting "*ANSI null default"* so you can check this setting on your temp database also)* *L.* * ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] What's the state of "string"?
I wonder about much code in the RTL/FCL, that depends on String type arguments, like: Procedure TStream.WriteAnsiString (const S : String); Var L : Longint; begin L:=Length(S); WriteBuffer (L,SizeOf(L)); WriteBuffer (Pointer(S)^,L); end; This method will work only as long as String=AnsiString, because Length *bytes* are written, not *chars* of a possibly different byte count. Is the use of generic types, like String, really okay in the library code, when the concrete type matters? The documentation on strings (3.2 Character types) is not really helpful, most entries look like they deserve an update reflecting the role of UnicodeString and the generic String type, and implicit string conversions. In detail I miss instructions on how to determine or specify the String type, with different FPC versions. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, Mar 20, 2012 at 8:12 PM, wrote: > > > On Tue, 20 Mar 2012, Marcos Douglas wrote: > >> On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt >> wrote: >>> >>> >>> >>> On Tue, 20 Mar 2012, Marcos Douglas wrote: >>> No. Anyway, I change the colum names (id,name to col1, col2) The error is: "Cannot insert the value NULL into column 'col', table tempdb.dbo.#t..." >>> >>> >>> >>> This error has nothing to do with FPC or SQLDB. >>> >>> Your SQL statement is trying to insert NULL in a required field. >> >> >> No Michael, see the example I wrote before. > > > I saw the example :-) > > >> >> Create table: >> create table #t (col1 int, col2 varchar(60)) >> >> OBS: No column is required. >> >> This INSERT works: >> insert into #t values (1, 'bla bla bla') >> >> This INSERT do NOT works: >> insert into #t (col2) values ('bla bla') > > > This kind of SQL is passed as-is to MSSQL. To my knowledge, SQLDB does not > change it. > > If you had been using parameters, it would have been a different story. Does matter if I use or not parameters. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, 20 Mar 2012, Marcos Douglas wrote: On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt wrote: On Tue, 20 Mar 2012, Marcos Douglas wrote: No. Anyway, I change the colum names (id,name to col1, col2) The error is: "Cannot insert the value NULL into column 'col', table tempdb.dbo.#t..." This error has nothing to do with FPC or SQLDB. Your SQL statement is trying to insert NULL in a required field. No Michael, see the example I wrote before. I saw the example :-) Create table: create table #t (col1 int, col2 varchar(60)) OBS: No column is required. This INSERT works: insert into #t values (1, 'bla bla bla') This INSERT do NOT works: insert into #t (col2) values ('bla bla') This kind of SQL is passed as-is to MSSQL. To my knowledge, SQLDB does not change it. If you had been using parameters, it would have been a different story. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt wrote: > > > On Tue, 20 Mar 2012, Marcos Douglas wrote: > >> >> No. >> Anyway, I change the colum names (id,name to col1, col2) >> The error is: >> "Cannot insert the value NULL into column 'col', table tempdb.dbo.#t..." > > > This error has nothing to do with FPC or SQLDB. > > Your SQL statement is trying to insert NULL in a required field. No Michael, see the example I wrote before. Create table: create table #t (col1 int, col2 varchar(60)) OBS: No column is required. This INSERT works: insert into #t values (1, 'bla bla bla') This INSERT do NOT works: insert into #t (col2) values ('bla bla') Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] passing options for the build process.
The buildfaq claims that OPT= will add parameters to every compiler commandline. Unfortunately it doesn't seem to actually do that. The options are added when building the compiler and RTL but it seems they aren't added when building fpmake. This is a problem for me as to successfully build fpmake on a multiarch arm system I need to tell it where to find crti.o (it seems freepascal can successfully build stuff linked against c libraries without finding crti.o on some architectures but not others). For now i've created a symlink at /usr/lib/crti.o to /usr/lib/arm-linux-gnueabihf/crti.o to make things work but i'd rather not have to mess with my system in that way. Is there some way of specifying options so that they actually get passed to ALL compiler invocations in the build process? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, 20 Mar 2012, Marcos Douglas wrote: No. Anyway, I change the colum names (id,name to col1, col2) The error is: "Cannot insert the value NULL into column 'col', table tempdb.dbo.#t..." This error has nothing to do with FPC or SQLDB. Your SQL statement is trying to insert NULL in a required field. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
2012/3/20 Marcos Douglas : > On Tue, Mar 20, 2012 at 5:57 PM, silvioprog wrote: >> This error occurs to me too. Please see this video: >> >> http://silvioprog.com.br/video/bug/sqldb >> >> Lazarus 0.9.30.4 r35940 FPC 2.6.0 i386-win32-win32/win64 + openSUSE 12 >> / Windows 7 + PQConnection + PostgreSQL 8.4. > > Silvio, > Thanks for the video... but I think did you wanted to post in this thread: > http://lists.freepascal.org/lists/fpc-pascal/2012-March/032845.html > > Am I right? ;-) > > Marcos Douglas Oops, I confused the link, sorry. ^^' -- Silvio Clécio Site - LazSolutions - LazWebSolutions - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, Mar 20, 2012 at 5:57 PM, silvioprog wrote: > This error occurs to me too. Please see this video: > > http://silvioprog.com.br/video/bug/sqldb > > Lazarus 0.9.30.4 r35940 FPC 2.6.0 i386-win32-win32/win64 + openSUSE 12 > / Windows 7 + PQConnection + PostgreSQL 8.4. Silvio, Thanks for the video... but I think did you wanted to post in this thread: http://lists.freepascal.org/lists/fpc-pascal/2012-March/032845.html Am I right? ;-) Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
This error occurs to me too. Please see this video: http://silvioprog.com.br/video/bug/sqldb Lazarus 0.9.30.4 r35940 FPC 2.6.0 i386-win32-win32/win64 + openSUSE 12 / Windows 7 + PQConnection + PostgreSQL 8.4. -- Silvio Clécio Site - LazSolutions - LazWebSolutions - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, Mar 20, 2012 at 4:00 PM, Michael Van Canneyt wrote: > > > On Tue, 20 Mar 2012, Marcos Douglas wrote: > > > Hi Michael, > Do you have some prediction to include the sources? My apologies, I had totally forgotten; I am buried in work currently. Committed in revision 20522. I didn't commit any examples or tests. Please test if everything works OK. I compiled on Linux 64-bit, I don't have a working FPC/Lazarus 32-bit windows development environment currently. >>> >>> >>> I will do tests. >>> Thanks! >> >> >> I found a bug >> Consider the script: >> create table #t (id int, name varchar(60)) >> >> If I execute: >> insert table #t values (1, 'john') OK >> >> If I execute: >> insert table #t (name) values ('john') ERROR > > > What is the error you get ? > > Probably you need to quote name, as I imagine 'name' is a reserved word. No. Anyway, I change the colum names (id,name to col1, col2) The error is: "Cannot insert the value NULL into column 'col', table tempdb.dbo.#t..." See the code (Insert2 procedure): program t001; {$mode objfpc}{$H+} uses heaptrc, classes, sysutils, sqldb, fileutil, mssqlconn; var tran: TSQLTransaction; conn: TMSSQLConnection; q: TSQLQuery; procedure CreateTable; begin q.Close; q.SQL.Text := 'create table #t (col1 int, col2 varchar(60))'; q.ExecSQL; end; procedure Insert1; begin q.Close; q.SQL.Text := 'insert into #t values (1, ''áéíç'')'; q.ExecSQL; end; procedure Insert2; begin q.Close; q.SQL.Text := 'insert into #t (col2) values (''áéíç'')'; q.ExecSQL; end; procedure SelectAndShow; var s: string; begin q.Close; q.SQL.Text := 'select * from #t'; q.Open; while not q.EOF do begin s := q.FieldByName('col2').AsString; writeln(UTF8ToConsole(s)); q.Next; end; end; procedure Update; begin q.Close; q.SQL.Text := 'update #t set col2 = ''foo'''; q.ExecSQL; end; {$R *.res} begin tran := TSQLTransaction.Create(nil); conn := TMSSQLConnection.Create(nil); q := TSQLQuery.Create(nil); try conn.Transaction := tran; q.DataBase := conn; conn.HostName := 'localhost'; conn.DatabaseName := 'DbTest'; conn.UserName := 'test'; conn.Password := '123'; conn.CharSet := 'UTF-8'; conn.Connected := True; CreateTable; Insert1; SelectAndShow; Insert2; // ERROR here SelectAndShow; tran.Commit; tran.StartTransaction; try Update; tran.Commit; except tran.Rollback; raise; end; SelectAndShow; writeln('Done'); finally q.Free; conn.Free; tran.Free; end; end. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] update on freepascal armhf porting, doubles are working now for singles.
I can now successfully pass doubles to/from C functions on armhf. I've written a test program that passes lots of different combinations of single/double/longint/int64 to C code and all combinations that do not involve singles are working. It would also be helpful to add this test to the testsuite we do have some tests in test/cg but it wouldn't hurt to add more of that type! I've attatched the program that generates the test program, if you need it under a specific license just ask. Currently it is set up to test all combinations of up to four parameters and a more limited set of combinations up to 17 parameters but these are both easilly adjusted to suit. The generator has two modes, if the letter c is passed as the first command line parameter it operates in "pascal calling c" mode. Otherwise it operates in "pascal calling pascal mode". In "pascal calling c" mode two files are generated. testfp.dpr and testfpfunctions.c in "pascal calling pascal" mode only one file is generated. Note that "pascal calling c" mode makes some assumptions about the equivilence of pascal and c basic types. These assumptions should hold on most platforms but there may be some where they do not. program gentestfp; uses sysutils,classes; type ttype = (sin,dou,int,i64); const typenames: array[ttype] of string = ('single','double','longint','int64'); ctypenames: array[ttype] of string = ('float','double','int','long long'); printfspecifiers: array[ttype] of string = ('%f','%f','%ld','%lld'); var paramcount : longint; param: longint; paramcombination: longint; paramcombinationinner: longint; returntype : ttype; paramtype : ttype; t: text; c: text; paramtypes : array[1..17] of ttype; mainparamtype, lastparamtype : ttype; calls: tstringlist; callsofcalls : tstringlist; cmode : boolean; procedure genfunction; var definitionstring : string; callstring: string; cstring: string; functionname : string; begin //generate function name functionname := 'z'; for param := 1 to paramcount do begin functionname := functionname + typenames[paramtypes[param]][1]; end; functionname := functionname + typenames[returntype][1]; definitionstring := 'function ' + functionname; if paramcount > 0 then begin definitionstring := definitionstring + '('; for param := 1 to paramcount do begin definitionstring := definitionstring +char(param-1+byte('a')) + ':' + typenames[paramtypes[param]]; definitionstring := definitionstring + ';'; end; definitionstring[length(definitionstring)] := ')'; end; definitionstring := definitionstring + ':'+typenames[returntype]+';'; if cmode then begin definitionstring := definitionstring+'cdecl;external;'; cstring := ctypenames[returntype] + ' ' + functionname; if paramcount > 0 then begin cstring := cstring + '('; for param := 1 to paramcount do begin cstring := cstring + ctypenames[paramtypes[param]] +' ' +char(param-1+byte('a')); cstring := cstring + ','; end; cstring[length(cstring)] := ')'; end else begin cstring := cstring + '(void)'; end; cstring := cstring +'{ '; if paramcount = 0 then begin cstring := cstring + 'return 0x12beef;'; end else begin cstring := cstring +'printf("'; for param := 1 to paramcount do begin cstring := cstring + printfspecifiers[paramtypes[param]] + ' '; end; cstring[length(cstring)] := '\'; cstring := cstring + 'n"'; for param := 1 to paramcount do begin cstring := cstring + ',' + char(param-1+byte('a')); end; cstring := cstring + ');'; cstring := cstring + 'fflush(stdout);'; cstring := cstring + 'return '; for param := 1 to paramcount do begin cstring := cstring + char(param-1+byte('a')) + '+'; end; cstring[length(cstring)] := ';'; end; cstring := cstring + '}'; writeln(c,cstring); end else begin definitionstring := definitionstring +'begin '; if paramcount = 0 then begin definitionstring := definitionstring + 'result := $12beef;'; end else begin definitionstring := definitionstring +'writeln('; for param := 1 to paramcount do begin definitionstring := definitionstring + char(param-1+byte('a')) + ','' '','; end; setlength(definitionstring,length(definitionstring)-5); definitionstring := definitionstring + ');'; definitionstring := definitionstring + 'result := trunc('; for param := 1 to paramcount do begin definitionstring := definitionstring + char(param-1+byte('a')) + '+'; end; definitionstring[length(definitionstring)] := ')'; definitionstring := definitionstring + ';'; end; definitionstring := definitionstring + ' end;'; end; writeln(t,definitionstring); callstring := 'if '+functionname; callstring := 'd := '+functionname; if paramcou
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
peter green wrote: The bad news is that a number of testcases are still failing. Next on my list is 16 singles. Ok that was easy, a small logic flaw in my code was preventing a parameter being correctly assigned to the last available single precision register when it should have been. And with that fixed all the parameter combinations I try seem to work. Now I just have to clean up my patch and submit it :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, 20 Mar 2012, Marcos Douglas wrote: Hi Michael, Do you have some prediction to include the sources? My apologies, I had totally forgotten; I am buried in work currently. Committed in revision 20522. I didn't commit any examples or tests. Please test if everything works OK. I compiled on Linux 64-bit, I don't have a working FPC/Lazarus 32-bit windows development environment currently. I will do tests. Thanks! I found a bug Consider the script: create table #t (id int, name varchar(60)) If I execute: insert table #t values (1, 'john') OK If I execute: insert table #t (name) values ('john') ERROR What is the error you get ? Probably you need to quote name, as I imagine 'name' is a reserved word. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Fri, Mar 16, 2012 at 9:55 AM, Marcos Douglas wrote: > On Fri, Mar 16, 2012 at 5:40 AM, wrote: >> >> >> On Thu, 15 Mar 2012, Marcos Douglas wrote: >> >>> On Mon, Feb 27, 2012 at 9:33 AM, Marcos Douglas wrote: On Mon, Feb 27, 2012 at 5:08 AM, wrote: > > > > On Mon, 27 Feb 2012, LacaK wrote: > >> Hi, >> let me share same basic info/ideas about TMSSQLConnection : >> 1. As Marcos wrote it is descendant of sql-db TSQLConnection class and >> provides native connector for MS SQL Servers and Sybase servers >> 2. is depends/requires on FreeTDS open-source cross platform DB-Library >> (alternatively can be used also Microsoft db-library ntwdblib.dll) >> 3. all what is needed are 2-3 files: >> - mssqlconn.pp (implementation of TMSSQLConnection and >> TSybaseConnection) >> - dblib.pp (interface to FreeTDS db-library ABI dblib.dll on Windows, >> libsybdb.so on *NIX) >> - readme.txt (some info for users/developers) >> 4. according to market share of MS SQL Server and Sybase there may be >> many >> users, which will welcome alternative to TODBCConnection >> 5. there is on http://www.freepascal.org/future.var in "Improve the >> database support" > "Drivers (descendants) for more database types" so >> I >> understand it as FPC is open for new stuff ;-) >> 6. if there is any problem please let us know. If you decide to include >> it >> into fcl-db then you can place files for example into src/sqldb/mssql >> folder >> ;-) > > > > I will have a look and include both units. And the dream will become true... Thanks Michael. Any chance to merge in fixes_2_6 in short time? Marcos Douglas >>> >>> >>> Hi Michael, >>> Do you have some prediction to include the sources? >> >> >> >> My apologies, I had totally forgotten; I am buried in work currently. >> >> Committed in revision 20522. I didn't commit any examples or tests. Please >> test if everything works OK. I compiled on Linux 64-bit, I don't have >> a working FPC/Lazarus 32-bit windows development environment currently. > > I will do tests. > Thanks! I found a bug Consider the script: create table #t (id int, name varchar(60)) If I execute: insert table #t values (1, 'john') OK If I execute: insert table #t (name) values ('john') ERROR Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : RE : [fpc-devel] trunk no longer compiles with -Cr
> > Done http://bugs.freepascal.org/view.php?id=21516 Patch attached to mantis. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] trunk no longer compiles with -Cr
On 20/03/2012 12:55, Ludo Brands wrote: typelib.pas(1353,48) Error: range check error while evaluating constants (-1 must be between 0 and 4294967295) Can you raise a mantis issue? I'll fix this. According to msdn http://msdn.microsoft.com/en-us/library/cc237755%28v=prot.10%29.aspx the function ITypeInfo::GetRefTypeOfImplType is defined as HRESULT GetRefTypeOfImplType( [in] UINT index, [out] HREFTYPE* pRefType ); index: MUST be a nonnegative integer, or -1. Done http://bugs.freepascal.org/view.php?id=21516 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : [fpc-devel] trunk no longer compiles with -Cr
> Compiling .\winunits-base\src\typelib.pas > typelib.pas(371,71) Hint: Local variable "Handle" does not seem to be > initialized > typelib.pas(493,33) Hint: Local variable "sl" does not seem to be > initialized > typelib.pas(562,48) Hint: Local variable "sMethodName" does > not seem to > be initialized > typelib.pas(609,46) Hint: Local variable "sVarName" does not > seem to be > initialized > typelib.pas(1034,40) Hint: Local variable "senum" does not seem to be > initialized > typelib.pas(1097,37) Hint: Local variable "sl" does not seem to be > initialized > typelib.pas(1138,40) Hint: Local variable "slref" does not seem to be > initialized > typelib.pas(1207,48) Hint: Local variable "srecordname" does > not seem to > be initialized > typelib.pas(1224,50) Hint: Local variable "smembername" does > not seem to > be initialized > typelib.pas(1346,32) Hint: Local variable "sl" does not seem to be > initialized > typelib.pas(1353,48) Error: range check error while > evaluating constants > (-1 must be between 0 and 4294967295) Can you raise a mantis issue? I'll fix this. According to msdn http://msdn.microsoft.com/en-us/library/cc237755%28v=prot.10%29.aspx the function ITypeInfo::GetRefTypeOfImplType is defined as HRESULT GetRefTypeOfImplType( [in] UINT index, [out] HREFTYPE* pRefType ); index: MUST be a nonnegative integer, or -1. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] trunk no longer compiles with -Cr
on Win 32 Compiling .\winunits-base\src\typelib.pas typelib.pas(371,71) Hint: Local variable "Handle" does not seem to be initialized typelib.pas(493,33) Hint: Local variable "sl" does not seem to be initialized typelib.pas(562,48) Hint: Local variable "sMethodName" does not seem to be initialized typelib.pas(609,46) Hint: Local variable "sVarName" does not seem to be initialized typelib.pas(1034,40) Hint: Local variable "senum" does not seem to be initialized typelib.pas(1097,37) Hint: Local variable "sl" does not seem to be initialized typelib.pas(1138,40) Hint: Local variable "slref" does not seem to be initialized typelib.pas(1207,48) Hint: Local variable "srecordname" does not seem to be initialized typelib.pas(1224,50) Hint: Local variable "smembername" does not seem to be initialized typelib.pas(1346,32) Hint: Local variable "sl" does not seem to be initialized typelib.pas(1353,48) Error: range check error while evaluating constants (-1 must be between 0 and 4294967295) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class section (public, private) in debug info
On 20 Mar 2012, at 12:29, Paul Ishenin wrote: 20.03.12 19:02, Jonas Maebe написал: That's of course a very old version of gdb (some fork based on 6.3.50), so maybe it's a regression. As I remember this was fixed in fpc trunk only? That was something else. It works fine if I compile the compiler with DWARF using 2.6.0. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class section (public, private) in debug info
20.03.12 19:02, Jonas Maebe написал: That's of course a very old version of gdb (some fork based on 6.3.50), so maybe it's a regression. As I remember this was fixed in fpc trunk only? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class section (public, private) in debug info
On 19 Mar 2012, at 16:37, Martin wrote: Dwarf (see below) everything seems to be public: Dwarf does not seem to show methods With gdb on Mac OS X it works fine (and yes, this is DWARF): (gdb) ptype TLINKEDLIST type = ^TLINKEDLIST = class : public TOBJECT private FCOUNT : LONGINT; FFIRST : TLINKEDLISTITEM; FLAST : TLINKEDLISTITEM; FNOCLEAR : BOOLEAN; FIRST : TLINKEDLISTITEM; LAST : TLINKEDLISTITEM; COUNT : LONGINT; public function CREATE () : TLINKEDLIST; procedure DESTROY (); virtual; function EMPTY () : BOOLEAN; procedure CLEAR (); procedure INSERT (); procedure INSERTBEFORE (); procedure INSERTAFTER (); virtual; procedure CONCAT (); procedure REMOVE (); function GETFIRST () : TLINKEDLISTITEM; function GETLAST () : TLINKEDLISTITEM; procedure INSERTLIST (); procedure INSERTLISTBEFORE (); procedure INSERTLISTAFTER (); procedure CONCATLIST (); procedure INSERTLISTCOPY (); procedure CONCATLISTCOPY (); end That's of course a very old version of gdb (some fork based on 6.3.50), so maybe it's a regression. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class section (public, private) in debug info
On 20/03/2012 07:41, Paul Ishenin wrote: 20.03.2012 15:39, Graeme Geldenhuys написал: Maybe I'm not understanding this correctly, but why would you want "visibility restrictions" on debug information? Surely when debugging, you want access to ALL data - thus public visibility across the board seem good. Obviously - to show the visibility in inspect window for example. More you know - better. exactly. (and filter, if there is lots of data) the symbols can be viewed in the debugger anyway, even if they are private ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class section (public, private) in debug info
20.03.2012 15:39, Graeme Geldenhuys написал: Maybe I'm not understanding this correctly, but why would you want "visibility restrictions" on debug information? Surely when debugging, you want access to ALL data - thus public visibility across the board seem good. Obviously - to show the visibility in inspect window for example. More you know - better. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class section (public, private) in debug info
On 19 March 2012 17:37, Martin wrote: > > Dwarf (see below) everything seems to be public: Maybe I'm not understanding this correctly, but why would you want "visibility restrictions" on debug information? Surely when debugging, you want access to ALL data - thus public visibility across the board seem good. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel