[Harbour] hbide Unrecoverable error 6005: Exception SIGSEGV on exit

[marco bra]

Hi Pritpal, on Ubuntu 9.10 32bit hbide when i exit from hbide i get this
error:

idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS  xbeP_Close
QMainWindow::saveState(): 'objectName' not set for QToolBar 0x8d8fcc8 ''
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS  xbeP_Close after:
hbide_saveINI( Self )
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS  xbeP_Close after:
::oSM:closeAllSources()
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS
==
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS Before::oDlg:destroy()
 0  0
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS

idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS ,,
 IdeEnvironments:destroy()  0
Object::disconnect: No such signal QTableWidget::itemDoubleClicked(
QTableWidgetItem *, int ) in ../../../hbqt_hbslots.cpp:286
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS101
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS102
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS103
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS101
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS102
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS103
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS101
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS102
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS103
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS <<
   XbpDialog:destroyB  >>
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS101
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS102
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS103
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS <<
   XbpDialog:destroyE  >>
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS

idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS After ::oDlg:destroy()
 0  0
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS
==
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS EXITING after destroy 
 0  0
xbpgeneric.prg:0:HBXBP_END$(): HB_TR_ALWAYS
... EXIT PROCEDURE hbxbp_End()begin
xbpgeneric.prg:0:HBXBP_END$(): HB_TR_ALWAYS
... EXIT PROCEDURE hbxbp_End()end

Unrecoverable error 6005: Exception SIGSEGV at address 0x8

Thank you and best regards

-- 
Linux Infinite Freedom
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbide Unrecoverable error 6005: Exception SIGSEGV on exit

[Pritpal Bedi]

Hi Marco

This log has two entries of primary interest for me:

1. QMainWindow::saveState(): 'objectName' not set for QToolBar 0x8d8fcc8 ''
2. Object::disconnect: No such signal QTableWidget::itemDoubleClicked(
QTableWidgetItem *, int ) in ../../../hbqt_hbslots.cpp:286

1st one I know and have fixed.
2nd one is strange. This slot is always fired and is connected.
Why this entry is in the changelog ? Is Qt also dumb some debug info ?

Above both entries are from Qt's internals, rest all are executed from
hbIDE.

Though I do not know the cause, but may be 1st one has some connection to
it.
Thanks for the feedback.




-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis_&_design_
-- 
View this message in context: 
http://n2.nabble.com/hbide-Unrecoverable-error-6005-Exception-SIGSEGV-on-exit-tp4735569p4735682.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:[14168] trunk/harbour

[vszakats]

Revision: 14168
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14168&view=rev
Author:   vszakats
Date: 2010-03-15 09:00:55 + (Mon, 15 Mar 2010)

Log Message:
---
2010-03-15 09:58 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbct/ctnet.c
  * contrib/hbtpathy/tpwin.c
  * contrib/hbnf/getenvrn.c
! Fixed to disable some functionality on all WinCE platforms.
  These were WinCE API functions wrongly declared in
  mingwarm/poccarm headers. (thus causing link-time errors
  for final apps trying to use these functions)

  * contrib/hbwin/win_dlg.c
! Enabled more functionality for WinCE. mingwarm builds
  will probably crash due to buggy commdlg.h header.

  * src/vm/fm.c
! Fixed to redefine ABORT for all wce/msvcarm targets.

  * utils/hbmk2/hbmk2.prg
! Minor typo in recently added help item.

  * contrib/gtwvg/gtwvg.h
  * contrib/gtwvg/wvggui.h
  * contrib/hbwin/win_prn1.c
  * contrib/hbwin/win_prn2.c
  * contrib/hbwin/win_prn3.c
  * contrib/hbwin/win_dlg.c
  * contrib/hbodbc/odbc.c
  * contrib/rddsql/sddodbc/sddodbc.c
! Fixed to compile with -DWIN32_LEAN_AND_MEAN.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/gtwvg/gtwvg.h
trunk/harbour/contrib/gtwvg/wvggui.h
trunk/harbour/contrib/hbct/ctnet.c
trunk/harbour/contrib/hbnf/getenvrn.c
trunk/harbour/contrib/hbodbc/odbc.c
trunk/harbour/contrib/hbtpathy/tpwin.c
trunk/harbour/contrib/hbwin/win_dlg.c
trunk/harbour/contrib/hbwin/win_prn1.c
trunk/harbour/contrib/hbwin/win_prn2.c
trunk/harbour/contrib/hbwin/win_prn3.c
trunk/harbour/contrib/rddsql/sddodbc/sddodbc.c
trunk/harbour/src/vm/fm.c
trunk/harbour/utils/hbmk2/hbmk2.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: hbide Unrecoverable error 6005: Exception SIGSEGV on exit

[marco bra]

2010/3/15 Pritpal Bedi 

>
> Hi Marco
>
> This log has two entries of primary interest for me:
>
> 1. QMainWindow::saveState(): 'objectName' not set for QToolBar 0x8d8fcc8 ''
> 2. Object::disconnect: No such signal QTableWidget::itemDoubleClicked(
> QTableWidgetItem *, int ) in ../../../hbqt_hbslots.cpp:286
>
> 1st one I know and have fixed.
> 2nd one is strange. This slot is always fired and is connected.
> Why this entry is in the changelog ? Is Qt also dumb some debug info ?
>
>
I don't know why but i get this on Linux Ubuntu 9.10 32 bits with the
installed qt related packages that i send you in attach (might be
incomplete):

And there no dbg package installed on this Ubuntu pc.

Hope this helps
ii  libattica0 0.1.2-0ubuntu2~karmic1~ppa1  
  a Qt library that implements the Open Collab
ii  libdbusmenu-qt10.2.2-0ubuntu2~karmic1~ppa1  
  a Qt library that implements the DBusMenu sp
