On Tue, 08 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> I expected not to fail in gtos2 and gtstd, but as gtstd failed, I
> checked files and made confirmations to be sure, and at last I added
> "config\os2\watcom.mk" content in message for clarity
Thank you very much.
> >It also means tha
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> > I do not see any reason to break using GTOS2 in MT mode waiting for
> > OpenWatcom fix so I would like to keep current hack until it will
> > not be fixed in OW.
> In your prev mail you told that full removal
> of -s also doesn't help on watcom
>> Okay, that clears it up. So in essence OpenWatcom for OS/2
>> is broken whatever we do in Harbour.
>> [ In this case though, we may safely readd -s for all modules,
>> thus deleting our little hack and wait for Watcom team to fix it. ]
>
> I do not see any reason to break using GTOS2 in MT mod
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> Okay, that clears it up. So in essence OpenWatcom for OS/2
> is broken whatever we do in Harbour.
> [ In this case though, we may safely readd -s for all modules,
> thus deleting our little hack and wait for Watcom team to fix it. ]
I do not see
>> I've just seen David's latest tests... IMO if there
>> is no reasonable solution for it, removing -s could
>> still be a fallback option, for the reason that
>> watcom/os2 is not a primary target, I mean no one
>> seems to use it for production, in practice we need it
>> only for cross-plat
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> I've just seen David's latest tests... IMO if there
> is no reasonable solution for it, removing -s could
> still be a fallback option, for the reason that
> watcom/os2 is not a primary target, I mean no one
> seems to use it for production, in
On Mon, 07 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> Harbour 13153
> config\os2\watcom.mk contain:
>ifeq ($(filter $(LIBNAME),gtos2 gtstd),)
> CFLAGS += -s
>endif
Have you made clean Harbour build?
> [E:\harbour911b\harbour\bin\os2\watcom]hbmk2 speedtst -l -kmo -mt
> -gc3
>> So how about removing -s switch altogether for watcom/os2
>> in both our make system and hbmk2?
>
> No. It's not necessary to touch hbmk2.
>
>> For the reason that a slightly slower, but working app is
>> better than a failing app.
>
> This slight slower means over 3 times slower.
> -s disa
On Sun, 06 Dec 2009, Szak�ts Viktor wrote:
Hi,
> So how about removing -s switch altogether for watcom/os2
> in both our make system and hbmk2?
No. It's not necessary to touch hbmk2.
> For the reason that a slightly slower, but working app is
> better than a failing app.
This slight slower m
On Sun, 06 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> With Harbour 13140:
> [E:\harbour911b\harbour\bin\os2\watcom]hbmk2 speedtst -l -kmo -mt
> -gc3 -gtos2
> Harbour 2.0.0beta3 (Rev. 13140)
> Copyright (c) 1999-2010, http://www.harbour-project.org/
> Compiling 'speedtst.prg'...
> Lines 120
So how about removing -s switch altogether for watcom/os2
in both our make system and hbmk2?
For the reason that a slightly slower, but working app is
better than a failing app.
Brgds,
Viktor
On 2009 Dec 6, at 11:26, David Arturo Macias Corona wrote:
> Przemek:
>
> >> "-s" is used to avoid "
On Sat, 05 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> "-s" is used to avoid "stack overflow checking", as OpenWatcom doc state:
[...]
I know what it does ;-)
> I am unsure if switchs changes must be managed in hbmk2.prg too
it's necessary only for C code calling APIENTRY16 functions.
In
>> linked with GTSTD, i.e.:
>> hbmk2 speedtst.prg -l -kmo -gc3 -gtstd
>> Such information may be important for OpenWatcom developers.
>
> Harbour 13130 or 13131 ?
They are currently equivalent.
Brgds,
Viktor
___
Harbour mailing list (attachment size
On Sat, 05 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> From previous tests only -s removed avoid GPF
> A year ago -sg increased run time, but today we have new Harbour and new
> OpenWatcom
Harbour code does not make any difference in this problem.
It's only OpenWatcom bug.
So the only one
On Wed, 02 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> Now below are tests with only src\rtl\gtos2\Makefile adding:
> HB_BUILD_OPTIM := no
> Tests with
> speedtst.exe --thread ...
> does not fail with GPF
Thank you very much. This is what I wanted to see :-)
So all what we have to do i
On Tue, 01 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> >Thank you very much. So now we know that we can remove -s as
> >workaround. Unfortunately it causes very big speed overhead. Much
> >bigger then in Linux where removing -s reduce the speed only ~24
> >percent. It's 363% what is even bi
On Fri, 27 Nov 2009, David Arturo Macias Corona wrote:
Hi,
> Here is the summary
> If you want detailed results for each case let me know
> Harbour 13035
> OpenWatcom 1.8
> Below are results using:
>
>hbmk2 -m -n -w -es2 -l -kmo -gc3 speedtst.prg
> speedtst.exe
On Fri, 27 Nov 2009, David Arturo Macias Corona wrote:
Hi,
> As a summary:
> - OS/2-Watcom was failing with GPF in MT mode
> - Tests lead us to devices input problem (keyboard, mouse, ...) on
> threads except 1
Exactly.
> - Maurilio made tests changing switchs and it work for him, removing -s
>
Thanks for the answers.
> >so linker problems which you try to workaround using WLINK are not
> >proper/final solutions we should implement in Harbour. Instead, you
> >should report these problems to port maintainers for fix. (if it's >really
> a showstopper).
>
> As OMF can use many "final linke
Sorry, but I've been asking some specific questions and now you
begin with a long tirade starting from 1999.
Let's cut it short:
Please correct me, if I'm wrong:
- There is 3.3.4 and lower, supporting COFF (or whatever else, let's
call it non-OMF)
- There is 3.3.5, which supports both OMF and
>Case closed from my side.
You misread again
Just to clarify it, along time on some of your responses you tend to
suggest that I am against your work and that is not true. How easily
jumped in when seeing a different POV
Only avoid these suggestions, somebody may believe it is true and I
Viktor Szakáts wrote:
Yes I know you do not want any new value in Harbour build scheme, but we
need only one to inform Harbour that we are building with alternative
library format in OS/2 platform
Does not need any specification of gcc3 or gcc4 as you think
No new value? Perhaps you missed the
[...] so still gcc3/gcc4 compiler names are better here.
I was thinking this matter had been completely clarified: we do not
need
gcc3/gcc4 separation
Along these messages I have seen how misunderstandings come again and
again even after they have been explained
You confused much of the expl
I do not see two-fold as layout messy
In Harbour we have added, deleted, moved directories oftenly
Yes, to avoid mess :)
First mt is solved as subdir even in vm lib. Second we may
have other extra versions of .dll, such flat layout is IMO
very limiting and inelegant.
And for additional objects
Thank you.
Brgds,
Viktor
On 2009.09.08., at 11:37, David Arturo Macias Corona wrote:
Thanks Viktor
>Pls try with 12439.
It work fine now
David Macias
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman
On Mon, 17 Aug 2009, David Arturo Macias Corona wrote:
Hi David,
> First try with gcc 4.x.x and OpenWatcom wlink.exe as linker
[...]
> Downloading wl-hll-r1.zip wl.exe show:
> --
> [E:\wl-hll-r1]wl
> ** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 1.6beta1 Limited
> A
>I don't agree with all the verbose output, but as I said
>you can enable it locally if you need them, please test if
>it works, if not we need to fix it.
I do not found use of HB_USER_MKFLAGS, so I used
set HB_USER_MAKEFLAGS=-w
Yes, my mistake. It's best to refer to docs (INSTALL) rather
than
I don't agree with all the verbose output, but as I said
you can enable it locally if you need them, please test if
it works, if not we need to fix it.
As for .tds, I intentionally didn't create difference
in logic for different shells, specifically to help cross
build scenarios. f.e. bcc can be
On Wed, 12 Aug 2009, David Arturo Macias Corona wrote:
Hi,
>> This seems to be problem we had in the past. HBRUN used some code which
>> causes such effect but I do not remember what it was. It's also
>> possible that I'm wrong and it's new problem.
>> Anyhow we will have to locate it.
>> Do othe
Thank you. It was explicitly invoking the shell command processor
to launch the shell commands. Probably much better to use $(shell)
command in case such forced shell invocation is to be used, but
these weren't such cases.
I only guess but IMO it was workaround for older GNU make versions
which
On Wed, 12 Aug 2009, Szak�ts Viktor wrote:
Hi,
> Thank you. It was explicitly invoking the shell command processor
> to launch the shell commands. Probably much better to use $(shell)
> command in case such forced shell invocation is to be used, but
> these weren't such cases.
I only guess but I
>; QUESTION: Could an OS/2 user tell me whether $(CMDPREF) is
>*really* needed? This is the only place it's used,
>so I wonder. If not, we should delete it.
I do not know what $(CMDPREF) mean or what it does
In current builds I do not see any difference
Thank
On Tue, 11 Aug 2009, David Arturo Macias Corona wrote:
Hi David,
> This is an updated report:
> Current Harbour under OS/2
> * $Id: ChangeLog 12055 2009-08-11 07:57:13Z vszakats $
> 2009-08-11 09:55 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> a) gcc (GCC) 3.3.5 (Bird Build 2006-03-18 05:37
On Mon, 10 Aug 2009, David Arturo Macias Corona wrote:
Hi David,
> Przemek:
> - having the sources and possibility to rebuild os2make381, have some
> benefit ?
> - The problem is with os2make381, and/or OS/2 command shell (CMD.exe) ? If
> later, can we use other ?
> - Is any other kind of envir
On Fri, 31 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> >If it still generates GPF then you can finally try sth like:
> >define create_library
> >echo $(LIB_DIR)/$@ > __lib__.tmp
> >$(if $(wordlist 1, 10,$(^F)), echo $(wordlist 1, 10,$(addprefix
> >-+,$(^F))) >> __lib__.tmp,)
> >$(if $(
On Fri, 31 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> Current Harbour under OS/2
> * $Id: ChangeLog 11949 2009-07-31 11:21:30Z druzus $
> 2009-07-31 13:21 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> It fail with:
>
> and make_ow.log contain:
> -
On Fri, 31 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> >This looks like side effect caused by results of some previous builds.
> >It's possible that if you clean all files left by previous builds then
> >above warnings disappear. If it will not help then I would like to see
> >whole log fil
On Thu, 30 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> >Try to replace:
> > LD_RULE = $(link_exe_file) $(HB_USER_LDFLAGS)
> >with:
> > empty:=
> > space:= $(empty) $(empty)
> > comma:= ,
> > LDFILES = $(subst $(space),$(comma) ,$(^F))
> > LDLIBS = $(subst $(space),$(comma) ,$(s
On Thu, 30 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> But using your change:
>for %i in ( *$(OBJ_EXT) ) do @echo -+%i >> __lib__.tmp
> build fine
> I think problem is some kind of limit in make.exe, and/or Watcom
It's not related to Watcom because also gcc.cf needs such trick so I gue
On Thu, 30 Jul 2009, David Arturo Macias Corona wrote:
> First try with current Harbour and OpenWatcom 1.8 under OS/2
Have you tried to run OS2 OpenWatcom binaries created on other OS?
I.e. in Windows or Linux?
> * $Id: ChangeLog 11922 2009-07-29 03:20:01Z druzus $
> 2009-07-29 05:19 UTC+0200
>Okay, the larger one is the static build, the smaller uses
>external libs. I'd opt for the static build as it has higher
>chances to work on all OS/2 systems, unless this is a non-issue
>on OS/2 systems. What do you think?
I do not think we should include make.exe or any other in SVN
Use of any
Hi David,
For hbpp.exe fail but not for harbour.exe, hbrun.exe, hbtest.exe, ...
For hbpp.exe are missing ..\..\bin\os2 review/creation, as shown in
make_gnu.log:
Okay, I see now what is the problem, will attempt a fix.
>BTW, I've found a GNU Make 3.81 different from your builds,
>maybe you
Any followup on the GNU Make problems?
Brgds,
Viktor
On 2009.07.29., at 10:22, David Arturo Macias Corona wrote:
2009-07-29 05:19 UTC+0200 Przemyslaw Czerpak (druzus/at/
priv.onet.pl)
gcc (GCC) 3.3.5 (Bird Build 2006-03-18 05:37)
eCS
Harbour under OS/2 build entirely with just well kno
On Tue, 28 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> Good progress
>2009-07-28 18:54 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
>gcc (GCC) 3.3.5 (Bird Build 2006-03-18 05:37)
>eCS
> ../../../hbsocket.c: In function `hb_socketInetAddr':
> ../../../hbsocket.c:1391: war
On Fri, 14 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> I did one more test and I've found that -bm has a great impact, on memory
> mostly, speedtst ST:
> T029 with -bm 22 sec.
> T030 with -bm 25 sec.
> T029 w/o -bm 1.6 sec.
> T030 w/o -bm 2.0 sec.
Exactly. It has horrible performance impact w
I did one more test and I've found that -bm has a great impact, on memory
mostly, speedtst ST:
T029 with -bm 22 sec.
T030 with -bm 25 sec.
T029 w/o -bm 1.6 sec.
T030 w/o -bm 2.0 sec.
Best regards.
Maurilio.
PS. speedtst MT takes nearly twice.
Maurilio Longo wrote:
> Przemyslaw, David,
>
> B
Przemyslaw, David,
BTW, from watcom docs I read:
The "bm" option must be specified since we are creating a multi-threaded
application. If your multi-threaded application contains more than one module,
each module must be compiled using the "bm" switch.
So, it is not enough to buil hbvmmt with bm
Przemyslaw, David,
David Arturo Macias Corona wrote:
>
> We can ignore -5[r], -fp5, -6[r], -fp6
>
I did some tests this morning, passing from no options to -6r -6fp changes
speedtst ST time from 16.8 to 16.6 seconds, so they're worth nothing.
> You are missing -bm for MT
>
I've not used it and
On Thu, 13 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Not.
> -bt should be present
> Which I removed was osn, value used in message:
> "creating a (osn) executable"
> by default is OS/2
OK.
> >> changed -5 to -5r because -5 is for 16bit code.
> >I think it does not cause any diff
On Thu, 13 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> I'think I've found something:
> first of all, I started from config/win32/owatcom flags, then I had to remove
> -bt=OS2 which is wrong, should be -bt=OS2V2 but this gives an undefined
> function referenced error when building, so I removed
Przemyslaw,
I'think I've found something:
first of all, I started from config/win32/owatcom flags, then I had to remove
-bt=OS2 which is wrong, should be -bt=OS2V2 but this gives an undefined
function referenced error when building, so I removed every thing, then I
changed -5 to -5r because -5 is
On Wed, 12 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> I think the problem is not in the code but in the flags used to build harbour,
> I've changed owatcom.cf this way
It's highly possible.
> I've removed nearly all compilation flags, I don't know what they mean, but
> anyway, I've always t
Przemyslaw, David,
I think the problem is not in the code but in the flags used to build harbour,
I've changed owatcom.cf this way
#CPPFLAGS = -j -w3 -d2 -5s -5r -fp5 -oxehtz -zq -zt0 -mf -bt=NT
#DAVID: CPPFLAGS = -w2 -d1 -zq -bt=OS2
CPPFLAGS = -w2 -d1 -zq -bt=OS2 -bm
#architecture flags
#CPPFLA
On Tue, 11 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> what do you use to build harbour with watcom?
> On my pc, simply trying to build a single .c file from the ide gives a trap
> inside OS2KRNL, so I fear it is not SMP ready.
I do not know if the IDE is SMP ready but it's not a problem for
On Tue, 11 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> GCC has this code inside libos2 which is linked with every program:
> ---8<
> /* kbd4.c */
> #define INCL_KBD
> #include
> USHORT _THUNK_FUNCTION (Kbd16CharIn) ();
> USHORT KbdCharIn (PKBDKEYINFO pkbci, USHORT
On Tue, 11 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> I don't know, but I remember that I started working on harbour for OS/2
> exactly for the same problem, sometimes it was GPFing without reason and I
> traced that reason to two things:
> 1) KBD code not using tiled memory
> 2) gtos2.c code
Przemyslaw,
GCC has this code inside libos2 which is linked with every program:
---8<
/* kbd4.c */
#define INCL_KBD
#include
USHORT _THUNK_FUNCTION (Kbd16CharIn) ();
USHORT KbdCharIn (PKBDKEYINFO pkbci, USHORT fWait, HKBD hkbd)
{
return ((USHORT)
(_THUN
David,
what do you use to build harbour with watcom?
On my pc, simply trying to build a single .c file from the ide gives a trap
inside OS2KRNL, so I fear it is not SMP ready.
Maurilio.
David Arturo Macias Corona wrote:
> Przemek:
>
>>So it's general problem with accessing console from other t
Przemyslaw,
> To be precise the problem is with any console input and it's inside pure
> OS2 API functions. It means that we probably using them in wrong way.
I attach here kbCharIn docs
-8<--
Reads a character data record from the keyboard.
#define INCL_KBD
#include
PKBD
On Tue, 11 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Przemek:
> any comments ?
Thanks for the example but it does not help us in the problem we have.
> I found in documentation included in OW a sample for multithreading
> Entirely page is below
> Przemek, can you check page ?
> Th
On Tue, 11 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Do you have answer about this ?
But was it the question?
> I do not know if it is what you are looking for
> I found in different places of documentation included in OW
> -
> The macro _threadid can be used to determine
On Mon, 10 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> It seems you did focus on mouse code, I've never dealt with it, but I'd say it
> has to do with openwatcom, because with GCC mttest*.* work ok.
To be precise the problem is with any console input and it's inside pure
OS2 API functions. It
David, Przemyslaw,
I'm sorry, I was not monitoring this list lately because of lack of spare
time, anyway, can I do to help?
It seems you did focus on mouse code, I've never dealt with it, but I'd say it
has to do with openwatcom, because with GCC mttest*.* work ok.
If I'm not wrong, openwatcom
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Good question but I am not tested that
> What I say is: using gtos2, at least in these tests, screen/output is not
> refreshed and tracing labels existent in body of fuction where error happen
> are not shown
> You will see more
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Results included in message were redirected to saleos2.txt, salecgi.txt,
> salestd.txt
> In screen or redirected are same
> Entire results are below
> It work correctly using hb_gt_cgi_ReadKey() as hb_gt_os2_ReadKey()
> I insist,
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Entire results for HB_GT_OS2_DEFAULT, HB_GT_CGI_DEFAULT, HB_GT_STD_DEFAULT
> are below
> HB_GT_OS2_DEFAULT and HB_GT_STD_DEFAULT should fail equal, but STD does a
> step ahead (??)
Thank you very much.
Maybe when GTOS2 is used
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Original message is included below
>
> As summary:
>
> For first thread (how do you know is 1 ? ):
> -
> [...]
> 2. hb_threadMutexLock()
> 2. hb_inkeyPoll()
> 3. hb_inkeyPoll()
> 1. hb_gt_os2_ReadKey()<---
> 2. hb_
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> I made a Harbour fresh checkout and build with
> set C_USR=-DHB_FM_STATISTICS_OFF -DHB_TR_LEVEL_DEBUG
> Screen output (same as Win32:OW):
>
> make[3]: *** [hboutdbg.obj] Error 8
> make[2]: *** [descend] Erro
Hi David,
Screen output (same as Win32:OW):
make[3]: *** [hboutdbg.obj] Error 8
make[2]: *** [descend] Error 2
What is the error message?
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
h
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> I have not updated Harbour code from SVN trying to not introduce a
> different behaviour by some recent change
> But perhaps is time to use a fresh checkout and recreate tests
> I will do that
It will resolve possible GPF during
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Rebuilt Harbour with
> set C_USR=-DHB_FM_STATISTICS_OFF -DHB_TR_LEVEL_DEBUG
> Before running new test application (pba.exe):
> set HB_TR_LEVEL=HB_TR_DEBUG
> set HB_TR_FLUSH=1
> set HB_TR_OUTPUT=trace.log
> and results are:
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> hb_gt_os2_ReadKey() is working fine, but it happen many steps before error.
Where did you found such information?
> I marked it to you in tracing list (you skiped it, review it)
> TID=1
> 2. hb_threadMutexLock()
> 2. hb_inkeyPo
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Some pass in:
>iKey = HB_GTSELF_READKEY( pGT, INKEY_ALL );
> I put tracing in
> static int hb_gt_def_ReadKey( PHB_GT pGT, int iEventMask )
> and
> static int hb_gt_def_MouseReadKey( PHB_GT pGT, int iEventMask )
> but never a
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> I corrected your C code :-)
:-) I'm writing it by hand in this messages only using mouse for
copy and past and here I marked " in function name. It's possible
that sth like that will happen, sorry.
> Some pass in:
>iKey = H
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David.
> Did you see this info in gtos2.c about 16 bit ?
> -
> * Copyright 2000 - 2001 Maurilio Longo <[EMAIL PROTECTED]>
> *hb_gt_DispBegin() / hb_gt_DispEnd()
> *hb_gt_ScreenPtr() and hb_gt_x() functions and vi
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Not yet with hope to find problem with these tests
Now we are nearly in the place.
> I think error will happen with any gt
> hbrun_mt.exe is gtos2 and current .prg for tests is gtstd
As you can see with GTCGI it's related to GT
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> 2. hb_threadMutexLock()
> 2. hb_inkeyPoll()
> 3. hb_inkeyPoll()
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
Try to check hb_gt_os2_ReadKey().
In the .prg test code I sent was:
announc
On Sat, 08 Nov 2008, Przemyslaw Czerpak wrote:
Hi David,
> The mutex locking is correct.
> Next candidate are GTOS2 internals.
> BTW have you tried to enable tracing?
> It would help us to locate the problem quite fast.
If you will have problems with tracing then please tests
code below. It's rt
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> 1. hb_threadMutexLock()
> _hb_gettid()
> TID=2
> _hb_gettid()
> TID=2
> 2. hb_threadMutexLock()
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
The mutex locking is correct.
Next candidate ar
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
> Error happen
> -
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=2
> _hb_gettid()
> TID=2
>
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> To see something I added last tracing label
> -
> ULONG _hb_gettid( void )
> {
>ULONG tid = 0;
>PTIB ptib = NULL;
>
>if( DosGetInfoBlocks( &ptib, NULL ) == NO_ERROR )
>{
> if( ! ptib
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> >So it will crashes inside hb_vmExecute()
> >Please try to commenct line 1127 in hvm.c
> > hb_inkeyPoll();
> >to eliminate yet another possibly danger place and make test.
> I commented in hvm.c two active
> hb_inkeyPoll
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Take note: I changed C code myself :-)
Thanks :-)
[...]
> 14. hb_vmDo()
> 15. hb_vmDo()
> 16. hb_vmDo() <-- note 18 ?
> SYS1808:
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
So it wi
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Somebody tested Harbour / OpenWatcom 1.7 in Windows ?
I'm build systematically MS-Windows OpenWatcom 1.2 binaries
in Linux using WINE and MT mode is working without any problems.
> Perhaps have the same problem of OS/2 and if so
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Using -bm flag and hbvmmt
> ---
> 1. HB_THREADSTART
> 1. hb_threadStartVM
> 3. HB_THREADSTART
> 2. hb_threadStartVM
> 1. hb_vmThreadInit()
> 2. hb_vmThreadInit()
> 3. hb_vmThreadInit()
> 4. hb_vmThreadInit()
> SYS1
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Using -bm flag and hbvmmt
> ---
> 1. hb_stackInit()
> 2. hb_stackInit()
> 3. hb_stackInit()
> 4. hb_stackInit(00130034)
> 5. hb_stackInit()
> 1. HB_THREADSTART
> 1. hb_threadStartVM
> 3. HB_THREADSTART
> 2. hb_thre
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Using -bm flag and hbvmmt
> ---
> 1. HB_THREADSTART
> 1. hb_threadStartVM
> 3. HB_THREADSTART
> 2. hb_threadStartVM
> SYS1808:
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
>
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi Daivd,
> >I'm attaching modified thread.c file.
> >Url :
> >http://lists.harbour-project.org/pipermail/harbour/attachments/20081107/4c83ebf2/thread.c-0001.gz
> Checked with WarpZip and Linux-Ark and both confirm: thread.c-0001.gz is
> em
On Thu, 06 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> But it seem to be C code and I do not know C and handle with OW :-)
> Well, trying based in make_ow.log, hbrun creation:
> [E:\harbour810\harbour]wpp386 pba.c -fo=pba.obj -i=include -bm
> [E:\harbour810\harbour]wlink debug all OP
On Thu, 06 Nov 2008, Przemyslaw Czerpak wrote:
Hi David,
> Now we should resolve the problem with creating new threads in OS2
> OpenWatcom() looks that sth is wrong and the problem is not inside
> Harbour but OpenWatcom MT CRTL. Or maybe it's a trivial problem with
> calling convention and expect
On Thu, 06 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> >Probably it's the cost of OpenWatcom MT safe CRTL. Harbour does not use
> >extensively CRTL. In practice the only one function which may have
> >serious performance impact is memory allocation. Maybe I will be able to
> >say sth
On Thu, 06 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Tests with current Harbour - OS/2 - With OpenWatcom 1.7 (Rev. 9846):
> [E:\harbour810\harbour\tests]e:\harbour810\harbourow\bin\hbrun_mt.exe
> speedtst.prg --scale
Please try mttest*.prg 1st. It will be easier to locate basic pr
On Thu, 06 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Tests with current Harbour - OS/2 - With OpenWatcom 1.7 (Rev. 9846):
> [E:\harbour810\harbour\tests]e:\harbour810\harbourow\bin\hbrun_st.exe
> speedtst.prg
> [ total application time: ]...104.00
>
On Wed, 05 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> >Should be fixed. Please tray after:
> > 2008-11-04 17:28 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> >> ../../../thread.c(402): Warning! W869: col(25) use of '_beginthread'
> >> requires build target to be multi-thre
On Tue, 04 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> With OpenWatcom 1.7:
> make[3]: *** [hbcrypt.obj] Error 8
> For hbrun.exe:
> Warning! W1023: no starting address found, using 0001:
> creating an OS/2 32-bit executable
Should be fixed. Please tray after:
2008-11-04 17
On Mon, 03 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> With OpenWatcom 1.7:
> - Screen output
> ---
> make[3]: *** [seconds.obj] Error 8
> make[4]: *** [thread.obj] Error 8
Thanks for tests. This should be fixed. Please try after:
2008-11-04 02:12 UTC+0100 Prze
On Mon, 03 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> >2008-11-03 17:49 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> > * harbour/include/hbthread.h
> >* include in OpenWatcom OS2 builds
../../../thread.c(402): Error! E029: col(13) symbol '_beginthread' has not been
On Mon, 03 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Note order:
> Documentation say to use:
> SET INCLUDE=%WATCOM%\H;%WATCOM%\H\OS2
> but OW installer set:
> SET INCLUDE=%WATCOM%\H\OS2;%WATCOM%\H
And this seems to be correct because some files may exists in different
directori
Przemyslaw,
I'm not aware of any other method.
Best regards.
Maurilio.
Przemyslaw Czerpak wrote:
> On Mon, 03 Nov 2008, Maurilio Longo wrote:
>
> Hi Maurilio,
>
>> I've not tested this code, but something like this should give you the
>> thread id.
>> unsigned long _gettid()
>> {
>>PTIB
On Sun, 02 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> With OpenWatcom 1.7:
> - Screen output
> ---
> make[3]: *** [hbinet.obj] Error 9
It may be a little bit hard to fix it without seeing OS2 OpenWatcom
header files. I'll try to make it but if you can please comp
1 - 100 of 116 matches
Mail list logo