2008-11-03 08:57 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* common.mak
* source/codepage/Makefile
+ source/codepage/cproiso.c
+ source/codepage/cpfriso.c
+ source/codepage/cpfrwin.c
+ Added new CPs.
- source/codepage/cphr1250.c
+ source/codepage/cphrwin.c
* Renamed to f
[Lorenzo]
I'm using Sun's VBox 2.0.4 under Ubuntu 8.04 with a Win2000Sp4 VM.
>I use it to maintain C53b/FW16 apps and to build Harbour using
>msys/mingw and I access datas that are in the host ( Ubuntu ) using
>VBox's shared folders.
>Now if I build the apps using C53b/Fw16 they work ( slowly )
Hi Przemek and all,
Shouldn't we add a way to set the default
codepage for RDD operations?
Right now I could pass it to each RDD function
call (like dbCreate()) but that needs touching
all such possible calls (which is error prone),
moreover using a "dirty" parameter extension.
Also, usually the
> ../../hbmd5.c(328): Error! E473: col(22) function argument(s) do not
> match those in prototype
> ../../hbmd5.c(328): Note! N392: col(22) definition: 'unsigned long
> hb_fsReadLarge( int, char *, unsigned long )'
> And we have a problem.
> In OpenWatcom header files BYTE is defined as:
>typ
2008-11-03 00:56 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/thread.c
+ added temporary workaround for non GCC OS2 ST builds
* harbour/source/rtl/hbmd5.c
* casting cleanup
best regards
Przemek
___
Harbour mailing
On Sun, 02 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Current Harbour code compile fine with gcc335 with just well known warnings
Thanks,
> With OpenWatcom 1.7:
> - Screen output
> ---
> make[3]: *** [hbmd5.obj] Error 8
../../hbmd5.c(328): Error! E473: col(22)
2008-11-02 23:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbapicdp.h
* common.mak
* source/codepage/Makefile
+ source/codepage/uc855.c
+ source/codepage/uc874.c
+ source/codepage/uc1256.c
+ source/codepage/uc1258.c
+ source/codepage/uc860.c
+ source/codepage/uc862.
and in some places 0xFFFD is used, which is "REPLACEMENT CHAR"
I think we should sync all the cps in this regard.
Brgds,
Viktor
On 2008.11.02., at 22:49, Szakáts Viktor wrote:
Sorry, 1253 and 1254 are counter examples, but the
trend really looks like to leave these positions
0x.
Brgds,
V
Sorry, 1253 and 1254 are counter examples, but the
trend really looks like to leave these positions
0x.
Brgds,
Viktor
On 2008.11.02., at 22:12, Szakáts Viktor wrote:
Hi Przemek,
I'm converting a few remaining Unicode conversion tables
to the Harbour format, but I cannot decide based on th
2008-11-02 22:45 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/codepage/uc1250.c
* source/codepage/uc1251.c
* source/codepage/uc1252.c
* source/codepage/uc1253.c
* source/codepage/uc1254.c
* source/codepage/uc1257.c
* source/codepage/uc737.c
* source/codepage/uc850.c
* s
2008-11-02 22:24 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/codepage/uc1250.c
* source/codepage/uc1251.c
* source/codepage/uc1252.c
* source/codepage/uc1253.c
* source/codepage/uc1254.c
* source/codepage/uc1257.c
* source/codepage/uc737.c
* source/codepage/uc850.c
* s
Hi Przemek,
I'm converting a few remaining Unicode conversion tables
to the Harbour format, but I cannot decide based on the
existing ones, whether the correct behavior for non-defined
Unicode char positions should be zero or the normal ASCII
char itself?
F.e. 0x90 in uc1257.c is zero, while in
2008-11-02 21:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbapicdp.h
* common.mak
* source/codepage/Makefile
+ source/codepage/uc8859_3.c
+ source/codepage/uc8859_4.c
+ source/codepage/uc8859_6.c
+ source/codepage/uc8859_7.c
+ source/codepage/uc8859_8.c
+ source/co
2008-11-02 16:33 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbextern.ch
* common.mak
* source/codepage/Makefile
+ source/codepage/cpro852.c
+ source/codepage/cprowin.c
+ Added Romanian codepages.
; TODO: Add ROISO variant.
* source/codepage/uc1250.c
* source/cod
Hi
<<<
Ho can I generate a unique number given ThreadID() and nWA ?
Multplying both will clash for given two threads as nWA is reused
once table is closed.
>>>
As maximum limit of workareas per thread is 65534, I can safely
define macro as
#define MYWORKAREA( nWA ) ( ThreadID() * nWA )
Am I
Hello
<<<
The relevant question:
What happens when a thread is finished - its thread id is reused ?
Or any new thread have unique ID? I did not experiment to check.
>>>
I was too fast. ThreadID() is always unique. This is good.
Now the question:
Ho can I generate a unique number given ThreadID()
Przemek
<<<
Probably I do not understand what you need. If you want to add unique
for all thread number which is you low level table ID into each open WA
then simply add it to your RDD local workarea structure and extract it:
nTableNO := USRRDD_AREADATA( nWA )[ MYWA_TABLE ]
and use it instead
2008-11-02 14:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbextern.ch
! Readded HB_LANG_EN.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
2008-11-02 14:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbextern.ch
! Added all missing LANG and CODEPAGE modules.
[TOMERGE 1.0]
* ChangeLog
- Removed duplicate entry of mine.
* source/common/hbstr.c
* source/rtl/version.c
* source/rtl/filesys.c
* Min
>2008-11-02 12:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> * harbour/source/vm/dynlibhb.c
>* forced casting in OS2 builds to eliminate problems with possible
> differences between compilers in 'char' type sign
> * harbour/source/rtl/filesys.c
>! use _getcwd1() only in
Hi Przemek,
Pls find attached high level i18n_* functions. (untested)
hb_i18n_fnametemplate( [] ) ->
hb_i18n_baselang( [] ) ->
hb_i18n_activelang( [] ) ->
hb_i18n_gettext( ) ->
hb_i18n_gettextlang( [, ] ->
Not strictly intended for the core as it has some
parts I wouldn't like to be in
2008-11-02 13:36 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbexprb.c
! fixed possible GPF/internal memory corruption in code like:
? HB_I18N_GETTEXT_NOOP( "Ala ma kota" + " !!!" )
Mindaugas, the fix is also the answer for the question you left
On Sat, 01 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
> Pls find attached high level i18n_* functions. (untested)
> hb_i18n_fnametemplate( [] ) ->
> hb_i18n_baselang( [] ) ->
> hb_i18n_activelang( [] ) ->
> hb_i18n_gettext( ) ->
> hb_i18n_gettextlang( [, ] ->
> Not strictly intended for t
Hi all,
Pls find attached high level i18n_* functions.
Now, instead of a filename template, a translation
loader callback can be specified by the user, so
the actual source of the translation is completely
controllable from the user side. The block is getting
the language ID as a parameter. This
On Sun, 02 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> With OpenWatcom 1.7:
> - Screen output
> ---
> make[3]: *** [filesys.obj] Error 8
> make[3]: *** [dynlibhb.obj] Error 8
Please test after:
2008-11-02 12:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.p
2008-11-02 12:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/dynlibhb.c
* forced casting in OS2 builds to eliminate problems with possible
differences between compilers in 'char' type sign
* harbour/source/rtl/filesys.c
! use _getcwd1() only in GCC OS
>Looks that OpenWatcom for OS2 does not enable LONGLONG support
>by default. I've just committed:
> 2008-11-01 15:20 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> * harbour/include/hbdefs.h
> + added #define INCL_LONGLONG to include native compiler LONGLONG
> definitio
2008-11-02 00:40 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])
* harbour/contrib/gtwvg/gtwvg.c
* harbour/contrib/gtwvg/gtwvg.h
* harbour/contrib/gtwvg/hbgtwvg.ch
* harbour/contrib/gtwvg/wvgpaint.prg
! Synchronized with GTWVT.
+ Added HB_GTI_* hb_gtInfo() constants:
HB_GTI_PR
28 matches
Mail list logo
