Environment

[Darkwood]

Hi!

I keep getting errors like the E0054 posted below (which nobody has commented on), and I am wondering if I have incorrect environment settings. I loaded Alaska xbase++ demo after the xHarbour demo, and I am wondering if some settings were over-written.

If someone could capture their environment (set >set.txt), remove the non-xharbour stuff, and post it here I would really appreciate it.

Mike

[Ron Pinkas]

Hi Mike,

Sorry, I don't see which prior post you talk about. Please post again.
Rather then speculate that you have some environment problem, I would prefer
to learn about the actual error you experienced.

Ron

"Darkwood" <darkwoodc...@gmail.com> wrote in message
news:2efda55f-0531-44c8...@googlegroups.com...

[dlzc]

Dear Ron Pinkas:

On Sunday, November 11, 2012 7:51:41 AM UTC-7, Ron Pinkas wrote:
...

> Sorry, I don't see which prior post you talk
> about. Please post again.

https://groups.google.com/d/topic/comp.lang.xharbour/8p1svqAlZ3I/discussion

> Rather then speculate that you have some
> environment problem, I would prefer to learn
> about the actual error you experienced.

David A. Smith

[druzus]

This and similar problems were reported few times in the past. Also by
me. They are created by not thought WITH OBJECT syntax. It was
necessary to break Clipper PP rules to make code like this working:

WITH OBJECT errorNew()
? :canDefault
END

Now PP accept as expressions starting with ":" character what is the
source of problem just like in your example (conflict with LIST ...
command) and also many other ones, i.e.:

proc main
local xVar, get
@ 0, 0 SAY xVar PICTURE get:pict
return

And the bad thing is that it cannot be well fixed without removing
current WITH OBJECT syntax and replacing it by some different
construction which respects Clipper PP rules. In Harbour I added hack
which allows to compile above examples but it's not real solution.
To fix it new construction should use some variable name, i.e. it can
be more general and powerful for programmer:

WITH VARIABLE <newVarName> [:= <initValue> ]
...
ENDWITH

or at least we should change the prefix of "with" object messages,
i.e. use "." instead of ":"

WITH OBJECT errorNew()
? .canDefault
END

best regards,
Przemek

[Andi Jahja]

A self-containe sample is as follows:


--- 8< ---
Procedure Main()

Local List := Foo()
List:Bar := 1
--- 8< ---

This result in:
Error E0054 WITH Message [BAR] with no WITH OBJECT in sight.

But if we change List with something, it'll be OK.

--- 8< ---
Procedure Main()

Local oList := Foo()
oList:Bar := 1
--- 8< ---

I wonder if there is a special treatment for the word "List", I'll
investigate.

Andi

[Andi Jahja]

A self-containe sample is as follows:


--- 8< ---
Procedure Main()

Local List := Foo()
List:Bar := 1
--- 8< ---

This result in:
Error E0054 WITH Message [BAR] with no WITH OBJECT in sight.

But if we change List with something, it'll be OK.

--- 8< ---
Procedure Main()

Local oList := Foo()
oList:Bar := 1
--- 8< ---

I wonder if there is a special treatment for the word "List", I'll
investigate.

Andi

On Sun, 11 Nov 2012 06:51:37 -0800, "Ron Pinkas"
<Ron.Pinkas_...@xHarbour.com> wrote:

[druzus]

On 14 Lis, 10:14, andija...@internet.com (Andi Jahja) wrote:
> A self-containe sample is as follows:
> --- 8< ---
> Procedure Main()
> Local List := Foo()
> List:Bar := 1
> --- 8<  ---
>
> This result in:
> Error E0054  WITH Message [BAR] with no WITH OBJECT in sight.
>
> But if we change List with something, it'll be OK.

Anyhow this is valid Clipper code and xHarbour cannot compile it.
Just like many other similar examples:

/*** t01.prg ***/
proc main()
local display := foo()
display:msg()
return

/*** t02.prg ***/
proc main()
local seek := foo()
seek:show()
return


/*** t03.prg ***/
proc main()
local go := foo()
go:msg2()
return


/*** t04.prg ***/
// this is even worser because it does not cause compile time error
// but wrong code is generated, see .ppo file
proc main()
local dir := foo()
dir:parse()
return

best regards,
Przemek

[Andi Jahja]

Yes, all key words used in std.ch, which are burnt into pptable during
make process will cause this error.

As you are the designer of xHarbour pp (as per copyright), could you
please give us hints how to correct this situation without
reengineering with object related things?

Thanks in advance.

Andi

PS: for xHarbour users, pending the solution to this matter, it is
recommended that key words are not used for variables. Fe. in the
poster's snippet , LIST is used as command (see std.ch)

[druzus]

On 15 Lis, 11:04, andija...@internet.com (Andi Jahja) wrote:
> Yes, all key words used in std.ch, which are burnt into pptable during
> make process will cause this error.

It can cause conflicts with any PP rules also with the ones used by 3-
rd party
projects or in other harbour headers, i.e. clonflicts with hbclass.ch:

/*** t05.prg ***/
#include "hbclass.ch"
proc main()
local method := foo(), access := bar(), assign := too()
method:disp()
access:show()
assign:hide()
return

if variable names like 'method', 'access' or 'assign' are too exotic
for you then try other ones like 'data' or 'var':

