This is confusing...
George Razutov
in a reliable manner than VO is the only programming language during
the last 46 years (since FORTRAN appeared in 1956) that CANNOT do it!
And what about brackets in string and float expressions (they probably
need temporary dynamic pointers too)? Does it mean that the only
reliable way to write programs in VO is "Assembler-like" coding with
storing the result of any primitive operation? I just cannot believe
that. Maybe I don't understand something important (well the language
barrier etc...)?
2. From my point of view the most attractive and unique feature of
Clipper was the ability to process macros with complex expressions and
function calls at run time. It made it possible to take major part of
business logic outside the program code and place it into the
database. This feature is especially useful when you have many
installations with slightly different business rules that often change
and are unknown at the projecting time -- a normal situation for the
country where laws are changing every week. I was happy to use this
feature for 12 years with Clipper without any problems at all, and
this is what I am trying to do now with VO -- with unpredictable 5333s
from time to time. Well I can get rid of expressions in function calls
in program code, using variables. But what can I do with macro
compiled complex expressions coming from database as text strings? Is
there a reliable way to proceed them?
Jamie Macleod
Macros work fine in VO. If you are getting 5333 errors with macros you are
probably trying to access them after they are no longer in scope. This has
to do with the nature of OOP.
Jamie
"George Razutov" <el...@dialup.ptt.ru> wrote in message
news:178f3208.02101...@posting.google.com...
Jamal
If you have actual code samples that you have problem with, I am sure many
here can jump in and help. Most people here are former Clipper developers.
But you to remember, Windows programming is a little different than the old
Clipper days, but most of the business logic should move with little or no
change.
Jamal
"George Razutov" <el...@dialup.ptt.ru> wrote in message
news:178f3208.02101...@posting.google.com...
Phil McGuinness
You might amazed how many still do a bit of Clipper.
snip[ Windows programming is a little different than the old Clipper days]
A little different... it is a whole new ball game.
Phil
----
"Jamal" <jama...@nospamhotmail.com> wrote in message
news:JOKr9.4256$eW3....@news4.srv.hcvlny.cv.net...
Jamal
I was using more diplomatic ways! Anyone who wants to program in VO needs
some encouragement.
Jamal
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:aontu8$o6vgh$1...@ID-88745.news.dfncis.de...
Phil McGuinness
Send them around to Graham McKechnie's house then...
Phil
---
"Jamal" <jama...@nospamhotmail.com> wrote in message
news:NuLr9.4506$eW3....@news4.srv.hcvlny.cv.net...
Jamal
I think you need to cool down 'a little'. I'm not getting between the two of
you.
Jamal
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:aoo2oj$oa7fg$1...@ID-88745.news.dfncis.de...
Mathias Håkansson
> in a reliable manner
It can. The problem some people have been experiencing is relates to
assignments in function calls like:
MyFunction(val := My Otherfunction())
> 2. From my point of view the most attractive and unique feature of
> Clipper was the ability to process macros with complex expressions and
> function calls at run time. It made it possible to take major part of
> business logic outside the program code and place it into the
> database. This feature is especially useful when you have many
> installations with slightly different business rules that often change
> and are unknown at the projecting time -- a normal situation for the
> country where laws are changing every week. I was happy to use this
> feature for 12 years with Clipper without any problems at all, and
> this is what I am trying to do now with VO -- with unpredictable 5333s
> from time to time.
If you get 5333 errors in codeblocks there's propably a variable that has
gone out of scope and been collected by the garbage collector. To solve this
problem you have two possibilities. You have to make sure that the variables
you are using does not go out of scope while you are executing your code
block.
Mathias
Denis Mitrofanov
> 1. If this is true that VO cannot manage expressions in function call
Who say you this? Have example? I working with VO several years, and have no
problems with it...
> 2. From my point of view the most attractive and unique feature of
> Clipper was the ability to process macros with complex expressions and
> function calls at run time. It made it possible to take major part of
> business logic outside the program code and place it into the
> database. This feature is especially useful when you have many
> installations with slightly different business rules that often change
> and are unknown at the projecting time -- a normal situation for the
> country where laws are changing every week. I was happy to use this
> feature for 12 years with Clipper without any problems at all, and
> this is what I am trying to do now with VO -- with unpredictable 5333s
> from time to time. Well I can get rid of expressions in function calls
> in program code, using variables. But what can I do with macro
> compiled complex expressions coming from database as text strings? Is
> there a reliable way to proceed them?
If you get 5333, it is completely your responsibility. I have developed huge
application using DDA concepts (almost on compiled expressions), and all is
working fine until now... Just check your approach. It is true, Clipper was
much more democratic than VO with macros, but VO has it's own advantages.
Denis.
Malcolm Gray
> 1. If this is true that VO cannot manage expressions in function call
> in a reliable manner than VO is the only programming language during
> the last 46 years (since FORTRAN appeared in 1956) that CANNOT do it!
f(x:=g(),b) if g caused a garbage collect.
I also had a few problems with references to DWORDs
(I have yet to meet a compiler that didn't have bugs)
> 2. From my point of view the most attractive and unique feature of
> Clipper was the ability to process macros with complex expressions and
> function calls at run time.
I cannot comment on this as we hardly use it. (compile time we use a
lot)
You certainly have to be careful as orphaned locals are handled
in a different way (not at all) than they were in clipper for both
compile time and run time.
Geoff Schaller
> Maybe I don't understand something important
Well you got that bit right! <g>.
You are so way out of line its quite humourous <g>. Rather than rant on like
a looney, if you have code you are having difficulty with, why not place it
here and ask for assistance? Perhaps you are having trouble adjusting to
Windows... perhaps its just having trouble with OOP but nothing you said
makes the slightest sense.
You can still use macros and you can still use expressions as parameters.
But that doesn't necessarily make it good coding or make for good outcomes.
Come on now... join the spirit of the ng and put up your issues for review
rather than just whinging about them.
Cheers,
Geoff
Amilcar A. Camargo
<malcol...@jobstream.co.uk> wrote:
>You certainly have to be careful as orphaned locals are handled
>in a different way (not at all) than they were in clipper for both
>compile time and run time.
Remember that clipper was a pseudo-compiled environment and VO
compiles to CPU native code. I presume that this is what precludes the
use of "nested" codeblocks, something i miss from my clipper code. :-|
Regards,
Amilcar A. Camargo F.
Sand, S. A.
Guatemala, C. A.
George Razutov
Geoff,
> You are so way out of line its quite humourous <g>.
Yes you are right. In fact I tried to post message to "5333 String in
Method Error.." thread started by Nathan Robeson 12 Oct. But it
appeared as separate thread for some reason unknown to me.
> nothing you said makes the slightest sense.
Yes you are right, normally you really cannot understand the sense of
postings from other people.
Now some quotes from your own messages:
From your current response 18 Oct:
> You can still use macros and you can still use expressions as parameters.
Just compare it with the following:
13 Oct:
>> oDbServer :=DBServer{ ( cPath_DataL + "\Dc_Card" ), DBSHARED,
> This makes it into a function which needs to be evaluated and thus could be the cause of ocassional failure
14 Oct:
> I recommend resolving all parameters external to their use.
15 Oct:
> Expressions which do not form explicit assignments (ie when used as params to other expressions/functions) must be resolved by the runtime creating a local var and resolving it
Best regards,
George
Geoff Schaller
Sure, so please, let's start again.
Which bit is confusing to you.
I stand by totally in everything I said and I will probably say it all
again. I subscribe to a certain coding style, just as other developers might
do to different styles. We each have our reasons. Its up to you to review
all the info in front of and then make your choice. You can do a lot of
things with VO that I and many others don't recommend but you can do almost
everything you said you thought you couldn't <g>.
Some people would have you killed just for using globals <g>.
A lot of this material is in the help manuals and these manuals are very
well written. Now, perhaps you would like to restart the topic some
specifics? I can give you my thoughts on the subject and others will likely
join in, agreeing or disagreeing as their want. If you think I or anyone was
too glob or too brief with a response then please, just ask for info or
justification. We won't be offended.
Cheers,
Geoff
"George Razutov" <el...@dialup.ptt.ru> wrote in message
news:178f3208.02101...@posting.google.com...
Geoff Schaller
> too glib or too brief with a response then please, just ask for info or
Sorry <g>
George Razutov
This is my understanding of previously discussed issues of 5333
failures:
1. Any complex expression that involves at least 1 intermidiate
dynamic result (of STRING, REAL, ARRAY or OBJECT type), is not 100%
GC-safe, because no intermediate results are stored in a safe manner
until all the expression is evaluated. If GC jumps out of the darkness
after some part of such an expression was evaluated, but before the
evaluation of the whole expression is finished and stored, it (GC) can
(and will) sweep such a result from memory. This will bring
application to crash.
2. Because of GC nature, such a crash appears with non-zero
probability, depending on frequency of GC activisation. So application
can crush at some moment unpredictably (or not crash at all).
3. If this is true, just any expression that involve the types
mentioned above is potentially unsafe, because its results must be
formed somewhere dynamically before the assignment is performed. But
normally it doesn't happen in practice, probably because simple
expressions are calculated fast enough and the probability of GC
activation at that moment is close to 0, or maybe GC is prevented from
running in some cases.
4. The probability of crash is >0 if there is more than 1 intermediate
dynamic result in the expression; that is, a+b+c+d is reasonably safe,
but (a+b)+(c+d) is not.
5. The probability of crash is >0 if the result of expression cannot
be stored in a variable for some time (e. g. expression is used in a
function call as an argument). And it is high if such an expression
involves function calls in turn.
6. There are some other situations bringing to GC crash, described by
Denis Mitrofanov and many others (in-line assignments etc.).
Well all these conclusions are taken from the postings in this NG and
were discussed not once with many examples. IF THIS IS TRUE -- and it
is, I'm afraid, -- than there is only one way to write safe code --
that is, avoiding expressions everywhere (especially in function
calls) and replacing them with local variables. You are a bit cunning
when speaking about "different programming styles". People who want to
write GC-safe code just do not have a choice, they HAVE TO use
"Assembler-like style".
Now the questions:
1. Is it possible to protect complex expression from GC actions
without splitting it to peaces and saving them in variables?
2. Is there a reliable way to manually prevent GC from running for
some period?
3. Does anyone have a list of situations bringing to GC failures?
Best regards,
George
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message news:<Ok4s9.591$DP6....@news-server.bigpond.net.au>...
George Razutov
Macros really didn't cause any problems by themselves. I mentioned
them just to explain why I cannot split complex expressions to pieces
and save intermediate results in local variables.
George
"Jamie Macleod" <bu...@yahoo.com> wrote in message news:<4BKr9.35627$ER5.2...@news2.telusplanet.net>...
Ed Ratcliffe
I will not try to answer all points in your posting, far too many.
But I will question your understanding of the conditions causing a 5333
error.
Please download Geoff Schaller's article on preventing such problems.
I believe it is at knowvo, and if not I am certain someone here will be
able to point you to it.
Ed
George Razutov
> Who say you this? Have example?
Yes I do. Here it is:
...
FOR i:=1 TO Alen(aExp)
aExp[i,1] := &("{|x| " + ceVar + "}")
aExp[i,2] := cfVar
NEXT
...
DO WHILE !oDS:EoF
FOR i:=1 TO Alen(aExp)
oDS:FIELDPUT(aExp[i,2], Eval(aExp[i,1], oDS))
NEXT
oDS:Skip()
ENDDO
Both ceVar (expression) and cfVar (field name) are coming from
database. Expression looks like this:
GET_REC("_C1->OPEROST","412
"+STR(x:ans,5)+STR(x:nnt,6),1)*GET_REC("_VST->CENPV",STR(x:nntvid,2)+STR(x:nnt,6),1)
GET_REC is a function returning field value from specified dbf, having
field name, key and order as parameters. It is used often and never
caused any problems.
ans, nnt, nntname -- field names of oDS, resolved dynamically via
NoIVarGet.
Application crashes after several hundreds evaluations, always on
different records, when working under NT or 2000 (Win98 is OK). It
didn't see crashes after I changed
oDS:FIELDPUT(aExp[i,2], Eval(aExp[i,1], oDS))
into
uv := Eval(aExp[i,1], oDS)
oDS:FIELDPUT(aExp[i,2], uv)
but I am still not sure I really did solve the problem (maybe just
reduced the probability of crash).
Best regards
George
"Denis Mitrofanov" <deni...@mail.ru> wrote in message news:<aoo9ij$2614$1...@dipt.donbass.net>...
Geoff Schaller
You are actually making this seem much more sinister than it is. The thing
you have to remember is that you are working now in a dynamic memory
environment and GCs are a fact of life. They are now for C++ developers,
Delphi and others alike! They all face the same things. Do things
dangerously and you have riksy outcomes. Do things safely and you will be
fine.
But you also over dramatize the problem.
Let's take some of your issues.
> 1. Any complex expression that involves at least 1 intermidiate
> 2. Because of GC nature, such a crash appears with non-zero
> 3. If this is true, just any expression that involve the types
No - you are misrepresenting the issue. It is when you use expressions as
parameters to functions and the called fuction relies on pointers to dynamic
objects (eg API calls) that it MIGHT become a problem. Do you understand
this distinction? It has no bearing on regular expressions used elsewhere.
Such expressions and their temporary vars are quite safe. Always.
> 4. The probability of crash is >0 if there is more than 1 intermediate
> dynamic result in the expression; that is, a+b+c+d is reasonably safe,
> but (a+b)+(c+d) is not.
Well, a+b+c etc represents just as much a risk (there are partial
evaluations here and if dynamic mem is requested, the GC can kick in...) but
the bracketted example certainly includes more intermediary results so you
would expect it to place your code at greater risk.
> 5. The probability of crash is >0 if the result of expression cannot
> be stored in a variable for some time (e. g. expression is used in a
No - I don't understand your point here.
> calls) and replacing them with local variables. You are a bit cunning
> when speaking about "different programming styles". People who want to
> write GC-safe code just do not have a choice, they HAVE TO use
> "Assembler-like style".
This is rubbish - I don't know what you mean here.
> Now the questions:
> 1. Is it possible to protect complex expression from GC actions
> without splitting it to peaces and saving them in variables?
> 2. Is there a reliable way to manually prevent GC from running for
> some period?
Absolutely! DynLock() and DynUnlock() are your friends here. If you
understand the dynamic memory implications of the code you are "protecting"
then it is quite a valid and safe mechanism. Simply turn off the GC, fire
your code, turn it back on.
> 3. Does anyone have a list of situations bringing to GC failures?
How long is a piece of string? Have a look at my paper on 5333's - it goes
through some of them.
Geoff
Stephen Quinn
"_C1->OPEROST"
"_VST->CENPV"
Your ALIASes of '_C1' and '_VST' aren't guaranteed to be that at runtime.
--
HTH
Steve Quinn
http://www.tuxedo.org/~esr/faqs/smart-questions.html
'I want to move to Theory...Everything works in Theory'
Denis Mitrofanov
George
> GET_REC("_C1->OPEROST","412
>
"+STR(x:ans,5)+STR(x:nnt,6),1)*GET_REC("_VST->CENPV",STR(x:nntvid,2)+STR(x:n
nt,6),1)
GET_REC: what is the exactly prototype of this functions? If this function
is strictly typed, you have a problem. You _must_ declare this function
untyped. like this:
FUNCTION GET_REC(Par1, par2, Par3, ...) AS USUAL CLIPPER
Denis.
George Razutov
> Your ALIASes of '_C1' and '_VST' aren't guaranteed to be that at runtime.
Sure they aren't. That's why they are in quotes. I replace them with
actual alias inside the function.
> You _must_ declare this function untyped
Yes it is declared untype. It works OK in many places of application,
and works OK in 99% in this particular case. But that 1% was
bothering.
Actually I don't think 5333 fault is a sort of thing easy to find,
especially in a program written by somebody else. Currently after some
"shaman" actions it looks likely I eliminated the problem but without
deep understanding of its nature.
Thank you for your help.
George
"Denis Mitrofanov" <deni...@mail.ru> wrote in message news:<ap0ju8$qqu$1...@dipt.donbass.net>...
Nathan Robeson
I agree with your conclusions. I have had the same experince. Regardless of
trhe programming style, VO should have a way to protect intermediate dynamic
vars. BTW, Ginny also concurs with this opinion.
Nathan
"George Razutov" <el...@dialup.ptt.ru> wrote in message
news:178f3208.02101...@posting.google.com...
Ginny Caughey
Yep. ;-)
--
Ginny
"Nathan Robeson" <nat...@voicecue.com> wrote in message
news:urb19dk...@news.supernews.com...
Ginny Caughey
I forgot to mention that a reproducible sample will go a long way toward getting
this fixed if indeed it's still broken. I can't say that I'm actually having
problems with expressions inside functions calls in general and I haven't seen a
5333 in a very long time and generally then only when there is a corrupt DBF or
CDX file.
--
Ginny
"Nathan Robeson" <nat...@voicecue.com> wrote in message
news:urb19dk...@news.supernews.com...
Nathan Robeson
But its tough to get the GC to kick in at just the right time for it to crap
out.
Nathan
"Ginny Caughey" <ginny....@wasteworks.com> wrote in message
news:ap43ge$qlcpp$1...@ID-144704.news.dfncis.de...
Ginny Caughey
No doubt. <g> I assume that's why it's also hard to fix, but if anybody can
catch it, I'm sure GrafX would like to see it.
--
Ginny
"Nathan Robeson" <nat...@voicecue.com> wrote in message
news:urj231e...@news.supernews.com...