On 11/09/2011 23:40, Jonas Maebe wrote:
extensions. I don't see the advantage of allocating one of those and
communicating it to other compiler writers (to avoid them using that
same extension for something else) instead of submitting it for
inclusion in the official DWARF standard though.
I
Hi,
Speaking of the subject in another thread, and to show the desire I have
to finding a solution to this [what I consider a very serious] problem
FPC needs its own debugger! GDB is just rubbish when it comes to the
Object Pascal language. Also if FPC had it's own debugger, the time it
On 12 Sep 2011, at 08:56, Graeme Geldenhuys wrote:
On 11/09/2011 23:40, Jonas Maebe wrote:
extensions. I don't see the advantage of allocating one of those and
communicating it to other compiler writers (to avoid them using that
same extension for something else) instead of submitting it for
P5 is also in an unusuable state.
It should not be allowed to write code as follows:
repeat
if a b then
begin
end
until a b;
^ This code should produce an error becomes end is not ended with a semicolon
– ;
This confuses Delphi’s source beautifier, which could be seen as a short coming
On Sun, 11 Sep 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
I'm a user of fpdoc, not a maintainer, have no idea of the internals.
In that case, please do not say things like
'this extension should not be too hard to implement'
But please, file a bug report so we won't
On 12/09/2011 09:13, Jonas Maebe wrote:
You don't have to wait until it is published. Both gcc and gdb
supported provisional DWARF4 features before the standard was out.
And then standing the chance of it being reject - thus doing the
implementation in GCC and GDB all for nothing. But maybe
Hello,
Could sb with a recent trunk based system and mysql please
try to duplicate Mantis #15324?
Thanks in advance.
]
Marco
On XP SP2 with fpc 2.7.1 rev 18901:
C:\Documents and Settings\Ludo\Mes documents\Lazarus
Projects\test\leak0015324leak.exe
Heap dump by heaptrc unit
189
On 11/09/2011 13:51, Skybuck Flying wrote:
The P5 code is not properly indented.
Now you are on the border line of ridiculous! Simply run the code
through JCF (Jedi Code Formatter), and the code will look exactly as you
specified in all of 2 seconds!
Regards,
- Graeme -
--
fpGUI Toolkit
On Sun, Sep 11, 2011 at 1:51 PM, Skybuck Flying skybuck2...@hotmail.com wrote:
^ This code should produce an error becomes end is not ended with a
semicolon – ;
Looks like you are not aware that Pascal uses semicolon as separators,
not statement enders. AFAIK the code you posted is valid, and
On 12 Sep 2011, at 09:22, Graeme Geldenhuys wrote:
So maybe one should start a wiki page regarding this, putting down
some
ideas that others can review and contribute towards? Building up
towards a specification we can later submit to the DWARF guys.
That certainly sounds like a good
On 2011-09-12 09:08, Graeme Geldenhuys wrote:
Hi,
Speaking of the subject in another thread, and to show the desire I have
to finding a solution to this [what I consider a very serious] problem
FPC needs its own debugger! GDB is just rubbish when it comes to the
Object Pascal language.
In our previous episode, Ludo Brands said:
C:\Documents and Settings\Ludo\Mes documents\Lazarus
Projects\test\leak0015324leak.exe
Heap dump by heaptrc unit
189 memory blocks allocated : 11362/12624
189 memory blocks freed : 11362/12624
0 unfreed memory blocks : 0
True heap size :
On 09/11/2011 07:33 PM, Hans-Peter Diettrich wrote:
No Latex support here (Win7)
Virtual Box is your friend :-) .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 12/09/2011 10:21, Michael Schnell wrote:
On 09/11/2011 07:33 PM, Hans-Peter Diettrich wrote:
No Latex support here (Win7)
Virtual Box is your friend :-) .
Even easier, you get LaTeX for Windows too... I think it is called
something like MiKTex.
Regards,
- Graeme -
--
fpGUI Toolkit -
In our previous episode, Graeme Geldenhuys said:
No Latex support here (Win7)
Virtual Box is your friend :-) .
Even easier, you get LaTeX for Windows too... I think it is called
something like MiKTex.
Even better, TeXLive has easy installers nowaday, and that is the TeX distro
mostly used
Skybuck Flying schrieb:
end
until a b;
^ This code should produce an error becomes end is not ended with a
semicolon – ;
Please understand Pascal first, before you try to modify it.
DoDi
___
fpc-devel maillist -
Martin schrieb:
More than that, Lazarus is not the only way to use the info, people use
other IDEs or gdb directly = all that needs to be considered.
You can't have one tool for everybody and everything. A debugger can not
(and must not) know about all languages. Language specific support
Graeme Geldenhuys schrieb:
Just the other day I had to use Delphi 7 again to do some maintenance on
one of our older products. That's when I again came to the realization
what dismal state FPC's debugging support is at - it's like travelling
back in time to the early 80's where using writeln()
Graeme Geldenhuys schrieb:
If anybody with the know how is interested in implementing a Object
Pascal based debugger (or extending Duby specifically for use with FPC),
please let me know. I am more than willing to pay a few hundred US
dollars (or Euros) towards this bounty.
I'd add another
On 12/09/2011 08:47, Torsten Bonde Christiansen wrote:
I really miss the easy use of the Delphi debugger from D7. Especially the
live inspection of object during single step of the code.
In that case you (all involved) better specify the required features.
The debugger itself (in my
On 09/12/2011 12:18 PM, Hans-Peter Diettrich wrote:
I'd add another 100€ for reasonable debugging support in Lazarus :-)
Could you generate a wish-List ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 12/09/2011 11:06, Hans-Peter Diettrich wrote:
IMO debugging support was one of the reasons, why Kylix was based on
Wine, and the cross-platform versions of Delphi use remote debugging
only. For that implementation a tiny (remote) debugger interface is
sufficient, and the IDE can implement
On 12/09/2011 11:43, Martin wrote:
The debugger itself (in my understanding) can either have a library-like
interface or command-line driven or both.
Duby already has both (in rudimentary form). At this point I will be
fine with a command-line debugger only, that can actually debug my code.
On 12/09/2011 11:10, Graeme Geldenhuys wrote:
Here is what I would consider a debugger:
- command line interface at least
- watches
since lazarus displays watches, using gdb, maybe this should be more
specific?
- Yes, certain expressions are not supported, or not well supported.
--
Martin wrote:
On 12/09/2011 08:47, Torsten Bonde Christiansen wrote:
I really miss the easy use of the Delphi debugger from D7. Especially the
live inspection of object during single step of the code.
In that case you (all involved) better specify the required features.
The debugger itself
12.09.2011 11:08, Graeme Geldenhuys:
[...]
If anybody with the know how is interested in implementing a Object
Pascal based debugger (or extending Duby specifically for use with FPC),
please let me know. I am more than willing to pay a few hundred US
dollars (or Euros) towards this bounty.
I'd
On Monday 12 September 2011 12:23:44 Martin wrote:
- watchpoints. break when data at memory address changed. Very
handy to debug those procedural programs that loves to use global
variables. MSEide supports this (but it is actually a GDB feature)
Yes indeed.
Btw, i
On 12/09/2011 11:51, Martin Schreiber wrote:
The big issue, is that gdb often scopes them wrong, and you loose the
watch point before you it triggers
MSEide has popup menu functions 'Address Watchpoint 8', 'Address Watchpoint
16', 'Address Watchpoint 32' and 'Address Watchpoint 64' in watch
On Monday 12 September 2011 12:45:40 Nikolai Zhubr wrote:
12.09.2011 11:08, Graeme Geldenhuys:
[...]
If anybody with the know how is interested in implementing a Object
Pascal based debugger (or extending Duby specifically for use with FPC),
please let me know. I am more than willing to
On 12/09/11 12:00, Martin Schreiber wrote:
And a FPC only debugger can not debug linked c libraries which we can do
Good point. I've found this very handy in the past.
currently with gdb. And think of the remote debugging options gdb provides
with many targets.
Another one very handy for
On 09/12/2011 12:10 PM, Graeme Geldenhuys wrote:
- watchpoints. break when data at memory address changed. Very
handy to debug those procedural programs that loves to use global
variables. MSEide supports this (but it is actually a GDB feature)
Ooops. (Without hardware support) This
On Monday 12 September 2011 13:08:31 Michael Schnell wrote:
On 09/12/2011 12:10 PM, Graeme Geldenhuys wrote:
- watchpoints. break when data at memory address changed. Very
handy to debug those procedural programs that loves to use global
variables. MSEide supports this (but
On 12/09/2011 13:00, Martin Schreiber wrote:
True. And maintaining all platforms is a fulltime job too.
Maintenance should be MUCH less work than the initial implementation. So
I don't consider this too a big problem. FPC doesn't change that
radically that often.
And a FPC only debugger can
12.09.2011 15:01, Henry Vermaak:
On 12/09/11 12:00, Martin Schreiber wrote:
And a FPC only debugger can not debug linked c libraries which we can do
Good point. I've found this very handy in the past.
currently with gdb. And think of the remote debugging options gdb
provides
with many
12.09.2011 19:00, Martin Schreiber wrote:
True. And maintaining all platforms is a fulltime job too. And a FPC
only debugger can not debug linked c libraries which we can do
currently with gdb. And think of the remote debugging options gdb
provides with many targets.
As I understand the plan
On Monday 12 September 2011 13:12:11 Graeme Geldenhuys wrote:
On 12/09/2011 13:00, Martin Schreiber wrote:
True. And maintaining all platforms is a fulltime job too.
Maintenance should be MUCH less work than the initial implementation. So
I don't consider this too a big problem. FPC doesn't
On 12/09/2011 12:45, Nikolai Zhubr wrote:
I'd also happily contribute $300 or so (in case there is a reasonable
chance to actually get it working at least on windows/linux/bsd)
However, the effort needed is probably much much more expensive
Well, considering the about of people that are
On Monday 12 September 2011 13:16:58 Graeme Geldenhuys wrote:
On 12/09/2011 12:45, Nikolai Zhubr wrote:
I'd also happily contribute $300 or so (in case there is a reasonable
chance to actually get it working at least on windows/linux/bsd)
However, the effort needed is probably much much
On Monday 12 September 2011 13:16:21 Paul Ishenin wrote:
12.09.2011 19:00, Martin Schreiber wrote:
True. And maintaining all platforms is a fulltime job too. And a FPC
only debugger can not debug linked c libraries which we can do
currently with gdb. And think of the remote debugging
On 12/09/2011 13:32, Martin Schreiber wrote:
I think it is better to invest time into gdb support instead into a FPC
debugger which probably never will reach a usable state.
[sarcasm on]
With that attitude the same could be applied to MSEide, MSEgui and fpGUI
too. Why did we bother investing
On 12/09/2011 13:30, Martin Schreiber wrote:
???
EUR 100'000..200'000? Really?
Yes, we all know your rates a much higher than others - so we will not
ask you to do the work.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
On Monday 12 September 2011 13:36:43 Graeme Geldenhuys wrote:
On 12/09/2011 13:32, Martin Schreiber wrote:
I think it is better to invest time into gdb support instead into a FPC
debugger which probably never will reach a usable state.
[sarcasm on]
With that attitude the same could be
12.09.2011 19:36, Graeme Geldenhuys wrote:
On 12/09/2011 13:32, Martin Schreiber wrote:
I think it is better to invest time into gdb support instead into a FPC
debugger which probably never will reach a usable state.
[sarcasm on]
With that attitude the same could be applied to MSEide, MSEgui
Anyone care to comment on those ideas?
Are they worth to be made a feature request?
And if so, which of the proposed ideas should be made into a feature
request?
On 11/09/2011 23:15, Martin wrote:
Like it was done for properties that directly map to a field. The now
are somehow encoded, so
On 12/09/2011 13:49, Martin Schreiber wrote:
True. And because we know what it means to develop something new from scratch
and because I know that I don't want to invest several years into development
of a FPC debugger and because we know that there are not so many people who
Please have a
On 12 Sep 2011, at 12:23, Martin wrote:
The big issue, is that gdb often scopes them wrong, and you loose
the watch point before you it triggers
If you use an expression in a watch point, gdb will reevaluate that
expression if a value used in the watch expression changes.
Since in
On 12/09/2011 13:07, Graeme Geldenhuys wrote:
On 12/09/2011 13:49, Martin Schreiber wrote:
True. And because we know what it means to develop something new from scratch
and because I know that I don't want to invest several years into development
of a FPC debugger and because we know that there
On 12/09/2011 14:07, Paul Ishenin wrote:
I also want to know. Imo, you are loosing your time :)
[off-topic: so this will be my last public response to this]
No, fpGUI has now reached a point where I can knock out apps in a
fraction of the time it took me 5 years ago. Also those apps are
On 09/12/2011 01:15 PM, Martin Schreiber wrote:
gdb uses hardware watchpoint support if available.
That seems hard to beat when doing a new multi-arch debugger
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 12/09/2011 13:11, Jonas Maebe wrote:
On 12 Sep 2011, at 12:23, Martin wrote:
The big issue, is that gdb often scopes them wrong, and you loose the
watch point before you it triggers
If you use an expression in a watch point, gdb will reevaluate that
expression if a value used in the
On Monday 12 September 2011 14:20:06 Michael Schnell wrote:
On 09/12/2011 01:15 PM, Martin Schreiber wrote:
gdb uses hardware watchpoint support if available.
That seems hard to beat when doing a new multi-arch debugger
Correct. :-)
Martin
12.09.2011 15:08, Graeme Geldenhuys wrote:
So consider this an official bounty. If others want to add to this
bounty, you are more than welcome.
I suggest to create a wiki page with:
1) at least brief specification
2) a list of sponsors
3) a list of jury members
4) acceptance criteria
Best
- Graeme Geldenhuys graemeg.li...@gmail.com schreef:
On 12/09/2011 13:30, Martin Schreiber wrote:
???
EUR 100'000..200'000? Really?
Yes, we all know your rates a much higher than others - so we will
not
ask you to do the work.
Graeme,
I think you underestimate the work
I'm trying to compile from svn trunk on Win32, but I get this when I do make
clean all:
Free Pascal Compiler version 2.4.4 [2011/04/23] for i386
Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Win32 for i386
Compiling fpmake.pp
fpmake.pp(20,51) Error: Identifier not found iPhoneSim
On 12 Sep 2011, at 15:48, Leonardo M. Ramé wrote:
I'm trying to compile from svn trunk on Win32, but I get this when I
do make clean all:
Try manually deleting all units directories under fpc/packages/*. In
general, you should always perform a make distclean *before*
updating from svn
On 12/09/2011 14:57, Dimitri Smits wrote:
I don't disagree with the need for a prime debugger, nor with the
amounts of bounty everyone is offering, just with the statements
above.
I still stand with my statement that it will NOT cost 100,000 - 200,000
euros to get a basic working debugger!
Hi,
I compiled MSEide with FPC 2.4.4, FPC fixes_2_6 and Delphi 7 for comparison.
Delphi 7:
Borland Delphi Version 15.0
Copyright (c) 1983,2002 Borland Software Corporation
[...]
308390 lines, 6.20 seconds, 2279788 bytes code, 827729 bytes data.
Exe size: 3.23MB
FPC 2.4.4:
Free Pascal Compiler
On 12 Sep 2011, at 14:07, Martin wrote:
Anyone care to comment on those ideas?
Are they worth to be made a feature request?
And if so, which of the proposed ideas should be made into a feature request?
I really don't like hacks like that. They will have to be maintained almost
forever
On 12/09/2011 18:32, Jonas Maebe wrote:
On 12 Sep 2011, at 14:07, Martin wrote:
Anyone care to comment on those ideas?
Are they worth to be made a feature request?
And if so, which of the proposed ideas should be made into a feature request?
I really don't like hacks like that. They will
On 12/09/2011 19:08, Martin wrote:
On 12/09/2011 18:32, Jonas Maebe wrote:
On 12 Sep 2011, at 14:07, Martin wrote:
Anyone care to comment on those ideas?
Are they worth to be made a feature request?
And if so, which of the proposed ideas should be made into a feature
request?
I really don't
On 12/09/2011 19:14, Martin wrote:
On 12/09/2011 19:08, Martin wrote:
On 12/09/2011 18:32, Jonas Maebe wrote:
While not a complete solution either, couldn't you use the
information from the Lazarus codetools to figure out which
properties exist? If that's currently not possible because you
On 12 Sep 2011, at 20:20, Martin wrote:
On 12/09/2011 19:14, Martin wrote:
Currently properties that map to a field are already present in dwarf (again
why not in stabs?).
Because Stabs is legacy and I don't want to spend time on it.
Could not properties mapping to a function be
On 12/09/2011 19:31, Jonas Maebe wrote:
On 12 Sep 2011, at 20:20, Martin wrote:
Could not properties mapping to a function be implemented the same way = normal
functions are already listed in ptype so
public
property Counter: Integer read GetCounter
could appear the same as the function
On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote:
On 12 Sep 2011, at 20:20, Martin wrote:
On 12/09/2011 19:14, Martin wrote:
Currently properties that map to a field are already present in dwarf
(again why not in stabs?).
Because Stabs is legacy and I don't want to spend time on
Hi all,
Does someone knows a trick how to make gdb call a method (function) from
a class?
When I have this class defined, compiled with dwarf2: (-gw3 gives an IE,
I'll have a look at that too)
type
TMyClass = class
public
function Read: integer;
end;
ptype returns:
(gdb) ptype aclass
On 12/09/2011 20:46, Joost van der Sluis wrote:
On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote:
On 12 Sep 2011, at 20:20, Martin wrote:
Could not properties mapping to a function be implemented the same way = normal
functions are already listed in ptype so
public
property Counter:
On 12 Sep 2011, at 22:05, Joost van der Sluis wrote:
Does someone knows a trick how to make gdb call a method (function) from
a class?
It requires a patch to gdb. I'm fairly sure I already sent it to you in the
past. It was part of an, incomplete, patch set to also add support for the
Martin schrieb:
You can't have one tool for everybody and everything. A debugger can
not (and must not) know about all languages. Language specific support
IMO should reside in another layer (IDE, plugin...) between the
debugger and the user.
Never said that. My statement was about pascal
Martin schrieb:
On 12/09/2011 11:06, Hans-Peter Diettrich wrote:
IMO debugging support was one of the reasons, why Kylix was based on
Wine, and the cross-platform versions of Delphi use remote debugging
only. For that implementation a tiny (remote) debugger interface is
sufficient, and the
Michael Schnell schrieb:
On 09/12/2011 12:18 PM, Hans-Peter Diettrich wrote:
I'd add another 100€ for reasonable debugging support in Lazarus :-)
Could you generate a wish-List ?
For now: see my notes on Graeme's wish list.
I haven't been debugging for a while, because it mostly ended up
Graeme Geldenhuys schrieb:
Here is what I would consider a debugger:
- command line interface at least
Me: GUI interface at least.
Where GUI is not a special property of the interface, only a set of
(callback) procedures that allow to implement desired language-specific
display features,
Paul Ishenin schrieb:
12.09.2011 19:00, Martin Schreiber wrote:
True. And maintaining all platforms is a fulltime job too. And a FPC
only debugger can not debug linked c libraries which we can do
currently with gdb. And think of the remote debugging options gdb
provides with many targets.
As
cced to lazarus list. please switch list.
On 12/09/2011 21:28, Hans-Peter Diettrich wrote:
Martin schrieb:
Mind, I do NOT want to play down say that the lack of property support.
I didn't notice until now that my problems may be related to
properties. AFAIR I also couldn't inspect global
cced lazarus
On 12/09/2011 22:51, Hans-Peter Diettrich wrote:
Paul Ishenin schrieb:
12.09.2011 19:00, Martin Schreiber wrote:
True. And maintaining all platforms is a fulltime job too. And a FPC
only debugger can not debug linked c libraries which we can do
currently with gdb. And think of
On 12/09/2011 22:16, Hans-Peter Diettrich wrote:
Another wish: separation of debug info and debug code.
Currently I can't step into packages or FCL/RTL, without compiling
these first for debugging. But doing so puts in all the debug code
(output...), residing in the units. What I want is a
On 13 Sep 2011, at 00:31, Martin wrote:
Maybe this will help?
make.exe all OPT=-gl -gw -godwarfsets -O1
You should use -O-1 instead of -O1. The default for make all is -O2, and
-O2 -O1 is the same as -O2 (it says enable -O2 optimizations and also -O1
optimizations, but -O2 already
On 12/09/2011 23:18, Martin wrote:
However, I still recommend trunk = a lot of fixes have been applied.
And if you are on windows, I recommend gdb 7.3
32bit:
http://svn.freepascal.org/svn/lazarus/binaries/i386-win32/gdb/bin
libraries go into the same folder as gdb.
64 bit = not yet updated.
I don't understand why a property with a getter could ever be ran by a
debugger. If I have a property called NextValue, implanted by a method
called GetNextValue, that increments a field, stores it in a database, and
returns the new value, I absolutely do not want the debugger to execute that
DaWorm schrieb:
I don't understand why a property with a getter could ever be ran by a
debugger. If I have a property called NextValue, implanted by a method
called GetNextValue, that increments a field, stores it in a database,
and returns the new value, I absolutely do not want the debugger
Hi,
Is it possible to set a object/class procedure/function to external?
I want to do something like this:
TGObject = object
function new: PGObject; cdecl; external 'libglib.so' name 'g_object_new';
There are other cases where this maps better (i'm ignoring the 'self'
parameter in this
80 matches
Mail list logo
