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 exampl
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
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
even
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
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 -O
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 de
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 th
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 va
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 I
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,
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 i
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 I
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 (f
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
Borl
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
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 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 spen
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 functio
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 imp
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 don
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 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 have
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
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 ve
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
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
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"
fpm
- "Graeme Geldenhuys" 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 required when
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 rega
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
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 watc
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
http://lists.freep
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
conside
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 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 genera
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
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
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 an
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
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
http://fpgui.sourceforge.ne
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 investin
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 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 mu
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
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 do
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 is
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 target
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 ca
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 th
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 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 e
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 wil
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 wind
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.
>
>
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
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 (i
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.
-- stri
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: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 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
http://lists.freepascal.org/
On 12/09/2011 10:55, Hans-Peter Diettrich wrote:
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
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 understand
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 100
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() w
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 IM
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 - fpc-devel@lists.freepascal
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
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 Toolki
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
In our previous episode, Ludo Brands said:
>
> <
> C:\Documents and Settings\Ludo\Mes documents\Lazarus
> Projects\test\leak0015324>leak.exe
>
> Heap dump by heaptrc unit
> 189 memory blocks allocated : 11362/12624
> 189 memory blocks freed : 11362/12624
> 0 unfreed memory blocks : 0
> Tr
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. Also
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 idea.
On Sun, Sep 11, 2011 at 1:51 PM, Skybuck Flying 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 so it is
to write for
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 Toolki
> 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\leak0015324>leak.exe
Heap dump by hea
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 may
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 f
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 comin
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
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
would
80 matches
Mail list logo
