Przemyslaw, I tried to backport the latest hash patch but without success

[Lorenzo Fiorini]

A small test seems to work but the real apps don't work as expected.

No errors, simply strange things that suggest that hashes are not managed correctly.

Reverting the change fix everything.

I would need to have it in:
hvm.c 15841 2010-11-19 10:11:29Z druzus

and the code is the one below.

Is there any chance?

best regards,
Lorenzo

--------

static void hb_vmHashGen( HB_SIZE nElements ) /* generates an nElements Hash and fills it from the stack values */
{
   HB_STACK_TLS_PRELOAD
   PHB_ITEM pHash, pKey, pVal;

   HB_TRACE(HB_TR_DEBUG, ("hb_vmHashGen(%" HB_PFS "u)", nElements));

   /* create new hash item */
   pHash = hb_hashNew( NULL );
   hb_hashPreallocate( pHash, nElements );
   while( nElements-- )
   {
      pKey = hb_stackItemFromTop( -2 );
      pVal = hb_stackItemFromTop( -1 );
      if( HB_IS_HASHKEY( pKey ) )
      {
         hb_hashAddNew( pHash, pKey, pVal );
         hb_stackPop();
         hb_stackPop();
      }
      else
      {
         hb_errRT_BASE( EG_BOUND, 1133, NULL, hb_langDGetErrorDesc( EG_ARRASSIGN ), 3, pHash, pKey, pVal );
         break;
      }
   }
   hb_itemMove( hb_stackAllocItem(), pHash );
   hb_itemRelease( pHash );
}

-------

[Przemyslaw Czerpak]

On Fri, 24 May 2013, Lorenzo Fiorini wrote:

Hi,

> A small test seems to work but the real apps don't work as expected.
> No errors, simply strange things that suggest that hashes are not managed
> correctly.
> Reverting the change fix everything.
>
> I would need to have it in:
> hvm.c 15841 2010-11-19 10:11:29Z druzus
>
> and the code is the one below.
> Is there any chance?

I do not remember what exactly was in this version but it should be enough
to copy current hb_vmHashGen() code as is to the old repository.
Did you try to make it?

best regards,
Przemek

[Lorenzo Fiorini]

On Mon, May 27, 2013 at 2:06 PM, Przemyslaw Czerpak <dru...@poczta.onet.pl> wrote:

 

I do not remember what exactly was in this version but it should be enough
to copy current hb_vmHashGen() code as is to the old repository.
Did you try to make it?

Yes, it was what I did. I applied the diffs in hvm.c and hbapi.h.

I'll try again and report.

best regards,

Lorenzo

[Lorenzo Fiorini]

On Mon, May 27, 2013 at 4:08 PM, Lorenzo Fiorini <lorenzo...@gmail.com> wrote:

I'll try again and report.

 

I've just tried the to port the patch to my local 3.2.0 git: same result.

Strange unrelated rt errors like: No exported method CHARTS while the method exist.

Reverting the change fix everything.

best regards,
Lorenzo

[Przemyslaw Czerpak]

On Mon, 27 May 2013, Lorenzo Fiorini wrote:

Hi,

> I've just tried the to port the patch to my local 3.2.0 git: same result.
> Strange unrelated rt errors like: No exported method CHARTS while the
> method exist.
> Reverting the change fix everything.

It should not happen so I can only guess that it interacts with some
other code which exists in the Harbour version you are using.
Maybe hb_stackItemFromTop( n ) uses more then once n arg?
In such case replaceing:
pKey = hb_stackItemFromTop( iPos++ );
pVal = hb_stackItemFromTop( iPos++ );
with:
pKey = hb_stackItemFromTop( iPos );
iPos++;
pVal = hb_stackItemFromTop( iPos );
iPos++;
should resolve the problem.
BTW why are you using this version of Harbour?

best regards,
Przemek

[Lorenzo Fiorini]

On Tue, May 28, 2013 at 12:54 PM, Przemyslaw Czerpak <dru...@poczta.onet.pl> wrote:

 

BTW why are you using this version of Harbour?

In this last test I used the actual git plus some local changes:

- #define HB_PP_MULTILINE_STRINGS in ppcore.c

- #define HB_EXT_INKEY in inkey.ch to fix things K_CTRL_C vs PgDn

- a custom teditor.prg and memoedit.prg in rtl to manage text selection and copy/cut/paste

- few local changes in some contribs

before I used a pre-3.0 version that I consider stable with the same local changes.

best regards,

Lorenzo

[Przemyslaw Czerpak]

On Tue, 28 May 2013, Lorenzo Fiorini wrote:

Hi,

> In this last test I used the actual git plus some local changes:
> - #define HB_PP_MULTILINE_STRINGS in ppcore.c
> - #define HB_EXT_INKEY in inkey.ch to fix things K_CTRL_C vs PgDn

