On Wed, 10 Feb 2010, 2D Info - Leandro Damasio wrote:
Hi,
> >But in the .prg code used for EXE file when you are calling
> >functions which do not exist in it and are loaded dynamically
> >then all such functions should be declared as DYNAMIC otherwise
> >you will have link time error (function d
Przemek:
>> Something has changed for this case since Aug 2007 ?
>I created new code for MT mode which also can use BSD or POSIX locks
>for deny flags emulation so now it works between aliased work areas
>even in single process.
>This code were copied from Harbour repository to xHarbour CVS by:
Revision: 13842
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13842&view=rev
Author: vszakats
Date: 2010-02-11 11:33:10 + (Thu, 11 Feb 2010)
Log Message:
---
2010-02-11 12:32 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* src/rtl/direct.c
* in
Revision: 13843
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13843&view=rev
Author: vszakats
Date: 2010-02-11 11:37:58 + (Thu, 11 Feb 2010)
Log Message:
---
2010-02-11 12:37 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbwin/wapi_wingdi
Przemek:
>Any you want. DBT allows to store only strings and uses 512 bytes
>blocks. FPT allows to store also other data types (numbers, dates,
>arrays, ...) and user can set block size (default is 64 bytes) so it's
>more flexible and creates smaller files.
>It also contains garbage collector whi
On Thu, 11 Feb 2010, jara...@users.sourceforge.net wrote:
Hi Xavi,
> 2010-02-11 04:25 UTC+0100 Xavi (jarabal/at/gmail.com)
> * contrib/hbwin/wapi_winbase.c
> + Added wapi_GETSHORTPATHNAME()
Thank you very much. Just only few notes.
WAPI_* functions should be as closed to original implement
Hi Xavi,
On 2010 Feb 11, at 05:20, Xavi wrote:
> Hi Viktor,
>
>> You've introduced a new permanently set macro called HB_OS_WIN64_32,
>> redefined a Harbour type (which should be avoided by all means)
>
> Is to work with win64 implementation in win32 with minimal changes.
> If the system is win
I made tests with
* $Id: ChangeLog 13841 2010-02-11 03:26:15Z jarabal $
2010-02-11 04:25 UTC+0100 Xavi (jarabal/at/gmail.com)
and new os2gcc442
- I saw there are new libraries in Harbour
- So os2gcc reach 32K limit again and harbourm.dll can not build
Except for harbourm.dll build error, Harb
On Thu, 11 Feb 2010, David Arturo Macias Corona wrote:
Hi,
> Thanks, with these explanations now is more clear:
> - In Linux nothing prevent two applications open file in EXCLUSIVE
> from each side
No. In Linux and other POSIX system there is no EXCLUSIVE mode at all.
Only shared mode exists tho
On Thu, 11 Feb 2010, David Arturo Macias Corona wrote:
Hi,
> g) Why Clipper and Harbour show different ? :
> SET( _SET_MBLOCKSIZE ) 64
> SET( _SET_MBLOCKSIZE ) 0
> It must be fixed ?
0 means use RDD default. 64 for FPT and 32 for SMT.
best regards,
Przemek
__
Hi David,
On 2010 Feb 11, at 12:58, David Arturo Macias Corona wrote:
> I made tests with
> * $Id: ChangeLog 13841 2010-02-11 03:26:15Z jarabal $
> 2010-02-11 04:25 UTC+0100 Xavi (jarabal/at/gmail.com)
>
> and new os2gcc442
>
> - I saw there are new libraries in Harbour
> - So os2gcc reach 32K
Revision: 13844
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13844&view=rev
Author: vszakats
Date: 2010-02-11 12:12:51 + (Thu, 11 Feb 2010)
Log Message:
---
2010-02-11 13:12 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* external/libhpdf/Makefile
>But in the .prg code used for EXE file when you are calling
>functions which do not exist in it and are loaded dynamically
>then all such functions should be declared as DYNAMIC otherwise
>you will have link time error (function does not exist).
In my case of use the functions in the DLL are call
As Paul Smedley was releasing os2gcc404, os2gcc432, os2gcc433, os2gcc440
I was testing Harbour with them
Later my choice was to use Harbour+os2gcc433 as reference and Harbour
2.0.0 for OS/2 was released with this version too
Since Dec 2009 are available os2gcc434 and os2gcc442
I tested them
On Thu, 11 Feb 2010, Leandro Damasio wrote:
Hi,
> >It will work but I do not understand how it's possible to call
> >function by macro knowing it's name when macro value is created
> >but in other context you do not know this name. Your above
> >description does not make any sense or you simply f
Przemek:
>Yes but now there are some other problems in data sharing.
>We have fixed CP support so it's not possible to share data
>with xHarbour applications which uses incompatible CP implementation.
>It will cause index file corruption so it's necessary to precisely
>verify if both application
Przemek:
>> g) Why Clipper and Harbour show different ? :
>> SET( _SET_MBLOCKSIZE ) 64
>> SET( _SET_MBLOCKSIZE ) 0
>> It must be fixed ?
>0 means use RDD default. 64 for FPT and 32 for SMT.
Along years we know that but reference may vary
For example, in Clipper 5.3
Viktor:
>> - So os2gcc reach 32K limit again and harbourm.dll can not build
>:( I could be seen in advance. I can't give any solution,
>but I hope someone will.
As expected, Harbour has grown and can not fit in 32K limit :-)
>I'll suppress the libharu warnings.
Thanks
David Macias
___
On Thu, 11 Feb 2010, David Arturo Macias Corona wrote:
Hi,
> Not only locking-scheme problem but proper CP implementation too
> So to share data files between Harbour and xHarbour (or some other
> systems) is a big risk of data corruption
Just like between Harbour and Harbour or Clipper and Clip
On Thu, 11 Feb 2010, David Arturo Macias Corona wrote:
> This old Clipper code of my friend does not apply in Harbour:
> IF SET( _SET_MBLOCKSIZE )<> 64
>SET( _SET_MBLOCKSIZE, 64 )
It perfectly works in Harbour forcing 64 bytes block size.
best regards,
Przemek
___
Hello Przemek
>It will work but I do not understand how it's possible to call
>function by macro knowing it's name when macro value is created
>but in other context you do not know this name. Your above
>description does not make any sense or you simply forgot to say
>about some important condit
Pritpal continue "highly focused in hbide" and other people does not
have hints for this case:
---
d) hbqt
List of source files which have errors on OS/2 and detailed flow of tests
Alternatives:
- Fix source code
- Perhaps this code does not work on OS/2 - Qt
But
Hi,
few times per year we find corrupted .fpt files in databeses of our
customers. The problem is that this corruption is not detected by driver
and causes strange behavior. For example, application hangs-up, but do
not GPFs. After some tests we found, that it "hangs-up" because it uses
a hu
Mindaugas Kavaliauskas wrote:
USHORT uiField = hb_parni( 1 );
ULONG ulBlock, ulSize, ulType;
BOOL bDeleted;
Viktor will kill you if he sees these :)
Cheers
Alex
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http:
> Mindaugas Kavaliauskas wrote:
>
>> USHORT uiField = hb_parni( 1 );
>> ULONG ulBlock, ulSize, ulType;
>> BOOL bDeleted;
>
> Viktor will kill you if he sees these :)
It won't compile, so such harsh action is not necessary ;)
But yes, you are right, and I forgot to send a specific
message about
Hi Przemek and All,
We have this decision left regarding new types,
and I'd like to clear it.
We currently have two types which are mapped to
the same ANSI C type 'unsigned char'.
IMO if we want to keep both, we should give some
clear guideline to Harbour and 3rd party developer,
as to which
David,
this is something in gcc4 on OS/2, with my old GCC 3.3.5 and latest make I can
build harbour.dll and harbourm.dll without problems.
Directory of E:\REPOSITORY\HARBOUR\bin\os2\gcc
11/02/10 13:44 124 .
11/02/10 13:27 124 ..
11/02/10 13:41 3.866.628
Maurilio:
>this is something in gcc4 on OS/2, with my old GCC 3.3.5 and latest
>make I can build harbour.dll and harbourm.dll without problems.
>Directory of E:\REPOSITORY\HARBOUR\bin\os2\gcc
>11/02/10 13:41 3.866.628124 a--- harbour.dll
>11/02/10 13:44 3.874.820124 a--- har
Maurilio:
this is something in gcc4 on OS/2, with my old GCC 3.3.5 and latest
make I can build harbour.dll and harbourm.dll without problems.
Directory of E:\REPOSITORY\HARBOUR\bin\os2\gcc
11/02/10 13:41 3.866.628124 a--- harbour.dll
11/02/10 13:44 3.874.820124 a--- har
I agree with the uniqueness of the type, but i like HB_UCHAR.
The 'unsigned' qualifier is declared, despite of HB_BYTE (signed or
unsigned?).
I know that it's more familiar, but not so precise as the HB_UCHAR (leaving
no doubt about the sign).
Maurizio la Cecilia
> -Messaggio
Maurizio la Cecilia wrote:
I agree with the uniqueness of the type, but i like HB_UCHAR.
The 'unsigned' qualifier is declared, despite of HB_BYTE (signed or
unsigned?).
I know that it's more familiar, but not so precise as the HB_UCHAR (leaving
no doubt about the sign).
For me, HB_BYTE implies
Hi Viktor,
That can work, but it means we don't support int64/double
parameters and int64/double/float/char return values anymore.
Currently we do, so maybe it'd be good to take care of it.
We should also support both cdecl and stdcall versions.
Yes I know, this is not perfect.
Also I just t
When I try to run an MT app that works perfectly under Linux I get the
error below ( even with -g Harbour rebuild ).
If I link against harbour.dll it works as expected.
Win offers to send the error to MS and gives a long dump of info.
Any idea?
best regards,
Lorenzo
[New thread 2348.0xe40]
war
David Arturo Macias Corona wrote:
>
> Pritpal continue "highly focused in hbide" and other people does not
> have hints for this case:
>
I know nothing about OS2 and hence not in a position to comment.
One point which comes in mind is that Harbour is supporting Qt 5.5.3
and your experiments
Hi All,
Does 'For Each' require variables to be local defined?
proc test
local ary := {1,2,3}
local n << with out this line a RTE Error BASE/1003 Variable does not
exist: N will occour
for each n in ary
? n
Next
Thanks
Abe
--
View this message in context:
http://n2.
David,
I've reviewed your messages, I think 32K is environment size limit for OS/2
processes; so, maybe os2gcc and/or ld receive something as an envvar and this
is now bigger than 32Kb :(
Maurilio.
David Arturo Macias Corona wrote:
> Maurilio:
>
>> this is something in gcc4 on OS/2, with my ol
Revision: 13845
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13845&view=rev
Author: vszakats
Date: 2010-02-11 17:18:40 + (Thu, 11 Feb 2010)
Log Message:
---
2010-02-11 18:17 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbwin/win_dll.c
Revision: 13846
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13846&view=rev
Author: vszakats
Date: 2010-02-11 17:41:28 + (Thu, 11 Feb 2010)
Log Message:
---
2010-02-11 18:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbwin/win_dll.c
Revision: 13847
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13847&view=rev
Author: vszakats
Date: 2010-02-11 17:49:24 + (Thu, 11 Feb 2010)
Log Message:
---
2010-02-11 18:48 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbwin/win_dll.c
On Thu, 11 Feb 2010, AbeB wrote:
Hi,
> Does 'For Each' require variables to be local defined?
No.
> proc test
> local ary := {1,2,3}
> local n << with out this line a RTE Error BASE/1003 Variable does not
> exist: N will occour
> for each n in ary
> ? n
> Next
Pefect behavior. No 'n' va
Hi Przemek and All,
IMO it would be more consistent behavior to create a private
variable in such case, since with regular FOR/NEXT it also
works without declaring the variable:
--- OK
FOR tmp := 1 TO Len( a )
NEXT
---
--- Not OK
FOR EACH tmp IN a
NEXT
---
'tmp' is a written variable in both
Revision: 13848
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13848&view=rev
Author: vszakats
Date: 2010-02-11 18:35:25 + (Thu, 11 Feb 2010)
Log Message:
---
2010-02-11 19:33 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbwin/win_dll.c
Hi,
Alex Strickland wrote:
USHORT uiField = hb_parni( 1 );
ULONG ulBlock, ulSize, ulType;
BOOL bDeleted;
Viktor will kill you if he sees these :)
I have alibi. This code is created half year ago :)
Regards,
Mindaugas
___
Harbour mailing list (at
On Thu, 11 Feb 2010, Szak�ts Viktor wrote:
Hi,
> IMO it would be more consistent behavior to create a private
> variable in such case, since with regular FOR/NEXT it also
> works without declaring the variable:
> --- OK
> FOR tmp := 1 TO Len( a )
> NEXT
Because you have explicit assignment ':=
> tmp in FOR EACH is only reference.
> Why we should create variable for such reference in FOR EACH
> but not in function call?, i.e.:
>
> func( @tmp )
> ? tmp
>
> 'tmp' is also "a written variable" like in above both cases.
>
> Of course if most of Harbour users prefer to create new memvar
Przemysław Czerpak wrote:
>
> Personally I even think that FOR EACH should use their own temporary
> variables instead of declared ones. It will be much cleaner and faster.
>
+1
-
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_desig
http://msdn.microsoft.com/en-us/library/dd465215(VS.100).aspx
http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx
(interesting to see their IDE improvements. better late
than never)
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB
Hi Przemek,
Ok, I'll do it ...more slowly :)
Best regards,
--
Xavi
El 11/02/2010 12:48, Przemysław Czerpak escribió:
On Thu, 11 Feb 2010, jara...@users.sourceforge.net wrote:
Hi Xavi,
2010-02-11 04:25 UTC+0100 Xavi (jarabal/at/gmail.com)
* contrib/hbwin/wapi_winbase.c
+ Added wapi_G
On Thu, 11 Feb 2010, Szak�ts Viktor wrote:
Hi,
> We have this decision left regarding new types,
> and I'd like to clear it.
> We currently have two types which are mapped to
> the same ANSI C type 'unsigned char'.
>
> IMO if we want to keep both, we should give some
> clear guideline to Harb
>> IMO if we want to keep both, we should give some
>> clear guideline to Harbour and 3rd party developer,
>> as to which should be used in what situations.
>>
>> If we cannot do so, or if there is indeed no clear
>> different between them (meaning they are equivalent),
>> we should keep only
On Thu, 11 Feb 2010, Mindaugas Kavaliauskas wrote:
Hi,
> few times per year we find corrupted .fpt files in databeses of our
> customers. The problem is that this corruption is not detected by
> driver and causes strange behavior. For example, application
> hangs-up, but do not GPFs. After some t
Hi Xavi and All,
On 2010 Feb 11, at 16:23, Xavi wrote:
> Hi Viktor,
>
>> That can work, but it means we don't support int64/double
>> parameters and int64/double/float/char return values anymore.
>>
>> Currently we do, so maybe it'd be good to take care of it.
>>
>> We should also support both
Hi Viktor,
I can easily implement pure .c win32 .dll call support
which drops support for int64/double parameters and
int64/double/float return values. I'd also guess they
are not very widely used, so it's probably not a big
loss.
I agree. If need it, is better to have a specific wrapper.
Bes
Hi Xavi,
> Hi Viktor,
>
>> I can easily implement pure .c win32 .dll call support
>> which drops support for int64/double parameters and
>> int64/double/float return values. I'd also guess they
>> are not very widely used, so it's probably not a big
>> loss.
>
> I agree. If need it, is better to
54 matches
Mail list logo