ii  libkexiv2-8
4:4.4.1-0ubuntu1~karmic1~ppa1  Qt like interface for 
the libexiv2 library (
ii  libodbcinstq1c22.2.11-16ubuntu1 
  Qt-based ODBC configuration library
ii  libphonon-dev  
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 Phonon library 
development files
ii  libphonon4 
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 Phonon module
ii  libpolkit-qt0  0.9.3-0ubuntu1~karmic1~ppa1  
  PolicyKit-qt library
ii  libqca22.0.2-1ubuntu1   
  libraries for the Qt Cryptographic Architect
ii  libqt3-compat-headers  3:3.3.8-b-5ubuntu3   
  Qt 1.x and 2.x compatibility includes
ii  libqt3-headers 3:3.3.8-b-5ubuntu3   
  Qt3 header files
ii  libqt3-mt  3:3.3.8-b-5ubuntu3   
  Qt GUI Library (Threaded runtime version), V
ii  libqt3-mt-dev  3:3.3.8-b-5ubuntu3   
  Qt development files (Threaded)
ii  libqt4-assistant   
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 assistant module
ii  libqt4-dbus
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 D-Bus module
ii  libqt4-designer
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 designer module
ii  libqt4-dev 
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 development files
ii  libqt4-gui 
4:4.6.2-0ubuntu1~karmic1~ppa2  transitional package for 
Qt 4 GUI runtime li
ii  libqt4-help
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 help module
ii  libqt4-multimedia  
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 Multimedia module
ii  libqt4-network 
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 network module
ii  libqt4-opengl  
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 OpenGL module
ii  libqt4-opengl-dev  
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 OpenGL library 
development files
ii  libqt4-phonon  
4:4.6.2-0ubuntu1~karmic1~ppa2  transitional package for 
Qt 4 Phonon librari
ii  libqt4-phonon-dev  
4:4.6.2-0ubuntu1~karmic1~ppa2  transitional package for 
Qt 4 Phonon librari
ii  libqt4-qt3support  
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 3 compatibility 
library for Qt 4
ii  libqt4-script  
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 script module
ii  libqt4-scripttools 
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 script tools module
ii  libqt4-sql 
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 SQL module
ii  libqt4-sql-mysql   
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 MySQL database 
driver
ii  libqt4-sql-sqlite  
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 SQLite 3 database 
driver
ii  libqt4-svg 
4:4.6.2-0ubuntu1~karmic1~ppa2  Qt 4 SVG module
ii  libqt4-test   

Re: [Harbour] Re: hbide Unrecoverable error 6005: Exception SIGSEGV on exit

[Bruno Luciani]

I confirm the same problem here , same scenario ubuntu 9.10 32 bits

Bruno

br...@notebook:~/harbour-project/harbour/contrib/hbide$ ./hbide
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS NIL
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockProjectTree", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockEditorTabs", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockFuncList", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget "dockHelp",
which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockSkeleton", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockFindInFiles", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockThemes", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockProperties", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockEnvironments", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockCompileResults", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockLinkResults", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockOutputResults", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockDocViewer", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockFunctions", which already has a layout
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS  xbeP_Close
QMainWindow::saveState(): 'objectName' not set for QToolBar 0xa0d0f98 ''
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS  xbeP_Close after:
hbide_saveINI( Self )
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS  xbeP_Close after:
::oSM:closeAllSources()
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS
==
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS Before
::oDlg:destroy()  0  0
idemisc.prg:923:HBIDE_DBG():
HB_TR_ALWAYS
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS ,,
IdeEnvironments:destroy()  0
Object::disconnect: No such signal QTableWidget::itemDoubleClicked(
QTableWidgetItem *, int ) in ../../../hbqt_hbslots.cpp:283
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS101
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS102
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS103
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS101
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS102
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS103
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS101
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS102
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS103
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS
<>
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS101
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS102
THbQtUI.prg:0:HBQ_DBG(): HB_TR_ALWAYS103
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS
<>
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
xbpdialog.prg:0:XBPDIALOG:DESTROY(): HB_TR_ALWAYS .
idemisc.prg:923:HBIDE_DBG():
HB_TR_ALWAYS
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS After
::oDlg:destroy()  0  0
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS
==
idemisc.prg:923:HBIDE_DBG(): HB_TR_ALWAYS EXITING after destroy
  0  0
xbpgeneric.prg:0:HBXBP_END$(): HB_TR_ALWAYS
... EXIT PROCEDURE hbxbp_End()begin
xbpgeneric.prg:0:HBXBP_END$(): HB_TR_ALWAYS
... EXIT PROCEDURE hbxbp_End()end
QApplication.cpp:115: HB_TR_ALWAYS hbqt_exit 0 0x9d267d8
QApplication.cpp:120: HB_TR_ALWAYS hbqt_exit 1 (nil)

Unrecoverable error 6005: Exception SIGSEGV at address 0x8
br...@notebook:~/harbour-project/harbour/contrib/hbide$
___
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:[14169] trunk/harbour

[druzus]

Revision: 14169
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14169&view=rev
Author:   druzus
Date: 2010-03-15 11:32:16 + (Mon, 15 Mar 2010)

Log Message:
---
2010-03-15 12:32 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/include/hbstack.h
* minor cleanup

  * harbour/external/bzip2/bzip2.c
! fixed to compile on platforms which do not accept "\" as path delimiter

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/external/bzip2/bzip2.c
trunk/harbour/include/hbstack.h


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] IE9104

[Mindaugas Kavaliauskas]

Hi,


the following sample generates IE9104:
===
PROC MAIN()
  DBCREATE("bandom.dbf", {{"NR", "N", 8, 0}, {"TEXT", "C", 8, 0}, 
{"TEXT2", "C", 4, 0}}, "DBFCDX")

  DbUseArea(.T., "DBFCDX", "bandom.dbf", "pirma", .T., .F.)
  OrdCreate("bandom.cdx", "pirmas", "STR(NR)+TEXT")
  OrdCreate("antras.cdx", "antras", "TEXT")
  DBCLOSEALL()
  DbUseArea(.T., "DBFCDX", "bandom.dbf", "pirma", .T., .F.)
  OrdListAdd("antras.cdx")
  OrdSetFocus("pirmas")
  OrdCondSet(,, RecNo() .T.,,, .T.,,)
  OrdCreate("antras.cdx", "a102", "TEXT2")  // IE9104
  DBCLOSEALL()
RETURN
===
Unrecoverable error 9104: hb_cdxIndexFree: index file still locked.
Called from ORDCREATE(0)
Called from MAIN(11) in pcode.hrb
Called from HB_HRBRUN(0)
Called from _APPMAIN(0) in ../../../hbrun.prg


Regards,
Mindaugas

