On Sun, 2010-10-24 at 23:28 +0200, Graeme Geldenhuys wrote:
Hi,
Recently I mentioned a issue with debugging (using GDB) and indexing
in a AnsiString to retrieve a specific character from that string.
DWARF2
---
eg:
S := 'mystring';
GDB can display the value of S without
Op 2010-10-26 10:23, Joost van der Sluis het geskryf:
are problems with gdb also. The problem is that if a problem in fpc is
fixed properly, that will lead to problems in gdb. And the other way
around. Only way to fix those is to update both at the same time. This
is difficult because of the
On Tue, 26 Oct 2010 10:59:47 +0200, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
I'm just getting sick of the sad state that FPC debugging (with our only
choice GDB) is in. It's near unusable and currently only good for
stepping
through code. So I'll take the cue and see if I can do
На 26.10.2010 11:59, Graeme Geldenhuys напісаў(ла):
I'm just getting sick of the sad state that FPC debugging (with our only
choice GDB) is in. It's near unusable and currently only good for stepping
through code. So I'll take the cue and see if I can do something about it.
Regards,
-
On Tue, Oct 26, 2010 at 12:08 PM, Anton Kavalenka anto...@tut.by wrote:
I know at least two developers who stand - the only thing preventing them of
using FPC is GDB.
Windows-only developers?
Or else I don't know another compiler which will offer better
debugging in the rest of the platforms.
26.10.2010 18:33, Felipe Monteiro de Carvalho wrote:
Or else I don't know another compiler which will offer better
debugging in the rest of the platforms.
If Java can also be considered as a platform I must say that debugging
in eclipse is better.
Best regards,
Paul Ishenin.
?? 26.10.2010 13:33, Felipe Monteiro de Carvalho ???(??):
On Tue, Oct 26, 2010 at 12:08 PM, Anton Kavalenkaanto...@tut.by wrote:
I know at least two developers who stand - the only thing preventing them of
using FPC is GDB.
Windows-only developers?
Or else I don't know another
?? 26.10.2010 14:10, Paul Ishenin ???(??):
26.10.2010 18:33, Felipe Monteiro de Carvalho wrote:
Or else I don't know another compiler which will offer better
debugging in the rest of the platforms.
If Java can also be considered as a platform I must say that debugging
in eclipse is better.
Op 2010-10-26 13:22, Anton Kavalenka het geskryf:
Their last argument - we need assembly-line stepping debugger like in
Delphi.
This is actually supported in MSEide, I did it the other day (View
Assembler and use 'Next instruction' in stead of 'Next' in the debugger
toolbar). Even breakpoints
Graeme Geldenhuys wrote:
I'm just getting sick of the sad state that FPC debugging (with our only
choice GDB) is in. It's near unusable and currently only good for stepping
through code. So I'll take the cue and see if I can do something about it.
I expect the LLVM debugger
Hi all,
Someone reported bug in gtk2lcl which crashes lazarus ide. I've found that
intersectRect usage from types (from r 27870) makes that.
So imagine next code:
var
R, SrcRect: TRect;
begin
R := Rect(0, 0, 22, 22);
SrcRect := Rect(0, 0, 24, 24);
Types.IntersectRect(R, SrcRect, R);
On Tuesday, 26. October 2010 13.22:27 Anton Kavalenka wrote:
Yes, windows only.
But they fully understand bonuses from FPC and Lazarus but really hate GDB.
Their last argument - we need assembly-line stepping debugger like in
Delphi.
???
Works with gdb, see MSEide example:
On Tuesday, 26. October 2010 13.47:22 Graeme Geldenhuys wrote:
Op 2010-10-26 13:22, Anton Kavalenka het geskryf:
Their last argument - we need assembly-line stepping debugger like in
Delphi.
This is actually supported in MSEide, I did it the other day (View
Assembler and use 'Next
I'm just getting sick of the sad state that FPC debugging (with our
only
choice GDB) is in. It's near unusable and currently only good for
stepping
through code. So I'll take the cue and see if I can do something about
it.
+1
although it must be said that is mainly for lazarus. The
On Tuesday 26 October 2010 14:02, Felipe Monteiro de Carvalho wrote:
IMHO it is
2.FPC Types.IntersectRect() have bug
And it's very ugly :)
I've grepped complete lazarus tree for such misusage of IntersectRect, but
found only same problematic code in gtk dir and fixed that.
zeljko
I was testing the release candidate and found this bug dealing with
bitpacked records when using i386:
http://bugs.freepascal.org/view.php?id=17715
I don't know if it's a regression, I haven't been able to get an
environment set up to test it with an older version of the compiler.
-SG
--
This
Hello,
About this bug tracker item:
http://bugs.freepascal.org/view.php?id=9734
It seams impossible to install the Free Pascal RPM and use the
PCLinuxOS package manager (apt-get + Synaptic). FPC can only be
installed with --nodeps because it depends on a libtinfo file which
doesn't exist in
In our previous episode, Felipe Monteiro de Carvalho said:
It seams impossible to install the Free Pascal RPM and use the
PCLinuxOS package manager (apt-get + Synaptic). FPC can only be
installed with --nodeps because it depends on a libtinfo file which
doesn't exist in this distro and
Is there a no-brainer guide for building the rpms?
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
In our previous episode, Felipe Monteiro de Carvalho said:
Is there a no-brainer guide for building the rpms?
Yes, release engineering in wiki iirc has some.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 25.10.2010 19:12, schrieb luciano de souza:
7. IUP - It fulfills all the requirements. Previous experiences using
Lua and IUP, graphical tool kit developed by brazilian reseachers,
shows excelent results. Graphical interfaces can be created by blind
programmers, without any coordenate, using
Op 2010-10-26 14:13, Martin Schreiber het geskryf:
It is OK for 32 bit stabs but 64 bit FPC debugger support (dwarf AFAIK) is
probably not finished. I do not recommend to use 64 bit for FPC development
at the moment if 32 bit can be used instead.
Well I don't think it's that bad compared to
Op 2010-10-26 14:10, Dimitri Smits het geskryf:
although it must be said that is mainly for lazarus. The fpc-ide
debugger for instance is the only way to get assembler-viewing+stepping
to work. (to some extend)
Try MSEide instead, it works very well there.
Regards,
- Graeme -
--
fpGUI
On Tuesday 26 October 2010 14:02, Felipe Monteiro de Carvalho wrote:
IMHO it is
2.FPC Types.IntersectRect() have bug
No, I've opened an issue and Jonas closed with good explanation - we had
misusage of IntersectRect in gtk/gtk2 interfaces (I've fixed both) ... so not
bug.
zeljko
On Tue, Oct 26, 2010 at 3:14 PM, zeljko zel...@holobit.net wrote:
No, I've opened an issue and Jonas closed with good explanation - we had
misusage of IntersectRect in gtk/gtk2 interfaces (I've fixed both) ... so not
bug.
I guess it depends on how you see it.
Anyway, the solution would be
On Tuesday, 26. October 2010 15.07:31 Graeme Geldenhuys wrote:
The CPU
window doesn't work at all though, where it did under 32-bit Linux.
http://opensoft.homeip.net/~graemeg/mseide_debug_windows.png
Plase check if 'Project'-'Options'-'Debugger'-'Target'-'Processor' is set
to 'i386'
Hello,
Just in case they are already there somewhere. I did a text search and
it seams that we have no headers for X11 Extensions. For example
XShape*
So I will add XShape* to a new unit.
Please anyone correct me if they are already somewhere.
thanks,
--
Felipe Monteiro de Carvalho
On Tuesday 26 October 2010 15:13, Felipe Monteiro de Carvalho wrote:
On Tue, Oct 26, 2010 at 3:14 PM, zeljko zel...@holobit.net wrote:
No, I've opened an issue and Jonas closed with good explanation - we had
misusage of IntersectRect in gtk/gtk2 interfaces (I've fixed both) ... so
not bug.
Op 2010-10-26 15:18, Martin Schreiber het geskryf:
Plase check if 'Project'-'Options'-'Debugger'-'Target'-'Processor' is set
to 'i386' instead of 'auto' or 'x86_64'.
Ah, that did the trick, thanks Martin. :)
The problem is then in the MSEide template projects (issue is probably in
svn
zeljko пишет:
On Tuesday 26 October 2010 15:13, Felipe Monteiro de Carvalho wrote:
On Tue, Oct 26, 2010 at 3:14 PM, zeljko zel...@holobit.net wrote:
No, I've opened an issue and Jonas closed with good explanation - we had
misusage of IntersectRect in gtk/gtk2 interfaces (I've fixed both) ...
IUP 2.x are not compatible with screen readers. The reason is the
excessive usage of Canvas Draw. I did a large number of tests with IUP
and Lua and I can assure IUP 3.1 and 3.2, the last version, are very
good so in Linux as in Windows. For this reason, I would like to
translate IUP 3.2.
Yes, we
On 26 Oct 2010, at 16:12, Sergei Gorelkin wrote:
zeljko пишет:
On Tuesday 26 October 2010 15:13, Felipe Monteiro de Carvalho wrote:
On Tue, Oct 26, 2010 at 3:14 PM, zeljko zel...@holobit.net wrote:
No, I've opened an issue and Jonas closed with good explanation -
we had
misusage of
Am 26.10.2010 16:18, schrieb luciano de souza:
IUP 2.x are not compatible with screen readers. The reason is the
excessive usage of Canvas Draw. I did a large number of tests with IUP
and Lua and I can assure IUP 3.1 and 3.2, the last version, are very
good so in Linux as in Windows. For this
2010/10/26, Sven Barth pascaldra...@googlemail.com:
Am 26.10.2010 16:18, schrieb luciano de souza:
IUP 2.x are not compatible with screen readers. The reason is the
excessive usage of Canvas Draw. I did a large number of tests with IUP
and Lua and I can assure IUP 3.1 and 3.2, the last
Jonas Maebe пишет:
With a little testing, here are two facts:
1) Delphi 7 also shows this bug.
2) Windows.IntersectRect() does not show it, allowing 'misuses'.
So, whoever wrote the FPC function, must have been trying really hard
to achieve bug-to-bug compatibility with Delphi... or simply
I understand. After running H2pas, I had erros in all rows with array
of const. The arguments are not constants indeed. They are ihandle or
pihandle as the first one is. So but when I use varargs probabibly all
the arguments have the same type: pihandle. I believe the second
alternative will
On Tuesday 26 October 2010 16:57, Sergei Gorelkin wrote:
Well, maybe. For me, it is rather hard to think about the opposite - that a
const may be passed *not* by reference - due to long-term Delphi/Windows
experience.
But, after all, Types.IntersectRect and surrounding stuff were introduced
On Tue, 26 Oct 2010, Sergei Gorelkin wrote:
Jonas Maebe пишет:
With a little testing, here are two facts:
1) Delphi 7 also shows this bug.
2) Windows.IntersectRect() does not show it, allowing 'misuses'.
So, whoever wrote the FPC function, must have been trying really hard to
achieve
Am 26.10.2010 17:00, schrieb luciano de souza:
I understand. After running H2pas, I had erros in all rows with array
of const. The arguments are not constants indeed. They are ihandle or
pihandle as the first one is. So but when I use varargs probabibly all
the arguments have the same type:
On Tuesday, 26. October 2010 16.14:50 Graeme Geldenhuys wrote:
The problem is then in the MSEide template projects (issue is probably in
svn repository too, because the default ones are not changed locally). I
went Project New From Template console.prj. By default it is set it
i386 instead
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko zel...@holobit.net wrote:
On Tuesday 26 October 2010 16:57, Sergei Gorelkin wrote:
Well, maybe. For me, it is rather hard to think about the opposite - that a
const may be passed *not* by reference - due to long-term Delphi/Windows
experience.
Mattias Gaertner escreveu:
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko zel...@holobit.net wrote:
One note: IntersectRect in lazarus worked OK until we decided to use
Types.IntersectRect, old implementation from GraphType looks much better than
current fpc one.
Then it is probably
Quoting Mattias Gaertner nc-gaert...@netcologne.de:
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko zel...@holobit.net wrote:
On Tuesday 26 October 2010 16:57, Sergei Gorelkin wrote:
Well, maybe. For me, it is rather hard to think about the
opposite - that a
const may be passed *not* by
Quoting Luiz Americo Pereira Camara luiz...@oi.com.br:
Mattias Gaertner escreveu:
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko zel...@holobit.net wrote:
One note: IntersectRect in lazarus worked OK until we decided to
use Types.IntersectRect, old implementation from GraphType looks
much
On Tue, Oct 26, 2010 at 8:05 PM, zel...@holobit.net wrote:
No, why ? I've fixed problems inside widgetsets.Let's propose patch for
improving Types.IntersectRect().
I already fixed this in FPC 2.5.1+ Please verify.
--
Felipe Monteiro de Carvalho
___
On 24 Oct 2010, at 23:56, Willibald Krenn wrote:
Am 24.10.2010 20:49, schrieb Jonas Maebe:
It should probably check whether the packedbitsize is in [8, 16, 32,
64]. The reason is that if you have a load from a byte-aligned
address using a size that is natively supported by the code
zel...@holobit.net escreveu:
Quoting Luiz Americo Pereira Camara luiz...@oi.com.br:
Mattias Gaertner escreveu:
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko zel...@holobit.net wrote:
One note: IntersectRect in lazarus worked OK until we decided to
use Types.IntersectRect, old implementation
Am 26.10.2010 21:33, schrieb Jonas Maebe:
Thanks for confirming my thoughts. Shall I still file a bugreport for this?
It's fixed.
Thanks, I just wanted to file a report for this and the assembly thing
but it seems that reporting new issues on mantis does not work
currently. (I am getting
Willibald Krenn wrote:
Am 26.10.2010 21:33, schrieb Jonas Maebe:
Thanks for confirming my thoughts. Shall I still file a bugreport for
this?
It's fixed.
Thanks, I just wanted to file a report for this and the assembly thing
but it seems that reporting new issues on mantis does not work
was Re: [fpc-devel] AnsiString in DWARF2 vs DWARF3
- Anton Kavalenka anto...@tut.by schreef:
На 26.10.2010 13:33, Felipe Monteiro de Carvalho напісаў(ла):
On Tue, Oct 26, 2010 at 12:08 PM, Anton Kavalenka anto...@tut.by wrote:
I know at least two developers who stand - the only thing
Hi,
I was wondering why on several occasions in discussions regarding compiler
design and parser branches it was mentioned (especially by Florian) that FPC is
in need of a faster FillChar.
The reason for this bewonderment is that I see code regarding the fastmove that
is by John O'Harrow of
Interlocked features for Int64 are bound to {$ifdef cpu64}
While Int64 data type is supported under i386 FPC the interlocked
features aren't included in FPC RTL.
Can I writeup a bug for this or is this due to another problem?
Thanks.
___
fpc-devel
52 matches
Mail list logo
