Re: [Harbour] mysql test sample either compile in LINUX
Have you used HB_WITH_MYSQL=/mysql/include 2010/2/7 Bruno Luciani bruno.luci...@gmail.com: Nobody know how to resolve this ? Bruno 2010/2/5 marco bra marcobra.ubu...@gmail.com Same here on Ubuntu 9.10 32 bits. with harbour -build Harbour 2.1.0dev (Rev. 13777) Copyright (c) 1999-2010, http://www.harbour-project.org/ Harbour Build Info --- Version: Harbour 2.1.0dev (Rev. 13777) Compiler: GNU C 4.4.1 (32-bit) Platform: Linux 2.6.31-16-generic i686 PCode version: 0.2 ChangeLog last entry: 2010-02-05 10:11 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) ChangeLog ID: ChangeLog 13777 2010-02-05 18:13:49Z vouchcac Built on: Feb 5 2010 21:38:59 Build options: Language options: (Clipper 5.3) (Clipper 5.x undoc) (Xbase++) (Flagship) -- Massimo Belgrano ___ 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:[13787] trunk/harbour
Revision: 13787 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13787view=rev Author: vszakats Date: 2010-02-07 00:02:17 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 01:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/runner.c ! Fixed error reported by Petr. I'm not really sure about the problem, and current code I got it by now :) 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:[13788] trunk/harbour
Revision: 13788 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13788view=rev Author: vszakats Date: 2010-02-07 09:57:50 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 10:47 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbapi.h * src/vm/memvars.c * ULONG - HB_SIZE where applicable * int - HB_ISIZ where it was used for size * src/vm/macro.c ! LONG - long for date/time. * include/hbchksum.h * src/rtl/hbadler.c * src/rtl/hbcrc.c * src/rtl/hbi18n1.c * contrib/hbmzip/hbmzip.c * ULONG - HB_U32 for crc32 and adler32 * ULONG - HB_U16 for crc16 (the crc table was also changed to HB_U16, pls speak up if this may cause less-optimal performance than previous state.) * int - HB_ISIZ where it was used for size (in adler loop) * include/hbapi.h * HB_VMHANDLE is now mapped to 'unsigned long' instead of ULONG * contrib/hbwin/win_bmp.c - Deleted no more necessary cast. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbmzip/hbmzip.c trunk/harbour/contrib/hbwin/win_bmp.c trunk/harbour/include/hbapi.h trunk/harbour/include/hbchksum.h trunk/harbour/src/rtl/hbadler.c trunk/harbour/src/rtl/hbcrc.c trunk/harbour/src/rtl/hbi18n1.c trunk/harbour/src/vm/macro.c trunk/harbour/src/vm/memvars.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:[13788] trunk/harbour
On Sun, 07 Feb 2010, vszak...@users.sourceforge.net wrote: Hi, 2010-02-07 10:47 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/memvars.c * int - HB_ISIZ where it was used for size This is wrong and has to be reverted. iSize is limited by HB_SYMBOL_NAME_LEN and 'int' was used as the optimal type for most of C compilers/machines. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13784] trunk/harbour
On Sat, 06 Feb 2010, vszak...@users.sourceforge.net wrote: Hi, 2010-02-06 19:51 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/runner.c * BYTE - char Now in all places expect runner we are using BYTE for PCODE but in runner char. Is it possible that you can join such modifications to make them more consistent? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13788] trunk/harbour
On Sun, 07 Feb 2010, vszak...@users.sourceforge.net wrote: Hi, 2010-02-07 10:47 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/memvars.c * int - HB_ISIZ where it was used for size This is wrong and has to be reverted. iSize is limited by HB_SYMBOL_NAME_LEN and 'int' was used as the optimal type for most of C compilers/machines. Okay, thanks. 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:[13789] trunk/harbour
Revision: 13789 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13789view=rev Author: druzus Date: 2010-02-07 11:18:15 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 12:17 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rdd/dbfcdx/dbfcdx1.c * minor code cleanup * harbour/src/vm/macro.c % eliminated memory allocation in macro compiler for object item assign operation * updated hb_macroGenMessage() to work like hb_compilerGenMessage() * harbour/src/vm/memvars.c * reverted HB_ISIZ - int * harbour/include/hbmacro.h * harbour/include/hbexprop.h * harbour/include/hbexpra.c * harbour/src/common/expropt1.c - eliminated old hb_compExprNewSend()/hb_macroExprNewSend() + added common for compiler and macrocompiler functions: hb_compExprNewSend(), hb_compExprNewMacroSend(), hb_compExprNewMethodObject() * harbour/include/hbcomp.h * harbour/src/compiler/harbour.y * harbour/src/compiler/harbour.yyc * harbour/src/compiler/harbour.yyh * use new functions for send coperator % eliminated asMessage structure - it was the biggest one so this modification reduce total memory usage by grammar stack + added new terminal symbol MacroAny and simplified some rules using it + added static function hb_compCheckMethod() used for enumerator messages - eliminated public function hb_compForEachVarError() * harbour/src/macro/macro.y * harbour/src/macro/macro.yyc * use new functions for send coperator Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbcomp.h trunk/harbour/include/hbexpra.c trunk/harbour/include/hbexprop.h trunk/harbour/include/hbmacro.h trunk/harbour/src/common/expropt1.c trunk/harbour/src/compiler/harbour.y trunk/harbour/src/compiler/harbour.yyc trunk/harbour/src/compiler/harbour.yyh trunk/harbour/src/macro/macro.y trunk/harbour/src/macro/macro.yyc trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c trunk/harbour/src/vm/macro.c trunk/harbour/src/vm/memvars.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:[13784] trunk/harbour
Hi, 2010-02-06 19:51 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/runner.c * BYTE - char Now in all places expect runner we are using BYTE for PCODE but in runner char. Is it possible that you can join such modifications to make them more consistent? Shouldn't we add a dedicated type for PCODE? like HB_PCODE? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_QWith()/with object inside macro compiler
On Wed, 03 Feb 2010, Maurilio Longo wrote:
Hi,
I'd like to see a sample of code which uses with var as well.
Right now, with object enables me to write dynamic html pages via an
interpreter which uses () to evaluate source code and to hide to this
interpreted code whether it is being run as a CGI or as a fast CGI (sort of,
it is xitami lrwp protocol).
I try to explain more in detail so that you can grasp what I'm looking for and
tell me if it is feasible or not with harbour (and following harbour rules).
My web server has an association between .prg files and a cgi program called
hscript (like the old contrib one from which I borrowed several ideas).
When a request comes in for a page with .prg extension the web server calls
hscript which 'executes' the source code like a cgi program and, before
returning, starts another instance of itself which attaches to the webserver
via the lrwp protocol so that all following requests for the same page are an
order of magnitude faster.
Inside hscript I have code like this:
[...]
// interpreted
with object oCGI
Interprete( )
end
// fast cgi
with object oLRWP
Interprete( ... )
end
[...]
where % and % delimit clipper code which calls the oCGI/oLRWP methods to do
its work, output things, or access oCGI/oLRWP iVARs like :Sever_Name or
:Query_String.
So, if with var works with () it is perfect for me, I don't mind having to
change a few with object statements.
with var oCGI
Interprete( ... )
end
I'm really not able to give you more valid reasons to have such a capability,
because I'm using it just for this kind of code (my employer web site, for
example, is completely written this way).
In the above text you haven't presented anything what causes that you
have to use WITH OBJECT at all. In such context you can reach the same
effect using some private variables, i.e. _WITH and make all such code
Clipper compatible so for me it's not the reason to change core code.
If I add such extension and document using :msg in macro compiler
then it will be very hard to revert it in the future and it will close
door to optimize code generated for WITH OBJECT because it will be
necessary to keep current implementation which needs additional HVM
stack register lWithObject which can be eliminated and by compile
time calculations. In my opinion it's bad idea and I think that most
of users prefer better performance then some seldom use extensions
which are not structural and volatile language semantic (it's possible
to use such macros outside WITH OBJECT / END statement what should be
forbidden). Also HB_QWITH() function comes from XHB library and it's
not Harbour core functions because in the future it's possible that
we will have to eliminate it.
Now WITH OBJECT is in practice compiler only extension. It was added
replicating xHarbour behavior for compatibility but it introduced
series of anomalies like hacked preprocessor (I sent examples in
previous message) or code with more then one meaning, i.e.:
case : msg()
used inside DO CASE and WITH OBJECT statement can be compiled as:
case ( :msg() ) // DO CASE condition
or:
(case):msg() // 'msg' is sent to object in 'case' variable
Such things should not happen in well designed language so I would
like to eliminate it in the future even with the cost of compatibility
with xHarbour.
As long as current WITH OBJECT is compiler only extension then when
we replace it by some new one users can easy fix their code because
old syntax is reported as error at compile time so it will be simple
process. If we add official support for :msg[(params,...)] to
macrocompiler then compiler won't report any errors at compile time
making switching to new syntax much harder.
Now probably only few users like you used it in macrocompiler creating
code for xHarbour so such extension will only increase the problem in
the future.
I can understand that you have some xHarbour code and it's serious
problem for you. In last commit I cleaned some grammar code used
to compile messages so you can enable it very easy in your own
personal Harbour builds. It's enough to add this line to macro.y[485]:
| ':' SendId { $$ = $2; }
and regenerate macro.yyc
below is a patch.
HTH and you understand why I do not want to change it in SVN code.
best regards,
Przemek
--- harbour/src/macro/macro.y (wersja 13789)
+++ harbour/src/macro/macro.y (kopia robocza)
@@ -482,6 +482,7 @@
/* Object's instance variable
*/
ObjectData : LeftExpression ':' SendId { $$ = hb_compExprNewMethodObject(
$3, $1 ); }
+| ':' SendId { $$ = $2; }
;
SendId : IDENTIFIER { $$ = hb_compExprNewSend( $1, HB_COMP_PARAM ); }
___
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:[13790] trunk/harbour
Revision: 13790 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13790view=rev Author: vszakats Date: 2010-02-07 12:17:40 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 13:16 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/fm.c * src/vm/extrap.c * src/common/hbarch.c * src/nortl/nortl.c * src/rtl/binnum.c * src/rtl/hbbffnc.c * src/rtl/hbznet.c * src/rtl/hbbfish.c * src/rtl/hbbyte.c * src/rtl/binnumx.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/dbf1.c * src/rdd/hsx/hsx.c * src/rdd/dbffpt/dbffpt1.c * src/rdd/hbsix/sxcrypt.c * src/compiler/cmdcheck.c * include/hbgtcore.h * include/hbdefs.h * include/hbbfish.h * contrib/hbct/bitnum.c * contrib/hbct/ctwin.c * contrib/xpp/binnumx.c * contrib/hbnetio/netiocli.c * contrib/hbnetio/netiosrv.c * contrib/hbbmcdx/bmdbfcdx.c * contrib/hbbtree/hb_btree.c * UINT16 - HB_U16 * UINT32 - HB_U32 * UINT64 - HB_U64 * INT16 - HB_I16 * INT32 - HB_I32 * INT64 - HB_I64 * contrib/hbct/bitnum.c ! Fixed INTNEG(), INTPOS(). Second 'l32bit' parameter was working in reverse. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/hbbtree/hb_btree.c trunk/harbour/contrib/hbct/bitnum.c trunk/harbour/contrib/hbct/ctwin.c trunk/harbour/contrib/hbnetio/netiocli.c trunk/harbour/contrib/hbnetio/netiosrv.c trunk/harbour/contrib/xpp/binnumx.c trunk/harbour/include/hbbfish.h trunk/harbour/include/hbdefs.h trunk/harbour/include/hbgtcore.h trunk/harbour/src/common/hbarch.c trunk/harbour/src/compiler/cmdcheck.c trunk/harbour/src/nortl/nortl.c trunk/harbour/src/rdd/dbf1.c trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c trunk/harbour/src/rdd/dbffpt/dbffpt1.c trunk/harbour/src/rdd/hbsix/sxcrypt.c trunk/harbour/src/rdd/hsx/hsx.c trunk/harbour/src/rtl/binnum.c trunk/harbour/src/rtl/binnumx.c trunk/harbour/src/rtl/hbbffnc.c trunk/harbour/src/rtl/hbbfish.c trunk/harbour/src/rtl/hbbyte.c trunk/harbour/src/rtl/hbznet.c trunk/harbour/src/vm/extrap.c trunk/harbour/src/vm/fm.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error...SqlMix...
Harbour Rev. 13777, Mysql 5.1 During compilation appears this error: sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_cl...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_er...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_er...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_real_conn...@32 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_i...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_insert...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_affected_r...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_field_co...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_free_res...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_num_r...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_store_res...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_real_qu...@12 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_fetch_...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlOpen(struct _SQLBASEAREA *) (?mysqlOpen@@YAIPAU_SQLBASEAREA@@@Z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_row_t...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlOpen(struct _SQLBASEAREA *) (?mysqlOpen@@YAIPAU_SQLBASEAREA@@@Z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_fetch_field_dir...@8 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlOpen(struct _SQLBASEAREA *) (?mysqlOpen@@YAIPAU_SQLBASEAREA@@@Z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_num_fie...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlOpen(struct _SQLBASEAREA *) (?mysqlOpen@@YAIPAU_SQLBASEAREA@@@Z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_fetch_leng...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlGoTo(struct _SQLBASEAREA *,unsigned long) (?mysqlGoTo@@YAIPAU_SQLBASEAREA@@k...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_row_s...@8 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlGoTo(struct _SQLBASEAREA *,unsigned long) (?mysqlGoTo@@YAIPAU_SQLBASEAREA@@k...@z) How to solve this? Thank -- View this message in context: http://old.nabble.com/Error...SqlMix...-tp27488122p27488122.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13790] trunk/harbour
On Sun, 07 Feb 2010, vszak...@users.sourceforge.net wrote: Hi, 2010-02-07 13:16 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/fm.c * src/vm/extrap.c * src/common/hbarch.c * src/nortl/nortl.c * src/rtl/binnum.c * src/rtl/hbbffnc.c * src/rtl/hbznet.c * src/rtl/hbbfish.c * src/rtl/hbbyte.c * src/rtl/binnumx.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/dbf1.c * src/rdd/hsx/hsx.c * src/rdd/dbffpt/dbffpt1.c * src/rdd/hbsix/sxcrypt.c * src/compiler/cmdcheck.c * include/hbgtcore.h * include/hbdefs.h * include/hbbfish.h * contrib/hbct/bitnum.c * contrib/hbct/ctwin.c * contrib/xpp/binnumx.c * contrib/hbnetio/netiocli.c * contrib/hbnetio/netiosrv.c * contrib/hbbmcdx/bmdbfcdx.c * contrib/hbbtree/hb_btree.c * UINT16 - HB_U16 * UINT32 - HB_U32 * UINT64 - HB_U64 * INT16 - HB_I16 * INT32 - HB_I32 * INT64 - HB_I64 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
Re: [Harbour] SF.net SVN: harbour-project:[13784] trunk/harbour
On Sun, 07 Feb 2010, Szak�ts Viktor wrote: Hi, Shouldn't we add a dedicated type for PCODE? like HB_PCODE? We use HB_PCODE as enum type (see hbpcode.h). Anyhow separate type is good idea. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13784] trunk/harbour
Shouldn't we add a dedicated type for PCODE? like HB_PCODE? We use HB_PCODE as enum type (see hbpcode.h). Anyhow separate type is good idea. Let's find a name. HB_PCODE_T? (not hugely elegant though) Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error...SqlMix...
resolved, I lacked Add a libmysql.lib Thanks Ale SB wrote: Harbour Rev. 13777, Mysql 5.1 During compilation appears this error: sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_cl...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_er...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_er...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_real_conn...@32 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_i...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlConnect(struct _SQLDDCONNECTION *,void *) (?mysqlConnect@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_insert...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_affected_r...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_field_co...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_free_res...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_num_r...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_store_res...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_real_qu...@12 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlExecute(struct _SQLDDCONNECTION *,void *) (?mysqlExecute@@YAIPAU_SQLDDCONNECTION@@p...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_fetch_...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlOpen(struct _SQLBASEAREA *) (?mysqlOpen@@YAIPAU_SQLBASEAREA@@@Z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_row_t...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlOpen(struct _SQLBASEAREA *) (?mysqlOpen@@YAIPAU_SQLBASEAREA@@@Z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_fetch_field_dir...@8 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlOpen(struct _SQLBASEAREA *) (?mysqlOpen@@YAIPAU_SQLBASEAREA@@@Z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_num_fie...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlOpen(struct _SQLBASEAREA *) (?mysqlOpen@@YAIPAU_SQLBASEAREA@@@Z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_fetch_leng...@4 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlGoTo(struct _SQLBASEAREA *,unsigned long) (?mysqlGoTo@@YAIPAU_SQLBASEAREA@@k...@z) sddmy.lib(mysqldd.obj) : error LNK2019: símbolo externo _mysql_row_s...@8 sin resolver al que se hace referencia en la función unsigned int __cdecl mysqlGoTo(struct _SQLBASEAREA *,unsigned long) (?mysqlGoTo@@YAIPAU_SQLBASEAREA@@k...@z) How to solve this? Thank -- View this message in context: http://old.nabble.com/Error...SqlMix...-tp27488122p27488310.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13791] trunk/harbour
Revision: 13791 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13791view=rev Author: vszakats Date: 2010-02-07 12:58:41 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 13:58 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbct/ctchksum.c ! Fixed to not strip const from type. * ULONG - HB_SIZE, HB_U32 * UCHAR - HB_UCHAR * contrib/hbct/asciisum.c * size_t - HB_SIZE * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbct/asciisum.c trunk/harbour/contrib/hbct/ctchksum.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13792] trunk/harbour
Revision: 13792 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13792view=rev Author: vszakats Date: 2010-02-07 13:19:33 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 14:18 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/pp/ppcore.c * src/vm/itemapi.c * src/vm/dynlibhb.c * src/vm/set.c * src/debug/dbgentry.c * src/common/expropt1.c * src/common/hbstr.c * src/common/expropt2.c * src/macro/macro.yyc * src/macro/macro.y * src/macro/macro.yyh * src/rtl/scroll.c * src/rtl/gtdos/gtdos.c * src/rtl/gtwin/gtwin.c * src/rtl/gttrm/gttrm.c * src/rtl/transfrm.c * src/rtl/dates.c * src/rtl/filesys.c * src/rtl/chrasc.c * src/rtl/cdpapi.c * src/rtl/hbi18n1.c * src/rtl/itemseri.c * src/rtl/hbhex.c * src/rtl/cdpapihb.c * src/rdd/dbsql.c * src/rdd/dbfnsx/dbfnsx1.c * src/rdd/dbf1.c * src/rdd/hsx/hsx.c * src/rdd/hbsix/sxutil.c * src/rdd/hbsix/sxcompr.c * src/rdd/hbsix/sxcrypt.c * src/compiler/compi18n.c * src/compiler/complex.c * src/compiler/genc.c * src/compiler/harbour.yyc * src/compiler/harbour.y * src/compiler/harbour.yyh * include/hbpp.h * include/hbapicdp.h * include/hbrddnsx.h * include/hbexprb.c * ChangeLog * contrib/hbct/screen2.c * contrib/hbct/pos1.c * contrib/hbct/screen1.c * contrib/hbct/token1.c * contrib/hbct/disk.c * contrib/xhb/xhbmsgs.c * contrib/hbnf/ftattr.c * UCHAR - HB_UCHAR ; NOTE: In cdp subsystem 'unsigned char' is used instead of HB_UCHAR in many places, maybe it needs cleanup (I've found one inconsistency in a function declaration). ; QUESTION: There is one suspiciously looking usage: ftattr.c / iColor = ( HB_UCHAR ) *pAttrib++; Is it ok? Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbct/disk.c trunk/harbour/contrib/hbct/pos1.c trunk/harbour/contrib/hbct/screen1.c trunk/harbour/contrib/hbct/screen2.c trunk/harbour/contrib/hbct/token1.c trunk/harbour/contrib/hbnf/ftattr.c trunk/harbour/contrib/xhb/xhbmsgs.c trunk/harbour/include/hbapicdp.h trunk/harbour/include/hbexprb.c trunk/harbour/include/hbpp.h trunk/harbour/include/hbrddnsx.h trunk/harbour/src/common/expropt1.c trunk/harbour/src/common/expropt2.c trunk/harbour/src/common/hbstr.c trunk/harbour/src/compiler/compi18n.c trunk/harbour/src/compiler/complex.c trunk/harbour/src/compiler/genc.c trunk/harbour/src/compiler/harbour.y trunk/harbour/src/compiler/harbour.yyc trunk/harbour/src/compiler/harbour.yyh trunk/harbour/src/debug/dbgentry.c trunk/harbour/src/macro/macro.y trunk/harbour/src/macro/macro.yyc trunk/harbour/src/macro/macro.yyh trunk/harbour/src/pp/ppcore.c trunk/harbour/src/rdd/dbf1.c trunk/harbour/src/rdd/dbfnsx/dbfnsx1.c trunk/harbour/src/rdd/dbsql.c trunk/harbour/src/rdd/hbsix/sxcompr.c trunk/harbour/src/rdd/hbsix/sxcrypt.c trunk/harbour/src/rdd/hbsix/sxutil.c trunk/harbour/src/rdd/hsx/hsx.c trunk/harbour/src/rtl/cdpapi.c trunk/harbour/src/rtl/cdpapihb.c trunk/harbour/src/rtl/chrasc.c trunk/harbour/src/rtl/dates.c trunk/harbour/src/rtl/filesys.c trunk/harbour/src/rtl/gtdos/gtdos.c trunk/harbour/src/rtl/gttrm/gttrm.c trunk/harbour/src/rtl/gtwin/gtwin.c trunk/harbour/src/rtl/hbhex.c trunk/harbour/src/rtl/hbi18n1.c trunk/harbour/src/rtl/itemseri.c trunk/harbour/src/rtl/scroll.c trunk/harbour/src/rtl/transfrm.c trunk/harbour/src/vm/dynlibhb.c trunk/harbour/src/vm/itemapi.c trunk/harbour/src/vm/set.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13793] trunk/harbour
Revision: 13793 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13793view=rev Author: vszakats Date: 2010-02-07 13:41:30 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 14:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbct/strdiff.c * contrib/hbct/token2.c * contrib/hbct/charlist.c * contrib/hbct/charonly.c * contrib/hbct/atadjust.c * contrib/hbct/charsort.c * contrib/hbct/charmix.c * contrib/hbct/charevod.c * contrib/hbct/wordrepl.c * contrib/hbct/charrepl.c * contrib/hbct/strswap.c * contrib/hbct/charswap.c * contrib/hbct/charop.c * contrib/hbct/charone.c * contrib/hbct/pos1.c * contrib/hbct/ascpos.c * contrib/hbct/ctstr.c * contrib/hbct/token1.c * contrib/hbct/ctstr.h * contrib/hbct/charmirr.c * contrib/hbct/relation.c * contrib/hbct/atnum.c * contrib/hbct/count.c * contrib/hbct/ctcrypt.c * contrib/hbct/posdiff.c * contrib/hbct/range.c * contrib/hbct/addascii.c * contrib/hbct/tab.c * contrib/hbct/dattime2.c * contrib/hbct/replace.c * contrib/hbct/pos2.c * contrib/hbct/numat.c * contrib/hbct/atrepl.c * contrib/hbct/wordtoch.c * contrib/hbct/ctpad.c * contrib/hbct/justify.c * contrib/hbct/remove.c * size_t - HB_SIZE % Deleted now unnecessary casts. + Added casts to strlen() calls. * contrib/hbct/ctcrypt.c * ULONG - HB_SIZE * contrib/hbct/dattime2.c * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbct/addascii.c trunk/harbour/contrib/hbct/ascpos.c trunk/harbour/contrib/hbct/atadjust.c trunk/harbour/contrib/hbct/atnum.c trunk/harbour/contrib/hbct/atrepl.c trunk/harbour/contrib/hbct/charevod.c trunk/harbour/contrib/hbct/charlist.c trunk/harbour/contrib/hbct/charmirr.c trunk/harbour/contrib/hbct/charmix.c trunk/harbour/contrib/hbct/charone.c trunk/harbour/contrib/hbct/charonly.c trunk/harbour/contrib/hbct/charop.c trunk/harbour/contrib/hbct/charrepl.c trunk/harbour/contrib/hbct/charsort.c trunk/harbour/contrib/hbct/charswap.c trunk/harbour/contrib/hbct/count.c trunk/harbour/contrib/hbct/ctcrypt.c trunk/harbour/contrib/hbct/ctpad.c trunk/harbour/contrib/hbct/ctstr.c trunk/harbour/contrib/hbct/ctstr.h trunk/harbour/contrib/hbct/dattime2.c trunk/harbour/contrib/hbct/justify.c trunk/harbour/contrib/hbct/numat.c trunk/harbour/contrib/hbct/pos1.c trunk/harbour/contrib/hbct/pos2.c trunk/harbour/contrib/hbct/posdiff.c trunk/harbour/contrib/hbct/range.c trunk/harbour/contrib/hbct/relation.c trunk/harbour/contrib/hbct/remove.c trunk/harbour/contrib/hbct/replace.c trunk/harbour/contrib/hbct/strdiff.c trunk/harbour/contrib/hbct/strswap.c trunk/harbour/contrib/hbct/tab.c trunk/harbour/contrib/hbct/token1.c trunk/harbour/contrib/hbct/token2.c trunk/harbour/contrib/hbct/wordrepl.c trunk/harbour/contrib/hbct/wordtoch.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] mysql test sample either compile in LINUX
Is needed in linux ? Bruno 2010/2/7 Massimo Belgrano mbelgr...@deltain.it Have you used HB_WITH_MYSQL=/mysql/include 2010/2/7 Bruno Luciani bruno.luci...@gmail.com: Nobody know how to resolve this ? Bruno 2010/2/5 marco bra marcobra.ubu...@gmail.com Same here on Ubuntu 9.10 32 bits. with harbour -build Harbour 2.1.0dev (Rev. 13777) Copyright (c) 1999-2010, http://www.harbour-project.org/ Harbour Build Info --- Version: Harbour 2.1.0dev (Rev. 13777) Compiler: GNU C 4.4.1 (32-bit) Platform: Linux 2.6.31-16-generic i686 PCode version: 0.2 ChangeLog last entry: 2010-02-05 10:11 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) ChangeLog ID: ChangeLog 13777 2010-02-05 18:13:49Z vouchcac Built on: Feb 5 2010 21:38:59 Build options: Language options: (Clipper 5.3) (Clipper 5.x undoc) (Xbase++) (Flagship) -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13794] trunk/harbour
Revision: 13794 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13794view=rev Author: vszakats Date: 2010-02-07 13:53:35 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 14:53 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/itemapi.c * src/vm/hvm.c * src/vm/arrays.c * src/vm/extend.c * src/common/hbstr.c * src/common/hbdate.c * src/rdd/dbfcdx/dbfcdx1.c * src/compiler/gencc.c * tests/bldtest/bldtest.c * include/hbxvm.h * include/hbdefs.h * include/hbapi.h * include/hbapiitm.h * contrib/hbwin/olecore.c * contrib/hbbmcdx/bmdbfcdx.c * LONGLONG - HB_LONGLONG * ULONGLONG - HB_ULONGLONG Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/hbwin/olecore.c trunk/harbour/include/hbapi.h trunk/harbour/include/hbapiitm.h trunk/harbour/include/hbdefs.h trunk/harbour/include/hbxvm.h trunk/harbour/src/common/hbdate.c trunk/harbour/src/common/hbstr.c trunk/harbour/src/compiler/gencc.c trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c trunk/harbour/src/vm/arrays.c trunk/harbour/src/vm/extend.c trunk/harbour/src/vm/hvm.c trunk/harbour/src/vm/itemapi.c trunk/harbour/tests/bldtest/bldtest.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] mysql test sample either compile in LINUX
I don't know because i have lost my ubuntu virtual machine when you start make it display ! Component:mysql?? 2010/2/7 Bruno Luciani bruno.luci...@gmail.com: Is needed in linux ? Bruno 2010/2/7 Massimo Belgrano mbelgr...@deltain.it Have you used HB_WITH_MYSQL=/mysql/include -- Massimo Belgrano ___ 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:[13795] trunk/harbour
Revision: 13795 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13795view=rev Author: vszakats Date: 2010-02-07 14:16:13 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 15:15 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/dynsym.c * src/vm/fm.c * src/vm/classes.c * src/rtl/transfrm.c * src/rtl/filebuf.c * src/rdd/wacore.c * src/compiler/compi18n.c * tests/bldtest/bldtest.c * include/hbcomp.h * include/hbcompdf.h * contrib/xhb/hbserv.c * contrib/hbfimage/fi_wrp.c * UINT - HB_UINT, unsigned, HB_SIZE, (unchanged) Depending on context. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbfimage/fi_wrp.c trunk/harbour/contrib/xhb/hbserv.c trunk/harbour/include/hbcomp.h trunk/harbour/include/hbcompdf.h trunk/harbour/src/compiler/compi18n.c trunk/harbour/src/rdd/wacore.c trunk/harbour/src/rtl/filebuf.c trunk/harbour/src/rtl/transfrm.c trunk/harbour/src/vm/classes.c trunk/harbour/src/vm/dynsym.c trunk/harbour/src/vm/fm.c trunk/harbour/tests/bldtest/bldtest.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Errors in latest SVN
Error E2257 ../../../../../include\hbdefs.h 608: , expected Error E2238 ../../../../../include\hbdefs.h 718: Multiple declaration for 'HB_LONGLONG' Error E2344 ../../../../../include\hbdefs.h 608: Earlier declaration of 'HB_LONGLONG' EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Errors in latest SVN
After revision 13795 with clean build I get this: win-make.exe[3]: `../../../../../lib/win/mingw/libsqlite3.a' is up to date. 1 arquivo(s) copiado(s). gcc -I. -I../../../../../include -O3 -fomit-frame-pointer -march=i586 -mtune=p entiumpro -Ic:/harbour/external/zlib -Ic:/harbour/external/libpng -o_hbhbpdf.o -c ../../../_hbhbpdf.c In file included from ../../../../../include/hbvmpub.h:56, from ../../../../../include/hbapi.h:61, from ../../../_hbhbpdf.c:5: ../../../../../include/hbdefs.h:608: error: expected '=', ',', ';', 'asm' or '__ attribute__' before 'HB_FOFFSET' win-make.exe[3]: *** [_hbhbpdf.o] Error 1 win-make.exe[2]: *** [descend] Error 2 win-make.exe[1]: *** [libhpdf.inst] Error 2 win-make.exe: *** [external.inst] Error 2 Regards, Vailton Renato ___ 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:[13796] trunk/harbour
Revision: 13796 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13796view=rev Author: vszakats Date: 2010-02-07 15:03:51 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 16:03 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbdefs.h ! New Harbour types moved upper in the file to avoid errors reported on the list. - Deleted HB_I8 and HB_U8 types. Practice shows that HB_UCHAR and HB_SCHAR are used instead of these. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbdefs.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:[13796] trunk/harbour
-Messaggio Originale- Da: vszak...@users.sourceforge.net A: harbour@harbour-project.org Data invio: domenica 7 febbraio 2010 16.03 Oggetto: [Harbour] SF.net SVN: harbour-project:[13796] trunk/harbour Thank you. Now I get: Error E2176 ../../../cdpapi.c 1047: Too many types in declaration EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ 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:[13796] trunk/harbour
Thank you, it's a typo, just remove 'char' from return type until I commit the fix. Brgds, Viktor On 2010 Feb 7, at 16:14, Enrico Maria Giordano wrote: -Messaggio Originale- Da: vszak...@users.sourceforge.net A: harbour@harbour-project.org Data invio: domenica 7 febbraio 2010 16.03 Oggetto: [Harbour] SF.net SVN: harbour-project:[13796] trunk/harbour Thank you. Now I get: Error E2176 ../../../cdpapi.c 1047: Too many types in declaration EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13797] trunk/harbour
Revision: 13797 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13797view=rev Author: vszakats Date: 2010-02-07 15:37:24 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 16:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/cdpapi.c ! Fixed type when manually correcting 'unsigned char' to UCHAR to sync with declaration. * contrib/gtwvg/gtwvg.c ! Fixed wrong casts (HB_LONG instead of long) * src/pp/ppcore.c * src/vm/macro.c * src/vm/hashes.c * src/vm/itemapi.c * src/vm/hvm.c * src/vm/arrays.c * src/vm/task.c * src/vm/thread.c * src/vm/extend.c * src/common/hbwince.c * src/common/expropt1.c * src/common/hbstr.c * src/common/expropt2.c * src/common/hbdate.c * src/macro/macro.yyc * src/macro/macro.y * src/macro/macro.yyh * src/macro/macrolex.c * src/rtl/gttrm/gttrm.c * src/rtl/hbstrfmt.c * src/rtl/hbcrc.c * src/rtl/minmax.c * src/rtl/hbrandom.c * src/rtl/hbsocket.c * src/rtl/hbbit.c * src/rtl/hbgtcore.c * src/rtl/cputime.c * src/rtl/idle.c * src/rtl/itemseri.c * src/rtl/gtsln/gtsln.c * src/rtl/gtpca/gtpca.c * src/rtl/hbznet.c * src/rtl/hbhex.c * src/rtl/seconds.c * src/rtl/abs.c * src/rtl/gtwvt/gtwvt.c * src/rtl/hbbyte.c * src/rtl/val.c * src/rdd/dbfntx/dbfntx1.c * src/rdd/dbsql.c * src/rdd/sdf1.c * src/rdd/delim1.c * src/rdd/dbf1.c * src/rdd/dbffpt/dbffpt1.c * src/compiler/hbmain.c * src/compiler/complex.c * src/compiler/harbour.yyc * src/compiler/harbour.y * src/compiler/harbour.yyh * include/hbvmpub.h * include/hbgtcore.h * include/hbthread.h * include/hbdefs.h * include/hbmacro.h * include/hbapi.h * include/hbapiitm.h * include/hbznet.h * include/hbvm.h * include/hbcomp.h * include/hbcompdf.h * include/hbexprop.h * include/hbsocket.h * include/hbchksum.h * include/hbexprb.c * include/hbdate.h * contrib/hbct/bitnum.c * contrib/hbct/dbftools.c * contrib/hbct/files.c * contrib/hbct/disk.c * contrib/xhb/xhbfunc.c * contrib/hbcurl/hbcurl.c * contrib/hbnetio/netiocli.c * contrib/hbnetio/netiosrv.c * contrib/gtwvg/gtwvg.c * contrib/gtwvg/wvggui.c * contrib/gtwvg/wvgcore.c * contrib/rddads/ads1.c * contrib/hbwin/olecore.c * HB_LONG - HB_MAXINT * HB_ULONG - HB_MAXUINT Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/contrib/gtwvg/wvgcore.c trunk/harbour/contrib/gtwvg/wvggui.c trunk/harbour/contrib/hbct/bitnum.c trunk/harbour/contrib/hbct/dbftools.c trunk/harbour/contrib/hbct/disk.c trunk/harbour/contrib/hbct/files.c trunk/harbour/contrib/hbcurl/hbcurl.c trunk/harbour/contrib/hbnetio/netiocli.c trunk/harbour/contrib/hbnetio/netiosrv.c trunk/harbour/contrib/hbwin/olecore.c trunk/harbour/contrib/rddads/ads1.c trunk/harbour/contrib/xhb/xhbfunc.c trunk/harbour/include/hbapi.h trunk/harbour/include/hbapiitm.h trunk/harbour/include/hbchksum.h trunk/harbour/include/hbcomp.h trunk/harbour/include/hbcompdf.h trunk/harbour/include/hbdate.h trunk/harbour/include/hbdefs.h trunk/harbour/include/hbexprb.c trunk/harbour/include/hbexprop.h trunk/harbour/include/hbgtcore.h trunk/harbour/include/hbmacro.h trunk/harbour/include/hbsocket.h trunk/harbour/include/hbthread.h trunk/harbour/include/hbvm.h trunk/harbour/include/hbvmpub.h trunk/harbour/include/hbznet.h trunk/harbour/src/common/expropt1.c trunk/harbour/src/common/expropt2.c trunk/harbour/src/common/hbdate.c trunk/harbour/src/common/hbstr.c trunk/harbour/src/common/hbwince.c trunk/harbour/src/compiler/complex.c trunk/harbour/src/compiler/harbour.y trunk/harbour/src/compiler/harbour.yyc trunk/harbour/src/compiler/harbour.yyh trunk/harbour/src/compiler/hbmain.c trunk/harbour/src/macro/macro.y trunk/harbour/src/macro/macro.yyc trunk/harbour/src/macro/macro.yyh trunk/harbour/src/macro/macrolex.c trunk/harbour/src/pp/ppcore.c trunk/harbour/src/rdd/dbf1.c trunk/harbour/src/rdd/dbffpt/dbffpt1.c trunk/harbour/src/rdd/dbfntx/dbfntx1.c trunk/harbour/src/rdd/dbsql.c trunk/harbour/src/rdd/delim1.c trunk/harbour/src/rdd/sdf1.c trunk/harbour/src/rtl/abs.c trunk/harbour/src/rtl/cdpapi.c trunk/harbour/src/rtl/cputime.c trunk/harbour/src/rtl/gtpca/gtpca.c trunk/harbour/src/rtl/gtsln/gtsln.c trunk/harbour/src/rtl/gttrm/gttrm.c trunk/harbour/src/rtl/gtwvt/gtwvt.c trunk/harbour/src/rtl/hbbit.c trunk/harbour/src/rtl/hbbyte.c trunk/harbour/src/rtl/hbcrc.c trunk/harbour/src/rtl/hbgtcore.c trunk/harbour/src/rtl/hbhex.c trunk/harbour/src/rtl/hbrandom.c trunk/harbour/src/rtl/hbsocket.c trunk/harbour/src/rtl/hbstrfmt.c trunk/harbour/src/rtl/hbznet.c trunk/harbour/src/rtl/idle.c trunk/harbour/src/rtl/itemseri.c
Re: [Harbour] SF.net SVN: harbour-project:[13792] trunk/harbour
On Sun, 07 Feb 2010, vszak...@users.sourceforge.net wrote: Hi, ; QUESTION: There is one suspiciously looking usage: ftattr.c / iColor = ( HB_UCHAR ) *pAttrib++; Is it ok? Yes of course. 'char' is usually signed type so values like 0x80 will be translated to -128 without such casting so it's extremely important have it in such places. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13796] trunk/harbour
On Sun, 07 Feb 2010, vszak...@users.sourceforge.net wrote: Hi, 2010-02-07 16:03 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbdefs.h ! New Harbour types moved upper in the file to avoid errors reported on the list. - Deleted HB_I8 and HB_U8 types. Practice shows that HB_UCHAR and HB_SCHAR are used instead of these. Does it mean that we decided to definitely drop support for platforms which do not use 8 bit characters? I do not plan to make such ports in reasonable time so it's not a problem for me but maybe someone else will want to port Harbour to some IBM machines. 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:[13798] trunk/harbour
Revision: 13798 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13798view=rev Author: vszakats Date: 2010-02-07 15:54:35 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 16:54 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/gtwvt/gtwvt.c * contrib/gtwvg/gtwvg.c * contrib/hbmisc/hb_f.c * contrib/hbwin/win_dll.c * SHORT type cleanup. Converted to HB_WCHAR, nothing, USHORT, WORD depending on context. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/contrib/hbmisc/hb_f.c trunk/harbour/contrib/hbwin/win_dll.c trunk/harbour/src/rtl/gtwvt/gtwvt.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13799] trunk/harbour
Revision: 13799 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13799view=rev Author: vouchcac Date: 2010-02-07 15:56:14 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 07:46 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/hbqt_hbqplaintextedit.cpp * contrib/hbqt/hbqt_hbqplaintextedit.h * contrib/hbqt/qtgui/HBQPlainTextEdit.cpp * contrib/hbqt/qtgui/THBQPlainTextEdit.prg * contrib/hbqt/qth/HBQPlainTextEdit.qth * contrib/hbide/hbide.prg * contrib/hbide/ideactions.prg * contrib/hbide/ideeditor.prg * contrib/hbide/idefindreplace.prg + Implemented Delete Line Ctrl+Del - Current Line Indent Right Ctrl+Tab - Selected Lines Indent Right Shift+Ctrl+Tab - Selected Lines Indenting is exercised on selected lines with one column at a time. Vailton, can you create icons for above? Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/ideactions.prg trunk/harbour/contrib/hbide/ideeditor.prg trunk/harbour/contrib/hbide/idefindreplace.prg trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.h trunk/harbour/contrib/hbqt/qtgui/HBQPlainTextEdit.cpp trunk/harbour/contrib/hbqt/qtgui/THBQPlainTextEdit.prg trunk/harbour/contrib/hbqt/qth/HBQPlainTextEdit.qth 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:[13800] trunk/harbour
Revision: 13800 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13800view=rev Author: vszakats Date: 2010-02-07 16:10:56 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 17:10 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/hvm.c * src/rdd/dbfntx/dbfntx1.c * src/rdd/dbfnsx/dbfnsx1.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/dbf1.c * src/rdd/usrrdd/usrrdd.c * src/rdd/dbffpt/dbffpt1.c * src/rdd/hbsix/sxcompr.c * src/compiler/hbfix.c * src/compiler/hbopt.c * tests/bldtest/bldtest.c * include/hbrddnsx.h * include/hbxvm.h * include/hbdefs.h * include/hbapi.h * include/hbrddntx.h * include/hbrddcdx.h * contrib/hbbmcdx/bmdbfcdx.c * contrib/hbbmcdx/hbbmcdx.h * SHORT - HB_SHORT. (in some places 'short' is used, these should be synced, noticed it in RDD) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/hbbmcdx/hbbmcdx.h trunk/harbour/include/hbapi.h trunk/harbour/include/hbdefs.h trunk/harbour/include/hbrddcdx.h trunk/harbour/include/hbrddnsx.h trunk/harbour/include/hbrddntx.h trunk/harbour/include/hbxvm.h trunk/harbour/src/compiler/hbfix.c trunk/harbour/src/compiler/hbopt.c trunk/harbour/src/rdd/dbf1.c trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c trunk/harbour/src/rdd/dbffpt/dbffpt1.c trunk/harbour/src/rdd/dbfnsx/dbfnsx1.c trunk/harbour/src/rdd/dbfntx/dbfntx1.c trunk/harbour/src/rdd/hbsix/sxcompr.c trunk/harbour/src/rdd/usrrdd/usrrdd.c trunk/harbour/src/vm/hvm.c trunk/harbour/tests/bldtest/bldtest.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:[13796] trunk/harbour
-Messaggio Originale- Da: Viktor Szakáts harbour...@syenar.hu A: Harbour Project Main Developer List. harbour@harbour-project.org Data invio: domenica 7 febbraio 2010 16.23 Oggetto: Re: [Harbour] SF.net SVN: harbour-project:[13796] trunk/harbour Thank you, it's a typo, just remove 'char' from return type until I commit the fix. Thank you, it's ok after your last commit. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ 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:[13802] trunk/harbour
Revision: 13802 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13802view=rev Author: vszakats Date: 2010-02-07 17:47:39 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 18:36 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbdefs.h + Changed types to have our new types as primary ones, and old types as legacy ones. This also means that all old/legacy types are now based on new types. + Added HB_LEGACY_TYPES_OFF #define, with which you can disable all legacy types for testing purposes. This mode will become the default in the future, so start to prepare for the new types. ; NOTE: Harbour and 3rd party components can't be compiled with this switch enabled yet, since there is still some type conversions tasks left. For now its purpose is to look for remaining legacy types in Harbour code. * include/hbvmpub.h * BYTE - HB_BYTE Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbdefs.h trunk/harbour/include/hbvmpub.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] SF.net SVN: harbour-project:[13803] trunk/harbour
Revision: 13803 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13803view=rev Author: vszakats Date: 2010-02-07 18:03:00 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 19:02 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/classes.c * src/rtl/gtdos/gtdos.c * src/rtl/gtxwc/gtxwc.c * src/rdd/wacore.c * src/rdd/dbfnsx/dbfnsx1.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/dbffpt/dbffpt1.c * src/compiler/genobj32.c * include/hbinit.h * include/hbrddcdx.h * contrib/xhb/hbcrypt.c * contrib/xhb/freadlin.c * contrib/xhb/txtline.c * contrib/hbnf/descendn.c * contrib/rddsql/sqlmix.c * contrib/rddads/adsx.c * contrib/hbtip/encmthd.c * contrib/hbbmcdx/bmdbfcdx.c * contrib/hbbmcdx/hbbmcdx.h * Formatting. (whitespace only) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/hbbmcdx/hbbmcdx.h trunk/harbour/contrib/hbnf/descendn.c trunk/harbour/contrib/hbtip/encmthd.c trunk/harbour/contrib/rddads/adsx.c trunk/harbour/contrib/rddsql/sqlmix.c trunk/harbour/contrib/xhb/freadlin.c trunk/harbour/contrib/xhb/hbcrypt.c trunk/harbour/contrib/xhb/txtline.c trunk/harbour/include/hbinit.h trunk/harbour/include/hbrddcdx.h trunk/harbour/src/compiler/genobj32.c trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c trunk/harbour/src/rdd/dbffpt/dbffpt1.c trunk/harbour/src/rdd/dbfnsx/dbfnsx1.c trunk/harbour/src/rdd/wacore.c trunk/harbour/src/rtl/gtdos/gtdos.c trunk/harbour/src/rtl/gtxwc/gtxwc.c trunk/harbour/src/vm/classes.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13804] trunk/harbour
Revision: 13804 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13804view=rev Author: vszakats Date: 2010-02-07 20:22:34 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 21:21 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/clipdefs.h + Added Clipper compatible legacy types to Clipper compatibility header. They are enabled when HB_LEGACY_TYPES_OFF is set. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/clipdefs.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] SF.net SVN: harbour-project:[13805] trunk/harbour
Revision: 13805 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13805view=rev Author: vszakats Date: 2010-02-07 21:36:26 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 22:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * bin/hb-mkimp.bat + Added support for Apollo 7. * utils/hbmk2/hbmk2.prg + Accepting '' and '||' as 'and' and 'or' operators. * examples/hbsqlit2/hbsqlit2.hbp * examples/hbapollo/hbapollo.hbp + HB_INC_* - HB_WITH_* * examples/hbapollo/apollo.c * examples/hbapollo/hbapollo.hbc + Added support for Apollo 7. + Version 6.1 can now be selected by defining HB_WITH_APOLLO_VER61 envvar. * examples/gtwvw/gtwvw.c * HB_LONG - HB_MAXINT Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/hb-mkimp.bat trunk/harbour/examples/gtwvw/gtwvw.c trunk/harbour/examples/hbapollo/apollo.c trunk/harbour/examples/hbapollo/hbapollo.hbc trunk/harbour/examples/hbapollo/hbapollo.hbp trunk/harbour/examples/hbsqlit2/hbsqlit2.hbp 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] Debugging c code
Przemek, I want to confirm something. I'm not yet using the new code you wrote, so bear with me here. If I allocate memory using hb_xgrab_fm() as you suggested before and then call p1 = hb_itemNew(p2) if I do not release p1 the line reported by FM statistics appears to be where hb_xgrab_fm() is called. This is what I believe I am seeing, can you confirm this? April -- With my last breath I spit at thee... 'The Wrath of Khan' ___ 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:[13805] trunk/harbour
Peeking into the header, there wasn't too much done to this piece of software in the last 6 years... Three new APIs, one new constant and no header portability bugs fixed. What a waste... I wish Harbour had the MACH6 engine. Brgds, Viktor On 2010 Feb 7, at 22:36, vszak...@users.sourceforge.net wrote: Revision: 13805 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13805view=rev Author: vszakats Date: 2010-02-07 21:36:26 + (Sun, 07 Feb 2010) Log Message: --- 2010-02-07 22:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * bin/hb-mkimp.bat + Added support for Apollo 7. * utils/hbmk2/hbmk2.prg + Accepting '' and '||' as 'and' and 'or' operators. * examples/hbsqlit2/hbsqlit2.hbp * examples/hbapollo/hbapollo.hbp + HB_INC_* - HB_WITH_* * examples/hbapollo/apollo.c * examples/hbapollo/hbapollo.hbc + Added support for Apollo 7. + Version 6.1 can now be selected by defining HB_WITH_APOLLO_VER61 envvar. * examples/gtwvw/gtwvw.c * HB_LONG - HB_MAXINT Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/hb-mkimp.bat trunk/harbour/examples/gtwvw/gtwvw.c trunk/harbour/examples/hbapollo/apollo.c trunk/harbour/examples/hbapollo/hbapollo.hbc trunk/harbour/examples/hbapollo/hbapollo.hbp trunk/harbour/examples/hbsqlit2/hbsqlit2.hbp 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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mysql test sample either compile in LINUX
Library was created without problems HBMysql , but hbm file name it as libmysql I think thats an error or need another library that i don't know which is Bruno 2010/2/7 Massimo Belgrano mbelgr...@deltain.it I don't know because i have lost my ubuntu virtual machine when you start make it display ! Component:mysql?? 2010/2/7 Bruno Luciani bruno.luci...@gmail.com: Is needed in linux ? Bruno 2010/2/7 Massimo Belgrano mbelgr...@deltain.it Have you used HB_WITH_MYSQL=/mysql/include -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13806] trunk/harbour
Revision: 13806 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13806view=rev Author: vszakats Date: 2010-02-08 01:18:46 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-07 02:02 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/pp/ppcore.c * src/vm/macro.c * src/vm/runner.c * src/vm/codebloc.c * src/vm/garbage.c * src/vm/hvm.c * src/vm/maindllp.c * src/vm/fm.c * src/vm/extrap.c * src/vm/memvars.c * src/common/expropt1.c * src/common/expropt2.c * src/common/hbarch.c * src/common/hbmem.c * src/nortl/nortl.c * src/rtl/gtdos/gtdos.c * src/rtl/gtwin/gtwin.c * src/rtl/gtxwc/gtxwc.h * src/rtl/gtxwc/gtxwc.c * src/rtl/gtcrs/gtcrs.c * src/rtl/gtstd/gtstd.c * src/rtl/gttrm/gttrm.c * src/rtl/gtcgi/gtcgi.c * src/rtl/gtapi.c * src/rtl/gtos2/gtos2.c * src/rtl/hbgtcore.c * src/rtl/gtsln/gtsln.c * src/rtl/gtsln/kbsln.c * src/rtl/gtsln/gtsln.h * src/rtl/gtpca/gtpca.c * src/rtl/gt_tpl/gt_tpl.c * src/rtl/gtwvt/gtwvt.h * src/rtl/gtwvt/gtwvt.c * src/rdd/dbfntx/dbfntx1.c * src/rdd/dbsql.c * src/rdd/hbdbsort.c * src/rdd/workarea.c * src/rdd/sdf1.c * src/rdd/dbfnsx/dbfnsx1.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/delim1.c * src/rdd/dbf1.c * src/rdd/hsx/hsx.c * src/rdd/usrrdd/usrrdd.c * src/rdd/dbffpt/dbffpt1.c * src/rdd/hbsix/sxsem.c * src/rdd/hbsix/sxcompr.c * src/compiler/ppcomp.c * src/compiler/hbmain.c * src/compiler/hbfix.c * src/compiler/hbdbginf.c * src/compiler/hbpcode.c * src/compiler/genhrb.c * src/compiler/hbdead.c * src/compiler/genobj32.c * src/compiler/genc.c * src/compiler/hbopt.c * src/compiler/gencc.c * src/compiler/hbcmplib.c * src/compiler/hblbl.c * src/compiler/harbour.yyc * src/compiler/harbour.y * src/compiler/harbour.yyh * tests/bldtest/bldtest.c * tests/tstgtapi.c * include/hbpp.h * include/hbrdddbf.h * include/hbvmpub.h * include/hbrddnsx.h * include/hbgtcore.h * include/hbxvm.h * include/hbdefs.h * include/hbmacro.h * include/hbtypes.h * include/hbrddsdf.h * include/hbapi.h * include/hbrddntx.h * include/hbvm.h * include/hbcomp.h * include/hbapirdd.h * include/hbcompdf.h * include/hbrdddel.h * include/hbexpra.c * include/hbexprop.h * include/hbdbf.h * include/hbdbsort.h * include/hbapigt.h * include/hbrddcdx.h * include/hbrddfpt.h * include/hbexprb.c * contrib/gtalleg/gtalleg.c * contrib/hbct/ctwin.c * contrib/hbct/ascpos.c * contrib/hbct/screen1.c * contrib/hbct/ctcrypt.c * contrib/xhb/hbxml.c * contrib/xhb/xhbis.c * contrib/xhb/fparse.c * contrib/xhb/xhbat.c * contrib/xhb/xhbcopyf.c * contrib/xhb/cstructc.c * contrib/hbqt/gtqtc/gtqtc.cpp * contrib/hbqt/gtqtc/gtqtc.h * contrib/xpp/philesx.c * contrib/hbnf/ftshadow.c * contrib/hbnf/ftattr.c * contrib/hbnetio/netiocli.c * contrib/hbnetio/netiosrv.c * contrib/rddsql/sddmy/mysqldd.c * contrib/rddsql/sddpg/pgsqldd.c * contrib/rddsql/sddfb/fbirddd.c * contrib/rddsql/sddodbc/odbcdd.c * contrib/rddsql/hbrddsql.h * contrib/rddsql/sqlbase.c * contrib/rddsql/sqlmix.c * contrib/gtwvg/gtwvg.c * contrib/gtwvg/wvggui.c * contrib/gtwvg/wvgcore.c * contrib/gtwvg/wvgwing.c * contrib/rddads/adsx.c * contrib/rddads/rddads.h * contrib/rddads/ads1.c * contrib/hbtip/utils.c * contrib/hbwin/win_regc.c * contrib/hbwin/win_prn2.c * contrib/hbbmcdx/bmdbfcdx.c * contrib/hbbmcdx/hbbmcdx.h * contrib/hbbtree/hb_btree.c * BYTE - HB_BYTE except where BYTE was used in OS-specific context. * Some formatting. ; I didn't realign structure definitions in hbrdd*.h yet. * contrib/hbwin/win_regc.c * Minor type cleanup. * src/rtl/gt_tpl/gt_tpl.c * BYTE - int for color. * examples/hbapollo/apollo.c % Deleted MAX_STR_LEN. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtalleg/gtalleg.c trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/contrib/gtwvg/wvgcore.c trunk/harbour/contrib/gtwvg/wvggui.c trunk/harbour/contrib/gtwvg/wvgwing.c trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/hbbmcdx/hbbmcdx.h trunk/harbour/contrib/hbbtree/hb_btree.c trunk/harbour/contrib/hbct/ascpos.c trunk/harbour/contrib/hbct/ctcrypt.c trunk/harbour/contrib/hbct/ctwin.c trunk/harbour/contrib/hbct/screen1.c trunk/harbour/contrib/hbnetio/netiocli.c trunk/harbour/contrib/hbnetio/netiosrv.c trunk/harbour/contrib/hbnf/ftattr.c trunk/harbour/contrib/hbnf/ftshadow.c trunk/harbour/contrib/hbqt/gtqtc/gtqtc.cpp trunk/harbour/contrib/hbqt/gtqtc/gtqtc.h trunk/harbour/contrib/hbtip/utils.c trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/contrib/hbwin/win_regc.c trunk/harbour/contrib/rddads/ads1.c trunk/harbour/contrib/rddads/adsx.c trunk/harbour/contrib/rddads/rddads.h trunk/harbour/contrib/rddsql/hbrddsql.h trunk/harbour/contrib/rddsql/sddfb/fbirddd.c
Re: [Harbour] SF.net SVN: harbour-project:[13796] trunk/harbour
Hi Przemek and All, I think the first thing should be to define our existing char types: HB_UCHAR HB_SCHAR HB_WCHAR HB_BYTE / BYTE char USHORT I'm having a try to collect what we know about char/byte types: - HB_UCHAR: Similar to HB_BYTE. Was introduced to avoid signedness problems when using legacy type BYTE. - HB_SCHAR: Used in just a few places, signed HB_UCHAR. - HB_WCHAR: 16-bit UNICODE char (this is the only one I'm certain of) - HB_BYTE: Similar to HB_UCHAR, non-textual data streams, PCODEs, data stored on disk. - BYTE (deprecated): Similar to HB_BYTE but with non-guaranteed signedness. - char: generic text, 8-bit or UTF-8, PCODEs (wrongly used). Signedness non-guaranteed. - unsigned char: Similar to HB_UCHAR - HB_USHORT: Text character in GT API. Maybe used because low level interface may accept 8-16 bit chars. But even then hbapigt.h shouldn't use this type. - HB_I8: I estimate this won't be used too often in practice. - HB_U8: Seems to be interchangeable with HB_BYTE/HB_UCHAR, on systems where char is 8 bit, but could be useful for disk structures on systems where it's not. This of course needs that we start using those f.e. in RDD code. Questions: - Shouldn't we change HB_USHORT to something else in GT API? - Now that we define our own HB_BYTE, and it's guaranteed to be unsigned, isn't it equivalent to HB_UCHAR? (if not see next) - What is the difference between HB_BYTE/HB_UCHAR? Where should we use which? If they are equivalent, which should be chosen as the one? So far my conclusion is that HB_BYTE is superfluous and could be replaced by HB_UCHAR everywhere in code, except for disk structures where it should be replaced with HB_U8. 'unsigned char' should also be changed to HB_UCHAR. Or perhaps the cleanest and simplest way would be to stick to HB_BYTE and HB_CHAR (since signedness is now guaranteed) for in-memory usage, and HB_U8 for externally stored data, and drop HB_UCHAR, HB_SCHAR. BYTE/CHAR are much familiar names, and most of or code uses these terms. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi, ... I wonder if it's possible to fix this function to not be sensitive on this setting. Any idea? Yes, of course. ??? :) I can fix this without ASM, but a bad use of these functions always cause GPF. -- Xavi El 06/02/2010 18:37, Viktor Szakáts escribió: Hi Xavi, Very good point. I can add ugly hack to makefiles to always keep frame pointers for mingw in hbwin lib to make hb_DynaCall() function happy, but I wonder if it's possible to fix this function to not be sensitive on this setting. Any idea? Brgds, Viktor On 2010 Feb 6, at 17:41, Xavi wrote: Hi, I guess that is because hbwin is compiled with -fomit-frame-pointer. Try copy win_dll.c to the folder tests and compiled with .- hbmk2 testdll.prg win_dll.c -lstdc++ -debug Ok, I've only tested with gcc-dw2.exe -- Xavi El 06/02/2010 15:19, Fernando Athayde escribió: really don´t runs causes GPF i am using #include hbdll.ch hdll:=dllload(EZTW32.DLL) dllcall(hdll,DC_CALL_STD,TWAIN_SelectImageSource,::oFormCadastro:handle,) dllcall(hdll,DC_CALL_STD,TWAIN_AcquireToFilename,::oFormCadastro:handle,file.bmp) freelibrary(hdll) Best Regards, Fernando Athayde *De:* Itamar Linsitamarl...@gmail.com *Para:* harbour@harbour-project.org *Enviadas:* Sábado, 6 de Fevereiro de 2010 10:10:57 *Assunto:* [Harbour] MinGW dllcall function not run. Hi! sorry to insist on that but there is a possibility to make it work with him. I need to take MinGW. Best regards, Itamar M. Lins Jr. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
