Re: [fpc-devel] fink (debian) fpc package for darwin
Dr. Karl-Michael Schindler wrote: Hi all, In order to get fpc into fink, the darwin/macosx debian package manager it would be necessary to make available a bootstrap tar ball (640 KB) with the ppcppc binary and a default fpc.cfg file. My suggestion would be the same dir as the fpc source tar ball, i.e. ftp://ftp.freepascal.org/mirrors/fpc/beta/source-1.9.8/ Comments? Questions? Fine with me. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fink (debian) fpc package for darwin
the fpc.cfg is just installed in ../etc as a default fpc.cfg file. Am 20.03.2005 um 01:49 schrieb peter green: note: a config file is NOT needed to compile freepascal itself the makefiles pass an option that tells the compiler to ignore it anyway. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dr. Karl-Michael Schindler Sent: 19 March 2005 23:11 To: FPC developers' list Subject: [fpc-devel] fink (debian) fpc package for darwin Hi all, In order to get fpc into fink, the darwin/macosx debian package manager it would be necessary to make available a bootstrap tar ball (640 KB) with the ppcppc binary and a default fpc.cfg file. My suggestion would be the same dir as the fpc source tar ball, i.e. ftp://ftp.freepascal.org/mirrors/fpc/beta/source-1.9.8/ Comments? Questions? Best wishes - Michael Schindler ___ 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPC and valgrind
I tried out valgrind on lazaraus and one of my own lcl programs, and was
able to get it working by after applying some small patches to valgrind
(which I have sent to the valgrind mailing lists). valgrind found some
uninitialised memory reads, which the attached patch fixes.
On a related matter, if I try and look at the stabs info, objdump -g
gives errors such as:
Bad stab: defALTPROPNAME:c=s''; (My program)
Bad stab: 3391;-2147483647;2147483647; (lazarus)
though gdb is working fine. (System is Fedora Core 3)
Colin
diff -uNr fpc/rtl/inc/sstrings.inc fpc.w/rtl/inc/sstrings.inc
--- fpc/rtl/inc/sstrings.inc2005-02-26 10:58:09.0 +
+++ fpc.w/rtl/inc/sstrings.inc 2005-03-19 22:17:36.672656850 +
@@ -795,11 +795,11 @@
inc(code);
end;
{ Decimal ? }
- if (s[code]='.') and (length(s)=code) then
+ if (length(s)=code) and (s[code]='.') then
begin
hd:=1.0;
inc(code);
- while (s[code] in ['0'..'9']) and (length(s)=code) do
+ while (length(s)=code) and (s[code] in ['0'..'9']) do
begin
{ Read fractional part. }
flags:=flags or 2;
@@ -816,23 +816,24 @@
exit;
end;
{ Exponent ? }
- if (upcase(s[code])='E') and (length(s)=code) then
+ if (length(s)=code) and (upcase(s[code])='E') then
begin
inc(code);
- if s[code]='+' then
-inc(code)
- else
-if s[code]='-' then
- begin
- esign:=-1;
- inc(code);
- end;
- if not(s[code] in ['0'..'9']) or (length(s)code) then
+ if Length(s) = code then
+if s[code]='+' then
+ inc(code)
+else
+ if s[code]='-' then
+ begin
+ esign:=-1;
+ inc(code);
+ end;
+ if (length(s)code) or not(s[code] in ['0'..'9']) then
begin
fpc_Val_Real_ShortStr:=0.0;
exit;
end;
- while (s[code] in ['0'..'9']) and (length(s)=code) do
+ while (length(s)=code) and (s[code] in ['0'..'9']) do
begin
exponent:=exponent*10;
exponent:=exponent+ord(s[code])-ord('0');
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and valgrind
C Western wrote: I tried out valgrind on lazaraus and one of my own lcl programs, and was able to get it working by after applying some small patches to valgrind (which I have sent to the valgrind mailing lists). valgrind found some uninitialised memory reads, which the attached patch fixes. You could also use the -gv switch, it generates stabs accepted by valgrind. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and valgrind
Florian Klaempfl wrote: C Western wrote: I tried out valgrind on lazaraus and one of my own lcl programs, and was able to get it working by after applying some small patches to valgrind (which I have sent to the valgrind mailing lists). valgrind found some uninitialised memory reads, which the attached patch fixes. You could also use the -gv switch, it generates stabs accepted by valgrind. That works fine also - I guess I should have read the online help. It doen't fix the problem with objdump though objdump -g still gives errors. Colin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] ansistring -- widestring conversion
btw theese changes have already been committed (i sent them personally to fpk). It seems like this mail was held for approval or something (i previously thought it had been dropped) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of peter green Sent: 11 March 2005 03:33 To: fpc-devel@lists.freepascal.org Subject: [fpc-devel] ansistring -- widestring conversion i post here a heavilly modified version of the widestring code (and a couple of files from the xml code that depend on it) i have made the ansi -- wide conversion routines take a buffer and length as input but make the return in an ansistring/widestring var parameter i believe this gives a good compromise between performance and flexibility (most other ways of returning a variable length string are hacky to say the least) furthermore i think the cases where the output isn't being put into an ansistring or widestring will be very rare anyway. i also made the default/fallback conversion do a direct mapping of all values up to 255 rather than just up to 127 and made it use a ? rather than a space to replace unknown codes. this code seems to all compile ok but for some reason some gtk2 stuff has suddenly failed on me (which since grep didn't turn up anything widestring related seems very strange) preventing me from completing a make all. im not sure if this happens with the unmodified snapshot as well. the code has had no functional testing yet (does anyone know how to fun a modified compiler through the testsuite?) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] errorct.msg
El dc, 09-03-2005 a las 11:19, jordi escribió: Hi, I send the catalan translation of errore.msg (v 1.119). Sorry, I sent this message on march 9 ...and I receive the post acknowledgement today ... -- (Please, if you can answer use the list, otherwise I won't receive it. Thanks) Salutacions Jordi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
Ales Katona wrote: C++ requires friend only because it lacks the idea of modularity. Since all classes are apart they need some way to tell each other I can use you In pascal you simply put them into 1 unit. That's why the C++ model is better, there exists no requirement to implement related classes in a single module. In porting C++ code to Pascal I often stumbled into circular unit references. Then the only solution is a monster unit, that implements all the related classes at once, where the C++ implementation can be split into appropriate modules. Even in Java it's possible to implement every class in a dedicated unit, regardless of class relationships, and without a need for separate header files. That's what I call a good modular concept. Perhaps I dislike Pascal include files only because they are poorly supported by the Delphi IDE. With better support it were possible to split the implementation into multiple dedicated include files, which could be thought of as implementation files, according to e.g. the Modula model. Lazarus offers better support for included files, but unfortunately it currently groups the types, constants etc. overview together by the according clauses; I hope for better grouping options in the near future, so that e.g. all types of an unit can reside in a single group. I already considered to contribute to the Lazarus development, but currently I have other projects with higher priority... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
Michael Van Canneyt wrote: sorry, but I fail to see the problem ? The above makes all protected members of a class visible. This is normal, that is why they are protected. If you want to avoid that, make the members private. Then they are visible only in the same unit, even for other classes (for 'cooperation'), but not outside the unit, even with a descendent. I.e. protected means to you that there exist means to bypass that protection? Hmm, I think that I can update my mental class model accordingly ;-) Thanks DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
Micha Nelissen wrote: On Sat, 19 Mar 2005 10:04:55 +0100 DrDiettrich [EMAIL PROTECTED] wrote: In porting C++ code to Pascal I often stumbled into circular unit references. Then the only solution is a monster unit, that implements all the related classes at once, where the C++ implementation can be split into appropriate modules. The real question is: was the design of the code ok ? Circular references makes code harder to understand. Layers are easier to understand. C++ creates one monster module in this case as well. You could do the same as in C++: split everything into include files. Pascal units aren't 1:1 equivalent of C++ include files, if C++ libraries are done properly, you can translate namespaces to pascal units. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
Hi Ales, on 2005-03-18T10:57:10+01:00 Ales wrote: C++ requires friend only because it lacks the idea of modularity. Since all classes are apart they need some way to tell each other I can use you In pascal you simply put them into 1 unit. But IMCO this is not really a good OOP-like solution. Above all because every class in the unit have access to all sections of a other class, including the private section (at least in Delphi). A real private section is on my wish list since Delphi 1. Sometimes is it not possible or meaninful to put all related classes in 1 unit, e.g. to avoid monster units and split a problem in surveyable parts, although this classes belong together and are managed by a furthermore class. Then you need to publish more methods, as you need for other resp. the actual usage, this softed the information hiding concept. Years ago I read a description of a object oriented pascal dialect, which use a other concept, IIRC called view concept. The developer can declare different views to a class, which only contain the methods, which are needed for a concrete problem. I think such a concept would be the better way. The developer of a class or component don't need to consider, which methods / fields he need to set in the protected part. A developer which derive a class can define, which methods / fields he need and write a view without any hacks or modification of the origin class. wkr Peter. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Hint: Parameter sender not used
Hi Uberto,
on 2005-03-11T18:35:45+01:00 Uberto wrote:
This is not a big issue, anyway could we avoid the endless list of such
similar hints compiling Lazarus and our program?
Don't make me wrong, I apreciate the hints of the compiler.
9 times out of 10 if I don't use a parameter in a function or a method there
it is an error of mine.
But in published methods the parameter list is mandatory, so it doesn't make
sense to hint them.
Moreover they hide real hints.
I agree.
I have (unsuccessful) try to post a similar mail in the fpc pascal
list.
But what do you mean with published methods? The published section is
intended only for properties, which should be published in the object
inspector. I guess you mean event methods. Beside event methods,
callback functions and virtual methods could be affected too.
My main problem, if I hide the hint by using
{$HINTS OFF}
...
{$HINTS ON}
I remove all useful hints as well.
wkr Peter.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
DrDiettrich wrote / napísal (a): Ales Katona wrote: C++ requires friend only because it lacks the idea of modularity. Since all classes are apart they need some way to tell each other I can use you In pascal you simply put them into 1 unit. That's why the C++ model is better, there exists no requirement to implement related classes in a single module. In porting C++ code to Pascal I often stumbled into circular unit references. Then the only solution is a monster unit, that implements all the related classes at once, where the C++ implementation can be split into appropriate modules. Even in Java it's possible to implement every class in a dedicated unit, regardless of class relationships, and without a need for separate header files. That's what I call a good modular concept. Perhaps I dislike Pascal include files only because they are poorly supported by the Delphi IDE. With better support it were possible to split the implementation into multiple dedicated include files, which could be thought of as implementation files, according to e.g. the Modula model. Lazarus offers better support for included files, but unfortunately it currently groups the types, constants etc. overview together by the according clauses; I hope for better grouping options in the near future, so that e.g. all types of an unit can reside in a single group. I already considered to contribute to the Lazarus development, but currently I have other projects with higher priority... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel This is actualy a C problem. If you imagine the outcome any bigger C program is one big piece of code. If C/C++ had proper modularity support, things like this wouldn't happen. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Can't build 1.9.8
On Sun, 20 Mar 2005 19:02:06 +0100 (CET), Peter Vreman [EMAIL PROTECTED] wrote: Hi all, As 1.9.6 has finally entered Debian, I'm now working on packages for Why is the debian diff for 1.9.6 so big? It looks like it contains the same files that are also available in install/doc and install/debian in the original fpc sources and in cvs. I probably screwed up, somehow. I'll see if the same happens to 1.9.8 and fix it using 'make debtargz' as you've pointed out. Thanks! If you want to get a tar.gz.orig file you can use 'make debtargz' in the top dir of FPC. 1.9.8. However, by the time I try to compile the RTL, I get makefile errors which I didn't with 1.9.6. Here's the relevant output: `/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8/rtl/linux' /usr/bin/fpcmake -p -Ti386-linux Makefile.fpc Processing Makefile.fpc Error: No targets set make[3]: *** [fpc_install] Error 1 Already fixed in current CVS: RCS file: /FPC/CVS/fpc/install/debian/rules,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- rules 6 Feb 2005 22:13:15 - 1.21 +++ rules 7 Mar 2005 18:10:25 - 1.22 @@ -54,9 +54,10 @@ # Get utils NEWPP=$(PWD)/compiler/$(PPNEW) NEWFPDOC=$(PWD)/utils/fpdoc/fpdoc +NEWFPCMAKE=$(PWD)/utils/fpcm/fpcmake # Create default options BUILDOPTS=PP=$(NEWPP) -INSTALLOPTS=PP=$(NEWPP) INSTALL_PREFIX=$(INSTALL_DIR)/usr +INSTALLOPTS=PP=$(NEWPP) FPCMAKE=$(NEWFPCMAKE) INSTALL_PREFIX=$(INSTALL_DIR)/usr export DH_COMPAT=2 # export DH_VERBOSE=1 -- Carlos Laviola [EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
