Re: [fpc-devel] Can't build 1.9.8

2005-03-20 Thread Carlos Laviola
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


RE: [fpc-devel] "Friend" classes?

2005-03-20 Thread peter green


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of DrDiettrich
> Sent: 16 March 2005 10:59
> To: FPC developers' list
> Subject: Re: [fpc-devel] "Friend" classes?
>
>
> Michael Van Canneyt wrote:
>
> > > type TFriendClass = class(TNotMyClass);
> >
> > This is a simple descendent.
>
> Yes and no. The only purpose of this declaration is to get access to the
> protected members of the class, not to extend the class in any way.
note: protected in object pascal isn't really very well protected

if you need to get at a protected method/field/property of a class you can
always do so by creating a descendent and using an unchecked typecast.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] "Friend" classes?

2005-03-20 Thread Ales Katona
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] Hint: Parameter "sender" not used

2005-03-20 Thread Peter J. Haas
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?

2005-03-20 Thread Peter J. Haas
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] Can't build 1.9.8

2005-03-20 Thread Peter Vreman
> 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.

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





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] "Friend" classes?

2005-03-20 Thread Florian Klaempfl
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?

2005-03-20 Thread Micha Nelissen
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.

Micha

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] "Friend" classes?

2005-03-20 Thread DrDiettrich
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?

2005-03-20 Thread DrDiettrich
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] errorct.msg

2005-03-20 Thread jordi
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] ansistring <--> widestring conversion

2005-03-20 Thread peter green
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


[fpc-devel] Can't build 1.9.8

2005-03-20 Thread Carlos Laviola
Hi all,

As 1.9.6 has finally entered Debian, I'm now working on packages for
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:

make[4]: Leaving directory
`/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8/compiler/utils'
make[3]: Leaving directory
`/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8/compiler'
make[2]: Leaving directory
`/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8'
/usr/bin/make rtl_distinstall
PP=/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8/compiler/ppc386
INSTALL_PREFIX=/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8/debian/tmp/usr
make[2]: Entering directory
`/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8'
/usr/bin/make -C rtl distinstall
make[3]: Entering directory
`/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8/rtl'
/usr/bin/make -C linux all
make[4]: Entering directory
`/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8/rtl/linux'
make[4]: Leaving directory
`/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
make[3]: Leaving directory
`/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8/rtl'
make[2]: *** [rtl_distinstall] Error 2
make[2]: Leaving directory
`/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8'
make[1]: *** [install-arch-stamp] Error 2
make[1]: Leaving directory
`/home/claviola/code/debian/packages/freepascal/fpc/build/fpc-1.9.8'
make: *** [debbuild] Error 2

Regards,

-- 
Carlos Laviola
[EMAIL PROTECTED]

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and valgrind

2005-03-20 Thread Colin Western
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] FPC and valgrind

2005-03-20 Thread Florian Klaempfl
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


[fpc-devel] FPC and valgrind

2005-03-20 Thread C Western
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 s[code]='+' then
+  inc(code)
+else
+  if s[code]='-' then
+   begin
+ esign:=-1;
+ inc(code);
+   end;
+  if (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] fink (debian) fpc package for darwin

2005-03-20 Thread Dr. Karl-Michael Schindler
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


Re: [fpc-devel] fink (debian) fpc package for darwin

2005-03-20 Thread Florian Klaempfl
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