[Harbour] Harbour and unicode .prg files

2009-12-07 Thread Viktor Szakáts
Hi All, I was trying to compile a .prg which contained UTF-8 chars in strings, and it so happened that my editor added unicode signature (BOM) to the .prg file, causing this compile error: --- Harbour 2.0.0beta3 (Rev. 13091) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling

Re: [Harbour] BEGIN/END SEQUENCE Fails or is intended as such ?

2009-12-07 Thread Viktor Szakáts
#xcommand BEGIN SEQUENCE = BEGIN SEQUENCE WITH { |oErr| Break( oErr ) } or better yet .- #xcommand TRY = BEGIN SEQUENCE WITH t_bBreak #xcommand CATCH [!oErr!] = RECOVER [USING oErr] -oErr- #xcommand FINALLY = ALWAYS THREAD STATIC t_bBreak := { |oErr| Break( oErr )

[Harbour] SF.net SVN: harbour-project:[13151] trunk/harbour

2009-12-07 Thread vouchcac
Revision: 13151 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13151view=rev Author: vouchcac Date: 2009-12-07 08:59:58 + (Mon, 07 Dec 2009) Log Message: --- 2009-12-07 00:48 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) *

[Harbour] SF.net SVN: harbour-project:[13152] trunk/harbour

2009-12-07 Thread vszakats
Revision: 13152 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13152view=rev Author: vszakats Date: 2009-12-07 09:15:59 + (Mon, 07 Dec 2009) Log Message: --- 2009-12-07 10:14 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) *

[Harbour] SF.net SVN: harbour-project:[13153] trunk/harbour

2009-12-07 Thread snaiperis
Revision: 13153 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13153view=rev Author: snaiperis Date: 2009-12-07 09:37:16 + (Mon, 07 Dec 2009) Log Message: --- 2009-12-07 11:40 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) *

Re: [Harbour] bug?: SET( _SET_CODEPAGE, UTF8 )

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, 'SET( _SET_CODEPAGE, UTF8 )' does't work, it leaves CP in previous setting. 2009-09-11 20:37 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) + added pseduto codepage UTF8 which can be used in trnaslations only

Re: [Harbour] BEGIN/END SEQUENCE Fails or is intended as such ?

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Xavi wrote: Hi, Maybe you need to put this before .- #xcommand BEGIN SEQUENCE = BEGIN SEQUENCE WITH { |oErr| Break( oErr ) } I forgot to add that this is very bad idea because it fully disable error handler just like TRY / CATCH in xHarbour. It means that some important

[Harbour] List slowness (to Phil)

2009-12-07 Thread Viktor Szakáts
Hi Phil, Can you take a look at the mailing list engine, it seems rather slow since the weekend. Thank you. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org

Re: [Harbour] BEGIN/END SEQUENCE Fails or is intended as such ?

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Xavi wrote: Hi, Maybe you need to put this before .- #xcommand BEGIN SEQUENCE = BEGIN SEQUENCE WITH { |oErr| Break( oErr ) } or better yet .- #xcommand TRY = BEGIN SEQUENCE WITH t_bBreak #xcommand CATCH [!oErr!] = RECOVER [USING oErr] -oErr- #xcommand

Re: [Harbour] SF.net SVN: harbour-project:[13149] trunk/harbour

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, vszak...@users.sourceforge.net wrote: Hi, ; TOFIX: I'm getting this warning: warning: implicit declaration of function 'hb_setGetOSCP' and it's probably too late, but I couldn't find a way to include hbset.h without errors or

Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Massimo Belgrano
Wich is last good version of proposed script for q6 4.6? WIch version of minigui must be use for qt 4.6? Have we some advanced for NEWS 2009/12/5 Viktor Szakáts harbour...@syenar.hu Hi Istvan, The same experience I encountered with Qt 4.6 mingw environment (not TDM-MINGW). No more idea,

RE: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Bisz István
Hi Viktor, This is very easy to implement, only needs one extra 'mt=yes' line in contrib/hbqt/hbqt[s].hbc files. However, before we do this, I'd like know if this is indeed the _real_ solution to the problem. Turning on MT mode decreases performance by ~30% (AFAIR) in mingw, so it's not

[Harbour] Cairo GC

2009-12-07 Thread Mindaugas Kavaliauskas
Hi, Przemek, there is a question about GC and storing references between collectible pointers. It would be nice to hear your opinion about this. These letters explains the problem: http://lists.harbour-project.org/pipermail/harbour/2009-November/028156.html

