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
http://lists.harbour-project.org
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 h
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
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
I had a feeling like this :)
I'll simply add -b- to Harbour core flags then.
Since I don't think identifying all those parts
would be a maintainable option.
[ In this case, maybe it's safe to delete
HB_NO_READDBG option, as our GET system
will always work from the debugger. If someone
wants to d
2008-10-15 01:40 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
- lib/b32
- lib/vc
- bin/b32
- bin/vc
- obj/b32
- obj/vc
- Removed dirs from SVN. They are automatically created
by the build scripts.
--
Brgds,
Viktor
___
Harbour mai
On Wed, 15 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
> + Added '#pragma DEBUGINFO=OFF' to debugger
> sources. Otherwise compiling full Harbour with
> -b was causing an infinite loop. (this is now
> the default when building with
> 'HB_BUILD_DEBUG=yes'.
It's not e
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
http://lists.
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.
_INITLINES
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
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 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
___
Har
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 a
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 BEGIN
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 swi
>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
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,
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)
* harbour/inclu
Hi again,
- Original Message -
From: "Petr Chornyj" <[EMAIL PROTECTED]>
To:
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} and eval it
always, instea
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 Przemek,
I've reduced the problem to this:
--- make.bat
> C:\devl\hbvc-1.1\bin\harbour test.prg -n -b
> cl -IC:\devl\hbvc-1.1\include test.c /link /subsystem:CONSOLE /
LIBPATH:C:\devl\hbvc-1.1\lib shell32.lib hbcpage.lib hbdebug.lib
hbvmmt.lib hbrtl.lib gtcgi.lib gtgui.lib gtpca.lib gtstd.l
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
> HIGH
[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:
http://www.nabble
Hi Przemek,
Ok, so let's say we have PRI_IDLE, but as soon as we can go down a
step we
need a way to go up a step to return to the regular class of
priority and so
we have PRI_REGULAR.
This is not a problem of changing priority (though even this is OS
dependent and some things will not b
Hi Przemek,
I was documenting some RDDI_* actions in xHarbour ChangeLog.
Just like many other RDD extensions. If someone can collect
them in one peace of documentation then it will be nice.
I've now got more time and found them in dbinfo.ch.
Well, you probably know better which one should be
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.
> >
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
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
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
On Tue, 14 Oct 2008, Przemyslaw Czerpak 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.
I
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.
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 hidd
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 hb_socketErrorCode
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 sourc
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 { [,]}, f.e.:
DATA
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
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
fu
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 i
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.
Oggetto: Re: RE: [Harbour] 2008-10-13 20:21 UTC+0200
PrzemyslawCzerpak(druzus/at/priv.onet.pl)
On Tue, 14 Oc
[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
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
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 !( oClass:b
>From: "Massimo Belgrano" <[EMAIL PROTECTED]>
...
>
>What performance of mediator,ado?
When I use transference data from DBF, it is slow than dbf's (very
slow), but when data are "pure sql", then it is fast and very
comfortable in use. Via Mediator we can be use data this and/or this
(sql and xBas
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
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.
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, 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 co
>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
Harbour@harbour-project
>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; 0
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 hb_m
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 B
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( ) ->
which converts macro expression to c
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
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(
-Messaggio Originale-
Da: "Szakáts Viktor" <[EMAIL PROTECTED]>
A: "Harbour Project Main Developer List."
Data invio: martedì 14 ottobre 2008 9.49
Oggetto: Re: [Harbour] Macro to block conversion function
Nothing. Though, we've been talking about this expression: :)
bBlock := hb_macr
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
__
Hi Enrico,
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 that you have to type more char
-Messaggio Originale-
Da: "Szakáts Viktor" <[EMAIL PROTECTED]>
A: "Harbour Project Main Developer List."
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 construct:
bBlock := &( "{||"
-Messaggio Originale-
Da: "Przemyslaw Czerpak" <[EMAIL PROTECTED]>
A:
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 (druzus/at/priv.onet.pl)
* harbour/s
59 matches
Mail list logo
