On Tue, 16 Jun 2009, Pritpal Bedi wrote:
Hi,
> > I just wanted to suggest you something like that.
> > I'll add HB_WALIST()/HB_WAEVAL() functions which should help in
> > writing function to iterate workareas.
> If you are into that:
> Xbase++ functions to this effect:
> Syntax
> WorkSpaceList( [<nWorkSpace>] ) --> aAliasNames
This function suggest that xbase++ force unique aliases for each workarea
what is not Clipper compatible. CA-Clipper allows to use empty alias for
each workarea, i.e. what xbase++ shows in this code:
proc main()
dbCreate( "_tst", { { "F","C",10,0 } } )
use _tst alias "" new shared
? select(), used(), "["+alias()+"]"
use _tst alias "" new shared
? select(), used(), "["+alias()+"]"
wait
return
The second thing which we can find is the fact that in ZEROSPACE we cannot
store workareas with repeated alias names. But the documentation you sent
before to dbRequest()/dbRelease() says:
,----------------------------------------------------------------------------
| The transfer of alias names follows the FIFO principle (First in first out).
| If the Zero space contains multiple alias names, DbRequest() transfers the
| alias that was released first. If <cAlias> is specified DbRequest()
| transfers the first alias name that matches <cAlias> . For more information,
| refer to function DbRelease().
`----------------------------------------------------------------------------
The above suggests that multiple aliases can match <cAlias>.
In Harbour hb_waDetach()/hb_waRequest() respects it.
IMHO just like relation references this part also does not work correctly
in xbase++. This code should confirm it:
proc main()
dbCreate( "_tst", { { "F","C",10,0 } } )
use _tst alias "tst1" new shared
dbRelease()
use _tst alias "tst1" new shared
dbRelease()
aeval( WorkSpaceList( 2 ), {|s, i| qout( i, s ) } )
wait
return
Sth has to work in different way then expected and documented.
Anyhow I can implement such function in Harbour but it will
return repeated alias names if such situation happens.
> WorkSpaceEval( <bAreaBlock>, [<nWorkSpace>] ) --> nProcessed
It's not clear for me how they implemented ZEROSPACE iteration without
breaking some other rules and personally I have very serious doubts
they resolved all possible problems.
I have not information about ZEROSPACE locking. What will happen
if two threads will try to execute WorkSpaceEval() and/or some others
threads dbRelease()/dbRequest()?. I have no information in which
workspace codeblock is executed. How WA are transferred before and
during iteration. What happens when alias conflicts can appear.
If you can check all of the above (documentation does not say anything
about that and as we can see is really far from real behavior so we cannot
trust it and have to confirm the exact behavior by tests) then I can try
to implement of course if final version does not introduce some bad
anomalies and I'm not sure it doesn't.
> It will be nice if you used above namespace.
> We will be more near to Xbase++.
See above. I have nothing against but I have to know what I should
implement.
As long as we do not touch ZEROSPACE then you can implement them yourself
as .prg wrappers to hb_waEval(), i.e.:
function WorkSpaceList( nWorkSpace )
local aAliasNames := {}
// ZEROSPACE is unsupported
if valtype( nWorkSpace ) != "N" .or. nWorkSpace != 2
hb_waEval( {|| aadd( aAliasNames, alias() ) } )
endif
return aAliasNames
function WorkSpaceEval( bCode, nWorkSpace )
local nCount := 0
// ZEROSPACE is unsupported
if valtype( nWorkSpace ) != "N" .or. nWorkSpace != 2
hb_waEval( {|| eval( bCode ), ++nCount } )
endif
return nCount
Support for ZEROSPACE in WorkSpaceList() is trivial but can be implemented
only in C. I can add it in necessary. BTW please check above two example
with xbase++.
Support for ZEROSPACE in WorkSpaceEval() it's much more complicated and
personally I do not like it because it has to introduce some exceptions/
anomalies. If some well check what xbase++ does then I can replicate this
behavior in some compatibility library but only if it will not be source
of some serious bugs.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
