date:20081102

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_PRESPARAMS // provides mechanism to configure windows
appearance and behavior
HB_GTI_ENABLE // enables window to receive input focus with
specified GT
HB_GTI_DISABLE // disables window to accept input focus with
specified GT
HB_GTI_SETFOCUS// sets the input focus to specified GT

+ Added HB_GT_PP structure supporting design-time presentation
parameters via HB_GTI_PRESPARAMS:
HB_GTI_PP_EXSTYLE // extended style of the window
HB_GTI_PP_STYLE// normal style of the window
HB_GTI_PP_X// left position by pixel | top position by row
HB_GTI_PP_Y// top position by pixel | left position by col
HB_GTI_PP_WIDTH// width of the window by pixel | number of rows
in window
HB_GTI_PP_HEIGHT // height of the window by pixel | number of
columns in window
HB_GTI_PP_PARENT // parent GT if window needs to be modal and/or
other usage
HB_GTI_PP_VISIBLE // flag to specify if the window is made visible
immediate after this call
HB_GTI_PP_ROWCOLS // flag to interpret X,Y,WIDTH,HEIGHT as
Top,Left,Rows,Cols

;IMPLEMENTS the behavioral changes to current GT window invoked
either by hb_gtCreate() or hb_gtSelect() functions by
specifying
an array of 9 elements ( bound to increase in future ) via
hb_gtInfo( HB_GTI_PRESPARAMS, aPresParams ) where

contains elements described as above:
1. ExStyleN [D] 0
2. Style N WS_OVERLAPPEDWINDOW
3. x[pxl] top[row]N 0
4. y[pxl] left[col] N 0
5. width[pxl] rows[row] N CW_USEDEFAULT
6. height[pxl] cols[col] N CW_USEDEFAULT
7. Parent GT P NIL
8. Visibility L FALSE
9. RowColsL FALSE
must be passed with all 9 elements even if
you want only few to be changed.

* harbour/contrib/gtwvg/tests/demowvg.prg
! Updated to demonstrate above concept to show up a modal dialog in the
same thread on top of a threaded window. Try to click on the parent
window.
will show up this modal dialog.

;NOTE : Please do not use literals to define members, always use
#defines from hbgtwvg.ch as it is a work in progress and is
possible
that few of the definitions may change in future.

Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/2008-11-02-00%3A40-UTC-0800-Pritpal-Bedi-%28pritpal%40vouchcac.com%29-tp20287680p20287680.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] i18n high level functions #2


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 layer uses
low level __i18n_loadfrommemory() (for default cases),
and __i18n_gettext().

hb_i18n_loadcallback( [ | NIL ] ) -> 
hb_i18n_baselang( [] ) -> 
hb_i18n_activelang( [] ) -> 
hb_i18n_gettext(  ) -> 
hb_i18n_gettextlang(  [,  ] -> 

Comments are welcome.

Brgds,
Viktor



hbi18nfn.prg
Description: Binary data
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] i18n high level functions

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 the core as it has some
> parts I wouldn't like to be included there, f.e. the
> file template system. Maybe a callback block would
> be better to pull a specific trs table however the
> user wants it. Comments are welcome.

Looks fine but domain support is a must.
It has to be also updated for MT mode. Here we should define
what is global and what thread local.
Resources like translation tables should be global but
base lang/active lang should be thread local.
Please also remember that we have HB_SETLANGUAGE()/_SET_LANGUAGE.
It can be used instead of introducing new settings.
The MT access will have to be protected so we will have to define
what can be changed at runtime, f.e. do we allow manipulations on
translation table body? If yes then which ones?
The next problem which should be resolved is CP support.
I do not like to have copy of all translation tables for each CPs
just like we have msg* modules so we should think about adding
support for CP translation. To reduce RT overhead we can add function
to translate existing trnaslation table. I do not think it will be
big problem.
Finally if we want to introduce to Harbour core code full i18n support
then IMHO we should also add C API for it.
I think that some upper level functions like translation tools or .pot
files manipulations can be written as .prg code so user can easy extend
it. The low level functions and hb_i18n_gettext*() for RT performance
should be written in C.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] i18n high level functions




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 included there, f.e. the
file template system. Maybe a callback block would
be better to pull a specific trs table however the
user wants it. Comments are welcome.


