codeblock decompiler - Clipper

"frank van nuffel" <nospam@versateladsl.be> wrote in message
news:46795154$0$21256$bf4948fe@news.tele2.nl...
>
> "N:dlzc D:aol T:com (dlzc)" wrote in message
> news:rE9ei.5359$s57.2597@newsfe07.phx...
>
> > > now, it is hard to detect what is the final codeblock that
> > > is compiled. as a result, i have a case of nested
> > > codeblock [which fails to work as expected, while both
> > > parts, inner codeblock when used by itself, and outer codeblock
> > > when used without inner one, work as
> > > expected] it is not clear to me which part of codeblock
> > > is compiled [made "frozen"]
> >
> > Both are frozen into pcode. See Ron Pinkas' response to me here.
>
> Nothing to do with temperature :-) Detached local(s) instead
>
> > > and which part is evaluated-interpreted at runtime.
>
> When the codeblock references a detached local, the value that
> local had at the time the codeblock was compiled is not necessarily
> the value it has when the codeblock is evaluated; more likely, during
> evaluation the actual value of the local at the time of evaluation is
> returned; so there's even no concept of 'frozen' at all


n:=1
a:={||n}
n:=2
b:={||n}
n:=3

and both:
eval(a) ==> 3
eval(b) ==> 3

what is the cleverest way of composing codeblocks to have:

eval(a) ==> 1
eval(b) ==> 2

having:

a:=&("{||" + str(n) + "}")

ensures me to have variable "n" be "frozen" inside codeblock

anything better?

<dos513@emailDotSi.invalid> wrote in message
news:MPG.20e37c55ef143245989680@news.siol.net...
> sali wrote in post <f5beum$8bn$1@ls5.tel.net.ba> ...
>
> Hi, sali !
>
> [...]
> >
> > otb:=tbrowsedb(t,l,u,b)
> > for i=1 to fcount()
> > fn:=field()
> > otb:addcolumn(tbcolumnnew(fn,{||fn}))
> > next
> >
> Try next:
>
> // Create oBrowse
> oTBrw := TBrowseDB( nT, nL, nB, nR)
>
> // Add Column
> FOR iX = 1 TO FCount()
> FName := FieldName( iX)
> oTBrw:AddColumn( TBColumnNew( FName, &("{||" + FName + "}") ))
> NEXT
>


thnx

i also found that this [half-way-old-fashioned] works:

.. oTBrw:AddColumn( TBColumnNew( FName, {||&FName} ))

Hi Sali,

"sali" wrote in message news:f5bmmo$agr$1@ls5.tel.net.ba...

> n:=1
> a:={||n}
> n:=2
> b:={||n}
> n:=3
>
> and both:
> eval(a) ==> 3
> eval(b) ==> 3

Yes, because at the time of evaluation the code is way beyond statement n:=3
Else, if the codeblock is evaluated in a loop during which n is still
changing
value from assignments occuring outside of the block, but yes, in the same
procedure/function as where the block is first initialized (locals cannot be
changed from outside, of course - i admit this example is a rare situation)
then the referenced local may long have changed value in between evaluations

func cbExample ()
local n := 0
local cb := { || n }

for n := 1 to 5
? cb:eval() // consecutively 1-5
next

return n

btw, detached local _can_ be changed from outside its parenting proc/func,
to say, _from_ within the codeblock

func cbExample ()
local n1 := 0
local n2
local cb1 := { || n1 }
local cb2 := { || n1 := 0 }

for n2 := 1 to 5
n1 := n2
cbTest()
? cb:eval() // 5 times consecutively 0
next

return n

proc cbTest ( cb )
cb:eval()
return nil

..oO had to change cbExample() a bit, else the loop would occur
infinitely, since n is each time reset to 0

> what is the cleverest way of composing codeblocks to have:
>
> eval(a) ==> 1
> eval(b) ==> 2
>
> having:
>
> a:=&("{||" + str(n) + "}")
>
> ensures me to have variable "n" be "frozen" inside codeblock

yes, but be aware there is a limit on how complex such mix of literal
values and dynamic content may be; the clipper compiler can start
complaining about too complex codeblock or some error message
alike (don't remember what the message says exactly)

> anything better?

no

anyhow, perhaps try Steve's approach, reading what your .ppo
shows as code for the codeblock, cutting and pasting that into
a standalone func and calling the func from the block

frank

Sorry, should read:

func cbExample ()
local n1 := 0
local n2
local cb1 := { || n1 }
local cb2 := { || n1 := 0 }

for n2 := 1 to 5
n1 := n2
cbTest( cb2 )
? cb1:eval() // 5 times consecutively 0
next

return n

proc cbTest ( cb )
cb:eval()
return nil

and regarding { || &FNAME }, this is exactly the same as &("{||"+FNAME+"}")

best regards,

frank

"frank van nuffel" <nospam@versateladsl.be> wrote in message
news:46796645$0$21598$bf4948fe@news.tele2.nl...
>
> and regarding { || &FNAME }, this is exactly the same as
&("{||"+FNAME+"}")
>

you mean: they are producing the same result?

the first is a compile time codeblock that evaluates macro var
the second is run time codeblock


thnx for the hints.

"sali" wrote in message news:f5c3ce$e5j$1@ls5.tel.net.ba...

> > and regarding { || &FNAME }, this is exactly the same as
> &("{||"+FNAME+"}")
> >
>
> you mean: they are producing the same result?

> the first is a compile time codeblock that evaluates macro var
> the second is run time codeblock

true, come to think about it in terms of early binding versus late
binding; in the first case, the codeblock is compiled at compile
time with a late binding (runtime) macro evaluation - the second
is a block compiled at runtime with an early binding (if one can
consider the + FNAME part as early binding, although, for it is in se
a non-macro evaluation, the concept of late/early binding doesn't
strictly apply here), but yes they produce the same result in this case

a detached local has very much in common with a reference in C++
which can be seen as a pointer but without the need for applying
a dereference operator

and regarding debugging your code, as said Steve's approach is
the only option; you'll probably have to change the declaration
of the referenced locals into privates, so they'll be accessible
from within a callee, but i haven't tested this, i could be wrong here

> thnx for the hints.

my pleasure

"frank van nuffel" <nospam@versateladsl.be> je napisao u poruci interesnoj
grupi:4679b217$0$7285$bf4948fe@news.tele2.nl...
> "sali" wrote in message news:f5c3ce$e5j$1@ls5.tel.net.ba...
>
>> > and regarding { || &FNAME }, this is exactly the same as
>> &("{||"+FNAME+"}")
>> >
>>
>> you mean: they are producing the same result?
>
>> the first is a compile time codeblock that evaluates macro var
>> the second is run time codeblock
>
> true, come to think about it in terms of early binding versus late
> binding; in the first case, the codeblock is compiled at compile
> time with a late binding (runtime) macro evaluation - the second
> is a block compiled at runtime with an early binding (if one can
> consider the + FNAME part as early binding, although, for it is in se
> a non-macro evaluation, the concept of late/early binding doesn't
> strictly apply here), but yes they produce the same result in this case

funny, i was using codeblocks for [many] years now, but allways just the
simpliest forms [as you said, just to call the workhorse function], so never
had to think about thier nature.
yes, i have noticed that "sometimes some codeblock not worked" but have to
correct it through try-error iterations.
now, when i am almost out of my clipper apps, arose this complex
preprocessed codeblock that required special attention.

so far, having this "late binding" knowledge, this is solved.

thnx.

Dear sali:

"sali" <sali@euroherc.hr> wrote in message
news:f5d6fm$oh2$1@ls5.tel.net.ba...
....
> funny, i was using codeblocks for [many] years now,
> but allways just the simpliest forms [as you said, just
> to call the workhorse function], so never had to think
> about thier nature. yes, i have noticed that
> "sometimes some codeblock not worked" but have to correct it
> through try-error iterations. now, when i am
> almost out of my clipper apps, arose this complex preprocessed
> codeblock that required special attention.
>
> so far, having this "late binding" knowledge, this is solved.

Just in case you were not aware of this resource...
http://www.ghservices.com/gregh/clipper/cbevo.htm

David A. Smith

On Wed, 20 Jun 2007 18:04:26 +0100,
sali <sali@tel.net.ba> wrote:
> n:=1
> a:={||n}
> n:=2
> b:={||n}
> n:=3
> and both:
> eval(a) ==> 3
> eval(b) ==> 3
> what is the cleverest way of composing codeblocks to have:
> eval(a) ==> 1
> eval(b) ==> 2
> having:
> a:=&("{||" + str(n) + "}")
> ensures me to have variable "n" be "frozen" inside codeblock
> anything better?

proc main()
local n, a, b
n:=1
a:=detachedblock(n)
n:=2
b:=detachedblock(n)
n:=3
? eval(a)
? eval(b)
return

func detachedblock(n)
return {||n}

If you are using Harbour then you can also controll references in such
code, f.e.:

proc main()
local n, a, b
n:=1
a:=detachedblock(n)
n:=2
b:=detachedblock(@n) // pass n by reference
n:=3
? eval(a)
? eval(b)
return

func detachedblock(n)
return {||n}

and in such case block inside 'b' will share the 'n' value with local 'n'
variable of function main(). But this works only in Harbour and is not
supported by Clipper and xHarbour.

best regards,
Przemek