Xailer for Harbour

[Jose F. Gimenez]

Hi all,

FYI, Xailer has been successfully ported to Harbour, and it's already
available for download (including a demo) from our web site. For now, it
works with BCC++, and our next step is to start using MinGW.

We've also written a small "Migration guide to Harbour", which could be
useful for anybody who want to jump from xHarbour to Harbour, even
without Xailer. It covers the main issues we have found while porting
Xailer. This guide is here:
http://www.xailer.com/dokuwiki/doku.php?id=en:migrar.de.xharbour.a.harbour


Regards,

Jose F. Gimenez
http://www.xailer.com
http://www.xailer.info

[M., Ronaldo]

Hi Jose !

My choice is to use M$
http://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCsQFjAA&url=http%3A%2F%2Fwww.microsoft.com%2Fvisualstudio%2F&ei=Uk14UJOcLau20AHl8YCwBQ&usg=AFQjCNGVuBiWOJhjm7E95igaoAaTY9Dvjw

Regards

[M., Ronaldo]

Hi Jose !


I expect you reserve at least a half part of Xalier sales to Harbour Team...


Regards

[Przemyslaw Czerpak]

On Fri, 12 Oct 2012, Jose F. Gimenez wrote:

Hi Jose,

> FYI, Xailer has been successfully ported to Harbour, and it's
> already available for download (including a demo) from our web site.
> For now, it works with BCC++, and our next step is to start using
> MinGW.

Good news. Thank you.

> We've also written a small "Migration guide to Harbour", which could
> be useful for anybody who want to jump from xHarbour to Harbour,
> even without Xailer. It covers the main issues we have found while
> porting Xailer. This guide is here: http://www.xailer.com/dokuwiki/doku.php?id=en:migrar.de.xharbour.a.harbour