Looks fine but domain support is a must.
It has to be also updated for MT mode. Here we should define
what is global and what thread local.
Resources like translation tables should be global but
base lang/active lang should be thread local.


Yes. Possibly new threads should inherit from parent
threads.

Cache should naturally stay global, and this will
need mutex protection.


Please also remember that we have HB_SETLANGUAGE()/_SET_LANGUAGE.
It can be used instead of introducing new settings.


Okay. If so, we need to move this whole thing to C level.
This code is rather just a prototype anyway.


The MT access will have to be protected so we will have to define
what can be changed at runtime, f.e. do we allow manipulations on
translation table body? If yes then which ones?


No, I think the only means to change a translation body
is to force a reload. We may add such cache flushing
(not very elegant), or forced loading (not elegant
either), or just passing a flag to the load function
to signal if the translation is already cached and let
the app decide what do to. Reload can be as easy as
refill internals with passed in-memory table, if someone
really needs dynamic stuff, but otherwise (in normal
app code) translations very rarely change at runtime.
So IMO, the design should allow it, but it shouldn't
be optimized around it. Optimization should aim quick
loading and quick text translation.


The next problem which should be resolved is CP support.


Well yeah.


I do not like to have copy of all translation tables for each CPs
just like we have msg* modules so we should think about adding
support for CP translation. To reduce RT overhead we can add function
to translate existing trnaslation table. I do not think it will be
big problem.


Dunno, I have my own conversion functions (slow, but they
do the job), and relevant cp translation strings get loaded
from the .lng files. This is not ideal, but does the job.
We need to keep in mind that a given app can handle several
languages at a time, f.e. while printing an invoice in English
in Slovakia, obviously the progress message will be English,
the rest Slovak (base lang HU). I didn't follow Harbour when
CP support got implemented, so I don't know where it stands
now, and if I could personally use it instead of local
solution, or how could we connect to it.

Anyhow it needs to be solved. I'm secretly hoping for
Unicode, so part of this nightmare can be resolved forever.
(part of because you still have parts of the world which
needs non-unicode, like direct printing, so we will not get
around the topic anytime soon).


Finally if we want to introduce to Harbour core code full i18n support
then IMHO we should also add C API for it.


True.


I think that some upper level functions like translation tools or .pot
files manipulations can be written as .prg code so user can easy  
extend

it. The low level functions and hb_i18n_gettext*() for RT performance
should be written in C.


Yes, my C "fluency" is incomparable to yours, so maybe
I'm not the best candidate for this job :)

[ BTW, I'm currently very happy with the few low level
functions now rewritten plus my local support for this
area - in Clipper I was using a .dbf for translation -,
so any Harbour development is fully detached from
personal reasons, even the submitted code was made just
for Harbour. Of course I'd be happier to use the Harbour
parts as much as possible. ]

I'll check where codepage support stands currently.

See small attached test code for current state.

Brgds,
Viktor



testi18.prg
Description: Binary data


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-02 14:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

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
* Minor formatting.

  * source/codepage/cpcs852.c
  * source/codepage/cpsk852.c
  * source/codepage/cpcsiso.c
  * source/codepage/cpcswin.c
  * source/codepage/cpskiso.c
  * source/codepage/cpskwin.c
  * source/codepage/cpcskam.c
  * source/codepage/cpskkam.c
* Removed unnecessary ending ';'
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-02 13:36 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

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
  in TODO.

best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Harbour under OS/2 - OpenWatcom


>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
> definition. It's necessary for OpenWatcom. Please check how it
> will interact with other OS2 compilers (GCC)
>
>Please sync SVN repository and try to compile generating new log.

Thanks Przemek

Current Harbour code compile fine with gcc335 with just well known warnings

