Re: [fpc-pascal] Documentation
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/fpc-pascal
[fpc-pascal] Strings - suggestions
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 unfortunately studies take all my time - at
least for one more year - but time will come... :D ]
Nonetheless I would like to make a suggestion:
1.
Make a general String type, with no statement what the internal structure is
like.
Users can define the internal type with e.g. {$STRING UTF8} for their *whole*
project. On compilation now the defined type is used and there should be no
problems as long as the source code does not make any assumptions, what the
internal structure looks like and uses a general string unit (e.g. Sysutils).
External libraries (no source) define their string type accordingly in their
import header [sorry :) ] for their scope, strings are converted based on
this information, if necessary.
If you make it possible for users to define their own string unit (as
override of the general one), many string types are possible.
To clarify (an example; the main program file, not a unit):
...
{$STRING *user defined*}
{$USESTRINGUNIT *some user unit which implements all string ops for the own
string implementation*}
...
The advantage is, that anything compiled from source within a project
(external libraries, too) uses the user defined (=preferred) string type and
no conversion is needed (assuming there is no direct string access, which
should be good programming style nowadays).
[You see, I'm not a friend of the idea, that a string itself contains the
information about its internal type...]
2.
With this design (and most users never thinking about their own string type)
there still should be a defaul fpc string type. This is at least necessary for
string conversions. Any custom string type *must* provide a function to
convert to and from the default fpc string type, but *may* also provide such
to/from other string types.
Now any string can be (automatically) converted to any other, in the worst
case like this:
*user defined* - fpc default - *any other, maybe Ansistring*
There is still the problem, that conversions should be lossless, so the
default string type must be able to handle any character [but that should
obviously be possible anyway]...
... and I really hope that explicit conversions won't be necessary in future
(have I to use GetFilenameUTF8 or GetFilname or ...?? - you know)...
I can't say how much work this would be to implement, but in my eyes a more
complex but flexible solution should be worth it, thats not something you
change everyday...
... with {$STRING ANSI} it would work for any old project, so no problems in
backwards compatibility, although IMO a cut in compatability for the new
string type (supported defines, etc.) - if its necessary and makes things
cleaner - is definitely no problem and even the way to go...
3.
Now, what string type to use as default?
No suggestion from my side, but an suggestion how to quickly and
constructively find the right one.
Make a wiki page e.g. new string type suggestions where within a certain
time, everyone can describe his preferred string type, the best would be a
table with pros/cons...
... the core devs than can decide based on this.
[Basically summarized info of all the posts floating around in the mailing
list]
- So, don't waste your energy one more time, to fight each other in response
to this post, just fill the wiki page :)
[IMHO nobody will ever read all the postings about strings in the mailing
list, there *must* be a summarized overview somewhere]
[Sorry if this wiki page already exists...]
And a last thought from my side:
Please, don't try to stay Delphi compatible no matter what.
IMHO its time for fpc to move forward, not sticking to any (bad) Delphi design
change. Even now its almost impossible to use (modern) Delphi code 1:1 in
fpc, and it certainly won't be better in future. It would be much better to
define a last almost supported Delphi version and then go an own way.
Fpc (and Lazarus even more) shouldn't be reduced to make any Delphi(!)
project crossplatform - and doing the difficult (not to say dirty) work for
Embarcadero to make a Windows-oriented design work on many platforms - it
should be an independant implementation of ObjectPascal (and not Delphi!), in
the optimal case being compatible to Delphi, as long as its possible and makes
sense...
With the above suggestion, it would be even possible to make an own Delphi
compatible string type for Delphi mode.
- And, if the Delphi design really is superior to any other - then lets use it
(unfortunately its not).
Uff, a long post, hopefully at least a little helpful - and constructive.
Certainly many wait for the final decision (including me) - let's hope it will
come in near future... :D
Regards,
d.l.i.w
Re: [fpc-pascal] Strings - suggestions
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)?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 string type, as Delphi
has.
(well, it is there already).
- 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.
- The necessary conversions will be inserted by the compiler.
(in fact, they are there already)
- Supplying the type on the command-line will make it the project default.
We can think about a directive that can be specified in a project file.
Because of the requirement for backwards compatibility with FPC itself,
we'll make 2 RTLs: one backwards compatible, one with the new unicode string.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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
course does only work with {$STRING ANSI} to stay in my example.
Btw.
and uses a general string unit (e.g. Sysutils).
should be (e.g. strutils) :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 the new unicode string. Do you mean really seperated sources or a comiler switch? What's the problem to use the new RTL with Ansistring? I can't see a problem, if it doesn't use direct string access... ... of course you have to compile it accordingly.. so you can choose which string type you need per unit Can a project wide choice override this for *any* unit (3rd party) or will there be conversion going on between the different units? d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 make 2 RTLs: one backwards compatible, one with the new unicode string. Do you mean really seperated sources or a comiler switch? A bit of both :-) What's the problem to use the new RTL with Ansistring? I can't see a problem, if it doesn't use direct string access... For obvious reasons, the RTL uses direct string memory access in many places. ... of course you have to compile it accordingly.. You can use ansistring, no problem. The problem are classes. If I define TComponent = Class(TPersistent) Published Property Name : String; end; Then name will be of the string type as declared in the unit where TComponent is defined. For properties this is not so much of a problem but if you try to override something like Procedure(Arg : String); virtual; Then the string type must match the original string type as in the original declaration, no matter what the string type in your particular unit. so you can choose which string type you need per unit Can a project wide choice override this for *any* unit (3rd party) or will there be conversion going on between the different units? There will always be conversion if 1) a unit specifies a string type by itself. 2) the unit comes in compiled form. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 fpc default type? In other words, can I force *all* sources in my project to use the same string type, provided that I know, they don't do direct access? The wiki says [http://wiki.freepascal.org/FPC_Unicode_support], that - shortstring - ansistring - widestring - utf8string - utf16string - utf32string - ucs2string (?) - ucs4string (?) may be supported. So in future I will be able to define any of these for my source (and switch between them), without changing code? Thus: Any function with string as param will be automatically overloaded for all supported string types? d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 is used: (a) the type defined in project, (b) a fpc default type? That depends. See below. In other words, can I force *all* sources in my project to use the same string type, provided that I know, they don't do direct access? Yes, *if* the units are recompiled. The wiki says [http://wiki.freepascal.org/FPC_Unicode_support], that - shortstring - ansistring - widestring - utf8string - utf16string - utf32string - ucs2string (?) - ucs4string (?) may be supported. They will just be pre-defined string types. So in future I will be able to define any of these for my source (and switch between them), without changing code? Thus: Any function with string as param will be automatically overloaded for all supported string types? Provided a) you recompile everything b) The unit does not specify a string type the answer seems yes. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 mean String = UnicodeString = reference counted utf-16 encoded 16
bit string?
Because of the requirement for backwards compatibility with FPC itself,
we'll make 2 RTLs: one backwards compatible, one with the new unicode
string.
UnicodeString or codepage aware cpstrnew?
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 this choice:
String=Widestring.
You probably mean String = UnicodeString = reference counted utf-16 encoded 16
bit string?
Yes.
Because of the requirement for backwards compatibility with FPC itself,
we'll make 2 RTLs: one backwards compatible, one with the new unicode
string.
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.
(unless the compiler guys now tell me otherwise).
So, string will mean Unicode string.
The effect is that
TComponent.Name
etc. will be a unicode string.
In the backwards compatible RTL,
TComponent.Name
will be an ansistring, i.e. as it is now.
Michael.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
Em 22/12/2012 09:55, Michael Van Canneyt mich...@freepascal.org 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Strings - suggestions
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
way to
go as early as possible.
- We'll implement the capacity to have a code-page aware string type, as
Delphi has.
(well, it is there already).
- 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.
So how would the patch in e.g.
http://bugs.freepascal.org/view.php?id=22095
fit in?
That uses widestrings to support non-ASCII characters for ODBC and
should be in the fcl-db.
I suppose chosing any string type that is convenient in various fcl
units could lead to a lot of useless conversions.
How will this be avoided?
- The necessary conversions will be inserted by the compiler.
(in fact, they are there already)
- Supplying the type on the command-line will make it the project default.
We can think about a directive that can be specified in a project file.
Because of the requirement for backwards compatibility with FPC itself,
we'll make 2 RTLs: one backwards compatible, one with the new unicode
string.
Thanks,
Reinier
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
On Sat, 22 Dec 2012, luiz americo pereira camara wrote: Em 22/12/2012 09:55, Michael Van Canneyt mich...@freepascal.org 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? No. There will be a RtlString ? No. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 parts of program.
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)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Strings - suggestions
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 really should be an decision what
way to
go as early as possible.
- We'll implement the capacity to have a code-page aware string type, as
Delphi has.
(well, it is there already).
- 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.
So how would the patch in e.g.
http://bugs.freepascal.org/view.php?id=22095
fit in?
That uses widestrings to support non-ASCII characters for ODBC and
should be in the fcl-db.
I suppose chosing any string type that is convenient in various fcl
units could lead to a lot of useless conversions.
How will this be avoided?
That remains to be seen.
I suspect that we'll add a .AsAnsiString version to TField, in addition to
.AsWideString, and add a field type: ftAnsiString.
The low-level dataset driver will have to decide what to do with data coming in:
- AnsiString
- WideString
The .AsString will then pick the one that corresponds to the type of RTL.
ftString will be an alias to ftAnsiString or ftWideString, depending on the RTL.
This is different from what Delphi does, which simply says that
.AsString is now equal to .asWideString.
This way, you can decide what to do if you have a Unicode RTL:
Use .AsString and go with the conversions in case of unicode RTL.
Use .AsAnsiString and use ansistring if you know the database has ansi data.
Use .AsWideString.
But that remains still all to be decided.
Like I said: Trunk will most likely become rather unstable once we get started
:-)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 includefiles in a project, and compiles can also
be parts of program.
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 construct a (new) directive that
can be inserted in a program/library file only, and which will have the same
effect as the command-line argument: for all units that will be compiled as
part of the normal run, the string type is set.
Whether or not this is desirable, is another matter.
(personally, I think we have enough with the command-line version)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Strings - suggestions
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 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 string type, as
Delphi has.
(well, it is there already).
- 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.
So how would the patch in e.g.
http://bugs.freepascal.org/view.php?id=22095
fit in?
That uses widestrings to support non-ASCII characters for ODBC and
should be in the fcl-db.
I suppose chosing any string type that is convenient in various fcl
units could lead to a lot of useless conversions.
How will this be avoided?
That remains to be seen.
Thanks, I've updated
http://wiki.lazarus.freepascal.org/FPC_Unicode_support
Maybe a bit premature.
Tomorrow I may decide to change my mind, depending on how well I slept after watching
The hobbit ;)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 construct a (new) directive that can be inserted in a program/library file only, and which will have the same effect as the command-line argument: for all units that will be compiled as part of the normal run, the string type is set. Whether or not this is desirable, is another matter. Exactly. In theory you can lift a directive to global state for that compiler invocation (as done with linker related switches atm) But it can cause so much confusion (e..g other project that uses partially the same units) that it causes more problems than it solves. During the unicode discussions I thought about this, and even thought of a mitigation (though not complete solution) of that problem: 1. if such directive is in a normal unit, mark the PPU as such. 2. if such a PPU is loaded, make it global. 3. if that causes a conflict (multiple such units with different directives), abort. This way putting some directive in an unit that is at the top of the dependency graph will cause it to quickly pull it in on independent compiles. It mainly fixes the case where one users generally uses only one style. It does require some restraint though, which I think the solution is only theoretical. So either go to a mandatory project system (but not even Delphi does that), or not. This will also allow to throw errors when using an unit not compiled with the same project file etc. Delphi seems to go in that direction though, I found it is hard to quickly compile FPC programs on the cmdline with XE3, since then it misses the namespace prefixes and complains it can't find sysutils because it wants system.sysutils. There are backwards compat aliases (actualy, already since D7, and the winprocs,wintypes unit aliases are even older), but with XE3 they are less (personally, I think we have enough with the command-line version) Yes. And even if not, I would go for a mandatory project file, not in source. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Accessing low-level Firebird facilities
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, otherwise I could post my existing fragments here if somebody was prepared to look at them and tell me what needs changing. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Accessing low-level Firebird facilities
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 could point me at (Pascal) examples I'd appreciate it, otherwise I could post my existing fragments here if somebody was prepared to look at them and tell me what needs changing. Perhaps the fb events code Ludo Brands wrote could be useful? - Example code: packages\fcl-db\examples\fbeventstest.pp - The source packages\fcl-db\src\sqldb\interbase\fbeventmonitor.pp - the equivalent for PostgreSQL: packages\fcl-db\src\sqldb\postgres\pqeventmonitor.pp Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Strings - suggestions
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-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: So how would the patch in e.g. http://bugs.freepascal.org/view.php?id=22095 fit in? That uses widestrings to support non-ASCII characters for ODBC and should be in the fcl-db. I suppose chosing any string type that is convenient in various fcl units could lead to a lot of useless conversions. How will this be avoided? That remains to be seen. Thanks, I've updated http://wiki.lazarus.freepascal.org/FPC_Unicode_support Maybe a bit premature. I don't think so - I quoted your mail selectively - was just interested in final decisions ;) Have fun tonight! Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Accessing low-level Firebird facilities
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 Firebird. If somebody could point me at (Pascal) examples I'd appreciate it, otherwise I could post my existing fragments here if somebody was prepared to look at them and tell me what needs changing. Perhaps the fb events code Ludo Brands wrote could be useful? - Example code: packages\fcl-db\examples\fbeventstest.pp - The source packages\fcl-db\src\sqldb\interbase\fbeventmonitor.pp - the equivalent for PostgreSQL: packages\fcl-db\src\sqldb\postgres\pqeventmonitor.pp Thanks Reinier, I'll dig into that later (I might be back). What I'm trying to do is use PostgreSQL as the primary backend for something, but allow for Firebird as a local cache since it's generally considered to be a bit lighter-weight. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Accessing low-level Firebird facilities
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. If somebody could point me at (Pascal) examples I'd appreciate it, otherwise I could post my existing fragments here if somebody was prepared to look at them and tell me what needs changing. 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. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Accessing low-level Firebird facilities
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 that Firebird appears to make extremely heavy going of this when compared with Postgres. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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