I have few notes about it.
I tried to collect most important differences in in doc/xhb-diff.txt file.
If you read it then you will find more differences and also some detail
explanation about them.
- for GLOBALs read section: GLOBAL / GLOBAL EXTERNAL (GLOBAL_EXTERN)
- IN operator is one of few xHarbour operators defined as identifier,
details in section: IN, HAS, LIKE OPERATORS
- differences in SWITCH statement are in section: NEW LANGUAGE STATEMENTS (3)
- TRY / CATCH / END is not emulated in Harbour. In xHarbour TRY gives
exactly the same behavior as BEGIN SEQUENCE WITH { |e| break(e) }
(the default errorBlock() is replaced by {|e|break(e)} and the exception
is stored on HVM stack so it's limited to such case more general
extension which exists in Harbour. See NEW LANGUAGE STATEMENTS (4)
- object members as indexes in FOR / NEXT loops.
This is new for me. I didn't know about this xHarbour extension.
I'll rethink it and add this functionality or document the difference
in xhb-diff.
- using [] operator to access string characters. It's possible in Harbour
but not enabled by default. See: USING [] OPERATOR FOR STRING ITEMS
Modifing the string inside FOR EACH c IN @cVal is Harbour only
extension. See: NEW LANGUAGE STATEMENTS (1)
- Negative indexes also can be enable din Harbour, loo at section:
NEGATIVE INDEXES IN [] OPERATOR USED TO ACCESS ITEMS FROM TAIL
- Pseudo functions like HB_QWith() and HB_EnumIndex() are also supported
by Harbour in XHB compatibility library: NEW LANGUAGE STATEMENTS (1&2)
- the differences in function names and parameters are usually cover by
hb_compat.ch - look at this file for details.
- the difference with implicit :NEW() call in xHarbour class function
is much more complicated then you described. Look at section
OOP AND CLASS OBJECT/CLASS MESSAGES
for more information.
- The scopes differences are also more complicated, read these sections:
OOP SCOPES
OOP AND PRIVATE/HIDDEN DATAs
By default hidden messages are nonvirtual in Harbour. It can be
disabled at Harbour compile time by HB_VIRTUAL_HIDDEN anyhow I do not
suggest to use it.
Please also read TYPED OBJECT VARIABLES because this functionality often
creates problems for xHarbour users porting their code to Harbour.

I have also few questions:
- "SetKey is a reserved word"
I have never heard about such limitation in Harbour.
Is it local Xailer requirement or I missed something?
- "You must use the Harbour distro provided by Xailer Harbour due to a
necessary modification in the classes.c module in order to perform our
OOP extensions. The modification consists in the addition of only two
small functions at the end of the module."
Can you send me the patch?
Simple result of
svn diff > xailer.diff
is enough.
I'll check if I it can be included in SVN.

best regards,
Przemek

[Jose F. Gimenez]

Przemek,

thank you very much for taking the time to review it.

> I have few notes about it.
> I tried to collect most important differences in in doc/xhb-diff.txt file.
> If you read it then you will find more differences and also some detail
> explanation about them.

I know about that file, and I've readed it some times. The guide I wrote
for Xailer users is smaller, and do not try to cover all differences,
but only those that are usual for Xailer users, and indeed from the
point of view of Xailer users. In fact, it covers, one by one, all cases
we have encountered when porting Xailer itself. Nothing less nothing
more. Another reason to write it was that I started doing it in spanish
(this is the language for more than 50% Xailer users). It was translated
into english later.

Your xhb-diff.txt file is much more detailed, and covers all differences
from the point of view of a hb developer or an advanced user; much more
than a regular user.

Below, I've marked some items:
(1) I didn't try to explain better, since I though it was enough for
Xailer users.
(2) it's our target to not emulate xHarbour at all. Instead, we want to
be Harbour compliant. So, we're not using hbcompat.ch

> - for GLOBALs read section: GLOBAL / GLOBAL EXTERNAL (GLOBAL_EXTERN)
> - IN operator is one of few xHarbour operators defined as identifier,
> details in section: IN, HAS, LIKE OPERATORS
> - differences in SWITCH statement are in section: NEW LANGUAGE STATEMENTS (3)

(1)

> - TRY / CATCH / END is not emulated in Harbour. In xHarbour TRY gives
> exactly the same behavior as BEGIN SEQUENCE WITH { |e| break(e) }
> (the default errorBlock() is replaced by {|e|break(e)} and the exception
> is stored on HVM stack so it's limited to such case more general
> extension which exists in Harbour. See NEW LANGUAGE STATEMENTS (4)

Well, here I found a tiny difference, not exactly in TRY/CATCH but
related with it. In Harbour, when an error happens inside a TRY/CATCH
it's not possible to get the offending line where the error ocurrs.
xHarbour has :procname and :procline vars in error object, wchich are
filled upon the error ocurrs, but Harbour doesn't have them. When you
receive the error object at CATCH clause, the offending line is not
already in call stack.

> - object members as indexes in FOR / NEXT loops.
> This is new for me. I didn't know about this xHarbour extension.
> I'll rethink it and add this functionality or document the difference
> in xhb-diff.

;-)

> - using [] operator to access string characters. It's possible in Harbour
> but not enabled by default. See: USING [] OPERATOR FOR STRING ITEMS
> Modifing the string inside FOR EACH c IN @cVal is Harbour only
> extension. See: NEW LANGUAGE STATEMENTS (1)
> - Negative indexes also can be enable din Harbour, loo at section:
> NEGATIVE INDEXES IN [] OPERATOR USED TO ACCESS ITEMS FROM TAIL
> - Pseudo functions like HB_QWith() and HB_EnumIndex() are also supported
> by Harbour in XHB compatibility library: NEW LANGUAGE STATEMENTS (1&2)
> - the differences in function names and parameters are usually cover by
> hb_compat.ch - look at this file for details.

(2)

> - the difference with implicit :NEW() call in xHarbour class function
> is much more complicated then you described. Look at section
> OOP AND CLASS OBJECT/CLASS MESSAGES
> for more information.

I know about class objects or meta-classes. Trust me that every case of
using parameters in class functions was a mistake, not intended. In
fact, there was only 1 ocurrence in all Xailer source code. For me, it's
a bad feature in xHarbour, which caused me to spend a long while to find
the error.

> - The scopes differences are also more complicated, read these sections:
> OOP SCOPES
> OOP AND PRIVATE/HIDDEN DATAs
> By default hidden messages are nonvirtual in Harbour. It can be
> disabled at Harbour compile time by HB_VIRTUAL_HIDDEN anyhow I do not
> suggest to use it.

(1) (2)

> Please also read TYPED OBJECT VARIABLES because this functionality often
> creates problems for xHarbour users porting their code to Harbour.

Oh yes, I know. We used it in all Xailer code only for intellisense,
since xHarbour ignores it at all. Now, in Harbour, we faced the problem.
At the end, we are using it in the same way, but only for our class
commands (PROPERTY and COMPONENT).

> I have also few questions:
> - "SetKey is a reserved word"
> I have never heard about such limitation in Harbour.
> Is it local Xailer requirement or I missed something?

It was a mistake from me, sorry. Some years ago, in an early Xailer
version, we had a function SetKey(). Later, to avoid collision with the
original SetKey() function, we renamed it into XA_SetKey(), and added a
#translate SetKey() => XA_SetKey(). It's what was confusing me, and I
wrongly though that SetKey() was a reserved word.

> - "You must use the Harbour distro provided by Xailer Harbour due to a
> necessary modification in the classes.c module in order to perform our
> OOP extensions. The modification consists in the addition of only two
> small functions at the end of the module."
> Can you send me the patch?
> Simple result of
> svn diff > xailer.diff
> is enough.
> I'll check if I it can be included in SVN.

Yes, of course. I've attached it. The needed functions are
hb_clsGetMethodData() and hb_clsSetMethodData(). The function
__SetClassScope() was added later for convenience, but it could be dropped.
I sent you a private email a few weeks ago, but I suppose it was missing.

[Przemyslaw Czerpak]

On Mon, 15 Oct 2012, Jose F. Gimenez wrote:

Hi,

> >- object members as indexes in FOR / NEXT loops.
> > This is new for me. I didn't know about this xHarbour extension.
> > I'll rethink it and add this functionality or document the difference
> > in xhb-diff.
> ;-)

