#pragma to change default ENDTEXT keyword

[Bacco]

I had a hard time embedding some __stream in a PRG

that has "ENDTEXT" on a line (a code generator itself).

Of course I resorted to a kludge, because we have this:

            else if( hb_pp_hasCommand( pBuffer, nLen, &n, 1, "ENDTEXT" ) ||

inside ppcore.c

I know it's an edge case, but at same time it seems It would be very trivial

to have some way to change the stopword without breaking any compatibility,

as some languages do (eg. PHP's  HEREDOC/NOWDOC).

I thought something like

#pragma __text_stopword KEYWORDHERE

Example use:

#pragma __text_stopword ELEPHANT

#pragma __text (do something here with %s)

This is a list of lines

and I can embed a

ENDTEXT

inside the list without any trouble

ELEPHANT

// here we are in "harbour mode" again

Also, as a plus, setting the keyword could set a flag to ignore #pragma __endtext inside

the text itself, allowing any text.

Any ideas or considerations?

Regards,

Bacco

[Pritpal Bedi]

Hi Bacco

You can always use it like 


FUNCTION __pullJson()
#pragma __cstream | RETURN %s
{
  "version"                            : "1.01",
  "run-mode"                           : "__RUN_MODE_PRODUCTION__",
  "paths"                              : {
    "path-email-template-english"      :   "./templates/email_e.html",
    "path-sms-template-spanish"        :   "./templates/sms_s.txt"
                                         },
  "__dummy__"                          : "--- just last line so that json is not broken ---"
}
#pragma __endtext

Pritpal Bedi

a student of software analysis and concepts

[Bacco]

Hi, Pritpal.

Thanks a lot for the suggestion, but I mean you do the same with ENDTEXT as part

of the content. Try to do a __cstream with all these exact lines:

This is a list of lines

and I can embed a

ENDTEXT

inside the list without any trouble

You'll notice that the word ENDTEXT inside the text will force the end of block

and I can't undef this behaviour because it's hardcoded. So it seems I can't

use any text that has a line that begins with ENDTEXT inside.

Note, I don't need a solution for me (already resolved my specific case), I just

think that it would be interesting to have a global solution. Anyway, i'm grateful

for your quick support.

What I'm considering is to change this line inside ppcore.c

else if( hb_pp_hasCommand( pBuffer, nLen, &n, 1, "ENDTEXT" ) ||

to something like

else if( hb_pp_hasCommand( pBuffer, nLen, &n, 1, cTextStopWord ) ||

and default  cTextStopWord to "ENDTEXT"

And add a #pragma to change cTextStopWord if someone need it

I recognize that is such a rare edge case, but also it seems to me that the

solution is so simple that I can't see a reason to implement it. I may be

wrong, of course, I'm asking feedback.

Regards,

Bacco

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-devel/ff783c70-412a-413c-947c-bebfa4293553n%40googlegroups.com.

[Bacco]

Typo. I mean "that I can't see a reason to not implement it."

[Adam Lubszczyk]

Change lines with ENDTEXT (only lines with single word  ENDTEXT) to @ENDTEXT

and try sample:

#ytranslate "@ENDTEXT" => "ENDTEXT"
#ytranslate "@endtext" => "endtext"

#pragma __text| x += %s | |x := ""

This is a list of lines
and I can embed a

@ENDTEXT

inside the list without any trouble

test lower endtext

@endtext

ENDTEXT with other words - no stop pragma - no add @
#pragma __endtext

// here we are in "harbour mode" again

-----------

Adam

[Bacco]

Thank you all folks, but just note that I'm not asking

for userland solutions, if it was the case I would post

on users group, not here. I know you trying to help me,

don't get me wrong, but I'm asking for specific feedback

about having a native solution to change the stopword,

or at least disable ENDTEXT, since we can already use

#pragma __endtext, less prone to collision.

I already solved my specific problem, it's just that I thought

that it could be implemented in core, but if there's no user

interest, nor any hints from core devs, I understand, of

course, as it's an "extreme" edge case.

I didn't send a patch aleady because of two things; one,

I'm not sure that a simple change on ppcore will do (I'm

not too familiar with this part of build process) or there

are any extra dependencies that I'll need to be aware,

and second, if I'll do something for myself I'll do the bare

minimum, if it's something to share, there's more care

with coding conventions, studying current source

nomenclature and code organization, and so on.

 

Anyway, if I'll come with some clean solution I'll report here,

and hope same dev familiarized with HB preprocessing can

spare some thoughts.

Best regards,

Bacco

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-devel/00a189be-ff1c-425e-8f8e-14ada6632be7n%40googlegroups.com.

[José M. C. Quintas]

I think anything like this is a better solution, no strange source code to do that:

FUNCTION ze_LoadResource( cImage )

   cImage := Lower( cImage )
   DO CASE
   CASE cImage == "jpsenha.sql"; #pragma __binarystreaminclude "sql\jpsenha.sql" | RETURN %s
   CASE cImage == "jpbinary.sql"; #pragma __binarystreaminclude "sql\jpbinary.sql" | RETURN %s
   CASE cImage == "jpconfi.sql"; #pragma __binarystreaminclude "sql\jpconfi.sql" | RETURN %s
   CASE cImage == "agentes.json"; #pragma __binarystreaminclude "json\agentes.json" | RETURN %s
   ENDCASE

   RETURN Nil

José M. C. Quintas

To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-devel/CADMEX-U42aoVHyPgv4bFSoh%2BFcGCuaaOaNNKu7_QZuhOTPQZJg%40mail.gmail.com.

[Bacco]

It seems everyone is drifting from the topic...

To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-devel/525e9915-b0ba-5eae-5ea0-64198bb7626b%40gmail.com.

[Lailton Fernando Mariano]

Hi Bacco,

I really like your idea and looks good feature in my opnion in special when we are working

with something like "cgi/fastcgi/modharbour"

( not 100% but I think that harbour had something similar and was removed, I will try to check old version to see how it worked and I will see if I can prepare something  ).

There is a way too to make something like a plugin with hbmk2 to interpret the PRG ( in case we can't change the source for that ).

Have you tried something already?

[Bacco]

Hi, Lailton

Couldn't do much about it this month, as I'm focusing on other tasks

at hand, but I'll give feedback if I came to implement it in a meaningful

way (not in the top of priorities right now).

I did a quick try after my last mail, but coudn't make it run recompiling

HB partially, perhaps I'm missing some step (or looking at the wrong

place completely).

At first glance it seems if I create a c string somewhere I can override

the default "ENDTEXT" keyword (restricted to the .prg where the overide

#pragma occurs, but couldn't see the whole picture (if it's only on ppcore.c,

what dependencies and so on, as I didn't have any feedback from the

devs who touched this part).

Anyway, I'll post in this thread if I make it work.

Regards,

Bacco

To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-devel/51fbe652-9ffa-4ac4-aad2-e8d2a96de63en%40googlegroups.com.