On 5/19/06, Пётр Косаревский <[EMAIL PROTECTED]> wrote:
Sorry, these two letters were accidentally sent personally.
To Felipe Monteiro de Carvalho:
> > probably Windows will become totally utf16 (not really unicode, but
> > at least utf16) really soon (at least in newer versions in a way
> > in
Hi all,
please let me ask a few questions about this "issue":
- why these are hints instead of warnings? (maybe because the code
isn't still show too many false positives?)
- why are they shown to AnsiStrings? Aren't all AnsiStrings always initialized?
- would/will you accept patches to fix FPC co
Op Fri, 19 May 2006, schreef Flávio Etrusco:
> Forgive me if I'm saying BS but it's been about 10 years since I
> programmed in TurboPascal (and used ShortStrings), but don't
> ShortStrings use the size they are declared with? And 255 is just
> default size (if no size is specified)?
Of course.
Op Fri, 19 May 2006, schreef Flávio Etrusco:
> > Free Pascal is Delphi compatible.
>
> I know that FPC aims to be Delphi-compatible, but it's not always the
> case, as e.g. the WideStrings were reference-counted until a couple of
> months ago.
> So you are saying that in this is specific case F
On 5/19/06, Daniël Mantione <[EMAIL PROTECTED]> wrote:
Op Thu, 18 May 2006, schreef Flávio Etrusco:
> > L> Dynamic arrays can be very handy and I never knew anyone who avoids
> > L> them. Of course if your array has fixed length there's no reason
> > L> to use a dynamic array either.
> > L> Fo
On 5/19/06, Daniël Mantione <[EMAIL PROTECTED]> wrote:
Op Fri, 19 May 2006, schreef Micha Nelissen:
> On Fri, 19 May 2006 18:29:29 +0100
> Peter Vreman <[EMAIL PROTECTED]> wrote:
>
> > There are already some complains about the memory usage. Increasing the
> > string size adds a lot more overh
Op Fri, 19 May 2006, schreef Micha Nelissen:
> On Fri, 19 May 2006 18:29:29 +0100
> Peter Vreman <[EMAIL PROTECTED]> wrote:
>
> > There are already some complains about the memory usage. Increasing the
> > string size adds a lot more overhead. Especially for all the small labels
> > like .L1
On Fri, 19 May 2006 18:29:29 +0100
Peter Vreman <[EMAIL PROTECTED]> wrote:
> There are already some complains about the memory usage. Increasing the
> string size adds a lot more overhead. Especially for all the small labels
> like .L1 etc. Already using longstrings will add 3 bytes for the leng
> That's one solution, that's not the only solution.
Very right. It is a trade-off. Do you fix the shortstring issue
and continue to get their benefits, or do you abandon them,
rewrite large parts of the compiler and pay the performance/memory
usage price?
There are already some complains abo
I think you guys may be living in a 255 cave, simply because that's all we
have to deal
with at this time. Some say that ansistrings might be the way to go using
sysutils -
personally I think sysutils has no place in the compiler core and the
compiler core should
have tight custom units with
Also assembler symbols/labels should get extended to strings > 255 in the
future because there is already a bug open in which it is demonstrated
that it is possible to create too long labels which makes a program
uncompilable.
Or some scheme derived which makes sure that labels never get lar
On 19 mei 2006, at 15:20, ik wrote:
When executing a program using TProcess, it seems that Output.read
does not return from the reading, until the execution of the process
is over.
The returning probably happens every 4KB of data or so (and once the
program has finished). The reason is that
Hi,
When executing a program using TProcess, it seems that Output.read
does not return from the reading, until the execution of the process
is over.
Is that something that suppose to happen ? If so, is there a non
blocking way that I can have the given data while the stream still
getting data (a
Sorry, these two letters were accidentally sent personally.
To Felipe Monteiro de Carvalho:
> > probably Windows will become totally utf16 (not really unicode, but
> > at least utf16) really soon (at least in newer versions in a way
> > incompatible with current ones).
>
> A small correction, ut
Vincent Snijders wrote:
Oro06 wrote:
even if poor/no communication was made about that,
it's important to see that one of the older
delphi third party vendor start supporting lazarus and fpc.
What third party vendor?
Vincent
http://www.steema.com/files/vcl/public/TeeChartPro7/Release.t
Oro06 wrote:
even if poor/no communication was made about that,
it's important to see that one of the older
delphi third party vendor start supporting lazarus and fpc.
What third party vendor?
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepa
even if poor/no communication was made about that,
it's important to see that one of the older
delphi third party vendor start supporting lazarus and fpc.
here what there is in v7 release note :
[...]
" - Support for Lazarus / FreePascal compiler."
[...]
who will be the next.
soon, a third pa
Op Thu, 18 May 2006, schreef Flávio Etrusco:
> > L> Dynamic arrays can be very handy and I never knew anyone who avoids
> > L> them. Of course if your array has fixed length there's no reason
> > L> to use a dynamic array either.
> > L> Fortunately it's no very often that one falls in Borland's
> Thanks to everybody that helped. I managed to setup 3 versions of FPC
> in my home directory and changed the fpc.cfg file to use the
> $fpcversion instead of a hardcoded version. All works perfectly.
>
> All these tips should be place in a FAQ or WIKI somewhere if it hasn't
> already!
http:/
Thanks to everybody that helped. I managed to setup 3 versions of FPC
in my home directory and changed the fpc.cfg file to use the
$fpcversion instead of a hardcoded version. All works perfectly.
All these tips should be place in a FAQ or WIKI somewhere if it hasn't already!
Regards,
- Graeme
> >
> > Simply install them in different directories. I often just use -n and use
> > -Fu on the command line to point the compiler to the right rtl. If this is
> > to uncomfortable, you can make the configuration file conditional, it
> > supports #ifdef constructions (check documentation).
> I
21 matches
Mail list logo
