Re: [Harbour] SF bug tracker#2906734: ClassMethod: Message not found (Error)
Przemek, > Neither Harbour nor xHarbour supports class objects like Class(y) > : Thanks you for your reply. Should I mark this report as a Feature Request and leave it open, or close it with "Not going to Fix" status? Chen. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13093] trunk/harbour
Revision: 13093 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13093&view=rev Author: vouchcac Date: 2009-12-02 06:38:02 + (Wed, 02 Dec 2009) Log Message: --- 2009-12-01 22:35 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/idemisc.prg * contrib/hbide/hbide.prg ! Fixed many-many artifacts including the restoring of last cursor position. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idemisc.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] RE: CHANGELOG: 2009-12-01 01:37 UTC-0800 Brian Hays
Przemek: Thanks. If I hear no other feedback, I'll remove the RTE so the code you described can still work. Does anyone else have an opinion as to whether it's useful to add the feature of an explicit NIL value to mean to "return to default direction" ? Or is it not worth the trouble, and unlikely to be supported in other RDDs anyway? -- Brian Hays > -Original Message- > From: Przemysław Czerpak [mailto:dru...@acn.waw.pl] > Sent: Tuesday, December 01, 2009 3:15 PM > To: bhays; 'Viktor Szakáts'; Harbour Project Main Developer List. > Subject: Re: CHANGELOG: 2009-12-01 01:37 UTC-0800 Brian Hays > > On Tue, 01 Dec 2009, Brian Hays wrote: > > > I need help with a decision on whether to throw an error or not. > Please see discussion below. > > 2009-12-01 01:37 UTC-0800 Brian Hays > Dynamic DESCEND flag is not supported also in many Clipper RDDs. > So far the standard way in Clipper and [x]Harbour to check if dynamic > descending order is supported was checking the value returned by: >ordDescend( [], [] ) > just after: >ordDescend( [], [], ) > i.e.: >ordDescend( nTag,, .T. ) >? "order:", iif( ordDescend( nTag ), "descending", "ascending" ) > > such code works for any RDDs and will work also for ADS if you do not > enable such RTE. > In all core native RDDs (NTX, CDX, NSX) I implemented dynamic descend > flags so such RTE cannot be generated so I think that it will be most > important for ADS users which without RTE can easy create the same code > for different ADS versions. > > > A second question: AdsSetIndexDirection takes an unusual flag that > > EITHER takes 0 to return to the original state, or TRUE to > > "reverse the direction from the current state" > > IOW, they have the ability to “go back to normal which IIUC > > Clipper/(x)Harbour does NOT. > To clarify some technical issues. > In indexes like CDX, ADI or NSX there is no "normal" state. > Physically they exist only in ascending order and descending > order is done by logical flag (BTW I'm surprised why adding > user interface to change such logical flag took such long time > ADS authors) so we can talk only about default settings for > this flag stored in index header. Only NTX format uses reverted > key orders in index file to implement default descending sorting > so in our DBFNTX I implemented both versions and it's possible > to use dynamic switching too just like in CDX or NSX formats. > > I guess that you are asking about method of "resetting" DESCEND > flag to value chose by RDD when index is open. So far we do not > have such functionality though it can be easy implemented if we > agree how to inform RDD that we want to "reset" this flag. > > > Am I missing something? It would be nice to have a value to "return > > to native state" in our syntax > > instead of requiring a close/re-open of the file. Note: Once the > > direction has been dynamically changed, ordDescend() is only > > capable of returning the CURRENT state; there is no > > api to get the Original direction setting. > > Please remember that we are always in native state. The order direction > is in practice only logical flag. Usually structural code have to safe > and restore descend flag settings because it cannot assume that it was > in the same state as after opening table. Operation like resetting > order > DESCEND flag to the same state as after opening table are not > structural > so are less usable in most of code. Probably the only one type of code > I can imagine is some DBU like program which may want to display some > information with default order settings. > > > In some COMIX functions, there was the difference between an explicit > NIL > > and an ignored parameter > > to distinguish between intentions. I never liked having to explain > it to > > people, BUT > > this may be an instance where explicitly passing NIL as the third arg > could > > be the flag > > to revert to the original state of the index. > > NIL can be used for such job. In such case it's necessary to modify > ordDescend() in dbcmd53.c and change: > pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_LOGICAL ); > to: > pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_LOGICAL ); > if( pOrderInfo.itmNewVal ) > pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_NIL ); > > > Is there a good way to add the extended value/functionality of either > > learning or setting the original direction? > > The other method is defining new DBOI_* action for dbInfo() to extract > default DESCEND flag settings which can be used as ordDescend() > parameter. > > best regards, > Przemek > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.426 / Virus Database: 270.14.67/2506 - Release Date: > 12/01/09 07:59:00 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13092] trunk/harbour
Revision: 13092 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13092&view=rev Author: druzus Date: 2009-12-02 03:18:45 + (Wed, 02 Dec 2009) Log Message: --- 2009-12-02 04:18 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/maindllp.c * harbour/contrib/gtwvg/wvgsink.c % removed redefined HBTEXT() macro Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/wvgsink.c trunk/harbour/src/vm/maindllp.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13091] trunk/harbour
Many thanks. Brgds, Viktor On 2009 Dec 2, at 03:12, dru...@users.sourceforge.net wrote: > Revision: 13091 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13091&view=rev > Author: druzus > Date: 2009-12-02 02:12:14 + (Wed, 02 Dec 2009) > > Log Message: > --- > 2009-12-02 03:12 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/doc/en-EN/hb_apifs.txt > * harbour/include/hbapifs.h > * harbour/src/rtl/filesys.c >* changed: > BOOL hb_fsSetDevMode( HB_FHANDLE hFileHandle, USHORT uiDevMode ) > to: > int hb_fsSetDevMode( HB_FHANDLE hFileHandle, int iDevMode ) > Now it returns previous mode for hFileHandle or -1 on error. > if iDevMode == 0 then it does not change device mode. > > * harbour/src/rtl/philes.c >* modified HB_FSETDEVMODE() function to work with new hb_fsSetDevMode() > Current syntax is: > HB_FSETDEVMODE( [, ] ) -> > It may return FD_BINARY, FD_TEXT or FS_ERROR. > > * harbour/src/rtl/philes53.c >* modified FSETDEVMOD() function to work with new hb_fsSetDevMode() > It's similar to HB_FSETDEVMODE() but returns FD_BINARY instead of > FS_ERROR. Such behavior is more closer to CL53. > > * harbour/src/rtl/console.c >* set also STDIN into binary mode > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/doc/en-EN/hb_apifs.txt >trunk/harbour/include/hbapifs.h >trunk/harbour/src/rtl/console.c >trunk/harbour/src/rtl/filesys.c >trunk/harbour/src/rtl/philes.c >trunk/harbour/src/rtl/philes53.c > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13091] trunk/harbour
Revision: 13091 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13091&view=rev Author: druzus Date: 2009-12-02 02:12:14 + (Wed, 02 Dec 2009) Log Message: --- 2009-12-02 03:12 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/doc/en-EN/hb_apifs.txt * harbour/include/hbapifs.h * harbour/src/rtl/filesys.c * changed: BOOL hb_fsSetDevMode( HB_FHANDLE hFileHandle, USHORT uiDevMode ) to: int hb_fsSetDevMode( HB_FHANDLE hFileHandle, int iDevMode ) Now it returns previous mode for hFileHandle or -1 on error. if iDevMode == 0 then it does not change device mode. * harbour/src/rtl/philes.c * modified HB_FSETDEVMODE() function to work with new hb_fsSetDevMode() Current syntax is: HB_FSETDEVMODE( [, ] ) -> It may return FD_BINARY, FD_TEXT or FS_ERROR. * harbour/src/rtl/philes53.c * modified FSETDEVMOD() function to work with new hb_fsSetDevMode() It's similar to HB_FSETDEVMODE() but returns FD_BINARY instead of FS_ERROR. Such behavior is more closer to CL53. * harbour/src/rtl/console.c * set also STDIN into binary mode Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/doc/en-EN/hb_apifs.txt trunk/harbour/include/hbapifs.h trunk/harbour/src/rtl/console.c trunk/harbour/src/rtl/filesys.c trunk/harbour/src/rtl/philes.c trunk/harbour/src/rtl/philes53.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13090] trunk/harbour
Revision: 13090 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13090&view=rev Author: vouchcac Date: 2009-12-02 02:11:32 + (Wed, 02 Dec 2009) Log Message: --- 2009-12-01 18:09 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg * contrib/hbxbp/xbpstatusbar.prg + Started information. Now XbpStatusBar() honors multiple panels. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbxbp/xbpstatusbar.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Initialization of static variables in loaded HRB
On Tue, 01 Dec 2009, Adam Lubszczyk wrote:
Hi,
> When the module HRB (or pcode-DLL) is loaded dynamically , You are looking
> for whether it was once used a similar table of symbols, and then it
> recycled.
> If it is recycled, then You do not initialize static variables.
Yes,
> There is a problem to perform re-initialization ?
In current code there are no technical problems.
I resolved existing problems which made such operation very
complicated adding MT support to Harbour.
But there are some logical code aspects where unconditional
reinitialization of static variables is not good option.
I.e. some codeblock may still exists after unloading .hrb module
and use static variables from this module. When module is loaded
second time without static variable reinitialization then they
can continue their work without any problems.
Such behavior allows to load, unload and load again code which
defines new classes. Reinitialization of static variables will
cause that after reloading all class functions will try to
register the same classes again.
> Lack of initialization of static variables, of course, provides additional
> possibilities, but I think only the EXTRA. Normally, I expect that re-loaded
> the module will behave just like the first time.
> There are also other problems, such as when we have different versions of
> the same function, and in the program we load modules several times.
> Sample:
> hrb1.prg -> hrb1.hrb
> FUNCTION abc()
> LOCAL x:="HRB1: ++2 from init static 30 - Now is:"
> STATIC y:=30
> y:=y+VAL("2")
> RETURN x+STR(y,5)
>
> hrb2.prg -> hrb2.hrb
> STATIC z:=70
> FUNCTION abc()
> LOCAL x:="HRB2: --3 from 70 initalized. Now is: "
> LOCAL w:=VAL("2")
> LOCAL s:=" plus "
> s:=s+"extra "
> z:=z-w
> --z
> s:=s+"string :)"
> RETURN x+STR(z,5)+s
>
> main.prg -> main.exe
> PROCEDURE MAIN
> LOCAL i,hh
> FOR i:=1 TO 2
> ? "HRB1 load by #",i
> hh:=HB_HRBLOAD("hrb1.hrb")
> ? "ABC()->",&("ABC()")
> ? "ABC()->",&("ABC()")
> ? "HBR1 unload #",i
> HB_HRBUNLOAD(hh)
> ? "HRB2 load by #",i
> hh:=HB_HRBLOAD("hrb2.hrb")
> ? "ABC()->",&("ABC()")
> ? "ABC()->",&("ABC()")
> ? "HBR2 unload #",i
> HB_HRBUNLOAD(hh)
> NEXT
> RETURN
> **
> We obtain the result:
>
> HRB1 load by # 1
> ABC()-> HRB1: ++2 from init static 30 - Now is: 32
> ABC()-> HRB1: ++2 from init static 30 - Now is: 34
> HBR1 unload # 1
> HRB2 load by # 1
> ABC()-> HRB2: --3 from 70 initalized. Now is:31 plus extra string :)
> ABC()-> HRB2: --3 from 70 initalized. Now is:28 plus extra string :)
> HBR2 unload # 1
> HRB1 load by # 2
> ABC()-> HRB1: ++2 from init static 30 - Now is: 30
> ABC()-> HRB1: ++2 from init static 30 - Now is: 32
> HBR1 unload # 2
> HRB2 load by # 2
> ABC()-> HRB2: --3 from 70 initalized. Now is:29 plus extra string :)
> ABC()-> HRB2: --3 from 70 initalized. Now is:26 plus extra string :)
> HBR2 unload # 2
>
> Strange result is not it?
> HRB2 get static value from HRB1 and vice versa !!!
It's expected behavior.
It allows to register and unregister .HRB modules dynamically compiled from
.prg code in long running programs like some servers though I can imagine
situations when user would prefer different behavior.
> Przemek, maybe can You add options to HB_HRBLOAD () which will force a
> re-initialization of static variables like: hb_hrbload( HB_HRB_INIT_STATIC,
> "hrb.hrb")
> or better: hb_hrbload("hrb.hrb") normal and: hb_hrbload(
> HB_HRB_NO_INIT_STATIC, "hrb.hrb") extra feature.
I have similar option in my TODO list nearly from beginning of my work
on .hrb code (you can find some messaged about it in this mail list archive)
but so far I haven't found time to implement it. I'll try to give higher
priority to it ;-)
Please also note that such reinitialization can be done in two different
ways:
1) by simple overloading existing static variables
2) by allocating new static variables and detaching old ones so
if some codeblocks created by previously loaded HRB module are
still alive then they will access previous instances of static
variables not the new ones.
and probably some users will also want to control it.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
>> Just had time to read this bit, well, I couldn't have >> said it better. Probably many other improvements could >> be made on that driver. F.e. for me thos HB_ADORDD*() >> functions look a little strange in an RDD. They're >> needed to setup connection, and connection is stored >> in thread static data. I'm not sure this plays well >> with MT RDD features of Harbour. > > Many things can be done but it needs someone interested enough > in developing this code and with some deeper knowledge about RDD > internals. Looking at this code I'm find still new things which > should be implemented in different way. I can help with RDD code > but there is no chance that I can make anything with strict ADO > only code - it simply does not work in my Linux box ;-) > It's enough that I was working on OLE code without even single > runtime test. That's the reason it got pulled from contrib. We need folks who are interested in this code. >> Plus one issue: Marek used to tell that data types >> aren't properly translated to Harbour types. > > Yes but it does not discards it. Many database drivers supports > only some subset of available field types. I.e. there is no other > DBF driver which can read all DBF fields supported by Harbour but > it does not mean that rest of xbase worls does not have usable > drivers ;-). In clean code things like new field types are usually > easy to introduce and can be done by users who will need them. Well, for me anything is fine :) It's up to real ADORDD users to fine tune all the details. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] src/compiler
Hi Przemek,
> I've already made this modification then I also made some tests with
> FSETDEVMOD() in C53 and before I'll commit it I have two questions:
> 1. CL53 returns only 1 or 2 and nothing more to indicate errors.
> Should I replicate it?
> 2. In tests it looks that it has some logic to return value for
> current file descriptor state if second parameter is not passed.
> In our source code we have:
> /* C53 checks only number of parameters: hb_pcount() == 2 */
> if( HB_ISNUM( 1 ) && HB_ISNUM( 2 ) )
> {
> ...
> }
> are you sure that the note and condition are valid?
Just generic suggestions:
You can implement HB_FSETDEVMODE() in the best way you can, without hacks,
then you can tailor FSETDEVMOD() to be as 5.3 compatible as possible with
all the weirdnesses.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13089] trunk/harbour
Revision: 13089 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13089&view=rev Author: vszakats Date: 2009-12-02 00:57:48 + (Wed, 02 Dec 2009) Log Message: --- 2009-12-02 01:55 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/itemapi.c * src/vm/hvm.c * src/vm/set.c * src/rtl/gtdos/gtdos.c * src/rtl/gtwin/gtwin.c * src/rtl/gtxwc/gtxwc.h * src/rtl/gtxwc/gtxwc.c * src/rtl/gtcrs/gtcrs.c * src/rtl/gtcrs/gtcrs.h * src/rtl/gtstd/gtstd.c * src/rtl/gttrm/gttrm.c * src/rtl/gtcgi/gtcgi.c * src/rtl/hbgtcore.c * src/rtl/gtsln/gtsln.c * src/rtl/gtsln/kbsln.c * src/rtl/gtsln/gtsln.h * src/rtl/gtpca/gtpca.c * src/rtl/gtwvt/gtwvt.c * src/rdd/dbfntx/dbfntx1.c * src/rdd/hbdbsort.c * src/rdd/sdf1.c * src/rdd/dbfnsx/dbfnsx1.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/delim1.c * src/rdd/dbf1.c * src/rdd/hsx/hsx.c * src/rdd/dbffpt/dbffpt1.c * doc/en-EN/lang.txt * include/hbrdddbf.h * include/hbapicdp.h * include/hbextern.ch * contrib/xhb/dbf2txt.c * contrib/gtqtc/gtqtc.cpp * contrib/gtwvg/gtwvg.c * contrib/gtwvg/wvggui.c * contrib/hbbmcdx/bmdbfcdx.c * examples/hbdoc/examples/core_es/lang.txt - Deleted HB_CDP_SUPPORT_OFF. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtqtc/gtqtc.cpp trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/contrib/gtwvg/wvggui.c trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/xhb/dbf2txt.c trunk/harbour/doc/en-EN/lang.txt trunk/harbour/examples/hbdoc/examples/core_es/lang.txt trunk/harbour/include/hbapicdp.h trunk/harbour/include/hbextern.ch trunk/harbour/include/hbrdddbf.h trunk/harbour/src/rdd/dbf1.c trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c trunk/harbour/src/rdd/dbffpt/dbffpt1.c trunk/harbour/src/rdd/dbfnsx/dbfnsx1.c trunk/harbour/src/rdd/dbfntx/dbfntx1.c trunk/harbour/src/rdd/delim1.c trunk/harbour/src/rdd/hbdbsort.c trunk/harbour/src/rdd/hsx/hsx.c trunk/harbour/src/rdd/sdf1.c trunk/harbour/src/rtl/gtcgi/gtcgi.c trunk/harbour/src/rtl/gtcrs/gtcrs.c trunk/harbour/src/rtl/gtcrs/gtcrs.h trunk/harbour/src/rtl/gtdos/gtdos.c trunk/harbour/src/rtl/gtpca/gtpca.c trunk/harbour/src/rtl/gtsln/gtsln.c trunk/harbour/src/rtl/gtsln/gtsln.h trunk/harbour/src/rtl/gtsln/kbsln.c trunk/harbour/src/rtl/gtstd/gtstd.c trunk/harbour/src/rtl/gttrm/gttrm.c trunk/harbour/src/rtl/gtwin/gtwin.c trunk/harbour/src/rtl/gtwvt/gtwvt.c trunk/harbour/src/rtl/gtxwc/gtxwc.c trunk/harbour/src/rtl/gtxwc/gtxwc.h trunk/harbour/src/rtl/hbgtcore.c trunk/harbour/src/vm/hvm.c trunk/harbour/src/vm/itemapi.c trunk/harbour/src/vm/set.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
On Tue, 01 Dec 2009, Szak�ts Viktor wrote: Hi, > > Of course this RDD should be greatly improved yet and some > > missing functionality added. Also if someone has time then > > function like SQLTranslate() should be rewritten from scratch > > to be real xbase to SQL expressions translator. Not a small > > hack for some trivial examples. > Just had time to read this bit, well, I couldn't have > said it better. Probably many other improvements could > be made on that driver. F.e. for me thos HB_ADORDD*() > functions look a little strange in an RDD. They're > needed to setup connection, and connection is stored > in thread static data. I'm not sure this plays well > with MT RDD features of Harbour. Many things can be done but it needs someone interested enough in developing this code and with some deeper knowledge about RDD internals. Looking at this code I'm find still new things which should be implemented in different way. I can help with RDD code but there is no chance that I can make anything with strict ADO only code - it simply does not work in my Linux box ;-) It's enough that I was working on OLE code without even single runtime test. > Plus one issue: Marek used to tell that data types > aren't properly translated to Harbour types. Yes but it does not discards it. Many database drivers supports only some subset of available field types. I.e. there is no other DBF driver which can read all DBF fields supported by Harbour but it does not mean that rest of xbase worls does not have usable drivers ;-). In clean code things like new field types are usually easy to introduce and can be done by users who will need them. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom
On Tue, 01 Dec 2009, David Arturo Macias Corona wrote: Hi, > >Thank you very much. So now we know that we can remove -s as > >workaround. Unfortunately it causes very big speed overhead. Much > >bigger then in Linux where removing -s reduce the speed only ~24 > >percent. It's 363% what is even bigger then in Windows (295% in my > >test). > That increase in Windows is surprise for me, so problem are not in OS/2 only Many of C compilers we are using generate much slower code for debugger so it's nothing amazing and code to check stack overload is type of debug code though in this case we used it as workaround for some wrong code generated by OpenWatcom for functions calling APIENTRY16 functions. > >Now I would like to check if -s is necessary as global switch or it > >can be used locally only for GT2OS2 code. > >Please restore -s switch (just like in clean SVN code) and then > >add to src/rtl/gtos2/Makefile[5] this line: > > HB_BUILD_OPTIM := no > >It should disable optimization switches. > >Then check if speedtst works in MT mode. > src\rtl\gtos2\Makefile does not have HB_BUILD_OPTIM Yes, I want you add it to src/rtl/gtos2/Makefile at line 5 > I used: > set HB_BUILD_OPTIM=no and what you have recompiled later and how? Sorry that I'm asking but I have to be sure what exactly was done. Many thanks for your tests. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: RE: [Harbour] Problem in OLE implementation
On Tue, 01 Dec 2009, J. Lefebvre wrote: Hi, > You could be right, but ... > 1) This code is not really new, and I had in mind it was working when I > tested it some month ago (99% sure) ... > 2) The same call in visual Basic work fine on the same OLE object ... > I will continue to investigate, I think that it may greatly help if you create as small as possible peace of code which executes SETREPORTVARIABLEVALUE() method in VB and the you translate this code to Harbour and check if you can replicate the problem. If yes then please send both version to this list and we try to repeat the problem and help you. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HB_CDP_SUPPORT_OFF question
On Wed, 02 Dec 2009, Szak�ts Viktor wrote: > >>> Now that you've reworked CDP support in whole Harbour, > >>> do you think we can delete HB_CDP_SUPPORT_OFF guards > >>> (and non-CDP supported code branches) from code? > >> Any quick opinion on that? Delete or keep? > > Sorry I forgot to answer. Let's delete it. > Thank and no prob. I'll do it. Thank you, best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] src/compiler
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
Hi,
> >> [ BTW it's not fully compatible, as C5.3 returned the old
> >> dev mode value. ]
> > Yes, I know. I think we should change:
> > BOOL hb_fsSetDevMode( HB_FHANDLE hFileHandle, USHORT uiDevMode )
> > to:
> > int hb_fsSetDevMode( HB_FHANDLE hFileHandle, int iDevMode )
> > and also return previous value or -1 on error and then update FSETDEVMOD()
> > to work like in Clipper. I can make such modification.
> Thank you, it would very nice.
I've already made this modification then I also made some tests with
FSETDEVMOD() in C53 and before I'll commit it I have two questions:
1. CL53 returns only 1 or 2 and nothing more to indicate errors.
Should I replicate it?
2. In tests it looks that it has some logic to return value for
current file descriptor state if second parameter is not passed.
In our source code we have:
/* C53 checks only number of parameters: hb_pcount() == 2 */
if( HB_ISNUM( 1 ) && HB_ISNUM( 2 ) )
{
...
}
are you sure that the note and condition are valid?
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HB_CDP_SUPPORT_OFF question
>>> Now that you've reworked CDP support in whole Harbour, >>> do you think we can delete HB_CDP_SUPPORT_OFF guards >>> (and non-CDP supported code branches) from code? >> Any quick opinion on that? Delete or keep? > > Sorry I forgot to answer. Let's delete it. Thank and no prob. I'll do it. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HB_CDP_SUPPORT_OFF question
On Wed, 02 Dec 2009, Szak�ts Viktor wrote: Hi, > > Now that you've reworked CDP support in whole Harbour, > > do you think we can delete HB_CDP_SUPPORT_OFF guards > > (and non-CDP supported code branches) from code? > Any quick opinion on that? Delete or keep? Sorry I forgot to answer. Let's delete it. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: HB_CDP_SUPPORT_OFF question
> Hi Przemek, > > Now that you've reworked CDP support in whole Harbour, > do you think we can delete HB_CDP_SUPPORT_OFF guards > (and non-CDP supported code branches) from code? Any quick opinion on that? Delete or keep? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: CHANGELOG: 2009-12-01 01:37 UTC-0800 Brian Hays
On Tue, 01 Dec 2009, Brian Hays wrote: Hi, > I need help with a decision on whether to throw an error or not. Please see > discussion below. > > 2009-12-01 01:37 UTC-0800 Brian Hays > * contrib\rdd_ads\ads1.c > + Added support for ordDescend's 3rd arg to dynamically change > the index direction between ascending / descending. > ONLY supported in ADS 9 and later. > BEFORE, if you used ordDescend(,,.t.) (or any value in the 3rd arg), > it was silently ignored no matter what version of ADS you used. > This change now means that with ADS 9 or later the flag is implemented. > BUT if you have ADS 8 or earlier, now I throw an error to alert you that > that > flag is not supported and your requested action would fail to do anything. > This may anger people who have been silently failing for years > (perhaps with code that is shared with other platforms that DO support the > flag) > Im not very good at details with our Error throwing details. Heres what I > coded: > // Do we have a "Unsupported Option in this version" error? >hb_errRT_DBCMD( EG_ARG, EDBCMD_DBINFOBADPARAMETER, "Dynamic > descend not supported in this version", HB_ERR_FUNCNAME ); > SHOULD WE REMOVE THIS, and go back to ignoring it? Or should the error msg > be standardized? Dynamic DESCEND flag is not supported also in many Clipper RDDs. So far the standard way in Clipper and [x]Harbour to check if dynamic descending order is supported was checking the value returned by: ordDescend( [], [] ) just after: ordDescend( [], [], ) i.e.: ordDescend( nTag,, .T. ) ? "order:", iif( ordDescend( nTag ), "descending", "ascending" ) such code works for any RDDs and will work also for ADS if you do not enable such RTE. In all core native RDDs (NTX, CDX, NSX) I implemented dynamic descend flags so such RTE cannot be generated so I think that it will be most important for ADS users which without RTE can easy create the same code for different ADS versions. > A second question: AdsSetIndexDirection takes an unusual flag that EITHER > takes 0 to return > to the original state, or TRUE to "reverse the direction from the current > state" > IOW, they have the ability to go back to normal which IIUC > Clipper/(x)Harbour does NOT. To clarify some technical issues. In indexes like CDX, ADI or NSX there is no "normal" state. Physically they exist only in ascending order and descending order is done by logical flag (BTW I'm surprised why adding user interface to change such logical flag took such long time ADS authors) so we can talk only about default settings for this flag stored in index header. Only NTX format uses reverted key orders in index file to implement default descending sorting so in our DBFNTX I implemented both versions and it's possible to use dynamic switching too just like in CDX or NSX formats. I guess that you are asking about method of "resetting" DESCEND flag to value chose by RDD when index is open. So far we do not have such functionality though it can be easy implemented if we agree how to inform RDD that we want to "reset" this flag. > Am I missing something? It would be nice to have a value to "return to > native state" in our syntax > instead of requiring a close/re-open of the file. Note: Once the direction > has been > dynamically changed, ordDescend() is only capable of returning the CURRENT > state; there is no > api to get the Original direction setting. Please remember that we are always in native state. The order direction is in practice only logical flag. Usually structural code have to safe and restore descend flag settings because it cannot assume that it was in the same state as after opening table. Operation like resetting order DESCEND flag to the same state as after opening table are not structural so are less usable in most of code. Probably the only one type of code I can imagine is some DBU like program which may want to display some information with default order settings. > In some COMIX functions, there was the difference between an explicit NIL > and an ignored parameter > to distinguish between intentions. I never liked having to explain it to > people, BUT > this may be an instance where explicitly passing NIL as the third arg could > be the flag > to revert to the original state of the index. NIL can be used for such job. In such case it's necessary to modify ordDescend() in dbcmd53.c and change: pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_LOGICAL ); to: pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_LOGICAL ); if( pOrderInfo.itmNewVal ) pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_NIL ); > Is there a good way to add the extended value/functionality of either > learning or setting > the original direction? The other method is defining new DBOI_* action for dbInfo() to extract default DESCEND flag settings which can be used as ordDescend() parameter. best regards, Przemek ___ Harbour ma
Re: [Harbour] Problem in OLE implementation
>> I see no point in moving it back to contrib until someone >> takes a plunge into this and known problems get fixed. > > So far I haven't seen any confirmed error in ADORDD code > so I have no idea what we can fix. > > Of course this RDD should be greatly improved yet and some > missing functionality added. Also if someone has time then > function like SQLTranslate() should be rewritten from scratch > to be real xbase to SQL expressions translator. Not a small > hack for some trivial examples. Just had time to read this bit, well, I couldn't have said it better. Probably many other improvements could be made on that driver. F.e. for me thos HB_ADORDD*() functions look a little strange in an RDD. They're needed to setup connection, and connection is stored in thread static data. I'm not sure this plays well with MT RDD features of Harbour. Plus one issue: Marek used to tell that data types aren't properly translated to Harbour types. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
> On Tue, 01 Dec 2009, Szak�ts Viktor wrote: >> 2008-09-12 00:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) >> * contrib/rddado/adordd.prg >> * contrib/rddado/adordd.ch >>* Merged changes from xhb. >> Some hbusrrdd.ch values seem to be missing from Harbour, >> related features will be automatically enabled if we >> implement them in our usrrdd. >> Please test. > > Thank you, I missed it. It's not reported by SF in SVN browse. > > Anyhow do you know any code examples which show problems with existing > ADO RDD code which should be fixed. No, sorry, I also only see these reports on the list. I'm not an ADORDD user myself. For sure ADORDD could use some reviewing, but can't tell anything specific this time. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Initialization of static variables in loaded HRB
Hi Przemek !
When the module HRB (or pcode-DLL) is loaded dynamically , You are looking
for whether it was once used a similar table of symbols, and then it
recycled.
If it is recycled, then You do not initialize static variables.
There is a problem to perform re-initialization ?
Lack of initialization of static variables, of course, provides additional
possibilities, but I think only the EXTRA. Normally, I expect that re-loaded
the module will behave just like the first time.
There are also other problems, such as when we have different versions of
the same function, and in the program we load modules several times.
Sample:
hrb1.prg -> hrb1.hrb
FUNCTION abc()
LOCAL x:="HRB1: ++2 from init static 30 - Now is:"
STATIC y:=30
y:=y+VAL("2")
RETURN x+STR(y,5)
hrb2.prg -> hrb2.hrb
STATIC z:=70
FUNCTION abc()
LOCAL x:="HRB2: --3 from 70 initalized. Now is: "
LOCAL w:=VAL("2")
LOCAL s:=" plus "
s:=s+"extra "
z:=z-w
--z
s:=s+"string :)"
RETURN x+STR(z,5)+s
main.prg -> main.exe
PROCEDURE MAIN
LOCAL i,hh
FOR i:=1 TO 2
? "HRB1 load by #",i
hh:=HB_HRBLOAD("hrb1.hrb")
? "ABC()->",&("ABC()")
? "ABC()->",&("ABC()")
? "HBR1 unload #",i
HB_HRBUNLOAD(hh)
? "HRB2 load by #",i
hh:=HB_HRBLOAD("hrb2.hrb")
? "ABC()->",&("ABC()")
? "ABC()->",&("ABC()")
? "HBR2 unload #",i
HB_HRBUNLOAD(hh)
NEXT
RETURN
**
We obtain the result:
HRB1 load by # 1
ABC()-> HRB1: ++2 from init static 30 - Now is: 32
ABC()-> HRB1: ++2 from init static 30 - Now is: 34
HBR1 unload # 1
HRB2 load by # 1
ABC()-> HRB2: --3 from 70 initalized. Now is:31 plus extra string :)
ABC()-> HRB2: --3 from 70 initalized. Now is:28 plus extra string :)
HBR2 unload # 1
HRB1 load by # 2
ABC()-> HRB1: ++2 from init static 30 - Now is: 30
ABC()-> HRB1: ++2 from init static 30 - Now is: 32
HBR1 unload # 2
HRB2 load by # 2
ABC()-> HRB2: --3 from 70 initalized. Now is:29 plus extra string :)
ABC()-> HRB2: --3 from 70 initalized. Now is:26 plus extra string :)
HBR2 unload # 2
Strange result is not it?
HRB2 get static value from HRB1 and vice versa !!!
Przemek, maybe can You add options to HB_HRBLOAD () which will force a
re-initialization of static variables like: hb_hrbload( HB_HRB_INIT_STATIC,
"hrb.hrb")
or better: hb_hrbload("hrb.hrb") normal and: hb_hrbload(
HB_HRB_NO_INIT_STATIC, "hrb.hrb") extra feature.
Adam
[ translation into English with the help of Google :) ]
--
View this message in context:
http://old.nabble.com/Initialization-of-static-variables-in-loaded-HRB-tp26596357p26596357.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13088] trunk/harbour
Revision: 13088 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13088&view=rev Author: vouchcac Date: 2009-12-01 16:34:08 + (Tue, 01 Dec 2009) Log Message: --- 2009-12-01 08:24 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.ch * contrib/hbide/hbide.prg * contrib/hbide/idemisc.prg ! More properties honored while reloading the sessions. Now editor tab is opened exactly in the same state it was closed. Unluckily I am not been to move the cursor to the same position, I do not know why QTextCursor():movePosition( nPos ) fails. Anybody has any hint? Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.ch trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idemisc.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
On Tue, 01 Dec 2009, Szak�ts Viktor wrote: > 2008-09-12 00:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) > * contrib/rddado/adordd.prg > * contrib/rddado/adordd.ch > * Merged changes from xhb. > Some hbusrrdd.ch values seem to be missing from Harbour, > related features will be automatically enabled if we > implement them in our usrrdd. > Please test. Thank you, I missed it. It's not reported by SF in SVN browse. Anyhow do you know any code examples which show problems with existing ADO RDD code which should be fixed. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
On Tue, 01 Dec 2009, Alex Strickland wrote: > >Alex can you try to add at the beginning of rddado/tests/access2.prg: > >FIELD FIRST > >and change the line 33 from: > >locate for TEST2->First = "Lara" > >to: > >locate for First = "Lara" > >and then repeat the test? > Yes, this works and writes .T. to the console. Thank you. Maybe in the future someone will try to write XBASE->SQL expression translator which can be used in such cases. So finally do we have any example which fails due to pure ADORDD code? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF bug tracker#2906734: ClassMethod: Message not found (Error)
On Tue, 01 Dec 2009, Chen Kedem wrote: Hi, > The following was reported on SF bug tracker: > http://sourceforge.net/tracker/?func=detail&atid=100681&aid=2906734&group_id=681 > Angel Diaz Leiva (angeldiazleiva) wrote: > - > When making the declaration of a class, if you declare a ClassMethod > and then seeks to use it, there is an error message: 'message not found' > followed by the name of the method. > But if there is a ClassVar with the same name as the method does not > generate any error messages, although the method is not called or running. > It appears that ClassMethod not taken into account in the class declaration. > - > Attached is the sample given by the user > Tested with Rev13051 I get the same error as the user > I don't know if the sample program is wrong or if its a real error. Neither Harbour nor xHarbour supports class objects like Class(y) so they do not support class method and class variables in the same way as Class(y) does. In Harbour and xHarbour class variables are object variables shared between objects of the same class not instance variables of class object like in Class(y). Class methods are not supported by both compilers at all. xHarbour translates class messages to normal messages and Harbour silently ignore them. If xHarbour behavior is enough for you then you can add after: #include "hbclass.ch" this line: #xcommand CLASS METHOD [] => METHOD Anyhow without real class object the code in attached example is not very efficient because each call to TESTCLASS() forces creating new instance of TESTCLASS object. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
>> Thank you. So there still seem to be some things broken >> after whichever update, my suspect is still the xhb sync job. > > Looking at the ChangeLog and SVN repository I haven't found even > single xhb sync commit. 2008-09-12 00:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/rddado/adordd.prg * contrib/rddado/adordd.ch * Merged changes from xhb. Some hbusrrdd.ch values seem to be missing from Harbour, related features will be automatically enabled if we implement them in our usrrdd. Please test. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Przemysław Czerpak wrote: Alex can you try to add at the beginning of rddado/tests/access2.prg: FIELD FIRST and change the line 33 from: locate for TEST2->First = "Lara" to: locate for First = "Lara" and then repeat the test? Yes, this works and writes .T. to the console. Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
On Tue, 01 Dec 2009, Szak�ts Viktor wrote: Hi, > > USE test.mdb VIA "ADORDD" TABLE "Tabla1" > > with: > > USE xbrtest.mdb VIA "ADORDD" TABLE "Customer" > > it works. Perhaps test.mdb is broken? > Could be. Or it simply doesn't find it. But your > next example suggest that it's the former. > BTW: "broken", I've fixed this file at least once > already, and I'm sure it was working back then, so > maybe it's also possible that such .mdb files > aren't compatible with every db driver? I suspect > some hidden dependency here or IOW that .mdb isn't > a stable format, but more like .doc which tends to > break compatibility every now and then. > Fixing it looks to be futile to me, so I'm leaving > this to .mdb experts/users. Anyhow it's not ADORDD problem. > > access2.prg creates test2.mdb ok. On exiting it fails with: > > Error OLE/3012 Argument error: FIND (DOS Error -2147352567) > > Called from WIN_OLEAUTO:FIND(0) > > Called from ADO_LOCATE(1009) > > Called from __DBLOCATE(0) > > Called from MAIN(34) The error is outside Harbour in code activate by: oRecordSet:FIND( "TEST2->First = 'Lara'", 0 ) so maybe the whole problem is caused by the fact that it does not understand aliased expressions using '->' as alias operator and it was never working from the beginning when this LOCATE command was added. Alex can you try to add at the beginning of rddado/tests/access2.prg: FIELD FIRST and change the line 33 from: locate for TEST2->First = "Lara" to: locate for First = "Lara" and then repeat the test? > > mysql1.prg : > > Error OLE/3012 Argument error: OPEN (DOS Error -2147352567) > > Called from WIN_OLEAUTO:OPEN(0) > > Called from ADO_OPEN(312) > > Called from DBUSEAREA(0) > > Called from MAIN(12) > > mysql.prg is the same except MAIN(14) Here I cannot help. Maybe you have to install some MYSQL drivers to make it working. I do not know. It's seems to be question to MYSQL users. > Thank you. So there still seem to be some things broken > after whichever update, my suspect is still the xhb sync job. Looking at the ChangeLog and SVN repository I haven't found even single xhb sync commit. > I see no point in moving it back to contrib until someone > takes a plunge into this and known problems get fixed. So far I haven't seen any confirmed error in ADORDD code so I have no idea what we can fix. Of course this RDD should be greatly improved yet and some missing functionality added. Also if someone has time then function like SQLTranslate() should be rewritten from scratch to be real xbase to SQL expressions translator. Not a small hack for some trivial examples. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13083] trunk/harbour
On Tue, 1 Dec 2009, vszak...@users.sourceforge.net wrote: > Log Message: > --- > 2009-12-01 12:21 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * config/global.mk > % "De-xmastree"-d two more if/else structures. you SO are my hero. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
J. Lefebvre wrote: I will continue to investigate, Perhaps this may help: http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en#QuickInfoContainer it is OleView.exe which is quite useful for seeing what is behind the scenes. Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13087] trunk/harbour
Revision: 13087 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13087&view=rev Author: vszakats Date: 2009-12-01 15:09:59 + (Tue, 01 Dec 2009) Log Message: --- 2009-12-01 16:10 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * bin/hb-mkimp.bat * Minor. * contrib/hbwin/win_dll.c * contrib/hbcairo/paths.c * contrib/hbcairo/text.c * contrib/hbcairo/core.c * contrib/hbcairo/Makefile * Minor cleanups. ! Fixed minor typo. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/hb-mkimp.bat trunk/harbour/contrib/hbcairo/Makefile trunk/harbour/contrib/hbcairo/core.c trunk/harbour/contrib/hbcairo/paths.c trunk/harbour/contrib/hbcairo/text.c trunk/harbour/contrib/hbwin/win_dll.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13086] trunk/harbour
Revision: 13086 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13086&view=rev Author: snaiperis Date: 2009-12-01 14:59:28 + (Tue, 01 Dec 2009) Log Message: --- 2009-12-01 16:56 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) * harbour/contrib/hbcairo/context.c * harbour/contrib/hbcairo/paths.c * harbour/contrib/hbcairo/text.c * harbour/contrib/hbcairo/tests/table.prg * added some error check. If function parameters are invalid C level functions is not called with invalid (NULL) pointers. * changed cairo_text_extent() to return an array of .c structure members instead of returning multiple values using parameters passed by reference. In the future I'll try to follow this way to return structures. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbcairo/context.c trunk/harbour/contrib/hbcairo/paths.c trunk/harbour/contrib/hbcairo/tests/table.prg trunk/harbour/contrib/hbcairo/text.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: RE: [Harbour] Problem in OLE implementation
Hi Przemek, You could be right, but ... 1) This code is not really new, and I had in mind it was working when I tested it some month ago (99% sure) ... 2) The same call in visual Basic work fine on the same OLE object ... I will continue to investigate, Friendly, JF -Message d'origine- De : harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] De la part de Przemyslaw Czerpak Envoyé : mardi 1 décembre 2009 15:10 À : Harbour Project Main Developer List. Objet : Re: RE: [Harbour] Problem in OLE implementation On Tue, 01 Dec 2009, J. Lefebvre wrote: Hi, > Hu, not sure it is really related to a problem with ADORDD (see dos > error). > I have exactly the same error trying to access Crystal report runtime XI. >Error occurred at: 01/12/2009, 14:26:32 >Error description: (DOS Error -2147352567) OLE/3012 Argument error: > SETREPORTVARIABLEVALUE >Args: > [ 1] = C FADEVCUR > [ 2] = C True > Stack Calls > === >Called from: => WIN_OLEAUTO:SETREPORTVARIABLEVALUE(0) >Called from: crwcole.prg => CRW:SETFORMULA(848) > I checked documentation at least 1 million time, arguments I send to > "SetReportVariableValue" are ok. All OLE errors have 'Argument error' in description so it does not give you any valuable information. > I suspect some argument type error in ole implementation. I do not think so. At least the information you presented suggest that it's not Harbour problem at all. > Ole2TxtError() give DISP_E_EXCEPTION but I'm not sure it is related. And this it the only one important information. This error is reported by OLE object from Invoke() method and you should check in OLE object documentation for the reasons why calling method: SETREPORTVARIABLEVALUE( "FADEVCUR", "True" ) generates above error. This happens outside Harbour code. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13085] trunk/harbour
Revision: 13085 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13085&view=rev Author: snaiperis Date: 2009-12-01 14:42:57 + (Tue, 01 Dec 2009) Log Message: --- 2009-12-01 16:39 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) * harbour/contrib/hbwin/olecore.c * harbour/contrib/hbwin/axcore.c * changed error system name from OLE to WINOLE * renumerated error subcodes starting from 1001 Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/axcore.c trunk/harbour/contrib/hbwin/olecore.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Problem in OLE implementation
>-Original Message- >From: Alex Strickland [mailto:s...@mweb.co.za] >Sent: Tuesday, December 01, 2009 1:22 PM >To: Harbour Project Main Developer List. >Subject: Re: [Harbour] Problem in OLE implementation ... >REQUEST ADORDD > >function Main() > >USE xbrtest.mdb VIA "ADORDD" TABLE "Customer" > >Browse() > >USE > >return nil > >It appears to work very well, the browse showing me all the >customer details. I think it should be restored to SVN. > >Thanks and regards >Alex Strickland Alex, with ADO I can read from thrue SQL database only characters fields. select id_dekretacja, to_char( id_dekretacja, '99') dekret, opis, to_char( sum( case when gr_ik = '3' then kwota else 0 end ), '.99') kwota_ik, to_char( sum( case when gr_ik = '2' then kwota else 0 end ), '.99') kwota_gr, to_char( sum(kwota), '.99') kwota_og from All numeric or data fields must be covert to character. With ODBC\MIXSQL all work correct. Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
>> Error OLE/3012 Argument error: OPEN (DOS Error -2147352567) >> Called from WIN_OLEAUTO:OPEN(0) >> Called from ADO_OPEN(312) >> Called from DBUSEAREA(0) >> Called from MAIN(12) > > It would be nice to have some idea about how error subcode sould be used. > 3012 does not say much about the exact place of error. I've used to change > error subcodes to 3012, 3013, 3014, and so on , when I was debugging OLE > code. But I does not commit different error subcodes, since the whole idea > about error subcodes is not clear for me. Since the "OLE" error class is unique in Harbour, you are free to use any subcode under it. It usually starts with 1001 and the next free number is used for each different error case. BTW, maybe "WINOLE" would be a better error class name, although OLE is probably unique enough, maybe it's a little bit cleaner this way. Brgds. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Hi, Error OLE/3012 Argument error: OPEN (DOS Error -2147352567) Called from WIN_OLEAUTO:OPEN(0) Called from ADO_OPEN(312) Called from DBUSEAREA(0) Called from MAIN(12) It would be nice to have some idea about how error subcode sould be used. 3012 does not say much about the exact place of error. I've used to change error subcodes to 3012, 3013, 3014, and so on , when I was debugging OLE code. But I does not commit different error subcodes, since the whole idea about error subcodes is not clear for me. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: [Harbour] Problem in OLE implementation
On Tue, 01 Dec 2009, J. Lefebvre wrote: Hi, > Hu, not sure it is really related to a problem with ADORDD (see dos > error). > I have exactly the same error trying to access Crystal report runtime XI. >Error occurred at: 01/12/2009, 14:26:32 >Error description: (DOS Error -2147352567) OLE/3012 Argument error: > SETREPORTVARIABLEVALUE >Args: > [ 1] = C FADEVCUR > [ 2] = C True > Stack Calls > === >Called from: => WIN_OLEAUTO:SETREPORTVARIABLEVALUE(0) >Called from: crwcole.prg => CRW:SETFORMULA(848) > I checked documentation at least 1 million time, arguments I send to > "SetReportVariableValue" are ok. All OLE errors have 'Argument error' in description so it does not give you any valuable information. > I suspect some argument type error in ole implementation. I do not think so. At least the information you presented suggest that it's not Harbour problem at all. > Ole2TxtError() give DISP_E_EXCEPTION but I'm not sure it is related. And this it the only one important information. This error is reported by OLE object from Invoke() method and you should check in OLE object documentation for the reasons why calling method: SETREPORTVARIABLEVALUE( "FADEVCUR", "True" ) generates above error. This happens outside Harbour code. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] src/compiler
Maurilio Longo wrote: Good morning Przemyslaw and Viktor, first of all you have to answer a question I'm asking myself since a long time: how are you able to avoid sleeping and still be able to write such good code?? I see messages of yours during all night: 00.46, 01.17, 01.49, 02.53, 03.45, 04.17, 04.48, 08.50!! If you look more closely to the numbers, you'll see a 4 hours sleep interval between 04:48 and 08:50 :) Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Problem in OLE implementation
Hu, not sure it is really related to a problem with ADORDD (see dos error). I have exactly the same error trying to access Crystal report runtime XI. Error occurred at: 01/12/2009, 14:26:32 Error description: (DOS Error -2147352567) OLE/3012 Argument error: SETREPORTVARIABLEVALUE Args: [ 1] = C FADEVCUR [ 2] = C True Stack Calls === Called from: => WIN_OLEAUTO:SETREPORTVARIABLEVALUE(0) Called from: crwcole.prg => CRW:SETFORMULA(848) I checked documentation at least 1 million time, arguments I send to "SetReportVariableValue" are ok. I suspect some argument type error in ole implementation. Ole2TxtError() give DISP_E_EXCEPTION but I'm not sure it is related. JF -Message d'origine- De : harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] De la part de Viktor Szakáts Envoyé : mardi 1 décembre 2009 14:19 À : Harbour Project Main Developer List. Objet : Re: [Harbour] Problem in OLE implementation Hi Alex, > USE test.mdb VIA "ADORDD" TABLE "Tabla1" > > with: > > USE xbrtest.mdb VIA "ADORDD" TABLE "Customer" > > it works. Perhaps test.mdb is broken? Could be. Or it simply doesn't find it. But your next example suggest that it's the former. BTW: "broken", I've fixed this file at least once already, and I'm sure it was working back then, so maybe it's also possible that such .mdb files aren't compatible with every db driver? I suspect some hidden dependency here or IOW that .mdb isn't a stable format, but more like .doc which tends to break compatibility every now and then. Fixing it looks to be futile to me, so I'm leaving this to .mdb experts/users. > access2.prg creates test2.mdb ok. On exiting it fails with: > > Error OLE/3012 Argument error: FIND (DOS Error -2147352567) > Called from WIN_OLEAUTO:FIND(0) > Called from ADO_LOCATE(1009) > Called from __DBLOCATE(0) > Called from MAIN(34) > > mysql1.prg : > > Error OLE/3012 Argument error: OPEN (DOS Error -2147352567) > Called from WIN_OLEAUTO:OPEN(0) > Called from ADO_OPEN(312) > Called from DBUSEAREA(0) > Called from MAIN(12) > > mysql.prg is the same except MAIN(14) Thank you. So there still seem to be some things broken after whichever update, my suspect is still the xhb sync job. I see no point in moving it back to contrib until someone takes a plunge into this and known problems get fixed. [ The second one maybe just real open error, it's pointing to some external service. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Ace.lib not generate in last version
Pls see: 2009-11-30 11:51 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) Brgds, Viktor On 2009 Dec 1, at 14:21, Rossine wrote: > > Hello, > > I not see ace.lib in last version. > > Regards, > > Rossine. > > -- > View this message in context: > http://old.nabble.com/Ace.lib-not-generate-in-last-version-tp26591636p26591636.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Ace.lib not generate in last version
Hello, I not see ace.lib in last version. Regards, Rossine. -- View this message in context: http://old.nabble.com/Ace.lib-not-generate-in-last-version-tp26591636p26591636.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Hi Alex, > USE test.mdb VIA "ADORDD" TABLE "Tabla1" > > with: > > USE xbrtest.mdb VIA "ADORDD" TABLE "Customer" > > it works. Perhaps test.mdb is broken? Could be. Or it simply doesn't find it. But your next example suggest that it's the former. BTW: "broken", I've fixed this file at least once already, and I'm sure it was working back then, so maybe it's also possible that such .mdb files aren't compatible with every db driver? I suspect some hidden dependency here or IOW that .mdb isn't a stable format, but more like .doc which tends to break compatibility every now and then. Fixing it looks to be futile to me, so I'm leaving this to .mdb experts/users. > access2.prg creates test2.mdb ok. On exiting it fails with: > > Error OLE/3012 Argument error: FIND (DOS Error -2147352567) > Called from WIN_OLEAUTO:FIND(0) > Called from ADO_LOCATE(1009) > Called from __DBLOCATE(0) > Called from MAIN(34) > > mysql1.prg : > > Error OLE/3012 Argument error: OPEN (DOS Error -2147352567) > Called from WIN_OLEAUTO:OPEN(0) > Called from ADO_OPEN(312) > Called from DBUSEAREA(0) > Called from MAIN(12) > > mysql.prg is the same except MAIN(14) Thank you. So there still seem to be some things broken after whichever update, my suspect is still the xhb sync job. I see no point in moving it back to contrib until someone takes a plunge into this and known problems get fixed. [ The second one maybe just real open error, it's pointing to some external service. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Viktor Szakáts wrote: Can you try with the copy in 'examples/rddado' and tests under 'tests'. OK, got them. access1.prg fails with : Error OLE/3012 Argument error: OPEN (DOS Error -2147352567) Called from WIN_OLEAUTO:OPEN(0) If I replace this line: USE test.mdb VIA "ADORDD" TABLE "Tabla1" with: USE xbrtest.mdb VIA "ADORDD" TABLE "Customer" it works. Perhaps test.mdb is broken? access2.prg creates test2.mdb ok. On exiting it fails with: Error OLE/3012 Argument error: FIND (DOS Error -2147352567) Called from WIN_OLEAUTO:FIND(0) Called from ADO_LOCATE(1009) Called from __DBLOCATE(0) Called from MAIN(34) mysql1.prg : Error OLE/3012 Argument error: OPEN (DOS Error -2147352567) Called from WIN_OLEAUTO:OPEN(0) Called from ADO_OPEN(312) Called from DBUSEAREA(0) Called from MAIN(12) mysql.prg is the same except MAIN(14) Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13084] trunk/harbour
Revision: 13084 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13084&view=rev Author: vszakats Date: 2009-12-01 12:53:03 + (Tue, 01 Dec 2009) Log Message: --- 2009-12-01 13:52 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * examples/rddado/adordd.prg * examples/rddado/adordd.ch * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/examples/rddado/adordd.ch trunk/harbour/examples/rddado/adordd.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
>> BTW I'm still waiting for verification of reported RDDADO problems >> with current HBWIN OLE code. Can some MS-Windows users check it? > > It is not in current SVN, I copied adordd.prg, and adordd.ch and > tests\access1.prg from an old backup: > > * $Id: adordd.prg 10183 2009-02-05 09:21:52Z vszakats $ > * $Id: adordd.ch 9997 2008-12-23 02:08:51Z druzus $ > * $Id: access1.prg 9217 2008-08-23 15:02:49Z vszakats $ Can you try with the copy in 'examples/rddado' and tests under 'tests'. It was never removed, only moved. The sources you tested are older versions. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Przemysław Czerpak wrote: BTW I'm still waiting for verification of reported RDDADO problems with current HBWIN OLE code. Can some MS-Windows users check it? It is not in current SVN, I copied adordd.prg, and adordd.ch and tests\access1.prg from an old backup: * $Id: adordd.prg 10183 2009-02-05 09:21:52Z vszakats $ * $Id: adordd.ch 9997 2008-12-23 02:08:51Z druzus $ * $Id: access1.prg 9217 2008-08-23 15:02:49Z vszakats $ I altered access1.prg slightly to match xbrtest.mdb which I had from the ado test recently: /* * $Id: access1.prg 9217 2008-08-23 15:02:49Z vszakats $ */ #include "adordd.ch" REQUEST ADORDD function Main() USE xbrtest.mdb VIA "ADORDD" TABLE "Customer" Browse() USE return nil It appears to work very well, the browse showing me all the customer details. I think it should be restored to SVN. Thanks and regards Alex Strickland ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] SF.net SVN: harbour-project:[13028] trunk/harbour
>-Original Message- >From: Pritpal Bedi [mailto:bediprit...@hotmail.com] >Sent: Friday, November 27, 2009 5:49 PM >To: harbour@harbour-project.org >Subject: RE: [Harbour] SF.net SVN: harbour-project:[13028] >trunk/harbour > > >Hi > > >Horodyski Marek (PZUZ) wrote: >> >> In GTWVG i must from time to time hit right alt key, because cursor >> keys don't work. >> After push right alt key, all returns to normal. >> > >I never experienced such activity so far. >If you can reduce it to some compilable code I can check. > >Regards >Pritpal Bedi I have an example! :) /* test.prg, try it with GTWVG, GTWVT on WinXP */ Function Main() Local key #include "inkey.ch" KSetCaps( .t.) Cls ? 'press and release the left alt and then press the arrow keys,' ? 'then press and release right alt and then press the arrow keys. ? 'When there is no difference - 3x repeat the test.' ? 'Hit any key, ESC edns ...' While ( key := InKey( 0, INKEY_ALL)) != 27 ? key End __Wait( '...?') Return Nil /* eof */ Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour under OS/2 - OpenWatcom
Przemek:
I have not seen response
David Macias
Przemek:
I know but the problem seems to be inside OpenWatcom code and for me it
looks like OpenWatcom bug which probably can be quite easy fixed but
I need more information to be sure.
///
Thank you very much. So now we know that we can remove -s as
workaround. Unfortunately it causes very big speed overhead. Much
bigger then in Linux where removing -s reduce the speed only ~24
percent. It's 363% what is even bigger then in Windows (295% in my
test).
That increase in Windows is surprise for me, so problem are not in OS/2 only
Now I would like to check if -s is necessary as global switch or it
can be used locally only for GT2OS2 code.
Please restore -s switch (just like in clean SVN code) and then
add to src/rtl/gtos2/Makefile[5] this line:
HB_BUILD_OPTIM := no
It should disable optimization switches.
Then check if speedtst works in MT mode.
src\rtl\gtos2\Makefile does not have HB_BUILD_OPTIM
I used:
set HB_BUILD_OPTIM=no
Tests with
speedtst.exe --thread ...
fails as before with GPF:
-
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 0001.
-
Below are results using:
hbmk2 -m -n -w -es2 -l -kmo -gc3 speedtst.prg
speedtst.exe
hbmk2 -m -n -w -es2 -l -kmo -gc3 -mt speedtst.prg
speedtst.exe
speedtst.exe --thread
speedtst.exe --thread=2 --scale
David Macias
2009.11.28 08:22:22 OS/2 4.50
Harbour 2.0.0beta3 (Rev. 13035) Open Watcom C++ 12.80.8 (32-bit) x86
THREADS: 0
N_LOOPS: 100
[ T000: empty loop overhead ]...0.00
[ T001: x := L_C ]..0.03
[ T002: x := L_N ]..0.03
[ T003: x := L_D ]..0.06
[ T004: x := S_C ]..0.06
[ T005: x := S_N ]..0.03
[ T006: x := S_D ]..0.06
[ T007: x := M->M_C ]...0.06
[ T008: x := M->M_N ]...0.06
[ T009: x := M->M_D ]...0.06
[ T010: x := M->P_C ]...0.06
[ T011: x := M->P_N ]...0.06
[ T012: x := M->P_D ]...0.06
[ T013: x := F_C ]..0.13
[ T014: x := F_N ]..0.16
[ T015: x := F_D ]..0.10
[ T016: x := o:Args ]...0.13
[ T017: x := o[2] ].0.10
[ T018: round( i / 1000, 2 ) ]..0.19
[ T019: str( i / 1000 ) ]...0.39
[ T020: val( s ) ]..0.19
[ T021: val( a [ i % 16 + 1 ] ) ]...0.29
[ T022: dtos( d - i % 1 ) ].0.32
[ T023: eval( { || i % 16 } ) ].0.26
[ T024: eval( bc := { || i % 16 } ) ]...0.16
[ T025: eval( { |x| x % 16 }, i ) ].0.23
[ T026: eval( bc := { |x| x % 16 }, i ) ]...0.19
[ T027: eval( { |x| f1( x ) }, i ) ]0.26
[ T028: eval( bc := { |x| f1( x ) }, i ) ]..0.23
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ].0.23
[ T030: x := &( "f1(" + str(i) + ")" ) ]1.87
[ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ]2.00
[ T032: x := valtype( x ) + valtype( i ) ].0.32
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ]..0.52
[ T034: x := a[ i % 16 + 1 ] == s ].0.19
[ T035: x := a[ i % 16 + 1 ] = s ]..0.23
[ T036: x := a[ i % 16 + 1 ] >= s ].0.23
[ T037: x := a[ i % 16 + 1 ] <= s ].0.23
[ T038: x := a[ i % 16 + 1 ] < s ]..0.23
[ T039: x := a[ i % 16 + 1 ] > s ]..0.23
[ T040: ascan( a, i % 16 ) ]0.26
[ T041: ascan( a, { |x| x == i % 16 } ) ]...1.87
[ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s,s2,a2 ]0.52
[ T043: x := a ]0.06
[ T044: x := {} ]...0.10
[ T045: f0() ]..0.06
[ T046: f1( i ) ]...0.13
[ T047: f2( c[1...8] ) ]..
[Harbour] Re: src/compiler
Przemek: >I guess you are talking about context of some file to which >you redirected output. Just like in Clipper this lines are >shown using: > chr(13) + + chr( 13 ) + chr( 13 ) + ... >and your editor or program you used to view that file presents >chr(13) as new line. >If you change editor or viewer to one which does not accept >single chr(10) or chr(13) as EOL but only sequence chr(13)+chr(10) >then you will see the difference just like on the screen. >I.e. try: > type sale.txt [E:\harbour911b\harbour\bin\os2\watcom]type sale.txt hbmk2: Processing environment options: -compiler=watcom Harbour 2.0.0beta3 (Rev. 13082) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling 'speedtst.prg'... Lines 1204, Functions/Procedures 79 Generating C source output to 'speedtst.c'... Done. Funny. So: --- 100 200 300 [...] --- are "hidden"/overlapped even they exist on sale.txt file EPM, E, jEdit editors show --- 100 200 300 [...] --- while TEDIT editor show a line with two "flags" symbols between line numbers Now is more clear why you suggested long time ago to redirect to file to see all output Even "TYPE sale.txt" can confuse :-) David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13083] trunk/harbour
Revision: 13083 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13083&view=rev Author: vszakats Date: 2009-12-01 11:21:30 + (Tue, 01 Dec 2009) Log Message: --- 2009-12-01 12:21 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * config/global.mk % "De-xmastree"-d two more if/else structures. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/global.mk This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: src/compiler
On Tue, 01 Dec 2009, David Arturo Macias Corona wrote: Hi, > [E:\harbour911b\harbour\bin\os2\watcom]pba2.exe > 0: .T. > 1: .T. > 2: .T. > [E:\harbour911b\harbour\bin\os2\watcom]pba2.exe > pba2.txt > 0: .T. > 1: .F. > 2: .T. > [E:\harbour911b\harbour\bin\os2\watcom]pba2.exe 2> pba2.txt > 0: .T. > 1: .T. > 2: .F. Thank you and Maurilio. So we can use it to detect redirection on all platforms. > >In DJGPP builds with COMMAND.COM and BASH also works as expected > >so only OS/2 builds should be verified yet. > Below are results using OpenWatcom, current and older Harbour > > Why empty lines between ? > --- > 100 > > 200 > > 300 > [...] > --- I guess you are talking about context of some file to which you redirected output. Just like in Clipper this lines are shown using: chr(13) + + chr( 13 ) + chr( 13 ) + ... and your editor or program you used to view that file presents chr(13) as new line. > hbmk2 speedtst.prg > == > > hbmk2: Processing environment options: -compiler=watcom > Harbour 2.0.0beta3 (Rev. 13082) > Copyright (c) 1999-2009, http://www.harbour-project.org/ > Compiling 'speedtst.prg'... > Lines 1204, Functions/Procedures 79 > Generating C source output to 'speedtst.c'... Done. Very good. > hbmk2 speedtst.prg > sale.txt 2>&1 > == > hbmk2: Processing environment options: -compiler=watcom > Harbour 2.0.0beta3 (Rev. 13082) > Copyright (c) 1999-2009, http://www.harbour-project.org/ > Compiling 'speedtst.prg'... > > 100 > > 200 > > 300 > > 400 > > 500 > > 600 > > 700 > > 800 > > 900 > > 1000 > > Lines 1204, Functions/Procedures 79 > Generating C source output to 'speedtst.c'... Done. If you change editor or viewer to one which does not accept single chr(10) or chr(13) as EOL but only sequence chr(13)+chr(10) then you will see the difference just like on the screen. I.e. try: type sale.txt best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: src/compiler
Przemek:
>We should make some tests. Also in OS/2 for GCC and OpenWatcom builds.
>This code can be used for tests:
> proc main()
> ? "0:", HB_FISDEVICE( 0 )
> ? "1:", HB_FISDEVICE( 1 )
> ? "2:", HB_FISDEVICE( 2 )
> return
> #pragma begindump
> #include "hbapifs.h"
> HB_FUNC( HB_FISDEVICE )
> {
> hb_retl( hb_fsIsDevice( hb_numToHandle( hb_parnint( 1 ) ) ) );
> }
> #pragma enddump
[E:\harbour911b\harbour\bin\os2\watcom]pba2.exe
0: .T.
1: .T.
2: .T.
[E:\harbour911b\harbour\bin\os2\watcom]pba2.exe > pba2.txt
0: .T.
1: .F.
2: .T.
[E:\harbour911b\harbour\bin\os2\watcom]pba2.exe 2> pba2.txt
0: .T.
1: .T.
2: .F.
>In DJGPP builds with COMMAND.COM and BASH also works as expected
>so only OS/2 builds should be verified yet.
Below are results using OpenWatcom, current and older Harbour
Why empty lines between ?
---
100
200
300
[...]
---
David Macias
hbmk2 speedtst.prg
==
hbmk2: Processing environment options: -compiler=watcom
Harbour 2.0.0beta3 (Rev. 13082)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'speedtst.prg'...
Lines 1204, Functions/Procedures 79
Generating C source output to 'speedtst.c'... Done.
hbmk2 speedtst.prg > sale.txt 2>&1
==
hbmk2: Processing environment options: -compiler=watcom
Harbour 2.0.0beta3 (Rev. 13082)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'speedtst.prg'...
100
200
300
400
500
600
700
800
900
1000
Lines 1204, Functions/Procedures 79
Generating C source output to 'speedtst.c'... Done.
hbmk2 speedtst.prg
==
hbmk2: Processing environment options: -compiler=watcom
Harbour 2.0.0beta3 (Rev. 12894)
Copyright (c) 1999-2009,
http://www.harbour-proje
ct.org/
Compiling 'speedtst.prg'...
Lines 1204, Functions/Procedures 79
Generating C source output to
'speedtst.c'...
Done.
hbmk2 speedtst.prg > sale.txt 2>&1
==
hbmk2: Processing environment options: -compiler=watcom
Harbour 2.0.0beta3 (Rev. 12894)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'speedtst.prg'...
100
200
300
400
500
600
700
800
900
1000
Lines 1204, Functions/Procedures 79
Generating C source output to 'speedtst.c'... Done.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13076] trunk/harbour
Hi Mindaugas, > Viktor Szakáts wrote: >> BTW, I managed to build fancytxt using bcc 5.5 and it works with the same >> .dlls which failed so badly with mingw. > >> Application Internal Error - >> F:\work\harbour\harbour\contrib\hbcairo\tests\fancytxt.exe >> Terminated at: 2009.11.30 22:44:06 >> Unrecoverable error 6005: Exception error: > > I'll try to make a guess :) Force rebuilding of hbvm library and mingw will > work. You get GPF in hb_strfree(). VM library was not rebuild because > hbvmall.c is not touched. Good guess, my MinGW draft-build was flaky. It was enough to rebuild hbvm. Now it's okay, sorry for the mis-report. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] src/compiler
Good morning Przemyslaw and Viktor, first of all you have to answer a question I'm asking myself since a long time: how are you able to avoid sleeping and still be able to write such good code?? I see messages of yours during all night: 00.46, 01.17, 01.49, 02.53, 03.45, 04.17, 04.48, 08.50!! That said, it works now like a charm: (E:\REPOSITORY\HARBOUR\tests)hbmk2 -mt speedtst.prg hbmk2: Processing environment options: -mt -compiler=gcc hbmk2: Processing configuration: E:\harbour\bin\hbmk.cfg Harbour 2.0.0beta3 (Rev. 13082) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling 'speedtst.prg'... Lines 1204, Functions/Procedures 79 Generating C source output to 'speedtst.c'... Done. Thanks so much guys. Maurilio. Przemysław Czerpak wrote: > On Tue, 01 Dec 2009, Szak�ts Viktor wrote: >>> Fine. Please also check >>> tst.exe | grep . >>> to check the results for pipes. >>> I've just check that in DOS OpenWatcom builds it works as we want. >> Works fine with mingw + cmd.exe. >> Also works fine with mingw + msys. > > In DJGPP builds with COMMAND.COM and BASH also works as expected > so only OS/2 builds should be verified yet. > > Oops. I've forgot that FD_* constants are in .ch file for CL53 > FSETDEVMOD() > functions so we already have everything in core code so please simply add: > FSETDEVMOD( 1, FD_TEXT ) > FSETDEVMOD( 2, FD_TEXT ) > or if you want to make it in more generic way which will work also for > multi GT output (i.e. with some code which allocates many different GTCGI > drivers with different redirection) then make: > FSETDEVMOD( hb_gtInfo( HB_GTI_OUTPUTFD ), FD_TEXT ) > FSETDEVMOD( hb_gtInfo( HB_GTI_ERRORFD ), FD_TEXT ) Will commit it ASAP, I hope Maurilio can test it then. >>> I tested DOS OpenWatcom builds and it resolved the problem. > > Also in DJGPP builds. > >>> BTW in most of cases we expanded names of Clipper functions cut to 10 >>> characters, i.e. dbSelectArea(). Maybe we should also change FSetDevMod() >>> to FSetDevMode()? >> That's a good question. Maybe the best solution would be to >> add it as HB_FSETDEVMODE() and leave FSETDEVMOD() as >> a compatibility wrapper. >> This also helps hbmk2 to build when HB_COMPAT_C53 is disabled. > > So let's add HB_FSETDEVMODE() > >> [ BTW it's not fully compatible, as C5.3 returned the old >> dev mode value. ] > > Yes, I know. I think we should change: >BOOL hb_fsSetDevMode( HB_FHANDLE hFileHandle, USHORT uiDevMode ) > to: >int hb_fsSetDevMode( HB_FHANDLE hFileHandle, int iDevMode ) > > and also return previous value or -1 on error and then update FSETDEVMOD() > to work like in Clipper. I can make such modification. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13071] trunk/harbour
>> can you share your test to better understand? > > I am using a commercial DLL supplied to allow redemption and purchase of gift > vouchers. Many of the functions return arrays of objects (* IUnknown). With > Przemyslaw's changes (and not to forget the initial and ongoing contributions > from Mindaugas with ActiveX support and rewriting olecore.c) this kind of OLE > data is now supported. > > To my knowledge Harbour now supports all the forms of OLE data that xHarbour > supports, plus extras, in a safer way. ActiveX support is now more flexible > and safer than xHarbour. The C code is compact and clear (well, as clear as > OLE code ever is for me), allows the proper use of destructors and garbage > collection. All in all it is a fantastic job. Yes, it's a very nice part of Harbour now. Thanks and congrats to Mindaugas and Przemek for the hard work on it. I'd even dare to use it in production at this point :) [ I'm also not a personal user of it, but similar magic would be very nice on .dll support. I tried to lookup such code in PERL/Python, but couldn't find out anything meaningful by sweeping through their code. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13071] trunk/harbour
My only question here is why such functionality has to live inside Harbour SVN? Along with hb-mkdyn.sh, this has nothing to do with core Harbour. It also can be solved as a user supplied postinst task. hb-mkdyn is a generic lib to dynlib converter script, which is also shell and compiler specific. (current near self-modifying solution to add HB_TOOLS_PREF, icc, and sunos support doesn't look very alright to me either). Maybe such hacks are normal in the *nix world, but they make these scripts much more difficult to decipher than it would normally be. IMO these features should be kept separate (if it attracts many users) or local (if it's just a few users). But in any case kept fully separate from core. I didn't try but such customized harbour dynlibs may also break standard build tools like hbmk2. Along the same lines, we could just as well add support to allow addition of user supplied Harbour compiler options by injecting new code into the build system, thus creating "dynamic forks" of some sort. I also wonder how these customized Harbour dynlibs are supposed to work when Harbour becomes a standard package on *nix system and it's installed by simple 'apt-get install harbour' (or RPM variation). Or is this not our goal anymore? Brgds, Viktor On 2009 Dec 1, at 10:11, Lorenzo Fiorini wrote: > On Mon, Nov 30, 2009 at 4:52 PM, wrote: > >> * harbour/bin/hb-func.sh >>- removed not longer working HB_DB_DRVEXT >>+ added HB_USER_DLL_ADDONS which can be used to activate rebuilding >> Harbour shared library in postinst phase with additional libraries >> specified by user in above envvar - it's not officially supported >> functionality but temporary workaround until we will not add some >> more generic support for above feature so I do not document it in >> INSTALL > > Many thanks, this has removed a local patch. > > In hb_getlibs there is still gtxvt, shouldn't it be removed? > > best regards, > Lorenzo > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13071] trunk/harbour
Massimo Belgrano wrote: can you share your test to better understand? I am using a commercial DLL supplied to allow redemption and purchase of gift vouchers. Many of the functions return arrays of objects (* IUnknown). With Przemyslaw's changes (and not to forget the initial and ongoing contributions from Mindaugas with ActiveX support and rewriting olecore.c) this kind of OLE data is now supported. To my knowledge Harbour now supports all the forms of OLE data that xHarbour supports, plus extras, in a safer way. ActiveX support is now more flexible and safer than xHarbour. The C code is compact and clear (well, as clear as OLE code ever is for me), allows the proper use of destructors and garbage collection. All in all it is a fantastic job. Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13071] trunk/harbour
On Mon, Nov 30, 2009 at 4:52 PM, wrote: > * harbour/bin/hb-func.sh > - removed not longer working HB_DB_DRVEXT > + added HB_USER_DLL_ADDONS which can be used to activate rebuilding > Harbour shared library in postinst phase with additional libraries > specified by user in above envvar - it's not officially supported > functionality but temporary workaround until we will not add some > more generic support for above feature so I do not document it in > INSTALL Many thanks, this has removed a local patch. In hb_getlibs there is still gtxvt, shouldn't it be removed? best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] SF.net SVN: harbour-project:[13074] trunk/harbour
>-Original Message- >From: Mindaugas Kavaliauskas [mailto:dbto...@dbtopas.lt] >Sent: Monday, November 30, 2009 8:37 PM >To: Harbour Project Main Developer List. >Subject: Re: [Harbour] SF.net SVN: harbour-project:[13074] >trunk/harbour > >Sample test code results. Part 2 A good example would be to use in pdf the fonts to show each country, with what are sometimes big problems. Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
