Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2004-12

problem making docs

8 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Vincent Snijders

Hi,

Two days ago, I could make the docs by doing:
make htmldist
in the fpc\doc directory.
Now I get these errors:
make htmlinstall DOCINSTALLDIR=doc
make[1]: Binnengaan van map `/home/vsds/lazarus/source/fpc-1.9/fpc/docs' make[1]: *** Geen regel voor aanmaken doel `includes', nodig voor `htmlincludes'. Stop.
make[1]: Weggaan uit map `/home/vsds/lazarus/source/fpc-1.9/fpc/docs' make: *** [htmlzip] Fout 2

I tried to find in the Makefile what goes wrong, but I didn't see htmlincludes nor includes mentioned.

I think it has something to do with Peters changes in the Makefile, but don't see how.
2004-12-19 21:20 peter

* docs/Makefile:

* includes variable instead of target to prevent always rebuilding

Vincent

Reply by email

Peter Vreman
to Vincent Snijders
Show quoted text 15 lines
Hi, Two days ago, I could make the docs by doing: make htmldist in the fpc\doc directory. Now I get these errors: make htmlinstall DOCINSTALLDIR=doc make[1]: Binnengaan van map `/home/vsds/lazarus/source/fpc-1.9/fpc/docs' make[1]: *** Geen regel voor aanmaken doel `includes', nodig voor `htmlincludes'. Stop. make[1]: Weggaan uit map `/home/vsds/lazarus/source/fpc-1.9/fpc/docs' make: *** [htmlzip] Fout 2 I tried to find in the Makefile what goes wrong, but I didn't see htmlincludes nor includes mentioned.

The Makefile.* files are not updated. I'll have a look when i'm home.

Reply by email

Joost van der Sluis
to Peter Vreman

Hi all,

I've found a problem in the string-implementation of the variants, but I thought I would better discus it first, before I start doing all sort of work for nothing.

In variants string-values are stored as PWideChar's. (called vOleStr) But if you set a string-value to a variant, it's stored and initialized as a WideString. Widestrings are ref-counted, and since it's getting casted into a PWideChar, things are going wrong. Example:

var v : variant;
    s : string;
begin
  v := 'Hello World';
  s := v;
  writeln(s);
  s := v;
  writeln(s);
end;