/*** t06.prg ***/
#include "hbclass.ch"
proc main()
local data := foo(), var := bar()
data:get()
var:put()
return

> As you are the designer of xHarbour pp (as per copyright), could you
> please give us hints how to correct this situation without
> reengineering with object related things?

There is no way to fix it and keep current WITH OBJECT functionality
because exactly the same code can have different meaning, i.e.:

>
> Thanks in advance.
>
> Andi
>
> PS: for xHarbour users, pending the solution to this matter, it is
> recommended that key words are not used for variables. Fe. in the
> poster's snippet , LIST is used as command (see std.ch)

Not enough. See conflict with hbclass.ch above.
You should see _ALL_ .ch files you are using and do not use any
variable names for objects which can create conflicts with PP rules
defined in them.

best regards,
Przemek

[druzus]

Ups, looks that part of the message has been lost, let's try again

> As you are the designer of xHarbour pp (as per copyright), could you
> please give us hints how to correct this situation without
> reengineering with object related things?

There is no way to fix it and keep current WITH OBJECT functionality
because exactly the same code can have different meaning, i.e.:

PROC main()
LOCAL obj := foo(), go := bar()
WITH OBJECT obj
go:recno() // execute GO command with :recno() parameter
from WITH OBJECT obj
go:recno() // execute recno() method in GO object
END
RETURN

I created current PP uses by Harbour and xHarbour anyhow I'm really
sorry but I cannot create code clever enough to guess what programmer
needs and decode the same line in different ways. So far we do not
have hardware interface with programmer brain to extract informations
necessary for proper decision ;-)

The only one thing I can propose is hack which reduces the conflict in
the situations when there is no space before ':'
Just simply when there is no space before ':' then it cannot be
accepted as PP expression so in example above in both cases we will
have go object method call and if programmer wants to execute GO
command with :recno() value from WITH OBJECT obj then he has to use:
go :recno()
I already implemented it in Harbour and xHarbour to reduce the problem
(which still exists because Clipper behaves differently) but few years
ago Ron removed it from xHarbour. You can ask him why. Probably he
didn't know problems he created with this ill WITH OBJECT syntax.
If you can agree what to do with it then you can restore it. For me
this subject is closed and I only hope that in the future new
'features' will be better designed.

best regards,
Przemek

[Andi Jahja]

OK, thanks a lot.

Andi

[Andi Jahja]

On Thu, 15 Nov 2012 04:29:09 -0800 (PST), druzus
<przemysla...@gmail.com> wrote:

>> PS: for xHarbour users, pending the solution to this matter, it is
>> recommended that key words are not used for variables. Fe. in the
>> poster's snippet , LIST is used as command (see std.ch)
>
>Not enough. See conflict with hbclass.ch above.
>You should see _ALL_ .ch files you are using and do not use any
>variable names for objects which can create conflicts with PP rules
>defined in them.

Yes. Pending the resolution on PP, then I am planning to create a list
of those words, plug them in when generating codes, so that
harbour.exe will reject any object name similar to the one that
contained in the list. This is a hack for good, IMO, there is no
reason one should entertain/stick to a name if there are millions
other available - fe. there is no penalty to use MYLIST instead of
LIST :-)

Andi

[Andi Jahja]

On Thu, 15 Nov 2012 13:58:00 GMT, andi...@internet.com (Andi Jahja)
wrote:

More transaparently, we could during code generation change the name
:-), to entertain programmers to freely use the 'key' words, but this
is very brutal, IMO.

Hello Ron, if you read this forum, please say something.

Andi

[Enrico Maria Giordano]

> go :recno()

If there is no complete solution I vote for the above. I think it's very
common to leave a space between commands and their parameters. It looks
better than creating a list of reserved names (how do you know the PP names
used by any possible third party libraries?).

EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic

[dlzc]

On Thursday, November 15, 2012 7:37:57 AM UTC-7, Enrico Maria Giordano wrote:
...

> > go :recno()
>
> If there is no complete solution I vote for the
> above. I think it's very common to leave a space
> between commands and their parameters. It looks
> better than creating a list of reserved names
> (how do you know the PP names used by any
> possible third party libraries?).

I second the motion. If it matters.

David A. Smith

[Saulius]

Hi,

...

>> go :recno()
>
> If there is no complete solution I vote for the above. I think it's very common to leave a space between
> commands and their parameters. It looks better than creating a list of reserved names (how do you know the
> PP names used by any possible third party libraries?).

I am third :-)
Nothing terrible to assume in rules, that every "<SPACE>:name" will be grabbed
within WITH OBJECT obj ... END body.

Saulius

[Andi Jahja]

On Thu, 15 Nov 2012 15:37:58 +0100, "Enrico Maria Giordano"
<e.m.gi...@emagsoftware.it> wrote:

>> go :recno()
>
>If there is no complete solution I vote for the above. I think it's very
>common to leave a space between commands and their parameters. It looks
>better than creating a list of reserved names

Sorry, but I am not interested with the syntax. Looks very ugly. The
big part of creating a reserved list is done automatically by ppgen.
Minor additions may be added later.

> (how do you know the PP names used by any possible third party libraries?).

No worry about it. The rejection of PP names as variable is done
during compile time. So, if the 3rd lib was built before the current
version _AND_ uses PP names, it will still work. But, if the 3rd party
lib is about to be rebuilt, then the progammer has to change those
names.

Andi