With OpenWatcom 1.7:
- Screen output
---
make[3]: *** [filesys.obj] Error 8
make[2]: *** [descend] Error 2
make[3]: *** [dynlibhb.obj] Error 8
make[2]: *** [descend] Error 2
make[3]: [hbrun.exe] Error 1 (ignored)
make[3]: [hbtest.exe] Error 1 (ignored)
make[3]: [hbdoc.exe] Error 1 (ignored)
make[3]: [hbmake.exe] Error 1 (ignored)
make[3]: *** [hbcrypt.obj] Error 8
make[2]: *** [descend] Error 2
---

. 33 libraries created
---
 2/11/08  3:30a79,360  0 a---  hbcommon.lib
 2/11/08  3:30a   351,744  0 a---  hbpp.lib
 2/11/08  3:31a   438,272  0 a---  hbcplr.lib
 2/11/08  3:31a87,040  0 a---  hbmacro.lib
 2/11/08  3:31a   124,928  0 a---  hbcpage.lib
 2/11/08  3:31a   299,520  0 a---  hblang.lib
 2/11/08  3:32a   314,880  0 a---  hbrdd.lib
 2/11/08  3:32a 6,144  0 a---  hbnulrdd.lib
 2/11/08  3:32a   105,472  0 a---  rddntx.lib
 2/11/08  3:33a   215,040  0 a---  rddcdx.lib
 2/11/08  3:33a57,856  0 a---  rddfpt.lib
 2/11/08  3:33a98,304  0 a---  hbsix.lib
 2/11/08  3:33a24,576  0 a---  hbhsx.lib
 2/11/08  3:33a86,528  0 a---  hbusrrdd.lib
 2/11/08  3:33a69,632  0 a---  hbextern.lib
 2/11/08  3:33a   182,784  0 a---  hbpcre.lib
 2/11/08  3:33a89,600  0 a---  hbzlib.lib
 2/11/08  3:34a   858,112  0 a---  hbdebug.lib
 2/11/08  4:03a   228,864  0 a---  hbbmcdx.lib
 2/11/08  4:03a43,520  0 a---  hbbtree.lib
 2/11/08  4:03a20,480  0 a---  hbclipsm.lib
 2/11/08  4:04a   359,936  0 a---  hbct.lib
 2/11/08  4:04a23,552  0 a---  hbdbgfx.lib
 2/11/08  4:05a69,632  0 a---  hbgfos2.lib
 2/11/08  4:05a20,480  0 a---  hbgt.lib
 2/11/08  4:05a   102,912  0 a---  hbmisc.lib
 2/11/08  4:05a64,512  0 a---  hbmzip.lib
 2/11/08  4:08a   851,456  0 a---  hbnf.lib
 2/11/08  4:09a   924,672  0 a---  hbtip.lib
 2/11/08  4:09a44,544  0 a---  hbtpathy.lib
 2/11/08  4:10a   568,832  0 a---  hbvpdf.lib
 2/11/08  4:10a27,648  0 a---  hbziparc.lib
 2/11/08  4:10a84,480  0 a---  hbmsql.lib
   33 file(s)   6,925,312 bytes used
---

- 2 executables created: harbour.exe, hbpp.exe

- Many references to "unreachable code", for example:
---
 dbjoin.c(188): Warning! W013: col(18) unreachable code
---

- New make_ow.log
Sent

David Macias

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Harbour under OS/2 - OpenWatcom


>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 OS2 builds - it's local GCC function
>* removed some header files from OS2 build - please test if it does
>  not break GCC builds

Thanks Przemek

Current Harbour code compile fine with gcc335 with just well known warnings

>Please test after:
>   2008-11-02 12:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

Done

>Side effect if -gc3 output. You can safely ignore them or use:
>   set PRG_USR=-gc0

Using:
 set PRG_USR=-gc0


> Warning! W1108: file E:\WATCOM/binp/wlink.lnk: line(3): system 286 
>defined more than once

>[...]
>Please try to remove from os2/owatcom.cf this line:
>   echo @%watcom%/binp/wlink.lnk >> __link__.tmp
>It's probably included by default and it causes repeated definitions.
>Please also note that this line:
>   Rem DAVID: echo LIB kernel32.lib, user32.lib, wsock32.lib, 
>winspool.lib, oleaut32.lib, uuid.lib, comctl32.lib, mapi32.lib >> 
>__link__.tmp