___
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:[14170] trunk/harbour

[druzus]

Revision: 14170
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14170&view=rev
Author:   druzus
Date: 2010-03-15 13:04:33 + (Mon, 15 Mar 2010)

Log Message:
---
2010-03-15 14:04 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/src/rdd/dbfcdx/dbfcdx1.c
! fixed bad copy and past typo which could cause internal error when
  new index using existing order (subindex) was created without ADDITIVE
  clause. Bug reported by Mindaugas - many thanks for the information.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Mindaugas Kavaliauskas]

Hi,



  * harbour/src/rdd/dbfcdx/dbfcdx1.c
! fixed bad copy and past typo which could cause internal error when
  new index using existing order (subindex) was created without ADDITIVE
  clause. Bug reported by Mindaugas - many thanks for the information.


Thanks! Actually, you've found a bug in our code :) We've forgot to set 
lAdditive = .T. :)



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: About ADEL()

[pete_westg]

στις 13/03/2010 12:52, O/H Viktor Szakáts έγραψε:



And here you answered the question. ADEL() is a Clipper
compatibility function, so it's expected to behave exactly
the same way as in Clipper, regardless of what we think
about some of that behavior.


Hi Viktor,
Thanks you for your reply. I don't like to be pedantic but,
as I understand it, the term "compatibility" is the case where the 
compatible object keeps the same *documented* behavior and produce the 
same *expected* results like the original. Preserving or rather 
"cloning" undocumented questionable/problematic "features", just for the 
sake of compatibility, is a bit surrealistic, which is ok on a 
philosophical/aesthetic level but from a pure programming view,

perhaps needs more consideration.

I agree that adel() does some kind of delete in the meaning that deletes 
the contents of an element but not the element itself, however, let me 
just to point out that in the case of a multidimensional array this 
"delete" translates to "make it broken".
Anyway, enough with ADEL(). The question is if we can do something with 
HB_ADEL(). I don't know if it is proper to propose now modifications but 
here it is:

---
HB_ADEL(aArray, []) --> mismatch argument RTE
HB_ADEL(aArray, []) --> boundary RTE
HB_ADEL(aArray)  -->  {} // an empty array, equal to aArray := {}

--

Of course all of the above could be easily implemented locally,
in prg or preprocessor level, but since i have faced the problem
in a real code situation, I thought that it might be useful
to notify my experience here.
Please, (and i hope i don't peculate your time) consider the code:
-
// IF nFile := ascan(a, {|x| UPPER(x[F_NAME]) == "HBDIR.EXE"}) > 0
IF ( nFile := HB_ASCAN( a, {|x| UPPER(x[F_NAME]) == "HBDIR.EXE"},,,.T. ) 
) > 0

HB_Adel(a, nFile, .t. )
ENDIF
-
It took me some time to realize what was wrong (in the now commented 
line above). The problem, as you can easily see, was the (unforgivable) 
lack of parentheses that had as result nFile var to take a boolean value 
(.T. in the particular case), which subsequently was giving to HB_ADEL() 
the "freedom" to do its magic by deleting  the first array element 
instead of  "HBDIR.EXE" element. Of course I would have saved  my time 
(and my nerves) if HB_ADEL() had, from the very first run, warned me 
about the erroneous type value of nFile.


best regards,

---
Pete

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] MT statics vs public

[Mindaugas Kavaliauskas]

Hi,


Lorenzo Fiorini wrote:

I've successfully implemented MT in my httpserver and the results are
great, but http apps are made to be ( almost ) stateless while desktop
apps are full of vars that remember selections, global and user
setting, preferences and so on.

Following the CL5 guidelines I've heavily used module wide static vars
and set/get functions to access them but in a MT statics are difficult
to share so the idea is to use a "big" public hash as a "session
holder" where every static become a key with a value and share it
between threads.

What do you think?
Do you see other paths?


Unfortunately, HTTP is stateless and session key stored in cookie is the 
key to solve a problem (still not very comfortable...).


Here I see the main difference between web application and GUI remote 
application.



Pritpal Bedi wrote:

Static variable as declared as STATIC are shared among threads.
Static variables declared as THREAD STATIC have thread wide scope.


Static thread variables helps only in case you bind a thread to a 
session. It also solves the problem of reopening aliases, etc. It was 
implemented in my uhttpd, but late I dropped such thread-session binding 
because of bad "thread reusage" and uncommon application architecture. 
It's very easy to make 1000 or much more open http sessions (imagine 20 
minutes session timeout) and waste all system resources.



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: SqlMix and dbcreated

[Mindaugas Kavaliauskas]

Hi,


Shum wrote:

It possible to implement the database connection number as a class ...
like the DacSession class in Xbase++ ...??


I know nothing about DacSession, but I guess it could be implemented on 
the top of current code.



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: About ADEL()

[Viktor Szakáts]

Hi,

>> And here you answered the question. ADEL() is a Clipper
>> compatibility function, so it's expected to behave exactly
>> the same way as in Clipper, regardless of what we think
>> about some of that behavior.
>> 
> Hi Viktor,
> Thanks you for your reply. I don't like to be pedantic but,
> as I understand it, the term "compatibility" is the case where the compatible 
> object keeps the same *documented* behavior and produce the same *expected* 
> results like the original. Preserving or rather "cloning" undocumented 
> questionable/problematic "features", just for the sake of compatibility, is a 
> bit surrealistic, which is ok on a philosophical/aesthetic level but from a 
> pure programming view,
> perhaps needs more consideration.

As a rule in Harbour we chose to "clone" original Clipper 
behavior, unless it's clear bug or MS-DOS specific 
portability issue. In case of ADEL() and lots of other 
original Clipper functions, many aspects of behavior can be 
questioned, disputed, and surely it could be made better, 
but there are two problems: 1) these areas are very subjective
2) It breaks Clipper compatibility. We value compatibility 
the most in Harbour, as this is the only way to ensure that 
code written for Clipper will also work with Harbour. So 
we don't touch, modify or extend basic features as a ground 
rule.

