[fpc-devel] RTTI is always enabled??

2009-12-10 Thread Graeme Geldenhuys
Hi, This is a odd one (at least for me and another developer in tiOPF project). Why is RTTI information ALWAYS available? See the example project below. It always returns that RTTI information is available when clearly it should not. Kylix 3 help says that ClassInfo property should return nil

Re: [fpc-devel] sets in dwarf

2009-12-10 Thread Jonas Maebe
On 10 Dec 2009, at 08:21, Paul Ishenin wrote: I've also found that it is possible to include sets info to the dwarf2 if option ds_dwarf_sets is included into current_settings.debugswitches. Although there are no places where this happen. You have to compile with -godwarfsets. Jonas

Re: [fpc-devel] RTTI is always enabled??

2009-12-10 Thread Paul Ishenin
10.12.2009 17:01, Graeme Geldenhuys wrote: This is a odd one (at least for me and another developer in tiOPF project). Why is RTTI information ALWAYS available? See the example project below. It always returns that RTTI information is available when clearly it should not. Kylix 3 help says

Re: [fpc-devel] RTTI is always enabled??

2009-12-10 Thread Graeme Geldenhuys
Paul Ishenin wrote: This is delphi 2010 compatible behavior. Only info about published methods is not written for classes with {$M-}. So what is the correct way of asking if a class as RTTI (published properties) available? Because currently we have stacks of unit tests that fail in tiOPF

Re: [fpc-devel] RTTI is always enabled??

2009-12-10 Thread Daniël Mantione
Op Thu, 10 Dec 2009, schreef Graeme Geldenhuys: Paul Ishenin wrote: This is delphi 2010 compatible behavior. Only info about published methods is not written for classes with {$M-}. So what is the correct way of asking if a class as RTTI (published properties) available? Because

Re: [fpc-devel] RTTI is always enabled??

2009-12-10 Thread Paul Ishenin
10.12.2009 17:25, Graeme Geldenhuys wrote: So what is the correct way of asking if a class as RTTI (published properties) available? Because currently we have stacks of unit tests that fail in tiOPF due to this change - give always true when asking if publish properties (RTTI) is available.

[fpc-devel] Error about unknown record field identifier

2009-12-10 Thread Mehmet Erol Sanliturk
Dear Free Pascal Developers , During filling a bug report , the report page has been disappeared ( due to one of my key presses I do not know which key it was ) on closing of Firefox . And a new bug report page could not be obtained for reporting because an empty page is displayed . If any

[fpc-devel] TIntefaceEntryType declaration

2009-12-10 Thread Sergei Gorelkin
Hello, What's the reason of having TInterfaceEntryType declared both in RTL (inc/objpash.inc) and compiler (symconst.pas) and keeping them in sync? It seems that compiler can always use declaration from System unit, no? Regards, Sergei ___

[fpc-devel] [arm] tStream.position

2009-12-10 Thread Dariusz Mazur
Hi there is problem with something like that var ts : tStream; begin ts:=tStream.create; ts.position:=2; // here arm write ERange Error // on trace setPosition // is very big number, like 153000 ts.free; end; platform : ARM with soft float -- Darek

Re: [fpc-devel] [arm] tStream.position

2009-12-10 Thread Mattias Gärtner
Zitat von Dariusz Mazur dar...@emadar.com: Hi there is problem with something like that var ts : tStream; begin ts:=tStream.create; ouch. TStream is an abstract class. Maybe the keyword 'abstract' should be added, so that the compiler warns. ts.position:=2; // here arm write ERange

Re: [fpc-devel] FPC test suite and ALGLIB

2009-12-10 Thread Jonas Maebe
On 09 Dec 2009, at 07:54, Sergey Bochkanov wrote: I've prepared small test suite based on ALGLIB's Fast Transforms sub-package: tests for FFT, FHT, convolution and cross-correlations, 4 tests in total. Thanks, I've added them to svn. I cursorily tested them and they at least work

Re: [fpc-devel] Error about unknown record field identifier

2009-12-10 Thread Jonas Maebe
On 10 Dec 2009, at 12:01, Mehmet Erol Sanliturk wrote: As of today ( 2009-December-10 ) I have encountered the same error with the above compilers . This shows that the error is persisting . As usual, we need compilable source code that demonstrates this problem to fix it.