>is written to .lnk file. Looks that linker ignores it but please try to
>eliminate such situations - it make cause some unexpected results.

Removed both lines

With OpenWatcom 1.7:
- Screen output
---
make[3]: *** [hbmd5.obj] Error 8
make[2]: *** [descend] Error 2
make[3]: *** [thread.obj] Error 8
make[2]: *** [descend] Error 2
make[3]: [hbrun.exe] Error 1 (ignored)
make[3]: [hbtest.exe] Error 1 (ignored)
make[3]: [hbdoc.exe] Error 1 (ignored)
make[3]: [hbmake.exe] Error 1 (ignored)
make[3]: *** [hbcrypt.obj] Error 8
make[2]: *** [descend] Error 2
---

. 33 libraries created

- 2 executables created: harbour.exe, hbpp.exe

- New make_ow.log
Sent

David Macias


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom

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.pl)

> - 2 executables created: harbour.exe, hbpp.exe

Fine. The 1-st step.

> - Many references to "unreachable code", for example:
> ---
>  dbjoin.c(188): Warning! W013: col(18) unreachable code
> ---

Side effect if -gc3 output. You can safely ignore them or use:
   set PRG_USR=-gc0

> - New make_ow.log
> Sent

Thanks,

> Warning! W1108: file E:\WATCOM/binp/wlink.lnk: line(3): system 286 defined 
> more than once
[...]
Please try to remove from os2/owatcom.cf this line:
   echo @%watcom%/binp/wlink.lnk >> __link__.tmp
It's probably included by default and it causes repeated definitions.
Please also note that this line:
   Rem DAVID: echo LIB kernel32.lib, user32.lib, wsock32.lib, winspool.lib, 
oleaut32.lib, uuid.lib, comctl32.lib, mapi32.lib >> __link__.tmp
is written to .lnk file. Looks that linker ignores it but please try to
eliminate such situations - it make cause some unexpected results.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-02 14:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

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

[Harbour] 2008-11-02 12:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

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 OS2 builds - it's local GCC function
* removed some header files from OS2 build - please test if it does
  not break GCC builds

best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] MT - WorkAreas - A Feature Request


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 of nWA directly.
>>>

I did not realize it before, thanks for guiding.
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.

<<<
If you want to change the WA numbers allocating in Harbour RDD code
so they will be unique between threads then it's rather bad idea.
It will force blocking a lot of RDD code because we will need serialization
for everything what can allocate/release new WA. Many modifications,
bad performance/scalability overhead and new problems to resolve, f.e.
RT errors which can stop the thread with locked RDD internals.
>>>

I understand. I will change my methodology.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/MT---WorkAreas---A-Feature-Request-tp20268713p20290030.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] MT - WorkAreas - A Feature Request


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() and nWA ?
Multplying both will clash for given two threads as nWA is reused
once table is closed.

Regards
Pritpal Bedi
-- 
View this message in context: 
http://www.nabble.com/MT---WorkAreas---A-Feature-Request-tp20268713p20290105.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] MT - WorkAreas - A Feature Request


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 right ?

Regards
Pritpal Bedi
-- 
View this message in context: 
http://www.nabble.com/MT---WorkAreas---A-Feature-Request-tp20268713p20290173.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-02 16:33 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

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/codepage/uc1251.c
  * source/codepage/uc1252.c
  * source/codepage/uc8859_5.c
  * source/codepage/uckam.c
* Minor formatting.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-02 21:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

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/codepage/uc8859_9.c
  + source/codepage/uc885910.c
  + source/codepage/uc885911.c
  + source/codepage/uc885913.c
  + source/codepage/uc885914.c
  + source/codepage/uc885915.c
  + source/codepage/uc885916.c
+ Added remaining 8859 codepages.
  0x00-0x1F chars are unstandard (following existing files).

  * source/codepage/uc8859_1.c
  * source/codepage/uc8859_2.c