> I agree that adel() does some kind of delete in the meaning that deletes the 
> contents of an element but not the element itself, however, let me just to 
> point out that in the case of a multidimensional array this "delete" 
> translates to "make it broken".
> Anyway, enough with ADEL(). The question is if we can do something with 
> HB_ADEL(). I don't know if it is proper to propose now modifications but here 
> it is:
> ---
> HB_ADEL(aArray, []) --> mismatch argument RTE
> HB_ADEL(aArray, []) --> boundary RTE
> HB_ADEL(aArray)  -->  {} // an empty array, equal to aArray := {}

In case of HB_ADEL() the only real constraint is 
to stay compatible with previous Harbour versions.

What you say can be technically implemented, I'd only 
argue with HB_ADEL()->{}, which is a synonym to 
ASIZE(,0), so IMO unnecessary and better to raise RTE.

> --
> 
> Of course all of the above could be easily implemented locally,
> in prg or preprocessor level, but since i have faced the problem
> in a real code situation, I thought that it might be useful
> to notify my experience here.
> Please, (and i hope i don't peculate your time) consider the code:
> -
> // IF nFile := ascan(a, {|x| UPPER(x[F_NAME]) == "HBDIR.EXE"}) > 0
> IF ( nFile := HB_ASCAN( a, {|x| UPPER(x[F_NAME]) == "HBDIR.EXE"},,,.T. ) ) > 0
>   HB_Adel(a, nFile, .t. )
> ENDIF
> -
> It took me some time to realize what was wrong (in the now commented line 
> above). The problem, as you can easily see, was the (unforgivable) lack of 
> parentheses that had as result nFile var to take a boolean value (.T. in the 
> particular case), which subsequently was giving to HB_ADEL() the "freedom" to 
> do its magic by deleting  the first array element instead of  "HBDIR.EXE" 
> element. Of course I would have saved  my time (and my nerves) if HB_ADEL() 
> had, from the very first run, warned me about the erroneous type value of 
> nFile.

Of course, but note that the best solution for most of similar 
problems is strongly typed parameter checking. Without it, 
even if we modify HB_ADEL() there will remain thousands of 
other such places for similar typos, so we're not really 
solving the real problem here IMO.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: MT workareas cloning

[Mindaugas Kavaliauskas]

Hi,


Support for ZEROSPACE in WorkSpaceList() is trivial but can be implemented 
only in C. I can add it in necessary. BTW please check above two example 
with xbase++. 



Would you please implement the WorkSpaceList() with ZEROSPACE  ...
I need to obtain all alias within ZEROSPACE 

Or any way to get a list of all alias within the ZeroSpace ???


I have a related question/problem. Let's say I want to transfer areas 
among threads (that's the purpose of alias detaching). I'm missing two 
functions:

1) to attach alias within another thread using a different alias name;
2) to search a "zerospace" for a specific area having some dbf file, 
some open mode, index, etc.


These missing functionality could be reached by function which renames 
current alias. F.e.:


  USE items NEW ORDER number READONLY ALIAS items1
  
  HB_DBSETALIAS("items_number_RO")
  HB_DBDETACH()

Another thread:
  HB_DBREQUEST("items_number_RO",,, .T.)
  HB_DBSETALIAS("items_ro")
  ...

This could be a waste dynsym table if I want add a random HTTP session 
number to a database name before detaching it (let's say I want to cache 
opened tables for HTTP session). It this case I find a useful solution 
to store a required (for reattaching) data in cargo field. F.e.:


  USE items NEW ORDER number READONLY ALIAS items1
  
  HB_DBDETACH(, "items_" + cSession)

Another thread:
  HB_DBREQUEST({|alias,cargo| IIF(cargo == "items_" + cSession, (alias 
:= "items_ro", .T.), .F.)},,, .T.)

  ...
  /* Here block is a kind of search block. It also assigns a new alias 
name */


The second proposed solution is more flexible, but is not optimal 
because it keeps a long mutex lock on "zerospace" internals.



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: SqlMix and dbcreated

[Massimo Belgrano]

Imo must be extended rdd structure

Follow my link
http://www.masfoxpro.com/index.php?title=XBase&printable=yes



PROCEDURE Main
 LOCAL cConnect := "DBE=ODBCDBE;DSN=OrderProcessing"
 LOCAL oSession := DacSession():new( cConnect )
 IF .NOT. oSession:isConnected()
 ? "Unable to connect to server !"
 ? oSession:getLastMessage()
 QUIT
 ENDIF

   < Business Logic As Usual >
 DbCloseAll()

 oSession:disconnect()
 RETURN


Procedure main
XDBQ:=CURDRIVE()+":\"+CURDIR()+"\"+STRTRAN(G_CAMINO,"\","")
cCon := "DBE=ODBCDBE;DRIVER={Microsoft dBase Driver
(*.dbf)};DBQ="+XDBQ+";DATABASE="+XDBQ
oSessionDBF:=DacSession():new(cCon)
oSessionDBF:setProperty(ODBCSSN_INDEX_AUTOOPEN, .T.)
IF !oSessionDBF:isconnected()
MSGBOX( "Unable to connect..." )
QUIT
ENDIF
DbeSetDefault( "ODBCDBE" )

SQL("CREATE INDEX TIPOS ON TIPOS(TIPO_COMP)")
USE TIPOS NEW
MSGBOX(INDEXKEY()) // Result= TIPO_COMP

* DBGOBOTTOM() //If this line is not commented, it works OK!

IF DBSEEK("EG")
MSGBOX("Found!")
ELSE
MSGBOX("Not found")
ENDIF
RETURN

Function tr_open()
 LOCAL oSession
 DbeSetDefault("ADSDBE")
 cConnStr :=
"SERVER=\\testweb.dnsalias.com:3232\test\data\test.ADD;ADS_REMOTE_SERVER;ADS_COMPRESS_INTERNET;UID=test;PWD=test"
 oSession:= DacSession():New("DBE=ADSDBE;"+cConnStr)
  DbeInfo( COMPONENT_DATA , ADSDBE_TBL_MODE, ADSDBE_CDX )
  DbeInfo( COMPONENT_ORDER, ADSDBE_TBL_MODE, ADSDBE_CDX )
 If (oSession:isConnected())
 If !DbUseArea(.T.,oSession, "adress","wadress",.t.,.t.)
 MsgBox("Status:"+Alias()+" kann nicht geöffnet werden")
 EndIf
 Set Index to Adress
 trconnect:=.t.
 Else
 trconnect:=.f.
 MsgBox("Status:"+Alias()+" kann nicht geöffnet werden")
 EndIf



