On Wed, 14 Sep 2011, Felipe Monteiro de Carvalho wrote:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
wrote:
One with unicode string, one with ansistring. They will have the same code,
but will be compiled twice, each time with a different compiler define to
decide which version it mu
On Wed, Sep 14, 2011 at 5:50 AM, Martin Schreiber wrote:
> Linux expects an array of bytes in filenames (no encoding, no utf-8) AFAIK.
That's a nice theory, but:
All Linux distributions that I know use utf-8
Android uses utf-8
Meego uses utf-8
So, do you have any concrete example of new release
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
wrote:
> Current strategy on fpc core seems to be to have 2 RTLs:
>
> One with unicode string, one with ansistring.
Isn't that somewhat nasty for people currently using UTF-8?
I mean, lets say that we can divide everyone using FPC into 3 group
On 14/09/2011 03:56, Luiz Americo Pereira Camara wrote:
>
> I propose that the above behavior be implemented as a type named RTLString
The Object Pascal language already has enough damn string types. I
really don't think we should be adding fuel to the fire, by adding yet
more string types!
> S
Am 14.09.2011 04:22, schrieb Felipe Monteiro de Carvalho:
Is this possible in UNIX? I can see that in Windows you can use the
trick to use W versions which are identical except for the string type
and drop Windows 9x support, but is this really possible for the UNIX
syscalls? They expect UTF-8 n
On Tue, Sep 13, 2011 at 10:03 PM, Paul Ishenin wrote:
> 14.09.2011 9:21, dmitry boyarintsev wrote:
> How would you estimate the costs of this task? Would you take it if we
> collect some good sum of money or do work for a full day now?
It's not just 1 task. These are multiple tasks:
1) Abstract D
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
wrote:
> One with unicode string, one with ansistring. They will have the same code,
> but will be compiled twice, each time with a different compiler define to
> decide which version it must be.
Is this possible in UNIX? I can see that in Wind
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
wrote:
> About the rest I will not comment. But the above certainly will not happen.
>
> The ansistring version must remain for backwards compatibility.
>
> Current strategy on fpc core seems to be to have 2 RTLs:
I didn't know that backward co
Jeppe Græsdal Johansen schrieb:
Hardware support for writes to arbitrary memory addresses is
restricted to very few addresses, not really useful.
How many times do you think you need more than 1-2 watchpoints? Lots of
breakpoints I can understand, but I've never found many uses for
watchpoints
On 13/9/2011 22:56, Luiz Americo Pereira Camara wrote:
On 13/9/2011 17:14, Graeme Geldenhuys wrote:
the easiest way... but this is be best way to codify our programs,
don't you think?
UnicodeString should meant UTF-8 on Linux, *BSD, MacOSX etc
Unicodestring should mean UTF-16 on Windows.
I p
Hello devs.
Please explain why the next example does not compiles with a message:
"Error: Wrong type "Array Of Const" in array constructor"?
program Project1;
{$mode delphi}{$H+}
function g_object_dosomething(AObject: Pointer; args: array of const):
Boolean; cdecl; external 'test.dll';
ty
14.09.2011 9:21, dmitry boyarintsev wrote:
Add a lack of development time to all this. And it turns-out gdb is
the best option available :)
How would you estimate the costs of this task? Would you take it if we
collect some good sum of money or do work for a full day now?
Best regards,
Paul
On 13/9/2011 17:14, Graeme Geldenhuys wrote:
On 13 September 2011 21:25, Marcos Douglas wrote:
Graeme Geldenhuys, sometime, written that string type shoud be
depended of plataform. I agree with him, but I don't know if this is
+1 ;-)
the easiest way... but this is be best way to codify our
I see no problems with the idea of creating another debugger,
especially if written in FPC.
Since there're plenty of the GDB-wrappers already!
And it's also a good option to support either ways: "over-gdb" and
"native". In fact, I've been planning to add "GDB" target into Duby,
together with native
On Tue, Sep 13, 2011 at 5:14 PM, Graeme Geldenhuys
wrote:
> On 13 September 2011 21:25, Marcos Douglas wrote:
>>
>> Graeme Geldenhuys, sometime, written that string type shoud be
>> depended of plataform. I agree with him, but I don't know if this is
>
> +1 ;-)
>
>
>> the easiest way... but this
On 13 September 2011 21:25, Marcos Douglas wrote:
>
> Graeme Geldenhuys, sometime, written that string type shoud be
> depended of plataform. I agree with him, but I don't know if this is
+1 ;-)
> the easiest way... but this is be best way to codify our programs,
> don't you think?
UnicodeStri
I agree with Joost. I've always liked the Insight GUI for gdb, and as
best I know that's written in Tcl/Tk, of all things. So a FreePascal
front end for gdb isn't a bad idea, and would be a great deal easier
than writing a complete low-level debugger from scratch.
--73--
--Jeff Duntemann
Co
On 13 September 2011 17:10, Juha Manninen wrote:
>
> Graeme, are you working on Duby or some new debugger?
I'm working on Duby, but all changes are local to my system. I don't
have commit rights to Duby on SourceForge - though I never asked.
I'm also not sure if the original author of duby would
On Tue, Sep 13, 2011 at 8:52 AM, Graeme Geldenhuys
wrote:
> [sorry to be harsh towards DaWorm, but that was a
> damn stupid example]
It was only an example intended to show that executing getters can
have unintended and sometimes disastrous and/or non reversible side
effects. By itself it might
On Tue, Sep 13, 2011 at 4:05 PM, Felipe Monteiro de Carvalho
wrote:
> Hello,
>
> Following from a discussion on mac-pascal, I'd like to propose a
> solution for Unicode support.
>
> I know that hundreds of messages were already spent on the topic, but
> was there any conclusion in the end?
>
> Bas
On Tue, 13 Sep 2011, Felipe Monteiro de Carvalho wrote:
Hello,
[snip]
The ansi version I would simply let it die. It's time people migrate
to Unicode anyway. The change from ansi to utf-8 is very easy.
About the rest I will not comment. But the above certainly will not happen.
The ans
Hello,
Following from a discussion on mac-pascal, I'd like to propose a
solution for Unicode support.
I know that hundreds of messages were already spent on the topic, but
was there any conclusion in the end?
Basically I think that we could support both choices (utf-8 and
unicode string or whate
- "Graeme Geldenhuys" schreef:
> the debugger to limit what I am allowed to do. eg: Delphi allows it
> without *anybody* complaining!. You are a programmer, you should know
> what you are doing. If you didn't want the getter method to execute,
> then you should have debugged the field variab
On 13 September 2011 16:52, Hans-Peter Diettrich wrote:
> That's why Delphi normally checks for changed values only when a breakpoint
> is hit, not on every instruction.
That makes no sense at all! A watchpoint should trigger as soon as
that data referenced by some memory address changes. Then y
On 9/12/2011 20:30, Skybuck Flying wrote:
Well I hope the pascal language is updated so semicolons become required for
end's.
semicolons terminate statements... end does not...
Take a long hard look at the P4 or P5 code and you will find a lot of if then
else statements with *wrong identatio
2011/9/13 Graeme Geldenhuys
> Not at all! The debugger I am working on ONLY reads the debug
> information embedded in the executable - in my case DWARF info supplied
> by FPC.
>
Graeme, are you working on Duby or some new debugger?
I found your old mails that mentioned a Sybil debugger.
Another
On 13 Sep 2011, at 16:52, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU p
Den 13-09-2011 16:52, Hans-Peter Diettrich skrev:
Michael Schnell schrieb:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU prov
Michael Schnell schrieb:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU provides support for this.
It's not the CPU, it's mor
Graeme Geldenhuys schrieb:
On 13/09/2011 01:43, DaWorm wrote:
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
Yes, yes, but I am a big boy and know what I am doing, so I do NOT want
the debugger to l
Michael Schnell schrieb:
GDB is built for supporting multiple languages. E.g., its ADA support
has been much better than its C++ support for a long time (although
C++ support is getting fairly good nowadays too).
Unfortunately it seems to be hard (or close to impossible) to work with
the g* te
Flávio Etrusco schrieb:
Right, property getters can have side effects, like all procedures. That's
why I already suggested an hint on property declarations, telling which data
item should be displayed for the property.
Yes. Delphi has/had an option to enable function calls/side effects on
pro
On Tue, Sep 13, 2011 at 10:10 AM, Graeme Geldenhuys
wrote:
> On 13/09/2011 14:48, Michael Schnell wrote:
>> If we could really hope for this, I would vote for a gdb extension
>> instead of creating a completely new debugger from scratch .
>
> I disagree. In the long term, I think a object pascal b
On 13/09/2011 14:48, Michael Schnell wrote:
> If we could really hope for this, I would vote for a gdb extension
> instead of creating a completely new debugger from scratch .
I disagree. In the long term, I think a object pascal based debugger for
FPC is the way to go - potential for much easier
Hi,
I noticed I still have the 2.4.2 PDF docs, so went to the freepascal.org
website and downloaded the online versions just to notice that they
are 2.4.2 as well.
The updated docs are on SourceForge though.
Can anybody update the PDF docs in the following URL please?
http://www.freepas
On Mon, Sep 12, 2011 at 7:59 PM, Martin wrote:
> 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
> librar
On 13 Sep 2011, at 14:52, Graeme Geldenhuys wrote:
On 13/09/2011 14:33, Jonas Maebe wrote:
No, he's saying that it should not be easy to do this accidentally. I
can imagine that in IDEs that evaluate everything your mouse cursor
happens to hoover over, automatic evaluation of getters with sid
On 13/09/2011 14:53, Jonas Maebe wrote:
>
> -O-1 is the same as -O- -O1 (just like -vwn is the same as -vw -vn --
> all single-character FPC options behave that way).
OK, thanks.
> -O- and -O1 are both listed in the overview of the command line
> options of the Programmers Guide (Appendix A
On Tue, 2011-09-13 at 14:48 +0200, Michael Schnell wrote:
> On 09/13/2011 01:22 PM, Jonas Maebe wrote:
> >
> > Don't insult people when you clearly don't have any experience
> > whatsoever in working with them.
> Sorry if I sounded impolite. I did not at all mean to insult them. On
> the contrary
On 13 Sep 2011, at 14:43, Graeme Geldenhuys wrote:
Wow, thanks for that tip! It's a rather important piece of
information.
Is it mentioned somewhere in the FPC docs? I searched the Programmers
Guide but couldn't find any reference to -O- or -O- syntax.
-O-1 is the same as -O- -O1 (just lik
On 13/09/2011 14:33, Jonas Maebe wrote:
>
> No, he's saying that it should not be easy to do this accidentally. I
> can imagine that in IDEs that evaluate everything your mouse cursor
> happens to hoover over, automatic evaluation of getters with side
> effects can be quite an annoyance.
Ag
Sounds good !
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/13/2011 02:09 PM, Joost van der Sluis wrote:
Very well said !
Thanks,
-Michael (who does a lot more ANSI C than Pascal, as this is necessary
with embedded controllers.)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.fre
On 13/09/2011 00:37, Jonas Maebe 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 optimization
On 09/13/2011 01:22 PM, Jonas Maebe wrote:
Don't insult people when you clearly don't have any experience
whatsoever in working with them.
Sorry if I sounded impolite. I did not at all mean to insult them. On
the contrary I praise them for their exceptional work !
I only wanted to state that
On 13 Sep 2011, at 14:20, Graeme Geldenhuys wrote:
What you are describing is like saying "we are not supposed to change
values at runtime while debugging either".
No, he's saying that it should not be easy to do this accidentally. I
can imagine that in IDEs that evaluate everything your mo
On 13 Sep 2011, at 13:46, Joost van der Sluis wrote:
I think I have that patch applied. Calling functions in itself does
work, even when they use Borland fastcall. The problem is that it does
not work for a method, this inside a class.
I've found the patch again:
http://www.hu.freepascal.org
On 13/09/2011 01:43, DaWorm wrote:
> 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
Yes, yes, but I am a big boy and know what I am doing, so I do NOT want
the debugger to limit what I am allowed to d
On 12/09/2011 22:37, Hans-Peter Diettrich wrote:
>
> I expect that RTTI is used by an FPC debugger, but I don't expect that
Not at all! The debugger I am working on ONLY reads the debug
information embedded in the executable - in my case DWARF info supplied
by FPC.
Regards,
- Graeme -
--
f
On Tue, 2011-09-13 at 12:59 +0200, Michael Schnell wrote:
> On 09/13/2011 11:06 AM, Jonas Maebe wrote:
> >
> > GDB is built for supporting multiple languages. E.g., its ADA support
> > has been much better than its C++ support for a long time (although
> > C++ support is getting fairly good nowad
On Mon, 2011-09-12 at 23:07 +0200, Jonas Maebe wrote:
> 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
On 13 Sep 2011, at 12:59, Michael Schnell wrote:
On 09/13/2011 11:06 AM, Jonas Maebe wrote:
GDB is built for supporting multiple languages. E.g., its ADA
support has been much better than its C++ support for a long time
(although C++ support is getting fairly good nowadays too).
Unfortuna
On 13/09/2011 12:11, Jonas Maebe wrote:
afaik, requires hardware support.
Support has to be implemented in GDB for each architecture before it
will work (currently it's implemented for x86 and ARM, afaik), but it
does not rely on special hardware support.
http://www.gnu.org/s/gdb/news/re
On 13 Sep 2011, at 12:22, Martin wrote:
On 13/09/2011 10:31, Flávio Etrusco wrote:
GDB supposedly has support for reverse execution/walking back; I
don't
even know whether it really works for C, not to mention FPC calling
conventions, but if it does it would be a killer ;-)
It's unrelated
On 09/13/2011 11:06 AM, Jonas Maebe wrote:
GDB is built for supporting multiple languages. E.g., its ADA support
has been much better than its C++ support for a long time (although
C++ support is getting fairly good nowadays too).
Unfortunately it seems to be hard (or close to impossible) to w
On 09/12/2011 03:23 PM, r...@rdos.net wrote:
that does not have a modern GUI integrated into it,
Why should a debugger have it's own GUI ? IMHO it should be used
integrated in an IDE, so tit should have a decent API to be used by an IDE.
So providing a command line interface (if started sitt
On 13/09/2011 11:02, michael.vancan... wrote:
>>
>> I have adapted the docs.
Thanks.
> By the way, the second paragraph in the help already contained this info.
Yes I saw that, but the original two paragraphs seem to contradict
themselves. So a clarification seemed in order. ;-)
Regards,
-
2011/9/13, michael.vancann...@wisa.be :
>
>
> On Tue, 13 Sep 2011, michael.vancann...@wisa.be wrote:
>
>>
>>
>> On Tue, 13 Sep 2011, Graeme Geldenhuys wrote:
>>
>>> Hi,
>>>
>>> Below is a quote from the documentation of the ApplicationName()
>>> function:
>>>
>>> "Standard this is equal to the resu
On 13/09/2011 10:31, Flávio Etrusco wrote:
GDB supposedly has support for reverse execution/walking back; I don't
even know whether it really works for C, not to mention FPC calling
conventions, but if it does it would be a killer ;-)
afaik, requires hardware support.
most intel cpu don't
___
On Mon, Sep 12, 2011 at 11:42 PM, Hans-Peter Diettrich
wrote:
> 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 da
On 12 Sep 2011, at 15:23, r...@rdos.net wrote:
Why would anybody want to concentrate on gdb, which is an ancient
debugger,
It's only 7 years older than FPC (GDB: 1986; FPC: 1993).
that does not have a modern GUI integrated into it,
A GUI should not be integrated in a debugger. You don't w
On Tue, 13 Sep 2011, michael.vancann...@wisa.be wrote:
On Tue, 13 Sep 2011, Graeme Geldenhuys wrote:
Hi,
Below is a quote from the documentation of the ApplicationName() function:
"Standard this is equal to the result of ParamStr(0), but it can be
customized by setting the OnGetApplicati
On Tue, Sep 13, 2011 at 2:30 AM, Skybuck Flying wrote:
> Well I hope the pascal language is updated so semicolons become required for
> end's.
lol!
> Take a long hard look at the P4 or P5 code and you will find a lot of if
> then else statements with wrong identation as well, this makes it somew
On Tue, 13 Sep 2011, Graeme Geldenhuys wrote:
Hi,
Below is a quote from the documentation of the ApplicationName() function:
"Standard this is equal to the result of ParamStr(0), but it can be
customized by setting the OnGetApplicationName callback."
It should say 'filename part' of param
On Tue, 13 Sep 2011, Skybuck Flying wrote:
Hello,
Free Pascal 2.4.2 does not know about "NativeInt" a new type in recent Delphi
compilers which is either 32 bit for 32 bit platforms or 64 bit for 64 bit
platforms.
NativeInt already exists in trunk, and should exist in the upcoming 2.6.0
Den 13-09-2011 10:15, Michael Schnell skrev:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU provides support for this. (I
have
Hi,
Below is a quote from the documentation of the ApplicationName() function:
"Standard this is equal to the result of ParamStr(0), but it can be
customized by setting the OnGetApplicationName callback."
This seems incorrect, as the following test program shows.
--[ test1.pas
> 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
Hello,
Free Pascal 2.4.2 does not know about "NativeInt" a new type in recent
Delphi compilers which is either 32 bit for 32 bit platforms or 64 bit for
64 bit platforms.
Apperently the adventage of the NativeInt is that it can be used in for
loops, while int64 may not be used in for loops.
Well I hope the pascal language is updated so semicolons become required for
end's.
Take a long hard look at the P4 or P5 code and you will find a lot of if
then else statements with wrong identation as well, this makes it somewhat
hard to understand which else belongs to which if, it also mak
2011/8/30, Martin :
> The error I get:
> { .\fpmake.exe distclean --localunitdir=../.. --globalunitdir=..
> --os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o
> -FuC:/FPC/SVN/fix_2_6/rtl -o -FuC:/FPC/SVN/fix_2_6/packages/hash -o
> -FuC:/FPC/SVN/fix_2_6/packages/paszlib -o
> -FuC:/FPC/SVN/fix_2_6/p
On 09/12/2011 11:51 PM, Hans-Peter Diettrich wrote:
) debugger, I only want *better* high-level (language specific)
support in Lazarus. Finally I want to debug applications, not an new
debugger with different behaviour and restrictions on every platform ;-)
A multi-arch compiler should come with
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU provides support for this. (I
have no idea which of the CPUs supported by FPC ha
73 matches
Mail list logo