It was and is possible to use object members as FOR iterators in Harbour.
Such syntax is legal:
FOR obj:var := 1 TO 10
? obj:var
NEXT
this one also:
FOR self:var := 1 TO 10
? obj:var
NEXT
just like this one:
FOR (::var) := 1 TO 10
? obj:var
NEXT
due to bug in lexer only this version was not supported:
FOR ::var := 1 TO 10
? obj:var
NEXT
I've just fixed it.
Thank you for the informaiton.

> >- "You must use the Harbour distro provided by Xailer Harbour due to a
> > necessary modification in the classes.c module in order to perform our
> > OOP extensions. The modification consists in the addition of only two
> > small functions at the end of the module."
> > Can you send me the patch?
> > Simple result of
> > svn diff > xailer.diff
> > is enough.
> > I'll check if I it can be included in SVN.
>
> Yes, of course. I've attached it. The needed functions are
> hb_clsGetMethodData() and hb_clsSetMethodData(). The function
> __SetClassScope() was added later for convenience, but it could be
> dropped.
> I sent you a private email a few weeks ago, but I suppose it was missing.

I had to miss this message.

Can you explain why you need hb_clsGetMethodData() and hb_clsSetMethodData()
functions?
They do not respect neither instance area offset nor class variable
offset so their result is unpredictable in multi ancestor classes
or when user uses super/class casting.

best regards,
Przemek

[Jose F. Gimenez]

Przemek,

