In our previous episode, dmitry boyarintsev said:
Any hints on these bugs?
http://bugs.freepascal.org/view.php?id=12923
http://bugs.freepascal.org/view.php?id=15642 // patch proposed to
workaround RTL limitation in LCL
This is mostly concern of Windows OS. Moders Unix doesn't have the
Il 01/02/2010 08:58, Paul Ishenin ha scritto:
01.02.2010 14:50, Giulio Bernardi wrote:
The reason is explained in this log message (2008-01-10):
* .res files must be copied to units output folder, otherwise .res files
will not be found when only compiled units path is available and
compiler
In our previous episode, Paul Ishenin said:
The reason is explained in this log message (2008-01-10):
* .res files must be copied to units output folder, otherwise .res files
will not be found when only compiled units path is available and
compiler does not know anything about sources
01.02.2010 15:03, Marco van de Voort wrote:
Yes, but it might not have the source (src/) directory later for the next
compile,
only the output dir.(units/$FPCTARGET)
For the later compile it has .or file which has all lfm and res merged
together.
Best regards,
Paul Ishenin.
dmitry boyarintsev wrote:
Would it be possible to fix the problem in RTL? by adding
UnicodeString (WideString) version of file operation functions?
Until the cpstrnew branch in FPC is complete, I guess the answer is No.
Alternatively you can introduce helper RTL functions. We have done
On Mon, Feb 1, 2010 at 11:01 AM, Marco van de Voort mar...@stack.nl wrote:
What would you do on Unix? Any solution must be platform-wide.
I'm not talking about removing Ansi functions. I'm talking about the
possibility of adding Unicode function equivalents.
For Unix unicode functions would
In our previous episode, dmitry boyarintsev said:
What would you do on Unix? Any solution must be platform-wide.
I'm not talking about removing Ansi functions. I'm talking about the
possibility of adding Unicode function equivalents.
For Unix unicode functions would simply call Ansi
In our previous episode, dmitry boyarintsev said:
Now, i see, the technical solution is not easy.
The point is more or less to come up with some logical system, not just
random additions when something is missing.
FPC will be forced to catch-up with D2009, anyway.
Yes, but D2009/d2010
On 02/01/2010 09:46 AM, Marco van de Voort wrote:
D2009/d2010 are still windows only.
Do you think there is any general problem in using D2009 strings with
dynamic encoding with Unix ? On the first view I don't see one.
-Michael
___
fpc-devel
In our previous episode, Michael Schnell said:
D2009/d2010 are still windows only.
Do you think there is any general problem in using D2009 strings with
dynamic encoding with Unix ? On the first view I don't see one.
In general I prefer to use each platform using its native encoding.
Op Mon, 1 Feb 2010, schreef Marco van de Voort:
In our previous episode, Michael Schnell said:
D2009/d2010 are still windows only.
Do you think there is any general problem in using D2009 strings with
dynamic encoding with Unix ? On the first view I don't see one.
In general I prefer to
In our previous episode, Dani?l Mantione said:
Some commercial unices are also using utf-16 afaik, since they haven't
switched their TTY to UTF-8 yet. To be investigated.
I lean towards RTLString=utf8string; and RTLString=unicodestring on the
respective platforms, and then express the
On 02/01/2010 10:27 AM, Marco van de Voort wrote:
We are not Codegear, for which everything but Windows is an afterthought.
Right, But exactly this seems to ask for dynamically encoded strings
allowing to do the user code as agnostic of the system encoding as
possible while automatic
In our previous episode, Michael Schnell said:
Right, But exactly this seems to ask for dynamically encoded strings
allowing to do the user code as agnostic of the system encoding as
possible while automatic conversions are made whenever necessary, but
avoided whenever possible.
Both string
Op Mon, 1 Feb 2010, schreef Marco van de Voort:
In our previous episode, Dani?l Mantione said:
Some commercial unices are also using utf-16 afaik, since they haven't
switched their TTY to UTF-8 yet. To be investigated.
I lean towards RTLString=utf8string; and RTLString=unicodestring on the
On 02/01/2010 10:53 AM, Marco van de Voort wrote:
It makes sense to take the
encoding closest to the system, to at least allow minimal conversion
scenarios.
Of course !
If the RTL is done with dynamically encoded strings you would need to
take care that anything string value that neither
In our previous episode, Michael Schnell said:
I feel that the runtime performance overhead necessary for doing the RTL
with dynamically encoded strings is not too big, provided the RTL itself
does not force automatic conversions (e.g. by inappropriately encoded
string constants) .
Daniel
On 02/01/2010 12:26 PM, Marco van de Voort wrote:
Daniel touches the main problem. The string type is compiletime, while the
standard encoding is runtime.
I do see this (that is why I said If possible, even if I have no idea
about what impact this has.
Maybe it could be possible to find a
On Mon, Feb 1, 2010 at 11:09 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
Alternatively you can introduce helper RTL functions. We have done similar
in fpGUI project (fpg_utils.pas unit), having functions like
fpgFileExists(), fpgFindFirst(), fpgFindNext() etc. Use them instead of the
In our previous episode, dmitry boyarintsev said:
in fpGUI project (fpg_utils.pas unit), having functions like
fpgFileExists(), fpgFindFirst(), fpgFindNext() etc. Use them instead of the
standard RTL functions, and they will try and handle Unicode file system
access correctly on each
On Mon, Feb 1, 2010 at 3:20 PM, Marco van de Voort mar...@stack.nl wrote:
More importantly, the stuff in the FCL depends on the RTL, so stuffing in
the FCL is useless since it would need primitives in the RTL to operate on.
Does it mean, if i provide a FCL package with:
unit
Marco van de Voort schreef:
That is not my call, but I won't commit it. Because all this stuff must be
maintained when real solutions come later.
if Lazarus needs a quick fix, they should keep it in own SVN.
Or use the units from msegui or use the units from tiopf or use the
units from
22 matches
Mail list logo
