On 27 Nov 2014, at 17:11, Hans-Peter Diettrich drdiettri...@aol.com wrote:
Such statements come only from writers that do not believe that their words
can be understood in various ways ;-)
I'm sorry, but I simply cannot discuss with people that, when I literally state
the result is
In our previous episode, Hans-Peter Diettrich said:
While it certainly is a stupid (Microsoft) idea to use UTF-16 for file
storage, we'll have to take that into account.
(16-bit codepages were designed into OS/2 and Windows NT before utf-8 even
existed)
On 11/27/2014 03:44 PM, Hans-Peter Diettrich wrote:
The universal paradigm would allow for extensions (e.g. UTF-32,
multiple 16 Bit Code pages, an additional fully dynamic String type,
n-byte un-encoded string types), as I described in the Wiki page.
Even if feasable, such arbitrary string
On 11/27/2014 07:29 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
E.g. there are (are least two Code pages for UTF-16 (LE, and
BE), that would be worth supporting.
You are confusing codepages and encodings :-(
That is why I put goose-feet around Code pages. I used this wording
Looking on the internet for DirectShow Pascal bindings, I came across
http://code.google.com/p/dspack/source/browse/#svn%2Ftrunk%2Fsrc%2FDirectX9. With a few
modifications, this does compile with fpc-2.6.4, e.g.
adriaan% fpc -MDelphi -Twin32 DirectShow9.pas
Free Pascal Compiler version 2.6.4
Am 28.11.2014 16:25 schrieb Adriaan van Os f...@microbizz.nl:
Looking on the internet for DirectShow Pascal bindings, I came across
http://code.google.com/p/dspack/source/browse/#svn%2Ftrunk%2Fsrc%2FDirectX9.
With a few modifications, this does compile with fpc-2.6.4, e.g.
adriaan% fpc
Sven Barth wrote:
Is there a fixed policy to include packages like these with FPC (or
not) ? The license is Mozilla Public License 1.1.
The policy is that we'd like to reduce the amount of packages we ship
with FPC directly. For this there is a package repository which can be
accessed
Am 28.11.2014 17:52 schrieb Adriaan van Os f...@microbizz.nl:
Sven Barth wrote:
Is there a fixed policy to include packages like these with FPC (or
not) ? The license is Mozilla Public License 1.1.
The policy is that we'd like to reduce the amount of packages we ship
with FPC directly. For
In response to another thread (this should start an new thread):
CP_NONE: this value indicates that no code page information has been
associated with the string data. The result of any explicit or implicit
operation that converts this data to another code page is undefined.
After rereading I
Jonas Maebe schrieb:
I'm sorry, but I simply cannot discuss with people that, when I
literally state the result is undefined, think that I may actually
have meant the result is defined and if you change the
implementation and/or keep it stable across compiler releases, then
it will also conform
Michael Schnell schrieb:
I fear that there will be code that relies on the flawed behavior of
RawByteString (it's a feature, not a bug) and using the same name with
different behavior would brake same. And a really usable DynmicString
would not adhere to that description.
How can somebody
Michael Schnell schrieb:
On 11/27/2014 03:44 PM, Hans-Peter Diettrich wrote:
An *efficient* implementation would be based on a single program-wide
string representation, with different encodings being handled only in
an exchange with external data sources.
Yep. But it would result in severe
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
While it certainly is a stupid (Microsoft) idea to use UTF-16 for file
storage, we'll have to take that into account.
(16-bit codepages were designed into OS/2 and Windows NT before utf-8 even
existed)
Right,
On 28/11/14 21:30, Hans-Peter Diettrich wrote:
I prefer to specify and document everything *before* coding, so that
everybody can expect that the code will behave as specified.
If certain behaviour is explicitly undefined, it *is* specified and
documented. It means that your program is buggy if
14 matches
Mail list logo
