> char[50000] tosho;
> tosho[0..5]="bobef";
> mtest~=tosho;

That's a big string. Note when you ~= to mtest the whole 50_000 characters in tosho are concatentated. That might explain why you are consuming so much memory so quickly. By why memory is getting corrupted? I don't know. Maybe the 50_000 char string on the stack is blowing your stack and you don't know it? Try reducing that number to, say, a dynamic array.

Adding/pasting/deleting characters is managed internaly by scintilla so it
should be ok and if is not it is not in the my scope of worry...
To see something you do the following: open an editor to see what are the normal
fonts then hold f7 for a sec or two then open new editor... tracing font names
when editor loads styles shows that strings are messed up (you will not see them
right now; if you wish to do so goto line 598 of editor.d and add
trace(v2.styles[c].font_face.ptr); this will show the string in the output
window)...
And I forgot something - to compile any project you need to uncomment few lines
at output.d line 820...

In article <opsn1hx8td23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Tue, 22 Mar 2005 11:43:38 +0000 (UTC), bobef <bobef_member@pathlink.com> wrote:
>> OK... I didn't wanted to post anything before I'm ready with first stage
>> of my
>> program (first stage i call a fully capable editor and workspace
>> manager, no
>> debuger, no itellisense), but looks like I'll have to do so...
>> So here is it. The function I posted in last message is app.d line 255
>> and
>> editor.d line 45. To compile anything it has to be uncommented and tests
>> removed. Also it is fully capable if building itself already but to build
>> anything else it requires some manual work on the new workspace file...
>> The
>> executable is called akidea.exe because project that builds itself
>> produces
>> akide.exe in the same directory.
>> Please note if anyone use it for any reason. Although it is capable of
>> editing
>> and building projects already it is not complete yet and even when it is
>> I wont
>> be responsible for anything... If downloading read !!!readme!!!.txt
>
>Ok, here is what I've done.
>
>1. Built it.
>2. Ran it.
>3. Created a blank text file a.txt using textpad. (as file|new crashes
>akidea at the moment)
>4. Opened a.txt
>5. wrote 10 'a' characters, copy pasted them till I had 100 then added a
>newline to the end.
>6. ctrl+a, ctrl+c
>7. ctrl+v 10 times
>8. go to step 6 until memory usage reaches 200+MB
>9. close a.txt
>
>What I noticed in Task Manager is that the memory usage climbs as I paste characters, but drops again once I close the file. It seems to be allocating and freeing memory just fine.
>
>What do I have to do to see some corruption?
>
>Regan

I did this just for a test... Of course I'm not doing such thing in my app. 50k chars.. OMG... This just does the effect faster. If I do anything that use memory, earlier or later this data gets corrupted. I don't know if anything else is also corrupted and when...

In article <d1p4jp$2gv6$1@digitaldaemon.com>, Ben Hinkle says...
>
>> char[50000] tosho;
>> tosho[0..5]="bobef";
>> mtest~=tosho;
>
>That's a big string. Note when you ~= to mtest the whole 50_000 characters in tosho are concatentated. That might explain why you are consuming so much memory so quickly. By why memory is getting corrupted? I don't know. Maybe the 50_000 char string on the stack is blowing your stack and you don't know it? Try reducing that number to, say, a dynamic array.
>
>

On Tue, 22 Mar 2005 13:10:57 +0000 (UTC), bobef <bobef_member@pathlink.com> wrote:
> Adding/pasting/deleting characters is managed internaly by scintilla so it should be ok and if is not it is not in the my scope of worry...

I was trying to test the GC :)

> To see something you do the following: open an editor

What is an "editor".. do you mean open a file in akidea.

> to see what are the normal
> fonts then hold f7 for a sec or two then open new editor... tracing font names
> when editor loads styles shows that strings are messed up (you will not see them
> right now; if you wish to do so goto line 598 of editor.d and add
> trace(v2.styles[c].font_face.ptr); this will show the string in the output
> window)...

Line 598 of editor.d reads:

int getLineEndPosition(int line){return callscin(SCI_GETLINEENDPOSITION,line,0);}

I tried adding the trace call to that function but I get errors:

editor.d(598): undefined identifier v2
editor.d(598): no property 'styles' for type 'int'
editor.d(598): undefined identifier c
editor.d(598): 1 must be an array or pointer type, not int
editor.d(598): no property 'font_face' for type 'int'
editor.d(598): no property 'ptr' for type 'int'

I suspect you're looking at different source to me?

> And I forgot something - to compile any project you need to uncomment few lines
> at output.d line 820...

Done.

Regan