> It was and is possible to use object members as FOR iterators in Harbour.
> Such syntax is legal:
> FOR obj:var := 1 TO 10
> ? obj:var
> NEXT
> this one also:
> FOR self:var := 1 TO 10
> ? obj:var
> NEXT
> just like this one:
> FOR (::var) := 1 TO 10
> ? obj:var
> NEXT
> due to bug in lexer only this version was not supported:
> FOR ::var := 1 TO 10
> ? obj:var
> NEXT
> I've just fixed it.
> Thank you for the informaiton.

Fantastic! Thanks for the fix. We'll update our guide ASAP.

> I had to miss this message.

Don't worry. I could resend it to you if needed. For now, I think it's
better to center in the main issue.

> Can you explain why you need hb_clsGetMethodData() and hb_clsSetMethodData()
> functions?
> They do not respect neither instance area offset nor class variable
> offset so their result is unpredictable in multi ancestor classes
> or when user uses super/class casting.

I need a place inside PMETHOD to store an int value. I need it only for
methods, not vars, so I decided to used the member uiData from PMETHOD,
which is always 0 for methods. Notice that I cannot alter the PMETHOD
struct on my side, because it causes to be incompatible at binary level.

Of course, the more general and prefered solution were to add a new
member to that struct (f.e. a member called 'cargo' to mimic Clipper's
classes). It's also a common practice in windows and its 'common
controls' which use to has a 'lparam' member in many structs. That
'cargo' member could be a void *, so anybody could use it for any
pourpose by storing a pointer to an own struct or data of any kind.

[Przemyslaw Czerpak]

On Wed, 24 Oct 2012, Jose F. Gimenez wrote:

Hi Jose,

> >Can you explain why you need hb_clsGetMethodData() and hb_clsSetMethodData()
> >functions?
> >They do not respect neither instance area offset nor class variable
> >offset so their result is unpredictable in multi ancestor classes
> >or when user uses super/class casting.
> I need a place inside PMETHOD to store an int value. I need it only
> for methods, not vars, so I decided to used the member uiData from
> PMETHOD, which is always 0 for methods. Notice that I cannot alter
> the PMETHOD struct on my side, because it causes to be incompatible
> at binary level.
>
> Of course, the more general and prefered solution were to add a new
> member to that struct (f.e. a member called 'cargo' to mimic
> Clipper's classes). It's also a common practice in windows and its
> 'common controls' which use to has a 'lparam' member in many
> structs. That 'cargo' member could be a void *, so anybody could use
> it for any pourpose by storing a pointer to an own struct or data of
> any kind.

All such things you can easy made yourself in your code without
touching HVM.
I'm attaching code with hb_clsGetMethodData() and hb_clsSetMethodData()
implemented completely out of HVM classy code. You can easy modify it
to store any values, not only HB_USHORT ones and also change indexes
to strings if you need it. Unlike fixed cargo such solution does not
create conflicts when few different users (library authors) wants to
use such extension because each of them can implement and use it
independently.

best regards,
Przemek

[Jose F. Gimenez]

Przemek,

thank you very much. I really apreciate your help, indeed.

> All such things you can easy made yourself in your code without
> touching HVM.
> I'm attaching code with hb_clsGetMethodData() and hb_clsSetMethodData()
> implemented completely out of HVM classy code. You can easy modify it
> to store any values, not only HB_USHORT ones and also change indexes
> to strings if you need it. Unlike fixed cargo such solution does not
> create conflicts when few different users (library authors) wants to
> use such extension because each of them can implement and use it
> independently.

I've been playing with this solution. The bad side is that due to using
a hash, it's noticeable slower in those operations where I need those
functions, so I've implemented it by using faster structures, at the
cost of a bit more memory usage. However it's a very good trick, which I
didn't realize when I was dealing with it.

Now, we're able to run Xailer on an unmodified Harbour. I hope that a
new official release of Harbour could be published soon ;-)

Thank you very much again.