Re: [Harbour] Harbour and unicode .prg files

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, I was trying to compile a .prg which contained UTF-8 chars in strings, and it so happened that my editor added unicode signature (BOM) to the .prg file, causing this compile error: --- Harbour 2.0.0beta3 (Rev. 13091) Copyright (c) 1999-2009,

RE: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Bisz István
Hi Massimo, If you need to build harbour with TDM-MINGW with dual rewind feature installed and Qt previous to 4.6 release, you should set HB_COMPILER to mingw, skipping in this way the build system auto detection: set HB_WITH_QT=C:/Qt/4.5.3/include set HB_COMPILER=mingw for 4.6 just:

Re: [Harbour] Error Compiling with latest SVN

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Mario H. Sabado wrote: Hi, I encountered below error when building latest Harbour SVN under Mandriva. Please always try _CLEAN_ build before your report problems. best regards, Przemek ___ Harbour mailing list (attachment size

Re: [Harbour] bug?: SET( _SET_CODEPAGE, UTF8 )

2009-12-07 Thread Viktor Szakáts
Hi, 'SET( _SET_CODEPAGE, UTF8 )' does't work, it leaves CP in previous setting. 2009-09-11 20:37 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) + added pseduto codepage UTF8 which can be used in trnaslations only

Re: [Harbour] SF.net SVN: harbour-project:[13149] trunk/harbour

2009-12-07 Thread Viktor Szakáts
; TOFIX: I'm getting this warning: warning: implicit declaration of function 'hb_setGetOSCP' and it's probably too late, but I couldn't find a way to include hbset.h without errors or with least side-effects. Przemek, could you help? I'm

[Harbour] Re: Harbour under OS/2 - OpenWatcom

2009-12-07 Thread David Arturo Macias Corona
Przemek: We only do not know the exact place but this is a job for OpenWatcom developers to fix it. I do not plan to make it myself. Anyhow we can make some other tests to reduce the problem yet and better tune final self contain example which can be used in bug report. I do not see anything

RE: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Bisz István
I am resending, as the previous is lost... From: Bisz István [mailto:istvan.b...@t-online.hu] Sent: 2009. december 7. 11:02 To: 'Harbour Project Main Developer List.' Subject: RE: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour Hi Massimo,

[Harbour] bug?: HBQT_QTPTR_FROM_GCPOINTER()

2009-12-07 Thread Viktor Szakáts
Hi All, It's just a sort of hunch, since I don't have test code and detailed theoretical proof for this, but it looks like existing HBQT_QTPTR_FROM_GCPOINTER() is a wrong concept and should not be used at all. It converts GC pointer to a simple one. In code it's used for some comparisons,

[Harbour] Harbour and Flex

2009-12-07 Thread Viktor Szakáts
Hi All, I understand Harbour doesn't need Flex at all now, yet, we have harbour.l in src/compiler. Not used from Makefile. Any specific reason for that, or shall I go along and clean all references of flex from source tree, make system and INSTALL? Or should we leave harbour.l for

Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Viktor Szakáts
Hi Istvan, This is very easy to implement, only needs one extra 'mt=yes' line in contrib/hbqt/hbqt[s].hbc files. However, before we do this, I'd like know if this is indeed the _real_ solution to the problem. Turning on MT mode decreases performance by ~30% (AFAIR) in mingw, so it's not

Re: [Harbour] Harbour and unicode .prg files

2009-12-07 Thread Viktor Szakáts
Hi, I was trying to compile a .prg which contained UTF-8 chars in strings, and it so happened that my editor added unicode signature (BOM) to the .prg file, causing this compile error: --- Harbour 2.0.0beta3 (Rev. 13091) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling

Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom

2009-12-07 Thread Viktor Szakáts
So how about removing -s switch altogether for watcom/os2 in both our make system and hbmk2? No. It's not necessary to touch hbmk2. For the reason that a slightly slower, but working app is better than a failing app. This slight slower means over 3 times slower. -s disabled debug

Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Viktor Szakáts
If you need to build harbour with TDM-MINGW with dual rewind feature installed and Qt previous to 4.6 release, you should set HB_COMPILER to mingw, skipping in this way the build system auto detection: set HB_WITH_QT=C:/Qt/4.5.3/include set HB_COMPILER=mingw for 4.6 just: set

[Harbour] hbqt and MT / issues

2009-12-07 Thread Viktor Szakáts
Hi All, 1) I'm seeing this code: --- void MyMainWindow::paintEvent( QPaintEvent * event ) { hb_threadMutexLock( s_mutex ); [...] /* This is an ugly hack to control the way Qt executes its Paint Engine * which appears to be not reentrant. If paint message is received by two *

