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 do
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 s
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 si
On Mon, Feb 1, 2010 at 11:01 AM, Marco van de Voort 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 simply call Ansi fu
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 f
On Mon, Feb 1, 2010 at 11:31 AM, Marco van de Voort wrote:
> Which requires libc, and *nix supports UTF-8 directly.
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
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/
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 mail
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 u
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 expre
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 conver
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 strin
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
r
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 neith
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) .
Dani
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 fin
On Mon, Feb 1, 2010 at 11:09 AM, Graeme Geldenhuys
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
> standard RTL functio
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 eac
On Mon, Feb 1, 2010 at 3:20 PM, Marco van de Voort 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
UnicodeFileUtils;
function Fi
In our previous episode, dmitry boyarintsev said:
> On Mon, Feb 1, 2010 at 3:20 PM, Marco van de Voort 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 provid
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 (any
Mark Morgan Lloyd wrote:
Jonas Maebe wrote:
On 05 Oct 2009, at 15:27, Mark Morgan Lloyd wrote:
The fp IDE can drive libgdb to do straightforward debugging on x86
and ARM, there might be failures with complex stuff that I've not
been able to test. Those two platforms are no problem, the proble
25 matches
Mail list logo
