On Mon, Oct 13, 2008 at 10:10 PM, Przemyslaw Czerpak [EMAIL PROTECTED] wrote:
Very nice peace of code which is also very good start point for
multi RDBMS RDD API. I'll look closer into it in spare time.
Lorenzo asked about common OOP interface for different RDBMS
and this is rather starting
2008-10-14 08:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* contrib/examples/dbu/bld_vc.bat
! Removed -TP C option.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
-Messaggio Originale-
Da: Przemyslaw Czerpak [EMAIL PROTECTED]
A: harbour@harbour-project.org
Data invio: martedì 14 ottobre 2008 0.02
Oggetto: [Harbour] 2008-10-14 00:02 UTC+0200 Przemyslaw
Czerpak(druzus/at/priv.onet.pl)
2008-10-14 00:02 UTC+0200 Przemyslaw Czerpak
-Messaggio Originale-
Da: Szakáts Viktor [EMAIL PROTECTED]
A: Harbour Project Main Developer List. harbour@harbour-project.org
Data invio: martedì 14 ottobre 2008 1.53
Oggetto: Re: [Harbour] Macro to block conversion function
I'm looking for a function replacement
for this
I really don't see what's the difference between
bBlock := ( {|| + cExpr + } )
and
bBlock := hb_macroCompile( {|| + cExpr + } )
No! if i understand Przemek, the new syntax is :
bBlock := hb_macroBlock( cExpr )
and there are only 2 characters more, but easier to type.
Guy
-Messaggio Originale-
Da: Szakáts Viktor [EMAIL PROTECTED]
A: Harbour Project Main Developer List. harbour@harbour-project.org
Data invio: martedì 14 ottobre 2008 9.49
Oggetto: Re: [Harbour] Macro to block conversion function
Nothing. Though, we've been talking about this
To all
Lorenzo Fiorini wrote:
Today we have hbodbc, hbmysql, hbpgsql, hbfbird contrib libs and
probably more in the future.
Their pourpose is to connect Harbour to SQL databases but they use
different ( class ) interfaces.
I would venture that many Harbour programmers use these SQL databases
Compliment you have made point six of your todo
6, HB_LIBLOAD()/__HRBLOAD() may not be MT safe in some cases.
Before they will not be resolved please try to not use this
functions when other threads are executed.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
On Tue, 14 Oct 2008, Alex Strickland wrote:
Hi Alex,
Sockets appear to me to be reliable in Harbour but I think Przemek has
alluded to problems with them? I don't know what they are. I know ADS uses
UDP, I'm not sure why.
Now the biggest problem is lack of C level API and some missing
Hi Przemek,
bBlock := hb_macroCompile( {|| + cExpr + } )
Nothing. Though, we've been talking about this expression: :)
bBlock := hb_macroCompile( cExpr )
other than that you have to type more characters. I don't know if
there is
a speed concern but the first expression is idiomatic for a
Hi Przemek,
2. DEBUGGER is not MT safe. Now do not use debugger in code with
more then one thread active or it will crash.
Before we will touch this code please think how MT debugger
should
work.
I've run into this be accident just yesterday. I've
compiled my app with -b
Hi Przemek,
Think about it but base type checking should not be touched.
Otherwise IMO we should remove it at all because it stops to
give expected RT protection and we can keep it as source code
decoration just like in xHarbour.
Remove no. This is a nice feature and help me to find some hidden
Perfect and many thanks, I'll try it out a bit later today.
Brgds,
Viktor
On 2008.10.14., at 11:51, Przemyslaw Czerpak wrote:
2008-10-14 11:51 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapi.h
* harbour/source/vm/macro.c
* added missing const attribute to
Wich is best tools/way for recover a damaged dbf cdx ?
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Przemyslaw Czerpak wrote:
In the moment when you run thread with higher then normal priority
you can kill multitasking. To make it weel you have to know what
Ok, this goes to the programmer responsability, I can kill a system in a lot
of ways as soon as I start writing something :)
exactly
Przemyslaw Czerpak wrote:
* harbour/source/vm/dynlibhb.c
+ added support for DLL loading/unloading in OS2 builds.
Based on xHarbour code by Maurilio Longo - please test.
Przemyslaw,
I've never loaded pcode .DLLs on OS/2, I don't even know how to build one, but
on xHarbour I'm
Szakáts Viktor wrote:
I wouldn't make it overly complicated, as I wrote in
one of the mails, probably an IDLE, NORMAL, HIGHER
level would be enough. Of course there is the task
to tune these to give similar feels under different
OSes, which may be a bit of a problem, at least for
HIGHER.
2008-10-14 19:23 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbextern.ch
+ Added hb_macroBlock()
* source/rtl/langapi.c
* One error text changed to be more precise.
* doc/gmake.txt
* bin/bld.bat
* contrib/hbbtree/tests/bld_vc.bat
* contrib/examples/pp/bld_vc.bat
Hi again,
- Original Message -
From: Petr Chornyj [EMAIL PROTECTED]
To: harbour@harbour-project.org
Sent: Tuesday, October 14, 2008 6:48 PM
Subject: Re: Re: [Harbour] Inconsistency in DATA Types
[EMAIL PROTECTED] wrote:
BTW I can change empty codeblock datas from nil to {||nil}
Viktor, Przemyslaw,
Szakáts Viktor wrote:
3. Thread priorities - is it really necessary?
IMO, it would be useful. No real life personal need
yet from my side, but I could imagine using IDLE
initially, and maybe even more levels for a server-side
app.
I use them in a couple of sources to
Nice job.
Brgds,
Viktor
void hb_socketInit( void );
void hb_socketCleanup( void );
PHB_ITEM hb_socketNew( int iTimeOut );
int hb_socketClose( PHB_ITEM pSocket );
FHANDLE hb_socketHandle( PHB_ITEM pSocket );
int hb_socketStatus( PHB_ITEM pSocket );
int
On Tue, 14 Oct 2008, Maurilio Longo wrote:
Hi Maurilio,
Ok, this goes to the programmer responsability, I can kill a system in a lot
of ways as soon as I start writing something :)
But in this case the same program can works in different way on
different OSes so it stop to be portable.
I've tried it now live, and also with invalid
code (it returns NIL) and it's working perfectly,
just as I've expected.
Thanks a lot Przemek.
Brgds,
Viktor
On 2008.10.14., at 11:51, Przemyslaw Czerpak wrote:
2008-10-14 11:51 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
*
[EMAIL PROTECTED] wrote:
IMHO codeblock types can receive nil to easy checking, like:
if !( oClass:bDraw == nil )
Eval( oClass:bDraw )
endif
I agree with you, but I also think other types of variables should
accept NIL as well.
Regards
Alex
2008-10-14 20:36 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/rtl/dbedit.prg
* source/rtl/tgetint.prg
* source/rtl/tlabel.prg
* source/rtl/treport.prg
* Changed '( {|| + c + } )' expressions to
hb_macroBlock() calls.
To me these places seemed safe to change, but
Why you can't check it as
if hb_IsBlock( oClass:bDraw )
Eval( oClass:bDraw )
endif
Hi Petr,
This is exactly the problem: I have a codeblock, but sometimes I need
set it to nil and I can´t due data type protection. So now I´m
converting all calls to:
oClass:bDraw = {||nil}
and always I
so I'd prefer sth different what will keep current PP syntax.
Even such minor modification resolved the problem.
DATA bDraw AS ?CODEBLOCK INIT nil
But we can also use sth what will allow to mix types, f.e.:
DATA bDraw AS CODEBLOCK | NIL
or we can support additionally: AS {type [,type]},
On Tue, 14 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
I've reduced the problem to this:
--- test.prg
PROC MAIN()
TESTCALL()
#pragma BEGINDUMP
HB_FUNC( TESTCALL )
{
}
#pragma ENDDUMP
This is happening with MSVS2008 32-bit. _only_
when linking hbvmmt _and_ using -b Harbour switch.
[EMAIL PROTECTED] wrote:
BTW I can change empty codeblock datas from nil to {||nil} and eval it
always, instead check it.
Why you can't check it as
if hb_IsBlock( oClass:bDraw )
Eval( oClass:bDraw )
endif
Regards,
Petr
--
View this message in context:
On Tue, 14 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
I really don't see what's the difference between
bBlock := ( {|| + cExpr + } )
and
bBlock := hb_macroCompile( {|| + cExpr + } )
Nothing. Though, we've been talking about this expression: :)
bBlock := hb_macroCompile( cExpr )
other than
I use many Oracle databases via Mediator Server and via Ado with
xHarbour.
And I'm waited to HDBC with acces (directly via OCI, without agent) to
Oracle from Harbour.
What performance of mediator,ado?
___
Harbour mailing list
On Tue, 14 Oct 2008, Massimo Belgrano wrote:
Hi Massimo,
Compliment you have made point six of your todo
6, HB_LIBLOAD()/__HRBLOAD() may not be MT safe in some cases.
Before they will not be resolved please try to not use this
functions when other threads are executed.
Not
On Tue, 14 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
Yes, hb_macroBlock() is faster. The difference depends on
macro body. For very simplt macros, f.e. .T. it's:
empty loop overhead: 0.09
macro compilation: 2.44
hb_macroblock: 1.43
For more complex macros
On Tue, 14 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
[...]
When I turned off debugging, the problem went away.
If you want, I can redo some tests to make the
circumstances cleaner.
I'll look at it. If I will not be able to isolate the
problem then I'll ask you for help.
TODO:
1. We
I also vote for adding this code to the contrib lib
IMO is possible:
add a Driver Structure with ability to be loaded at runtime .
And a class for complete access to DMBS merging actual (hbodbc, hbmysql,
hbpgsql, hbfbird) contrib libs?
About The rdd syntax the insert, update,
can be made Update
Hi Przemek,
I'm sorry but I'm not able to replicate it. The only one problem
I finally created was after compiling hbdebug library with -b
parameter. Otherwise it works as expected.
Just a few questions. Maybe I'll guess what's wrong.
Is it necessary to declare TESTCALL() inside #pragma
Date: Mon, 13 Oct 2008 11:16:41 -0300
From: Rodrigo Miguel [EMAIL PROTECTED]
Subject: [Harbour] Re: A standard for the Harbour's SQL libs Click to
flag this post
...
Hi Lorenzo,
I wrote some OCI oracle native code, that's a working code, but need
...
by Lorenzo Fiorini-2 Oct 11, 2008; 02:59pm ::
On Tue, 14 Oct 2008, [EMAIL PROTECTED] wrote:
Hi Toninho,
I don´t know if this is an feature or a problem. If I have
DATA bDraw AS CODEBLOCK INIT nil
INIT clause is unprotected and allow to assign any value with
declared type respecting.
bDraw accept NIL without problem, but I can´t set it
Hi folks,
I don´t know if this is an feature or a problem. If I have
DATA bDraw AS CODEBLOCK INIT nil
bDraw accept NIL without problem, but I can´t set it to nil again. If
I do:
oClass:bDraw = nil
I receive an error.
IMHO codeblock types can receive nil to easy checking, like:
if !(
Can i remember multi windows gt?
- Messaggio originale -
Da: Przemyslaw Czerpak [EMAIL PROTECTED]
Inviato: martedì 14 ottobre 2008 12.55
A: Harbour Project Main Developer List. harbour@harbour-project.org
Oggetto: Re: RE: [Harbour] 2008-10-13 20:21 UTC+0200
2008-10-14 11:51 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapi.h
* harbour/source/vm/macro.c
* added missing const attribute to hb_macroCompile() parameter
+ added new .prg function:
hb_macroBlock( cExpr ) - bCode
which converts macro
Hi Toninho, and all
to elaborate on this, it might be a good idea to introduce syntax for
nullable (nilable) types, just like in C#
it would suffice to assert a declaration with type info, followed by a
question mark
DATA bDraw AS CODEBLOCK? INIT nil
Then this var can be set to a CODEBLOCK or
2008-10-15 00:31 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbxvm.h
* harbour/source/vm/hvm.c
- removed to unused functions
* harbour/source/vm/thread.c
- removed unnecessary casting
best regards
Przemek
___
On Tue, 14 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
To me the culprit seems to be the INITLINES logic.
If I disable line numbers with -l, it will start to
work with MSVS. But not with BCC.
Your results suggest that the problem is not related to MT mode.
It's rather caused by debugger
Hi Przemek,
Unfortunately I cannot reproduce the problem myself. It may be
caused by different order of startup code execution in compilers
you are using.
If possible please try to use CodeGuard in BCC build. It should
catch the place where this code fails.
Also if possible please check if the
2008-10-15 01:04 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/debug/dbgtobj.prg
* source/debug/dbgbrwsr.prg
* source/debug/dbgtwin.prg
* source/debug/dbgmenu.prg
* source/debug/dbgthsh.prg
* source/debug/tbrwtext.prg
* source/debug/dbgwa.prg
* source/debug/debugger.prg
On Wed, 15 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
I have no CodeGuard unfortunately. I didn't debug Harbour
since 8 years, but I'll try to find something out.
I've found it.
To repeat the problem is necessary to have some the startup
code execution order like in Windows/DOS.
2008-10-15 01:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/hvm.c
! clear HVM stack return value before use in initialization code
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
2008-10-15 01:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/debug/dbgtobj.prg
* source/debug/dbgbrwsr.prg
* source/debug/dbgtwin.prg
* source/debug/dbgmenu.prg
* source/debug/dbgthsh.prg
* source/debug/tbrwtext.prg
* source/debug/dbgwa.prg
* source/debug/debugger.prg
Hi Przemek,
I confirm that it's working now (tested with MSVS2008).
Brgds,
Viktor
On 2008.10.15., at 1:39, Przemyslaw Czerpak wrote:
2008-10-15 01:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/hvm.c
! clear HVM stack return value before use in initialization
On Wed, 15 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
I'll simply add -b- to Harbour core flags then.
Since I don't think identifying all those parts
would be a maintainable option.
Maybe it will be better to not have any -b? flags.
If someone will want to debug some part of Harbour
then he
2008-10-15 02:33 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/rtl/langapi.c
* utils/hbtest/rt_class.prg
* Cleanup to previous modif.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
52 matches
Mail list logo