returns only one 'ello World' or in some cases ' d'. That's because in the assignment (s:=v) the memory of the Widestring is already freed before it's value is assigned to the string. (A new pwidechar is initialised at the same memory-location, wich sets the first character to #0, the termination of the newly-initialised pwidechar)

I've fixed this in changing the assignment-part to use a PWideChar instead of the Widestring. The problem of that solution is that you have to allocate memory for the PWideChar. If you change the value of the variant, memory should be re-allocated. And I'm curious if the memory will be freed when the variant is freed. Writing all those things would mean that you're writing all sorts of code, which is already there for Widestrings!

So I want to suggest to change the string-support in variants form PWideChar into Widestrings. This is also more Delphi-compatible. According to the Delphi help strings in variants are stored in Widestrings...

But as said, before I start changing this I would like to know what your opinion is on this...

Met vriendelijke groeten, Joost van der Sluis CNOC Informatiesystemen en Netwerken http://www.cnoc.nl

Reply by email

Joost van der Sluis
to Joost van der Sluis

Sorry, a small correction:

Show quoted text 13 lines
var v : variant; s : string; begin v := 'Hello World'; s := v; writeln(s); s := v; writeln(s); end; returns only one 'ello World' or in some cases ' d'. That's because in the assignment (s:=v) the memory of the Widestring is already freed
That's not true. Offcourse it's going wrong in the assignment of the
variant. (v:='Hello World')

Met vriendelijke groeten,

Joost van der Sluis
CNOC Informatiesystemen en Netwerken
http://www.cnoc.nl

Reply by email

Michael Van Canneyt
to Joost van der Sluis: I've found a problem in the string-implementation of the variants, but I thought I would…
Joost van der Sluis wrote 35 lines
Hi all, I've found a problem in the string-implementation of the variants, but I thought I would better discus it first, before I start doing all sort of work for nothing. In variants string-values are stored as PWideChar's. (called vOleStr) But if you set a string-value to a variant, it's stored and initialized as a WideString. Widestrings are ref-counted, and since it's getting casted into a PWideChar, things are going wrong. Example: var v : variant; s : string; begin v := 'Hello World'; s := v; writeln(s); s := v; writeln(s); end; returns only one 'ello World' or in some cases ' d'. That's because in the assignment (s:=v) the memory of the Widestring is already freed before it's value is assigned to the string. (A new pwidechar is initialised at the same memory-location, wich sets the first character to #0, the termination of the newly-initialised pwidechar) I've fixed this in changing the assignment-part to use a PWideChar instead of the Widestring. The problem of that solution is that you have to allocate memory for the PWideChar. If you change the value of the variant, memory should be re-allocated. And I'm curious if the memory will be freed when the variant is freed. Writing all those things would mean that you're writing all sorts of code, which is already there for Widestrings!

You must be careful with this. The implementation on Linux will be different than on Windows: On Windows the windows variant routines are used to manage the variants (because they can be passed to other processes via COM) and on Linux, FPC specific routines are used.

We should take care that the two remain compatible.

So I want to suggest to change the string-support in variants form PWideChar into Widestrings. This is also more Delphi-compatible. According to the Delphi help strings in variants are stored in Widestrings...

This is not quite true. (or it may depend on the Delphi version)

"if a variant containing an AnsiString is assigned to an OleVariant, the AnsiString becomes a WideString."

So this needs some thinking, and some input from the compiler guys.

Michael.

Reply by email

Joost van der Sluis
to Michael Van Canneyt
Show quoted text 38 lines
> I've found a problem in the string-implementation of the variants, but I > thought I would better discus it first, before I start doing all sort of > work for nothing. > > In variants string-values are stored as PWideChar's. (called vOleStr) > But if you set a string-value to a variant, it's stored and initialized > as a WideString. Widestrings are ref-counted, and since it's getting > casted into a PWideChar, things are going wrong. Example: > > var v : variant; > s : string; > > begin > v := 'Hello World'; > s := v; > writeln(s); > s := v; > writeln(s); > end; > > returns only one 'ello World' or in some cases ' d'. That's because in > the assignment (s:=v) the memory of the Widestring is already freed > before it's value is assigned to the string. (A new pwidechar is > initialised at the same memory-location, wich sets the first character > to #0, the termination of the newly-initialised pwidechar) > > I've fixed this in changing the assignment-part to use a PWideChar > instead of the Widestring. The problem of that solution is that you have > to allocate memory for the PWideChar. If you change the value of the > variant, memory should be re-allocated. And I'm curious if the memory > will be freed when the variant is freed. Writing all those things would > mean that you're writing all sorts of code, which is already there for > Widestrings! You must be careful with this. The implementation on Linux will be different than on Windows: On Windows the windows variant routines are used to manage the variants (because they can be passed to other processes via COM) and on Linux, FPC specific routines are used.

That explains the location of there implementation. I have no experience with COM, windows-variant internals etc. Can someone try the above example under Windows?

We should take care that the two remain compatible.

Are you sure they are now?

Show quoted text 9 lines
> So I want to suggest to change the string-support in variants form > PWideChar into Widestrings. This is also more Delphi-compatible. > According to the Delphi help strings in variants are stored in > Widestrings... This is not quite true. (or it may depend on the Delphi version) "if a variant containing an AnsiString is assigned to an OleVariant, the AnsiString becomes a WideString."

Yep, but in FPC (Linux, haven't looked into win32 stuff), variants can't contain any ansistrings. There are only two 'string-types' available in FPC's variants: PWideChar (which they call OleVariant, partially implemented as widestrings as I stated above) and VarString, which aren't implemented or used any further.

On Delphi there are shortstrings, widestrings, ansistrings, pwidechars, widechars and pchars. (see the help on TVarRec) This is all very different from the implementation in FPC.

So this needs some thinking, and some input from the compiler guys.

Probably, yes. (compiler guys, anyone?)
Basically I think that we should look how win32 handles this, and implement it that way into linux/other OS's.

Met vriendelijke groeten, Joost van der Sluis CNOC Informatiesystemen en Netwerken http://www.cnoc.nl

Reply by email

Michael Van Canneyt
to Joost van der Sluis
Joost van der Sluis wrote 66 lines
> > I've found a problem in the string-implementation of the variants, but I > > thought I would better discus it first, before I start doing all sort of > > work for nothing. > > > > In variants string-values are stored as PWideChar's. (called vOleStr) > > But if you set a string-value to a variant, it's stored and initialized > > as a WideString. Widestrings are ref-counted, and since it's getting > > casted into a PWideChar, things are going wrong. Example: > > > > var v : variant; > > s : string; > > > > begin > > v := 'Hello World'; > > s := v; > > writeln(s); > > s := v; > > writeln(s); > > end; > > > > returns only one 'ello World' or in some cases ' d'. That's because in > > the assignment (s:=v) the memory of the Widestring is already freed > > before it's value is assigned to the string. (A new pwidechar is > > initialised at the same memory-location, wich sets the first character > > to #0, the termination of the newly-initialised pwidechar) > > > > I've fixed this in changing the assignment-part to use a PWideChar > > instead of the Widestring. The problem of that solution is that you have > > to allocate memory for the PWideChar. If you change the value of the > > variant, memory should be re-allocated. And I'm curious if the memory > > will be freed when the variant is freed. Writing all those things would > > mean that you're writing all sorts of code, which is already there for > > Widestrings! > > You must be careful with this. The implementation on Linux will be > different than on Windows: On Windows the windows variant routines > are used to manage the variants (because they can be passed to other > processes via COM) and on Linux, FPC specific routines are used. That explains the location of there implementation. I have no experience with COM, windows-variant internals etc. Can someone try the above example under Windows? > We should take care that the two remain compatible. Are you sure they are now? > > So I want to suggest to change the string-support in variants form > > PWideChar into Widestrings. This is also more Delphi-compatible. > > According to the Delphi help strings in variants are stored in > > Widestrings... > > This is not quite true. (or it may depend on the Delphi version) > > "if a variant containing an AnsiString is assigned to an OleVariant, > the AnsiString becomes a WideString." Yep, but in FPC (Linux, haven't looked into win32 stuff), variants can't contain any ansistrings. There are only two 'string-types' available in FPC's variants: PWideChar (which they call OleVariant, partially implemented as widestrings as I stated above) and VarString, which aren't implemented or used any further. On Delphi there are shortstrings, widestrings, ansistrings, pwidechars, widechars and pchars. (see the help on TVarRec) This is all very different from the implementation in FPC.

TVarRec has nothing to do with Variants. TVarRec is for the Array of Const implementation. TVarData is for a variant.

Show quoted text 6 lines
> So this needs some thinking, and some input from the compiler guys. Probably, yes. (compiler guys, anyone?) Basically I think that we should look how win32 handles this, and implement it that way into linux/other OS's.

Not yet:

I had a closer look at the Delphi implementation (D5). They use varString (an internal type) which is not known by Windows. It is handled specially by the Delphi code. (That is probably why it is not present in FPC...)

Now, whenever a variant is passed to windows, it is converted to an OleVariant, which does the conversion from varString to varOleString.

What I think we can do is add support for varstring, and use that to store the ansistring. The PWideChar conversion stuff can then be added later, when we have COM support.

Do you think you can do this, or do you want me to have a go at it ?

Michael.

Reply by email

Joost van der Sluis
to Michael Van Canneyt
Michael Van Canneyt wrote 29 lines
On Mon, 20 Dec 2004, Joost van der Sluis wrote: > > > I've found a problem in the string-implementation of the variants, but I > > > thought I would better discus it first, before I start doing all sort of > > > work for nothing. > > > So I want to suggest to change the string-support in variants form > > > PWideChar into Widestrings. This is also more Delphi-compatible. > > > According to the Delphi help strings in variants are stored in > > > Widestrings... > > > > This is not quite true. (or it may depend on the Delphi version) > > > > "if a variant containing an AnsiString is assigned to an OleVariant, > > the AnsiString becomes a WideString." > > Yep, but in FPC (Linux, haven't looked into win32 stuff), variants can't > contain any ansistrings. There are only two 'string-types' available in > FPC's variants: PWideChar (which they call OleVariant, partially > implemented as widestrings as I stated above) and VarString, which > aren't implemented or used any further. > > On Delphi there are shortstrings, widestrings, ansistrings, pwidechars, > widechars and pchars. (see the help on TVarRec) This is all very > different from the implementation in FPC. TVarRec has nothing to do with Variants. TVarRec is for the Array of Const implementation. TVarData is for a variant.

You're right, sorry.

Show quoted text 12 lines
> > So this needs some thinking, and some input from the compiler guys. > > Probably, yes. (compiler guys, anyone?) > Basically I think that we should look how win32 handles this, and > implement it that way into linux/other OS's. Not yet: I had a closer look at the Delphi implementation (D5). They use varString (an internal type) which is not known by Windows. It is handled specially by the Delphi code. (That is probably why it is not present in FPC...)

That's the VarString, as implemented in FPC, which isn't used.

Show quoted text 9 lines
Now, whenever a variant is passed to windows, it is converted to an OleVariant, which does the conversion from varString to varOleString. What I think we can do is add support for varstring, and use that to store the ansistring. The PWideChar conversion stuff can then be added later, when we have COM support. Do you think you can do this, or do you want me to have a go at it ?

I'll give it a try. If I need help, or if I don't succeed I will contact you.

Met vriendelijke groeten, Joost van der Sluis CNOC Informatiesystemen en Netwerken http://www.cnoc.nl

Reply by email