* Comments.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] codepage question to Przemek


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 uc1250 it's 0x09,
officially this position is UNDEFINED in both of these.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-02 22:24 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

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
  * source/codepage/uc852.c
  * source/codepage/uc857.c
  * source/codepage/uc866.c
  * source/codepage/uc8859_1.c
  * source/codepage/uc8859_2.c
  * source/codepage/uc8859_3.c
  * source/codepage/uc8859_4.c
  * source/codepage/uc8859_5.c
  * source/codepage/uc8859_6.c
  * source/codepage/uc8859_7.c
  * source/codepage/uc8859_8.c
  * source/codepage/uc8859_9.c
  * source/codepage/uc885910.c
  * source/codepage/uc885911.c
  * source/codepage/uc885913.c
  * source/codepage/uc885914.c
  * source/codepage/uc885915.c
  * source/codepage/uc885916.c
  * source/codepage/uc88591b.c
  * source/codepage/uckam.c
  * source/codepage/uckoi8.c
  * source/codepage/uckoi8u.c
  * source/codepage/ucmaz.c
  * source/codepage/ucmik.c
* Formatting.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-02 22:45 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

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
  * source/codepage/uc852.c
  * source/codepage/uc857.c
  * source/codepage/uc866.c
  * source/codepage/uc8859_1.c
  * source/codepage/uc8859_2.c
  * source/codepage/uc8859_3.c
  * source/codepage/uc8859_4.c
  * source/codepage/uc8859_5.c
  * source/codepage/uc8859_6.c
  * source/codepage/uc8859_7.c
  * source/codepage/uc8859_8.c
  * source/codepage/uc8859_9.c
  * source/codepage/uc885910.c
  * source/codepage/uc885911.c
  * source/codepage/uc885913.c
  * source/codepage/uc885914.c
  * source/codepage/uc885915.c
  * source/codepage/uc885916.c
  * source/codepage/uc88591b.c
* Formatting.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: codepage question to Przemek


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 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 uc1250 it's 0x09,
officially this position is UNDEFINED in both of these.

Brgds,
Viktor



___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: codepage question to Przemek


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,
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 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 uc1250 it's 0x09,
officially this position is UNDEFINED in both of these.

Brgds,
Viktor





___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-02 23:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

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.c
  + source/codepage/uc864.c
  + source/codepage/uc775.c
  + source/codepage/uc1255.c
  + source/codepage/uc861.c
  + source/codepage/uc863.c
  + source/codepage/uc865.c
  + source/codepage/uc869.c
+ Added missing IBM/Windows codepages.

  * source/rtl/cdpapi.c
* Formatting.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom

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) 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:
   typedef charBYTE, *PBYTE, *NPBYTE;
By default in OpenWatcom 'char' is unsigned but looks that it does not
like such conversion. I hope that you haven't enabled -j OpenWatcom switch.
It will break final binaries. Unfortunately we are using BYTE as synonym
of 'unsigned char' in many places. I introduced UCHAR / SCHAR and
systematically update BYTE used in number context to UCHAR but there is
still a lot of code which have to be updated.
In this case it should not be a problem because it's buffer so I'll add
casting which will pacify the warnings/error message but we should keep
in mind that BYTE in some platforms can be signed and we should continue
code updating. The same is with pure 'char' casting. It can be signed or
unsigned type, it's platform/C compiler dependent so we always should
use 'unsigned char' (UCHAR) or 'signed char' (SCHAR) if sign is important.
But this I fixed few years ago and now it's only reminder for new code.

> make[3]: *** [thread.obj] Error 8

../../thread.c(1240): Error! E029: col(60) symbol '_gettid' has not been 
declared

_gettid() is GCC local function.
I do not see function which returns directly thread ID in OS2 API.
Probably it can be extracted from TIB structure returned by
DosGetInfoBlocks(). I cannot find simpler method. Maurilio can you help?

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-03 00:56 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

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 list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Harbour under OS/2 - OpenWatcom


