Re: [fpc-devel] In FPC written FPC Debugger
no gdb or even a GNU compiler exists for Win64. Does that mean, if you want to use open source tools, you can write code for Win64 in Pascal but not in C ? Amazing ! -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
On Fri, Feb 22, 2008 at 9:10 AM, Michael Schnell [EMAIL PROTECTED] wrote: Does that mean, if you want to use open source tools, you can write code for Win64 in Pascal but not in C ? You can use Visual Studio and the Microsoft C Compiler to write win64 code too. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
On Fri, Feb 22, 2008 at 9:14 AM, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: On Fri, Feb 22, 2008 at 9:10 AM, Michael Schnell [EMAIL PROTECTED] wrote: Does that mean, if you want to use open source tools, you can write code for Win64 in Pascal but not in C ? You can use Visual Studio and the Microsoft C Compiler to write win64 code too. Ops, didn't read the open source part =) sorry ... please ignore -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Paul Ishenin wrote / napísal(a): And we need: 1. abstraction layer to use gdb or native debugger or any other debugger 2. program interface which can satisfy fpc ide, mse ide, and lazaraus ide I agree 100% on this, unless gdb people don't accept patches at all I think this is the way to go. Writing our own debugger would be an unfinished endless process riddled with bugs anyhow. Of course Marc has more to say about gdb than most of us :) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Martin Schreiber пишет: On Friday 22 February 2008 08.19:27 Daniël Mantione wrote: Displaying of ansistrings, widestrings and dynamic arrays is possible with current gdb. MSEide uses some tricks to achieve correct display in most of the cases. How? I have been playing with the idea of doing memory dumps with the x command and process the data yourself, but to do so, you need to have info about the symbols. A possibility for the textmode IDE, because ithas an integrated compiler, but a problem for an IDE that does not include the compiler. You are parsing ppu files or so? No, I use the typeinfo that gdb returns. Maybe everybody will benefit in you boys will do 1 good bicycle instead of 3? I see that Martin, Daniël and Marc are working/worked on one thing - debugger for fpc. And now we have 3 implementation based on gdb. + one start of native debugger. And we need: 1. abstraction layer to use gdb or native debugger or any other debugger 2. program interface which can satisfy fpc ide, mse ide, and lazaraus ide Is that more difficult than fixing/reimplementing already fixed/implemented things? Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Displaying of ansistrings, widestrings and dynamic arrays is possible with current gdb. MSEide uses some tricks to achieve correct display in most of the cases. GREAT ! The Lazarus team should take a look at this. (I was very disappointed to see that dynamic arrays could not be monitored.) (I did not play much with debugging FP without Lazarus.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Op Fri, 22 Feb 2008, schreef Michael Schnell: Lack of Pascal support like with, local procedures, widestrings, dynamic arrays, properties is platform independend. Therefore all platforms would benefit. Are these things depending on the internal structures of GDB part and informations for the executables that is needed to be used under a GIU like Lazarus or Eclipse ) or is it just a shortcoming of the command line user interface of GDB ? The internal structures of GDB don't allow for full Dwarf support, which is what is needed to fully support the Pascal language. Further, GDB would have to be enhanced to display data types as Pascal coders expect them. Would it not be more appropriate to enhance GDB itself instead of setting up a completely new project. Enhancing gdb has been done several times. Basically all Pascal support by GDB was written by our own Pierre Muller. However, there are several downsides: - GDB does not accept patches from everyone - It takes a long time between patch submission and when people actually have such a gdb on their systems. - You cannot rewrite the GDB internals as an outsider to properly support Dwarf and thus Pascal This seems to be a lot less work that reinventing the wheel. I feel that Delphi language is not the only language that offers features like or similar to local procedures, widestrings, dynamic arrays, properties. So this effort should be supported by the powers of GDB. You will find many people are only interrested in C. People working on gdb are mainly employed by embedded Linux companies of which C is the primary language. They don't mind someone working on Pascal support, but don't expect them to start acticvely working on features for other languages. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Op Fri, 22 Feb 2008, schreef Michael Schnell: have to be enhanced to display data types as Pascal coders expect them. Would it not be more appropriate to enhance GDB itself instead of setting up a completely new project. Enhancing gdb has been done several times. Basically all Pascal support by GDB was written by our own Pierre Muller. However, there are several downsides: - GDB does not accept patches from everyone - It takes a long time between patch submission and when people actually have such a gdb on their systems. - You cannot rewrite the GDB internals as an outsider to properly support Dwarf and thus Pascal - I don't have the feeling GDB is really trying to improve the quality on win* platforms. It seems we are still as far as we were when GDB 6.1 came out. This seems to be a lot less work that reinventing the wheel. I feel that Delphi language is not the only language that offers features like or similar to local procedures, widestrings, dynamic arrays, properties. So this effort should be supported by the powers of GDB. You will find many people are only interrested in C. People working on gdb are mainly employed by embedded Linux companies of which C is the primary language. They don't mind someone working on Pascal support, but don't expect them to start acticvely working on features for other languages. And same for any other non-*nix use. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Ales Katona schrieb: Paul Ishenin wrote / napísal(a): And we need: 1. abstraction layer to use gdb or native debugger or any other debugger 2. program interface which can satisfy fpc ide, mse ide, and lazaraus ide I agree 100% on this, unless gdb people don't accept patches at all I GDB is written in C, even worse it is written in a 80th hackish style using tons of macros. Most advanced pascal programmers can read it but writing or even debugging is another matter. Compiling gdb as any gcc written software is a nightmare especially on non unix. People not believing it might be my guest in creating new cross binutils for windows. Using Cygwin doesn't count because the dependency on cygwin1.dll causes only trouble for the user. And even if gdb supports everything, you are still stuck to it's sluggish machine interface when accessing it from IDEs since libgdb is not supported officially anymore. think this is the way to go. Writing our own debugger would be an unfinished endless process riddled with bugs anyhow. Of course Marc has more to say about gdb than most of us :) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Using Cygwin doesn't count because the dependency on cygwin1.dll causes only trouble for the user. That is _very_ true ! I had tons of those problems in non FP projects with several different development environments. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] An incomplete prototype of my ebook FREE PASCAL FROM SQUARE ONE
I have read the text and I'd like to thank the author for the immense effort (both in the past and in the future) put into it. The only criticism I might have on it would be that it is a little too US-centric. I am referring to the stuff related to measurement systems, and other various things that are peculiar to living in US. These are likely to make the job of translator rather hard and/or cause unnecessary confusion in the non-US (and, non-English) reader. Unless of course you let the translators do their job by translating the gist of the matter --i.e. do cultural translation-- by skipping or altering those parts. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Jonas Maebe schrieb: On 22 Feb 2008, at 09:32, Florian Klaempfl wrote: GDB is written in C, even worse it is written in a 80th hackish style using tons of macros. Most advanced pascal programmers can read it but writing or even debugging is another matter. It is not /that/ hard to debug But it is hard for people knowing C not that well but knowing pascal, that's what I meant. Would you ever have be able to contribute to fpc if the compiler had been written in C (yes, I did a prototype in C in '93 because I wanted a 32 Bit compiler to bootstrap :) )? Luckily enough I got the money to buy BP7 so I could use at least PM to have enough memory, this was before I got the idea to abuse TEMSStream to store symbols :) Compiling gdb as any gcc written software is a nightmare especially on non unix. On unix (at least on Linux and Mac OS X) it is trivial to compile (./configure ; make). Yes, and then you can go drinking 3 cups of coffee ;) even using a modern machine and not considering the unix centric approach it uses. If you've bad luck, make distclean doesn't clean everything, happens regularily, and you need to create a patch of your changes, re-unpack the sources and apply your patch. It doesn't have any unusual external dependencies, pretty much everything that's required is included in the gdb source tree itself. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
On 22 Feb 2008, at 11:24, Florian Klaempfl wrote: Jonas Maebe schrieb: On 22 Feb 2008, at 09:32, Florian Klaempfl wrote: GDB is written in C, even worse it is written in a 80th hackish style using tons of macros. Most advanced pascal programmers can read it but writing or even debugging is another matter. It is not /that/ hard to debug But it is hard for people knowing C not that well but knowing pascal, that's what I meant. If you can read the gdb sources, you can also debug it. I speak from experience, and I'm really not a C expert. It does take a while before you can find your way in the sources, but the same goes for any big project. It's obvious that if gdb were written in Pascal, more Pascal programmers could easily contribute to it. But I personally do not consider that downside big enough to rewrite the whole thing from scratch in Pascal (at least not for Mac OS X and Linux; and other people are obviously free to spend their time however they like). Would you ever have be able to contribute to fpc if the compiler had been written in C (yes, I did a prototype in C in '93 because I wanted a 32 Bit compiler to bootstrap :) )? Not at that time (I didn't know C at all in 1997). On unix (at least on Linux and Mac OS X) it is trivial to compile (./configure ; make). Yes, and then you can go drinking 3 cups of coffee ;) even using a modern machine and not considering the unix centric approach it uses. It's true that the first build takes a long time (especially if you, like me, build it on a network volume). But after that the incremental builds don't take that long. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
About reinventing the wheel... It is not about reinventing GDB. You can compare this story with designing a car: You can use an engine designed for an older car, this saves you the work of designing a new engine. But the existing engine does not fullfill all needs of the new car. So, some designers want to design a new engine which perfectly fits in the car and therefore gives many advantages. Others look up to the work needed and want to use the existing engine, with some modifications and live with the rest of its quirks. Both are valid engineering decisions. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
On 22 Feb 2008, at 09:32, Florian Klaempfl wrote: On unix (at least on Linux and Mac OS X) it is trivial to compile (./ configure ; make). It doesn't have any unusual external dependencies, It has some problems in general with preinstalled versions of the GNU libraries it packages (intl,readline), if your distribution deviates from what Linux/x86 packages. (or is explicitely fixed in configure). I routinely disable intenationalisation (-disable-nls) because of it. pretty much everything that's required is included in the gdb source tree itself. Which then in turn is also a cause for problems. Nothing an experienced Unix person can't handle, but not userfriendly either. IMHO the gdb tree should not build those libraries shared, or reject versions outside the tree to avoid this) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Hi! On Fre, 2008-02-22 at 09:20 +0100, Michael Schnell wrote: Lack of Pascal support like with, local procedures, widestrings, dynamic arrays, properties is platform independend. Therefore all platforms would benefit. Are these things depending on the internal structures of GDB part and informations for the executables that is needed to be used under a GIU like Lazarus or Eclipse ) or is it just a shortcoming of the command line user interface of GDB ? Would it not be more appropriate to enhance GDB itself instead of setting up a completely new project. This seems to be a lot less work that reinventing the wheel. I feel that Delphi language is not the only language that offers features like or similar to local procedures, widestrings, dynamic arrays, properties. So this effort should be supported by the powers of GDB. I want to second that. GDB also lacks some features very useful for C++ programmers (yes, I have to use it): - Display STL types (e.g. std::string, std::vector, std::map). These are the usual way of making strings and containers in C++ and are quite complex internally. GDB displays this internal structure of these types instead of beautifying it according to its semantics. For the containers it's even impossible to view its elements. - Set breakpoints within template functions. A template function might be instantiated multiple times, i.e. for every type it is used for. If you set a breakpoint at the source line within a template function, only one instantiation is (randomly?) chosen. Hmm, these rather like a GDB wish list bug report looking items point out that GDB doesn't even intensively care about C++ (despite it supports name (de-)mangling). Besides the mentioned points, I really dissuade from starting with a completely new debugger project, since there is so many basic work to implement and to care for and then to support. The FPC community is IMHO still too small for such a project. And GDB still lacks a lot of improvements. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] In FPC written FPC Debugger
Paul Ishenin wrote: Maybe everybody will benefit in you boys will do 1 good bicycle instead of 3? At the moment i do not see the good bicycle to ride on. I see that Martin, Daniël and Marc are working/worked on one thing - debugger for fpc. And now we have 3 implementation based on gdb. + one start of native debugger. And we need: 1. abstraction layer to use gdb or native debugger or any other debugger 2. program interface which can satisfy fpc ide, mse ide, and lazaraus ide Well the abstraction layer should be one feature of the native debugger, to make it usable for projects like lazarus, mseide etc ... At the moment i don't see gdb supporting all necessary features (e.g. gdb does not care for pascal enough). Is that more difficult than fixing/reimplementing already fixed/implemented things? I am currently trying to find pros and cons, feasibility. Usecase: I want to develop and debug on an arm target nice and productive. The arm target has udp, or serial console, but no display and has limited mem. My vision is as follows load: The fpc native debugger stub to the arm board. Communicate with the debugger, show a nice gui on linux/win. Do your job. The same should(could) hold for windows, linux, macos too ... The reality now would be: How do i find in internet or compile the gdb for my target ? (2 weeks) Deal with linking (2 days), Deal with libraries (3 days) ,deal with makefiles (1 day), deal with c code (1/2 day), deal with memory shortage, deal with the poor gdb pacal support, deal with the poor gdb interfacing support. (priceless ;-)) Then start doing the job with limitations ... In lazarus i have gdb/interfacing related crashes every one debugging run (making console apps for linux). What i want to say in my firm i need 3 experts to set up the whole thing. So why should i not start the project in c(++)? Because i can write and read pascal code after 1 bottle of wodka :-) And i vomit reading c code, as the language drives every user to win an obfuscation contest, including me when i used it for firmware projects. That is my motivation ... PS: i did not had a look marc weustinks code, nor knowed about it, i will have a look soon .. helmut ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Convert C++ Array[1] to FPC
Please help I am unsure how to port from C++ to fpc this code.
The function this must be passed to says that the structure pointer or size
is invalid.
C++
typedef struct _SSLPROTOCOL {
DWORD dwProtocol;
DWORD dwVersion;
DWORD dwFlags;
} SSLPROTOCOL, FAR *LPSSLPROTOCOL;
typedef struct _SSLPROTOCOLS {
DWORD dwCount;
SSLPROTOCOL ProtocolList[1]; // array of 'count' structures
} SSLPROTOCOLS, FAR *LPSSLPROTOCOLS;
My Attempt FPC Delphi Mode
type SSLPROTOCOL = record
dwProtocol : DWORD;
dwVersion : DWORD;
dwFlags: DWORD;
end;
_SSLPROTOCOL = SSLPROTOCOL;
LPSSLPROTOCOL = ^SSLPROTOCOL;
type SSLPROTOCOLS = record
dwCount :DWORD;
ProtocolList : array[0..0] of SSLPROTOCOL; // array of 'count'
structures
end;
_SSLPROTOCOLS = SSLPROTOCOLS;
LPSSLPROTOCOLS = ^SSLPROTOCOLS;
PSSLPROTOCOLS = ^SSLPROTOCOLS;
Thanks in advance.
If my port seems correct are there any ideas what could be the problem?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Freepascal in microcontrollers
Can freepascal be used on small processors that are 8 or 16 bits or does it expect that there are at least 32 bits for most things? I've been tempted lately to start making little circuits with microcontrollers on them. I realize that a great deal of the rtl/fcl would not be used on these little processors. Also since there is no OS on these devices does that mean that for sure fpc cannot work? Regards, Andrew Haines A 32 bit microcontroller: http://www.microcontroller.com/news/microchip_pic32.asp ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