Re: [Harbour] BEGIN/END SEQUENCE Fails or is intended as such ?

2009-12-07 Thread Xavi
Gracias Przemek, important things like setting NETERR() or setting 0 as result of division by 0 stop to work. To me is clear: global setting of BEGIN SEQUENCE limits the possibilities. I do not know if it has clarified the issue. Pritpal? P.e. In the *local* context of the function

Re: [Harbour] Harbour and Flex

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, I understand Harbour doesn't need Flex at all now, yet, we have harbour.l in src/compiler. Not used from Makefile. Yes. I eliminated FLEX usage few years ago. Any specific reason for that, or shall I go along and clean all references of

Re: [Harbour] hbqt and MT / issues

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Is this workaround a good one? To me it looks to only delay potential problems. Exactly. It should be removed because it does not fix anything. If some code needs it then for sure it's not rpduction ready and has to be fixed. best regards, Przemek

Re: [Harbour] bug?: SET( _SET_CODEPAGE, UTF8 )

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, Ok I see. Although this also means that I can't use it as native CP in an application. You seem to have suggested that any app may use UTF-8 even now. But maybe I misunderstood something. I understand this needs UTF-8 sorting support (for

RE: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Bisz István
Hi Viktor, Just to clarify the picture or to restrict the playing space, why these issues is are missing in linux (Fedora 12) builds? Best regards, István -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor

Re: [Harbour] Harbour and Flex

2009-12-07 Thread Viktor Szakáts
On 2009 Dec 7, at 16:53, Przemysław Czerpak wrote: On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, I understand Harbour doesn't need Flex at all now, yet, we have harbour.l in src/compiler. Not used from Makefile. Yes. I eliminated FLEX usage few years ago. Okay. Any specific

Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, I've just seen David's latest tests... IMO if there is no reasonable solution for it, removing -s could still be a fallback option, for the reason that watcom/os2 is not a primary target, I mean no one seems to use it for production, in

Re: [Harbour] bug?: SET( _SET_CODEPAGE, UTF8 )

2009-12-07 Thread Viktor Szakáts
Ok I see. Although this also means that I can't use it as native CP in an application. You seem to have suggested that any app may use UTF-8 even now. But maybe I misunderstood something. I understand this needs UTF-8 sorting support (for ASORT(), , operators, maybe else, plus these

Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Viktor Szakáts
Hi Istvan, Hi Viktor, Just to clarify the picture or to restrict the playing space, why these issues is are missing in linux (Fedora 12) builds? Interesting question, I hope someone will give an answer. For sure MT isn't used by default on Fedora either, and also base Harbour isn't built

Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom

2009-12-07 Thread Viktor Szakáts
I've just seen David's latest tests... IMO if there is no reasonable solution for it, removing -s could still be a fallback option, for the reason that watcom/os2 is not a primary target, I mean no one seems to use it for production, in practice we need it only for cross-platform build

RE: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Bisz István
It's just a question, to make us to go deeper in this issue... -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts Sent: 2009. december 7. 17:27 To: Harbour Project Main Developer List. Subject: Re:

Re: [Harbour] SF.net SVN: harbour-project:[13149] trunk/harbour

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, Since the reference to hb_set*() function is hidden inside a macro defined in hbwince.h (ie. it's a macro implementation detail, which user code shouldn't be aware of), hbset.h should be #included from the header which defines the macro,

Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, Okay, that clears it up. So in essence OpenWatcom for OS/2 is broken whatever we do in Harbour. [ In this case though, we may safely readd -s for all modules, thus deleting our little hack and wait for Watcom team to fix it. ] I do not see any

Re: [Harbour] Cairo GC

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Mindaugas Kavaliauskas wrote: Hi, there is a question about GC and storing references between collectible pointers. It would be nice to hear your opinion about this. These letters explains the problem:

Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom

2009-12-07 Thread Viktor Szakáts
Okay, that clears it up. So in essence OpenWatcom for OS/2 is broken whatever we do in Harbour. [ In this case though, we may safely readd -s for all modules, thus deleting our little hack and wait for Watcom team to fix it. ] I do not see any reason to break using GTOS2 in MT mode waiting

Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, I do not see any reason to break using GTOS2 in MT mode waiting for OpenWatcom fix so I would like to keep current hack until it will not be fixed in OW. Confused state ON In your prev mail you told that full removal of -s also doesn't help

Re: [Harbour] Harbour and unicode .prg files

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, Anyhow if it's important then now I can add small code which will simply strip UTF-8 signature from compiled .prg files. If it's not huge effort and don't make later modification harder, I think it would be nice, as it'd open the way to

Re: [Harbour] bug?: SET( _SET_CODEPAGE, UTF8 )

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Szak�ts Viktor wrote: Hi, So, I'm afraid I'm confused. For sure I don't want to unblock it just for the sake of having it unlocked. But now I can't see why it cannot work as main CP, but can work as DB CP. I assume if it can be used in DB, sorting must be working,

[Harbour] SF.net SVN: harbour-project:[13155] trunk/harbour

2009-12-07 Thread druzus
Revision: 13155 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13155view=rev Author: druzus Date: 2009-12-07 18:29:27 + (Mon, 07 Dec 2009) Log Message: --- 2009-12-07 19:29 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) *

Re: [Harbour] bug?: HBQT_QTPTR_FROM_GCPOINTER()

2009-12-07 Thread Pritpal Bedi
Hello Viktor Viktor Szakáts wrote: It's just a sort of hunch, since I don't have test code and detailed theoretical proof for this, but it looks like existing HBQT_QTPTR_FROM_GCPOINTER() is a wrong concept and should not be used at all. It converts GC pointer to a simple one. In

Re: [Harbour] hbqt and MT / issues

2009-12-07 Thread Pritpal Bedi
Hi Viktor Szakáts wrote: 1) I'm seeing this code: --- void MyMainWindow::paintEvent( QPaintEvent * event ) { hb_threadMutexLock( s_mutex ); [...] /* This is an ugly hack to control the way Qt executes its Paint Engine * which appears to be not reentrant. If paint

Re: [Harbour] BEGIN/END SEQUENCE Fails or is intended as such ?

2009-12-07 Thread Pritpal Bedi
Hello Przemek Przemysław Czerpak wrote: Please read in Clipper documentation what BEGIN SEQUENCE / RECOVER / END exactly does. RECOVER is activated only when error handler calls BREAK(). I guess that you wanted to make sth like: /* Clipper compatible code */ cbError :=

Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Pritpal Bedi
Hello Viktor Szakáts wrote: Exploits it and cannot imagine doesn't mean it _requires_ it. What I'm interested in, is whether HBQT _requires it_? IMO, it should not require it, but may give extra features if available, and for sure _be compatible with it_. If current implementation

RE: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Pritpal Bedi
Hi Istvan Bisz István wrote: Here I can share just my experiences with the harbour Qt implementation testing. I spent a lot of time to clarify the build problems with 4.6 and after the successful building the resulted executable testing. My first conclusion was that C++ mode force to the

Re: [Harbour] SF.net SVN: harbour-project:[13154] trunk/harbour

2009-12-07 Thread Viktor Szakáts
Log Message: --- 2009-12-07 18:42 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/pp/ppcore.c * strip UTF-8 BOM signature from compiled .prg files Nice, thanks a bunch. Brgds, Viktor ___ Harbour mailing list

Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Pritpal Bedi
Hi Viktor Szakáts wrote: Me - still in the hunch mode - am still finding it odd that we need to use MT HVM to make QT not GPF. I perfectly believe your tests are correct and for you MT solved the problems, but we still don't see the deeper reason. For sure QT itself cannot require MT

Re: [Harbour] bug?: HBQT_QTPTR_FROM_GCPOINTER()

2009-12-07 Thread Viktor Szakáts
Viktor Szakáts wrote: It's just a sort of hunch, since I don't have test code and detailed theoretical proof for this, but it looks like existing HBQT_QTPTR_FROM_GCPOINTER() is a wrong concept and should not be used at all. It converts GC pointer to a simple one. In code it's used

Re: [Harbour] hbqt and MT / issues

2009-12-07 Thread Viktor Szakáts
Hi Pritpal, Viktor Szakáts wrote: 1) I'm seeing this code: --- void MyMainWindow::paintEvent( QPaintEvent * event ) { hb_threadMutexLock( s_mutex ); [...] /* This is an ugly hack to control the way Qt executes its Paint Engine * which appears to be not reentrant. If

Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Viktor Szakáts
IMO, it should not require it, but may give extra features if available, and for sure _be compatible with it_. If current implementation _requires it_, which means it cannot work or cannot reliably work without it, we should document this fact. HBQT may/may not _require it_ but HBXBP

Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour

2009-12-07 Thread Viktor Szakáts
Me - still in the hunch mode - am still finding it odd that we need to use MT HVM to make QT not GPF. I perfectly believe your tests are correct and for you MT solved the problems, but we still don't see the deeper reason. For sure QT itself cannot require MT _HVM_, because it also

Re: [Harbour] SF.net SVN: harbour-project:[13154] trunk/harbour

2009-12-07 Thread Tamas TEVESZ
On Mon, 7 Dec 2009, dru...@users.sourceforge.net wrote: hi, Revision: 13154 * harbour/src/rdd/dbfcdx/dbfcdx1.c * modified to use unique names for startup functions yup, much better now, all artifacts seem to have disappeared, thanks! -- [-] mkdir /nonexistent

[Harbour] bug?: HBQT: hb_vmRequestReenter() calls without hb_vmRequestRestore()

2009-12-07 Thread Viktor Szakáts
Hi Pritpal, I've just checked hbqt_slots.cpp and there are _many_ hb_vmRequestReenter() calls without hb_vmRequestRestore() pairs. I don't know the consequences, but it doesn't seem right. Brgds, Viktor ___ Harbour mailing list (attachment size

Re: [Harbour] bug?: HBQT: hb_vmRequestReenter() calls without hb_vmRequestRestore()

2009-12-07 Thread Pritpal Bedi
Hi Viktor Szakáts wrote: I've just checked hbqt_slots.cpp and there are _many_ hb_vmRequestReenter() calls without hb_vmRequestRestore() pairs. I don't know the consequences, but it doesn't seem right. Matched. I also do not know its implications, Przemek ? Regards Pritpal Bedi

[Harbour] SF.net SVN: harbour-project:[13156] trunk/harbour

2009-12-07 Thread vszakats
Revision: 13156 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13156view=rev Author: vszakats Date: 2009-12-08 00:10:17 + (Tue, 08 Dec 2009) Log Message: --- 2009-12-08 01:09 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) +

[Harbour] HBQT problems

2009-12-07 Thread Viktor Szakáts
Hi All, Some other discoveries, which should probably be fixed: 1) QSyntaxHighlighter is not a wrapper of QT class with same name, but a customized Harbour version, named HbSyntaxHighlighter. This is wrong, such special class should be added as such on .prg level with alternate

[Harbour] SF.net SVN: harbour-project:[13157] trunk/harbour

2009-12-07 Thread vouchcac
Revision: 13157 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13157view=rev Author: vouchcac Date: 2009-12-08 00:31:10 + (Tue, 08 Dec 2009) Log Message: --- 2009-12-07 16:30 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg

[Harbour] HBXBP - Broken after last two commits

2009-12-07 Thread Pritpal Bedi
Hello Viktor Last two commits in succession has broken demoxbp which GPF's on startup, possibly when building XbpBrowse(). Did you compiled demoxbp before commit ? I ask because yours and mine commits has conflicts when I started. Regards Pritpal Bedi -- View this message in context:

Re: [Harbour] SF.net SVN: harbour-project:[13154] trunk/harbour

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Tamas TEVESZ wrote: Hi, Revision: 13154 * harbour/src/rdd/dbfcdx/dbfcdx1.c * modified to use unique names for startup functions yup, much better now, all artifacts seem to have disappeared, thanks! Yes, but please remember what I wrote about HB_STRICT_ANSI_C

Re: [Harbour] HBXBP - Broken after last two commits

2009-12-07 Thread Viktor Szakáts
Hello Viktor Last two commits in succession has broken demoxbp which GPF's on startup, possibly when building XbpBrowse(). Did you compiled demoxbp before commit ? I ask because yours and mine commits has conflicts when I started. No, I only tested demoqt. Brgds, Viktor

[Harbour] SF.net SVN: harbour-project:[13158] trunk/harbour

2009-12-07 Thread vszakats
Revision: 13158 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13158view=rev Author: vszakats Date: 2009-12-08 00:51:31 + (Tue, 08 Dec 2009) Log Message: --- 2009-12-08 01:51 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) *

