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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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\*
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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.
-
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
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
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
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
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 -
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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 =
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
301 - 400 of 513 matches
Mail list logo
