667 Eval Stack Crashed / Impact of Class(y) objects on DGROUP

Hi,

for a few years now, we have been constantly experiencing 667-Errors
every now and then in our application (Clipper 5.2e / Class(y) /
Clip4Win / Funcky); lately in an increasing manner. There have been many
attempts to get rid of this, yet with no lasting effect.

After having inspected "conventional" ways how to fix this issue, I am
now trying to figure out why memory in Clipper's DGROUP (esp. the Eval
stack) seems to not being released properly when I'd expect it should.
We are making extensive use of Class(y) objects, e.g. for windows, UI
controls, etc. What I'm interested in is: how does a Class(y)
class/object affect memory in the Eval stack? I.e.: how are instance
variables managed by means of their memory consumption? And: as far as
I'd understand, destroying an object should free the resources it used,
however, while testing I've found out it doesn't. (Or at least, it seems
so.) For example, when closing a window in our application, the
underlying object (managing window behaviour, event handling, etc) is
destroyed via object:destroy(). Doesn't this free the memory used inside
the Eval stack for instance and/or local variables?

Any ideas appreciated. :)

Best wishes,
Karsten

--
PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
"When the light of day is dead, the spark of night ignites"

Karsten,

1. Have you tried using Memory( -1 ) to explicitly activate Clipper's
Garbage Collector?

2. I'd strongly suggest a recompile of your app under xHarbour, which is
practically 100% Clipper compatible, and does not suffer from these memory
size limitations.

Ron

"Karsten Stöckmann" <ngc2997@gmx.net> wrote in message
news:fsq39g$ckg$02$1@news.t-online.com...
> Hi,
>
> for a few years now, we have been constantly experiencing 667-Errors
> every now and then in our application (Clipper 5.2e / Class(y) /
> Clip4Win / Funcky); lately in an increasing manner. There have been many
> attempts to get rid of this, yet with no lasting effect.
>
> After having inspected "conventional" ways how to fix this issue, I am
> now trying to figure out why memory in Clipper's DGROUP (esp. the Eval
> stack) seems to not being released properly when I'd expect it should.
> We are making extensive use of Class(y) objects, e.g. for windows, UI
> controls, etc. What I'm interested in is: how does a Class(y)
> class/object affect memory in the Eval stack? I.e.: how are instance
> variables managed by means of their memory consumption? And: as far as
> I'd understand, destroying an object should free the resources it used,
> however, while testing I've found out it doesn't. (Or at least, it seems
> so.) For example, when closing a window in our application, the
> underlying object (managing window behaviour, event handling, etc) is
> destroyed via object:destroy(). Doesn't this free the memory used inside
> the Eval stack for instance and/or local variables?
>
> Any ideas appreciated. :)
>
> Best wishes,
> Karsten
>
> --
> PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
> "When the light of day is dead, the spark of night ignites"

Ron Pinkas wrote:

> [..]
> 1. Have you tried using Memory( -1 ) to explicitly activate Clipper's
> Garbage Collector?

Has no visible effect.


> 2. I'd strongly suggest a recompile of your app under xHarbour, which is
> practically 100% Clipper compatible, and does not suffer from these memory
> size limitations.

This has already been discussed (and, as far as I know, tested).
However, a colleague did some experimentation with xHarbour and ended up
with an error message from an application compiled with xHarbour. I was
not involved, so unfortunately I can't tell any details. For some
reasons, further tests have been discontinued then.

As far as I see the entire problem, there is nearly no alternative than
again try and recompile our apps with xHarbour. What I'd be interested
in then, is: are all of our source codes and third-party libs compatible
(Clipper 5.2b, Class(y) 2.4b, Clip-4-Win 2, Funcky, Novlib, SixNSX 3,
ADS 6.11/7, TCS4Win; hope, I mentioned all..), and what effort would be
necessary recompiling with xHarbour (changes to source code, linker,
build scripts)?

Best wishes,
Karsten

--
PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
"When the light of day is dead, the spark of night ignites"

Karsten

