Transform CodeBlocks in strings

Harbour, MingW related news.

Moderator: Rathinagiri

User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil
Has thanked: 100 times
Been thanked: 182 times

Transform CodeBlocks in strings

Post by Pablo César » Thu May 08, 2014 1:42 pm

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 !
Last edited by Pablo César on Sat Oct 15, 2016 4:47 pm, edited 1 time in total.
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein

User avatar
bpd2000
Posts: 1077
Joined: Sat Sep 10, 2011 4:07 am
Location: India
Has thanked: 197 times
Been thanked: 96 times

Post by bpd2000 » Thu May 08, 2014 3:21 pm

Thank you Pablo
BPD
Convert Dream into Reality through HMG

User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil
Has thanked: 100 times
Been thanked: 182 times

Post by Pablo César » Sat Oct 15, 2016 4:01 pm

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
Screen15.png (36.74 KiB) Viewed 3800 times
I found this [x]Harbour reference documentation: http://www.creasolgroup.com/xOraclipLan ... _f.en.html

This code was tested, but not success... :(

Code: Select all

#include <hmg.ch>

// In this example, a code block is created and stored in a MEM file.
// The second invocation of the example code loads the stored code block
// and evaluates it. Note that the code block referenes a PRIVATE variable
// that is restored along with the code block.

Function Main()
LOCAL bBlock := {|| MsgInfo( pcString ) }

MsgDebug(HB_Serialize(bBlock))
IF .NOT. File( "Codeblock.mem" )

   PRIVATE pcString := "code block restored from file"
   PRIVATE pcBlock := HB_Serialize( bBlock )
   
   SAVE TO Codeblock.mem ALL LIKE pc*
   MsgInfo("Restart program to load code block")
   
ELSE
   RESTORE FROM Codeblock.mem
   
   bBlock := HB_DeSerialize( pcBlock )
   
   Eval( bBlock )
ENDIF

Return Nil
PCBLOCK returns empty... :oops:

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...
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein

User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil
Has thanked: 100 times
Been thanked: 182 times

Post by Pablo César » Sat Oct 15, 2016 5:48 pm

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... :?
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein

User avatar
serge_girard
Posts: 2333
Joined: Sun Nov 25, 2012 2:44 pm
DBs Used: 1 MySQL - MariaDB
2 DBF
Location: Belgium
Has thanked: 575 times
Been thanked: 124 times
Contact:

Post by serge_girard » Sun Oct 16, 2016 8:44 am

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

User avatar
srvet_claudio
Posts: 2044
Joined: Thu Feb 25, 2010 8:43 pm
Location: Uruguay
Has thanked: 35 times
Been thanked: 146 times
Contact:

Post by srvet_claudio » Sun Oct 16, 2016 5:40 pm

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.
Best regards.
Dr. Claudio Soto
(from Uruguay)
http://srvet.blogspot.com

User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil
Has thanked: 100 times
Been thanked: 182 times

Post by Pablo César » Mon Oct 17, 2016 10:44 am

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... :(
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein

User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil
Has thanked: 100 times
Been thanked: 182 times

Post by Pablo César » Mon Nov 14, 2016 12:14 pm

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. :cry:

Any suggestion ? :roll:
Last edited by Pablo César on Mon Nov 14, 2016 2:50 pm, edited 1 time in total.
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein

User avatar
esgici
Posts: 4513
Joined: Wed Jul 30, 2008 9:17 pm
DBs Used: DBF
Location: iskenderun / Turkiye
Has thanked: 389 times
Been thanked: 111 times
Contact:

Post by esgici » Mon Nov 14, 2016 1:26 pm

Viva INTERNATIONAL HMG :D

User avatar
srvet_claudio
Posts: 2044
Joined: Thu Feb 25, 2010 8:43 pm
Location: Uruguay
Has thanked: 35 times
Been thanked: 146 times
Contact:

Post by srvet_claudio » Mon Nov 14, 2016 1:37 pm

Best regards.
Dr. Claudio Soto
(from Uruguay)
http://srvet.blogspot.com

Post Reply