2010/3/15 Mindaugas Kavaliauskas :
> Hi,
>
>
> Shum wrote:
>>
>> It possible to implement the database connection number as a class ...
>> like the DacSession class in Xbase++ ...??
>
> I know nothing about DacSession, but I guess it could be implemented on the
> top of current code.
>
>
> Regards,
> Mindaugas



-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Mindaugas Kavaliauskas]

Hi,



../../../sddfb.c: In function ‘fbDisconnect’:
../../../sddfb.c:181:4: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
../../../sddfb.c: In function ‘fbOpen’:
../../../sddfb.c:209:4: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
../../../sddfb.c:219:4: warning: dereferencing type-punned pointer will break 
strict-aliasing rules

This is also danger casting though it should work if void * is large enough
to hold FB handlers. Anyhow it's potential problem so it should be fixed.


I've added protection for this, see line 100, but I'm going to fix this 
(and other similar issues) in the nearest future.



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Error in SDDFB

[Mindaugas Kavaliauskas]

Hi,


Luis R. Stach wrote:

Error SDDFB/1903 Prepare statement failed: SELECT * FROM agenda (DOS Error 
335544569)
What I do is this:

ANNOUNCE RDDSYS
REQUEST SQLMIX, SDDFB
RDDSETDEFAULT( "SQLMIX" )

hConn := RDDINFO( RDDI_CONNECT, { "FIREBIRD",, "SYSDBA", "masterkey", 
"192.168.0.1:d:\data\agenda.fdb" } )
MsgInfo( hConn )  //Return 1
DBUSEAREA( .T.,, "SELECT * FROM agenda" ) //Line error

I use Firebird 2.1.3.18185
Someone can help me


I was offline for some time, but I'm going to check this issue together 
with other RDDSQL fixes in the nearest future (perhaps end of this week).



Regards,
Mindaugas
___
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:[14171] trunk/harbour

[vszakats]

Revision: 14171
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14171&view=rev
Author:   vszakats
Date: 2010-03-15 15:50:00 + (Mon, 15 Mar 2010)

Log Message:
---
2010-03-15 16:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  + external/bzip2/bzip2.dif
+ Added .dif file.

Modified Paths:
--
trunk/harbour/ChangeLog

Added Paths:
---
trunk/harbour/external/bzip2/bzip2.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[2]: [Harbour] Error in SDDFB

[Luis R. Stach]

Thanks Mindaugas

 
Saludos,
Luis R. Stach


Monday, March 15, 2010, 12:42:06 PM, you wrote:

> Hi,

> I was offline for some time, but I'm going to check this issue together
> with other RDDSQL fixes in the nearest future (perhaps end of this week).


> Regards,
> Mindaugas
> ___
> 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] MT statics vs public

[Lorenzo Fiorini]

On Mon, Mar 15, 2010 at 3:47 PM, Mindaugas Kavaliauskas
 wrote:

> Unfortunately, HTTP is stateless and session key stored in cookie is the key
> to solve a problem (still not very comfortable...).
>
> Here I see the main difference between web application and GUI remote
> application.

Thanks for your comment.

I'm trying to follow the J2EE blueprints to "repaint" the apps around
public objects like Application, Session, Page and Request but keeping
the GT code working.

It seems to me that using a single public object ( that has a single
hash to hold all the data ) for Application and Session greatly helps
to control the data that can be easily cleaned, saved/restored,
inspected.

So a function can be inside a dynamically loaded HRB or in a DLL and
still easily access oApplication, oSession.

best regards,
Lorenzo
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] proposal: HB_PATH_MAX estension

[Przemysław Czerpak]

On Sun, 14 Mar 2010, Szak�ts Viktor wrote:

Hi,

> The macro responsible to set maximum filename/path 
> length in Harbour (HB_PATH_MAX) is now set to 264.
> Modern systems can handle much more as maximum path 
> length (f.e. Windows 32K chars).

AFAIR the longer paths are not for FS but for host name
in UNC notation though some FS can use much bigger values
then OS.

> Shouldn't we extend this Harbour constant to handle 
> more?
> There are few issues to take care of:
> - This macro is used for both filename and pathname 
>   max length in Harbour, maybe we should have two values 
>   to fix that.

It will introduce unnecessary problems in path modifications
and it's not clear what does it mean and how to adopt it to
different FS limitations.
Current meaning is correct. This is the maximum size of complete
path. It doesn't matter it's single file in root directory or
series of directories. Important is only total size.

> - Set this constant to different values depending on 
>   platform.

Potentially it's new problem for code which have to exchange
data between different Harbour builds.

> - Many times the buffer is allocated on stack, we 
>   may need to revise whether using larger buffers here 
>   has any bad side-effect.

If you plan to enlarge this value to 32KB then it will be
necessary to remove all such places and define that it's
illegal to use it directly or indirectly by some other
structures like HB_FNAME in C stack variables. For core
code it can be done (though with the cost of speed in some
cases) but it's potentially serious problem for 3-rd party
code. We will probably have to change current code and
hide HB_FNAME internals so user can use it on HVM stack.

Changing the value of HB_PATH_MAX breaks binary compatibility
with existing code so I do not think it's good idea to touch
without some serious reasons, i.e. real problems in some FS.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: MT workareas cloning

[Przemysław Czerpak]

On Mon, 15 Mar 2010, Mindaugas Kavaliauskas wrote:

Hi,

> I have a related question/problem. Let's say I want to transfer
> areas among threads (that's the purpose of alias detaching). I'm
> missing two functions:
> 1) to attach alias within another thread using a different alias name;
> 2) to search a "zerospace" for a specific area having some dbf file,
> some open mode, index, etc.
> These missing functionality could be reached by function which
> renames current alias. F.e.:
>   USE items NEW ORDER number READONLY ALIAS items1
>   
>   HB_DBSETALIAS("items_number_RO")
>   HB_DBDETACH()
> 
> Another thread:
>   HB_DBREQUEST("items_number_RO",,, .T.)
>   HB_DBSETALIAS("items_ro")
>   ...
> This could be a waste dynsym table if I want add a random HTTP
> session number to a database name before detaching it (let's say I
> want to cache opened tables for HTTP session). It this case I find a
> useful solution to store a required (for reattaching) data in cargo
> field. F.e.:
>   USE items NEW ORDER number READONLY ALIAS items1
>   
>   HB_DBDETACH(, "items_" + cSession)
> Another thread:
>   HB_DBREQUEST({|alias,cargo| IIF(cargo == "items_" + cSession,
> (alias := "items_ro", .T.), .F.)},,, .T.)
>   ...
>   /* Here block is a kind of search block. It also assigns a new
> alias name */
> The second proposed solution is more flexible, but is not optimal
> because it keeps a long mutex lock on "zerospace" internals.

