On Tue, Jul 5, 2011 at 12:39 PM, Miklos Cserzo
wrote:
> fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the
> missing package?
>
> "fp: error while loading shared libraries: libtinfo.so.5: cannot open shared
> object file: No such file or directory"
I have rebuild fpc 2.4.2
On Tue, Jul 5, 2011 at 12:39 PM, Miklos Cserzo
wrote:
> fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the
> missing package?
>
> "fp: error while loading shared libraries: libtinfo.so.5: cannot open shared
> object file: No such file or directory"
This is a library named d
On 05 Jul 2011, at 22:38, Mark Morgan Lloyd wrote:
> Miklos Cserzo wrote:
>> Hi Folks,
>> fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the
>> missing package?
>> "fp: error while loading shared libraries: libtinfo.so.5: cannot open shared
>> object file: No such file or
Miklos Cserzo wrote:
Hi Folks,
fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of
the missing package?
"fp: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory"
Since nobody else has answered: Google suggests tha
On 05/07/2011 19:28, Alexander Klenin wrote:
On Wed, Jul 6, 2011 at 05:12, Martin wrote:
TStringList could be made save, and keep the const. Just add additonal
references where needed.
Agreed with your analysis. This still feels like a wrong design to me
-- spreading complexity
It's the wron
On Wed, Jul 6, 2011 at 05:12, Martin wrote:
> TStringList could be made save, and keep the const. Just add additonal
> references where needed.
Agreed with your analysis. This still feels like a wrong design to me
-- spreading complexity
all over the place (all the libaries) instead of concenctra
On 05/07/2011 18:56, Alexander Klenin wrote:
On Wed, Jul 6, 2011 at 03:44, Jonas Maebe wrote:
2) All such incorrect usage should be removed from LCL and FCL
(for example: event handlers in LCL and TStrings methods in FCL).
Well, then the situation is hopeless ;-)
TStringList could be made sa
On Wed, Jul 6, 2011 at 03:44, Jonas Maebe wrote:
> 2) All such incorrect usage should be removed from LCL and FCL
> (for example: event handlers in LCL and TStrings methods in FCL).
Well, then the situation is hopeless ;-)
Note that the only reason TString/TStringList does not break too often is
On 05/07/2011 18:27, José Mejuto wrote:
This changes should be detected ?
var
a: ansistring;
procedure DoSomehting(const v: ansistring);
begin
a[1]:='a';
end;
begin
a:='b';
DoSomething(a);
end.
It would probably best to detect this changes too.
But since it would be more of a pe
On 05/07/2011 17:27, Alexander Klenin wrote:
Lazarus teams now have many bugs to fix;-)
for the LCL we know. Though it isn't sure yet if it is so many.
Finding one of them in the LCL, was actually what started the discussion
___
fpc-devel mai
Hello FPC,
Tuesday, July 5, 2011, 6:44:24 PM, you wrote:
JM> Since the behaviour of "const" for automated types is
JM> explicitly defined by Borland as not causing any changes in
JM> reference counting (see the note at the bottom of
JM> http://docwiki.embarcadero.com/RADStudio/en/Using_Reference_
On Tue, 5 Jul 2011, Jonas Maebe wrote:
On 05 Jul 2011, at 18:27, Alexander Klenin wrote:
2) All such incorrect usage should be removed from LCL and FCL
(for example: event handlers in LCL and TStrings methods in FCL).
Changing TStrings like that would break the compilation of any code tha
On 05 Jul 2011, at 18:27, Alexander Klenin wrote:
> 2) All such incorrect usage should be removed from LCL and FCL
> (for example: event handlers in LCL and TStrings methods in FCL).
Changing TStrings like that would break the compilation of any code that
overrides its methods (since they also
On Wed, Jul 6, 2011 at 02:41, Martin wrote:
> On 05/07/2011 16:28, Florian Klaempfl wrote:
>>
>> As written in some of the bug reports, I consider as a better solution:
>> - Pointer checking of constant parameters of types like ansistrings,
>> interfaces at procedure exit. Together with heaptrc an
cobines schrieb:
procedure mclass.dot(const s: string);
Here you know that you cannot modify 's'. But you may not know that
you cannot also change mclass.ftext variable, which actually 's'
points to because apparently someone called
mclass.dot(mclass.fsometext).
You *can* change mclass.ftext,
On Tue, Jul 5, 2011 at 22:51, Martin wrote:
> I think you misunderstood me. There is a (or there may be) a bug. But
> *not* in the compiler, and *not* in the implementation of "const string".
> I explicitly pointet that out on the top of the quotation "I don't think it
> is a bug." (with referen
On 05/07/2011 16:28, Florian Klaempfl wrote:
As written in some of the bug reports, I consider as a better solution:
- Pointer checking of constant parameters of types like ansistrings,
interfaces at procedure exit. Together with heaptrc and keep_released
enabled, this catches all cases of dispos
Am 04.07.2011 22:39, schrieb Chad Berchek:
> I've been reading over some of the recent discussion about reference
> counting problems with const string parameters. I've done some
> experiments and I believe that the so-called const optimization is a
> serious flaw, not just a corner case of questio
2011/7/5 :
> You can always fool the compiler. The compiler trusts you and assumes that
> what you tell her is true, namely, that the called code will not modify the
> const parameter (in the case of an ansistring: a pointer). That's it. Based
> on this she may or may not perform some optimization
Thaddy schrieb:
That is also part of the speed optimization: the compiler doesn't have
to check because of this contract.
More important: the compiler can omit try-finally sections, otherwise
required for safe refcounting of non-const strings.
DoDi
_
On Tue, Jul 5, 2011 at 1:04 PM, Thaddy wrote:
> On 5-7-2011 12:34, Felipe Monteiro de Carvalho wrote:
>>
>> Maybe the compiler should start issuing hints or warnings for all
>> places where one uses const with ansistring, so that people who don't
>> care about the speed advantage can start removin
On 05/07/2011 11:24, michael.vancann...@wisa.be wrote:
On Tue, 5 Jul 2011, Martin wrote:
On 05/07/2011 04:02, Chad Berchek wrote:
Martin wrote:
I don't think it is a bug.
...
"(const s: string)" is a declaration by the programmer, that the
variable (the string) will not be modified at al
michael.vancann...@wisa.be schrieb:
On Tue, 5 Jul 2011, Martin wrote:
On 05/07/2011 04:02, Chad Berchek wrote:
Martin wrote:
I don't think it is a bug.
...
"(const s: string)" is a declaration by the programmer, that the
variable (the string) will not be modified at all. That is neither b
On 5-7-2011 12:34, Felipe Monteiro de Carvalho wrote:
Maybe the compiler should start issuing hints or warnings for all
places where one uses const with ansistring, so that people who don't
care about the speed advantage can start removing those const
ansistrings from their code base.
Yes, but i
Hi Folks,
fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of
the missing package?
"fp: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory"
Cheers,
miklos
___
fpc-de
Maybe the compiler should start issuing hints or warnings for all
places where one uses const with ansistring, so that people who don't
care about the speed advantage can start removing those const
ansistrings from their code base.
--
Felipe Monteiro de Carvalho
__
On Tue, 5 Jul 2011, Martin wrote:
On 05/07/2011 04:02, Chad Berchek wrote:
Martin wrote:
I don't think it is a bug.
...
"(const s: string)" is a declaration by the programmer, that the
variable (the string) will not be modified at all. That is neither by
the procedure called, nor by any c
On 05/07/2011 04:02, Chad Berchek wrote:
Martin wrote:
I don't think it is a bug.
...
"(const s: string)" is a declaration by the programmer, that the
variable (the string) will not be modified at all. That is neither by
the procedure called, nor by any code outside the procedure, via any
oth
> Am 04.07.2011 17:42, schrieb Ludo Brands:
> > Just spent an hour debugging a runtime error 217. No
> information just
> > runtime error 217, compilation aborted under lazarus and with
> > lazbuild. Rebuild fpc with debug information and ran the
> "offending"
> > compile command from the co
29 matches
Mail list logo