This is not necessary in current GT code.
You can use new extended inkey codes which give much more power
flexibility then the old ones.
In this patch:
2013-04-22 15:38 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
I updated most important core GT drivers to work with new keyboard and
mouse code (in some spare time I'll update yet GTWIN, GTDOS and GTOS2).
Unlike the previous solution now all translations are done dynamically
and can be enabled by users which need extended key codes at runtime
so it's not necessary to create separate build for it.
If you enable HB_INKEY_EXT inkey mask (in 2-nd INKEY() parameter or by
_SET_EVENTMASK then you wil receive extended inkey code which contains
keycode part (HB_KX_*) and modifiers (shift, ctrl, alt, keypad, HB_KF_*)
You can translate such extended key code to standard Clipper ones by:
hb_keyStd( nExtKey ) -> nClipKey
to character value (unicode and multibyte characters are fully supported):
hb_keyChar( nExtKey ) -> cStr
to extended xHarbour keycode (xhb.lib):
xhb_KeyTrans( nExtKey ) -> nXhbExtKey
or you can extract extended key (HB_KX_*) or character value by:
hb_keyVal( nExtKey ) -> nKeyCharVal
and modifiers bitfield (HB_KF_*) by:
hb_keyVal( nExtKey ) -> nKeyFlags
If you used to work with xHarbour extended key codes then you can simply
use xhb_Inkey() (xhb.lib) instead of Inkey().

> - a custom teditor.prg and memoedit.prg in rtl to manage text selection and
> copy/cut/paste

Someday whole TEDITOR just like ACHOICE and DBEDIT should be updated to
exactly mimic Clipper behavior and then extended if necessary. Now these
are the weakest parts of Harbour in case of strict Clipper compatibility.
Rest seems to be really perfect.

> - few local changes in some contribs
> before I used a pre-3.0 version that I consider stable with the same local
> changes.

We have some important fixes and extensions from this time.

best regards,
Przemek

[Lorenzo Fiorini]

On Tue, May 28, 2013 at 12:54 PM, Przemyslaw Czerpak <dru...@poczta.onet.pl> wrote:

 

It should not happen so I can only guess that it interacts with some
other code which exists in the Harbour version you are using.

Now I'm using an untouched git version and the problem still exists.

I've debug the code and the issue is raised by an empty hash value that suddenly become empty while it is not in other calls.

I have the issue in my http server ( that is in production pre-3.0 version of Harbour ) reading the values of the session.

The calls are likely done in parallel.

Could it be an MT issue?

p.s. The main reason I still use a pre 3.0 version, is because I need to have both ST and MT apps at the same time on the same server.

best regards,

Lorenzo

 

[Przemyslaw Czerpak]

On Tue, 28 May 2013, Lorenzo Fiorini wrote:

Hi,

> Now I'm using an untouched git version and the problem still exists.
>
> I've debug the code and the issue is raised by an empty hash value that
> suddenly become empty while it is not in other calls.
> I have the issue in my http server ( that is in production pre-3.0 version
> of Harbour ) reading the values of the session.
> The calls are likely done in parallel.
>
> Could it be an MT issue?

No untill you do not have some MT bugs in your code which were
exploited by different hash order.
IMHO the problem is that you have some broken hashes constatns
which have the same keys with different values, i.e.
local cKey1 := "abc", cKey2 := "abc"
local hVal := { cKey1 => 1, cKey2 => 2 }
In previous version above code created hash array with one elemnt:
{ "abc" => 2 }
and current code creates hash array like:
{ "abc" => 1 }
Just check it.
If this is the source of your problems then you can replace:

hb_hashAddNew( pHash, pKey, pVal );

with:
hb_hashAdd( pHash, pKey, pVal );
in hb_vmHashGen() function.

> p.s. The main reason I still use a pre 3.0 version, is because I need to
> have both ST and MT apps at the same time on the same server.

In current Harbour version we do not have ST version of harbour shared
library. In fact it only causes some speed overhead because MT code
uses HVM stack pointer stored in TLS. Anyhow if speed is critical then
you should not use shared harbour library because it has to be compiled
with -fPIC what for x86 also gives slower code then non relocatable
static libraries. Additionally when you run harbour application linked
with shared harbour libraries then at startup it register all functions
present in harbour.{so,dll,dyn,...} in HVM dynamic table not only the
one which could be linked with static binaries what creates additional
overhead.

best regards,
Przemek

[Lorenzo Fiorini]

On Tue, May 28, 2013 at 11:38 PM, Przemyslaw Czerpak <dru...@poczta.onet.pl> wrote:

 

In current Harbour version we do not have ST version of harbour shared

...

one which could be linked with static binaries what creates additional
overhead.

Thank you for your explanation.

My concern is more about stability than speed.

I'll do more tests and report.

best regards,

Lorenzo

[Przemyslaw Czerpak]

On Wed, 29 May 2013, Lorenzo Fiorini wrote:

Hi,

> Thank you for your explanation.
> My concern is more about stability than speed.
> I'll do more tests and report.

I do not know about any differences in stability between MT and ST HVM.
MT mode allows to access the same resources simultaneously from different
threads so if necessary user has to add sync code and this is his job.
Anyhow it cannot create any problems if only single thread is used.

best regards,
Przemek

[Massimo Belgrano]

have samebody a sample of sync code 
for learn from example
This is my collection regarding MultiThread

https://docs.google.com/document/d/1xxRphZ5TIGbn5rOWQ_35VVcw8Yex63A4MKXimfq0MVg/edit#bookmark=id.cpyy6cdekpyh

2013/5/29 Przemyslaw Czerpak <dru...@poczta.onet.pl>

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

--

Massimo Belgrano
Delta Informatica S.r.l. (http://www.deltain.it/mbelgrano)