Just like WorkaAreaEval() in xbase++ and it's the reason why I still
haven't added it to SVN code.


There is one very serious problem with alias name modification and
switching workareas between threads. It hardly interacts with RDDs
using remote servers which allows to optimize expressions and execute
them on the server side. It causes that it's necessary to replicate
on the server side all local alias modifications what can seriously
reduce the performance.
Anyhow current code which tries to follow xbase++ specification
replicated also some xbase++ anomalies (fortunately not all) so it
has to be cleaned and I plan to make.
Your propositions are very interesting but before I'll change anything
in this code I will want to rethink all interactions with RDDs using
remote servers.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Massimo Belgrano]

Different order of c compiler for xharbour  by xailer
http://xailer.info/esp/?p=179

Embarcadero is working to 64 bit borland c++
http://edn.embarcadero.com/article/39174


2010/3/9 Maurilio Longo :
> Hi,
>
> which is the harbour recommended C compiler for the windows platform?
>
> best regards.
>
> --
>  __
> |  |  | |__| Maurilio Longo
> |_|_|_|| farmaconsult s.r.l.
>
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

> Different order of c compiler for xharbour  by xailer
> http://xailer.info/esp/?p=179

It's not that much different, only that they seem to 
rank Pelles C higher than us.

Pelles C is good in features, easy to use, but it's 
full of serious bugs (and nobody's bug reports 
were answered since last years August, apparently 
because the author doesn't seem to be around since 
then), and the code generated is among the slowest. 
It's more of less equivalent to BCC in this regard.

So for users concerned about execution speed and 
reliability the position between MinGW and MSVC 
is very much overstated.

The rest of the rank is okay. I'd only leave 
LCC and DMC off of it, since they are pretty much 
(or completely) dead products.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] proposal: HB_PATH_MAX estension

[Viktor Szakáts]

Hi Przemek,

>> The macro responsible to set maximum filename/path 
>> length in Harbour (HB_PATH_MAX) is now set to 264.
>> Modern systems can handle much more as maximum path 
>> length (f.e. Windows 32K chars).
> 
> AFAIR the longer paths are not for FS but for host name
> in UNC notation though some FS can use much bigger values
> then OS.

Yes.

>> Shouldn't we extend this Harbour constant to handle 
>> more?
>> There are few issues to take care of:
>> - This macro is used for both filename and pathname 
>>  max length in Harbour, maybe we should have two values 
>>  to fix that.
> 
> It will introduce unnecessary problems in path modifications
> and it's not clear what does it mean and how to adopt it to
> different FS limitations.
> Current meaning is correct. This is the maximum size of complete
> path. It doesn't matter it's single file in root directory or
> series of directories. Important is only total size.

F.e. on windows there is separate a limit for filename 
path component. I didn't make tests yet, anyhow worst 
case Windows API would generate errors when passed 
too long name, so I guess it alright for Harbour.

>> - Set this constant to different values depending on 
>>  platform.
> 
> Potentially it's new problem for code which have to exchange
> data between different Harbour builds.
> 
>> - Many times the buffer is allocated on stack, we 
>>  may need to revise whether using larger buffers here 
>>  has any bad side-effect.
> 
> If you plan to enlarge this value to 32KB then it will be
> necessary to remove all such places and define that it's
> illegal to use it directly or indirectly by some other
> structures like HB_FNAME in C stack variables. For core
> code it can be done (though with the cost of speed in some
> cases) but it's potentially serious problem for 3-rd party
> code. We will probably have to change current code and
> hide HB_FNAME internals so user can use it on HVM stack.

Okay.

Binary compatibility is only a concern for minor revisions, 
so in this case it's no showstopper for us. pcode set  
was already updated, so even .prg code is not compatible 
in 2.1.

It seems a viable path to first update current structures 
and core/contrib coding practices to allow for larger buffers 
without upping the limit itself, and after everything is in 
place, expand HB_PATH_MAX to allow for more.

Since we need to present a limit anyway, at may also be 
a possibility, and an easier one to simple up the limit 
from 262 to 4096 on win/wce/*nix systems. This looks 
still okay to do on stack and would resolve the problem 
for (I believe) 99.999% of users (F.e. Cygwin project 
did exactly that in 1.7 release).

Of course updating the internals to allow for more, is 
a nice thing in both cases, but only a requirement if we 
follow the first method.

What is your opinion on above options?

> Changing the value of HB_PATH_MAX breaks binary compatibility
> with existing code so I do not think it's good idea to touch
> without some serious reasons, i.e. real problems in some FS.

I tested simple code on Ubuntu, and f.e. CURDIR() 
will simply fail when run in deeper than HB_MAX_PATH 
directory structure. It will return empty string.

On Windows many upper level of OS/apps is quite faulty 
in this regard, so they behave strangely, even supplied 
Explorer is confused, so could not even execute apps 
from deeper path. I could run simple HB_FILEEXISTS() 
check and it fails as expected for anything longer than 
262.

Linux test code:
---
PROC MAIN()
   LOCAL a := CURDIR()
   ALERT( HB_NTOS( LEN( a ) ) + " " + a ) // -> '0 ' shown when run from deep 
structure
   RETURN
---

Windows test code:
---
PROC MAIN()
   HB_ALERT( HB_FILEEXISTS( 
"C:\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\g.exe"
 ) ) // -> '.F.' shown, while the file exists
   HB_ALERT( HB_FILEEXISTS( 
"C:\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\g.prg"
 ) ) // -> '.T.'
---

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Przemysław Czerpak]

On Mon, 15 Mar 2010, vszak...@users.sourceforge.net wrote:

Hi,

> ---
> 2010-03-15 16:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
>   + external/bzip2/bzip2.dif
> + Added .dif file.

What about enabling BZIP2 compilation in DOS and OS2 builds?
This code can be compiled as is by DJGPP and this small patch

   --- harbour/external/bzip2/bzip2.c   (wersja 14171)
   +++ harbour/external/bzip2/bzip2.c   (kopia robocza)
   @@ -34,7 +34,8 @@
--*/
#define BZ_LCCWIN32  0

   -#if defined(_WIN32) && !defined(__CYGWIN__)
   +#if ( defined(_WIN32) && !defined(__CYGWIN__) ) || \
   +( defined(__WATCOMC__) && ( defined(__OS2__) || defined(__DOS__) ) )

