I'll stick my nose in here with the suggestion that perhaps this is not
the proper place to discuss this material. As valid as the topic might
be on a neutral newsgroup, there are all sorts of possible ramifications
and unintended consequences that can come of discussions here that could
affect dev
Rodd
RoddGraham wrote:
>
>
> I have attempted to post my Xbase++ MT knowledge on the nabble.com link
> you provided. However it keeps saying that the post was not accepted by
> the mail list.
>
> As I spent some effort trying to share, can someone confirm that it is
> posted for all to see o
I have attempted to post my Xbase++ MT knowledge on the nabble.com link you
provided. However it keeps saying that the post was not accepted by the
mail list.
As I spent some effort trying to share, can someone confirm that it is
posted for all to see or what I need to do to post it. It is som
Pritpal Bedi wrote:
>
> Today I have posted this message on Xbase++ NG:
>
> For example, it will be interesting to have a knowledgebase
> about features and shortcomings of Xbase++ MT modal.
>
>
As a MT Xbase++ user, I have knowledge of its features and shortcommings.
1) Xbase++ is MT, but
Pritpal Bedi wrote:
>
> And I got this reply:
>
>
> Pritpal,
>
> why should I as a Xbase++ developer help a competitor to advance its
> product???
>
>
>
Please look again at Xbase++ NG. Jan does not represent my position and
other Xbase++ users ma
Rodd
RoddGraham wrote:
>
> Please look again at Xbase++ NG. Jan does not represent my position and
> other Xbase++ users may yet respond.
>
Thanks for the support.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/A-few-questions-about-MT-tp19555409p19681131.htm
2008-09-26 02:42 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/thread.c
! fixed thread cleanup code when startthread() fails, f.e.
OS refuse to create new thread.
best regards
Przemek
___
Harbour mailing list
Harbou
The key is in:
lInUse := ! lInUse
line. This code can be MT safe _only_ if xBase++ executes this
whole line as one atomic operation.
So far I haven't found any information about such functionality.
I see no sign this expression would be atomic.
I'd think if it would be, there would exist some
Hi Przemek
First of all I must say you are right, this code isn't thread safe:
lInUse := ! lInUse
But i've also said its only a simplification.
In a real program this code:
1- goes inside a sync method of a class
2- the logical var does not exit
3- the array is a var of the class
4- the class is
Przemek
> why should I as a Xbase++ developer help a competitor to advance its
> product???
> And why do you ask for our help in the Xbase++ generic newsgroup? In my
Please do not understand me wrong.
I know you have implemented far superior MT design than
Xbase++, I swear. My point was to gat
Hi Pritpal,
I know, this mail was targeted to Massimo specifically.
Brgds,
Viktor
On 2008.09.26., at 1:58, Pritpal Bedi wrote:
Sorry Viktor
Hi Massimo and all,
My post was related with knowledge on MT issues
which can be well described by Xbase++ user.
Also I have learned that it is not
On Fri, 26 Sep 2008, Przemyslaw Czerpak wrote:
> Publics are really global and the assign is done in atomic
> operation what is the additional necessary protection I was writing
> about in previous message. But to make it fully safe also access has
> to be done as atomic operation or they have to e
Sorry Viktor
>Hi Massimo and all,
My post was related with knowledge on MT issues
which can be well described by Xbase++ user.
Also I have learned that it is not good to
post any such messages on their NG. Probably one more
message will be my last on this topic.
Regards
Pritpal Bedi
--
Vie
On Fri, 26 Sep 2008, Szak�ts Viktor wrote:
> BTW folks, I'm seeing replies on nabble.com (by Angel Pais
> for example) to this thread, but these messages don't make
> it to this list (which is BTW perfectly okay to avoid spam).
Hi Viktor and Angel,
I've just read this message and I've got answer f
Hi Massimo and all,
Probably the intention is good, but please guys
could you just think it twice before posting Harbour
"advertisements" on other non-free Clipper compatible
product forums?
This is least to say impolite and really unnecessary
from our POV, besides painting a pretty wrong image
On Thu, 25 Sep 2008, Pritpal Bedi wrote:
Hi Pritpal,
> Pritpal,
> why should I as a Xbase++ developer help a competitor to advance its
> product???
> And why do you ask for our help in the Xbase++ generic newsgroup? In my
> eyes this is trolling. This has nothing to do with Xbase++.
> Maybe you
BTW folks, I'm seeing replies on nabble.com (by Angel Pais
for example) to this thread, but these messages don't make
it to this list (which is BTW perfectly okay to avoid spam).
I see this whole nabble/gmain cross-posting a big mess,
and just a way to scatter information and making the
wrong imp
I can understand the feelings of Jan to be honest.
I have no idea what kind of newsgroup is where you've
posted this message, but if XBase++ developers frequent
it, this can easily be taken as offense and the result
is kinda predictable.
Set aside the above, I think we have enough expertise
and
Hi
And I got this reply:
Pritpal,
why should I as a Xbase++ developer help a competitor to advance its
product???
And why do you ask for our help in the Xbase++ generic newsgroup? In my
eyes this is trolling. This has nothing to do with Xbase++.
Mayb
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
> Seems like a good idea. Considering the few CRTL stuff we use,
> maybe we could just get rid of them all. At least as far as core is
> concerned. [ Clipper did it, too. ]
Some function like memcpy() or memmove() are very often inlined
and h
[Maurilio]
latest code, OS/2 GCC, HB_FM_STATISTICS_OFF, PIV HT 3.6GHz, SMP Kernel.
ST
total application time: 52.85
total real time: 52.85
MT
=
Szakáts Viktor wrote:
>
>
> Question, what to do with sqlite3.c.
>
> Brgds,
> Viktor
>
>
I thinks authors of sqlite know this bug
#if defined(SQLITE_TEST) || defined(SQLITE_DEBUG) ||
defined(SQLITE_MEMDEBUG)
/*
** A version of printf() that understands %lld. Used for debugging.
** The p
Hi Przemek,
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
I've already did it, but it's the best if you take a second look
(I can make a mistake virtually anywhere :)
You made exactly what I did with the byte precision ;-)
so after svn update I do not have any conflicts and hbdefs.h
is not mar
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
> I've already did it, but it's the best if you take a second look
> (I can make a mistake virtually anywhere :)
You made exactly what I did with the byte precision ;-)
so after svn update I do not have any conflicts and hbdefs.h
is not marked as modified
Przemek,
I do not know details for MinGW TLS but it's possible that it will be
imporved yet in the future, f.e. now thay can use simple function call
like in BCC. Anyhow in current SVN code the cost of TLS is quite
efficient hidden by HB_STACK_PRELOAD. Just try to remove:
#define HB_STACK_PRE
I've already did it, but it's the best if you take a second look
(I can make a mistake virtually anywhere :)
Question, what to do with sqlite3.c.
Brgds,
Viktor
On 2008.09.25., at 22:12, Przemyslaw Czerpak wrote:
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
I've found some pages li
Szakáts Viktor wrote:
>
>> Gives me:
>> TEST NUMBER = [705032704]
>
#include
#include
int main( void )
{
printf( "TEST NUMER = [%lld]\n",50LL );
printf( "TEST NUMER = [%I64u]\n", 50LL );
return 0;
}
http://www.nabble.com/long-l
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
> I've found some pages listing %lld as one the significant
> incompatibilities of MinGW compared to Linux GCC.
> In MinGW the equivalent formatting seems to be:
> "%I64d" which is also claimed to be the Microsoft C compatible syntax.
> Testin
On Thu, Sep 25, 2008 at 9:44 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> I've found some pages listing %lld as one the significant
> incompatibilities of MinGW compared to Linux GCC.
>
> In MinGW the equivalent formatting seems to be:
> "%I64d" which is also claimed to be the Microsoft C compa
2008-09-25 21:50 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbdefs.h
! Fixed 64-bit printf() formatting strings to be compatible
with MinGW. MinGW seems to follow the Microsoft way instead
of being compatible with other GCC dialects.
This fixes some pcode/c c
Hi Przemek,
I've found some pages listing %lld as one the significant
incompatibilities of MinGW compared to Linux GCC.
In MinGW the equivalent formatting seems to be:
"%I64d" which is also claimed to be the Microsoft C compatible syntax.
Testing with %I64d shows correct results in 3.4.5 and 4.
Same code copied to OSX (Intel), compiled with default gcc 4.0.1
gives the right result:
---
TEST NUMBER = [50]
---
Brgds,
Viktor
On 2008.09.25., at 20:58, Szakáts Viktor wrote:
Hi Przemek,
But for me it's:
hb_xvmPushLongLong( HB_LL( 50 ) );
Can you check in you MinGW the f
Hi Przemek,
But for me it's:
hb_xvmPushLongLong( HB_LL( 50 ) );
Can you check in you MinGW the folowing code:
#include
int main( void )
{
printf( "TEST NUMER = [%lld]\n", 50LL );
return 0;
}
Gives me:
TEST NUMBER = [705032704]
In MinGW 3.4.5 (official - t
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
> After some experimenting it looks like -gc3 is the culprit.
I expected that it may be related to -gc3 switch and before
I wrote this message rebuild Harbour with -gc3 using Linux GCC
and cross MingGW. Everything works as expected.
> This c
On Thu, 25 Sep 2008, Przemyslaw Czerpak wrote:
> In my GCC final code looks for -O3 is:
> func:
> pushl %ebp
> movl%esp, %ebp
> subl$8, %esp
> movlhb_stack_ptr, %ecx
> movl4(%ecx), %eax
> add
Hi Przemek,
After some experimenting it looks like -gc3 is the culprit.
This can be easily seen even by using harbour.exe from the
official MinGW binary package.
You short sample program, compiled with -gc3 will produce
this line:
---
hb_xvmPushLongLong( HB_LL( 705032704 ) );
---
Brgds,
Viktor
Today I have posted this message on Xbase++ NG:
Hello Everybody
Harbour developers are concentrating on Multi-Threading
at the moment and have implemented the fairly advanced,
optimized, and stable modal.
As Xbase++ is the pioneer and is the only working
On Thu, 25 Sep 2008, Maurilio Longo wrote:
Hi Maurilio,
> Ok, here they are,
> same hardware, xharbour at $Id: ChangeLog,v 1.6182 2008/08/01 09:41:14
> marchuet Exp $
> MT
> total application time: 214.79
> ST
> total application time: 95.1
On Thu, Sep 25, 2008 at 7:22 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> This is very serious problem.
> Just try:
> proc main()
> ? 50
> return
I don't know if it helps but I've just tried with current official mingw 3.4.5:
$ gcc -v
Reading specs from c:/mingw/bin/../li
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
>>> tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990.
>>> Actually the new MinGW results are the right ones, but the
>>> expected results seem to be screwed up, showing 705032704 instead of
>>> 50. Quite strange. ]
>> Can y
Ok, here they are,
same hardware, xharbour at $Id: ChangeLog,v 1.6182 2008/08/01 09:41:14
marchuet Exp $
MT
total application time: 214.79
total real time:214.79
ST
total application time: 95.18
total
On Thu, 25 Sep 2008, Przemyslaw Czerpak wrote:
Hi All,
> The cost of TLS access is strictly compiler/OS dependent. I've
> just make interesting experiment to compare the code of using
> stack pointer to dynamically allocated stack instead of statick
> stack address in ST programs.
> I made very s
Hi Przemek,
tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990.
Actually the new MinGW results are the right ones, but the
expected results seem to be screwed up, showing 705032704 instead of
50. Quite strange. ]
Can you send the exact hbtest output?
Pls find them attached
On Thu, 25 Sep 2008, Maurilio Longo wrote:
Hi Maurilio,
> Yes, probably differences between SMP and UNI kernels, or size of on chip
> cache.
> Anyway, I think that in real code you don't notice such a difference.
Yes of course. This test measures only HVM performance on pure PCODE
evaluation. I
Przemyslaw Czerpak wrote:
>
> Thank you for the tests. You have a little bit bigger difference then
> David. It's ~34%. But I cannot say exactly why. It's possible that
> some memory operation have different cost in MT and ST code due to
> different startup memory consumption by MT and ST HVMs. An
On Thu, 25 Sep 2008, Maurilio Longo wrote:
Hi Maurilio,
> latest code, OS/2 GCC, HB_FM_STATISTICS_OFF, PIV HT 3.6GHz, SMP Kernel.
> ST
>
> total application time: 52.85
> total real time:
On Mon, 22 Sep 2008, Szak�ts Viktor wrote:
Hi all interested in PUBLIC like in xBase++
Now user can fully control the memavars inheritance even separately
for public and private vars. IMHO it's very flexible and allows
to use many of existing code using memvars without rewirting it
for MT mode so
Przemyslaw,
latest code, OS/2 GCC, HB_FM_STATISTICS_OFF, PIV HT 3.6GHz, SMP Kernel.
ST
total application time: 52.85
total real time: 52.85
MT
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
>> [ Update: Tried MinGW 4.3.2 with -DHB_USE_TLS, and I'm
>> still getting the same error as above. Maybe I'm doing
>> something wrong, which could well may be given the zillions
>> of factors involved. ]
> I did something wrong. Too much comp
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
>
> [ Update: After removing both from 1.0.1 builds, I got _just slightly_
> bigger binaries, and about identical performance. As a downside, now
> I'm getting 44 errors in hbtest, due to failing Round() and Int()
> tests: 914, 917-920, 923-92
2008-09-25 13:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
- make_tgz.sh
+ mpkg_tgz.sh
- make_deb.sh
+ mpkg_deb.sh
- make_rpm.sh
+ mpkg_rpm.sh
- make_rpmwce.sh
+ mpkg_rpm_wce.sh
- make_rpmwin.sh
+ mpkg_rpm_win.sh
- make_xmingw.sh
+ make_gnu_xmingw.sh
- make_xmingwce.s
2008-09-25 13:16 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* contrib/xhb/hbcompat.ch
+ Added xhb_CopyFile() two-way translations.
(untested)
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-proje
2008-09-25 13:13 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* tests/speedtst.prg
! Use hb_OSNewLine() instead of hard-wired EOL.
+ Emulate hb_OSNewLine() for non-Harbour compilers.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-p
2008-09-25 13:07 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbthread.h
+ Enabled HB_USE_TLS for MinGW >= 4.3.0
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/har
Hi Przemek,
[ Update: Tried MinGW 4.3.2 with -DHB_USE_TLS, and I'm
still getting the same error as above. Maybe I'm doing
something wrong, which could well may be given the zillions
of factors involved. ]
I did something wrong. Too much compilers and compiled
environments on one computer...
On Thu, 25 Sep 2008, Maurilio Longo wrote:
Hi Maurilio,
> > Thank you very much for the information. It means that dlmalloc.c
> > will have to be updated to use native OS2 API in the future if it
> > works as expected for Windows users.
> > Probably you are the best person to make it in such case
Viktor:
>> Unrecoverable error 9009: hb_xrealloc can't reallocate memory
>> Called from AADD(0)
>> Called from MAIN(6) in pcode.hrb
>> Called from
>> HB_HRBRUN(0)
>>
>> Called from _APPMAIN(114) in ../../hbrun.prg
>Do I see well
Hi Przemek,
I've built mingw with -DHB_USE_TLS (the rest is default),
then I got 'undefined reference to '__emutls_get_address'
errors on linking. Such symbol doesn't BTW exist in MinGW
4.3.2 supplied libs.
AFAIR the work on TLS support for MinGW started at the begining of
summer so probably
Przemyslaw,
why thread 1 does not have TID? I think that all .prg thread should be equal
:) so that we can handle them the same way.
Best regards.
Maurilio.
Przemyslaw Czerpak wrote:
> 2008-09-22 02:34 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> * harbour/include/hbvm.h
> * harb
Hi Przemek,
empty extensions, could anyone help how to
convert current harbour.spec to harbour-spec and
not break .rpm creation? Plus it would be also
It will break one feature. Now you can download harbour-*.src.tar.gz
and use:
rpmbuild -ta harbour-*.src.t
Viktor and Przemyslaw,
+1 for a way to be fully xbase++ compatible.
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman
Viktor,
not always, I mean, if I press Alt-C stack trace is ok.
If I call hbrun speedtst.prg, output is misaligned.
Maurilio.
Szakáts Viktor wrote:
>>
> Hi Maurilio, David,
>
>> Unrecoverable error 9009: hb_xrealloc can't reallocate memory
>> Called from AADD(0)
>> Called fr
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
> 2008-09-25 11:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
> * Some steps done to use more consistent names for Windows
> and Windows CE, and also to move away from '32' usage.
> ; TODO: I'd prefer to give all .spec files
Hi Maurilio, David,
Unrecoverable error 9009: hb_xrealloc can't reallocate memory
Called from AADD(0)
Called from MAIN(6) in pcode.hrb
Called from
HB_HRBRUN(0)
Called from _APPMAIN(114) in ../../hbrun.prg
Do I see well,
Przemek, Maurilio:
>>Once again thank you very much for your help. Now MT for OS2
>>seems to be fully functional and works well. Some minor things
>>can be cleaned yet but they are not big problem.
>>Have you agreed final version for TCPV40HDRS / HB_OS2_TCP32
>I think yes, let's wait for David c
Przemyslaw Czerpak wrote:
> Thank you very much for the information. It means that dlmalloc.c
> will have to be updated to use native OS2 API in the future if it
> works as expected for Windows users.
> Probably you are the best person to make it in such case :-)
>
Przemyslaw,
I was looking at d
Przemyslaw,
> Have you agreed final version for TCPV40HDRS / HB_OS2_TCP32
I think yes, let's wait for David confirmation, anyway HB_OS2_TCP32 is more
meaningfull since it pinpoints what it is changing.
Thanks.
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.
2008-09-25 11:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
- harbour-ce-spec
+ harbour-wce-spec
- harbour-w32-spec
+ harbour-win-spec
- make_rpmw32.sh
+ make_rpmwin.sh
- make_rpmce.sh
+ make_rpmwce.sh
* Some steps done to use more consistent names for Windows
and Win
On Thu, 25 Sep 2008, David Arturo Macias Corona wrote:
Hi David,
> I made a fresh build without -DHB_FM_STATISTICS_OFF
> and Harbour build/run fine
Thank you very much for test.
> It does not raise error reported by Maurilio:
>
>>> I did the change to the makefile,
On Wed, 24 Sep 2008, Szak�ts Viktor wrote:
Hi all,
> I've built mingw with -DHB_USE_TLS (the rest is default),
> then I got 'undefined reference to '__emutls_get_address'
> errors on linking. Such symbol doesn't BTW exist in MinGW
> 4.3.2 supplied libs.
AFAIR the work on TLS support for MinGW st
Hi all,
For simple variables I find this an odd feature,
might be even dangerous and may also affect
performance. Not to mention how many odd cases
it may generate (think of recursion if the trigger
block modifies the triggering variable, variables
referencing other variables, and handling arrays
Przemek, Maurilio:
[Maurilio]
yes! with fm statistics off it works wonderfully :)
[Przemek]
Thank you for confirmation. Now it should work also with memory
statistic enabled.
When we will make some other test then I'll disable stack preloading
for this systems and C compilers when it does not
It can be very useful, we need to do it manually :(
in our ERP need to spread some values on changing variables, and
the tree some times is very long and easy to break, we now are using
codeblocks that are evaluated overloading assign operator.
Is an important feature to ERP developers.
Trigger
On Thu, 25 Sep 2008, Maurilio Longo wrote:
Hi Maurilio,
> yes! with fm statistics off it works wonderfully :)
Thank you for confirmation. Now it should work also with memory
statistic enabled.
When we will make some other test then I'll disable stack preloading
for this systems and C compilers w
Szakáts Viktor a écrit :
2008-09-24 18:17 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* utils/hbdoc/hbdoc.prg
* utils/hbmake/hbmake.prg
* utils/hbrun/hbrun.prg
% One function made STATIC.
Thank you Viktor & Przemek.
Can we get this for 1.0.2 ?
Guy
_
Przemyslaw,
yes! with fm statistics off it works wonderfully :)
Thanks so much.
Maurilio.
Przemyslaw Czerpak wrote:
> On Wed, 24 Sep 2008, Maurilio Longo wrote:
>
> Hi Maurilio,
>
>> I'm not completely sure I do understand the way the pre-loading of the stack
>> gets done, but I think it ends
76 matches
Mail list logo
