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
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
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
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
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
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.
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
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, 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.
to:[EMAIL PROTECTED] On Behalf Of Przemyslaw
Czerpak
Sent: Monday, October 13, 2008 8:22 PM
To: harbour@harbour-project.org
Subject: [Harbour] 2008-10-13 20:21 UTC+0200 Przemyslaw
Czerpak(druzus/at/priv.onet.pl)
2008-10-13 20:21 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/s
2008-10-13 20:21 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/rdd/wacore.c
; updated comments about xbase++ behavior in dbRelease()
* harbour/include/hbvm.h
* harbour/source/vm/hvm.c
* harbour/source/vm/dynlibhb.c
* harbour/source/vm/runner.c
! added MT p
19 matches
Mail list logo
