Page 1 of 2
Transform CodeBlocks in strings
Posted: Thu May 08, 2014 1:42 pm
by Pablo César
I do not know if you have passed for this needing. But yesterday, I do and decided to post here as I posted in ClipperOnLine brazilian forum and I received this
this message (in portuguese) from our good coleague Mr. Rossine.
Very smart example and I made a little different to be tested in HMG:
Code: Select all
#Translate CBNew (<b>) => { <b>, <(b)> }
#Translate CBEval (<b>) => Eval( <b>\[1\] )
#Translate CBString (<b>) => <b>\[2\]
REQUEST HB_GT_WIN_DEFAULT
Function Main()
Local bCod1 := CBNew( { || My_Func("This is a test") } )
Local bCod2 := CBNew( { || My_Func(12) } )
Local bCod3 := CBNew( { || My_Func("This is a test") } )
Local bCod4 := CBNew( { || nCtd += 1, npar2 -=1, npar3 +=10 } )
Private nCtd := 0, npar2 := 0, npar3 := 0
SetMode(25,80)
cls
? PadC(Chr(32)+CBString( bCod1 )+Chr(32),79,"-")
? CBEval( bCod1 )
? Replicate("-",79)
?
?
? PadC(Chr(32)+CBString( bCod2 )+Chr(32),79,"-")
? CBEval( bCod2 )
? Replicate("-",79)
?
?
? PadC(Chr(32)+CBString( bCod3 )+Chr(32),79,"-")
? CBEval( bCod3 )
? Replicate("-",79)
?
?
? PadC(Chr(32)+CBString( bCod4 )+Chr(32),79,"-")
? CBEval( bCod4 )
? Replicate("-",79)
Inkey(0)
Return Nil
Function My_Func( uDesc )
? "ValType: "+Chr(34)+ValType(uDesc)+Chr(34)+Space(40)+"Value: ", uDesc
Return uDesc
This Rossine example, is a very simple solution with the power to use
#translate resource.
I hope it will be useful to anyone who needs it !
Thank you very much, Rossine ! You are a "mineiro bão, sô !". Congratulations !
Re: Transform CodeBlocks in strings
Posted: Thu May 08, 2014 3:21 pm
by bpd2000
Thank you Pablo
Transform CodeBlocks in strings
Posted: Sat Oct 15, 2016 4:01 pm
by Pablo César
Back again with this matter...
In
this topic I am approaching about
CodeBock convertion to
String in Harbour.
This trying convertion seems it is failed at Harbour...
This procedure is called by
HB_Serialize() which it would convert to binary string but except to CodeBlocks...
See Harbour ChangeLog from Przemyslaw Czerpak at 2013-01-23
- Screen15.png (36.74 KiB) Viewed 12263 times
I found this [x]Harbour reference documentation:
http://www.creasolgroup.com/xOraclipLan ... _f.en.html
This code was tested, but not success...
PCBLOCK returns empty...
And also I found something about CB to String in another programming language (Ruby):
http://stackoverflow.com/questions/2410 ... o-a-string
Deserialization xHarbour it worked but not in Harbour now.
My next attempt will be use of _PP functions...
Transform CodeBlocks in strings
Posted: Sat Oct 15, 2016 5:48 pm
by Pablo César
Pablo César wrote:My next attempt will be use of _PP functions...
Not worked too...
I found this text (In xhb-diff.txt)
### CODEBLOCK SERIALIZATION / DESERIALIZATION ###
=======================================================
xHarbour has support for codeblock serialization. It's done by simple
storing compiled codeblock body (PCODE) in string variable and then
restoring it from such variable. Harbour does not support it intentionally
and in such form it will never be supported by HVM because it can work
only in some very limited situations and then can be source of very bad
bugs like internal HVM memory corruption or absolutely unexpected runtime
behaviors. Compiled PCODE contains references to symbol tables or even
memory addresses (i.e. macrocompiled codeblocks). If application stores
such codeblock in some external holder, i.e. memo file then after restoring
by different instance of the same application memory addresses can be
different so for macrocompiled codeblocks it's not safe at all. For
codeblocks compiled by compiler it can work until exactly the same
application is used. But any modifications in the code can change
symbol table so after restoring the result can be unpredictable.
Codeblock like:
{|x| qout( x ) }
can be defined in code where just after QOUT() in symbol table is FERASE().
Small modification in application code can cause that symbols will be
moved and above codeblock after restoring will effectively execute FERASE()
instead of QOUT(). What does it mean for programs which makes something like:
eval( cb, "The most import file is:" )
eval( cb, cDataFile )
eval( cb, "Please make backup." )
I do not have to explain.
With full respect to xHarbour users IMO such "extension" is giving knife
into monkey hands.
Codeblock serialization can be implemented in safe way but it needs at
least some partial PCODE (de|re)compiler. If Harbour users find codeblock
serialization as important extension then maybe we create such PCODE
recompiler and such functionality will be added. Anyhow it will be necessary
to keep recompiler code synced with compiler and it will be additional job
in any future compiler modifications which can change generated PCODE.
There is another person who has looked up for the same propose: just to take Block data as strings not to execute it.
I believe would it exist this conversion just for displaying not for executing proposes...
Re: Transform CodeBlocks in strings
Posted: Sun Oct 16, 2016 8:44 am
by serge_girard
Pablo,
A dirty way is to parse the PRG file and store the found cb in the MEM file : '{|| MsgInfo( pcString ) }'
Then in the second part: Eval( &pcBlock )
Serge
Re: Transform CodeBlocks in strings
Posted: Sun Oct 16, 2016 5:40 pm
by srvet_claudio
Pablo César wrote:
I found this text (In xhb-diff.txt)
### CODEBLOCK SERIALIZATION / DESERIALIZATION ###
=======================================================
xHarbour has support for codeblock serialization. It's done by simple
storing compiled codeblock body (PCODE) in string variable and then
restoring it from such variable. Harbour does not support it intentionally
and in such form it will never be supported by HVM because it can work
only in some very limited situations and then can be source of very bad
bugs like internal HVM memory corruption or absolutely unexpected runtime
behaviors. Compiled PCODE contains references to symbol tables or even
memory addresses (i.e. macrocompiled codeblocks). If application stores
such codeblock in some external holder, i.e. memo file then after restoring
by different instance of the same application memory addresses can be
different so for macrocompiled codeblocks it's not safe at all. For
codeblocks compiled by compiler it can work until exactly the same
application is used. But any modifications in the code can change
symbol table so after restoring the result can be unpredictable.
Codeblock like:
{|x| qout( x ) }
can be defined in code where just after QOUT() in symbol table is FERASE().
Small modification in application code can cause that symbols will be
moved and above codeblock after restoring will effectively execute FERASE()
instead of QOUT(). What does it mean for programs which makes something like:
eval( cb, "The most import file is:" )
eval( cb, cDataFile )
eval( cb, "Please make backup." )
I do not have to explain.
With full respect to xHarbour users IMO such "extension" is giving knife
into monkey hands.
Codeblock serialization can be implemented in safe way but it needs at
least some partial PCODE (de|re)compiler. If Harbour users find codeblock
serialization as important extension then maybe we create such PCODE
recompiler and such functionality will be added. Anyhow it will be necessary
to keep recompiler code synced with compiler and it will be additional job
in any future compiler modifications which can change generated PCODE.
There is another person who has looked up for the same propose: just to take Block data as strings not to execute it.
I believe would it exist this conversion just for displaying not for executing proposes...
With this information, in practice it is little useful you convert an codeblock to an string.
Transform CodeBlocks in strings
Posted: Mon Oct 17, 2016 10:44 am
by Pablo César
serge_girard wrote:A dirty way is to parse the PRG file and store the found cb in the MEM file : '{|| MsgInfo( pcString ) }'
I have tested as I said for saving memvars at MEM file but it doesn't work with CodeBocks.
But I see your apostrophe siybol at beginning and end of CodeBock what it means you have already declared as string of CodeBlock and it will be act as macro compile not as pure CodeBlock. Because its ValueType is "C" (character) not "B". And in all FMG files are written as CodeBlock (of course inside a text file) but are responding as all codeblock in all HMG. It dosn't work.
serge_girard wrote:Then in the second part: Eval( &pcBlock )
But in HMG it is not like this.
srvet_claudio wrote:With this information, in practice it is little useful you convert an codeblock to an string.
Yes, only to convert to string not for the opposite case and not for re-editable code blocks with it.
For example. We use a lot of MsgDebug, to display some variables and arrays contains. But not for "B" cases. In this case it we displays just a "{||...}" and not showing what's really is in it.
So even I am getting success to take xHarbour's codes of
HB_Serialize() and
HB_SaveBlock() a creating a specific routine for BCToStr(), I don't wish to use HB_DeSerialize() because its for fmg creating propose only. Creating with a complete info.
Well... we still we're without solution in Harbour...
Transform CodeBlocks in strings
Posted: Mon Nov 14, 2016 12:14 pm
by Pablo César
I have installed xHarbour to make tests. It was a horrible experience. Because all promissed hb_SaveBlock() or HB_Serialize() becomes a bad returns. No safe conversions from CodeBlocks to String... (I've lost my time with xHarbour).
I've read this
PowerShell Tip - Convert Script Block to string or string to Script Block saying that
"It is very simple. You just need to create a new instance of System.Management.Automation.ScriptBlock and use Create() method."
I am thinking to try with WbemScripting.
I am feeling incomplete even if I finish the Prg2Fmg project because I not getting a solution to get all the ACTIONs CodeBlocks in it and transform into text file FMG.
Any suggestion ?
Re: Transform CodeBlocks in strings
Posted: Mon Nov 14, 2016 1:26 pm
by esgici
Re: Transform CodeBlocks in strings
Posted: Mon Nov 14, 2016 1:37 pm
by srvet_claudio