Re: [Harbour] My first study on hbqt code...
Hi Francesco,
In the objects destructor ( the hbqt_gcRelease_* functions ) pq value
is checked against NULL... But in hbqt_gcpointer it is not... because
in hbqt_gcpointer we just have a generic QGC_POINTER and not the
specific QGC_POINTER_QPushButton so pq is not available...
See:
typedef struct
{
void * ph;
bool bNew;
QT_G_FUNC_PTR func;
QPointer QPushButton pq;
} QGC_POINTER_QPushButton;
typedef struct
{
void * ph;
bool bNew;
QT_G_FUNC_PTR func;
} QGC_POINTER;
My idea is then to add a Qpointer placeholder in QGC_POINTER but it
would need some more changes, infact it seems ok for objects in
directory qtgui (they descend from QObject) but not for objects in
qtcore that doesn't inherit from QObject.
So there are 2 possibilities to verify:
1) in hbqt.h change the #define hbqt_par_QPushButton( n ) ( (
QPushButton * ) hbqt_gcpointerFromQObject( n ) ) for object in qtgui
and then copy hbqt_gcpointer to hbqt_gcpointerFromQObject adding pq
checking (the some for *FromObj) but then how to handle Q_release ?
If I understand correctly (correct me if not):
- You intend to create separate hbqt_gcpointer*() calls for
each object type.
- To add NULL checking to these functions.
I agree with both. HBQT code should definitely throw RTE when
NULL is detected, instead of letting it GPF.
2) using bNew not as a bool but as a bitmask with values
1=CREATED_BY_NEW 2=HAS_PQ 4=INVALID 8=DELETE_IN_PROGRESS (to
trap/debug strange interactions between c++ delete and harbour GC)
giving us a clear picture of what is happening and also a lot more
status bit to use
Using 2) it may be just a matter of adding the status bit at object
creation and checking the 1-ness of bit 2 before testing pq and some
other trivial changes...
May be good, but I can't oversee this one.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error compiling pcre with MSVC8
Hi Compiling with MSVC8 i get following errors: cl.exe -I. -I../../../../../include -nologo -TC -Ot2b1 -EHs-c- -Zi -DHB_LEGACY_TYPES_OFF -DHB_TR_LEVEL_DEBUG -DPCRE_STATIC -DHAVE_STDINT_H=0 -DHAVE_CONFIG_H -DUNICODE -Fochartabs.obj -c ../../../chartabs.c chartabs.c c:\hrb\svn\src-svn\external\pcre\pcreinal.h(198) : fatal error C1083: Cannot open include file: 'inttypes.h': No such file or directory mingw32-make[3]: [chartabs.obj] Error 2 (ignored) . . . BRGDS Franček - brgs Franček Prijatelj -- View this message in context: http://n2.nabble.com/Error-compiling-pcre-with-MSVC8-tp4884638p4884638.html Sent from the harbour-devel 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] MSVC8 rc complier doesn't hava -nologo param
Hi
Compiling with MSVC8 i get following error:
rc.exe -nologo -fo hbrun.res ../../../hbrun.rc
fatal error RC1106: invalid option: -ologo
My settings:
! Building Harbour 2.1.0dev from source - http://www.harbour-project.org
! MAKE: mingw32-make 3.81 sh.exe clean install i
! HB_USER_PRGFLAGS: -l-
! HB_INSTALL_PREFIX: C:\HRB\msvc_D_Tr
! HB_BIN_INSTALL: C:\HRB\msvc_D_Tr\bin
! HB_LIB_INSTALL: C:\HRB\msvc_D_Tr\lib
! HB_INC_INSTALL: C:\HRB\msvc_D_Tr\include
! HB_DOC_INSTALL: C:\HRB\msvc_D_Tr\doc
! HB_BUILD_NAME: _D
! HB_BUILD_DEBUG: yes
! HB_BUILD_MODE: cpp
! HB_HOST_PLAT: win (x86) HB_SHELL: nt
! HB_PLATFORM: win (x86)
! HB_COMPILER: msvc
! Component: 'zlib' found in C:/HRB/SVN/SRC-SVN/external/zlib (local)
! Component: 'pcre' found in C:/HRB/SVN/SRC-SVN/external/pcre (local)
! Component: 'openssl' found in C:\Lib\OpenSSL\include
! Component: 'gpm' not supported on win platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not found. Configure with HB_WITH_CURSES.
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on win platform
! 'gtcrs' library skipped (component not found)
! 'gtdos' library skipped (platform not supported)
! 'gtos2' library skipped (platform not supported)
! 'gtsln' library skipped (component not found)
! 'gttrm' library skipped (platform or compiler not supported)
! 'gtxwc' library skipped (component not found)
! 'gtalleg' library skipped ('allegro' not found. Configure with
HB_WITH_ALLEGRO.)
! 'hbcairo' library skipped ('cairo' not found. Configure with
HB_WITH_CAIRO.)
! 'hbgd' library skipped ('libgd' not found. Configure with HB_WITH_GD.)
! Using QT 'moc' executable: C:\Qt\msvc\include\..\bin\moc.exe
(autodetected)
! 'rddads' library skipped ('ads' not found. Configure with HB_WITH_ADS.)
! 'sddoci' library skipped ('ocilib' not found. Configure with
HB_WITH_OCILIB.)
BRGDS
-
brgs
Franček Prijatelj
--
View this message in context:
http://n2.nabble.com/MSVC8-rc-complier-doesn-t-hava-nologo-param-tp4884664p4884664.html
Sent from the harbour-devel 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:[14312] trunk/harbour
Revision: 14312 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14312view=rev Author: vszakats Date: 2010-04-11 07:25:49 + (Sun, 11 Apr 2010) Log Message: --- 2010-04-11 09:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * external/pcre/Makefile ! Fixed to compile 8.02 with msvc and bcc. * package/winuni/RELNOTES * Updated external package versions. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/external/pcre/Makefile trunk/harbour/package/winuni/RELNOTES 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:[14313] trunk/harbour
Revision: 14313 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14313view=rev Author: vszakats Date: 2010-04-11 07:32:12 + (Sun, 11 Apr 2010) Log Message: --- 2010-04-11 09:31 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * INSTALL * HB_COMPILER_VER explanation made hopefully more clear. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL 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] My first study on hbqt code...
If I understand correctly (correct me if not): - You intend to create separate hbqt_gcpointer*() calls for each object type. No, my proposal 1) has just 2 functions, one hbqt_gcpointer for Qt objects that don't have pq and one hbqt_gcpointer_has_pq for objects that have one... Proposal 2) keeps only one function but uses bNew to store if pq is valid or not. Proposal 3) stress it more using QPointer in place of ph to streamline some routine... - To add NULL checking to these functions. Yes. But Pritpal says that we don't have such cases and the problem is only in destructor... Infact I proposed that bNew status bits to better trace what happens... --- I was also thinking about the possibility of eliminating all the QGC_POINTER_Q* structures at all and just use QGC_POINTER but with the addition of pq and bNews used as status... It would add 4 bytes to each Qt object All QGC_POINTER_Q* I examined are equal to QGC_POINTER or to QGC_POINTER plus pq member... I only don't know if it is possibile to have a generic definition QPointer * pq; So I believe that each QGC_POINTER_Q* that has no pq member can become a QGC_POINTER, while for the others that have the pq member a C++ expert should tell if QPointer * pq; is supported. I found also a case where QGC_POINTER_QHttpResponseHeader is defined, but a standard QGC_pointer is used Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] My first study on hbqt code...
Yes. But Pritpal says that we don't have such cases and the problem is
only in destructor... Infact I proposed that bNew status bits to
So such change can do no harm and should be done
to prove this statement of Pritpal and avoid any
future misunderstandings in this regard.
But, I doubt current situation is clean. To me this
little code shows a clear GPF situation, when no, or
wrong 1st parameter is passed to this function:
HB_FUNC( QT_QPUSHBUTTON_SETAUTODEFAULT )
{
hbqt_par_QPushButton( 1 )-setAutoDefault( hb_parl( 2 ) );
}
NULL check seems clearly required, otherwise '-'
may just fail.
So I believe that each QGC_POINTER_Q* that has no pq member can become
a QGC_POINTER, while for the others that have the pq member a C++
expert should tell if QPointer * pq; is supported.
I found also a case where QGC_POINTER_QHttpResponseHeader is defined,
but a standard QGC_pointer is used
Yes. Plus check TOFIX notes in HBQT code, and it's
worth to carefully read Przemek's recent quick summary
of HBQT problems, there are some important issues
raised there which may help finding the right direction.
(f.e. confusing/mixing raw pointers with GC collected
ones, which is another clear GPF situation).
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] My first study on hbqt code...
Yes. Plus check TOFIX notes in HBQT code, and it's worth to carefully read Przemek's recent quick summary of HBQT problems, there are some important issues raised there which may help finding the right direction. (f.e. confusing/mixing raw pointers with GC collected ones, which is another clear GPF situation). Can you point me to this message ? Date would be enough. Thanks Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] My first study on hbqt code...
On 2010 Apr 11, at 10:23, francesco perillo wrote:
Yes. Plus check TOFIX notes in HBQT code, and it's
worth to carefully read Przemek's recent quick summary
of HBQT problems, there are some important issues
raised there which may help finding the right direction.
(f.e. confusing/mixing raw pointers with GC collected
ones, which is another clear GPF situation).
Can you point me to this message ? Date would be enough.
Begin forwarded message:
From: Przemysław Czerpak
Date: 2010 March 12 11:42:00 CET
To: Harbour Project Main Developer List. harbour@harbour-project.org
Subject: Re: [Harbour] GC Pointers - Anyway to detatch them ?
Reply-To: Harbour Project Main Developer List. harbour@harbour-project.org
On Thu, 11 Mar 2010, Pritpal Bedi wrote:
Hi,
I am looking for a solution where is GC pointer is
detatched from freeing it, all other operations remaining
the same.
You have to implement it.
Add to GC structure 'detached' member which will inform you destructor
code executed by our GC that it should not release the QT object.
QT Object should be 'detached' when they are attached to some other
objects and will be freed together with them.
I do not know the HBQT details but if possible I suggest to also clean
references to such object from GC pointer item so it will not be
longer accessible as stand alone object (it's enough to set NULL/0
to object pointer in GC block).
It is possible that I am not been able to explain what I need properly.
In hbQT we are been unable to know, at certain points, when
Qt releases the pointer. As per inherent nature of pointers
C or C++ does not set the value of pointer variable to NULL.
???
Sorry but this suggests that some code is broken or wrongly casted
and has to be fixed. You have to isolate such places to check where
exactly the problem appears to eliminate similar situations in the
future and of course fix them.
I do not understand current HBQT code so I cannot help in details.
Looks that you are using 'QPointer pq' only as some type of dummy
pointer which protects against multiple call to 'delete' operator
in GC pointer item destructor but it's not used at all to resolve
the main problem and blocking access to freed object for all other
code.
I also do not see any protection against wrong object casting and
raw pointer items are accepted what effectively blocks any serious
cleanups. Few months ago I sent code example which adds such protection
to this list.
You cannot make code which is only partially safe. It will never work
correctly. It has to be fully safe or it is extremely hard to locate
real sources of problems. I.e. due to unprotected ph member of
QGC_POINTER you can encapsulate pointer to some freed object in
hb_gcAlloc() block and return it to PRG code as GC pointer item.
From the beginning it's wrong pointer so it will has to fail inside
GC release operation so you are looking for workarounds inside GC
pointer item destructors when in fact they do not create any problems.
The code is growing up and the number of potential problems is also
increased and it's harder to fully follow all internal dependencies.
Finally it's fighting with the ghosts. As long as the base things are
not really safe then resolving upper level problems seems to be waste
of time because no one can say what is the real source of problem.
And hence when it is subject to freeing, GC does not
know if it has already been freed and hence GPF's.
Yes of course. Such situations are unacceptable and definitely
have to be fixed. Our GC have to be informed that some objects
were released. QPointer calls should make it.
I have a mechanism in place where all delete operations
can be carried on as per Qt specs, I just want that the
pointer is not freeed in GC. It will only detatch GC from it
and will clear its stack.
Maybe I'm missing sth but seems that It will only hides the real bugs.
The easiest method is redirecting FREE message to dummy method which
does nothing. Functionally you will reach the same results. Memory leak
which eliminates the problem of accessing freed memory.
If you want to create really working solution then you have to start
from the beginning and fix the code using GC pointer items. If you need
sth like:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), iParam );
if( p p-ph )
return p-ph;
else if( HB_ISPOINTER( iParam ) )
return hb_parptr( iParam ); /* TOFIX: In what cases is this needed?
Reference counting to avoid referring to freed pointers? */
else
return NULL; /* TODO: Still better if RTE. */
}
then it means that your code is wrong.
p-ph is not cleared when QT freese the object and:
else if( HB_ISPOINTER( iParam ) )
return hb_parptr( iParam );
means that you still have some completely unsafe pointer items
which can make memory corruptions and any create
Re: [Harbour] My first study on hbqt code...
It seems that I'm looking in the right direction And this one ? I also do not see any protection against wrong object casting and raw pointer items are accepted what effectively blocks any serious cleanups. Few months ago I sent code example which adds such protection to this list. Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Full path of current folder
Hello All Is this the correct way to build fully qualified path given a file in current folder, for *nixes ? On Windows it works perfect. hb_curDrive() + hb_osDriveSeparator() + hb_osPathSeparator() + CurDir() + hb_osPathSeparator() + cMyFile.ext - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/Full-path-of-current-folder-tp4884986p4884986.html Sent from the harbour-devel 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] Full path of current folder
Hi Pritpal, Hello All Is this the correct way to build fully qualified path given a file in current folder, for *nixes ? On Windows it works perfect. hb_curDrive() + hb_osDriveSeparator() + hb_osPathSeparator() + CurDir() + hb_osPathSeparator() + cMyFile.ext I'm not sure why you need it, but the best (and only portable!) way to refer to file in current drive/dir, is just to not use any absolute path at all, IOW: cMyFile.ext Any other solution has problems. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Full path of current folder
Viktor Szakáts wrote: hb_curDrive() + hb_osDriveSeparator() + hb_osPathSeparator() + CurDir() + hb_osPathSeparator() + cMyFile.ext I'm not sure why you need it, but the best (and only portable!) way to refer to file in current drive/dir, is just to not use any absolute path at all, IOW: cMyFile.ext Any other solution has problems. This is what I suspected. The question was of cosmatic importance. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/Full-path-of-current-folder-tp4884986p4885036.html Sent from the harbour-devel 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:[14314] trunk/harbour
Revision: 14314 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14314view=rev Author: vszakats Date: 2010-04-11 11:00:41 + (Sun, 11 Apr 2010) Log Message: --- 2010-04-11 13:00 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * INSTALL + Added (untested) examples for upcoming Windows SDK 7.1 and MSVS 2010. (to be released tomorrow) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL 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:[14315] trunk/harbour
Revision: 14315 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14315view=rev Author: vszakats Date: 2010-04-11 11:23:52 + (Sun, 11 Apr 2010) Log Message: --- 2010-04-11 13:23 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * package/winuni/RELNOTES * Preparing for Open Watcom 1.9 and MSVS 2010 / WSDK 7.1. * contrib/hbide/hbide.ch ! Added #include hbtrace.ch Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.ch trunk/harbour/package/winuni/RELNOTES 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:[14316] trunk/harbour
Revision: 14316 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14316view=rev Author: vszakats Date: 2010-04-11 11:35:38 + (Sun, 11 Apr 2010) Log Message: --- 2010-04-11 13:35 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbmzip/minizip.dif * contrib/hbmzip/ioapi.h + Enabled 64-bit file operations for open watcom 1.9. ! Fixed typo in prev commit regarding watcom. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbmzip/ioapi.h trunk/harbour/contrib/hbmzip/minizip.dif 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:[14317] trunk/harbour
Revision: 14317 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14317view=rev Author: vszakats Date: 2010-04-11 11:50:46 + (Sun, 11 Apr 2010) Log Message: --- 2010-04-11 13:50 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbmzip/minizip.dif * contrib/hbmzip/ioapi.h + Enabled 64-bit file operations for open watcom 1.9. (no go, reverted) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbmzip/ioapi.h trunk/harbour/contrib/hbmzip/minizip.dif 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] Installation of hbide
On 11/04/10 12:10, Andriy K wrote: Hi! I installed Harbour on my Ubuntu 9.10 64-bit. I followed the instructions http://www.elart.it/links/harbourhowto_deb_en.php Everything was going well, except installation of hbide. I typed cd $HOME/src/contrib/hbide bud the directory did not exist. Then I realized that there is a directory $HOME/src/harbour/contrib/hbide I typed cd $HOME/src/harbour/contrib/hbide and then hbmk2 hbide.hbp -rebuild but I have got an error message: hbmk2: Processing configuration: /usr/bin/hbmk.cfg hbmk2: Compiling Harbour sources... Harbour 2.1.0dev (Rev. 14313) Copyright (c) 1999-2010, http://www.harbour-project.org/ Compiling 'hbide.prg'... Lines 6501, Functions/Procedures 27 Generating C source output to '.hbmk/linux/gcc/hbide.c'... Done. Compiling 'ideobject.prg'... ideobject.prg(233) Warning W0001 Ambiguous reference 'HB_TR_ALWAYS' ideobject.prg(246) Warning W0001 Ambiguous reference 'HB_TR_ALWAYS' No code generated. hbmk2: Error: Running Harbour compiler (embedded). 1 (/usr/bin/harbour) -n2 hbide.prg ideobject.prg idestylesheets.prg idetags.prg idemisc.prg ideactions.prg ideeditor.prg idefindreplace.prg idedocks.prg idesaveload.prg iderequests.prg idethemes.prg ideprojmanager.prg idesources.prg ideharbourhelp.prg ideenviron.prg idehome.prg idefunctions.prg idedocwriter.prg ideskeletons.prg idewizard.prg idetools.prg ideshortcuts.prg -w3 -es2 -gc3 -o.hbmk/linux/gcc/ -i/usr/include/harbour -i../hbxbp -i../hbqt Then I tried ./hbide but the file did not exist. Does anybody have any suggestions how to install hbide? Thanks in advance for your help. Regards, Andriy Yes there seems to be a problem with the current build since yesterday. If you move into /contrib and issue:- svn co -r 14262 https://harbour-project.svn.sourceforge.net/svnroot/harbour-project/trunk/harbour/contrib/hbide to revert to version 14262 that's a few days old, then:- cd hbide hbmk2 hbide.hbp It should build OK - it did for me. Barry ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Installation of hbide
Update from svn... after harbour-project:[14315] trunk/harbour should be ok ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Pritpal, can you commit this more HB_TRACE ?
void * hbqt_gcpointer( int iParam )
{
HB_TRACE( HB_TR_DEBUG, ( hbqt_gcpointer iParam=%d, iParam ) );
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), iParam );
if( p p-ph )
{
HB_TRACE( HB_TR_DEBUG, ( hbqt_gcpointer returns p-ph
ph=%p, p-ph ) );
return p-ph;
}
else if( HB_ISPOINTER( iParam ) )
{
HB_TRACE( HB_TR_DEBUG, ( hbqt_gcpointer returns hb_parptr(
iParam ) ) );
return hb_parptr( iParam ); /* TOFIX: In what cases is this
needed? Reference counting to avoid referring to freed pointers? */
}
else {
HB_TRACE( HB_TR_DEBUG, ( HBQT_GCPOINTER RETURNS NULL ) );
return NULL; /* TODO: Still better if RTE. */
}
}
From my logs, you can't RTE because when you, for example, create a
QPushButton with
hello := QPushButton():new( )
there is a
pObj = ( QPushButton* ) new QPushButton( hbqt_par_QWidget( 1 ) ) ;
hbqt_par_QWidget( 1 ) is a define to hbqt_gcpointer... if parameter at
harbour level is not present hbqt_gcpointer returns NULL. If the
parameter is mandatory, probably it should be enforced at harbour
class level
Francesco
there is a
HB_TRACE( HB_TR_DEBUG, ( HBQT_GCPOINTER RETURNS NULL ) );
return NULL; /* TODO: Still better if RTE. */
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Pritpal, can you commit this more HB_TRACE ?
Hi Francesco,
Maybe it'd be a good idea to also add similar traces to
hbqt_gcpointerFromItem(), hbqt_pPtrFromItem() and hbqt_pPtrFromObj()
function.
Brgds,
Viktor
On 2010 Apr 11, at 15:01, francesco perillo wrote:
void * hbqt_gcpointer( int iParam )
{
HB_TRACE( HB_TR_DEBUG, ( hbqt_gcpointer iParam=%d, iParam ) );
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), iParam );
if( p p-ph )
{
HB_TRACE( HB_TR_DEBUG, ( hbqt_gcpointer returns p-ph
ph=%p, p-ph ) );
return p-ph;
}
else if( HB_ISPOINTER( iParam ) )
{
HB_TRACE( HB_TR_DEBUG, ( hbqt_gcpointer returns hb_parptr(
iParam ) ) );
return hb_parptr( iParam ); /* TOFIX: In what cases is this
needed? Reference counting to avoid referring to freed pointers? */
}
else {
HB_TRACE( HB_TR_DEBUG, ( HBQT_GCPOINTER RETURNS NULL ) );
return NULL; /* TODO: Still better if RTE. */
}
}
From my logs, you can't RTE because when you, for example, create a
QPushButton with
hello := QPushButton():new( )
there is a
pObj = ( QPushButton* ) new QPushButton( hbqt_par_QWidget( 1 ) ) ;
hbqt_par_QWidget( 1 ) is a define to hbqt_gcpointer... if parameter at
harbour level is not present hbqt_gcpointer returns NULL. If the
parameter is mandatory, probably it should be enforced at harbour
class level
Francesco
there is a
HB_TRACE( HB_TR_DEBUG, ( HBQT_GCPOINTER RETURNS NULL ) );
return NULL; /* TODO: Still better if RTE. */
___
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] Pritpal, can you commit this more HB_TRACE ?
Maybe it'd be a good idea to also add similar traces to hbqt_gcpointerFromItem(), hbqt_pPtrFromItem() and hbqt_pPtrFromObj() function. Yes, of course. ___ 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:[14318] trunk/harbour
Revision: 14318 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14318view=rev Author: vszakats Date: 2010-04-11 13:42:21 + (Sun, 11 Apr 2010) Log Message: --- 2010-04-11 15:41 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_destruct.cpp + Added trace calls. (pls correct me if there is a typo, I don't have capacity to rebuild QT components these days) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt_destruct.cpp 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:[14319] trunk/harbour
Revision: 14319 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14319view=rev Author: vszakats Date: 2010-04-11 13:54:25 + (Sun, 11 Apr 2010) Log Message: --- 2010-04-11 15:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/qtgui/QInputContext.cpp ! Deleted hbqt_getmemused() reference. How could this file not be updated automatically? * contrib/hbqt/qtgui/QInputContext.cpp * contrib/hbqt/qtcore/QChar.cpp * contrib/hbqt/qtcore/TQChar.prg ! Added missing SVN props. * contrib/hbqt/hbqt.h * contrib/hbqt/hbqt.hbc * contrib/hbqt/hbqt_base.cpp * contrib/hbqt/hbqts.hbc - Deleted Windows specific memory tracing. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt.h trunk/harbour/contrib/hbqt/hbqt.hbc trunk/harbour/contrib/hbqt/hbqt_base.cpp trunk/harbour/contrib/hbqt/hbqts.hbc trunk/harbour/contrib/hbqt/qtcore/QChar.cpp trunk/harbour/contrib/hbqt/qtcore/TQChar.prg trunk/harbour/contrib/hbqt/qtgui/QInputContext.cpp Property Changed: trunk/harbour/contrib/hbqt/qtcore/QChar.cpp trunk/harbour/contrib/hbqt/qtcore/TQChar.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: SF.net SVN: harbour-project:[14318] trunk/harbour
vszakats wrote: 2010-04-11 15:41 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_destruct.cpp + Added trace calls. (pls correct me if there is a typo, I don't have capacity to rebuild QT components these days) Seems to be working OK. Compiles fine but I did not check with DEBUG trace, though I do not feel there would be problem. Can you remove hb_getMemUsed() calls from hbide.prg also ? My setup is in indifferent state per hbIDE and cannot commit as a part. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-14318-trunk-harbour-tp4885573p4885690.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
On 09/04/10 17:43, Barry Jackson wrote: On 09/04/10 16:26, Pritpal Bedi wrote: IF hbide_getOS() == nix cArg := iif( empty( ::cBatch ), cC, cC + '.' + ::cBatch + ) cArg += cExeHbMk2 + + cHbpPath + cCmdParams + '' ELSE *cArgs := '-c . ' + /home/baz/tmp/ahrl8i.sh hbmk2 /home/baz/hash/ash.hbp -q -trace -info -lang=en' ...to add to my other reply (which is taking for ever to hit the list) the above is missing a space after . however with it there it still fails with same invalid option error from hbide, but does run from cmd line. Rgds Barry ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour Output from latest SVN (14320) :- Project [ ash ]Launch [ No ]Rebuild [ No ]Started [ 16:08:44 ] Batch File Exists = /home/baz/tmp/yydylr.sh Batch File Contents = #!/bin/sh export PATH=$PATH:/home/baz/SVN/harbour/bin/linux/gcc echo this ran /home/baz/hash/ash_hbide.txt hbmk2 /home/baz/hash/ash.hbp -q -trace -info -lang=en Command = /bin/bash Arguments = -c /home/baz/tmp/yydylr.sh CurDir() = home/baz/hash Starting in = /home/baz/hash/ /bin/bash: - : invalid option Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --protected --rcfile --restricted --verbose --version --wordexp Shell options: -irsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option Exit Code [ 2 ]Exit Status [ 0 ]Finished at [ 16:08:44 ]Done in [ 0.63 Secs ] Rgds, Barry ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: HBIDE Project build start folder problem
Barry Jackson wrote: Output from latest SVN (14320) :- Project [ ash ]Launch [ No ]Rebuild [ No ]Started [ 16:08:44 ] Batch File Exists = /home/baz/tmp/yydylr.sh Batch File Contents = #!/bin/sh export PATH=$PATH:/home/baz/SVN/harbour/bin/linux/gcc echo this ran /home/baz/hash/ash_hbide.txt hbmk2 /home/baz/hash/ash.hbp -q -trace -info -lang=en Command = /bin/bash Arguments = -c /home/baz/tmp/yydylr.sh CurDir() = home/baz/hash Starting in = /home/baz/hash/ /bin/bash: - : invalid option Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug Can you change cC := iif( hbide_getOS() == nix, -c , /C ) to cC := iif( hbide_getOS() == nix, -c ., /C ) and try again? - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-Project-build-start-folder-problem-tp4861627p4885921.html Sent from the harbour-devel 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] Re: SF.net SVN: harbour-project:[14313] trunk/harbour
Hi Rc compiler will have /nologo param only in next version in VS2010. BRGDS - brgs Franček Prijatelj -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-14313-trunk-harbour-tp4884692p4885965.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug Can you change cC := iif( hbide_getOS() == nix, -c , /C ) to cC := iif( hbide_getOS() == nix, -c ., /C ) and try again? Rather to: cC := iif( hbide_getOS() == nix, , /C ) An .sh file is not a command, so -c is just not needed there. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] [Viktor] Can we delete the -nologo parameter for rc.exe ?
Viktor, Seems that rc.exe hasn't a -nologo parameter. Can I safely remove that in the config/win/msvc.mk file at SVN ? best regards, Teo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[14313] trunk/harbour
Hi, Yes, so delete HB_COMPILER setting to let the build system autodetect your compiler plus version. Or set compiler version manually. Nothing personal, but I'd like to ask mailing list participants to read the e-mails coming to the list. It's pretty inefficient to explain the same thing every second/third day. I update INSTALL doc, which always has correct and up to date information, so pls read it if messages were missed. And to reiterate: I recommend everyone to delete HB_COMPILER setting _now_. It's not needed in 99% of cases. Brgds, Viktor On 2010 Apr 11, at 18:00, Franček Prijatelj wrote: Hi Rc compiler will have /nologo param only in next version in VS2010. BRGDS - brgs Franček Prijatelj -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-14313-trunk-harbour-tp4884692p4885965.html Sent from the harbour-devel 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
Re: [Harbour] [Viktor] Can we delete the -nologo parameter for rc.exe ?
Seems that rc.exe hasn't a -nologo parameter. It has, in MSVS 2010. Can I safely remove that in the config/win/msvc.mk file at SVN ? There is a better solution: See my just sent e-mail. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] [Viktor] Can we delete the -nologo parameter for rc.exe ?
Hello Viktor, On Apr 11, 2010, at 11:16 AM, Viktor Szakáts wrote: Seems that rc.exe hasn't a -nologo parameter. It has, in MSVS 2010. Can I safely remove that in the config/win/msvc.mk file at SVN ? There is a better solution: See my just sent e-mail. I just did, and I'm a little confused here: I have (in the same Windows machine) several C/C++ compilers: - MSVC ( 8 9 versions ) - MinGW - BCC - OpenWatcom If I remove the HB_COMPILER option then the build process at Harbour detects the compiler as MinGW. So in my case, I have to manually set the HB_COMPILER option. The file at config/win/msvc.mk says: ifeq ($(filter $(HB_COMPILER_VER),600 700 710 800 900),) RCFLAGS += -nologo endif So, what value I have to give to HB_COMPILER_VER to do not execute the RCFLAGS += -nologo ? best regards, Teo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Installation of hbide
2010/4/11 Andriy K andriy...@yahoo.de Hi! I installed Harbour on my Ubuntu 9.10 64-bit. I followed the instructions http://www.elart.it/links/harbourhowto_deb_en.php Everything was going well, except installation of hbide. I typed cd $HOME/src/contrib/hbide bud the directory did not exist. Then I realized that there is a directory $HOME/src/harbour/contrib/hbide There is a typo (now i correct it) and i must made a better work... Thank you, best regards Marco -- Linux Infinite Freedom ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] [Viktor] Can we delete the -nologo parameter for rc.exe ?
Hi, There is a better solution: See my just sent e-mail. I just did, and I'm a little confused here: I have (in the same Windows machine) several C/C++ compilers: - MSVC ( 8 9 versions ) - MinGW - BCC - OpenWatcom If I remove the HB_COMPILER option then the build process at Harbour detects the compiler as MinGW. So in my case, I have to manually set the HB_COMPILER option. So set it, and also set HB_COMPILER_VER accordingly. It's always a good practice if you want to make sure proper build options are used by Harbour build process and hbmk2. There is no way to make up a default which works properly for everyone. I'd however not recommend keeping that many tools in the PATH at the same time. It can be source of many strange build errors, even with Harbour. It's also a basic recommendation in INSTALL. BTW this rule applies even more so for other 3rd party package, so it's not a Harbour thing or my invention. Locally I use small batch files to setup the environment for the compiler I'd like to use at any moment, f.e.: 'mi hbmk2 hello.prg', to select mingw and build something. The file at config/win/msvc.mk says: ifeq ($(filter $(HB_COMPILER_VER),600 700 710 800 900),) RCFLAGS += -nologo endif So, what value I have to give to HB_COMPILER_VER to do not execute the RCFLAGS += -nologo ? Next time there might be other options which depend on compiler version, so I don't want to remove this. At least the problem isn't hidden now. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Compiling CGI programs and RUN on Apache
I am just trying to compile and test , sample testcgi.prg from test folder and another samples of cgi , and only obtain this error from web server My server works ok , because I test it with an sample Xharbour compiled CGI program and works ok Any Help ? Bruno Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, y...@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. -- Apache/2.0.63 (Win32) PHP/5.2.6 Server at localhost Port 80 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] [Viktor] Can we delete the -nologo parameter for rc.exe ?
Hello Viktor, On Apr 11, 2010, at 12:02 PM, Viktor Szakáts wrote: Hi, [snip] I'd however not recommend keeping that many tools in the PATH at the same time. It can be source of Thank you, this solved my problem: I was keeping in the path the C:\MinGW\bin directory in order to find the MinGW make utility (now contained in the Harbour tree). Thanks again for the explanation. [snip] best regards, Teo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Compiling CGI programs and RUN on Apache
To compile i am using: hbmk2 testcgi -lgtcgi It is ok that Bruno 2010/4/11 Bruno Luciani bruno.luci...@gmail.com I am just trying to compile and test , sample testcgi.prg from test folder and another samples of cgi , and only obtain this error from web server My server works ok , because I test it with an sample Xharbour compiled CGI program and works ok Any Help ? Bruno ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbIDE - Downloads statistics from hbide.vouch.info
Hello Everybody There are 164 downloads since 29Mar2010. Minus 2 what I initiated to test. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/hbIDE-Downloads-statistics-from-hbide-vouch-info-tp4886350p4886350.html Sent from the harbour-devel 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] Re: [Viktor] Can we delete the -nologo parameter for rc.exe ?
Hi I had the same problem. Multiple configurations - msvc and mingw and c:\mingw\bin in path. (for mingw32-make) So autodetection didn't work. And the same was with: SET HB_COMPILER=msvc SET HB_COMPILER_VER=800 Both variants work now when i removed mingw path. BRGDS - brgs Franček Prijatelj -- View this message in context: http://n2.nabble.com/Viktor-Can-we-delete-the-nologo-parameter-for-rc-exe-tp4885998p4886371.html Sent from the harbour-devel 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] Re: [Viktor] Can we delete the -nologo parameter for rc.exe ?
On 2010 Apr 11, at 19:41, Franček Prijatelj wrote: Hi I had the same problem. Multiple configurations - msvc and mingw and c:\mingw\bin in path. (for mingw32-make) So autodetection didn't work. And the same was with: SET HB_COMPILER=msvc SET HB_COMPILER_VER=800 Both variants work now when i removed mingw path. Sorry, but I can't follow what you did. If you specify above two settings, it should work regardless of mingw being also in PATH. In my local tests everything works as expected, msvc compiler selected, -nologo switch controlled by version, with or without mingw. BTW, maybe it's useful information for someone, but -nologo is also supported by rc.exe (v6.1.7600.16385) packaged with Win SDK 7. I can just recommend this package over MSVS 2008. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Compiling CGI programs and RUN on Apache
The sample testhtml works ok , but testcgi not Bruno 2010/4/11 Bruno Luciani bruno.luci...@gmail.com I am just trying to compile and test , sample testcgi.prg from test folder and another samples of cgi , and only obtain this error from web server My server works ok , because I test it with an sample Xharbour compiled CGI program and works ok Any Help ? Bruno ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbIDE - Keyboard Shortcuts - Behavior Overview
Hello Everybody Ground is ready to launch Keyboard Shortcuts in hbIDE. Before I end-up in a mess I need group opinion as to how user-defined or user-altered definitions should behave. Current implementation is like: Keyboard shortcut is only defined for menu options. Toolbar icons do not consider them. Defined with menu option ensures that those can be activated from anywhere in hbIDE. Some actions are defined only for active editor instance a Now if user alters one, say, CTRL+D ( Duplicate Line ), to something DeleteLine(), how it should be treated? Note that once defined as with menu option, such action cannot be intercepted from within editor instance. One option could be, do not define any shortcut key with menu option, only show it with menu prompt text, and intercept the same in editor instance. And this makes the engine really robust. Note: action will always be carried as is if menu option is clicked. The second option could be, change the menu prompt and attch new definition user has altered. This will make menu options always inconsistent. I would prefer the first option. Another options you are to suggest. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/hbIDE-Keyboard-Shortcuts-Behavior-Overview-tp4886460p4886460.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
On 11/04/10 17:07, Viktor Szakáts wrote: Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug Can you change cC := iif( hbide_getOS() == nix, -c , /C ) to cC := iif( hbide_getOS() == nix, -c ., /C ) and try again? Rather to: cC := iif( hbide_getOS() == nix, , /C ) An .sh file is not a command, so -c is just not needed there. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour I thought I would go with Viktor's version first! :-) :-) :-) :-) :-) :-) Project [ ash ]Launch [ No ]Rebuild [ No ]Started [ 19:04:46 ] Batch File Exists = /home/baz/tmp/91uqn7.sh Batch File Contents = #!/bin/sh export PATH=$PATH:/home/baz/SVN/harbour/bin/linux/gcc echo this ran /home/baz/hash/ash_hbide.txt hbmk2 /home/baz/hash/ash.hbp -q -trace -info -lang=en Command = /bin/bash Arguments = /home/baz/tmp/91uqn7.sh CurDir() = home/baz/hash Starting in = /home/baz/hash/ hbmk2: Autodetected platform: linux hbmk2: Autodetected C compiler: gcc hbmk2: Using Harbour: /home/baz/SVN/harbour/bin /home/baz/SVN/harbour/include /home/baz/SVN/harbour/lib/linux/gcc /home/baz/SVN/harbour/lib/linux/gcc hbmk2: Harbour compiler command (embedded): (/home/baz/SVN/harbour/bin/linux/gcc/harbour) -n2 /home/baz/hash/ash.prg /home/baz/hash/f_amax.prg /home/baz/hash/b_bget.prg /home/baz/hash/f_getini.prg /home/baz/hash/products.prg /home/baz/hash/f_chtd.prg /home/baz/hash/catalog.prg /home/baz/hash/account1.prg /home/baz/hash/sales.prg /home/baz/hash/f_sysset.prg /home/baz/hash/utils.prg /home/baz/hash/ashelp.prg /home/baz/hash/company.prg /home/baz/hash/l_syserr.prg /home/baz/hash/f_inxcnt.prg /home/baz/hash/terminal.prg /home/baz/hash/term2.prg /home/baz/hash/f_beep.prg /home/baz/hash/l_dbfsek.prg /home/baz/hash/lists.prg /home/baz/hash/l_dbftra.prg /home/baz/hash/f_gblank.prg /home/baz/hash/f_fn_ok.prg /home/baz/hash/l_dbfzap.prg /home/baz/hash/f_fn_mat.prg /home/baz/hash/f_bskip.prg /home/baz/hash/batch.prg /home/baz/hash/web.prg /home/baz/hash/f_clmess.prg /home/baz/hash/f_mbeep.prg /home/baz/hash/f_recalc.prg /home/baz/hash/f_fpknum.prg /home/baz/hash/f_outed.prg /home/baz/hash/f_strmem.prg /home/baz/hash/f_inkeyw.prg /home/baz/hash/f_delwin.prg /home/baz/hash/f_tagged.prg /home/baz/hash/l_sysscr.prg /home/baz/hash/l_syspop.prg /home/baz/hash/f_go_bot.prg /home/baz/hash/account2.prg /home/baz/hash/f_bx_qry.prg /home/baz/hash/vatrep.prg /home/baz/hash/year_end.prg /home/baz/hash/f_updtda.prg /home/baz/hash/f_go_top.prg /home/baz/hash/f_ntod.prg /home/baz/hash/l_sysdat.prg /home/baz/hash/l_sysntx.prg /home/baz/hash/bank.prg /home/baz/hash/l_syscol.prg /home/baz/hash/l_colsys.prg /home/baz/hash/l_systmu.prg /home/baz/hash/l_sysmnu.prg /home/baz/hash/l_syspri.prg /home/baz/hash/f_memvar.prg /home/baz/hash/l_dbfskp.prg /home/baz/hash/f_lupdat.prg /home/baz/hash/f_gettop.prg /home/baz/hash/f_locate.prg /home/baz/hash/orders.prg /home/baz/hash/f_dbfuse.prg /home/baz/hash/f_getco.prg /home/baz/hash/f_invtag.prg /home/baz/hash/f_ctrtag.prg /home/baz/hash/ctools.prg /home/baz/hash/f_tag.prg /home/baz/hash/f_hblog.prg -q -o/home/baz/tmp/ -i/home/baz/SVN/harbour/include Harbour 2.1.0dev (Rev. 14310) Copyright (c) 1999-2010, http://www.harbour-project.org/ hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/ash.c -o /home/baz/tmp/ash.o hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/f_amax.c -o /home/baz/tmp/f_amax.o hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/b_bget.c -o /home/baz/tmp/b_bget.o hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/f_getini.c -o /home/baz/tmp/f_getini.o hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/products.c -o /home/baz/tmp/products.o hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/f_chtd.c -o /home/baz/tmp/f_chtd.o hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/catalog.c -o /home/baz/tmp/catalog.o hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/account1.c -o /home/baz/tmp/account1.o hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe
[Harbour] HBIDE problem / redundancy
Hi Pritpal, I've found that you've decided to replicate complete help texts of hbmk2, harbour, xpp.exe and alink.exe hard-wired inside HBIDE source code. While the latter two may well violate copyrights, it's even not a good idea to replicate external tool help text like that in HBIDE code for Harbour's own utilities. The smaller problem is that it doesn't honor translations, the bigger is that it may be off compared to the actual version of hbmk2 / harbour being used. IOW it breaks separation of layers and responsibilities. Please remove them and just call these tools with --help or equivalent help option to query help text and present the output to users. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: HBIDE problem / redundancy
Viktor Szakáts wrote: I've found that you've decided to replicate complete help texts of hbmk2, harbour, xpp.exe and alink.exe hard-wired inside HBIDE source code. While the latter two may well violate copyrights, it's even not a good idea to replicate external tool help text like that in HBIDE code for Harbour's own utilities. The smaller problem is that it doesn't honor translations, the bigger is that it may be off compared to the actual version of hbmk2 / harbour being used. IOW it breaks separation of layers and responsibilities. Please remove them and just call these tools with --help or equivalent help option to query help text and present the output to users. I kept it here for reference sake to build some type of user interface, i.e, which type of input method be used if an option is a part of UI. Since I am not at this topic yet, it can be deleted. I will do it in next commit. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-problem-redundancy-tp4886596p4886643.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
Barry Jackson wrote: Can you change cC := iif( hbide_getOS() == nix, -c , /C ) to cC := iif( hbide_getOS() == nix, -c ., /C ) and try again? Rather to: cC := iif( hbide_getOS() == nix, , /C ) An .sh file is not a command, so -c is just not needed there. I thought I would go with Viktor's version first! :-) :-) :-) :-) :-) :-) Project [ ash ]Launch [ No ]Rebuild [ No ]Started [ 19:04:46 ] Batch File Exists = /home/baz/tmp/91uqn7.sh Batch File Contents = #!/bin/sh export PATH=$PATH:/home/baz/SVN/harbour/bin/linux/gcc echo this ran /home/baz/hash/ash_hbide.txt hbmk2 /home/baz/hash/ash.hbp -q -trace -info -lang=en Command = /bin/bash Arguments = /home/baz/tmp/91uqn7.sh CurDir() = home/baz/hash Starting in = /home/baz/hash/ hbmk2: Autodetected platform: linux hbmk2: Autodetected C compiler: gcc hbmk2: Using Harbour: /home/baz/SVN/harbour/bin /home/baz/SVN/harbour/include /home/baz/SVN/harbour/lib/linux/gcc /home/baz/SVN/harbour/lib/linux/gcc hbmk2: Harbour compiler command (embedded): ... Exit Code [ 0 ]Exit Status [ 0 ]Finished at [ 19:04:57 ]Done in [ 10.30 Secs ] No apologies for posting the whole output as it's been a long time coming! This is a non-GUI app and when built with the build and launch button the output adds:- Detected exeutable = ash Launching application [ /home/baz/hash/ash ] ... but nothing further - I don't know if this is correct in this situation. Well done everyone ! So we succeeded, at last. Thanks Viktor for pointing to keep everything in.sh/.bat and above tip. Thanks Przemek for understanding how bash commands work. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-Project-build-start-folder-problem-tp4861627p4886672.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
Barry Jackson wrote: This is a non-GUI app and when built with the build and launch button the output adds:- Detected exeutable = ash Launching application [ /home/baz/hash/ash ] ... but nothing further - I don't know if this is correct in this situation. It should launch theoretically. But let us examine how I am initiating the launch. #if 1 qProcess := QProcess():new() qProcess:setWorkingDirectory( hbide_pathToOSPath( oProject:wrkDirectory ) ) IF !empty( oProject:launchParams ) qStr := QStringList():new() qStr:append( oProject:launchParams ) qProcess:startDetached_1( cTargetFN, qStr ) ELSE qProcess:startDetached_2( cTargetFN ) ENDIF qProcess:waitForStarted() qProcess := NIL #else Please investigate. It is straight forward. Somewhere we are missing how should we pass the params to QProcess(). - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-Project-build-start-folder-problem-tp4861627p4886691.html Sent from the harbour-devel 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] Re: HBIDE problem / redundancy
Please remove them and just call these tools with --help or equivalent help option to query help text and present the output to users. I kept it here for reference sake to build some type of user interface, i.e, which type of input method be used if an option is a part of UI. Since I am not at this topic yet, it can be deleted. I will do it in next commit. Thank you. Three more issues (sorry to plug it like that, but I've stumbled upon them at this second): 1. Path to hbmk2 is ignored in Compiler Environments. Started off HBIDE with default settings, opened hbide.hbp, build obviously didn't work, so I set above option, and nothing changed when clicking Build. 2. In 'Compiler Environments' is says 'Save and Exit', while it should really say 'Save and Close'. There are other panels/dialogs with this same problem. 3. Envvar HBIDE_DIR_HBMK2 is also ignored. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: HBIDE Project build start folder problem
Pritpal Bedi wrote: It should launch theoretically. But let us examine how I am initiating the launch. #if 1 qProcess := QProcess():new() qProcess:setWorkingDirectory( hbide_pathToOSPath( oProject:wrkDirectory ) ) IF !empty( oProject:launchParams ) qStr := QStringList():new() qStr:append( oProject:launchParams ) qProcess:startDetached_1( cTargetFN, qStr ) ELSE qProcess:startDetached_2( cTargetFN ) ENDIF qProcess:waitForStarted() qProcess := NIL #else Please investigate. It is straight forward. Somewhere we are missing how should we pass the params to QProcess(). METHOD IdeProjManager:launchProject( cProject, cExe ) needs to be overhauled as it is Windows centric anyway. Because passed parameter is not having .exe as extnsion, nothing has hapened. Please check. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-Project-build-start-folder-problem-tp4861627p4886710.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
It should launch theoretically. But let us examine how I am initiating the launch. #if 1 qProcess := QProcess():new() qProcess:setWorkingDirectory( hbide_pathToOSPath( oProject:wrkDirectory ) ) IF !empty( oProject:launchParams ) qStr := QStringList():new() qStr:append( oProject:launchParams ) qProcess:startDetached_1( cTargetFN, qStr ) ELSE qProcess:startDetached_2( cTargetFN ) ENDIF qProcess:waitForStarted() qProcess := NIL #else Please investigate. It is straight forward. Somewhere we are missing how should we pass the params to QProcess(). Accidentally I've stumbled upon new code to detect executable name, and it's not right. First of all hbmk2: Linker command: text is only shown when -trace mode is used, second, there is no guarantee that '-o' option is used in all supported target compilers, this is not true even with current set of compilers. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: HBIDE problem / redundancy
Viktor Szakáts wrote: Three more issues (sorry to plug it like that, but I've stumbled upon them at this second): Any number of times. We all are working hard for some goal and every bit of participation is highly welcome. 1. Path to hbmk2 is ignored in Compiler Environments. Started off HBIDE with default settings, opened hbide.hbp, build obviously didn't work, so I set above option, and nothing changed when clicking Build. I had some issues regarding this when I was experimenting, now possibly lot have changed, let us do it once more. If I remember correctly, it had been HB_COMPILER something issue then. 2. In 'Compiler Environments' is says 'Save and Exit', while it should really say 'Save and Close'. There are other panels/dialogs with this same problem. Fixed. Please point-out other areas. When you are doing quick, you tend to do mistakes. 3. Envvar HBIDE_DIR_HBMK2 is also ignored. Please read answer to #1. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-problem-redundancy-tp4886596p4886747.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
Viktor Szakáts wrote: Accidentally I've stumbled upon new code to detect executable name, and it's not right. First of all hbmk2: Linker command: text is only shown when -trace mode is used, second, there is no guarantee that '-o' option is used in all supported target compilers, this is not true even with current set of compilers. I know this fact. But am short of insight how effectively should I detect it. Please tweak with this issue, if possible. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-Project-build-start-folder-problem-tp4861627p4886756.html Sent from the harbour-devel 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:[14321] trunk/harbour
Revision: 14321 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14321view=rev Author: vszakats Date: 2010-04-11 19:40:53 + (Sun, 11 Apr 2010) Log Message: --- 2010-04-11 21:40 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbide/ideprojmanager.prg ! Fixed to not ignore hbmk2 path as set in options or via envvar. ! Fixed to not use -c when calling bash with .sh script as parameter. ! Deleted attempt to detect output filename by parsing link command for -o option. This is not portable method. ! Fixed target filename detection to look for Chr( 10 ) instead of .exe. Detection is now fine, but it still cannot launch it for other reasons. Plus, detection only works when -inc mode is used. ! Deleted hard-coded help text of external tools. * contrib/hbide/idemisc.prg % Changed to not include '#!/bin/sh' in generated .sh file. + DirAddPathSep() renamed to hbide_DirAddPathSep() and made public. * contrib/hbide/hbide.prg - Deleted test code. * contrib/hbblink/blinker.prg ! Reverted previous wrong fix. (-C doesn't work as cmd.exe option) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbblink/blinker.prg trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idemisc.prg trunk/harbour/contrib/hbide/ideprojmanager.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: HBIDE problem / redundancy
Viktor Szakáts wrote: I don't understand that answer. What does this have to do with HB_COMPILER? I'm trying to find it, but there is a huge forest of classes and I can't easily oversee them. Simply the path is not used when forming hbmk2 executable name. Let us re-introduce it. Can you test after changing line 1236 cExeHbMk2 := hbmk2 /* Needs that path is already set before calling hbmk2 */ = cExeHbMk2 := ::oProject:cPathMk2 + hbmk2 - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-problem-redundancy-tp4886596p4886846.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
On 11/04/10 20:14, Pritpal Bedi wrote: Pritpal Bedi wrote: It should launch theoretically. But let us examine how I am initiating the launch. #if 1 qProcess := QProcess():new() qProcess:setWorkingDirectory( hbide_pathToOSPath( oProject:wrkDirectory ) ) IF !empty( oProject:launchParams ) qStr := QStringList():new() qStr:append( oProject:launchParams ) qProcess:startDetached_1( cTargetFN, qStr ) ELSE qProcess:startDetached_2( cTargetFN ) ENDIF qProcess:waitForStarted() qProcess := NIL #else Please investigate. It is straight forward. Somewhere we are missing how should we pass the params to QProcess(). METHOD IdeProjManager:launchProject( cProject, cExe ) needs to be overhauled as it is Windows centric anyway. Because passed parameter is not having .exe as extnsion, nothing has hapened. Please check. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ I hit another problem trying to test with a simple Hello World project. I have seen this before but was waiting until other issues were fixed. On attempting to add a second project to hbide, either by creating from scratch, or using an existing .hbp, this array bound error crashes hbide. http://i115.photobucket.com/albums/n287/barjac_2006/hbide10.png My ash project does not run now - I suspect a change in Harbour in the last few days has broken it as it has always been OK. Error DBCMD/35 Workarea not in use: __DBLOCATE Called from __DBLOCATE(0) Called from INTVAR(401) Called from MAIN(195) It's a very simple early routine that opens a .dbf, locates some data and closes it again, before main system is up and indexes opened etc. 399 FUNCTION intvar 400 USE company 401 LOCATE FOR co = ZZ 402 IF FOUND() 403zco = cmpny ---snip--- Rgds, Barry ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: HBIDE problem / redundancy
Pritpal Bedi wrote: Can you test after changing line 1236 cExeHbMk2 := hbmk2 /* Needs that path is already set before calling hbmk2 */ = cExeHbMk2 := ::oProject:cPathMk2 + hbmk2 I see you have committed the fix and also auto-detection of exe. Thanks. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-problem-redundancy-tp4886596p4886863.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
Barry Jackson wrote: I hit another problem trying to test with a simple Hello World project. I have seen this before but was waiting until other issues were fixed. On attempting to add a second project to hbide, either by creating from scratch, or using an existing .hbp, this array bound error crashes hbide. http://i115.photobucket.com/albums/n287/barjac_2006/hbide10.png First, do not mix two issues in one thread, open another. Can you guard idehome.prg#368 aadd( aHtm, '' + dtoc( dir_[ 1,3 ] ) + + dir_[ 1,4 ] ) with if ! empty( dir_ ) aadd( aHtm, '' + dtoc( dir_[ 1,3 ] ) + + dir_[ 1,4 ] ) endif Infact I know nothing about how things happen on *nixes. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/HBIDE-Project-build-start-folder-problem-tp4861627p4886893.html Sent from the harbour-devel 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] Re: HBIDE Project build start folder problem
On 11/04/10 21:08, Pritpal Bedi wrote: First, do not mix two issues in one thread, open another. Sorry Can you guard idehome.prg#368 aadd( aHtm, '' + dtoc( dir_[ 1,3 ] ) + + dir_[ 1,4 ] ) with if ! empty( dir_ ) aadd( aHtm, '' + dtoc( dir_[ 1,3 ] ) + + dir_[ 1,4 ] ) endif That worked - sort of, but it seems not to save the second project properly between runs, and mixes displayed info from one project in the other, so I now have just one very simple project to test this problem. Project [ hellotest ]Launch [ Yes ]Rebuild [ No ]Started [ 23:32:26 ] Batch File Exists = /home/baz/tmp/2bxo6s.sh Batch File Contents = #!/bin/sh export PATH=$PATH:/home/baz/SVN/harbour/bin/linux/gcc hbmk2 /home/baz/hbr/hbhello/hellotest.hbp -q -trace -info -lang=en Command = /bin/bash Arguments = /home/baz/tmp/2bxo6s.sh CurDir() = home/baz/hash Starting in = /home/baz/hbr/hbhello/ = CurDir() wrong - this project is not going into /home/baz/hash hbmk2: Autodetected platform: linux hbmk2: Autodetected C compiler: gcc hbmk2: Using Harbour: /home/baz/SVN/harbour/bin /home/baz/SVN/harbour/include /home/baz/SVN/harbour/lib/linux/gcc /home/baz/SVN/harbour/lib/linux/gcc hbmk2: Harbour compiler command (embedded): (/home/baz/SVN/harbour/bin/linux/gcc/harbour) -n2 /home/baz/hbr/hbhello/hellotest.prg -q -o/home/baz/tmp/ -i/home/baz/SVN/harbour/include Harbour 2.1.0dev (Rev. 14310) Copyright (c) 1999-2010, http://www.harbour-project.org/ hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/hellotest.c -o /home/baz/tmp/hellotest.o hbmk2: C/C++ compiler command: gcc -c -O3 -Wall -W -pipe -I/home/baz/SVN/harbour/include /home/baz/tmp/hbmk_kv2ysd.c -o /home/baz/tmp/hbmk_kv2ysd.o hbmk2: Linker command: gcc /home/baz/tmp/hellotest.o /home/baz/tmp/hbmk_kv2ysd.o -Wl,--start-group -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgttrm -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lm -ldl -lrt -lpcre -lz -Wl,--end-group -ohellotest -L/home/baz/SVN/harbour/lib/linux/gcc Exit Code [ 0 ]Exit Status [ 0 ]Finished at [ 23:32:28 ]Done in [ 1.10 Secs ] Detected exeutable = hellotest== Typo :-) Launching application [ /home/baz/hbr/hbhello/hellotest ] == Looks correct. There is no more output in the console though. On command line in hbhello:- [...@jackodesktop hbhello]$ ./hellotest Hello World or from anywhere :- [...@jackodesktop ~]$ /home/baz/hbr/hbhello/hellotest Hello World How is current directory set? Rgds, Barry ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Compiling CGI programs and RUN on Apache
Nobody use CGI ? Can anybody try to test the CGI sample that comes with harbour in test folder and say to me if work ? Bruno 2010/4/11 Bruno Luciani bruno.luci...@gmail.com I am just trying to compile and test , sample testcgi.prg from test folder and another samples of cgi , and only obtain this error from web server My server works ok , because I test it with an sample Xharbour compiled CGI program and works ok Any Help ? Bruno Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, y...@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. -- Apache/2.0.63 (Win32) PHP/5.2.6 Server at localhost Port 80 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HBIDE problem / redundancy
On 11/04/10 20:51, Pritpal Bedi wrote: Let us re-introduce it. Can you test after changing line 1236 cExeHbMk2 := hbmk2 /* Needs that path is already set before calling hbmk2 */ = cExeHbMk2 := ::oProject:cPathMk2 + hbmk2 - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ Needs cExeHbMk2 := ::oProject:cPathMk2 + /hbmk2 ^ then it's OK /home/baz/SVN/harbour/bin/linux/gcc/hbmk2 /home/baz/hbr/hbhello/hellotest.hbp -q -trace -info -lang=en Rgds Barry ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Improve on hbqt object handling
I have yet another proposal:
in QGC_POINTER_* a new member should be added, call it fingerprint.
Every QObject should be issued a different fingerprint, let's say
QApplication is 1, QPushButton is 2 and so on.
So when we get somehow a QGC_POINTER_* we can get back it's c++ class...
hbqt_gcpointer may accept as second parameter the fingerprint of the
requested object and RTE if not matched it may be 0 to not do any
check...
typedef struct
{
void * ph;
bool bNew;
QT_G_FUNC_PTR func;
QPointer QPushButton pq;
long fingerprint;
} QGC_POINTER_QPushButton;
p-bNew = bNew;
p-func = hbqt_gcRelease_QPushButton;
p-fingerprint = 2 ;
...
#define hbqt_par_QPushButton( n ) ( ( QPushButton
* ) hbqt_gcpointer( n ) )
becomes
#define hbqt_par_QPushButton( n ) ( ( QPushButton
* ) hbqt_gcpointer( n , 2 ) )
and hbqt_gcpinter is amended as necessary.
It must be said that hbqt_gcpointer is allways called via the previous
defines. Only in hbqt_destruct.cpp is called directly twice with -1
and a couple of times with iParam...
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Improve on hbqt object handling
francesco perillo wrote: I have yet another proposal: in QGC_POINTER_* a new member should be added, call it fingerprint. Let me _repeat_ again: Problem is not with functioning of the objects, that is working perfect. It lies when object is _destructed_ by Qt and when Harbour tries to _free_ the pointer. This is the scenario we should base our findings... oWnd contains oPushButton, oMenu's and lot other controls - comples parent child hirarchy. Now suppose oWnd goes out of scope, Harbour schedules garbage collection and it is not know in what order it will release the variables. Assume, oWidget is released first which contains many others. Our destructor will be called which in turn will issue delete ( QWidget * ) p-ph . The request will reach Qt GC ( they may call is with another name ) and Qt deletes oWidget and, by its way of handellings, Qt will also delete all childeren. The pointers held in Harbour GC of those children are still there to be released as per same cycle. And voila GPF, because those are already been freed by Qt. If you study hbXBP, I have implemented object destruction very carefully. Child first, parent next. That is why oDlg has ever to be issued :destroy() method which does not leave anything for GC to free them in arbitratory fashion. The whole point os distability is the way we need to handle destruction. Hope this info may prove helpful to hit the right solution. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/Improve-on-hbqt-object-handling-tp4887521p4887614.html Sent from the harbour-devel 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] Re: looking for hbqt GPFs...
francesco perillo wrote: If you are getting GPFs in a replicable and consistent way PLEASE contact me and help me replicate it on my pc I tried all day to get a GPF and got none... You tried with hbIDE ? If yes, please note that it is now optimized to destroy objects in proper way. There are a couple of places I know, but even they are OS dependant. BTW which compiler and OS you are trying with ? - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/looking-for-hbqt-GPFs-tp4887604p4887624.html Sent from the harbour-devel 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] Re: looking for hbqt GPFs...
I'm on XP, mingw32 gcc 4.4.-dw2 (TDM-2 mingw32) and Qt sdk 2010.02, should be Qt 4.6.2 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Improve on hbqt object handling
Let me _repeat_ again:
I know exactly what you have been saying for a long time :-)
this specific proposal was only to do parameter checking
Problem is not with functioning of the objects,
that is working perfect. It lies when object is _destructed_
by Qt and when Harbour tries to _free_ the pointer.
This is the scenario we should base our findings...
oWnd contains oPushButton, oMenu's and lot other controls - comples
parent child hirarchy. Now suppose oWnd goes out of scope, Harbour
schedules garbage collection and it is not know in what order it will
release the variables. Assume, oWidget is released first which contains
many others. Our destructor will be called which in turn will issue
delete ( QWidget * ) p-ph . The request will reach Qt GC ( they may
call is
with another name ) and Qt deletes oWidget and, by its way of
handellings,
Qt will also delete all childeren.
Perfect, this is exactly what Qt documentation says. This is normal.
And I checked this via the trace logs.
The pointers held in Harbour GC of
those
children are still there to be released as per same cycle. And voila
GPF, because
those are already been freed by Qt.
This should only happen if in this hierarchy there are objects without
QPointer... if all objects have QPointers then there is something
wrong... If there are objects that are not deriving from QObject so
that they can't have QPointer (is it ever possible for display classes
) I agree with you that this doing a recursion and deleting
objects ourself is the only way unless we overload the delete
operator, take the pointer value, lookup the address (via an HASH ???)
and discover the QGC_POINTER_* whose ph is equal to the pointer value.
in pseudo-code,
in hbqt_gcAllocate_*
hash[ p-ph ] = p
in the overloaded delete:
if ( t := hash[ ptr ] ) {
t-ph := 0;
remove hash[ ptr ];
}
If you accept my first idea to change bNew in a bitmap status you can
t-bNew |= QT_DELETED ;
In this way you should not care about object destruction order
I just found but not completely understood these two links:
http://silmor.de/33
http://search.cpan.org/~awin/PerlQt-2.105/doc/starting.pod#Object_destruction
Francesco
PS: Qt has an hash class, QHash...
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: looking for hbqt GPFs...
francesco perillo wrote: I'm on XP, mingw32 gcc 4.4.-dw2 (TDM-2 mingw32) and Qt sdk 2010.02, should be Qt 4.6.2 Tried through which program ? hbIDE ? demoXBP ? demoQT ? Or your own demo application ? Plus your results may not match ours because we still use 4.5.3 as announced in INSTALL. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/looking-for-hbqt-GPFs-tp4887604p4887767.html Sent from the harbour-devel 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] Re: Improve on hbqt object handling
francesco perillo wrote:
Let me _repeat_ again:
This should only happen if in this hierarchy there are objects without
QPointer... if all objects have QPointers then there is something
wrong... If there are objects that are not deriving from QObject so
that they can't have QPointer (is it ever possible for display classes
) I agree with you that this doing a recursion and deleting
objects ourself is the only way unless we overload the delete
operator, take the pointer value, lookup the address (via an HASH ???)
and discover the QGC_POINTER_* whose ph is equal to the pointer value.
We can overload new() and delete() operators.
Read previsous messages and flag -hbnocppmm to hbMK2.
How you can do so:
1. Put following code in cppstub.cpp and add to hbide.hbp
const char * __hbmk2_hbcppmm( void )
{
return HBCPPMM;
}
int getnew( void )
{
static int i = 0;
return ++i;
}
int getdelete( void )
{
static int i = 0;
return ++i;
}
void * operator new( size_t nSize )
{
if( nSize == 0 )
{
nSize = 1;
}
void * ptr = hb_xgrab( nSize );
HB_TRACE( HB_TR_ALWAYS, ( new( %p ) %i %i, ptr, nSize,
getnew() ) );
return ptr;
}
void operator delete( void * ptr )
{
if( ptr )
{
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( delete( void * %p ) %s %i, ptr,
0, getdelete() ) );
ptr = 0;
}
}
2. Build hbide as hbmk2 hbide.hbp -hbnocppmm
3. Then follow the tracelog.
Hopefully you will understand how delete() is called.
You will also be surprised to know that new() is always called
but delete() is only called for non-QObject derived objects,
and that too are missing sometimes.
I just found but not completely understood these two links:
http://silmor.de/33
http://search.cpan.org/~awin/PerlQt-2.105/doc/starting.pod#Object_destruction
First link I studied at when we started this project.
It gave me wider insight into the subject, though today
I got one more tip: destroyed() signal. I will check how
it can be exploited, though, the same functionality
is achieved with p-pq already.
2nd link I never read but it has little for us.
BTW as many links about Qt destruction mechanism state
the complexity of approach trolltech adopted in this regard.
Every binding is in trouble.
-
enjoy hbIDEing...
Pritpal Bedi
http://hbide.vouch.info/
--
View this message in context:
http://n2.nabble.com/Improve-on-hbqt-object-handling-tp4887521p4887858.html
Sent from the harbour-devel 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-users] hb_arrayNew consultation
Hello, I need your help: When I create an array in C: pArray = hb_itemNew (NULL); hb_arrayNew (pArray, size); before the program ends I have necessarily to call: hb_itemRelease (pArray); to free the memory allocated? or HARBOUR releases automatically? thank you very much, Claudio Soto sr...@adinet.com.uy ___ Harbour-users mailing list (attachment size limit: 40KB) Harbour-users@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour-users
