* harbour/include/hbapicom.h
* minor modification in defined names
* harbour/src/rtl/hbcom.c
+ added some very seldom (in practice only on Linux kernels >= 2.4
and not by all hardware drivers) supported termios extensions
* harbour/include/hbatomic.h
! fixed typo in non x86 and non MinGW GCC>=4.1 builds reported
on SF bug tracker
* harbour/include/hbsetup.h
+ added HB_FORCEINLINE macro
* harbour/include/hbatomic.h
* use HB_FORCEINLINE instead of _HB_INLINE_
* harbour/src/vm/fm.c
* define for DLMALLOC FORCEINLINE macro as HB_FORCEINLINE
* harbour/src/vm/dlmalloc.c
* removed some cleanup in FORCEINLINE declaration and _HB_INLINE_
usage reducing number of local Harbour modifications.
* harbour/include/hbatomic.h
* removed unnecessary parenthesis
* renamed HB_SPINLOCK_INIT_R macro to HB_SPINLOCK_INITVAL_R
+ added HB_SPINLOCK_INIT_R(l) macro
* harbour/src/vm/fm.c
* harbour/src/vm/dlmalloc.c
+ updated to DLMALLOC 2.8.4
* added OS2 support from our previous DLMALLOC version
+ updated to use our own recursive locks when available
* disabled hack which breaks strict aliasing
! added some fixes to new DLMALLOC code
TODO: Test it with MSVC win and wince builds and add _MSC_VER
based protection for __forceinline usage (I do not know
in which MSVC version it was added).
Test it with OS2 GCC and OpenWatcom builds.
Test it Darwin and some other *nixes.
* harbour/contrib/sddfb/sddfb.c
! fixed missing reference operator in isc_detach_database()
! fixed NULL used to clear connection handles
* keep references to connection handlers passed to isc_*() functions
* minor formatting
* harbour/include/hbatomic.h
* removed 'static inline' from OpenWatcom ASM functions defined
by '#pragma aux ...' to make OpenWatcom < 1.8 happy.
Version 1.8 ignores 'static inline' attributes in such declarations.
* harbour/config/dos/watcom.mk
* harbour/utils/hbmk2/hbmk2.prg
* switched from DOS/4GW to DOS/32A extender. It's faster what is
noticeable also in final Harbour binaries, does not have DOS4G
command line limitations and has nice tools which allow to easy
set different runtime parameters (ss.exe) or compress final
executable (sc.exe)
BTW people having problem with maximum command line size in
OpenWatcom tools can replace DOS/4GW with DOS/32A in this tools
It can be made also globally by coping dos32a.exe to dos4gw.exe.
NOTE: I've found why DOS Harbour OpenWatcom application created
in my Linux box were not working. Just simply the directory
with DOS extender setup files was not in PATH.
Creating DOS OpenWatcom applications in other systems (i.e.
Linux or OS2) do not forget to add directory with DOS binaries
'%WATCOM%\binw' to PATH after directory with platform native
OpenWatcom binaries '%WATCOM%\bin*' or copy DOS extender
(dos32a.exe) to one of PATH directories.
* harbour/config/dos/watcom.mk
* added workaround for not included automatically by linker CLIB
library when Harbour is compiler in pure C mode. I hope it's only
temporary hack which we can remove in the future. I haven't added
it to hbmk2 so linking DOS applications using hbmk2 user will have
to add -lclib3r to hbmk2 parameters.
* harbour/config/common/watcom.mk
* disable DOS/32A banner messages
* harbour/src/vm/dlmalloc.c
% use harbour spin locks if available by default in all builds
* harbour/include/hbatomic.h
* removed HB_SPINLOCK_SLEEP macro and enable code to always yield
the processor in spin locks
* cover double spin lock setting by HB_SPINLOCK_REPEAT
* harbour/src/vm/garbage.c
* removed unused HB_SPINLOCK_SLEEP macro
* harbour/include/hbstack.h
* harbour/src/vm/estack.c
+ added new internal function hb_stackAllocator()
* disable hb_stackTotalItems() stack macro so this function can be
used also in internal HVM code to check if stack is initialized
* harbour/src/vm/fm.c
! use hb_stackAllocator() to access pointer to DLMALLOC mspace
It should fix GPF when DLMT was used in OS2 builds - please test.
+ harbour/config/linux/clang.mk
+ added support for CLANG in LINUX builds
* harbour/include/hbatomic.h
+ added assembler code for SPINLOCKs in WATCOM x86 builds
* harbour/src/vm/fm.c
* enabled HB_FM_DLMT_ALLOC by default in MT HVM if HB_FM_DL_ALLOC is
also enabled
* harbour/src/vm/dlmalloc.c
* modifications for non MS-Windows WATCOM builds
TOFIX: now it compiles in Linux and OS2 builds but it still does not
work
* harbour/include/hbatomic.h
% added architecture independent support for atomic operations and
spinlocks in all SunOS builds
* harbour/source/vm/dynlibhb.c
! reenabled dlopen interface for Sun C compilers
* enabled dlopen interface for SunOS builds
* contrib/hbqt/hbqt_slots.cpp
! Deleted windows.h.
* include/hbsetup.h
+ PPC CPU detection made better.
* include/hbatomic.h
* source/vm/maindllp.c
* source/rtl/gttone.c
+ Using HB_CPU_* macros to detect CPU instead of compiler
specific solutions.
Przemek, please review me.
* source/vm/maindllp.c
% Using hbver.h constants to form the version number
included in the .dll name. So it's now maintainence
free.
% Reduced redundancy when forming .dll names.
* source/vm/maindllp.c
* utils/hbmk2/hbmk2.prg
* Renamed wce .dll to harbour[mt]-20-wce-arm.dll
* Renamed non-ARM wce .dlls to harbour[mt]-20-wce.dll
* INSTALL
+ config/linux/sunpro.cf
+ Added Sun Studio compiler support for Linux platforms.
Thanks Tamas Tevesz for the tip that this port exists.
It has various problems to fix, but it's a start.
* config/sunos/sunpro.cf
! Typo in prev commit.
* harbour/include/hbsetup.h
* harbour/include/hbthread.h
* harbour/include/hbatomic.h
* harbour/source/vm/thread.c
* added support for MT mode in WinCE builds using raw MS-Windows API
instead of CRTL wrappers. It's possible that it may badly interact
with some CRTLs functions we are using in our code so I do not know
it will work. Please test.
+ harbour/include/hbtask.h
+ harbour/source/vm/task.c
* harbour/include/hbthread.h
* harbour/include/hbatomic.h
* harbour/source/vm/thread.c
* harbour/source/vm/hvm.c
* harbour/source/vm/fm.c
* harbour/source/rtl/idle.c
* harbour/source/rtl/filesys.c
+ implemented OS independent task switching system - it gives PTHREAD
compatible basic API so it can be used in HVM as alternative MT support
which does not use any OS threads. As long as Harbour does not call
any blocking OS function then it's possible to create and execute
simultaneously many threads though only one CPU is used and switched
between HVM threads. It gives similar scalability to xbase++ threads
and also similar behavior in item protection at .prg level.
Now it's possible to use HVM threads in any OS.
Of course it does not mean that Harbour adds in some magic way
thread support to OS-es which does not support threads like DOS.
It only means that HVM supports threads for .prg code just like
in native MT environment as long as some C code does not block
task switching or process execution will not be frozen by sth, i.e.
executing other process (__run()) in single process OS like DOS.
In some cases it can be interesting alternative even in OS which
have native thread support.
All tests/mttest*.prg programs and speedtst --thread=<n> --scale
are executed correctly with new task switching just like with
OS native MT support.
Compilation with task switching in hbvmmt library can be forced
by HB_TASK_THREAD macro which also disable native OS threads
support.
For task context switching two alternative methods are used:
1) getcontext()/makecontext()/swapcontext() (SUSv2, POSIX.1-2001)
which is preferable because does not need any additional
hacks but not all OS-es supports these functions.
It's enabled by default in Linux builds.
2) setjmp()/longjmp() (POSIX, ISO 9899 (C99)) otherwise.
These functions are supported by most of C compilers
but there is no function to set new stack in saved context
so it's necessary to introduce for each architecure/C compiler
peace of code which makes it. Macro HB_TASK_STACK_INIT() in
task.c makes it. I defined this macro for x86@32 in DJGPP
Linux GCC and OpenWatcom builds. I tested OpenWatcom builds only
in DOS and Linux but probably it works in all x86@32 builds.
If someone is interesting in adding support for some other
platforms which does not support ucontext.h and 1-st methods
then please define above macro for them.
Have a fun with new toy ;-)
* harbour/source/vm/Makefile
* enabled hbvmmt in DJGPP and OpenWatcom DOS builds. It works well.
Viktor if possible please add support for -mt switch in hbmk2
in all builds even if we do not compile hbvmmt by default so
it can be used with DJGPP and OW and any other builds for which
someone enable hbtask.c though OS does not support threads.
* harbour/contrib/hbmzip/hbmzip.c
! fixed '[const] char|BYTE *' casting in DOS and OS2 builds
* harbour/doc/Makefile
! removed unexisting license.txt file
* harbour/include/hbapidbg.h
* do not export Harbour debugger functions. If someone wants to create
3-rd party debugger then we should agree the list of functions which
should be public.
* harbour/include/hbstack.h
* minor cleanup in some definitions
* harbour/include/hbdefs.h
+ added HB_DLL_ENTRY_POINT macro to set default DLL entry point for
different Windows compilers
* harbour/source/vm/maindllh.c
* harbour/source/vm/maindllp.c
* use HB_DLL_ENTRY_POINT macro
* harbour/include/hbsetup.h
* added internal macro to disable flatten optimization
* harbour/include/hbmath.h
* harbour/source/rtl/math.c
* make default math error handler function static
* harbour/include/hbatomic.h
+ added atomic inc/dec inline asm code to OW x86 builds
* harbour/source/rtl/console.c
* small code reorganization to not mix public and private function calls
* harbour/source/rtl/hbregex.c
* harbour/source/hbpcre/_hbpcreg.c
* do not use hb_xfree() function pointer directly to avoid problems
with different calling conventions.
* harbour/config/win/owatcom.cf
* harbour/config/os2/owatcom.cf
* removed unnecessary in recent OpenWatcom versions explicit wlink.lnk
including.
* INSTALL
* Moved Windows CE compilers into a separate section.
* bin/hb-mkdyn.bat
* Changes made to allow wce arch. (provision for wce arch)
* mpkg_win.bat
* Allows to override HB_ARCHITECTURE. (provision for wce arch)
+ Include arch in target directory. (provision for wce arch)
* include/hbatomic.h
- Turned off inline asm for _MSC_VER compilers in 64-bit mode. (pocc64, msvc64)
These target don't support inline asm.
This fixes previously reported regressions with these targets.
* utils/hbmk2/hbmk2.prg
% win/owatcom: Pentium Pro scheduling.
* win/owatcom: Temply set back stack calling convention.
* external/libhpdf/Makefile
- Disabled for pocc64 due to errors, even internal compiler error:
---
can't spill register variable: rcx (3) image
../../hpdf_image.c(480): fatal error: Internal error: best_spillee.
---
* config/win/bcc.cf
+ Added comment about -4, -5, -6.
* ChangeLog
! Minor fix to prev entry.
* harbour/include/hbatomic.h
! fixed inline assembler code for atomic inc/dec operations.
It's late and I haven't wrote anything in assembler using
Intel syntax for years.
* reenabled inline assembler code for atomic inc/dec operations
for POCC/XCC builds - such version should work. Please check.
* include/hbatomic.h
! Typo (__inline__ -> __inline).
! Temply disabled new _MSC_VER inline asm code, because it causes this with POCC5:
include\hbatomic.h(268): error #3114: [asm] Invalid combination of opcode and operands.
include\hbatomic.h(273): error #3114: [asm] Invalid combination of opcode and operands.
* harbour/include/hbatomic.h
+ added atomic inc/dec inline assembler code for 32bit MSVC builds
and probably also to other compilers which defines _MSC_VER
macro (XCC/POCC). Thanks to Viktor for help. Please make some tests.
* harbour/source/compiler/hbopt.c
! disabled one assert() in PCODE optimization code.
Mindaugas, I left note which explains why.
* harbour/config/darwin/gcc.cf
! changed CCACHE to HB_CCACHE
* harbour/include/hbatomic.h
! removed unnecessary volatile casting in Darwin atomic function
parameters
* harbour/source/compiler/harbour.y
! cleaned one untyped expression assign
(by Phil Krylov borrowed from xHarbour)
* harbour/bin/hb-func.sh
* updated contrib library last
* harbour/include/hbthread.h
* harbour/source/vm/thread.c
+ added hb_atomic_set(), hb_atomic_get(), hb_atomic_inc() and
hb_atomic_dec() functions which operates on HB_COUNTER or smaller
type if it's necessary for some platforms which can be access/assign
increment/decrement in MT safe atom operations.
hb_atomic_dec() returns true if counter is 0 after decrementation
* harbour/include/hbatomic.h
! fixed compilation in Linux and OpenWatcom
* harbour/include/hbapiitm.h
* harbour/source/rtl/itemseri.c
+ make hb_itemSerialize() and hb_itemDeserialize() public functions
! fixed serialization items with internal item references
* harbour/source/vm/hvm.c
* release memvars after closing RDDs
* harbour/source/debug/dbgentry.c
! fixed buffer overflow reported by Rodrigo
* harbour/source/vm/macro.c
* harbour/source/compiler/hbmain.c
* formatting
* harbour/include/hbexprb.c
! fixed wrongly recognized functions with HB_I18N_ prefix as
HB_I18N_GETTEXT()
* harbour/include/hbapi.h
* harbour/include/hbstack.h
* harbour/include/hbthread.h
* harbour/source/vm/estack.c
* harbour/source/vm/thread.c
* harbour/source/vm/hvm.c
+ added support for I18N in HVM.
Each thread can have it's own i18n set.
When new thread is created then it inherits i18n set from parent
thread and both uses the same set (please remember about it if you
will want to make some direct modifications on active i18n set
internals).
When thread change active i18n set then it effects only this thread
and new threads which will be create later. It does not change i18n
in other existing threads.
+ added functions to set/get pointer to active i18n set in HVM
void * hb_vmI18N( void )
void hb_vmSetI18N( void * )
* harbour/include/hbapi.h
* harbour/source/rtl/hbi18n.c
+ added i18n module. Now only for internal Harbour usage without support
for optional switching to alternative implementations.
I'll add such functionality later when I will work on native gettext
support.
The following public .prg functions has been added:
HB_I18N_GETTEXT[_STRICT]( <cMsgID> [, <cContext> ] )
-> <cTranslatedMsgID> | <cMsgID>
HB_I18N_NGETTEXT[_STRICT]( <nValue>, <cMsgID> | <acMsgID> ;
[, <cContext> ] )
-> <cTranslatedMsgID> | <cMsgID> | <acMsgID>[ <nIndex> ]
This is minimal support necessary for .prg code which has to exists
in each i18n module working with Harbour.
The following functions had been added as public C API:
PHB_ITEM hb_i18n_gettext( PHB_ITEM pMsgID, PHB_ITEM pContext )
PHB_ITEM hb_i18n_ngettext( PHB_ITEM pNum,
PHB_ITEM pMsgID, PHB_ITEM pContext )
The following functions had been added as private HVM C API:
void hb_i18n_init( void )
void hb_i18n_exit( void )
void hb_i18n_release( void * cargo )
void * hb_i18n_alloc( void * cargo )
They have to be supported by alternative i18n modules
The following functions has been added to manage Harbour i18n
translations sets:
HB_I18N_CREATE()
-> <pI18N>
Creates new empty I18N translation set
HB_I18N_CODEPAGE( [<pI18N>,] [<cNewCP>], [<lBase>], [<lTranslate>] )
-> <cOldCP>
Gets or sets Harbour codepage used by translation set
<pI18N> - I18N translation set,
if it's not given then currently active I18N set is used
<cNewCP> - new CP ID. Must be linked with application
<lBase> - when it's .T. then get/set base massages CP instead of
translated massages CP
<lTranslate> - if it's .T. then translate base (<lBase>==.T.) or
final messages in I18N set from previous CP to
given one. Base messages translation in synced
with context ID translation.
HB_I18N_PLURALFORM( [<pI18N>,] [<cNewForm>|<bNewForm>], [<lBase>] )
-> <cOldForm>|<bOldForm>
Gets or sets plural form used for final or base messages
<pI18N> - I18N translation set,
if it's not given then currently active I18N set is used
<cNewForm> - language ID of plural form, f.e.: "EN", "PL", "LT".
Now only three above are supported. Please add rules
for other languages to source/rtl/hbi18n.c.
<bNewForm> - codeblock used to calculate plural form indexes.
can be used instead of character representation but
it's not storred in serialized I18N set
<lBase> - when it's .T. then get/set base massages plural form
instead of translated massages one.
HB_I18N_DESCRIPTION( [<pI18N>,] [<cNewDescription>] )
-> <cOldDescription>
Gets or sets translation set description. After serialization
up to 32 bytes is stored in header which can be easy used to
determinate type of translation file.
<pI18N> - I18N translation set,
if it's not given then currently active I18N set is used
<cNewDescription> - new description
HB_I18N_ADDTEXT( <pI18N>, <cMsgID>, <cTrans> | <acTrans> [, <cContext> ] )
-> NIL
Adds new message with translation to i18n translation set
<pI18N> - I18N translation set
<cMsgID> - original message
<cTrans> - translated message
<acTrans> - array with translated messages used for plural forms
<cContext> - message context
HB_I18N_SET( [ <pI18N> | NIL ] )
-> <lActive>
Sets given I18N translation set as default one used by
HB_I18N_[N]GETTEXT[_STRICT]() functions or remove translation
set for calling thread when passed parameter is NIL
<pI18N> - I18N translation set
Returns logical value which is .T. when i18n set is active
HB_I18N_SAVETABLE( [<pI18N>] )
-> <cTable>
Returns I18N translation as string item which can be stored
in file or database
<pI18N> - I18N translation set, if it's not given then currently
active I18N set is used
HB_I18N_RESTORETABLE( <cTable> )
-> <pI18N> | NIL
Restores I18N translation set from strin item.
<cTable> - I18N translation set in string representation
On success it returns new <pI18N> set otherwise NIL if <cTable>
is not valid item created by HB_I18N_SAVETABLE() or it's corrupted.
HB_I18N_HEADERSIZE()
-> <nHeaderSize>
Returns size of header used by i18n serialized version
HB_I18N_CHEK( <cTable> | <cHeader> [, @<cDescription> ] )
-> <lValid>
<cTable> - i18n translation set serialized by HB_I18N_SAVETABLE
<cHeader> - header of i18n translation set
( LEFT( <cTable>, HB_I18N_HEADERSIZE() )
<cDescription> - optional parameter passed by reference where
will be sored i18n translation set description
extracted from valid header
Returns logical value indicating if given table or header is
valid serialized by HB_I18N_SAVETABLE() data. It does not
decode the table though it validates size and control sums.
These functions are optional and some future alternative implementations
may not support all of them and/or may provide some other functions.
+ added unofficial .prg function __I18N_HASHTABLE() which allows to
access hash table used by i18n translation set or create new translation
set with given hash table. It's helper functions for developers which
will work on Harbour i18n tools and should not be used by Harbour users.
Unlike original gettext Harbour allows to use language with many
plural forms as base one. In such case programmer should activate
at application startup default i18n translation set with base plural
form valid for base application language, f.e. by:
pI18N := hb_i18n_create()
hb_i18n_pluralForm( pI18N, <cLangID> | <bForm>, .t. )
hb_i18n_set( pI18N )
.prg code example:
#xtranslate _( <x,...> ) => hb_i18n_gettext_strict( <x> )
#xtranslate _N( <x,...> ) => hb_i18n_ngettext_strict( <x> )
proc main()
local pI18N, i
pI18N := hb_i18n_create()
hb_i18n_pluralForm( pI18N, "PL", .t. )
hb_i18n_set( pI18N )
for i := 0 to 30
? i, _N( i, {"grosz", "grosze", "groszy"} )
if i > 0 .and. i % 10 == 0
wait
endif
next
return
In .pot files created during compilation by Harbour with -j option
for above code we have the following entries for message with plural
forms:
msgid "grosz"
msgid_plural "grosze"
msgid_plural2 "groszy"
msgstr[0] ""
The msgid_plural2 (and others if language has more plural forms)
is Harbour extension which is not gettext compatible.
The above implementation is base version but should be fully functional.
Now we will need functions to safe/read i18n files and tools to mange
.pot files: merge them, edit translations, create final binary i18n
translation sets. Because we are using gettext compatible .pot files
then for some of such jobs we can use original gettext tools but we
need at least function which will create translation set from one or
more .pot files.
We should also agree some default localization(s) for files containing
translated data, their name convention and environment variable(s)
to set default language. It's not strictly necessary and each user
can have his own implementation but it would help in adding new
translations by final users to any Harbour application which will
respect them. We can use LANG envvar to extract preferred language
and use the same path as executed application looking for files
<appname>-<lang>.hil files though it may create some problems for
OSes which support only 8.3 file names so we can also define that
HB_I18N envvar has higher priority and points to expected translation
file.
* harbour/include/hbextern.ch
- removed old __i18n_*() functions
+ added current i18n functions
* harbour/include/hbatomic.h
+ added support for built in GCC atomic functions: __sync_*()
They are present in GCC >= 4.1 if given CPU supports them. For
x86 CPU family the ones we use need at least i486 CPU. Please make
tests with other CPUs like PPC. If given platform/CPU does not support
them then GCC generate call to function __sync_*_<N>() where <N>
is size of given type used in atomic operation instead of storing
inlined assembler code.
* harbour/include/Makefile
+ harbour/include/hbatomic.h
* harbour/include/hbthread.h
* harbour/source/vm/garbage.c
* harbour/source/vm/fm.c
* moved atomic and spinlock functions into hbatomic.h
* harbour/include/hbatomic.h
+ added atomic inc/dec for GCC and x86@64 and PPC@32
+ use OSAtomic*() and OSSpin*() functions for atomic inc/dec and
spinlocks in Darwin builds
+ added spinlocks to MS-Win builds