> (Clipper 5.2b, Class(y) 2.4b, Clip-4-Win 2, Funcky, Novlib, SixNSX 3,
If your still using 5.2b then I suggest the first thing to do is upgrade to 
5.2e
- IIRC there are over 100 bugs fixed between versions (5.2c/5.2d/5.2e)
- you can get the patches/updates from the OASIS or the GrafxSoft ftp site.

I'd also suggest you use Blinker or Causeway (freely available now) to re-li
nk your app in extended mode & dump RUN for
Blinkers SwpRunCmd() (if you have Blinker that is<g> ).

Unless you have the source to those libs to re-compile in xHarbour (or someo
ne has provided equivalent libs/functions)
then you'll have to stay with Clipper as they won't be compatible.

--
CYA
Steve

Stephen Quinn wrote:

> [..] 
> If your still using 5.2b then I suggest the first thing to do is upgrade to 5.2e[/
color]

Oops, sorry, that was a typo; we use Clipper 5.2e of course.. :)


> [..]
> I'd also suggest you use Blinker or Causeway (freely available now) to re-
link your app in extended mode & dump RUN for
> Blinkers SwpRunCmd() (if you have Blinker that is<g> ).

Yes, we already use Blinker 7, as we have been experiencing the 667 Eval
stack error for a couple of years now, and hoped to resolve this issue
Blinker, as it optimizes DGROUP memory. However, as our app keeps
growing, this isn't sufficient any longer, as it seems.


> Unless you have the source to those libs to re-compile in xHarbour (or som
eone has provided equivalent libs/functions)
> then you'll have to stay with Clipper as they won't be compatible.

So, in other words: we can't simply use xHarbour to recompile our app
and link in the existing third-party libs. (This _might_ be the reason
why testing with xHarbour has been discontinued here..)

Best wishes,
Karsten

--
PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
"When the light of day is dead, the spark of night ignites"

> As far as I see the entire problem, there is nearly no alternative than
> again try and recompile our apps with xHarbour. What I'd be interested
> in then, is: are all of our source codes and third-party libs compatible
> (Clipper 5.2b, Class(y) 2.4b, Clip-4-Win 2, Funcky, Novlib, SixNSX 3,
> ADS 6.11/7, TCS4Win; hope, I mentioned all..), and what effort would be
> necessary recompiling with xHarbour (changes to source code, linker,
> build scripts)?

- Class(y)
- Clip-4-Win
- Funcky
- Six
- ADS

Have xHarbour replacements. Sorry, I'm not familiar with TCS4Win.
Ultimately, I believe the minor investment in locating or coding
replacement[s] for NovLib, etc., plus the minor modifications if any for
existing code, as well as build scripts, will be well worth it.

Ron

Stephen,
 
> If your still using 5.2b then I suggest the first thing to do is upgrade
> to 5.2e
>    - IIRC there are over 100 bugs fixed between versions (5.2c/5.2d/5.2e)
>    - you can get the patches/updates from the OASIS or the GrafxSoft ftp
> site.
>
> I'd also suggest you use Blinker or Causeway (freely available now) to
> re-link your app in extended mode & dump RUN for Blinkers SwpRunCmd() (if
> you have Blinker that is<g> ).
>
> Unless you have the source to those libs to re-compile in xHarbour (or
> someone has provided equivalent libs/functions) then you'll have to stay
> with Clipper as they won't be compatible.

FWIW, most libs are either directly supported, or have direct replacements:

- Class(y), is directly supported by xHarbour.

- Clip-4-Win is supported by means of WinDock:
http://www.sirodev.com/e195/e264/index_ger.html

- Funcky, is now available as a COM Server, as well as:
http://www.xharbour.com/xHC/index.a..._i=7&show_sub=1

- Six is available with xHarbour Builder:
http://www.xharbour.com/index.asp?p..._h=1&show_i=999

- ADS is directly supported by xHarbour

Ron

Ron Pinkas schrieb: 
>
>    - Class(y)
>    - Clip-4-Win
>    - Funcky
>    - Six
>    - ADS
>
> Have xHarbour replacements. Sorry, I'm not familiar with TCS4Win.
> Ultimately, I believe the minor investment in locating or coding
> replacement[s] for NovLib, etc., plus the minor modifications if any for
> existing code, as well as build scripts, will be well worth it.
>
> Ron
>
>
>
>
We use mredit http://www.extrasensory.com/mredit.htm.
Does this work with xharbour ?

Thanks
Andreas