Opitions are like that (defaults) - does not include -gh (no heap trace)
-MObjFPC -Scghi -O1 -g -gl -l -vewnhibq
-FiC:\codetyphon\typhonTemp\lib\i386-win32
-FUC:\codetyphon\typhonTemp\lib\i386-win32\ -FEC:\codetyphon\typhonTemp\
Note - this is first time that Typhon behave this was. Even, beta
On Fri, 11 Mar 2016, dinmil wrote:
program project1;
{$mode delphi}
uses
cmem,
Classes, SysUtils;
var
VBuffer: TBytes;
VStream: TStream;
begin
VStream := TBytesStream.Create;
try
VBuffer := TEncoding.UTF8.GetBytes('abc');
VStream.WriteBuffer(VBuffer[0], Length(VBuffer));
finally
program project1;
{$mode delphi}
uses
cmem,
Classes, SysUtils;
var
VBuffer: TBytes;
VStream: TStream;
begin
VStream := TBytesStream.Create;
try
VBuffer := TEncoding.UTF8.GetBytes('abc');
VStream.WriteBuffer(VBuffer[0], Length(VBuffer));
finally
VStream.Free;
end;
wri
On Tue, Mar 8, 2016 at 12:10 PM, Michael Van Canneyt wrote:
> On Tue, 8 Mar 2016, silvioprog wrote:
>
>> On Tue, Mar 8, 2016 at 9:29 AM, Bart wrote:
>>
>> On 3/8/16, silvioprog wrote:
>>>
>>> (my environment: Lazarus 1.7 rUnknown FPC 3.1.1 i386-win32-win32/win64)
>>>
>>> I can run simple L
On Tue, Mar 8, 2016 at 1:12 PM, Bart wrote:
> On 3/8/16, silvioprog wrote:
> > Can you test this attached program?
>
> Builds and runs fine, both 64 and 32 bit, inside and outside the debugger.
> Tested on Win7-64.
Strange. I got it on my Windows:
http://ctrlv.in/725499
http://ctrlv.in/72550
I use CodeTyphon for programming. New version have similar error.
CodeTyphon-570 use FreePascal 3.1.1 Source 02-03-2016 SVN Rev 33143 with
some modification by CT people.
For CT-570 I use solution like this.
Basically remove cmem when in debug mode. For production (without debug) use
cmem.
progra
On 3/8/16, silvioprog wrote:
> Can you test this attached program?
Builds and runs fine, both 64 and 32 bit, inside and outside the debugger.
Tested on Win7-64.
Bart
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.o
On Tue, 8 Mar 2016, silvioprog wrote:
On Tue, Mar 8, 2016 at 9:29 AM, Bart wrote:
On 3/8/16, silvioprog wrote:
(my environment: Lazarus 1.7 rUnknown FPC 3.1.1 i386-win32-win32/win64)
I can run simple Lazarus GUI program that uses CMem.
Lazarus 1.7 r51837 FPC 3.0.0 i386-win32-win32/win6
On Tue, Mar 8, 2016 at 9:48 AM, Michael Van Canneyt
wrote:
[...]
> Linux, 64 bit.
I'll check it on my Xubuntu ...
--
Silvio Clécio
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-p
On Tue, 8 Mar 2016, silvioprog wrote:
On Tue, Mar 8, 2016 at 8:42 AM, Michael Van Canneyt
wrote:
[...]
I tried that and the code runs fine on my system.
Linux?
(my environment: Lazarus 1.7 rUnknown FPC 3.1.1 i386-win32-win32/win64)
Linux, 64 bit.
Michael.
On 3/8/16, silvioprog wrote:
> (my environment: Lazarus 1.7 rUnknown FPC 3.1.1 i386-win32-win32/win64)
I can run simple Lazarus GUI program that uses CMem.
Lazarus 1.7 r51837 FPC 3.0.0 i386-win32-win32/win64.
(32-bit)
Bart
___
fpc-pascal maillist -
On Tue, Mar 8, 2016 at 8:42 AM, Michael Van Canneyt
wrote:
[...]
> I tried that and the code runs fine on my system.
Linux?
(my environment: Lazarus 1.7 rUnknown FPC 3.1.1 i386-win32-win32/win64)
--
Silvio Clécio
___
fpc-pascal maillist - fpc-pas
On Tue, 8 Mar 2016, silvioprog wrote:
On Tue, Mar 8, 2016 at 4:02 AM, Sven Barth
wrote:
[...]
*Always* put an alternate memory manager as the first unit. I think that
requirement is even documented somewhere...
Thanks for share this information.
Also don't use -gh with alternate memory
On Tue, Mar 8, 2016 at 5:54 AM, Michael Van Canneyt
wrote:
[...]
> First paragraph.
>
> http://freepascal.org/docs-html/current/rtl/cmem/index.html
This Sven explanation below should be added there too:
'Also don't use -gh with alternate memory managers. They are *both* memory
managers and thu
On Tue, Mar 8, 2016 at 4:02 AM, Sven Barth
wrote:
[...]
> *Always* put an alternate memory manager as the first unit. I think that
> requirement is even documented somewhere...
>
Thanks for share this information.
> Also don't use -gh with alternate memory managers. They are *both* memory
> mana
On Mon, Mar 7, 2016 at 10:09 PM, Bart wrote:
> On 3/8/16, silvioprog wrote:
> > I got an AV in the CMem unit. To reproduce the problem just compile and
> run
> > this code below:
> >
> > === code ===
> >
> > program project1;
> >
> > {$mode delphi}
> >
> > uses
> > Classes, SysUtils, cmem;
>
>
On Tue, 8 Mar 2016, Sven Barth wrote:
Am 08.03.2016 01:51 schrieb "silvioprog" :
Hello,
I got an AV in the CMem unit. To reproduce the problem just compile and
run this code below:
=== code ===
program project1;
{$mode delphi}
uses
Classes, SysUtils, cmem;
[Snip]
=== /code ===
Am 08.03.2016 01:51 schrieb "silvioprog" :
>
> Hello,
>
> I got an AV in the CMem unit. To reproduce the problem just compile and
run this code below:
>
> === code ===
>
> program project1;
>
> {$mode delphi}
>
> uses
> Classes, SysUtils, cmem;
>
[Snip]
> === /code ===
*Always* put an alternate
On 3/8/16, silvioprog wrote:
> I got an AV in the CMem unit. To reproduce the problem just compile and run
> this code below:
>
> === code ===
>
> program project1;
>
> {$mode delphi}
>
> uses
> Classes, SysUtils, cmem;
1. Shouldn't Cmem be the first unit in your program's uses clause?
2. Mayb
Hello,
I got an AV in the CMem unit. To reproduce the problem just compile and run
this code below:
=== code ===
program project1;
{$mode delphi}
uses
Classes, SysUtils, cmem;
var
VBuffer: TBytes;
VStream: TStream;
begin
VStream := TBytesStream.Create;
try
VBuffer := TEncoding.U
20 matches
Mail list logo