> ../../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:
>typedef charBYTE, *PBYTE, *NPBYTE;
> By default in OpenWatcom 'char' is unsigned but looks that it does not
> like such conversion. I hope that you haven't enabled -j OpenWatcom
> switch.

Not touched
Checked:
#CPPFLAGS = -j -w3 -d2 -5s -5r -fp5 -oxehtz -zq -zt0 -mf -bt=NT
CPPFLAGS = -w2 -d1 -zq -bt=OS2

>It will break final binaries. Unfortunately we are using BYTE as synonym
>of 'unsigned char' in many places. I introduced UCHAR / SCHAR and
>systematically update BYTE used in number context to UCHAR but there is
>still a lot of code which have to be updated.
>In this case it should not be a problem because it's buffer so I'll add
>casting which will pacify the warnings/error message but we should keep
>in mind that BYTE in some platforms can be signed and we should continue
>code updating. The same is with pure 'char' casting. It can be signed or
>unsigned type, it's platform/C compiler dependent so we always should
>use 'unsigned char' (UCHAR) or 'signed char' (SCHAR) if sign is 
>important.

>But this I fixed few years ago and now it's only reminder for new code.

As I see is a known problem, C compiler dependent, and work in progress 
to update code


> make[3]: *** [thread.obj] Error 8

>../../thread.c(1240): Error! E029: col(60) symbol '_gettid' has not been
>declared

>_gettid() is GCC local function.
>I do not see function which returns directly thread ID in OS2 API.
>Probably it can be extracted from TIB structure returned by
>DosGetInfoBlocks(). I cannot find simpler method. Maurilio can you help?

OK

>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

Thanks Przemek

Current Harbour code compile fine with gcc335 with just well known warnings

With OpenWatcom 1.7:
- Screen output
---
make[3]: *** [hbinet.obj] Error 9
make[2]: *** [descend] Error 2
make[4]: *** [thread.obj] Error 8
make[3]: *** [descend] Error 2
make[2]: *** [first] Error 2
make[3]: [hbrun.exe] Error 1 (ignored)
make[3]: [hbtest.exe] Error 1 (ignored)
make[3]: [hbdoc.exe] Error 1 (ignored)
make[3]: [hbmake.exe] Error 1 (ignored)
make[3]: *** [hbcrypt.obj] Error 8
make[2]: *** [descend] Error 2
---

. 34 libraries created (one more)

- 2 executables created: harbour.exe, hbpp.exe

- New make_ow.log
Sent

David Macias


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] codepage and RDD


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 RDD CP is global to an app's
database.

Right now I'm using hb_setcodepage(), but this
may not be enough given that it could depend on
UI/app language, so it may be bit different than
db cp (which is not ideal, but may happen).

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: C53b vs Harbour and VBox shared folders


[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 ) while the
>same apps ( with many #ifdef of course )  hang at start with Harbour.
>If I copy the data in the VM C: drive they work of course.

>I've tried to use gdb but it simply hang and often the entire VM need
>to be closed.

>Clearly it is not an Harbour problem but since C53b works it would be
>nice to know where the "problem" can be so I could try to forward the
>info to the Sun's developers.

[Przemek]
>I also think that file locking is 1-st candidate.
>Try to isolate the problem with small example which
>creates/open DBF with indexes.

I have about six months using Mandriva 2008.1 - VirtualBox - WinXPPSP2, 
started with VBox 1.5.6 and now is 2.0.4


All this time I used Samba/shares to access NTFS/FAT32 partitions with 
WinXPPSP2 VM and everything work fine with Harbour and disk access


Now I replaced Samba/shares with "Shared Folders" and running same 
programs WinXPPSP2 reboot with screen "to protect itself" ( a text 
screen with a lot of info about drivers failures, ... and reboot to 
protect )


This failure happen using:
  nHandler := FOPEN( cDestino, FO_READWRITE+FO_SHARED )
and NOT using DBF/CDX files

Other program work fine using DBF/CDX files, not tested writing on file

As I can see there are a problem with Shared Folders / Harbour disk access

David Macias

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-11-03 08:57 UTC+0200 Viktor Szakats (harbour.01 syenar hu)