> In article <opsn1hx8td23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>> On Tue, 22 Mar 2005 11:43:38 +0000 (UTC), bobef
>> <bobef_member@pathlink.com> wrote:
>>> OK... I didn't wanted to post anything before I'm ready with first stage
>>> of my
>>> program (first stage i call a fully capable editor and workspace
>>> manager, no
>>> debuger, no itellisense), but looks like I'll have to do so...
>>> So here is it. The function I posted in last message is app.d line 255
>>> and
>>> editor.d line 45. To compile anything it has to be uncommented and tests
>>> removed. Also it is fully capable if building itself already but to build
>>> anything else it requires some manual work on the new workspace file...
>>> The
>>> executable is called akidea.exe because project that builds itself
>>> produces
>>> akide.exe in the same directory.
>>> Please note if anyone use it for any reason. Although it is capable of
>>> editing
>>> and building projects already it is not complete yet and even when it is
>>> I wont
>>> be responsible for anything... If downloading read !!!readme!!!.txt
>>
>> Ok, here is what I've done.
>>
>> 1. Built it.
>> 2. Ran it.
>> 3. Created a blank text file a.txt using textpad. (as file|new crashes
>> akidea at the moment)
>> 4. Opened a.txt
>> 5. wrote 10 'a' characters, copy pasted them till I had 100 then added a
>> newline to the end.
>> 6. ctrl+a, ctrl+c
>> 7. ctrl+v 10 times
>> 8. go to step 6 until memory usage reaches 200+MB
>> 9. close a.txt
>>
>> What I noticed in Task Manager is that the memory usage climbs as I paste
>> characters, but drops again once I close the file. It seems to be
>> allocating and freeing memory just fine.
>>
>> What do I have to do to see some corruption?
>>
>> Regan
>
>

Hmm.  Doesn't this point out a flaw in design?  C++ have the issue of variables going out of scope, yet returned to the callee.  Java, like so many scripting languages, GCd so that it would clean up after you once there were no references, but since we are sending the caller a reference, the variable (class) is not destroyed.

Now, with "auto" you can simulate the C++ error with great support!  (-:

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d1ono3$23in$1@digitaldaemon.com...
> Use auto.  Example:
>
> int function()
> {
> auto Window w;
>
> (etc...)
> }
>
> When w falls off scope, it's destructor will be called.  However, if you were returning w, you would not want this; for that reason, you cannot return autos.
>
> I have not experienced any memory leaks with the garbage collector.
>
> -[Unknown]
>
>
>> I'm absolutely sure that data is not corrupted because of my mistake. I
>> assume
>> win32 does something wrong with all this pointer-to-int casts but I will
>> have to
>> find out that. It would be so easier if there was a nice debugger :))
>> And about the GC - it was hard to me to trust it and do not use
>> calloc/free now
>> I have to live with the idea my program is wasting memory :)))) Anyway
>> I'll get
>> over it :)) But still I can not understand why when the program runs out
>> of
>> scope that created the object, destructor is not called? This is kind-a
>> important for me because I'm dealing with win32 windows and they need to
>> be
>> removed from the global map... Looks like I'll try the new
>> __FILE__/__LINE__
>> things...

FWIW, the destructor of "auto" variables is not called if execution leaves scope as the result of a thrown exception.  I'm sure this is a bug that will be addressed eventually, but it's something to be aware of in the interim.


Sean

In article <d1sdt0$9v$1@digitaldaemon.com>, Charlie Patterson says...
>
>Hmm.  Doesn't this point out a flaw in design?  C++ have the issue of variables going out of scope, yet returned to the callee.  Java, like so many scripting languages, GCd so that it would clean up after you once there were no references, but since we are sending the caller a reference, the variable (class) is not destroyed.
>
>Now, with "auto" you can simulate the C++ error with great support!  (-:
>
>"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d1ono3$23in$1@digitaldaemon.com...
>> Use auto.  Example:
>>
>> int function()
>> {
>> auto Window w;
>>
>> (etc...)
>> }
>>
>> When w falls off scope, it's destructor will be called.  However, if you were returning w, you would not want this; for that reason, you cannot return autos.
>>
>> I have not experienced any memory leaks with the garbage collector.
>>
>> -[Unknown]
>>
>>
>>> I'm absolutely sure that data is not corrupted because of my mistake. I
>>> assume
>>> win32 does something wrong with all this pointer-to-int casts but I will
>>> have to
>>> find out that. It would be so easier if there was a nice debugger :))
>>> And about the GC - it was hard to me to trust it and do not use
>>> calloc/free now
>>> I have to live with the idea my program is wasting memory :)))) Anyway
>>> I'll get
>>> over it :)) But still I can not understand why when the program runs out
>>> of
>>> scope that created the object, destructor is not called? This is kind-a
>>> important for me because I'm dealing with win32 windows and they need to
>>> be
>>> removed from the global map... Looks like I'll try the new
>>> __FILE__/__LINE__
>>> things...
>
>