fixes compilation with OpenWatcom for DOS and OS2.
Probably support for OS2 GCC will also need only such cosmetic
modifications or maybe it even works out of the box.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

> Different order of c compiler for xharbour  by xailer
> http://xailer.info/esp/?p=179

Few more points to make after reading the article in translator:

- They ranked Pelles C the first, but they forgot to 
  measure execution speed.
- In the article they worry about MSVC being abandoned as free 
  product, but in fact the same can happen with Pelles C in 
  one way or another. (ie. it's already abandoned, since it's 
  not updated)
- Harbour users and developers _do_ use mingw, so for us 
  (compared with xhb users) it's not alien.
- As I mentioned here a few times (and as it's documented 
  in INSTALL), MSVC 2008 compiler tools are now included in 
  Windows SDK 7, which means it's easy to use in a compact 
  package for x86 and x64 development.
  I doubt MS would pull it as free tool if they decided to 
  bundle it with SDK and given current trends in OS/compiler 
  business. (though of course nobody can guarantee it, just 
  like for any other non-open source compilers, including 
  Pelles C)

This leaves MinGW and MSVC the leading choices for Harbour. 

[ BTW, the article is from 2009 April, so at that time 
they couldn't predict SDK 7 and the apparent stall in 
Pelles C development. ]

Of course it's always good to have more options, that's 
why we also support watcom, icc, pocc and bcc as well. 
Anyhow for real work these are less suitable at the moment.

As for BCC64, if they make it available without much 
trouble (and it also works properly), we can add support 
for it easily in Harbour.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Viktor Szakáts]

Hi,

>> ---
>> 2010-03-15 16:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
>>  + external/bzip2/bzip2.dif
>>+ Added .dif file.
> 
> What about enabling BZIP2 compilation in DOS and OS2 builds?
> This code can be compiled as is by DJGPP and this small patch
> 
>   --- harbour/external/bzip2/bzip2.c  (wersja 14171)
>   +++ harbour/external/bzip2/bzip2.c  (kopia robocza)
>   @@ -34,7 +34,8 @@
>--*/
>#define BZ_LCCWIN32  0
> 
>   -#if defined(_WIN32) && !defined(__CYGWIN__)
>   +#if ( defined(_WIN32) && !defined(__CYGWIN__) ) || \
>   +( defined(__WATCOMC__) && ( defined(__OS2__) || defined(__DOS__) ) )
> 
> fixes compilation with OpenWatcom for DOS and OS2.
> Probably support for OS2 GCC will also need only such cosmetic
> modifications or maybe it even works out of the box.

All the better. I will make above modifications, but 
it will enable bzip2 also for os2/gcc, so it will fail 
unless necessary patches are added for this target.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[vszakats]

Revision: 14172
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14172&view=rev
Author:   vszakats
Date: 2010-03-15 20:32:35 + (Mon, 15 Mar 2010)

Log Message:
---
2010-03-15 21:31 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * external/bzip2/Makefile
  * external/bzip2/bzip2.dif
  * external/bzip2/bzip2.c
+ Added patch to make it compile on dos and os2/watcom.
  Thanks to Przemek.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/external/bzip2/Makefile
trunk/harbour/external/bzip2/bzip2.c
trunk/harbour/external/bzip2/bzip2.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:[14173] trunk/harbour

[druzus]

Revision: 14173
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14173&view=rev
Author:   druzus
Date: 2010-03-15 20:40:14 + (Mon, 15 Mar 2010)

Log Message:
---
2010-03-15 21:40 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/include/hbthread.h
! added workaround for problems with static __thread variables in
  Open64 C compiler

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/include/hbthread.h


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Przemysław Czerpak]

On Mon, 15 Mar 2010, vszak...@users.sourceforge.net wrote:
> 2010-03-15 21:31 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
>   * external/bzip2/Makefile
>   * external/bzip2/bzip2.dif
>   * external/bzip2/bzip2.c
> + Added patch to make it compile on dos and os2/watcom.
>   Thanks to Przemek.

Thank you very much.

best regards,
Przemek
___
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:[14174] trunk/harbour

[vszakats]

Revision: 14174
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14174&view=rev
Author:   vszakats
Date: 2010-03-15 20:58:45 + (Mon, 15 Mar 2010)

Log Message:
---
2010-03-15 21:54 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * INSTALL
  * external/Makefile
- Deleted "HB_EXTERNALLIBS=no" option. Blindly disabling
  all external libs can break the build process.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/INSTALL
trunk/harbour/external/Makefile


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] Error building libs for Msvc 2008 CE

[José Luis Capel]

Hi all,

I have some errors building libs for msvc 2008 ce.

Using these sets:


call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"

set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\ce\include;C:\Program Files (x86)\Windows Mobile 5.0 SDK
R2\PocketPC\Include\Armv4i;C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\include\
set LIB=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\ce\lib\armv4i;C:\Program Files (x86)\Windows Mobile 5.0 SDK
R2\PocketPC\Lib\ARMV4I
set PATH=e:\programacion_ant\hb_mvsc\bin;C:\Program Files (x86)\Microsoft
Visual Studio 9.0\VC\ce\bin\x86_arm;C:\Program Files (x86)\Microsoft Visual
Studio 8\Common7\IDE;%PATH%

SET HB_INSTALL_PREFIX=e:\programacion_ant\hb_msvcce
SET HB_CONTRIBLIBS=no
SET HB_CONTRIB_ADDONS=no

using:

win-make clean install

I get this:

1 archivo(s) copiado(s).
cl.exe   -I. -I../../../../../include -nologo -D_M_ARM -DARM -D_ARM_ -TC -Od
-Os
 -Gy -EHsc- -DHB_LEGACY_TYPES_OFF  -DUNICODE -DUNDER_CE -D_WIN32_WCE
-Fosqlite3
.obj -c ../../../sqlite3.c
sqlite3.c
lib.exe-nologo -out:../../../../../lib/wce/msvcarm/sqlite3.lib
sqlite3.obj |
| del /q /f ../../../../../lib/wce/msvcarm/sqlite3.lib
1 archivo(s) copiado(s).
! 'bzip2' library skipped (unused)
! 'libhpdf' library skipped (platform or compiler not supported)
cl.exe   -I. -I../../../../../include -nologo -D_M_ARM -DARM -D_ARM_ -TC -Od
-Os
 -Gy -EHsc- -DHB_LEGACY_TYPES_OFF  -DUNICODE -DUNDER_CE
-IE:/Programacion_ant/ha
rbour/external/zlib  -Fopng.obj -c ../../../png.c
png.c
e:\programacion_ant\harbour\external\libpng\pngconf.h(336) : fatal error
C1083:
No se puede abrir el archivo incluir: 'sys/types.h': No such file or
directory
win-make[3]: *** [png.obj] Error 2
win-make[2]: *** [descend] Error 2
win-make[1]: *** [libpng.inst] Error 2
win-make: *** [external.inst] Error 2

Any help is wellcommen.

Regards,
José Luis Capel
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: MT workareas cloning

[Mindaugas Kavaliauskas]

Hi,


Przemysław Czerpak wrote:

The second proposed solution is more flexible, but is not optimal
because it keeps a long mutex lock on "zerospace" internals.


Just like WorkaAreaEval() in xbase++ and it's the reason why I still
haven't added it to SVN code.

There is one very serious problem with alias name modification and
switching workareas between threads. It hardly interacts with RDDs
using remote servers which allows to optimize expressions and execute
them on the server side. It causes that it's necessary to replicate
on the server side all local alias modifications what can seriously
reduce the performance.


If we allow "modification" of alias only on workarea attaching, then we 
just have to treat detach as close, and attach as open. Perhaps this can 
help to simplify remote RDD optimisations, but I do not have a whole 
picture here.




Anyhow current code which tries to follow xbase++ specification
replicated also some xbase++ anomalies (fortunately not all) so it
has to be cleaned and I plan to make.
Your propositions are very interesting but before I'll change anything
in this code I will want to rethink all interactions with RDDs using
remote servers.


I see also some hidden problems, that's why I wanted to make more a 
discussion, than a final "I wish" idea proposal.


The first idea that came to my mind was functions:
   hArea := HB_DBDETACH( [ cAlias | nWorkArea ])
and
   HB_DBATTACH( hArea, [ cAlias ], [ lNewArea ] )

hArea could be any handle to detached workarea, f.e., number, but 
collectible pointer is the best choice in case of Harbour. If hArea is 
not visible for application than area is closed. A simple HB_DBDETACH() 
call without using return value is equivalent to DBCLOSEAREA(). This 
hArea can be stored in array together with corresponding alias, 
filename, index, open mode, or whatever data, and later simple ASCAN() 
can be used to get alias from "zerospace". hArea can also be notified to 
some mutex queue and this is equivalent to fWait flag in current 
DBREQUEST().


But these two HB_DBDETACH()/HB_DBATTACH() has very different logic from 
current xBase++ implementation, so, I did not proposed this. On the 
other hand I feel we should use the solution that fits our ideas the 
best and is enough flexible to build another logic on the top of it. F.e.:


STATIC saZeroSpace := {}
STATIC shMutex := HB_MUTEXCREATE()

FUNC DBDETACH( cAlias, xCargo )
  LOCAL hArea
  IF EMPTY(cAlias);  cAlias := ALIAS()
  ENDIF
  hArea := HB_DBDETACH(cAlias)
  IF EMPTY(hArea);  RETURN .F.
  ENDIF
  HB_MUTEXLOCK(shMutex)
  AADD(saZeroSpace, {hArea, cAlias, xCargo})
  HB_MUTEXNOTIFYALL(shMutex)
  HB_MUTEXUNLOCK(shMutex)
RETURN .T.

FUNC DBREQUEST( cAlias, lFreeArea, xCargo, lWait )
  LOCAL nI, lRet := .F.
  HB_MUTEXLOCK(shMutex)
  DO WHILE .T.
IF (nI := ASCAN(saZeroSpace, {|X| X[2] == cAlias})) > 0
  HB_DBATTACH(saZeroSpace[nI, 1], saZeroSpace[nI, 2], lFreeArea)
  xCargo := saZeroSpace[nI, 3]
  ADEL(saZeroSpace, nI)
  ASIZE(saZeroSpace, LEN(saZeroSpace) - 1)
  lRet := .T.
  EXIT
ENDIF
IF ! EMPTY(lWait)
  HB_MUTEXSUBSCRIBE(shMutex)
ELSE
  EXIT
ENDIF
  ENDDO
  HB_MUTEXLOCK(shMutex)
RETURN lRet

/* This code represents the idea only, it is not tested, can contain 
bugs, can be optimized by putting new item position into notify queue, 
to avoid ascan of all array for all mutex subscribers and so on... */



Regards,
Mindaugas
___
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:[14175] trunk/harbour

[druzus]

Revision: 14175
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14175&view=rev
Author:   druzus
Date: 2010-03-15 22:57:31 + (Mon, 15 Mar 2010)

Log Message:
---
2010-03-15 23:57 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/hbwin/wapi_winuser.c
+ added new PRG function:
 WAPI_LoadImage( [], , [],
 [], [], [] ) -> 

  * harbour/contrib/hbwin/Makefile
  + harbour/contrib/hbwin/win_shell.c
+ added new PRG function:
 WIN_ShellNotifyIcon( [], [], [], [],
  [], [] ) -> 

  * harbour/contrib/hbwin/hbwin.ch
+ added new constants for WAPI_LoadImage() and WIN_ShellNotifyIcon()

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/Makefile
trunk/harbour/contrib/hbwin/hbwin.ch
trunk/harbour/contrib/hbwin/wapi_winuser.c

Added Paths:
---
trunk/harbour/contrib/hbwin/win_shell.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour