Re: [xHarbour-developers] error conflicting types
Yes, I've not committed it yet, since there is that error on destructors which makes xharbour broken for me. Maurilio. Enrico Maria Giordano wrote: -Messaggio Originale- Da: Maurilio Longo maurilio.lo...@libero.it A: Enrico Maria Giordano e.m.giord...@emagsoftware.it Cc: Xharbour-Developers List xharbour-developers@lists.sourceforge.net Data invio: mercoledì 7 gennaio 2009 14.43 Oggetto: Re: [xHarbour-developers] error conflicting types Let me know if you can fix it yourself or you want me to fix it. Enrico, yes, fixed, thanks, Thank you. I can't see your fix in the CVS yet. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] error conflicting types
-Messaggio Originale- Da: Maurilio Longo maurilio.lo...@libero.it A: Enrico Maria Giordano e.m.giord...@emagsoftware.it Cc: Xharbour-Developers List xharbour-developers@lists.sourceforge.net Data invio: giovedì 8 gennaio 2009 9.03 Oggetto: Re: [xHarbour-developers] error conflicting types Yes, I've not committed it yet, since there is that error on destructors which makes xharbour broken for me. Ok, no problem. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] 2008-01-08 11:55 UTC+0100 Miguel Angel Marchuet miguelan...@marchuet.net
2008-01-08 11:55 UTC+0100 Miguel Angel Marchuet miguelan...@marchuet.net * common.mak * compile.mak * include\Makefile * include\hbrddnsx.h * include\hbsetup.h * makefile.bc * makefile.dc * makefile.gc * makefile.pc * makefile.vc * makefile.wc * mdir.bat * source\rdd\dbfcdx\dbfnsx1.c + Added dbfnsx rdd form Prezmek harbour's version (many thks to Prezmek) ! fixed OrdBagName it was returning too extension. * source\lang\msgca.c ! fixed some catalanish entries. * source\rdd\bmdbfcdx\bmdbfcdx1.c * source\rdd\dbfcdx\dbfcdx1.c * source\rdd\dbfntx\dbfntx1.c * reused pError on canretry errors. * source\compiler\hbslex.c * source\rtl\philes.c * include\hbrddntx.h * source\tip\client.prg * source\tip\ftpcln.prg * minor syntax modifications. Best regards, Miguel Angel Marchuet -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] MT build dies at startup
On Thu, 8 Jan 2009 15:28:39 +0100 Enrico Maria Giordano e.m.giord...@emagsoftware.it wrote: -Messaggio Originale- Da: Maurilio Longo maurilio.lo...@libero.it A: Xharbour-Developers List xharbour-developers@lists.sourceforge.net Data invio: giovedì 8 gennaio 2009 15.02 Oggetto: Re: [xHarbour-developers] MT build dies at startup I've received a message from Przemyslaw that I attach here, I think we should seriously fix these problems, right now xharbour is not useable anymore, not only in MT mode but even a plain ST code with a destructor (which does not uses statics nor creates now objects inside destructor). xharbour is not useable anymore is a nonsense for me. +1 -- Andi -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] MT build dies at startup
Enrico, when you cannot use destructors in objects in single-threaded programs... I don't care how we call it, I say it is broken (and it was working a few months ago). Maurilio. Enrico Maria Giordano wrote: -Messaggio Originale- Da: Maurilio Longo maurilio.lo...@libero.it A: Xharbour-Developers List xharbour-developers@lists.sourceforge.net Data invio: giovedì 8 gennaio 2009 15.02 Oggetto: Re: [xHarbour-developers] MT build dies at startup I've received a message from Przemyslaw that I attach here, I think we should seriously fix these problems, right now xharbour is not useable anymore, not only in MT mode but even a plain ST code with a destructor (which does not uses statics nor creates now objects inside destructor). xharbour is not useable anymore is a nonsense for me. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] MT build dies at startup
-Messaggio Originale- Da: Maurilio Longo maurilio.lo...@libero.it A: Enrico Maria Giordano e.m.giord...@emagsoftware.it Cc: Xharbour-Developers List xharbour-developers@lists.sourceforge.net Data invio: giovedì 8 gennaio 2009 16.38 Oggetto: Re: [xHarbour-developers] MT build dies at startup Enrico, when you cannot use destructors in objects in single-threaded programs... I don't care how we call it, I say it is broken (and it was working a few months ago). Can you show us a reduced and self-contained sample of the problem? EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] MT build dies at startup
Enrico, I attach the class that fails, to build it you need code not available inside cvs. I have a program that uses this class (subclass it) that I cannot share which, upon exiting gives the error I reported the other day. I'll try to create a simpler example, but, as you can see, the destructor does not use statics nor it creates new objects. Best regards. Maurilio. Enrico Maria Giordano wrote: -Messaggio Originale- Da: Maurilio Longo maurilio.lo...@libero.it A: Enrico Maria Giordano e.m.giord...@emagsoftware.it Cc: Xharbour-Developers List xharbour-developers@lists.sourceforge.net Data invio: giovedì 8 gennaio 2009 16.38 Oggetto: Re: [xHarbour-developers] MT build dies at startup Enrico, when you cannot use destructors in objects in single-threaded programs... I don't care how we call it, I say it is broken (and it was working a few months ago). Can you show us a reduced and self-contained sample of the problem? EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. teasy.prg Description: application/prg -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] MT build dies at startup
Enrico Maria Giordano wrote: Can you show us a reduced and self-contained sample of the problem? for the MT problem, it should be enough to build tests\mtstress.prg Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] MT build dies at startup
-Messaggio Originale- Da: Maurilio Longo maurilio.lo...@libero.it A: Enrico Maria Giordano e.m.giord...@emagsoftware.it Cc: Xharbour-Developers List xharbour-developers@lists.sourceforge.net Data invio: giovedì 8 gennaio 2009 16.47 Oggetto: Re: [xHarbour-developers] MT build dies at startup Enrico, I attach the class that fails, Sorry, I can't compile it. Try to reduce it. The following sample seems to work fine here: #include Hbclass.ch CLASS TTest METHOD New() DESTRUCTOR Free() ENDCLASS METHOD New() CLASS TTest ? New() RETURN Self PROCEDURE Free() CLASS TTest ? Free() RETURN FUNCTION MAIN() TEST() RETURN NIL STATIC FUNCTION TEST() LOCAL oTest := TTest():New() RETURN NIL Result: New() Free() EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] MT build dies at startup
Ron:
This same problem Maurilio describes occurs with the most current
builds of xharbour builder and for this reason we can't test the
Outlook add-in with any recent versions of xbuilder because
Outlooks bombs upon closing it.
Regards,
Maurilio Longo wrote:
I've received a message from Przemyslaw that I attach here, I think we should
seriously fix these problems, right now xharbour is not useable anymore, not
only in MT mode but even a plain ST code with a destructor (which does not
uses statics nor creates now objects inside destructor).
Maurilio.
Message from Przemyslaw follows
8-
It's causes by:
STATIC lInErr
inside rtl/terror.prg
below I'm forwarding the last message I sent to Phil with a patch
which resolves the problem by simple removing lInErr.
Please note that there is s_iLaunchCount for protection against recursive
error calls inside source/vm/errorapi.c which in MT version is part of HVM
stack.
The problem with destructors your reported is probably caused by
executing destructors also for statics variables. Because class
definition is stored inside such variables then it means that now
you cannot create any new object inside destructor even if you want
to remove it immediately. It also means that you should not expect
any valid values in static variables you will want to access from
destructors so you should probably not use them in destructors at all.
best regards,
Przemek
- Forwarded message from Przemyslaw Czerpak dru...@acn.waw.pl -
From: Przemyslaw Czerpak dru...@acn.waw.pl
Subject: Re: [xHarbour-developers] ChangeLog 2008-12-23 01:00 UTC+0300
PhilKrylov phil a t newstar.rinet.ru
To: Phil Krylov p...@newstar.rinet.ru
Date: Wed, 24 Dec 2008 03:25:48 +0100
Lines: 131
On Wed, 24 Dec 2008, Przemyslaw Czerpak wrote:
Hi Phil,
Finally I located the problem with reference counters and why
it was crashing in T004. Just simply in some syncing after CVS
update I had to add by mistake HB_ATOMIC_INC()/HB_ATOMIC_DEC()
macros definition to the section which is used for ST mode.
If you moved it then readonly access to complex variables
begins to work without crashes. Looking for the problem I also
found that hb_itemUnShareString() was copied from Harbour as
is without adopting it to xHarbour. I have serious doubts if
Miguel well knows what he is doing porting Harbour code only
partially. Someone should verify such modifications.
I'm attaching patch which resolves this problems and speedtst.prg
begins to work with xHarbour. But it was rather trivial things.
Now you should look for much more complicated ones. F.e. race
conditions when threads are started/finished which causes that
programs creating simultaneously many short life threads crashes,
memvar variables which causes unreported memory leaks so in practice
cannot be use in MT programs which have to be executed for long time
creating many threads (each new thread allocates new dynamic symbols
for each used memvar which is never released), add MT protection
for classy code, remove all global static variables like
hb_vm_bQuitRequest, s_iBaseLine, hb_vm_iTry, ...
check the .prg code which also uses many static variables
(probably you will have to add support for THREAD STATIC if
you will want to make some things like GETLIST working in MT
mode), make SETs thread local (or any code which have to use
them cannot be ported to MT), updated GT code and enable GT
locking (f.e. see gtapi.c in Harbour and xHarbour), clean
basic thread API to eliminate race conditions which xHarbour
thread functions have (see some notes in speedtst.prg), fix
some compiler constructions like multivalue macros (f.e.:
a[(1,2)], qout((3,4)), a:={(5,6,7})] ) or TRY/CATCH
which are not MT safe, update debugger for MT mode, reduce
number of internal locks which kill scalability - you probably
noticed in speedtst results that on real multiCPU machine is
more efficient to execute simultaneously 2 * numCPU instances
of single thread xHarbour program then numCPU threads in MT one.
Here it will be necessary to strongly change some subsystems.
F.e. whole macro compiler is protected by MUTEX so only one thread
can access it. To resolve it it's necessary to rewrite compiler,
macrocompiler and lexer code to be MT and reentrant safe.
And probably many other things I do not remember know. If you
are interested then I can try to collect modifications I had
to made in Harbour when I was working on MT mode. I still should
have a list I created over year ago.
They should help you to locate places which should be updated.
HTH
Marry Christmas and Happy New Year,
Przemek
* xharbour/config/rules.cf
* give PRG_USR higher priority then HB_FLAGS
* xharbour/include/thread.h
! fixed declaration of HB_ATOMIC_INC()/HB_ATOMIC_DEC() macros
for 32bit x86 *nixes - by mistake it was added to ST section
* xharbour/source/rtl/terror.prg
Re: [xHarbour-developers] MT build dies at startup
Maurilio, Luis,
Please post a REDUCED, yet SELF CONTAINED, sample that shows the problem.
Ron
--
From: Luis Krause Mantilla lkrau...@shaw.ca
Sent: Thursday, January 08, 2009 9:27 AM
To: Maurilio Longo maurilio.lo...@libero.it
Cc: Xharbour-Developers List xharbour-developers@lists.sourceforge.net;
Ron Pinkas r...@xharbour.com
Subject: Re: [xHarbour-developers] MT build dies at startup
Ron:
This same problem Maurilio describes occurs with the most current
builds of xharbour builder and for this reason we can't test the
Outlook add-in with any recent versions of xbuilder because
Outlooks bombs upon closing it.
Regards,
Maurilio Longo wrote:
I've received a message from Przemyslaw that I attach here, I think we
should
seriously fix these problems, right now xharbour is not useable anymore,
not
only in MT mode but even a plain ST code with a destructor (which does
not
uses statics nor creates now objects inside destructor).
Maurilio.
Message from Przemyslaw follows
8-
It's causes by:
STATIC lInErr
inside rtl/terror.prg
below I'm forwarding the last message I sent to Phil with a patch
which resolves the problem by simple removing lInErr.
Please note that there is s_iLaunchCount for protection against recursive
error calls inside source/vm/errorapi.c which in MT version is part of
HVM
stack.
The problem with destructors your reported is probably caused by
executing destructors also for statics variables. Because class
definition is stored inside such variables then it means that now
you cannot create any new object inside destructor even if you want
to remove it immediately. It also means that you should not expect
any valid values in static variables you will want to access from
destructors so you should probably not use them in destructors at all.
best regards,
Przemek
- Forwarded message from Przemyslaw Czerpak dru...@acn.waw.pl -
From: Przemyslaw Czerpak dru...@acn.waw.pl
Subject: Re: [xHarbour-developers] ChangeLog 2008-12-23 01:00 UTC+0300
PhilKrylov phil a t newstar.rinet.ru
To: Phil Krylov p...@newstar.rinet.ru
Date: Wed, 24 Dec 2008 03:25:48 +0100
Lines: 131
On Wed, 24 Dec 2008, Przemyslaw Czerpak wrote:
Hi Phil,
Finally I located the problem with reference counters and why
it was crashing in T004. Just simply in some syncing after CVS
update I had to add by mistake HB_ATOMIC_INC()/HB_ATOMIC_DEC()
macros definition to the section which is used for ST mode.
If you moved it then readonly access to complex variables
begins to work without crashes. Looking for the problem I also
found that hb_itemUnShareString() was copied from Harbour as
is without adopting it to xHarbour. I have serious doubts if
Miguel well knows what he is doing porting Harbour code only
partially. Someone should verify such modifications.
I'm attaching patch which resolves this problems and speedtst.prg
begins to work with xHarbour. But it was rather trivial things.
Now you should look for much more complicated ones. F.e. race
conditions when threads are started/finished which causes that
programs creating simultaneously many short life threads crashes,
memvar variables which causes unreported memory leaks so in practice
cannot be use in MT programs which have to be executed for long time
creating many threads (each new thread allocates new dynamic symbols
for each used memvar which is never released), add MT protection
for classy code, remove all global static variables like
hb_vm_bQuitRequest, s_iBaseLine, hb_vm_iTry, ...
check the .prg code which also uses many static variables
(probably you will have to add support for THREAD STATIC if
you will want to make some things like GETLIST working in MT
mode), make SETs thread local (or any code which have to use
them cannot be ported to MT), updated GT code and enable GT
locking (f.e. see gtapi.c in Harbour and xHarbour), clean
basic thread API to eliminate race conditions which xHarbour
thread functions have (see some notes in speedtst.prg), fix
some compiler constructions like multivalue macros (f.e.:
a[(1,2)], qout((3,4)), a:={(5,6,7})] ) or TRY/CATCH
which are not MT safe, update debugger for MT mode, reduce
number of internal locks which kill scalability - you probably
noticed in speedtst results that on real multiCPU machine is
more efficient to execute simultaneously 2 * numCPU instances
of single thread xHarbour program then numCPU threads in MT one.
Here it will be necessary to strongly change some subsystems.
F.e. whole macro compiler is protected by MUTEX so only one thread
can access it. To resolve it it's necessary to rewrite compiler,
macrocompiler and lexer code to be MT and reentrant safe.
And probably many other things I do not remember know. If you
are interested then I can try to collect modifications I had
to made in Harbour when I was working on MT mode. I still
[xHarbour-developers] 2009-01-08 23:25 UTC+0300 Phil Krylov phil a t newstar.rinet.ru
2009-01-08 23:25 UTC+0300 Phil Krylov phil a t newstar.rinet.ru * config/rules.cf * give PRG_USR higher priority then HB_FLAGS * include/thread.h ! fixed declaration of HB_ATOMIC_INC()/HB_ATOMIC_DEC() macros for 32bit x86 *nixes - by mistake it was added to ST section * source/rtl/terror.prg ! removed lInErr static variable - it breaks using errorNew() in MT programs * source/vm/itemapi.c ! fixed copied as is from Harbour hb_itemUnShareString() Harbour uses different HVM internals and such code cannot be copied without adopting to xHarbour * tests/speedtst.prg ! fixed possible race condition in initialization + added SET WORKAREA PRIVATE (by Przemyslaw Czerpak) * include/classes.h * source/vm/classes.c * source/vm/hvm.c ! Avoid s_pClasses reallocation in MT mode. (partially borrowed from Harbour code by Przemyslaw Czerpak) * ChangeLog ! fixed year numbers in last few commits -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
