Re: [fpc-devel] TField.AsString and Databases with UTF-8 charset
On Friday 24 July 2009 12:49:51 Graeme Geldenhuys wrote: 2) The UTF-8 implementation of Firebird is seriously flawed. Firebird makes as if UTF-8 is a fixed byte algorithm and just returns rubbish results from a Char(x) field and breaks the DDL rule of what the maximum character length is. Using the metadata, SqlDB *can* fixes this by using something like: copy(fieldvalue, 0, MaxCharacterLength) Applies for UNICODE_FSS not UTF8. As I wrote before: Firebird trims CHAR fields for UTF8 to character length (byte length = 4*character length) and with the old UNICODE_FSS to byte length (= 3*character length), see http://www.destructor.de/firebird/charsets.htm Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TField.AsString and Databases with UTF-8 charset
On Friday 24 July 2009 14:06:21 Graeme Geldenhuys wrote: PostgreSQL also supports the UTF-8 character set in databases. Surprise, surprise TParam.Size and TField.Size report the value of Char(x). Also the return values read from the Char(x) field don't contain any space padding on the right unless the actual text is less than the Char(x) definition. Also the character length NEVER exceeds the Char(x) definition. Try to enter 'äöüéà' in a char(5) utf-8 encoded PQ field in SqlDb. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TField.AsString and Databases with UTF-8 charset
On Friday 24 July 2009 15:31:32 Michael Van Canneyt wrote: On Fri, 24 Jul 2009, Graeme Geldenhuys wrote: As a consequence, my prediction is that, because it reports a size in characters, the postgres implementation will suffer of buffer overflows as soon as strange (=multibyte) unicode characters are returned. Whereas the firebird implementation will not buffer overflow since it returns a size in bytes (but instead it suffers from the problem you encountered). Correct. We need to foresee the possibility where the size in characters is different from the size in bytes. If I am correct, the TWideStringField accomodates for this, it uses a character size of 2. Graeme will not accept it because he wants to use ancient Greek and Klingon AFAIK. ;-) MSEgui uses variable size storage for strings in tmsebufdataset. It was difficult to implement but it is worth the effort. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TField.AsString and Databases with UTF-8 charset
On Tuesday 21 July 2009 15:56:02 Graeme Geldenhuys wrote: What is your thoughts on this. As far as I know MSEgui does automatic trimming of spaces in the TField, so should this maybe be done in SqlDB (Interbase/Firebird) as well? Don't confuse Firebird field datasize (in bytes) and field character length (in characters/code points). MSEgui SqlDB fork queries the character length by metadata. The utf-8 encoded database text will be converted to widestring and stored in the dataset by variable length widestrings. tmsestringfield.size will be set to the character length instead to the data length. Firebird trims CHAR fields for UTF8 to character length (byte length = 4*character length) and with the old UNICODE_FSS to byte length (= 3*character length), see http://www.destructor.de/firebird/charsets.htm Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] with r13297 ChangeName has gone
On Friday 19 June 2009 04:23:19 Paul Ishenin wrote: I think that ChangeName should stay in the TComponent class. Agreed, Delphi has it too. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger for FPC
On Wednesday 11 March 2009 09:24:53 Graeme Geldenhuys wrote: For me GDB with the MSEide frontend is better than the integrated debugger in Delphi 7. It is almost impossible to develop something like MSEide+MSEgui with writeln and logfile approach. Manytimes bugs are hard to find in event driven software without watchpoints. GDB can switch the stackframe which Delphi 7 cant. The problem of the properties is not a big one because of the f naming convention, I don't like if gdb would call the getter functions because of possible sideeffects. There are some issues with debuginfo of dynamic arrays in classes, if the FPC team is interested, I can try to build testcases to show the problems. Hi everybody, [...] Simple things that worked in Delphi IDE and even Kylix IDE, but not in FPC/Lazarus IDE: * Breakpoints do not always break I never seen this in MSEide. * Tooltip evaluation of highlighted code gives no such symbol in context errors Same can happen in Delphi 7 for example in with statements. * Properties on objects cannot be debugged. You have to use the underlying field variable if you have access to it, A small problem once you know it. :-) or you the property uses access methods you are screwed. Think on the possible sideeffects. * In most cases I cannot inspect local variables, due to no such symbol in context errors This normally works for me. * debugging nested procedures are totally useless. Switch the stackframe if you want to examine variables of a caller. [...] Like I said, I am not very knowledgeable with debugger internals, but I am willing to learn and help. Not having decent debugger support is killing me - and I am clearly not alone, as the thread in the Lazarus mailing list proves. The problem as far as I can see, is that the Free Pascal project is trying to use existing debuggers that were NOT designed to work with the Object Pascal language. So maybe we should stop using those and implement our own debugging symbol format (if that is required) and then continue with writing a debugger specific to Free Pascal. I am more that willing to put in some effort if it means we end up with a working debugger! Using gdb has the *big* advantage to have a working environment on many platforms with working remote debugging. I suspect the work for developping an own debugger will be very big, have a look into the gdb sources and you know what I mean... The main problem with gdb is the communication by pipes and the not finished mi-interface, once the communication works and the workarounds for the missing mi-functions are done gdb is not bad. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger for FPC
On Wednesday 11 March 2009 11:06:38 Florian Klaempfl wrote: GDB is ported for 10 years to windows and it's behaviour is still *very* poor. MinGW gdb 6.8-3 works well for me. http://sourceforge.net/project/showfiles.php?group_id=2435package_id=20507release_id=594520 Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger for FPC
On Wednesday 11 March 2009 11:26:07 Florian Klaempfl wrote: My main problem (if they really work) with all gdb gui frontends is that they are dog slow compared with a good debugger like Visual Studio. Agreed. MSEide has a button to disable the watches for fast stepping. On a modern computer gdb with MSEide frontend is fast enough for me. Another nice gdb feature is the ability to debug C-libraries linked into a Pascal program. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger for FPC
On Wednesday 11 March 2009 11:28:27 Graeme Geldenhuys wrote: Well writing a new compiler is just such a big task and it didn't prevent Florian from starting FPC. Having a 100% working debugger (no matter if it takes a while to get there) is still much better in the long run - for the developers and for the Free Pascal Compiler project. Not to mention MSEide and Lazarus IDE could benefit from it too. The main problem with gdb is the communication by pipes and the not finished mi-interface, once the communication works and the workarounds for the missing mi-functions are done gdb is not bad. Well at least having our own object pascal based compiler, we will be able to implement new features and fixes much quicker than GDB. I think it would be better to extend gdb for better FPC support. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger for FPC
On Wednesday 11 March 2009 11:23:00 Michael Schnell wrote: GDB can switch the stackframe which Delphi 7 cant. This allows for taking a look at the local variable of a ancestor procedure ? Yes, don't forget to compile with -O-. [...] There are some issues with debuginfo of dynamic arrays in classes, if the FPC team is interested, I can try to build testcases to show the problems. Do you think that issue can be handled ? Yes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Debugger for FPC
On Wednesday 11 March 2009 15:14:27 Graeme Geldenhuys wrote:
On Wed, Mar 11, 2009 at 3:55 PM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
http://opensoft.homeip.net/~graemeg/gdb_issues_with_fpc.png
And then the same think under Kylix 3. As I said, with Delphi and
Kylix such trivial things is a no-brainer. Debugging just works.
http://opensoft.homeip.net/~graemeg/kylix_debuging.png
Delphi/Kylix:
var
CurrencyString: string;
CurrencyFormat: Byte;
NegCurrFormat: Byte;
ThousandSeparator: Char;
DecimalSeparator: Char;
CurrencyDecimals: Byte;
DateSeparator: Char;
ShortDateFormat: string;
FPC:
Var
{ Character to be put between date, month and year }
DateSeparator: char absolute DefaultFormatSettings.DateSeparator;
{ Format used for short date notation }
ShortDateFormat: string absolute DefaultFormatSettings.ShortDateFormat;
Delphi/Kylix probably can't map a variable to the address of another variable,
because of that Delphi needs separate implementations of format functions
with and without FormatSettings parameter.
Use DefaultFormatSettings.ShortDateFormat to display the value in gdb.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to search units reported by gdb? (fpc and mseide devels please participate)
On Friday 27 February 2009 15:17:29 Paul Ishenin wrote:
How this solved by mseide developers?
MSEgui uses includefiles for headers in platform specific units
(msesysintf.pas, mseguiintf.pas) only, so there are not many include files in
the MSEgui framework and the names are unique.
In order to search files which are reported by gdb MSEide uses the absolute
path if available. If not found it searches relative to the make directory
('Project'-'Options'-'Make'-'Make Directory'). If not found it scans the
listed directories in 'Project'-'Options'-'Debugger'-'Source directories'
where ? and * wildcards can be used.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to search units reported by gdb? (fpc and mseide devels please participate)
On Saturday 28 February 2009 11:07:48 Mattias Gaertner wrote:
On Sat, 28 Feb 2009 09:57:05 +0100
And how does MSEGui find lists.inc?
For example on indexoutofbounds exception?
http://www.msegui.homepage.bluewin.ch/pics/exception.png
http://www.msegui.homepage.bluewin.ch/pics/debugoptions.png
The links show a typical situation, lists.inc is found by
${fpcdir}rtl/objpas/classes/
MSEide does probably the same as Lazarus to find gdb reported files.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linker crash
On Monday 02 February 2009 16:01:06 Jonas Maebe wrote: I don't see any beating here either: * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412927 * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509873 * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473955 Even if they disagree, you just get the facts as they see it: https://bugzilla.novell.com/show_bug.cgi?id=66 Really, developers (Linux or otherwise) that deal with this sort of bugs generally won't bite your or anyone else's head off just because you use Pascal or a non-FSF compiler. OK, I'll try it. Where should I report? At Suse because it is a Suse patched ld? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linker crash
On Tuesday 03 February 2009 10:06:40 Jonas Maebe wrote: OK, I'll try it. Where should I report? At Suse because it is a Suse patched ld? That's indeed your best bet. Here's their bug reporting portal: http://en.opensuse.org/Submitting_Bug_Reports Done: https://bugzilla.novell.com/show_bug.cgi?id=471901 I fear the spam level in my Email account will increase again. :-( Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linker crash
On Monday 02 February 2009 12:00:07 Jonas Maebe wrote: I've never been beaten by the Linux gurus for submitting Pascal- related bug reports to gdb, or by discussing them on the gdb Archer project list (someone from Red Hat recently fixed a bug in the gdb Archer branch that only affected dwarf debug information generated by FPC for Mac OS X -- i.e., not by gcc on any platform, and only on Mac OS X when using FPC). See http://thread.gmane.org/gmane.comp.debugging.archer/756 Probably because you have the skills and technical background to talk with them on the same level and with the same language, I can't do that. :-( Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Linker crash
Hi, The Suse 11.1 i386 supplied linker crashes with FPC produced objects. Example linking the DE-resource unit in MSEgui i18ndemo: ./ppas.sh Linking libi18ndemo_de.so ./ppas.sh: line 10: 4825 Segmentation fault /usr/bin/ld -b elf32-i386 -m elf_i386 -init FPC_LIB_START -fini FPC_LIB_EXIT -soname libi18ndemo_de.so -shared -L. -o libi18ndemo_de.so link.res An error occurred while linking libi18ndemo_de.so ld --version GNU ld (GNU Binutils; openSUSE 11.1) 2.19 It happens with FPC 2.2.2 and fixes_2_2. Yes, I now that this is not a FPC problem but possibly someone finds the information useful. No, I don't want to submit a binutils bug report, I don't like to be beaten by the Linux gurus. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Whole program optimisation
On Thursday 11 December 2008 19.27:18 Jonas Maebe wrote: Hello, I've just merged the whole program optimisation branch into trunk. For information on what it currently does and how to use it, see http://wiki.freepascal.org/Whole_Program_Optimization Great! Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Memory consumed by strings
On Sunday 23 November 2008 09.26:35 Graeme Geldenhuys wrote: On Sun, Nov 23, 2008 at 10:19 AM, Mattias Gaertner [EMAIL PROTECTED] wrote: On Sat, 22 Nov 2008 23:05:43 +0200 For example the lazarus IDE typically holds 50 to 200mb sources in memory. If this would be changed to unicodestring (2 byte per char) then the IDE would need 50 to 200mb more memory. Ah, and that would probably explain why Martin decided not to pre-parse units in MSEide - for things like code complection etc... MSEide's memory usage would balloon greatly, compared to Lazarus. MSEide parses the code for code navigation only and on demand. For creating event handlers and the like the compiled in RTTI will be used. I decided not to parse the RTL because I wanted to be independent from the source installation and because I think the task to do exact parsing of the whole FPC RTL and other libraries is too difficult and not necessary because RTTI provides sufficient information. The parser uses 8bit strings, 16bit is used in the code editor. It is possible to work a whole day with MSEide without closing a single file and without noticeable loss of speed. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Memory consumed by strings
On Sunday 23 November 2008 13.44:02 Mattias Gaertner wrote: But RTTI only contains published classes, does it not? AFAIK there are some more elements where is is possible to get a typeinfo pointer. A compiler specialist can say more. :-) Does MSEGui read ppu files? No. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support (again)
On Tuesday 11 November 2008 17.34:36 Graeme Geldenhuys wrote: All I do know is that only recently did the WideString manager become usable in FPC. Martin had until recently some issues with bugs in the WideString manager. ??? The last widestring manager bug I remember was in January 2007 in FPC 2.0.5. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assign constant text to widestring
On Thursday 23 October 2008 13.31:30 Florian Klaempfl wrote: This is also a simplified view. - firstly, which real world (!) task really requires to execute an operation like this, mostly it's something like copy(s,pos(...),...); - secondly, a properly coded utf-16 application shouldn't do this either: it doesn't handle surrogates properly and e.g. umlauts can be encoded in all utf flavours as two chars: base letter plus the umlaut (the two dots). One should normalize unicode text before processing. If normalized to fully composed form there will be no problems with UCS2 single character processing in Western Europe. The GUI kit should return fully composed characters when ever possible to simplify the users life. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assign constant text to widestring
On Thursday 23 October 2008 13.58:04 Michael Schnell wrote: Bidi stuff? You are aware of the fact that unicode strings can contain e.g. bidi markers? Sorry, never heard of bidi :( Bidirectional text. Much more important than the hypothetical codepoints above the BMP. MSEgui does not support bidi BTW, too difficult. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is calling the Windows Unicode APIs really faster than the ANSI API's?
On Sunday 28 September 2008 00.10:43 Graeme Geldenhuys wrote: On Fri, Sep 26, 2008 at 5:02 PM, Mattias Gaertner [EMAIL PROTECTED] wrote: s[i]:='x' doesn't work in UTF-8, nor UTF-16, nor UTF-32. In short: A single character for all purposes can not be defined. Unicode can not be handled as array of character. This is what I thought, but everybody seems to side step the answer. Thanks Mattias for confirming this. Like I told Martin in one of my replies. In the last four years I have not needed indexing into a character array, and if I have to parse a string, it's normally sequential anyway, which is then easy to track each charter in UTF-8, even if multi-byte characters are used. Note that UTF8CharAtByte() won't work work in Mattias example neither. It seems that Apple decided to use two characters from the BMP to denote umlauts. Example for ä (U+00E4 LATIN SMALL LETTER A WITH DIARESIS): a (U+0061 LATIN SMALL LETTER A) followed by ¨ (U+0308, COMBINIG DIARESIS). Mattias please correct me if I am wrong. So the problem is not that the characters don't fit in the UCS2 range, the problem is that Apple use the decomposed forms of umlauts. If you work with OS X HFS you must convert to the composed normal form if fpGUI uses the composed form internally before processing the filenames in fpGUI. This is independent of using utf-8, utf-16, utf-32 or UCS2. You need conversion tables to do so and again, it is easier to handle with widestrings instead of utf-8 strings if you don't need characters which don't fit into BMP. And even if you want to support the full Unicode code point range it is simpler with utf-16 because there are surrogate *pairs* only. In MSEgui I would implement the normalization into the MSEgui filename routines, MSEgui uses a normalized cross platform filename scheme anyway. Win32 'c:\\bbb.ext' will be normalized to MSEgui form '/c://bbb.ext', Unicode composed normalization can be done in the same step. An article about Unicode normalization: http://en.wikipedia.org/wiki/Unicode_normalization Martin___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is calling the Windows Unicode APIs really faster than the ANSI API's?
On Sunday 28 September 2008 20.16:36 Graeme Geldenhuys wrote: On Sun, Sep 28, 2008 at 12:22 PM, Mattias Gaertner Is this normalized form used only internally in msegui or must the user use them too? I remember when I tried a MSEgui version some time back, that the IDE itself used that normalized form filenames. I think any file select dialogs etc uses that. I first thought it was a bug and reported it, and was told it's normal. I don't know if more recent versions of MSEgui has changed or not. All I can say is that from a user perspective, those filenames are weird. ;-) It has not changed. You can either enter the system specific or the MSEgui form of filenames into filename widgets, they eat both. :-) On Linux the system and the MSEgui filenames are the same. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is calling the Windows Unicode APIs really faster than the ANSI API's?
On Friday 26 September 2008 09.34:44 Graeme Geldenhuys wrote: Well if you have Utf-8 versions of all basic string processing functions like Pos, Length, Copy, Insert etc you don't have to think of encoding or anything. fpGUI uses UTF-8 internally, and I never have to think about what encoding I'm working with. I assume Lazarus LCL is the same. It seems you prefer utf-8 over utf-16 for internal string encoding in a GUI framework. Why? I prefer utf-16 over utf-8 for MSEide+MSEgui because *all* current users (including the Chinese) can use simple string index to access the characters of their used languages and almost nobody can use string index to access characters in utf-8. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is calling the Windows Unicode APIs really faster than the ANSI API's?y
On Friday 26 September 2008 12.30:27 Marco van de Voort wrote: In our previous episode, Martin Schreiber said: Hmm, you should ask the Russian users for example if they prefer MSEgui utf-16 internal encoding or Lazarus utf-8. Users always look short term, and want to change as little as possible. This goes both for UTF-16 (with the is UCS2 approximation and keep the old ways of string indexing) as for UTF-8 (as superset of ansi, avoidance of multiple file types (no endianess)). Note that e.g. source ocde seems to go en masse in the direction of UTF-8 (Even Tiburon, which works exclusively on Windows, an UTF-16 platform, saves source default to UTF8 afaik). As does MSEide, source code is stored in the current locale encoding or utf-8, the latter is preferred. MSEgui stores ini files and the like in utf-8, the form definition files (*.mfm, the MSEgui equivalent of Delphi *.dfm) are pure ASCII. For DB access MSEgui converts from utf-8 or the current locale encoding to utf-16 while fetching the data from server and converts back to utf-8 or the locale encoding before writing data to the server. There is a switch in the connection and dataset components to select either utf-8 or the locale encoding. Strings in the dataset buffer are stored as variable length utf-16 strings. All this can be done with the currently available standard FPC 2.2.2 widestring facilities. I have no problem if the FPC RTL supports the system encoding only, MSEgui has the commonly used interface to the filesystem and other services with widestring parameters. If something is missing, it can be added to the MSEgui library. But for internal character encoding where the users must work with, utf-16 is better suited than utf-8, I am happy that FPC will support a reference counted widestring type in Windows in future releases. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Sunday 14 September 2008 19.22:13 Florian Klaempfl wrote: Martin Schreiber schrieb: I tried with trunk, same result. The problem is probably that the second constant string parameter has a wrong reference count. It is initially 0 instead of -1. The incref call at begin of winfilepath turns it to 1, decref in finalize section of winfilepath tries to free the constant string memory - bumm. Fixed in rev 11779. Thanks for the test. Win32 MSEide works now with UnicodeString, no problems found up to now. :-) Thanks a lot! Do you plan to merge to fixes_2_2? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Thursday 11 September 2008 23.18:07 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I have a crash in MSEide startup in a procedure finalization section:
[...]
I saw that you merged unicodestring to trunk. Should I test with trunk
instead of unicodestring branch?
Yes. Unicodestring branch is closed.
I tried with trunk, same result. The problem is probably that the second
constant string parameter has a wrong reference count. It is initially 0
instead of -1. The incref call at begin of winfilepath turns it to 1, decref
in finalize section of winfilepath tries to free the constant string
memory - bumm.
Testresult:
-1
1
An unhandled exception occurred at $77892373 :
EAccessViolation : Access violation
$77892373
$778922F8
$0040A214
$004097A3
$004098DD
$004099DB
$00408844
$004068EA
$0040696D
$00401858
$004018D5
The crash stack:
#0 77892373 :0 ??()
#1 00416E04 :0 U_SYSTEM_ENTRYINFORMATION()
#2 004196D4 :0 U_SYSINITPAS_ENTRYINFORMATION()
#3 004162C4 :0 U_SYSTEM_OUTPUT()
#4 014CFE20 :0 ??()
#5 00408799 sysheap.inc:38 SYSOSALLOC(SIZE=0)
#6 778922F8 sysheap.inc:0 ??()
#7 00416F00 sysheap.inc:0 U_SYSTEM_ORPHANED_FREELISTS()
#8 0040A762 systhrd.inc:300 SYSENTERCRITICALSECTION(CS=void)
#9 0040A214 thread.inc:190 ENTERCRITICALSECTION(CS={DEBUGINFO = 0x0,
LOCKCOUNT = 1, RECURSIONCOUNT = 0, OWNINGTHREAD = 0, LOCKSEMAPHORE = 944,
SPINCOUNT = 0})
#10 004097A3 heap.inc:1034 WAITFREE_VAR(PMCV=0x41312c)
#11 004098DD heap.inc:1086 SYSFREEMEM_VAR(LOC_FREELISTS=0x416f84,
PMCV=0x41312c)
#12 004099DB heap.inc:1125 SYSFREEMEM(P=0x413138)
#13 00408844 heap.inc:275 FREEMEM(P=0x413138)
#14 004068EA ustrings.inc:179 DISPOSEUNICODESTRING(S=0x413138)
#15 0040696D ustrings.inc:206 fpc_unicodestr_decr_ref(S=0x413138)
#16 00401858 decrefcrash.pas:63 WINFILEPATH(DIRNAME=0x0, FILENAME=0x413138,
result=0x14fdab0)
#17 004018D5 decrefcrash.pas:69 main()
And there are calls to fpc_WideStr_Decr_Ref I don't understand.
Test program attached.
Martin
program decrefcrash;
{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
{$ifdef mswindows}{$apptype console}{$endif}
uses
{$ifdef FPC}{$ifdef linux}cthreads,{$endif}{$endif}
sysutils;
const
maxdatasize = $7fff;
type
msechar = unicodechar;
msestring = unicodestring;
msecharaty = array[0..maxdatasize div sizeof(msechar)-1] of msechar;
pmsecharaty = ^msecharaty;
procedure replacechar1(var dest: msestring; a,b: msechar);
//replaces a by b
var
int1: integer;
begin
uniquestring(dest);
for int1:= 0 to length(dest)-1 do begin
if pmsecharaty(dest)^[int1] = a then begin
pmsecharaty(dest)^[int1]:= b;
end;
end;
end;
function winfilepath(dirname,filename: msestring): msestring;
begin
writeln((pptrint(pointer(dirname))-2)^);
flush(output);
writeln((pptrint(pointer(filename))-2)^);
flush(output);
replacechar1(dirname,msechar('/'),msechar('\'));
replacechar1(filename,msechar('/'),msechar('\'));
if (length(dirname) = 3) and (dirname[1] = '\') and (dirname[3] = ':') then begin
dirname[1]:= dirname[2]; // '/c:' - 'c:\'
dirname[2]:= ':';
dirname[3]:= '\';
if (dirname[4] = '\') and (length(dirname) 4) then begin
move(dirname[5],dirname[4],(length(dirname) - 4)*sizeof(msechar));
setlength(dirname,length(dirname) - 1);
end;
end;
if filename '' then begin
if dirname = '' then begin
result:= '.\'+filename;
end
else begin
if dirname[length(dirname)] '\' then begin
result:= dirname + '\' + filename;
end
else begin
result:= dirname + filename;
end;
end;
end
else begin
result:= dirname;
end;
end;
var
mstr1,mstr2: msestring;
begin
mstr2:= 'C:\Dokumente und Einstellungen\mseca\Anwendungsdaten\.mseide';
mstr1:= winfilepath(mstr2,'*');
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestring type is a ref.
counted utf-16 string. On non-windows, widestring is mapped to this
type. If you're interested in unicode support please test, give feedback
here and submit fixes.
I have a crash in MSEide startup in a procedure finalization section:
#0 77892373 :0 ??()
#1 0082CDF4 :0 U_SYSTEM_ENTRYINFORMATION()
#2 03B7FB2C :0 ??()
#3 03B7FAAC :0 ??()
#4 03C22C1C :0 ??()
#5 0082D9F4 :0 U_SYSTEM_FREELISTS()
#6 03B7F874 :0 ??()
#7 0040F5EB heap.inc:1127 SYSFREEMEM(P=0x0)
#8 778922F8 heap.inc:0 ??()
#9 0082E500 heap.inc:0 U_HEAPTRC_OWNFILE()
#10 00410482 systhrd.inc:300 SYSENTERCRITICALSECTION(CS=void)
#11 0040FE94 thread.inc:190 ENTERCRITICALSECTION(CS={DEBUGINFO = 0x0,
LOCKCOUNT = 1, RECURSIONCOUNT = 0, OWNINGTHREAD = 0, LOCKSEMAPHORE = 812,
SPINCOUNT = 0})
#12 00414571 heaptrc.pp:666 TRACEFREEMEMSIZE(P=0x6d11b8, SIZE=0)
#13 004146BB heaptrc.pp:722 TRACEFREEMEM(P=0x6d11b8)
#14 0040E404 heap.inc:275 FREEMEM(P=0x6d11b8)
#15 004093FA ustrings.inc:179 DISPOSEUNICODESTRING(S=0x6d11b8)
#16 0040947D ustrings.inc:206 fpc_unicodestr_decr_ref(S=0x6d11b8)
#17 004A9B1C msesysintf.pas:306 WINFILEPATH(DIRNAME=0x0, FILENAME=0x6d11b8,
result=0x3c22fa8)
#18 004AB63F msesysintf.pas:1436 SYS_OPENDIRSTREAM(STREAM={INFOLEVEL =
FIL_NAME, DIRNAME = 0x3c23148, MASK = 0x3b7faa0, INCLUDE = [FA_ALL], EXCLUDE
= [], PLATFORMDATA = {0, 208983208, 1, 4294967295, 0, 0, 0, 0}})
#19 004B5BB2 msefileutils.pas:640 SEARCHFILE(AFILENAME=0xc7a07b0,
ADIRNAME=0x3c22e08, result=0x0)
#20 004B5DED msefileutils.pas:671 SEARCHFILE(AFILENAME=0x6bf2f8,
ADIRNAMES=0x3c22ed8, highADIRNAMES=0, result=0x0)
#21 004B5F9C msefileutils.pas:698 FINDFILE(FILENAME=0x6bf2f8,
DIRNAMES=0x3c22ed8, PATH=0x0, highDIRNAMES=0)
#22 004C03E1 msestatfile.pas:244 TSTATFILE__READSTAT(STREAM=0x0,
this=0x3c6b918)
#23 00453CF8 main.pas:1514 TMAINFO__MAINONLOADED(SENDER=0x3c03d40,
this=0x3c03d40)
#24 0050A717 mseforms.pas:854
TCUSTOMMSEFORM__DOEVENTLOOPSTART(this=0x3c03d40)
#25 0050A763 mseforms.pas:863 TCUSTOMMSEFORM__RECEIVEEVENT(EVENT=0xc7016f8,
this=0x3c03d40)
#26 0048CA3A mseevent.pas:213 TOBJECTEVENT__DELIVER(this=0xc7016f8)
#27 0042E7D0 msegui.pas:12666
TINTERNALAPPLICATION__EVENTLOOP(AMODALWINDOW=0x0, ONCE=false, this=0x3bd9460)
#28 0042F52C msegui.pas:13063 TINTERNALAPPLICATION__DOEVENTLOOP(ONCE=false,
this=0x3bd9460)
#29 0048B3F8 mseapplication.pas:1132 TCUSTOMAPPLICATION__RUN(this=0x3bd9460)
#30 004025D1 mseide.pas:59 main()
I could not find a simple program to demonstrate the failure. Something
strange is that the following procedure calls fpc_WideStr_Decr_Ref in
finalization section:
const
quotechar = unicodechar('');
procedure requote(var path: unicodestring; const newvalue: unicodestring);
begin
if punicodechar(path)^ = quotechar then begin
path:= quotechar + newvalue;
end
else begin
path:= newvalue;
end;
end;
I saw that you merged unicodestring to trunk. Should I test with trunk instead
of unicodestring branch?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Thursday 11 September 2008 22.33:32 listmember wrote: procedure TLabel.Paint(...) begin if *Caption.IsRTL *then DrawCaptionRTL(0,0,*Caption.AsUTF8*, flags) else DrawCaption(0,0,*Caption.AsUTF8*, flags); end; Is not that enough? What is the gain as opposed to procedure TLabel.Paint(...) begin if IsRTL(Caption) then DrawCaptionRTL(0,0,AsUTF8(Caption), flags) else DrawCaption(0,0,AsUTF8(Caption), flags); end; In other words where is the benefit from OOP in this ? IMO, both are deficient as they both assume that a string block (text) is either RTL or LTR. Doesn't that mean we will be --by design-- unable to write something like 'Yom Kippur (יוֹם כִּפּוּר)' on a caption? This is why I keep asking that the 'TCharacter' or 'TChar' needs to have a language attribute. MSEgui has a richstringty type, a combination of a widestring and a dynamic array of formatting info. There are formatting infos for the changes only, a richstringty without formatting info has a nil pointer for the dynamic array. See lib/common/kernel/mserichstring.pas http://sourceforge.net/projects/mseide-msegui/ type newinfoty = (ni_bold=ord(fs_bold),ni_italic=ord(fs_italic), ni_underline=ord(fs_underline),ni_strikeout=ord(fs_strikeout), ni_selected=ord(fs_selected), //same order as in fontstylety ni_fontcolor,ni_colorbackground,ni_delete); newinfosty = set of newinfoty; const fonthandleflags = [ni_bold,ni_italic]; fontstyleflags = [ni_bold,ni_italic,ni_underline,ni_strikeout,ni_selected]; type charstylety = record fontcolor,colorbackground: pcolorty; fontstyle: fontstylesty; end; pcharstylety = ^charstylety; charstylearty = array of charstylety; formatinfoty = record index: integer;//0- from first char newinfos: newinfosty; style: charstylety; end; pformatinfoty = ^formatinfoty; formatinfoarty = array of formatinfoty; pformatinfoarty = ^formatinfoarty; richstringty = record text: msestring; format: formatinfoarty; end; It was designed for fast processing in MSEide source code editor. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TSdfDataset does not work with records larger then 255 chars
On Tuesday 09 September 2008 20.28:05 Luca Olivetti wrote: El Mon, 8 Sep 2008 20:14:44 +0200 Martin Schreiber [EMAIL PROTECTED] escribió: Is Sqlite3 no option for you? MSEgui and FPC sqldb both have a DB-connection component for SQLite3. FWIW I had the problem of string fields limited to 255 characters with sqlite3 and zeos. I hadn't time to test other combinations. Since I only needed the db aware components to display (not even edit) fields of less than 255 chars, I simply used direct queries to manipulate fields longer than 255 chars. Like Felipe I couldn't trace the source of that limitation. There is no such limitation with MSEgui tmsesqlquery and tsqlite3connection AFAIK. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TSdfDataset does not work with records larger then 255 chars
On Monday 08 September 2008 04.53:25 Felipe Monteiro de Carvalho wrote: Hello, Using TSdfDataset my records are cut to fit 255 chars, even when I change the new MaxRecordLength property to 2048. This is a very elusive bug, and I am searching all over for the cause without success =( I searched everywhere for a shortstring, which could be the cause, but didn't find any. Any ideas? Possibly because FieldDefs[n].Size is too small. Did you setup TSdfDataset.Schema according to your needs? The format is fieldname=fieldsize AFAIK, MAXSTRLEN is a default value only. The new MaxRecordLength property is actually unnecessary and a little bit misleading. I was not able to debug inside FCL, maybe the standard build comes without debug info? Correct. I was able to debug the sdfdata unit because I am using it locally in my project, because I am using FPC 2.2.2 and when the flow of events comes to TFIXEDFORMATDATASET__SETFIELDDATA the string is already cutted and in TDBDRAWINGCODEMEMO__UPDATEDATA it was correct, so it must have been cutted in the FCL somewhere in between. procedure TStringField.SetAsString(const AValue: string); var Buf : TStringFieldBuffer; begin IF Length(AValue)=0 then begin Buf := #0; SetData(@buf); end else if FTransliterate then begin DataSet.Translate(@AValue[1],Buf,True); Buf[DataSize-1] := #0; SetData(@buf); end else begin // The data is copied into the buffer, since some TDataset descendents copy // the whole buffer-length in SetData. (See bug 8477) Buf := AValue; // If length(AValue) Datasize the buffer isn't terminated properly Buf[DataSize-1] := #0; probably here SetData(@Buf); end; end; Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TSdfDataset does not work with records larger then 255 chars
On Monday 08 September 2008 14.42:04 Felipe Monteiro de Carvalho wrote:
On 9/8/08, Marco van de Voort [EMAIL PROTECTED] wrote:
That shoulds like a shortstring limit. Is everything in {$H+} or {$mode
delphi} ?
This was my first idea, but I couldn't find anywhere a H+ missing ...
Also, as to my previous statement that it now started without without
reason, it seams only to have moved to a higher limit. I am getting
cut with 310 chars.
Did you open an existing datafile?
procedure TFixedFormatDataSet.InternalInitFieldDefs;
var
i, len, Maxlen :Integer;
LstFields :TStrings;
begin
if not Assigned(FData) then
exit;
FRecordSize := 0;
Maxlen := 0;
FieldDefs.Clear;
for i := FData.Count - 1 downto 0 do // Find out the longest record --
begin
len := Length(FData[i]);
if len Maxlen then
Maxlen := len; --
FData.Objects[i] := TObject(Pointer(i+1)); // Fabricate Bookmarks
end;
if (Maxlen = 0) then
Maxlen := MAXSTRLEN;
LstFields := TStringList.Create;
try
LoadFieldScheme(LstFields, Maxlen);
for i := 0 to LstFields.Count -1 do // Add fields
begin
len := StrToIntDef(LstFields.Values[LstFields.Names[i]], Maxlen); --
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TSdfDataset does not work with records larger then 255 chars
On Monday 08 September 2008 19.34:32 Felipe Monteiro de Carvalho wrote: On Mon, Sep 8, 2008 at 10:51 AM, Martin Schreiber [EMAIL PROTECTED] wrote: Did you open an existing datafile? I am always working opening an existing datafile. So, you are thinking that it calculates the size for the fields upon loading and then it does not increase the field sizes when posting to the database? It seems so if you don't define the field size in the TSdfDataset.Schema. Unlike tmsebufdataset, TSdfDataset stores the data in a record with fixed size which can't be changed after open. Is it possible to define the field size in the first data row? I never used TSdfDataset, I made the integration into MSEgui with tmsesdfdataset only so my knowledge about TSdfDataset is limited. Is Sqlite3 no option for you? MSEgui and FPC sqldb both have a DB-connection component for SQLite3. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TSdfDataset does not work with records larger then 255 chars
On Monday 08 September 2008 20.19:27 Felipe Monteiro de Carvalho wrote: On Mon, Sep 8, 2008 at 3:14 PM, Martin Schreiber [EMAIL PROTECTED] wrote: It seems so if you don't define the field size in the TSdfDataset.Schema. Unlike tmsebufdataset, TSdfDataset stores the data in a record with fixed size which can't be changed after open. Is it possible to define the field size in the first data row? Didn't work: ID,NAMEEN,NAMEPT,HEIGHT,WIDTH,PINS,DRAWINGCODE = 2048 chars It hits the same limit as before. ID,NAMEEN,NAMEPT,HEIGHT,WIDTH,PINS,DRAWINGCODE = 2048 works for me, it returns the fieldsize of 53 (the character count of the first row) for ID, NAMEEN, NAMEPT, HEIGHT, WIDTH and PINS and 2048 for DRAWINGCODE. I have found sdf better then sqlite3 (except for the bugs) for my small database needs, because I then I don't need an external library and I like the fact that i can easely edit the database with a text editor. MSEgui tstatfile or ttextdatastream are other options, probably Lazarus has similar components? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
Martin Schreiber schrieb:
Next problem is that pmsechar(msestring) returns a NIL pointer if
msestring = ''. As designed? The behaviour of ansistring and widestring
was very useful, I'd like if UnicodeString would behave the same.
Do you have some example code which shows this?
See attachment.
Test result:
F:\proj\testcase\fpc\unicode\punicodecharpunicodechartest.exe
4288048
4288048
0
0
0
An unhandled exception occurred at $004016C5 :
EAccessViolation : Access violation
$004016C5 main, line 25 of punicodechartest.pas
Martin
program punicodechartest;
{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
{$ifdef mswindows}{$apptype console}{$endif}
uses
{$ifdef FPC}{$ifdef linux}cthreads,{$endif}{$endif}
sysutils;
var
astr: ansistring;
wstr: widestring;
ustr: unicodestring;
begin
astr:= '';
wstr:= '';
ustr:= '';
writeln(ptrint(pansichar(astr)));
flush(output);
writeln(ptrint(pwidechar(wstr)));
flush(output);
writeln(ptrint(punicodechar(ustr)));
flush(output);
writeln(ord(pansichar(astr)^));
flush(output);
writeln(ord(pwidechar(wstr)^));
flush(output);
writeln(ord(punicodechar(ustr)^));
flush(output);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Sunday 07 September 2008 10.58:03 Florian Klaempfl wrote: Martin Schreiber schrieb: On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote: Martin Schreiber schrieb: Next problem is that pmsechar(msestring) returns a NIL pointer if msestring = ''. As designed? The behaviour of ansistring and widestring was very useful, I'd like if UnicodeString would behave the same. Do you have some example code which shows this? Fixed. Trunk 11723 does not compile: make[7]: Entering directory `E:/FPC/svn/trunk/rtl/win32' C:/FPC/2.2.2/bin/i386-Win32/gmkdir.exe -p E:/FPC/svn/trunk/rtl/units/i386-win32 C:/FPC/2.2.2/bin/i386-Win32/ppc386.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi.. /win -FE. -FUE:/FPC/svn/trunk/rtl/units/i386-win32 -di386 -dRELEASE -Us -Sg system.pp -Fi../win wustring22.inc(699,27) Fatal: Unknown compilerproc fpc_char_to_wchar. Check if you use the correct run time library. Fatal: Compilation aborted make[7]: *** [system.ppu] Fehler 1 make[7]: Leaving directory `E:/FPC/svn/trunk/rtl/win32' make[6]: *** [win32_all] Fehler 2 make[6]: Leaving directory `E:/FPC/svn/trunk/rtl' make[5]: *** [rtl] Fehler 2 make[5]: Leaving directory `E:/FPC/svn/trunk/compiler' make[4]: *** [next] Fehler 2 make[4]: Leaving directory `E:/FPC/svn/trunk/compiler' make[3]: *** [ppc1.exe] Fehler 2 make[3]: Leaving directory `E:/FPC/svn/trunk/compiler' make[2]: *** [cycle] Fehler 2 make[2]: Leaving directory `E:/FPC/svn/trunk/compiler' make[1]: *** [compiler_cycle] Fehler 2 make[1]: Leaving directory `E:/FPC/svn/trunk' make: *** [build-stamp.i386-win32] Fehler 2 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Sunday 07 September 2008 21.23:24 Florian Klaempfl wrote: Trunk 11723 does not compile: Trunk or unicodestring branch? Strange, because here it works? Unicodestring branch, sorry, I should change the directory name of my switched checkout. Does your unicodestring branch compile? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Friday 05 September 2008 22.50:23 Florian Klaempfl wrote: If you want to try it yourself, MSEide+MSEgui trunk rev. 2473 has msestring = unicodestring if compiled with -dmse_unicodestring. What's the official way to compile MSE? cd apps\ide ppc386.exe -Fu..\..\lib\common\* -Fi..\..\lib\common\kernel -Fu..\..\lib\common\kernel\i386-win32 mseide.pas or open apps\ide\mseide.prj in MSEide with 'Project'-'Open', 'Project'-'Make'. In order to test UnicodeString the commadline is: ppc386.exe -dmse_unicodestring -Fu..\..\lib\common\* -Fi..\..\lib\common\kernel -Fu..\..\lib\common\kernel\i386-win32 mseide.pas If you want to debug the compiler with MSEide add the compiler source directories to 'Project'-'Options'-'Debugger'-'Source directories'. From an older post of this list: This is for MSEide i386 and FPC 2.3.1: http://sourceforge.net/project/showfiles.php?group_id=165409 - 'Project'-'New'-'From Program'. - Select compiler/pp.pas from your FPC SVN checkout. - Accept pp.prj. - 'Project'-'Options'-'Make'-'Make options', add -di386 (without quotes) to the first row of 'Command line options'. - 'Project'-'Options'-'Make'-'Directories', add a row, select compiler/i386/ - Add a row with /compiler/x86/. - Add a row with /compiler/systems/. - Set the commandline parameters for the target in 'Target'-'Environment'. - Press F9. You should possibly change the unit output directory to be consistent with the make file. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Friday 05 September 2008 22.50:23 Florian Klaempfl wrote:
[...]
This should be fixed.
Thanks, FPC and MSEide compile now.
Attached an emergency patch that I could load the MSEgui forms, not finished
and not tested. Is TTypekind = (... tkInterfaceRaw,tkUChar,tkUString)
correct?
Next problem is that pmsechar(msestring) returns a NIL pointer if msestring
= ''. As designed? The behaviour of ansistring and widestring was very
useful, I'd like if UnicodeString would behave the same.
Thanks, Martin
Index: rtl/objpas/classes/classesh.inc
===
--- rtl/objpas/classes/classesh.inc (revision 11713)
+++ rtl/objpas/classes/classesh.inc (working copy)
@@ -899,7 +899,8 @@
TValueType = (vaNull, vaList, vaInt8, vaInt16, vaInt32, vaExtended,
vaString, vaIdent, vaFalse, vaTrue, vaBinary, vaSet, vaLString,
-vaNil, vaCollection, vaSingle, vaCurrency, vaDate, vaWString, vaInt64, vaUTF8String);
+vaNil, vaCollection, vaSingle, vaCurrency, vaDate, vaWString, vaInt64,
+vaUTF8String,vaUString);
TFilerFlag = (ffInherited, ffChildPos, ffInline);
TFilerFlags = set of TFilerFlag;
@@ -965,6 +966,7 @@
function ReadStr: String; virtual; abstract;
function ReadString(StringType: TValueType): String; virtual; abstract;
function ReadWideString: WideString;virtual;abstract;
+function ReadUnicodeString: UnicodeString;virtual;abstract;
procedure SkipComponent(SkipComponentInfos: Boolean); virtual; abstract;
procedure SkipValue; virtual; abstract;
end;
@@ -1016,6 +1018,7 @@
function ReadStr: String; override;
function ReadString(StringType: TValueType): String; override;
function ReadWideString: WideString;override;
+function ReadUnicodeString: UnicodeString;override;
procedure SkipComponent(SkipComponentInfos: Boolean); override;
procedure SkipValue; override;
end;
@@ -1101,6 +1104,7 @@
function ReadBoolean: Boolean;
function ReadChar: Char;
function ReadWideChar: WideChar;
+function ReadUnicodeChar: UnicodeChar;
procedure ReadCollection(Collection: TCollection);
function ReadComponent(Component: TComponent): TComponent;
procedure ReadComponents(AOwner, AParent: TComponent;
@@ -1119,6 +1123,7 @@
function ReadRootComponent(ARoot: TComponent): TComponent;
function ReadString: string;
function ReadWideString: WideString;
+function ReadUnicodeString: UnicodeString;
function ReadValue: TValueType;
procedure CopyValue(Writer: TWriter);
property Driver: TAbstractObjectReader read FDriver;
@@ -1170,6 +1175,7 @@
procedure WriteSet(Value: LongInt; SetType: Pointer); virtual; abstract;
procedure WriteString(const Value: String); virtual; abstract;
procedure WriteWideString(const Value: WideString);virtual;abstract;
+procedure WriteUnicodeString(const Value: UnicodeString);virtual;abstract;
end;
{ TBinaryObjectWriter }
@@ -1220,6 +1226,7 @@
procedure WriteSet(Value: LongInt; SetType: Pointer); override;
procedure WriteString(const Value: String); override;
procedure WriteWideString(const Value: WideString); override;
+procedure WriteUnicodeString(const Value: UnicodeString); override;
end;
TTextObjectWriter = class(TAbstractObjectWriter)
Index: rtl/objpas/classes/reader.inc
===
--- rtl/objpas/classes/reader.inc (revision 11713)
+++ rtl/objpas/classes/reader.inc (working copy)
@@ -339,6 +339,25 @@
end;
end;
+function TBinaryObjectReader.ReadUnicodeString: UnicodeString;
+var
+ len: DWord;
+{$IFDEF ENDIAN_BIG}
+ i : integer;
+{$ENDIF}
+begin
+ len := ReadDWord;
+ SetLength(Result, len);
+ if (len 0) then
+ begin
+Read(Pointer(@Result[1])^, len*2);
+{$IFDEF ENDIAN_BIG}
+for i:=1 to len do
+ Result[i]:=UnicodeChar(SwapEndian(word(Result[i])));
+{$ENDIF}
+ end;
+end;
+
procedure TBinaryObjectReader.SkipComponent(SkipComponentInfos: Boolean);
var
Flags: TFilerFlags;
@@ -749,6 +768,19 @@
raise EReadError.Create(SInvalidPropertyValue);
end;
+function TReader.ReadUnicodeChar: UnicodeChar;
+
+var
+ U: UnicodeString;
+
+begin
+ U := ReadUnicodeString;
+ if Length(U) = 1 then
+Result := U[1]
+ else
+raise EReadError.Create(SInvalidPropertyValue);
+end;
+
procedure TReader.ReadCollection(Collection: TCollection);
var
Item: TCollectionItem;
@@ -1172,7 +1204,7 @@
SetOrdProp(Instance, PropInfo, Ord(ReadBoolean));
tkChar:
SetOrdProp(Instance, PropInfo, Ord(ReadChar));
-tkWChar:
+tkWChar,tkUChar:
SetOrdProp(Instance, PropInfo, Ord(ReadWideChar));
tkEnumeration:
begin
@@ -1217,6 +1249,8 @@
FOnReadStringProperty(Self,Instance,PropInfo,TmpStr);
SetStrProp(Instance, PropInfo, TmpStr);
end;
+tkUstring:
+ SetUnicodeStrProp(Instance,PropInfo,ReadUnicodeString);
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Florian, On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote: I've continued to work on support of an unicodestring type in fpc. It's currently in an svn branch at: http://svn.freepascal.org/svn/fpc/branches/unicodestring and will be merged later to trunk. The unicodestring type is a ref. counted utf-16 string. On non-windows, widestring is mapped to this type. If you're interested in unicode support please test, give feedback here and submit fixes. I tried the unicode branch on Windows, rev. 11711 does not compile: make[7]: Entering directory `E:/FPC/svn/trunk/rtl/win32' E:/FPC/svn/trunk/compiler/ppc1.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE. -FUE:/FPC/svn/trunk/rtl/units/i386-win32 -di386 -dRELEASE -Us -Sg system.pp -Fi../win wstrings.inc(1655,60) Error: Identifier not found CharLengthPChar ustrings.inc(2147,42) Error: Incompatible types: got address of procedure(PCha r,var UnicodeString, LongInt);Register expected procedure variable type of procedure(PChar,var WideString, LongInt);Register ustrings.inc(2148,44) Error: Incompatible types: got address of function(const UnicodeString):UnicodeString;Register expected procedure variable type of function(const WideString):WideString;Register ustrings.inc(2149,44) Error: Incompatible types: got address of function(const UnicodeString):UnicodeString;Register expected procedure variable type of function(const WideString):WideString;Register ustrings.inc(2151,46) Error: Incompatible types: got address of function(const UnicodeString,const UnicodeString):LongInt;Register expected procedure variable type of function(const WideString,const WideString):LongInt;Register ustrings.inc(2152,50) Error: Incompatible types: got address of function(const UnicodeString,const UnicodeString):LongInt;Register expected procedure variable type of function(const WideString,const WideString):LongInt;Register system.pp(1253) Fatal: There were 6 errors compiling module, stopping Fatal: Compilation aborted make[7]: *** [system.ppu] Fehler 1 make[7]: Leaving directory `E:/FPC/svn/trunk/rtl/win32' make[6]: *** [win32_all] Fehler 2 make[6]: Leaving directory `E:/FPC/svn/trunk/rtl' make[5]: *** [rtl] Fehler 2 make[5]: Leaving directory `E:/FPC/svn/trunk/compiler' make[4]: *** [next] Fehler 2 make[4]: Leaving directory `E:/FPC/svn/trunk/compiler' make[3]: *** [ppc2.exe] Fehler 2 make[3]: Leaving directory `E:/FPC/svn/trunk/compiler' make[2]: *** [cycle] Fehler 2 make[2]: Leaving directory `E:/FPC/svn/trunk/compiler' make[1]: *** [compiler_cycle] Fehler 2 make[1]: Leaving directory `E:/FPC/svn/trunk' make: *** [build-stamp.i386-win32] Fehler 2 Compiling MSEide with rev. 11667 I get: Free Pascal Compiler version 2.3.1 [2008/09/05] for i386 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Win32 for i386 Compiling mseide.pas [...] msestream.pas(762,2) Warning: Class types tmsefilestream and THandleStreamcracker are not related msestream.pas(785,33) Warning: Class types tmsefilestream and THandleStreamcracker are not related msestream.pas(810,34) Warning: Class types tmsefilestream and THandleStreamcracker are not related msesysintf.pas(1552,21) Fatal: Unknown compilerproc fpc_widechararray_to_unicodestr. Check if you use the correct run time library. Fatal: Compilation aborted If you want to try it yourself, MSEide+MSEgui trunk rev. 2473 has msestring = unicodestring if compiled with -dmse_unicodestring. I found no UnicodeString support in typeinfo and variants? What are the plans for Unicode resourcestrigs? TField should probably have an asUnicodeString property too. Thank you very much for your work. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] generated assembler
On Wednesday 03 September 2008 11.07:49 Graeme Geldenhuys wrote: Hi, I know it's possible, but I can't remember the exact FPC parameters. How do I see the assembler generated by FPC for my source code? I need to do some optimisation comparisons looking at the assembler generated. eg: Is assembler code generated for a call to a blank (no content) procedure? The content of the procedure might be IFDEF'd out. You could use breakpoints and the (dis-)assembler window of MSEide, it lists mixed pascal and machine code. The SVN trunk version has some improvements in (dis-)assembler window, for example the possibility to set breakpoints on machine instructions. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] generated assembler
On Wednesday 03 September 2008 12.04:23 Graeme Geldenhuys wrote: On 9/3/08, Martin Schreiber [EMAIL PROTECTED] wrote: You could use breakpoints and the (dis-)assembler window of MSEide, it lists mixed pascal and machine code. Thanks Martin, I'll take a look. What I'm trying to find out (with my rusty assembler knowledge) is if a lot of IFDEF's around procedure calls, compared to only one IFDEF inside a procedure would make a difference in performance and the code generated. I would prefer example 2 (it looks cleaner and would be less work), and from my quick/crude analysis, it seems both options generate pretty much the same code if the gDEBUG define is disabled (does NOT exist). For the people who don't know MSEide attached a screenshot, I hope the file is not too big. It is with -O3. With inline there is still some overhead because of the string variable. Martin attachment: assemblerwindow.png___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] generated assembler
On Wednesday 03 September 2008 12.53:09 Graeme Geldenhuys wrote: On 9/3/08, Martin Schreiber [EMAIL PROTECTED] wrote: For the people who don't know MSEide attached a screenshot, I hope the file is not too big. It is with -O3. With inline there is still some overhead because of the string variable. OK, thanks Martin. Debugging in MSEide seems quite impressive. I can see you put a lot of effort into writing it. Because I implement so many bugs, I need an excellent IDE. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tuesday 29 July 2008 09.54:54 Graeme Geldenhuys wrote: A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses UTF-8 as the internal string encoding. He noticed that the File Dialog which displays the file sizes with thousand separators were totally blank. On further investigation he noticed that it was FormatFloat() that caused the issue. FormatFloat uses the ThousandSeparator locale variable. In FPC the ThousandSeparator is of type Char which can only hold one byte. Yet the Russian locale uses the non-breaking space character as expressed in UTF-8 as 'C2 A0' (bytes) and takes up 2 bytes. So how do we assign the Russian ThousandSeparator (U+00A0) in FPC to the ThousandSeparator variable? MSEgui has a widestring version of the FormatFloat function (lib/common/kernel/mseformatstr.pas formatfloatmse). There were no bug reports from Russian users, so it seems to work, although I did not test the U+00A0 ThousandSeparator... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
On Tuesday 15 April 2008 21.13:41 Jonas Maebe wrote: On 15 Apr 2008, at 21:05, Martin Schreiber wrote: Moving msesysintf from implementation uses to interface uses in msefileutils fixes the issue. I know what causes the crc problem: the fact that msesysintf declares routines as external name in the implementation which aren't declared as external name in the interface. This is supported for Delphi-compatibility, but is quite ugly (it also causes wrappers to be generated because it is possible that units which were compiled after only the interface was parsed may already contain calls to the non- external but regularly mangled Pascal name). You are right, after moving all exernal name declarations to interface I could move back uses msesysintf to implementation in msefileutils and the project compiled. Thanks a lot! Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] MSEide+MSEgui binary package
Hi,
We try to build a package for MSEide+MSEgui with precompiled units. While
compiling a simple testproject with the precompiled units we get:
Free Pascal Compiler version 2.2.0 [2007/08/31] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Linux for i386
Compiling project1.pas
PPU
Loading
/home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu
PPU Source: msesysintf.pas not found
PPU Source: msesysintf.inc not found
PPU
Loading
/home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu
PPU Source: msesysintf.pas not found
PPU Source: msesysintf.inc not found
PPU
Loading
/home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu
PPU Source: msesysintf.pas not found
PPU Source: msesysintf.inc not found
PPU
Loading
/home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu
PPU Source: msesysintf.pas not found
PPU Source: msesysintf.inc not found
Recompiling msesysintf, checksum changed for msefileutils {impl}
Fatal: Can't find unit msesysintf used by msesysutils
Fatal: Compilation aborted
What do we wrong, any hints?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
On Tuesday 15 April 2008 09.26:30 Micha Nelissen wrote:
Martin Schreiber wrote:
Recompiling msesysintf, checksum changed for msefileutils {impl}
Fatal: Can't find unit msesysintf used by msesysutils
Fatal: Compilation aborted
What do we wrong, any hints?
Do you have multiple installed msefileutils? Recompile with -va to see
what's going on.
The loaded msefileutils seems to be OK:
[15.878] PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/msefileutils.ppu
[15.878] PPU
Name: /home/mse/packs/standard/svn/mse/trunk/units/kernel/msefileutils.ppu
[15.878] PPU Time: 2008/04/15 08:46:51
[15.878] PPU Flags: 217216
[15.878] PPU Crc: 01F733A0
[15.878] PPU Crc: B8ECEB6F (intfc)
[15.878] Number of definitions: 267
[15.878] Number of symbols: 723
The -va result is on:
http://homepage.bluewin.ch/msegui/pics/test.txt.bz2
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
On Tuesday 15 April 2008 10.36:24 Jonas Maebe wrote:
On 15 Apr 2008, at 09:05, Martin Schreiber wrote:
Recompiling msesysintf, checksum changed for msefileutils {impl}
Fatal: Can't find unit msesysintf used by msesysutils
Fatal: Compilation aborted
What do we wrong, any hints?
Do you perhaps have routines marked as inline in circular
(implementation) dependent units? That can cause this problem (and
will keep causing it until the grand unit loading rewrite planned for
2.4.0 or 3.0.0).
There are no inline routines in MSEgui up to now (Delphi 7 compatibility). Can
inlined routines from FPC-RTL be harmfull too?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
On Tuesday 15 April 2008 13.25:14 Jonas Maebe wrote: Another reason might be this: http://bugs.freepascal.org/view.php?id=10551 I tried with fixes_2_2 and trunk, the problem is the same. Should I play with uses order in msefileutils? Any other suggestion? Could it be related to: http://bugs.freepascal.org/view.php?id=11062 ? Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
On Tuesday 15 April 2008 20.23:39 Jonas Maebe wrote:
On 15 Apr 2008, at 19:59, Martin Schreiber wrote:
On Tuesday 15 April 2008 13.25:14 Jonas Maebe wrote:
Another reason might be this:
http://bugs.freepascal.org/view.php?id=10551
I tried with fixes_2_2 and trunk, the problem is the same.
That bug was also reported for 2.2.0 and hasn't been fixed anywhere.
Should I play with
uses order in msefileutils? Any other suggestion?
Compile the pre-compiled units with -Ur
No success:
Free Pascal Compiler version 2.2.0 [2007/08/31] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Linux for i386
Compiling project1.pas
PPU
Loading
/home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu
PPU
Loading
/home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu
PPU
Loading
/home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu
PPU
Loading
/home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu
Recompiling msesysintf, checksum changed for msefileutils {impl}
Fatal: Can't find unit msesysintf used by msesysutils
Fatal: Compilation aborted
How can I check if I really produced release units?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
On Tuesday 15 April 2008 20.42:24 Martin Schreiber wrote: How can I check if I really produced release units? I think I produced release units, they are not recompiled with -B. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
On Tuesday 15 April 2008 20.49:39 Jonas Maebe wrote: I'm actually not sure whether -Ur makes the compiler also disregard any interface changes, but I think it does. Or are you not compiling msefileutils with -Ur at this point? (and did you only compile previous units with -Ur) I deleted all *.ppu *.o and *.a files before compiling with -Ur. How can I check if I really produced release units? ppudump unit.ppu|grep Unit flags - check if release is mentioned Thanks, I found a workaround: Moving msesysintf from implementation uses to interface uses in msefileutils fixes the issue. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
On Tuesday 15 April 2008 21.13:41 Jonas Maebe wrote: On 15 Apr 2008, at 21:05, Martin Schreiber wrote: Moving msesysintf from implementation uses to interface uses in msefileutils fixes the issue. I know what causes the crc problem: the fact that msesysintf declares routines as external name in the implementation which aren't declared as external name in the interface. This is supported for Delphi-compatibility, but is quite ugly (it also causes wrappers to be generated because it is possible that units which were compiled after only the interface was parsed may already contain calls to the non- external but regularly mangled Pascal name). That means all external name declarations should be in interface section? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with trunk/cleanroom
On Monday 07 April 2008 08.46:46 Michael Van Canneyt wrote: On Mon, 7 Apr 2008, Martin Schreiber wrote: Hi, We spent some days with debugging MSEide+MSEgui with FPC trunk. Sometimes there are AV's while calling an interface procedure. Example: http://homepage.bluewin.ch/msegui/pics/crash.png I don't know if it is a cleanroom, a FPC trunk or another problem. I stop cleanroom debugging now until the code is merged to fixes_2_2, there is too much indeterminateness by changing the compiler and the whole rtl additionally to the cleanroom code. As soon as the childpos thing is fixed, I'll merge the lot to fixes. I found the problem, see attachment. :-) Martin --- home/mse/packs/standard/svn/fp/trunk/rtl/objpas/classes/.svn/text-base/resref.inc.svn-base 2008-03-27 22:49:30.0 +0100 +++ tmp/svndiff.tmp 2008-04-08 15:55:16.0 +0200 @@ -392,7 +392,7 @@ // Collect all matches. While (RNil) do begin - If R.RootMatches(FRoot) and (FRef=UpperCase(R.FGLobal)) Then + If R.RootMatches(FRoot) and ((FRef = '') or (FRef=UpperCase(R.FGLobal))) Then begin If Not Assigned(L) then L:=TFPList.Create; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging FPC
On Monday 07 April 2008 09.22:11 Никита Баль wrote: Does anybody tryed to debug fpc under Lazarus? How? This is for MSEide i386 and FPC 2.3.1: http://sourceforge.net/project/showfiles.php?group_id=165409 - 'Project'-'New'-'From Program'. - Select compiler/pp.pas from your FPC SVN checkout. - Accept pp.prj. - 'Project'-'Options'-'Make'-'Make options', add -di386 (without quotes) to the first row of 'Command line options'. - 'Project'-'Options'-'Make'-'Directories', add a row, select compiler/i386/ - Add a row with /compiler/x86/. - Add a row with /compiler/systems/. - Set the commandline parameters for the target in 'Target'-'Environment'. - Press F9. You should possibly change the unit output directory to be consistent with the make file. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Saturday 05 April 2008 20.56:01 Jonas Maebe wrote: It works with gdb 6.6, but indeed not with 6.8. I'll try to find the cause and file a bug report with gdb if necessary. I've implemented a workaround in the compiler and submitted a gdb bug report. Tested with dwarf and gdb 6.6.50 and 6.8.50 - works. Thank you very much! Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problems with trunk/cleanroom
Hi, We spent some days with debugging MSEide+MSEgui with FPC trunk. Sometimes there are AV's while calling an interface procedure. Example: http://homepage.bluewin.ch/msegui/pics/crash.png I don't know if it is a cleanroom, a FPC trunk or another problem. I stop cleanroom debugging now until the code is merged to fixes_2_2, there is too much indeterminateness by changing the compiler and the whole rtl additionally to the cleanroom code. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Friday 04 April 2008 19.40:30 Jonas Maebe wrote: And this 6.6 also works fine with stabs. I tried with gdb 6.8.50: GNU gdb 6.8.50.20080306 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-linux-gnu... (gdb) break reader.inc:1260 Breakpoint 1 at 0x80d742e: file ../objpas/classes/reader.inc, line 1260. (gdb) run Starting program: /home/mse/packs/standard/svn/mse/trunk/apps/ide/mseidefp [Thread debugging using libthread_db enabled] [New Thread 0xb7b538d0 (LWP 5905)] [Switching to Thread 0xb7b538d0 (LWP 5905)] Breakpoint 1, READROOTCOMPONENT (READROOTCOMPONENT=0xb77a5020, AROOT=0xb77a5020, this=0xb7795020) at ../objpas/classes/reader.inc:1260 1260 Result.FComponentState := (gdb) print result.fcomponentstate $1 = [] (gdb) next 1264 i := 0; (gdb) print result.fcomponentstate $2 = [] (gdb) BTW the set display is not always wrong. This is with stabs (-O- -gl): GNU gdb 6.8.50.20080306 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-linux-gnu... (gdb) break main.pas:1422 Breakpoint 1 at 0x80a7094: file main.pas, line 1422. (gdb) run Starting program: /home/mse/packs/standard/svn/mse/trunk/apps/ide/mseidefp [Thread debugging using libthread_db enabled] [New Thread 0xb7b5d8d0 (LWP 8469)] [Switching to Thread 0xb7b5d8d0 (LWP 8469)] Breakpoint 1, MAINONLOADED (SENDER=0xb7579870, this=0xb7579870) at main.pas:1422 1422 mainstatfile.readstat; (gdb) bt #0 MAINONLOADED (SENDER=0xb7579870, this=0xb7579870) at main.pas:1422 #1 0x08189347 in DOEVENTLOOPSTART (this=0xb7579870) at ../../lib/common/widgets/mseforms.pas:848 #2 0x08189393 in RECEIVEEVENT (EVENT=0xb7b54be0, this=0xb7579870) at ../../lib/common/widgets/mseforms.pas:857 #3 0x080f88ea in DELIVER (this=0xb7b54be0) at ../../lib/common/kernel/mseevent.pas:195 #4 0x08083080 in EVENTLOOP (EVENTLOOP=false, AMODALWINDOW=0x0, ONCE=false, this=0xb79b4020) at ../../lib/common/kernel/msegui.pas:12320 #5 0x08083dcc in DOEVENTLOOP (ONCE=false, this=0xb79b4020) at ../../lib/common/kernel/msegui.pas:12715 #6 0x080f6f38 in RUN (this=0xb79b4020) at ../../lib/common/kernel/mseapplication.pas:1064 #7 0x0804c759 in main () at mseide.pas:57 (gdb) Hurray! Now MSEide and probably Lazarus too have a problem: debugging of FPC trunk applications will not work with some distributions. OpenSuse 10.3 gdb crashes with stabs and does not show set results correctly with dwarf. The need of different debugger compiler switches for different compiler versions is not ideal anyway. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Saturday 05 April 2008 10.25:45 Martin Schreiber wrote: Hurray! Update: GNU gdb 6.8.50.20080306 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-linux-gnu... (gdb) break main.pas:1422 Breakpoint 1 at 0x80a6884: file main.pas, line 1422. (gdb) run Starting program: /home/mse/packs/standard/svn/mse/trunk/apps/ide/mseidefp [Thread debugging using libthread_db enabled] [New Thread 0xb7c038d0 (LWP 9561)] [Switching to Thread 0xb7c038d0 (LWP 9561)] Breakpoint 1, TMAINFO__MAINONLOADED (SENDER=0xb761f870, this=0xb761f870) at main.pas:1422 1422 mainstatfile.readstat; (gdb) bt #0 TMAINFO__MAINONLOADED (SENDER=0xb761f870, this=0xb761f870) at main.pas:1422 #1 0x08188b37 in TCUSTOMMSEFORM__DOEVENTLOOPSTART (this=0xb761f870) at mseforms.pas:848 #2 0x08188b83 in TCUSTOMMSEFORM__RECEIVEEVENT (EVENT=0xb7bfabe0, this=0xb761f870) at mseforms.pas:857 Segmentation fault :-( Because of the missing TMAINFO_ it was probably dwarf and not stabs which worked before. Argh, so many different possibilities to make errors... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Saturday 05 April 2008 13.32:40 Jonas Maebe wrote: in a cross-platform way. Does the unix expect utility exist for Windows? http://expect.nist.gov/ lists two native windows ports and the cygwin port. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Saturday 05 April 2008 14.33:16 Jonas Maebe wrote: Fixed. gdb 6.5 also works again. It starts a lot slower than 6.6, so I guess 6.5 read all debug information on startup (which is why it crashed immediately) while 6.6 and later only read the debug info as needed (and hence only crashed when the type info it can't handle was needed). Tested with stabs and gdb 6.6.50 and 6.8.50 - works. Thanks a lot! For an automated test you could use gdb scripts? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Thursday 03 April 2008 15.02:46 Martin Schreiber wrote: On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote: One thing you can try is using -gw to use dwarf instead of stabs. That helps, thanks a lot! There are gdb crashes with -gw too: [EMAIL PROTECTED]:~/packs/standard/svn/mse/trunk/apps/ide gdb ./mseidefp GNU gdb 6.6.50.20070726-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i586-suse-linux... Using host libthread_db library /lib/libthread_db.so.1. (gdb) break fpc_raiseexception Breakpoint 1 at 0x805b635: file ../inc/except.inc, line 195. (gdb) run Starting program: /home/mse/packs/standard/svn/mse/trunk/apps/ide/mseidefp [Thread debugging using libthread_db enabled] [New Thread 0xb7bb88d0 (LWP 5338)] [Switching to Thread 0xb7bb88d0 (LWP 5338)] Breakpoint 1, fpc_raiseexception (fpc_raiseexception=0x846aee0, OBJ=0xb7bb1da0, ANADDR=0x80dd526, AFRAME=0xbfeef30c) at ../inc/except.inc:195 195 fpc_Raiseexception:=nil; (gdb) c Continuing. Breakpoint 1, fpc_raiseexception (fpc_raiseexception=0x846aee0, OBJ=0xb7bb2830, ANADDR=0x80dd526, AFRAME=0xbfeeef4c) at ../inc/except.inc:195 195 fpc_Raiseexception:=nil; (gdb) Continuing. Breakpoint 1, fpc_raiseexception (fpc_raiseexception=0x846aee0, OBJ=0xb7bb2580, ANADDR=0x80dd526, AFRAME=0xbfeeef4c) at ../inc/except.inc:195 195 fpc_Raiseexception:=nil; (gdb) Continuing. Breakpoint 1, fpc_raiseexception (fpc_raiseexception=0x846aee0, OBJ=0xb7bb2830, ANADDR=0x80dd526, AFRAME=0xbfeeef4c) at ../inc/except.inc:195 195 fpc_Raiseexception:=nil; (gdb) Continuing. Breakpoint 1, fpc_raiseexception (fpc_raiseexception=0x846aee0, OBJ=0xb7bb26a0, ANADDR=0x80dd526, AFRAME=0xbfeeef4c) at ../inc/except.inc:195 195 fpc_Raiseexception:=nil; (gdb) Continuing. Breakpoint 1, fpc_raiseexception (fpc_raiseexception=0x846aee0, OBJ=0xb7bb26d0, ANADDR=0x80dd526, AFRAME=0xbfeeef4c) at ../inc/except.inc:195 195 fpc_Raiseexception:=nil; (gdb) Continuing. Breakpoint 1, fpc_raiseexception (fpc_raiseexception=0x846aee0, OBJ=0xb7bb26a0, ANADDR=0x80dd526, AFRAME=0xbfeeef4c) at ../inc/except.inc:195 195 fpc_Raiseexception:=nil; (gdb) Continuing. [New Thread 0xb74cab90 (LWP 5347)] Breakpoint 1, fpc_raiseexception (fpc_raiseexception=0x84642e0, OBJ=0xb7bb24b0, ANADDR=0x80ccd55, AFRAME=0xbfeef428) at ../inc/except.inc:195 195 fpc_Raiseexception:=nil; (gdb) bt #0 fpc_raiseexception (fpc_raiseexception=0x84642e0, OBJ=0xb7bb24b0, ANADDR=0x80ccd55, AFRAME=0xbfeef428) at ../inc/except.inc:195 #1 0x080ccd61 in VALIDATERENAME (ACOMPONENT=0xb74d1a80, CURNAME=0x0, NEWNAME=0xb76dc188 'inlinefo2', this=0xb74cfc10) at ../objpas/classes/compon.inc:364 #2 0x080ccbff in SETNAME (NEWNAME=0xb76dc188 'inlinefo2', this=0xb74d1a80) at ../objpas/classes/compon.inc:313 #3 0x080d56bc in READCOMPONENT (READCOMPONENT=0xb74d1a80, COMPONENT=0x0, this=0xb755c220) at ../objpas/classes/reader.inc:854 #4 0x080d5ae5 in READDATA (INSTANCE=0xb74cfc10, this=0xb755c220) at ../objpas/classes/reader.inc:920 #5 0x080cca57 in READSTATE (READER=0xb755c220, this=0xb74cfc10) at ../objpas/classes/compon.inc:272 #6 0x080fc8e5 in TMSECOMPONENT__READSTATE (READER=0xb755c220, this=0xb74cfc10) at mseclasses.pas:2834 #7 0x08189983 in TCUSTOMMSEFORM__READSTATE (READER=0xb755c220, this=0xb74cfc10) at mseforms.pas:1206 #8 0x080d6dab in READROOTCOMPONENT (READROOTCOMPONENT=0xb74cfc10, AROOT=0xb74cfc10, this=0xb755c220) at ../objpas/classes/reader.inc:1289 #9 0x0816782c in TDESCENDENTINSTANCELIST__MODULEMODIFIED (AMODULE=0xb76cc5b0, this=0xb7ba0570) at msedesigner.pas:1277 #10 0x08169960 in TMODULELIST__COMPONENTMODIFIED (ACOMPONENT=0xb75fee30, this=0xb7b99e20) at msedesigner.pas:2097 #11 0x0816b2c2 in TDESIGNER__COMPONENTMODIFIED (COMPONENT=0xb75fee30, this=0xb77ea020) at msedesigner.pas:2802 #12 0x08167acc in TDESCENDENTINSTANCELIST__MODULEMODIFIED (AMODULE=0xb76cc470, this=0xb7ba0570) at msedesigner.pas:1341 #13 0x08169960 in TMODULELIST__COMPONENTMODIFIED (ACOMPONENT=0xb7602100, this=0xb7b99e20) at msedesigner.pas:2097 #14 0x0816b2c2 in TDESIGNER__COMPONENTMODIFIED (COMPONENT=0xb7602100, this=0xb77ea020) at msedesigner.pas:2802 #15 0x0826e595 in TDESIGNWINDOW__DOMODIFIED (this=0xb7808620) at formdesigner.pas:2080 #16 0x0826ef59 in TFORMDESIGNERFO__DOASYNCEVENT (ATAG=1, this=0xb7602c80) at formdesigner.pas:2343 ---Type return to continue, or q return to quit--- #17 0x080fc22d in TMSECOMPONENT__RECEIVEEVENT (EVENT=0xb752b1e0, this=0xb7602c80) at mseclasses.pas:2588 #18 0x080f4b17 in TACTCOMPONENT__RECEIVEEVENT (EVENT=0xb752b1e0, this=0xb7602c80) at mseapplication.pas:388 #19 0x0807b1ba in TWIDGET__RECEIVEEVENT (EVENT=0xb752b1e0, this=0xb7602c80
Re: [fpc-devel] gdb crashes with trunk
On Friday 04 April 2008 08.37:24 Martin Schreiber wrote: On Thursday 03 April 2008 15.02:46 Martin Schreiber wrote: On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote: One thing you can try is using -gw to use dwarf instead of stabs. That helps, thanks a lot! There are gdb crashes with -gw too: [EMAIL PROTECTED]:~/packs/standard/svn/mse/trunk/apps/ide gdb ./mseidefp I was to fast with the my messages, i didn't compile all units with -gw, sorry. I'll investigate further. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Friday 04 April 2008 08.48:59 Martin Schreiber wrote: On Friday 04 April 2008 08.37:24 Martin Schreiber wrote: On Thursday 03 April 2008 15.02:46 Martin Schreiber wrote: On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote: One thing you can try is using -gw to use dwarf instead of stabs. That helps, thanks a lot! There are gdb crashes with -gw too: [EMAIL PROTECTED]:~/packs/standard/svn/mse/trunk/apps/ide gdb ./mseidefp I was to fast with the my messages, i didn't compile all units with -gw, sorry. I'll investigate further. Yup, the gdb crash vanished when I compiled correct. The wrong set display is still there. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 03 April 2008 10.58:26 Michael Van Canneyt wrote: On Thu, 3 Apr 2008, Martin Schreiber wrote: You used my copyrighted code, the sources look exactly the same. ;-) A strong case against all these copyright suits... :-) And we made the same error, see attachment. It is a little bit more complicated. I hope I got the coding style right. ;-) Martin --- home/mse/packs/standard/svn/fp/trunk/rtl/objpas/classes/.svn/text-base/writer.inc.svn-base 2008-04-03 11:06:35.0 +0200 +++ tmp/svndiff.tmp 2008-04-04 11:51:29.0 +0200 @@ -595,10 +595,15 @@ begin Dummy:=0; Flags := []; - If Assigned(FAncestor) then -Flags:=[ffInherited]; - if csInline in Instance.ComponentState then -Flags:=Flags+[ffInline]; + If (FAncestor nil) and + //has ancestor + (not (csInline in Instance.ComponentState) or + //no inline component + (csAncestor in Instance.Componentstate) and (FAncestors nil)) then + //the inline component is inherited +Flags:=[ffInherited] + else If csInline in Instance.ComponentState then +Flags:=[ffInline]; FDriver.BeginComponent(Instance,Flags, Dummy); WriteProperties(Instance); WriteListEnd; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: While extensive testing has been done (using the FPCunit testing framework), and the working of Lazarus with this new code was verified, it is possible that bugs remain. We would therefor very much appreciate that if you have code that uses some of the routines below, that you test your code with the latest FPC from subversion (revision 10572 or above) and report any bugs that you may encounter. If you do, please submit a bugreport in mantis: http://bugs.freepascal.org/ The next problem is childpos handling: http://bugs.freepascal.org/view.php?id=11102 Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Alternatively, you can write the test case ;-) I'll do. The first is http://bugs.freepascal.org/view.php?id=11069 Fixed; There is no test to see what happens when you stream a descendent of a form with an inline form; if you have such a case, please test it. Argh, I just made it too! OK, I'll update from trunk and test it. There are interesting cases with inlined inherited components and the like. Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Alternatively, you can write the test case ;-) I'll do. The first is http://bugs.freepascal.org/view.php?id=11069 Fixed; There is no test to see what happens when you stream a descendent of a form with an inline form; if you have such a case, please test it. You used my copyrighted code, the sources look exactly the same. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] gdb crashes with trunk
Hi, I am currently debugging the cleanroom code which is a frustrating matter because gdb crashes at allmost every breakpoint. Any hints how to let gdb work more stable with trunk on i386-linux? I compile with -O- already, gdb version is 6.6.50.20070726-cvs. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Thursday 03 April 2008 13.54:32 Martin Schreiber wrote: Hi, I am currently debugging the cleanroom code which is a frustrating matter because gdb crashes at allmost every breakpoint. Any hints how to let gdb work more stable with trunk on i386-linux? I compile with -O- already, gdb version is 6.6.50.20070726-cvs. OK, I found something my self, hiding the stack window of MSEide helps in some cases. If gdb crashes, there is no information about procedure parameters in the stack trace. Example: #0 080D9CBD writer.inc:897 TWRITER__WRITEPROPERTY() #1 080D9086 writer.inc:678 TWRITER__WRITEPROPERTIES() #2 080D8DF6 writer.inc:603 TWRITER__WRITECOMPONENTDATA() #3 080CCDD7 compon.inc:386 TCOMPONENT__WRITESTATE() #4 080FCC12 mseclasses.pas:2915 TMSECOMPONENT__WRITESTATE() #5 080D8B8F writer.inc:545 TWRITER__WRITECOMPONENT() #6 080D8E5E writer.inc:617 TWRITER__WRITEDESCENDENT() #7 080DA25C writer.inc:962 TWRITER__WRITEROOTCOMPONENT() #8 080F90DA mseclasses.pas:979 COPYCOMPONENT() #9 0816B41F msedesigner.pas:2839 TDESIGNER__COPYCOMPONENT() #10 0816A67E msedesigner.pas:2410 TDESIGNER__CREATECOMPONENT() #11 080D54E1 reader.inc:812 TREADER__READCOMPONENT() #12 080D5AE5 reader.inc:920 TREADER__READDATA() #13 080CCA57 compon.inc:272 TCOMPONENT__READSTATE() #14 080FC8E5 mseclasses.pas:2824 TMSECOMPONENT__READSTATE() #15 08189973 mseforms.pas:1206 TCUSTOMMSEFORM__READSTATE() #16 080D6DAB reader.inc:1289 TREADER__READROOTCOMPONENT() #17 0816CE1D msedesigner.pas:3474 TDESIGNER__LOADFORMFILE() #18 080A5EF3 main.pas:1230 TMAINFO__OPENFORMFILE() #19 0808FB96 sourceform.pas:479 TSOURCEFO__UPDATESTAT() #20 08177001 projectoptionsform.pas:1187 UPDATEPROJECTOPTIONS() #21 08179966 projectoptionsform.pas:1559 READPROJECTOPTIONS() #22 080A8A94 main.pas:1892 TMAINFO__OPENPROJECT() #23 080A9A77 main.pas:2152 TMAINFO__MAINSTATFILEONUPDATESTAT() #24 0813D058 msestatfile.pas:142 TSTATFILE__DOSTATREAD() #25 0813407C msestat.pas:751 TSTATREADER__READSTAT() #26 0813D5B3 msestatfile.pas:235 TSTATFILE__READSTAT() #27 080A6899 main.pas:1422 TMAINFO__MAINONLOADED() #28 08188A97 mseforms.pas:848 TCUSTOMMSEFORM__DOEVENTLOOPSTART() #29 08188AE3 mseforms.pas:857 TCUSTOMMSEFORM__RECEIVEEVENT() #30 080F80AA mseevent.pas:195 TOBJECTEVENT__DELIVER() #31 08082870 msegui.pas:12320 TINTERNALAPPLICATION__EVENTLOOP() #32 080835BC msegui.pas:12715 TINTERNALAPPLICATION__DOEVENTLOOP() #33 080F66F8 mseapplication.pas:1064 TCUSTOMAPPLICATION__RUN() #34 0804C759 mseide.pas:57 main() Again, a frustrating matter, debugging without stack window. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote:
On 03 Apr 2008, at 13:54, Martin Schreiber wrote:
I am currently debugging the cleanroom code which is a frustrating
matter
because gdb crashes at allmost every breakpoint.
Any hints how to let gdb work more stable with trunk on i386-linux?
Can you give a reproducible case?
Checkout https://mseide-msegui.svn.sourceforge.net/svnroot/mseide-msegui/trunk
Compile apps/ide/mseide.pas and FPC RTL with FPC trunk and -O- -gl.
[EMAIL PROTECTED]:~/packs/standard/svn/mse/trunk/apps/ide gdb ./mseidefp
GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i586-suse-linux...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) break main.pas:1422
Breakpoint 1 at 0x80a6884: file main.pas, line 1422.
(gdb) set args -np
(gdb) run
Starting program: /home/mse/packs/standard/svn/mse/trunk/apps/ide/mseidefp -np
[Thread debugging using libthread_db enabled]
[New Thread 0xb7c298d0 (LWP 25514)]
[Switching to Thread 0xb7c298d0 (LWP 25514)]
Breakpoint 1, TMAINFO__MAINONLOADED (SENDER=0xb7645870, this=0xb7645870) at
main.pas:1422
1422 mainstatfile.readstat;
(gdb) bt
#0 TMAINFO__MAINONLOADED (SENDER=0xb7645870, this=0xb7645870) at
main.pas:1422
#1 0x08188a97 in TCUSTOMMSEFORM__DOEVENTLOOPSTART (this=0xb7645870) at
mseforms.pas:848
#2 0x08188ae3 in TCUSTOMMSEFORM__RECEIVEEVENT (EVENT=0xb7c20bc0,
this=0xb7645870) at mseforms.pas:857
Segmentation fault
[EMAIL PROTECTED]:~/packs/standard/svn/mse/trunk/apps/ide
It's possible we can work around it
by structuring the debug info differently. Also, did you compile the
trunk units with a trunk compiler or with a 2.2.1 compiler?
make clean all in trunk, compiled the RTL with the new trunk compiler
and -O- -gl.
One thing you can try is using -gw to use dwarf instead of stabs.
That helps, thanks a lot!
#0 080DA2E7 writer.inc:869 WRITEPROPERTY(INSTANCE=0xb74ff0c0,
PROPINFO=0x84d0da9, this=0xb7555cf0)
#1 080D9896 writer.inc:678 WRITEPROPERTIES(INSTANCE=0xb74ff0c0,
this=0xb7555cf0)
#2 080D9606 writer.inc:603 WRITECOMPONENTDATA(INSTANCE=0xb74ff0c0,
this=0xb7555cf0)
#3 080CD5E7 compon.inc:386 WRITESTATE(WRITER=0xb7555cf0, this=0xb74ff0c0)
#4 080FD422 mseclasses.pas:2915 WRITESTATE(WRITER=0xb7555cf0,
this=0xb74ff0c0)
#5 080D939F writer.inc:545 WRITECOMPONENT(COMPONENT=0xb74ff0c0,
this=0xb7555cf0)
#6 080D966E writer.inc:617 WRITEDESCENDENT(AROOT=0xb74ff0c0, AANCESTOR=0x0,
this=0xb7555cf0)
#7 080DAA6C writer.inc:962 WRITEROOTCOMPONENT(AROOT=0xb74ff0c0,
this=0xb7555cf0)
#8 080F98EA mseclasses.pas:979 COPYCOMPONENT(COPYCOMPONENT=0xb75031e0,
SOURCE=0xb74ff0c0, AOWNER=0x0, [EMAIL PROTECTED]: {Proc = {procedure
(^pointer, ^TWRITER = class , ^TCOMPONENT = class , ^Char, ^TCOMPONENT =
class , ^TCOMPONENT = class )} 0xbf8e72d8, Self = 0xb77f7020},
[EMAIL PROTECTED]: {Proc = {procedure (^pointer, ^TREADER =
class , ^Char, ^__vtbl_ptr_type = record )} 0xbf8e72f0, Self = 0xb77f7020},
[EMAIL PROTECTED]: {Proc = {procedure (^pointer, ^TREADER =
class , ^__vtbl_ptr_type = record , ^TCOMPONENT = class )} 0xbf8e72e8, Self =
0xb77f7020}, [EMAIL PROTECTED]: {Proc = {procedure (^pointer,
^TREADER = class , ^Char, ^__vtbl_ptr_type = record , ^TCOMPONENT = class )}
0xbf8e72e0, Self = 0xb77f7020})
#9 0816BC2F msedesigner.pas:2838 COPYCOMPONENT(COPYCOMPONENT=0xbf8e7314,
SOURCE=0xb74ff0c0, ROOT=0xb74ff0c0, this=0xb77f7020)
#10 0816AE8E msedesigner.pas:2410 CREATECOMPONENT(READER=0xb756b740,
COMPONENTCLASS=0x84cea98, [EMAIL PROTECTED]: 0x0, this=0xb77f7020)
#11 080D5CF1 reader.inc:812 READCOMPONENT(READCOMPONENT=0x0, COMPONENT=0x0,
this=0xb756b740)
#12 080D62F5 reader.inc:920 READDATA(INSTANCE=0xb7504ff0, this=0xb756b740)
#13 080CD267 compon.inc:272 READSTATE(READER=0xb756b740, this=0xb7504ff0)
#14 080FD0F5 mseclasses.pas:2824 READSTATE(READER=0xb756b740,
this=0xb7504ff0)
#15 0818A183 mseforms.pas:1206 READSTATE(READER=0xb756b740, this=0xb7504ff0)
#16 080D75BB reader.inc:1289 READROOTCOMPONENT(READROOTCOMPONENT=0xb7504ff0,
AROOT=0xb7504ff0, this=0xb756b740)
#17 0816D62D msedesigner.pas:3474 LOADFORMFILE(LOADFORMFILE=0xb76daff0,
FILENAME=0xb75559d8, this=0xb77f7020)
#18 080A6703 main.pas:1230 OPENFORMFILE(OPENFORMFILE=0x0,
FILENAME=0xb7555708, ASHOW=true, AACTIVATE=false, SHOWSOURCE=false,
CREATEMENU=true, this=0xb75e1870)
#19 080903A6 sourceform.pas:479 UPDATESTAT(STATFILER=0xb75cf460,
this=0xb770c2e0)
#20 08177811 projectoptionsform.pas:1187
UPDATEPROJECTOPTIONS(STATFILER=0xb75cf460, AFILENAME=0xb7bb29d8)
#21 0817A176 projectoptionsform.pas:1559
READPROJECTOPTIONS(READPROJECTOPTIONS=false, FILENAME=0xb7bb29d8)
#22 080A92A4 main.pas:1892
Re: [fpc-devel] gdb crashes with trunk
On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote: One thing you can try is using -gw to use dwarf instead of stabs. It seems sets are displayed as integers with dwarf? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Thursday 03 April 2008 17.18:48 Jonas Maebe wrote: On 03 Apr 2008, at 17:16, Martin Schreiber wrote: On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote: One thing you can try is using -gw to use dwarf instead of stabs. It seems sets are displayed as integers with dwarf? $ ppcppc57 -h [snip] -g Generate debug information (default format for target) [snip] -gox Set debug information options -godwarfsets Enable Dwarf set debug information (breaks gdb 6.5) The compiler crashes with -godwarfsets. Free Pascal Compiler version 2.3.1 [2008/03/28] for i386 Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Linux for i386 Compiling mseide.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/kernel/mseerr.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/kernel/msekeyboard.pas msekeyboard.pas(21,28) Note: Values in enumeration types have to be ascending Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/kernel/i386-linux/msesetlocale.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/kernel/msereal.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/kernel/i386-linux/msesysintf.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/kernel/i386-linux/msesysintf.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/kernel/msehash.pas msehash.pas(464,31) Warning: Converting pointers to signed integers may result in wrong comparison results and range errors, use an unsigned type instead. msehash.pas(681,31) Warning: Converting pointers to signed integers may result in wrong comparison results and range errors, use an unsigned type instead. Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/kernel/i386-linux/msesysintf.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/kernel/msesysutils.pas msesysintf.pas(768,2) Note: Local variable err not used Compiling actionsmodule.pas Compiling main.pas Compiling sourcepage.pas Compiling breakpointsform.pas Compiling sourceform.pas Compiling sourcepage.pas Compiling pascaldesignparser.pas Compiling msedesigner.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/designutils/msedesignintf.pas Compiling msedesigner.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/designutils/msepropertyeditors.pas Compiling msedesigner.pas Compiling formdesigner.pas Compiling componentpaletteform.pas Compiling main.pas Compiling sourcepage.pas Compiling sourcepage_mfm.pas Compiling sourceform.pas Compiling finddialogform.pas Compiling projectoptionsform.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/sysutils/msesysenv.pas Compiling projectoptionsform_mfm.pas Compiling sourceform.pas Compiling finddialogform.pas Compiling finddialogform_mfm.pas Compiling sourceform_mfm.pas Compiling main.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/printer/msepostscriptprinter.pas Compiling /home/mse/packs/standard/svn/mse/trunk/lib/common/printer/mseprinter.pas Fatal: Compilation aborted An unhandled exception occurred at $0819E73F : EAccessViolation : Access violation $0819E73F $0819EA0D $080D5D59 $081A2386 $080D64DE $0811E994 $0810608F $08114594 $0811D7D7 $0811E235 $0810608F $08114594 $0811D7D7 $0811E235 $0810608F $08114594 $0811D7D7 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gdb crashes with trunk
On Thursday 03 April 2008 21.33:17 Jonas Maebe wrote:
On 03 Apr 2008, at 19:12, Martin Schreiber wrote:
The compiler crashes with -godwarfsets.
Fixed.
It doesn't crash anymore, thanks.
The display of sets seems to be wrong:
[EMAIL PROTECTED]:~/packs/standard/svn/mse/trunk/apps/ide gdb ./mseidefp
GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i586-suse-linux...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) break reader.inc:1260
Breakpoint 1 at 0x80d6c1e: file ../objpas/classes/reader.inc, line 1260.
(gdb) run
Starting program: /home/mse/packs/standard/svn/mse/trunk/apps/ide/mseidefp
[Thread debugging using libthread_db enabled]
[New Thread 0xb7c188d0 (LWP 4821)]
[Switching to Thread 0xb7c188d0 (LWP 4821)]
Breakpoint 1, READROOTCOMPONENT (READROOTCOMPONENT=0xb786a020,
AROOT=0xb786a020, this=0xb785a020) at ../objpas/classes/reader.inc:1260
1260 Result.FComponentState :=
(gdb) print result.fcomponentstate
$1 = []
(gdb) next
1264 i := 0;
(gdb) print result.fcomponentstate
$2 = []
(gdb)
Result.FComponentState :=
Result.FComponentState + [csLoading, csReading];
{ We need an unique name }
i := 0;
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 20.48:23 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. OK, So: Form1 = TForm1 Frame1 = TMyFrame [inline comes here somewhere] end end When Frame1 is streamed, where do I find TMyFrame ? It's Ancestor is not being streamed ? It is like streaming of an inherited form. Lookup the ancestor and write the property differences. On reading TMyFrame is found by TReader.FindComponentClass (normally by GetFieldClass) as with non inlined child components. TMyFrame.Create loads the TMyFrame instance with the initial form resource data. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 20.42:13 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: I'd like to second Colins wish. Please use the same resolving order as Delphi. MSEide+MSEgui compiles with Delphi7 so the reversed order is an unnecessary complication and error source. It's not a complication. Resolving order is and must be irrelevant. Until 'Loaded' is called, you're not supposed to make any assumptions about what property is and what property is not set, and hence also not about the order. I am not convinced. By controlling the order of the properties and the load order of the forms it is possible to control the resolving order. Does FPC loose on quality if you use the same order as Delphi? It is possible that we don't know all future applications of resolving order at the moment, why should we give away compatibility if not necessary? In my developments I try to constrict the possibilities as little as possible. Often the users of our code do things we never thought. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Monday 31 March 2008 15.00:02 Michael Van Canneyt wrote: It is like streaming of an inherited form. Lookup the ancestor and write the property differences. Nono, when streaming an inherited form, the IDE provides the ancestor instance when the streaming starts, because it calls writedescendent. When you have a frame inside a form IDE, the IDE cannot provide the ancestor of the frame: the streaming code must look for the original instance of the frame by itself. My guess is that this is done by setting the OnFindAncestor callback ? Correct. Sorry that I didn't get your question right. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Monday 31 March 2008 16.13:48 Michael Van Canneyt wrote: On Mon, 31 Mar 2008, Martin Schreiber wrote: I am not convinced. By controlling the order of the properties and the load order of the forms it is possible to control the resolving order. Does FPC loose on quality if you use the same order as Delphi? It is possible that we don't know all future applications of resolving order at the moment, why should we give away compatibility if not necessary? Simply said: if I must reverse order, then I have to redo the whole cleanroom stuff and it will be exactly as in Delphi. This is not an option. I probably don't understand. What is the problem to reverse the iterating order over a list? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: On Sat, 29 Mar 2008, Martin Schreiber wrote: On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). Seems fixed now. I hope I have done it correct (your test program runs fine) and didn't break anything else... :( Looks good, thanks. There is a problem with inline components: http://bugs.freepascal.org/view.php?id=11069 Please delete 11068, it was posted private by accident. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 17.56:40 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: Looks good, thanks. There is a problem with inline components: http://bugs.freepascal.org/view.php?id=11069 Please delete 11068, it was posted private by accident. OK, I knew how to handle visual form inheritance so I could fix 11067, but inline I have no idea what it is. Can you explain me what needs to be done, and in what situations it is used ? Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Alternatively, you can write the test case ;-) I'll do. The first is http://bugs.freepascal.org/view.php?id=11069 Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: Jesus just told me that it is fixed in r10587. Great, I set the bug to resolved. Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). 11060 seems to be fixed for MSEide too, thanks a lot. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bug in trunk?
Hi,
What is wrong with this code:
program rangeerror;
{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
{$ifdef mswindows}{$apptype console}{$endif}
uses
{$ifdef FPC}{$ifdef linux}cthreads,{$endif}{$endif}
sysutils;
type
colorty = type longword;
const
cl_mapped = colorty($9000);
type
ttestclass = class
private
fcolor: colorty;
published
property color: colorty read fcolor write fcolor default cl_mapped; //--
end;
begin
end.
Free Pascal Compiler version 2.3.1 [2008/03/27] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Linux for i386
Compiling rangeerror.pas
rangeerror.pas(16,70) Error: range check error while evaluating constants
rangeerror.pas(21) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Delphi7 and FPC fixes_2_2 compile fine.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Friday 28 March 2008 11.23:07 Jonas Maebe wrote: On 28 Mar 2008, at 07:47, Martin Schreiber wrote: What is wrong with this code: [...] It compiles again. Thanks! Unrelated (because I think such declarations are broken for fpu types/values): what code do you have to write so that this default value is actually used? fcolor is initialized to the default value in constructor. TWriter does not stream property values which are equal to the default value. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: While extensive testing has been done (using the FPCunit testing framework), and the working of Lazarus with this new code was verified, it is possible that bugs remain. We would therefor very much appreciate that if you have code that uses some of the routines below, that you test your code with the latest FPC from subversion (revision 10572 or above) and report any bugs that you may encounter. If you do, please submit a bugreport in mantis: http://bugs.freepascal.org/ http://bugs.freepascal.org/view.php?id=11059 Does this cause no problems for Lazarus? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Friday 28 March 2008 16.36:35 Jonas Maebe wrote: Floats not, integers yes, I think ? FPC cannot deal properly with floats either as far as I can see from the compiler source code. But since there is apparently no way to easily create a simple test program, I can't verify this. AFAIK there is a inherent default of 0.0, default property keyword can not be used with floats. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Friday 28 March 2008 16.42:52 Jonas Maebe wrote: On 28 Mar 2008, at 16:41, Martin Schreiber wrote: On Friday 28 March 2008 16.36:35 Jonas Maebe wrote: Floats not, integers yes, I think ? FPC cannot deal properly with floats either as far as I can see from the compiler source code. But since there is apparently no way to easily create a simple test program, I can't verify this. AFAIK there is a inherent default of 0.0, default property keyword can not be used with floats. In can be in FPC. Uuh, no rounding problems across platforms and by ObjectTextToBinary-ObjectBinaryToText? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Merge request
Hi, Please merge the fix for Mantis 10825 (Memory error in fpc_WideStr_Concat_multi) to fixes_2_2. Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Fix request
Hi, Please fix Mantis 10791 (ObjectBinaryToText broken for reals) and merge to fixes_2_2, it damages the form files. Suggestion: remove the wrong code. Index: classes.inc === --- classes.inc(revision 10339) +++ classes.inc(working copy) @@ -1313,10 +1313,12 @@ vaExtended: begin ext:=ReadExtended; Str(ext:1:20,S);// Do not use localized strings. -i:=length(S); -while S[i]='0' do //1234.5678 is nicer than 1.23456780E+0003 - dec(i); -SetLength(S,i); +// +// does not work 2008-02-08 mse +//i:=length(S); +//while S[i]='0' do //1234.5678 is nicer than 1.23456780E+0003 +// dec(i); +//SetLength(S,i); OutLn(S); end; vaString: begin Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fix request
On Friday 21 March 2008 14.54:24 Vincent Snijders wrote: Martin Schreiber schreef: Hi, Please fix Mantis 10791 (ObjectBinaryToText broken for reals) and merge to fixes_2_2, it damages the form files. Suggestion: remove the wrong code. Why not let Giulio fix it? I don't understand. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fix request
On Friday 21 March 2008 15.09:22 Vincent Snijders wrote: Martin Schreiber schreef: On Friday 21 March 2008 14.54:24 Vincent Snijders wrote: Martin Schreiber schreef: Hi, Please fix Mantis 10791 (ObjectBinaryToText broken for reals) and merge to fixes_2_2, it damages the form files. Suggestion: remove the wrong code. Why not let Giulio fix it? I don't understand. The bug got assigned to Giulio (whose patch probably introduced it) only yesterday and why don't you give him the time to properly fix it instead of reverting the patch? 10791 was submitted 2008-02-14 and assigned 2008-02-14 to Michael Van Canneyt. The wrong patch has cosmetic reasons only and can savely be reverted. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fix request
On Friday 21 March 2008 15.19:57 Martin Schreiber wrote: 10791 was submitted 2008-02-14 and assigned 2008-02-14 to Michael Van Canneyt. The wrong patch has cosmetic reasons only and can savely be reverted. Argh! Correction: 10791 was submitted 2008-02-08. Sorry, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] m68k crosscompiler
Hi,
I try to build a m68k crosscompiler with fixes_2_2:
[...]
/home/mse/packs/standard/svn/fp/fixes_2_2/compiler/ppc -Ur -Xs -O2 -n -Fum68k
-Fusystems -Fu/home/mse/packs/standard/svn/fp/fixes_2_2/rtl/units/i386-linux
-Fim68k -FE. -FUm68k/units/i386-linux -dRELEASE -dm68k -dGDB -dBROWSERLOG
-dNOOPT
pp.pas
n68kmat.pas(282,52) Error: Illegal qualifier
n68kmat.pas(343,47) Error: Illegal qualifier
n68kmat.pas(344,105) Error: Illegal qualifier
n68kmat.pas(362) Fatal: There were 3 errors compiling module, stopping
Fatal: Compilation aborted
make[3]: *** [ppcross68k] Error 1
make[3]: Leaving directory
`/home/mse/packs/standard/svn/fp/fixes_2_2/compiler'
make[2]: *** [cycle] Error 2
make[2]: Leaving directory
`/home/mse/packs/standard/svn/fp/fixes_2_2/compiler'
make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory `/home/mse/packs/standard/svn/fp/fixes_2_2'
make: *** [build-stamp.m68k-linux] Error 2
n68kmat.pas:282:
{$WARNING FIX ME!!! shlshrnode needs review}
procedure tm68kshlshrnode.pass_generate_code;
[...]
shiftval := tordconstnode(right).value.svalue; -
Any hints?
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] m68k crosscompiler
On Thursday 13 March 2008 13.48:55 Jonas Maebe wrote: On 13 Mar 2008, at 13:24, Martin Schreiber wrote: I try to build a m68k crosscompiler with fixes_2_2: m68k is not supported in 2.x at this time. The last version that supported m68k was 1.0.10a. Every now and then, some people work on m68k in the 2.3.x branch, but even there it is not usable. Thanks, I'll try how far I get with trunk. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] m68k crosscompiler
On Thursday 13 March 2008 14.16:41 Martin Schreiber wrote: On Thursday 13 March 2008 13.48:55 Jonas Maebe wrote: On 13 Mar 2008, at 13:24, Martin Schreiber wrote: I try to build a m68k crosscompiler with fixes_2_2: m68k is not supported in 2.x at this time. The last version that supported m68k was 1.0.10a. Every now and then, some people work on m68k in the 2.3.x branch, but even there it is not usable. Thanks, I'll try how far I get with trunk. With trunk I get: /home/mse/packs/standard/svn/fp/trunk/compiler/ppcross68k -Ur -Pm68k -Ur -Xs -O2 -n -Fi../inc -Fi../m68k -Fi../unix -Fim68k -FD/opt/cross/m68k/bin -FE. -FU/home/mse/packs/standard/svn/fp/trunk/rtl/units/m68k-linux -dm68k -dRELEASE -Us -Sg system.pp softfpu.pp(592,1) Fatal: Internal error 200309041 Fatal: Compilation aborted make[5]: *** [system.ppu] Error 1 make[5]: Leaving directory `/home/mse/packs/standard/svn/fp/trunk/rtl/linux' make[4]: *** [linux_all] Error 2 make[4]: Leaving directory `/home/mse/packs/standard/svn/fp/trunk/rtl' make[3]: *** [rtl] Error 2 make[3]: Leaving directory `/home/mse/packs/standard/svn/fp/trunk/compiler' make[2]: *** [cycle] Error 2 make[2]: Leaving directory `/home/mse/packs/standard/svn/fp/trunk/compiler' make[1]: *** [compiler_cycle] Error 2 make[1]: Leaving directory `/home/mse/packs/standard/svn/fp/trunk' make: *** [build-stamp.m68k-linux] Error 2 Seems to be nothing m68k specific? The command line: make all CPU_TARGET=m68k CROSSCOMPILE=1 FPC=ppc386 CROSSBINDIR=/opt/cross/m68k/bin Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] m68k crosscompiler
On Thursday 13 March 2008 15.14:14 Jonas Maebe wrote: Seems to be nothing m68k specific? It probably means that invalid register allocation information is generated by the m68k code generator. As said: m68k is simply not supported at this time. Even if it would compile you'd get a lot of invalid code because it hasn't been tested nor kept up to date for several years. It compiles with -O-. spill_registers does not terminate while compiling rtl/linux/system.pp. I have no chance to fix it my self because I know nothing about register allocation. :-( Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
On Friday 29 February 2008 10.07:29 Daniël Mantione wrote: Ideally from my point of view would be if the resourcestrings are stored in utf-8 if the unit is compiled with -Fcutf8 and decoded by utf8decode for widestring assignment on runtime independent of the system encoding. This has been discussed before. Automatic conversion to/from ansistrings will always be to/from system encoding. If you want another encoding than the system encoding you will have to do a manual conversion. For the compiler, a resourcestring has the same type as an ansistring, so no distinction can be made between resourcestrings/ansistrings. That means that the program must be compiled in the same system encoding as the target runs in order to get working resourcestrings? That would resourcestrings for i18n purposes render useless apart from utf-8-only or latin-1-only. utf-8-only is not possible for older existing installations. The compiler does not know that the source is a resource string? But the compiler could know it, the information is available? If the resourcestring kind of source is known, fpc_ResourceStr_To_WideStr could be called instead of fpc_AnsiStr_To_WideStr, the widestring manager needs an additional procedure Resource2WideMoveProc where the appropriate conversion takes place. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
On Sunday 02 March 2008 10.22:32 Daniël Mantione wrote: Regarding code generation, there is a difference between ansistrings and resourcestrings, since with a resourcestring load, the compiler must look into the resourcestring tables to find the ansistring constant. So it is theoretical possible to call fpc_ResourceStr_To_WideStr instead of fpc_AnsiStr_To_WideStr if the source is a resourcestring? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
