> Well, I have planned a inline-to-external conversion for fpdoc for exactly
> this reason.
That's nice to hear...
[Sorry for late reply]
d.l.l.i.w
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/f
Hi,
concerning the string topic, for me (using fpc since 2.0.4 on a regular basis;
TP experience ~ average user) there really should be an decision what way to
go as early as possible.
I'm not ranting and I know, that I'm not in the position to demand anything...
[I would really like to help, but
Am Saturday 22 December 2012 12:26:09 schrieb dev.d...@gmail.com:
> Users can define the internal type with e.g. {$STRING UTF8} for their
> *whole* project.
Should that (*whole* project) include also the "3rd party" units (with
available sourcecode)?
__
On Sat, 22 Dec 2012, dev.d...@gmail.com wrote:
Hi,
concerning the string topic, for me (using fpc since 2.0.4 on a regular basis;
TP experience ~ average user) there really should be an decision what way to
go as early as possible.
- We'll implement the capacity to have a code-page aware str
Hi,
> > Users can define the internal type with e.g. {$STRING UTF8} for their
> > *whole* project.
>
> Should that (*whole* project) include also the "3rd party" units (with
> available sourcecode)?
Yes, that's the idea...
... the only problem is, that many still use old style "hacking", this of
Hi,
thanks for the quick reply.
So the direction seems to be quite clear...
... unfortunately this seemingly wasn't communicated clearly enough to the
surroundings.
>Because of the requirement for backwards compatibility with FPC itself,
>we'll make 2 RTLs: one backwards compatible, one with th
On Sat, 22 Dec 2012, dev.d...@gmail.com wrote:
Hi,
thanks for the quick reply.
So the direction seems to be quite clear...
... unfortunately this seemingly wasn't communicated clearly enough to the
surroundings.
Because of the requirement for backwards compatibility with FPC itself,
we'll m
Hi,
thx, got it...
> There will always be conversion if
> 1) a unit specifies a string type by itself.
> 2) the unit comes in compiled form.
One more question:
If a particular unit (maybe 3rd party) does not define its string type, what
string type is used:
(a) the type defined in project,
(b) a
On Sat, 22 Dec 2012, dev.d...@gmail.com wrote:
Hi,
thx, got it...
There will always be conversion if
1) a unit specifies a string type by itself.
2) the unit comes in compiled form.
One more question:
If a particular unit (maybe 3rd party) does not define its string type, what
string type
On Saturday 22 December 2012 12:55:12 Michael Van Canneyt wrote:
[...]
> - The {$H } directive will be extended so you can choose which string type
> you need per unit. (ansi/wide/utf16/utf8...)
> This is different from Delphi, where you don't have this choice:
> String=Widestring.
You probably
On Sat, 22 Dec 2012, Martin Schreiber wrote:
On Saturday 22 December 2012 12:55:12 Michael Van Canneyt wrote:
[...]
- The {$H } directive will be extended so you can choose which string type
you need per unit. (ansi/wide/utf16/utf8...)
This is different from Delphi, where you don't have th
On Saturday 22 December 2012 15:45:13 Michael Van Canneyt wrote:
> On Sat, 22 Dec 2012, Martin Schreiber wrote:
> > UnicodeString or codepage aware cpstrnew?
>
> 'codepage aware' just means that you can specify a charsize/codepage.
> A unicode string is just one type of codepage aware string.
> (u
22.12.12, 22:58, Martin Schreiber пишет:
That was so in the beginning but Delphi later changed it. So a Delphi
UnicodeString variable currently allways is utf-16 encoded.
The same in FPC.
Best regards,
Paul Ishenin
___
fpc-pascal maillist - fpc-p
Em 22/12/2012 09:55, "Michael Van Canneyt"
escreveu:
>
>
>
> Because of the requirement for backwards compatibility with FPC itself,
we'll make 2 RTLs: one backwards compatible, one with the new unicode
string.
>
It will be possible to compile a utf8 rtl?
There will be a RtlString ?
Luiz
>
> _
On 22-12-2012 12:55, Michael Van Canneyt wrote:
> On Sat, 22 Dec 2012, dev.dliw-re5jqeeqqe8avxtiumw...@public.gmane.org
> wrote:
>
>> Hi,
>> concerning the string topic, for me (using fpc since 2.0.4 on a
>> regular basis;
>> TP experience ~ average user) there really should be an decision what
>>
On Sat, 22 Dec 2012, luiz americo pereira camara wrote:
Em 22/12/2012 09:55, "Michael Van Canneyt" escreveu:
>
>
>
> Because of the requirement for backwards compatibility with FPC itself, we'll
make 2 RTLs: one backwards compatible, one with the new unicode string.
>
It will be possible
In our previous episode, Michael Van Canneyt said:
> - The {$H } directive will be extended so you can choose which string type
> you need per unit.
>(ansi/wide/utf16/utf8...)
>This is different from Delphi, where you don't have this choice:
> String=Widestring.
unicodestring, actually
In our previous episode, dev.d...@gmail.com said:
> Users can define the internal type with e.g. {$STRING UTF8} for their *whole*
> project.
This is technically impossible. Both FPC and Lazarus don't have a complete
overview of all units and includefiles in a project, and compiles can also
be par
On Sat, 22 Dec 2012, Reinier Olislagers wrote:
On 22-12-2012 12:55, Michael Van Canneyt wrote:
On Sat, 22 Dec 2012, dev.dliw-re5jqeeqqe8avxtiumw...@public.gmane.org
wrote:
Hi,
concerning the string topic, for me (using fpc since 2.0.4 on a
regular basis;
TP experience ~ average user) there
On Sat, 22 Dec 2012, Marco van de Voort wrote:
In our previous episode, dev.d...@gmail.com said:
Users can define the internal type with e.g. {$STRING UTF8} for their *whole*
project.
This is technically impossible. Both FPC and Lazarus don't have a complete
overview of all units and includ
On 22-12-2012 17:50, Michael Van Canneyt wrote:
>
>
> On Sat, 22 Dec 2012, Reinier Olislagers wrote:
>
>> On 22-12-2012 12:55, Michael Van Canneyt wrote:
>>> On Sat, 22 Dec 2012, dev.dliw-re5jqeeqqe8avxtiumw...@public.gmane.org
>>> wrote:
>>>
Hi,
concerning the string topic, for me (us
On Sat, 22 Dec 2012, Reinier Olislagers wrote:
On 22-12-2012 17:50, Michael Van Canneyt wrote:
On Sat, 22 Dec 2012, Reinier Olislagers wrote:
On 22-12-2012 12:55, Michael Van Canneyt wrote:
On Sat, 22 Dec 2012, dev.dliw-re5jqeeqqe8avxtiumw...@public.gmane.org
wrote:
Hi,
concerning the
In our previous episode, Michael Van Canneyt said:
> >
> > Rule of thumb: anything global must be passed on the cmdline everytime, and
> > directives are only for unit level. (a few special ones for library units
> > like $libsuffix excluded)
>
> While this is correct, I think it is possible to co
Can somebody please lend me a hand making three sets of calls to (I
think) ibase60dyn.pp please. I've written functions to make and poll
asynchronous notifications for PostgreSQL, but I need the corresponding
code for Firebird.
If somebody could point me at (Pascal) examples I'd appreciate it,
On 22-12-2012 19:00, Mark Morgan Lloyd wrote:
> Can somebody please lend me a hand making three sets of calls to (I
> think) ibase60dyn.pp please. I've written functions to make and poll
> asynchronous notifications for PostgreSQL, but I need the corresponding
> code for Firebird.
>
> If somebody
On 22-12-2012 18:07, Michael Van Canneyt wrote:
> On Sat, 22 Dec 2012, Reinier Olislagers wrote:
>> On 22-12-2012 17:50, Michael Van Canneyt wrote:
>>> On Sat, 22 Dec 2012, Reinier Olislagers wrote:
On 22-12-2012 12:55, Michael Van Canneyt wrote:
> On Sat, 22 Dec 2012, dev.dliw-re5jqeeqqe8
Reinier Olislagers wrote:
On 22-12-2012 19:00, Mark Morgan Lloyd wrote:
Can somebody please lend me a hand making three sets of calls to (I
think) ibase60dyn.pp please. I've written functions to make and poll
asynchronous notifications for PostgreSQL, but I need the corresponding
code for Firebi
On Saturday 22 December 2012 19:00:14 Mark Morgan Lloyd wrote:
> Can somebody please lend me a hand making three sets of calls to (I
> think) ibase60dyn.pp please. I've written functions to make and poll
> asynchronous notifications for PostgreSQL, but I need the corresponding
> code for Firebird.
Martin Schreiber wrote:
MSEgui has code for Firebird and PostgreSQL server notifications.
http://gitorious.org/mseide-msegui/mseide-msegui/trees/master/lib/common/db
Low level code is in mpqconnection.pp and mibconnection.pas, backend
independent code in msedbevents.pas.
Thanks. I must say t
Hi,
that's great news...
Thanks for the effort to clarify,
d.l.i.w
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
30 matches
Mail list logo