Re: [Harbour] HBQT problems

2009-12-07 Thread Pritpal Bedi
Hi Viktor Szakáts wrote: 1) QSyntaxHighlighter is not a wrapper of QT class with same name, but a customized Harbour version, named HbSyntaxHighlighter. This is wrong, such special class should be added as such on .prg level with alternate wrappers. This may be doable but I

Re: [Harbour] HBXBP - Broken after last two commits

2009-12-07 Thread Pritpal Bedi
Hi Viktor Szakáts wrote: No, I only tested demoqt. Please do so with demoxbp too. Demoqt is a very simple and wrappers only application. demoxbp exploits much more constructs. Regards Pritpal Bedi -- View this message in context:

Re: [Harbour] bug?: HBQT: hb_vmRequestReenter() calls without hb_vmRequestRestore()

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Pritpal Bedi wrote: Hi, I've just checked hbqt_slots.cpp and there are _many_ hb_vmRequestReenter() calls without hb_vmRequestRestore() pairs. I don't know the consequences, but it doesn't seem right. Matched. I also do not know its implications, Przemek ? It may

Re: [Harbour] bug?: HBQT: hb_vmRequestReenter() calls without hb_vmRequestRestore()

2009-12-07 Thread Pritpal Bedi
Hi Przemysław Czerpak wrote: It may change in different HVM version so no one should create code which depends on current behavior anyhow if you are interested what happens now then return value is overwritten by last return value in executed code (depending on context it may cause some

[Harbour] SF.net SVN: harbour-project:[13159] trunk/harbour

2009-12-07 Thread vszakats
Revision: 13159 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13159view=rev Author: vszakats Date: 2009-12-08 01:33:11 + (Tue, 08 Dec 2009) Log Message: --- 2009-12-08 02:32 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) *

[Harbour] SF.net SVN: harbour-project:[13160] trunk/harbour

2009-12-07 Thread vszakats
Revision: 13160 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13160view=rev Author: vszakats Date: 2009-12-08 01:42:25 + (Tue, 08 Dec 2009) Log Message: --- 2009-12-08 02:41 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) *

[Harbour] SF.net SVN: harbour-project:[13161] trunk/harbour

2009-12-07 Thread vszakats
Revision: 13161 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13161view=rev Author: vszakats Date: 2009-12-08 01:53:53 + (Tue, 08 Dec 2009) Log Message: --- 2009-12-08 02:53 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) *

Re: [Harbour] SF.net SVN: harbour-project:[13074] trunk/harbour

2009-12-07 Thread Przemysław Czerpak
On Mon, 30 Nov 2009, Mindaugas Kavaliauskas wrote: Hi, 2009-11-30 21:31 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) + harbour/contrib/hbcairo I'll write down a few issues I found in hbcairo development. 1) #include std.ch generates compile time errors. Just like in Clipper.

[Harbour] SF.net SVN: harbour-project:[13162] trunk/harbour

2009-12-07 Thread druzus
Revision: 13162 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13162view=rev Author: druzus Date: 2009-12-08 03:08:08 + (Tue, 08 Dec 2009) Log Message: --- 2009-12-08 04:07 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) *

Re: [Harbour] bug?: HBQT: hb_vmRequestReenter() calls without hb_vmRequestRestore()

2009-12-07 Thread Przemysław Czerpak
On Mon, 07 Dec 2009, Pritpal Bedi wrote: Hi It may change in different HVM version so no one should create code which depends on current behavior anyhow if you are interested what happens now then return value is overwritten by last return value in executed code (depending on context it

[Harbour] Re: Harbour under OS/2 - OpenWatcom

2009-12-07 Thread David Arturo Macias Corona
Przemek: config\os2\watcom.mk contain: ifeq ($(filter $(LIBNAME),gtos2 gtstd),) CFLAGS += -s endif Have you made clean Harbour build? Yes, of course I expected not to fail in gtos2 and gtstd, but as gtstd failed, I checked files and made confirmations to be sure, and at last I

[Harbour] SF.net SVN: harbour-project:[13163] trunk/harbour

2009-12-07 Thread vouchcac
Revision: 13163 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13163view=rev Author: vouchcac Date: 2009-12-08 07:45:20 + (Tue, 08 Dec 2009) Log Message: --- 2009-12-07 23:43 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) *