[Harbour] SF.net SVN: harbour-project:[14627] trunk/harbour

[vszakats]

Revision: 14627
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14627&view=rev
Author:   vszakats
Date: 2010-05-28 06:19:26 + (Fri, 28 May 2010)

Log Message:
---
2010-05-28 08:19 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbwin/hbolesrv.hbc
  * utils/hbmk2/hbmk2.prg
* Renamed ${hb_filename} macro to ${hb_self}.

  * contrib/hbcomm/hbcomm.prg
! Typo in comment.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbcomm/hbcomm.prg
trunk/harbour/contrib/hbwin/hbolesrv.hbc
trunk/harbour/utils/hbmk2/hbmk2.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14626] trunk/harbour

[vszakats]

Revision: 14626
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14626&view=rev
Author:   vszakats
Date: 2010-05-28 06:14:11 + (Fri, 28 May 2010)

Log Message:
---
2010-05-28 08:13 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
+ Added ${hb_filename} macro.
+ "hbexe", "hblib", "hbdyn", "hbdynvm", "hbimplib" can now
  be used as filter keywords to detect target type.

  * contrib/hbwin/hbolesrv.hbc
+ Will now show warning message if not used together with
  -hbdynvm option.
+ Will will now be ignored if not used together with
  -hbdynvm option.
; Tried to add hbolesrv.c as direct source 'sources=hbolesrv.c',
  but it requires this source (+ headers) to be distributed along
  the binaries, plus it didn't resolve the watcom issue, so
  I dropped it.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/hbolesrv.hbc
trunk/harbour/utils/hbmk2/hbmk2.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Jerry Finuliar]

Hi Viktor,

Please disregard my previous email.
I think I found the culprit. A left over MinGW 4.5 files.


Thanks for your time,

Jerry

-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Jerry Finuliar]

Hi Viktor,


D:\harbour>set path=c:\mingw\bin;c:\harbour\bin;

D:\harbour>path
PATH=c:\mingw\bin;c:\harbour\bin;

D:\harbour>win-make clean install
! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: win-make 3.81 sh.exe clean install
! HB_INSTALL_PREFIX: c:\harbour
! HB_HOST_PLAT: win (x86)  HB_SHELL: nt
! HB_PLATFORM: win (x86) (autodetected)
! HB_COMPILER: mingw (v45) (autodetected: c:/mingw/bin/)

Fresh download from SVN. WinXP SP3. TDM mingw 4.4
I think autodetection is not working.

Thanks,
Jerry


-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[14623] trunk/harbour

[smu johnson]

;)

On Thu, May 27, 2010 at 12:14 PM,  wrote:

> Revision: 14623
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14623&view=rev
> Author:   vszakats
> Date: 2010-05-27 19:14:43 + (Thu, 27 May 2010)
>
> Log Message:
> ---
> 2010-05-27 21:14 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>  * INSTALL
>+ Added requirement to not add the same compiler path multiple
>  times to PATH.
>
> Modified Paths:
> --
>trunk/harbour/ChangeLog
>trunk/harbour/INSTALL
>
>
> This was sent by the SourceForge.net collaborative development platform,
> the world's largest Open Source development site.
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
smu johnson 
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14625] trunk/harbour

[vszakats]

Revision: 14625
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14625&view=rev
Author:   vszakats
Date: 2010-05-27 21:38:12 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 23:36 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbmisc/calldll.prg
! Cleanup and fix to previous change.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbmisc/calldll.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[14624] trunk/harbour

[Viktor Szakáts]

Thank you very much.

Viktor

On 2010 May 27, at 22:56, dru...@users.sourceforge.net wrote:

> Revision: 14624
>  
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14624&view=rev
> Author:   druzus
> Date: 2010-05-27 20:56:44 + (Thu, 27 May 2010)
> 
> Log Message:
> ---
> 2010-05-27 22:56 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
>  * harbour/src/vm/hvm.c
>! fixed GPF when hb_arrayToParams() is used with empty array reported
>  by Viktor.
> 
> Modified Paths:
> --
>trunk/harbour/ChangeLog
>trunk/harbour/src/vm/hvm.c
> 
> 
> This was sent by the SourceForge.net collaborative development platform, the 
> world's largest Open Source development site.
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14624] trunk/harbour

[druzus]

Revision: 14624
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14624&view=rev
Author:   druzus
Date: 2010-05-27 20:56:44 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 22:56 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/src/vm/hvm.c
! fixed GPF when hb_arrayToParams() is used with empty array reported
  by Viktor.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/src/vm/hvm.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: SF.net SVN: harbour-project:[14611] trunk/harbour

[Pritpal Bedi]

Xavi-2 wrote:
> 
> 
> Maybe in a public forum can expect a change, but when there are comercial
> interests... I don't know. :(
> http://groups.google.com/group/scintilla-interest/browse_thread/thread/557fb713f11f09be
> 

Thanks Xavi.

I have just subscibed to the forum and am awaiting confirmation.

I wrote to Phil about QsciLexerFlagship but he did not respond.
BTW I have included your last changes - till last message - into 
Scintilla sources accompanying QScintilla and it is working. 
QsciLexerFlagship.cpp is based on it and respect the same styling 
constants

I will post the sources there on above forum, may be Phil 
could consider it.


-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14611-trunk-harbour-tp5106639p5110501.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Itamar Lins]

Hi!
The windows XP of Acer 3000 Notebook, install a program that was 
doubling the variable path.


Problem resolved.
Thk again.

Itamar M. Lins Jr.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: Documentation storm on user's list

[smu johnson]

Some thoughts,

On Thu, May 27, 2010 at 12:18 PM, pete_westg  wrote:

> are you sure you have understood my words? I 'm afraid you don't!
> What I am not sure for, is the reason for this misunderstanding. Perhaps,
> is it due to my bad English or what?
>

-  Stating that Harbour's lack of documention is "straightly against to the
spirit of open source initiative" can be considered offensive by many.  Who
made you the spokesperson of the Open Source movement?  It could be
interpreted that your statement means their years of work were done
improperly.

-  Saying that "this is a real problem with wider consequences than you can
imagine" is also a pretty offensive.  Are the Harbour developers incapable
of determining what might happen if there is a lack of documentation in the
near future?  I think they can.  And not only that, but hearing a vague
statement like this is like hearing someone claiming that the world is going
to end in 2012, in ways we can't possibly fathom.  It sounds like you are
saying the Harbour project is doomed unless developers start complying with
your documentation suggestions.

> All that one could ask from them is to be, their coding, more
> documentation friendly, ensuring this way that their valuable and very
> respectable labor and creation won't go in vain..

As Viktor said, others will have to volunteer to do it, if the original
developers don't feel like doing it.  Or maybe they will do it once their
work is relatively finalized?  Then they won't have to change documentation
so much when simple things change, and focus more on development.  The
ChangeLog keeps track of all this pretty nicely anyways.  (Sorry Viktor...
you had to tell me 2 or 3 times about making it a habit to check this file!)

In other (good) news, I am working on compiling a very readable FAQ with
pretty much everything covered that you could want in order to get something
that compiled on Clipper to compile in Win32 for Harbour... as I had to
figure it out all by myself, with the help of a few developers on the -dev
list.  So, this might help as far as teaching users how to do some basic and
intermediate things with Harbour that are very common.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: Documentation storm on user's list

[Viktor Szakáts]

> [I finally managed to discover that my post in users-forum had been replied 
> here. so, here it is my humble yet belated answer]
> 
> are you sure you have understood my words? I 'm afraid you don't!
> What I am not sure for, is the reason for this misunderstanding. Perhaps, is 
> it due to my bad English or what?
> And how did you find "insulting" thoughts, there where it doesn't exist? When 
> I am saying documentation is more valuable than coding, in no way mean that 
> "coding is nothing".

Yes, it read just that way. Maybe one day someone will 
teach me how to write documentation instead, so something 
valuable can be done at least. Maybe some day someone 
will teach us how to create "documentation friendly code" 
in my free time.

> It just means that without documentation, many parts of code is almost 
> unusable, for many people (users).
> 
> We all agree with you that if every individual harbour user would be willing 
> to write some (small) part of documentation, the Harbour manual would perhaps 
> be already here. But life has shown that it is not that simple. Months ago we 
> have had the very same discussion. many people had then declared their 
> interest to contribute, some of them had shown their valuable ideas and had 
> made specific proposals. Unfortunately after a while the interest had faded 
> out, and the only "real" remained/result was an documenting extension into 
> hbide, which supposedly would help to write documentation. I have tried to 
> use it. It didn't work (not in operational meaning of the term). Beyond this, 
> i 've had spent hours digging into sources, trying to format some pieces of 
> documentation. the results were not significant. why? because writing 
> documentation is indeed difficult, actually is more difficult than somebody 
> can imagine and for sure more difficult than coding. that's why, i suppose, 
> for every thousands good coders correspond few -very few or even none- good 
> documenters.

We didn't need HBIDE documentation extension, and we 
still don't need it to create docs. Unfortunately all 
our attempts to solve documentation quickly becomes 
a "tool frenzy". Maybe when such pops up, you should 
voice your opinion in time.

The only upside of last discussion is that we more or 
less nailed out the final NFDOC documentation format, 
but not enough that anyone would feel to pick it up and 
continue (or tell something better).

> Regarding your definition of idealism, i couldn't put it better.
> "thinking, learning, contributing and/or paying" is the only realistic 
> approach.
> Starting from the later, please don't have any doubt that I (and I believe 
> many other Harbour users) would be more than willing to _pay_ for a manual if 
> anything did exist. Contributing is another crucial story.

Unfortunately if users are willing to pay for what 
doesn't exist, it won't help us the smallest bit.

Plus the existing xhb documentation is available 
for money since years, yet nobody buys it. So what 
am I missing? All I see is empty words.

> Nobody's _demanding_ anything from developers. And how one could do that? But 
> asking for documentation should not considered as a demand. Is a very normal 
> and absolutely expected query for any
>  newcomer to Harbour. The "do it yourself" is a pushing away answer. What 
> "insulting" do you find in this paragraph?

Demanding and asking are two very different things, 
and it's usually easy to tell apart after having some 
time spent on public forums.

Demanding: Asking others to do something.
Asking: Asking a question in an interactive or productive 
fashion. Notice that the latter sometimes may even be 
considered as contribution.

Huge difference.

> By "documentation friendly code" i mean two simple and very well known things.
> a. Short introductory description on top of source code (in place of this 
> long and more or less useless copyright reminding replica )
> b. in-line comments.
> c. sample program.
> [OK, they are three, but any combination of two will perfectly do the job ;)]

I find this largely offensive. Did you check the code 
for comments? What exactly do you expect, hidden 
full blown documentation inside the source? Sample 
programs: all developers have done their fair share, 
so pls don't continue bugging us with it.

But, the short and generic answer is: DO IT if you 
miss it. All I see is you criticizing from the high ground 
without even considering how much work is what you ask 
for, and how much work has been done totally unnoticed 
by you...

You seem to miss the ground rule of open source: everyone 
does something to scratch an itch.

Some of us many times do much more than that, but pls 
don't ask for more, more and more, just do it.

> P.S.: merging harbour-xhb? (wow! this question could be a real philosophical 
> dilemma). although this is a core-developers decision, you better  don't have 
> doubts that the great majority of the users, in case they'd been asked for,  
> w

[Harbour] Re: Documentation storm on user's list

[pete_westg]

στις 27/05/2010 13:02, O/H Viktor Szakáts έγραψε:

To Pete,

[ Sorry to reply here, but I'm readonly user of users-list. ]


Strange and insulting thoughts towards anyone who have
dedicated huge amount (many years) of (maybe even full
time) to take this project where it is now. Maybe
you could elaborate on what you mean by "documentation
friendly code"...

If coding means nothing to you, pls delete all the
Harbour sources and try to use it after...



Viktor,

[I finally managed to discover that my post in users-forum had been 
replied here. so, here it is my humble yet belated answer]


are you sure you have understood my words? I 'm afraid you don't!
What I am not sure for, is the reason for this misunderstanding. 
Perhaps, is it due to my bad English or what?
And how did you find "insulting" thoughts, there where it doesn't exist? 
When I am saying documentation is more valuable than coding, in no way 
mean that "coding is nothing".
It just means that without documentation, many parts of code is almost 
unusable, for many people (users).


We all agree with you that if every individual harbour user would be 
willing to write some (small) part of documentation, the Harbour manual 
would perhaps be already here. But life has shown that it is not that 
simple. Months ago we have had the very same discussion. many people had 
then declared their interest to contribute, some of them had shown their 
valuable ideas and had made specific proposals. Unfortunately after a 
while the interest had faded out, and the only "real" remained/result 
was an documenting extension into hbide, which supposedly would help to 
write documentation. I have tried to use it. It didn't work (not in 
operational meaning of the term). Beyond this, i 've had spent hours 
digging into sources, trying to format some pieces of documentation. the 
results were not significant. why? because writing documentation is 
indeed difficult, actually is more difficult than somebody can imagine 
and for sure more difficult than coding. that's why, i suppose, for 
every thousands good coders correspond few -very few or even none- good 
documenters.

Regarding your definition of idealism, i couldn't put it better.
"thinking, learning, contributing and/or paying" is the only realistic 
approach.
Starting from the later, please don't have any doubt that I (and I 
believe many other Harbour users) would be more than willing to _pay_ 
for a manual if anything did exist. Contributing is another crucial story.
Nobody's _demanding_ anything from developers. And how one could do 
that? But asking for documentation should not considered as a demand. Is 
a very normal and absolutely expected query for any newcomer to Harbour. 
The "do it yourself" is a pushing away answer. What "insulting" do you 
find in this paragraph?
By "documentation friendly code" i mean two simple and very well known 
things.
a. Short introductory description on top of source code (in place of 
this long and more or less useless copyright reminding replica )

b. in-line comments.
c. sample program.
[OK, they are three, but any combination of two will perfectly do the 
job ;)]




P.S.: merging harbour-xhb? (wow! this question could be a real 
philosophical dilemma). although this is a core-developers decision, 
you better  don't have doubts that the great majority of the users, in 
case they'd been asked for,  would loudly vote "No!"


---
Pete

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14623] trunk/harbour

[vszakats]

Revision: 14623
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14623&view=rev
Author:   vszakats
Date: 2010-05-27 19:14:43 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 21:14 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * INSTALL
+ Added requirement to not add the same compiler path multiple
  times to PATH.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/INSTALL


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: --nxcompat MingW

[Viktor Szakáts]

>> 2010/5/27 Itamar Lins
>> > >
>> 
>>Em 27/5/2010 14:50, Viktor Szakáts escreveu:
>> 
>>C:\harbour\trunk\harbour>set path=c:\mingw\bin;%PATH%
>> 
>> You not clean
> Hi!
> Only one version MinGW on HD.
> The path c:\mingw\bin, if I set for exemple 2 times, is the same MinGW 
> version.

Remove one of the same entries from PATH. Why not listen?

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Itamar Lins]

Em 27/5/2010 15:42, Massimo Belgrano escreveu:



2010/5/27 Itamar Lins
mailto:itamarl...@gmail.com>>

Em 27/5/2010 14:50, Viktor Szakáts escreveu:

C:\harbour\trunk\harbour>set path=c:\mingw\bin;%PATH%

You not clean

Hi!
Only one version MinGW on HD.
The path c:\mingw\bin, if I set for exemple 2 times, is the same MinGW 
version.


Best regards,
Itamar M. Lins Jr.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: --nxcompat MingW

[Viktor Szakáts]

> Em 27/5/2010 15:36, Itamar Lins escreveu:
> ---8<
> Using prompt tdradgon, the result is:
> Path=C:\MinGW\bin;C:\WINDOWS\system32;
> -->8---
> 
> Maybe upper case M and GW of word MinGW ?

No, it doesn't matter.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Itamar Lins]

Em 27/5/2010 15:36, Itamar Lins escreveu:
---8<
Using prompt tdradgon, the result is:
Path=C:\MinGW\bin;C:\WINDOWS\system32;
-->8---

Maybe upper case M and GW of word MinGW ?

Best regards,
Itamar M. Lins Jr.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: --nxcompat MingW

[Massimo Belgrano]

2010/5/27 Itamar Lins 

> Em 27/5/2010 14:50, Viktor Szakáts escreveu:
>
> C:\harbour\trunk\harbour>set path=c:\mingw\bin;%PATH%
>
You not clean
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;*C:\mingw\bin*;C:\Dev\Harbour\bin;C:\Arquivos
de programas\TortoiseSVN\bin;C:\Arquivos de
programas\CVSNT\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;*
C:\mingw\bin;*C:\Dev\Harbour\bin;C:\Arquivos de
programas\TortoiseSVN\bin;C:\

C:\harbour\trunk\harbour>win-make.exe install
>
> Now compiling fine until here:
>
> lp.o dbgtinp.o dbgtmenu.o dbgtmitm.o dbgtwin.o debugger.o dbgtarr.o
> dbgthsh.o db
> gtobj.o tbrwtext.o dbgwa.o dbgbrwsr.o  ) || del /q /f
> ..\..\..\..\..\lib\win\min
> gw\libhbdebug.a
>1 arquivo(s) copiado(s).
> gcc  -Wl,--nxcompat -Wl,--dynamicbase -shared
> -L../../../../../lib/win/mingw  -o
>  ../../../../../bin/win/mingw/harbour-21.dll __dyn__.tmp -lkernel32
> -luser32 -lw
> s2_32 -ladvapi32 -lgdi32
> -Wl,--out-implib,../../../../../lib/win/mingw/libharbou
>
> r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def
> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe:
> unrecogniz
> ed option '--nxcompat'
> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use
> the --
> help option for usage information
> collect2: ld returned 1 exit status
> win-make.exe[3]: *** [harbour-21.dll] Error 1
> win-make.exe[2]: *** [descend] Error 2
> win-make.exe[1]: *** [dynlib.inst] Error 2
> win-make.exe: *** [src.inst] Error 2
>
>
>
I found a prev reply to unrecognized option '--nxcompat'

I can just guess without seeing the beginning of your log output.
Maybe you manually set HB_COMPILER (without setting HB_COMPILER_VER).

Viktor

Ah.  Correct again!  I thought if the gcc version I wanted to use before any
other was first in the windows path, it would only be used... but I am
incorrect.

# proper
! HB_COMPILER: mingw (v44) (autodetected: c:/mingw/bin/)

# problematic
! HB_COMPILER: mingw (v45) (autodetected: c:/mingw/bin/gcc.exe
C:/strawberry/c/bin/)

If it detected Strawberry Perl's gcc version after mine, which it seems like
it did as it comes 2nd on the above printout can't the version detect /
only use the first one, c:/mingw/bin/gcc.exe?

This time, I was reading other threads about problems like these... but
perhaps I made too big of an assumption this tim
SMU

I'm afraid not. In general it's not very good to mix
different compilers in PATH, but it's especially not
good mix two different gcc versions in PATH at the same
time. INSTALL doc makes this very clear.

There is no compiler selector logic in our build system,
since it would be a complete nightmare to test (hundreds
of different combinations) and maintain just to sort out
otherwise not very likely configurations as above. Notice
that mixing compilers is not only bad for Harbour, but it's
generally bad practice on Windows systems.

Viktor

>
>

-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Itamar Lins]

Em 27/5/2010 15:26, Viktor Szakáts escreveu:


Pls clean up your environment, I cannot help more.

Viktor


My envvar is clean, the HD is new. Only I setting
HB_INSTALL_PREFIX.
I found and isolate the problem.
If I set PATH in panel control of windows XP, c:\mingw\bin not work.
Now if I use mingw command prompt "tdragom" work. Because content of 
file mingevars.bat is:

@echo.
@echo Setting up environment for using MinGW with GCC from %~dp0.
@set PATH=%~dp0bin;%PATH%

Best regards,
Itamar M. Lins Jr.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: --nxcompat MingW

[Viktor Szakáts]

> C:\harbour\trunk\harbour>win-make.exe install
> ! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
> ! MAKE: win-make.exe 3.81 sh.exe install
> ! HB_INSTALL_PREFIX: c:\dev\harbour
> ! HB_HOST_PLAT: win (x86)  HB_SHELL: nt
> config/global.mk:971: *** ! HB_COMPILER not set, could not autodetect. Stop.
> 
> C:\harbour\trunk\harbour>set path=c:\mingw\bin;%PATH%
> 
> C:\harbour\trunk\harbour>win-make.exe install
> 
> Now compiling fine until here:
> 
> lp.o dbgtinp.o dbgtmenu.o dbgtmitm.o dbgtwin.o debugger.o dbgtarr.o dbgthsh.o 
> db
> gtobj.o tbrwtext.o dbgwa.o dbgbrwsr.o  ) || del /q /f 
> ..\..\..\..\..\lib\win\min
> gw\libhbdebug.a
>1 arquivo(s) copiado(s).
> gcc  -Wl,--nxcompat -Wl,--dynamicbase -shared -L../../../../../lib/win/mingw  
> -o
> ../../../../../bin/win/mingw/harbour-21.dll __dyn__.tmp -lkernel32 -luser32 
> -lw
> s2_32 -ladvapi32 -lgdi32 
> -Wl,--out-implib,../../../../../lib/win/mingw/libharbou
> r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def
> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: 
> unrecogniz
> ed option '--nxcompat'
> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use the 
> --
> help option for usage information
> collect2: ld returned 1 exit status
> win-make.exe[3]: *** [harbour-21.dll] Error 1
> win-make.exe[2]: *** [descend] Error 2
> win-make.exe[1]: *** [dynlib.inst] Error 2
> win-make.exe: *** [src.inst] Error 2

Pls clean up your environment, I cannot help more.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14622] trunk/harbour

[vszakats]

Revision: 14622
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14622&view=rev
Author:   vszakats
Date: 2010-05-27 18:24:19 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 20:23 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbmisc/calldll.prg
+ HB_DYNCALL1() will now cut the number of parameters
  according to passed nCount parameter, just to mimic
  exact behavior of original function.

  + contrib/hbmisc/tests/testcall.prg
+ Added test code for CALLDLL32() and HB_DYNCALL1().

  * contrib/hbwin/tests/testcopy.prg
* Copyright year.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbmisc/calldll.prg
trunk/harbour/contrib/hbwin/tests/testcopy.prg

Added Paths:
---
trunk/harbour/contrib/hbmisc/tests/testcall.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] BUG: hb_arrayToParams( {} )

[Viktor Szakáts]

Hi Przemek,

Accidentally found this:
---
PROC MAIN()
   QOUT( hb_arrayToParams( {} ) )
   RETURN
---

-> GPF (tested on win/mingw)

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Itamar Lins]

Em 27/5/2010 14:50, Viktor Szakáts escreveu:

God. The "how to f*ck up" contest continues :(

You have mingw two times in PATH. Remove one.


C:\harbour\trunk\harbour>win-make.exe install
! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: win-make.exe 3.81 sh.exe install
! HB_INSTALL_PREFIX: c:\dev\harbour
! HB_HOST_PLAT: win (x86)  HB_SHELL: nt
config/global.mk:971: *** ! HB_COMPILER not set, could not autodetect. 
Stop.


C:\harbour\trunk\harbour>set path=c:\mingw\bin;%PATH%

C:\harbour\trunk\harbour>win-make.exe install

Now compiling fine until here:

lp.o dbgtinp.o dbgtmenu.o dbgtmitm.o dbgtwin.o debugger.o dbgtarr.o 
dbgthsh.o db
gtobj.o tbrwtext.o dbgwa.o dbgbrwsr.o  ) || del /q /f 
..\..\..\..\..\lib\win\min

gw\libhbdebug.a
1 arquivo(s) copiado(s).
gcc  -Wl,--nxcompat -Wl,--dynamicbase -shared 
-L../../../../../lib/win/mingw  -o
 ../../../../../bin/win/mingw/harbour-21.dll __dyn__.tmp -lkernel32 
-luser32 -lw
s2_32 -ladvapi32 -lgdi32 
-Wl,--out-implib,../../../../../lib/win/mingw/libharbou

r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: 
unrecogniz

ed option '--nxcompat'
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: 
use the --

help option for usage information
collect2: ld returned 1 exit status
win-make.exe[3]: *** [harbour-21.dll] Error 1
win-make.exe[2]: *** [descend] Error 2
win-make.exe[1]: *** [dynlib.inst] Error 2
win-make.exe: *** [src.inst] Error 2


Best regards,
Itamar M. Lins Jr.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14621] trunk/harbour

[vszakats]

Revision: 14621
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14621&view=rev
Author:   vszakats
Date: 2010-05-27 17:58:50 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 19:57 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbmisc/Makefile
  + contrib/hbmisc/calldll.prg
+ Added CALLDLL compatibility API interface:
CALLDLL32(), HB_DYNACALL1(), STRPTR(), PTRSTR(), UNLOADALLDLL().
; Lightly tested, it's based on core .dll functions, so it may only
  need easy tweaking. Notice that this API support all platforms,
  not just 32-bit Windows.
  The original library is found in MINIGUI f.e.

  * contrib/hbwin/win_shell.c
* Minor formatting.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbmisc/Makefile
trunk/harbour/contrib/hbwin/win_shell.c

Added Paths:
---
trunk/harbour/contrib/hbmisc/calldll.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: SF.net SVN: harbour-project:[14611] trunk/harbour

[Xavi]

Hi Pritpal,


1. Flagship lexer is not implemented in QScintilla which I did.
2. May be it can go, but a lot of warnings while compiling QScintilla as per
Harbour make system.
3. I could only build static lib, .a, and do not know how to a shared one,
.dll.
4. One serious issue which I could not resolve, commenting out a line
 delete [] words; solved the problem, otherwise GPF. I know it may lead
 to leaked memory but unless someone with more knowledge look into it,
 I could not fix. "words" is defined as - char * words.
5. It is just the begining, I may need some more tweaking to achieve
 some more goals, so may be needing to tweak Scintilla sources itself.
6. Author, Phil Thomson, did not reply when I offered Flagship lexer code
 to him plus few fixes to get rid of the warnings. His only reply was,

"I don't understand this. By including QScintilla your application must
becompatible with the GPL. This means that you must make all the source
codeavailable to your users, and allow them to rebuild the application. So
whycan't you build it yourself as well? "


Maybe in a public forum can expect a change, but when there are comercial 
interests... I don't know. :(
http://groups.google.com/group/scintilla-interest/browse_thread/thread/557fb713f11f09be

Best regards,
--
Xavi
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: --nxcompat MingW

[Viktor Szakáts]

God. The "how to f*ck up" contest continues :(

You have mingw two times in PATH. Remove one.

Viktor

On 2010 May 27, at 19:27, Itamar Lins wrote:

> Em 27/5/2010 14:21, Viktor Szakáts escreveu:
>>> ! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
>>> ! MAKE: win-make.exe 3.81 sh.exe INSTALL
>>> ! HB_INSTALL_PREFIX: c:\dev\harbour
>>> ! HB_HOST_PLAT: win (x86)  HB_SHELL: nt
>>> ! HB_PLATFORM: win (x86) (autodetected)
>>> ! HB_COMPILER: mingw (v45) (autodetected: C:/mingw/bin/gcc.exe 
>>> C:/mingw/bin/)
>>> ! Component: 'zlib' found in C:/harbour/trunk/harbour/external/zlib (local)
>>> ! Component: 'pcre' found in C:/harbour/trunk/harbour/external/pcre (local)
>>> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
>>> ! Component: 'gpm' not supported on win platform
>>> ! Component: 'slang' not found. Configure with HB_WITH_SLANG.
>>> ! Component: 'curses' not found. Configure with HB_WITH_CURSES.
>>> ! Component: 'x11' not found. Configure with HB_WITH_X11.
>>> ! Component: 'wattcp/watt-32' not supported on win platform
>> 
>> Thank you. Pls also post the content of C:/mingw/bin/ directory.
>> 
>> Also pls tell what is the source of this mingw distro?
>> 
>> Viktor
>> 
> 
> C:\MinGW\bin
> 
> 27/05/2010  14:23  .
> 27/05/2010  14:23  ..
> 03/02/2009  11:10   545.280 addr2line.exe
> 03/02/2009  11:10   562.688 ar.exe
> 03/02/2009  11:10   968.704 as.exe
> 04/10/2009  21:13   227.840 c++.exe
> 03/02/2009  11:10   544.256 c++filt.exe
> 05/07/2001  13:11   226.816 cpp.exe
> 03/02/2009  11:10   588.800 dlltool.exe
> 03/02/2009  11:1057.856 dllwrap.exe
> 04/10/2009  21:13   227.840 g++.exe
> 05/07/2001  13:11   225.280 gcc.exe
> 05/07/2001  13:1116.207 gccbug
> 05/07/2001  13:1151.219 gcov.exe
> 23/04/2008  22:09 2.584.576 gdb.exe
> 23/04/2008  22:0958.880 gdbserver.exe
> 03/02/2009  11:10   605.184 gprof.exe
> 03/02/2009  11:10   785.408 ld.exe
> 05/07/2001  13:12   239.328 libgcc_s_sjlj-1.dll
> 04/10/2009  21:13   227.840 mingw32-c++.exe
> 04/10/2009  21:13   227.840 mingw32-g++.exe
> 05/07/2001  13:11   225.280 mingw32-gcc-4.4.1.exe
> 05/07/2001  13:11   225.280 mingw32-gcc.exe
> 05/06/2008  10:36   165.376 mingw32-make.exe
> 14/08/2009  23:5718.207 mingwm10.dll
> 03/02/2009  11:10   555.008 nm.exe
> 03/02/2009  11:10   692.224 objcopy.exe
> 03/02/2009  11:10 1.011.712 objdump.exe
> 13/05/2001  10:4771.886 pthreadGC2.dll
> 13/05/2001  10:47   120.455 pthreadGCE2.dll
> 03/02/2009  11:10   562.688 ranlib.exe
> 03/02/2009  11:10   281.600 readelf.exe
> 03/02/2009  11:10   547.328 size.exe
> 03/02/2009  11:10   546.304 strings.exe
> 03/02/2009  11:10   692.224 strip.exe
> 03/02/2009  11:10   567.296 windmc.exe
> 03/02/2009  11:10   649.728 windres.exe
> 
> Mingw is Tdragon:
> 18/10/2009  20:4227.414.487 tdm-mingw-1.908.0-4.4.1-2.exe
> 
> Best regards,
> Itamar M. Lins Jr.
> 
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Error with bcc582

[Rossine]

Hi Viktor,

> It's pure .prg code and unlike original C++ HBCOMM lib, it won't cause HVM
> corruption.

I link "hbcomm.prg" in my project and it worked fine now :)

Thank you for your suggestion :)

Rossine.

-- 
View this message in context: 
http://old.nabble.com/Error-with-bcc582-tp28685607p28697634.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Itamar Lins]

Em 27/5/2010 14:21, Viktor Szakáts escreveu:

! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: win-make.exe 3.81 sh.exe INSTALL
! HB_INSTALL_PREFIX: c:\dev\harbour
! HB_HOST_PLAT: win (x86)  HB_SHELL: nt
! HB_PLATFORM: win (x86) (autodetected)
! HB_COMPILER: mingw (v45) (autodetected: C:/mingw/bin/gcc.exe C:/mingw/bin/)
! Component: 'zlib' found in C:/harbour/trunk/harbour/external/zlib (local)
! Component: 'pcre' found in C:/harbour/trunk/harbour/external/pcre (local)
! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on win platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not found. Configure with HB_WITH_CURSES.
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on win platform


Thank you. Pls also post the content of C:/mingw/bin/ directory.

Also pls tell what is the source of this mingw distro?

Viktor



C:\MinGW\bin

27/05/2010  14:23  .
27/05/2010  14:23  ..
03/02/2009  11:10   545.280 addr2line.exe
03/02/2009  11:10   562.688 ar.exe
03/02/2009  11:10   968.704 as.exe
04/10/2009  21:13   227.840 c++.exe
03/02/2009  11:10   544.256 c++filt.exe
05/07/2001  13:11   226.816 cpp.exe
03/02/2009  11:10   588.800 dlltool.exe
03/02/2009  11:1057.856 dllwrap.exe
04/10/2009  21:13   227.840 g++.exe
05/07/2001  13:11   225.280 gcc.exe
05/07/2001  13:1116.207 gccbug
05/07/2001  13:1151.219 gcov.exe
23/04/2008  22:09 2.584.576 gdb.exe
23/04/2008  22:0958.880 gdbserver.exe
03/02/2009  11:10   605.184 gprof.exe
03/02/2009  11:10   785.408 ld.exe
05/07/2001  13:12   239.328 libgcc_s_sjlj-1.dll
04/10/2009  21:13   227.840 mingw32-c++.exe
04/10/2009  21:13   227.840 mingw32-g++.exe
05/07/2001  13:11   225.280 mingw32-gcc-4.4.1.exe
05/07/2001  13:11   225.280 mingw32-gcc.exe
05/06/2008  10:36   165.376 mingw32-make.exe
14/08/2009  23:5718.207 mingwm10.dll
03/02/2009  11:10   555.008 nm.exe
03/02/2009  11:10   692.224 objcopy.exe
03/02/2009  11:10 1.011.712 objdump.exe
13/05/2001  10:4771.886 pthreadGC2.dll
13/05/2001  10:47   120.455 pthreadGCE2.dll
03/02/2009  11:10   562.688 ranlib.exe
03/02/2009  11:10   281.600 readelf.exe
03/02/2009  11:10   547.328 size.exe
03/02/2009  11:10   546.304 strings.exe
03/02/2009  11:10   692.224 strip.exe
03/02/2009  11:10   567.296 windmc.exe
03/02/2009  11:10   649.728 windres.exe

Mingw is Tdragon:
18/10/2009  20:4227.414.487 tdm-mingw-1.908.0-4.4.1-2.exe

Best regards,
Itamar M. Lins Jr.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14620] trunk/harbour

[vszakats]

Revision: 14620
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14620&view=rev
Author:   vszakats
Date: 2010-05-27 17:27:23 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 19:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbwin/wapi_wingdi.c
  * contrib/hbwin/hbolesrv.c
! Fixed for msvcarm.

  * contrib/hbwin/hbwin.ch
  * contrib/hbwin/win_shell.c
  + contrib/hbwin/tests/testcopy.prg
+ Added:
  WIN_SHFileOperation( [], [], [|], 
[|],
   [], [<@lAnyOperationAborted>],
   [], [] ) -> 
; Przemek, if you have some time pls review s_StringList()
  function which I adapted from similar function in win_dlg.c,
  but it might not be perfect. '<\0><\0><\0>' format
  is required by this SHFileOperation() Windows function.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/hbolesrv.c
trunk/harbour/contrib/hbwin/hbwin.ch
trunk/harbour/contrib/hbwin/wapi_wingdi.c
trunk/harbour/contrib/hbwin/win_shell.c

Added Paths:
---
trunk/harbour/contrib/hbwin/tests/testcopy.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: --nxcompat MingW

[Viktor Szakáts]

> ! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
> ! MAKE: win-make.exe 3.81 sh.exe INSTALL
> ! HB_INSTALL_PREFIX: c:\dev\harbour
> ! HB_HOST_PLAT: win (x86)  HB_SHELL: nt
> ! HB_PLATFORM: win (x86) (autodetected)
> ! HB_COMPILER: mingw (v45) (autodetected: C:/mingw/bin/gcc.exe C:/mingw/bin/)
> ! Component: 'zlib' found in C:/harbour/trunk/harbour/external/zlib (local)
> ! Component: 'pcre' found in C:/harbour/trunk/harbour/external/pcre (local)
> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
> ! Component: 'gpm' not supported on win platform
> ! Component: 'slang' not found. Configure with HB_WITH_SLANG.
> ! Component: 'curses' not found. Configure with HB_WITH_CURSES.
> ! Component: 'x11' not found. Configure with HB_WITH_X11.
> ! Component: 'wattcp/watt-32' not supported on win platform

Thank you. Pls also post the content of C:/mingw/bin/ directory.

Also pls tell what is the source of this mingw distro?

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Itamar Lins]

Em 27/5/2010 14:08, Viktor Szakáts escreveu:
> Pls post the BEGINNING of your log to see what
> autodetection does.
>
> Viktor
>

! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: win-make.exe 3.81 sh.exe INSTALL
! HB_INSTALL_PREFIX: c:\dev\harbour
! HB_HOST_PLAT: win (x86)  HB_SHELL: nt
! HB_PLATFORM: win (x86) (autodetected)
! HB_COMPILER: mingw (v45) (autodetected: C:/mingw/bin/gcc.exe 
C:/mingw/bin/)

! Component: 'zlib' found in C:/harbour/trunk/harbour/external/zlib (local)
! Component: 'pcre' found in C:/harbour/trunk/harbour/external/pcre (local)
! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on win platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not found. Configure with HB_WITH_CURSES.
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on win platform


Best regards,
Itamar M. Lins Jr.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14619] trunk/harbour

[druzus]

Revision: 14619
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14619&view=rev
Author:   druzus
Date: 2010-05-27 17:08:44 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 19:08 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/hbwin/hbolesrv.c
% improved the performance and reduced memory usage by using hash
  array with strict assign order for message names to number translation
  in OLE objects accepting any message names

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/hbolesrv.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: --nxcompat MingW

[Viktor Szakáts]

Pls post the BEGINNING of your log to see what 
autodetection does.

Viktor

On 2010 May 27, at 19:00, Itamar Lins wrote:

> Em 27/5/2010 13:57, Viktor Szakáts escreveu:
>> On 2010 May 27, at 18:31, Itamar Lins wrote:
>> 
>>> Hi!
>>> Please see this:
>>> Win XP SP3 with MingW.
>>> 
>>> r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def
>>> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: 
>>> unrecognized option '--nxcompat'
>>> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use 
>>> the --
>>> help option for usage information
>>> collect2: ld returned 1 exit status
>>> win-make.exe[3]: *** [harbour-21.dll] Error 1
>>> win-make.exe[2]: *** [descend] Error 2
>>> win-make.exe[1]: *** [dynlib.inst] Error 2
>>> win-make.exe: *** [src.inst] Error 2
>>> 
>>> PS. Is possible be my fault enviroment config. I change my HD.
>> 
>> I've replied this like 50 times, the last time about 2 hours ago.
>> 
>> Delete HB_COMPILER envvar.
>> 
>> Viktor
>> 
> But this is envvar HB_COMPILER not set for here.
> See my envvar:
> 
> ALLUSERSPROFILE=C:\Documents and Settings\All Users
> APPDATA=C:\Documents and Settings\Itamar\Dados de aplicativos
> CLIENTNAME=Console
> CommonProgramFiles=C:\Arquivos de programas\Arquivos comuns
> COMPUTERNAME=ACER3000
> ComSpec=C:\WINDOWS\system32\cmd.exe
> FP_NO_HOST_CHECK=NO
> HB_INSTALL_PREFIX=c:\dev\harbour
> HB_WITH_BLAT=C:\blat\blat262\full\source
> HB_WITH_QT=C:\Qt\2009.04\qt\include
> HOMEDRIVE=C:
> HOMEPATH=\Documents and Settings\Itamar
> LOGONSERVER=\\ACER3000
> MAQ=FSICAL
> NUMBER_OF_PROCESSORS=1
> OS=Windows_NT
> Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\mingw\bin;C:\Dev\Harbour\bin;C:\Arquivos
>  de programas\TortoiseSVN\bin;C:\Arquivos de 
> programas\CVSNT\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\mingw\bin;C:\Dev\Harbour\bin;C:\Arquivos
>  de programas\TortoiseSVN\bin;C:\ARQUIV~1\ARQUIV~1\MUVEET~1\030625
> PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
> PROCESSOR_ARCHITECTURE=x86
> PROCESSOR_IDENTIFIER=x86 Family 15 Model 44 Stepping 2, AuthenticAMD
> PROCESSOR_LEVEL=15
> PROCESSOR_REVISION=2c02
> ProgramFiles=C:\Arquivos de programas
> PROMPT=$P$G
> SESSIONNAME=Console
> SystemDrive=C:
> SystemRoot=C:\WINDOWS
> TCX=ITAMAR
> TEMP=C:\DOCUME~1\Itamar\CONFIG~1\Temp
> TMP=C:\DOCUME~1\Itamar\CONFIG~1\Temp
> USERDOMAIN=ACER3000
> USERNAME=Itamar
> USERPROFILE=C:\Documents and Settings\Itamar
> windir=C:\WINDOWS
> 
> Best regards,
> Itamar M. Lins Jr.
> 
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Error with bcc582

[Viktor Szakáts]

> Hello Viktor,
> 
>> I suggest to use hbmk2 to build hbcomm...
> 
> OK i rebuilt harbour release 14618 the traditional way:
> 
> \harbour\bin\mingw32-make.exe clean install
> 
>> ...and also your app, and it should link properly.
> 
> OK. But the error continues.
> 
> I use for compile this command:
> 
> hbmk2 -trace -info -n -gc3 /I. -ic:\minigui\include myprog %1 myprog.hbm
> myprog.hbc > comp.log
> 
> In my .hbc i have:
> 
> {bcc}libs=hbcomm
> 
> What can it be ?

Sorry, I don't know. HBCOMM lib is built using non-hbmk2 
solution, so I cannot tell you what was messed up along 
the way, C++ is tricky to build, probably something is 
messed up.

Try building HBCOMM using hbmk2 also (I tested this case 
and it DID work for me), or try using recently added HBCOMM 
lib emulation inside Harbour contrib area. It's pure .prg code 
and unlike original C++ HBCOMM lib, it won't cause HVM 
corruption.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: --nxcompat MingW

[Itamar Lins]

Em 27/5/2010 13:57, Viktor Szakáts escreveu:

On 2010 May 27, at 18:31, Itamar Lins wrote:


Hi!
Please see this:
Win XP SP3 with MingW.

r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: 
unrecognized option '--nxcompat'
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use the --
help option for usage information
collect2: ld returned 1 exit status
win-make.exe[3]: *** [harbour-21.dll] Error 1
win-make.exe[2]: *** [descend] Error 2
win-make.exe[1]: *** [dynlib.inst] Error 2
win-make.exe: *** [src.inst] Error 2

PS. Is possible be my fault enviroment config. I change my HD.


I've replied this like 50 times, the last time about 2 hours ago.

Delete HB_COMPILER envvar.

Viktor


But this is envvar HB_COMPILER not set for here.
See my envvar:

ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\Itamar\Dados de aplicativos
CLIENTNAME=Console
CommonProgramFiles=C:\Arquivos de programas\Arquivos comuns
COMPUTERNAME=ACER3000
ComSpec=C:\WINDOWS\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HB_INSTALL_PREFIX=c:\dev\harbour
HB_WITH_BLAT=C:\blat\blat262\full\source
HB_WITH_QT=C:\Qt\2009.04\qt\include
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\Itamar
LOGONSERVER=\\ACER3000
MAQ=FSICAL
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\mingw\bin;C:\Dev\Harbour\bin;C:\Arquivos 
de programas\TortoiseSVN\bin;C:\Arquivos de 
programas\CVSNT\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\mingw\bin;C:\Dev\Harbour\bin;C:\Arquivos 
de programas\TortoiseSVN\bin;C:\ARQUIV~1\ARQUIV~1\MUVEET~1\030625

PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 44 Stepping 2, AuthenticAMD
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=2c02
ProgramFiles=C:\Arquivos de programas
PROMPT=$P$G
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TCX=ITAMAR
TEMP=C:\DOCUME~1\Itamar\CONFIG~1\Temp
TMP=C:\DOCUME~1\Itamar\CONFIG~1\Temp
USERDOMAIN=ACER3000
USERNAME=Itamar
USERPROFILE=C:\Documents and Settings\Itamar
windir=C:\WINDOWS

Best regards,
Itamar M. Lins Jr.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Error with bcc582

[Rossine]

Hello Viktor,

>I suggest to use hbmk2 to build hbcomm...

OK i rebuilt harbour release 14618 the traditional way:

\harbour\bin\mingw32-make.exe clean install

> ...and also your app, and it should link properly.

OK. But the error continues.

I use for compile this command:

hbmk2 -trace -info -n -gc3 /I. -ic:\minigui\include myprog %1 myprog.hbm
myprog.hbc > comp.log

In my .hbc i have:

{bcc}libs=hbcomm

What can it be ?

Best Regards,

Rossine.

-- 
View this message in context: 
http://old.nabble.com/Error-with-bcc582-tp28685607p28697076.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] --nxcompat MingW

[Viktor Szakáts]

On 2010 May 27, at 18:31, Itamar Lins wrote:

> Hi!
> Please see this:
> Win XP SP3 with MingW.
> 
> r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def
> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: 
> unrecognized option '--nxcompat'
> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use the 
> --
> help option for usage information
> collect2: ld returned 1 exit status
> win-make.exe[3]: *** [harbour-21.dll] Error 1
> win-make.exe[2]: *** [descend] Error 2
> win-make.exe[1]: *** [dynlib.inst] Error 2
> win-make.exe: *** [src.inst] Error 2
> 
> PS. Is possible be my fault enviroment config. I change my HD.

I've replied this like 50 times, the last time about 2 hours ago.

Delete HB_COMPILER envvar.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: Documentation storm on user's list

[Viktor Szakáts]

> El 27/05/2010 11:16, Horodyski Marek (PZUZ) escribió:
> 
>> 
>> Viktor,
>> ...  Harbour is beautiful, beautiful, and once again fast :)
>> 
>> Best regards,
>> Marek Horodyski
>> 
> 
> Amen 

Well, what stays true from this whole conversation 
is we are truly missing documentation. It's also true 
that bugging (or insulting) me or other core developers 
to make it isn't a working solution, however strong 
the emphasis is or however often it is done. 

That's still leaves us with the question:

How will Harbour get a documentation?

If anyone has any ideas, pls tell it. I'm ready to 
hand off my leader role for someone who is able to 
show us the solution and seems able and willing to 
lead the project to actual results here.

BTW

Now that we have practically complete compatibility 
with xhb, one (indeed idealistic) and also utopistic 
solution could be to finally remerge the effort of 
xhb and Harbour, where xhb would bring the docs, 
and we'd bring the code. This way both parties would 
bring its healthy part to the "marriage". xhb leaders 
would gain a strong and living codebase for their 
payware products, all users would gain good documentation, 
and as a "byproduct" the two separate communities 
would be merged, which is probably better to keep 
[x]Harbour alive as a language, and also for users 
seeking to have a compatible Harbour base, and the 
option for users to get paid support without having 
to chose between "worlds" (this means more potential 
market for xhb). "culture clash" could be one potential 
problem, but it's not a one-way ticket, since the 
sources stay open, so it's easy to back off in case 
of some fatal "issue" along the way.

It's not a real argument, but looking around the 
FOSS language landscape, I can't see any successful 
project which could "afford" such splitting of the 
community and the luxury of having two of everything.

So, such merge would IMO be a net win for all parties.

If someone has an opinion on this, particularly 
xhb team leaders and our core developers and devoted 
brains around this list, please don't hesitate to 
express it.

> Some hummor (really?) to ease the day ;)
> 
> http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/

Not joke, but it's a good one :)

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] --nxcompat MingW

[Itamar Lins]

Hi!
Please see this:
Win XP SP3 with MingW.

r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: 
unrecognized option '--nxcompat'
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: 
use the --

help option for usage information
collect2: ld returned 1 exit status
win-make.exe[3]: *** [harbour-21.dll] Error 1
win-make.exe[2]: *** [descend] Error 2
win-make.exe[1]: *** [dynlib.inst] Error 2
win-make.exe: *** [src.inst] Error 2

PS. Is possible be my fault enviroment config. I change my HD.

Best regards,
Itamar M. Lins Jr.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Documentation storm on user's list

[Pritpal Bedi]

Angel Pais wrote:
> 
> Some hummor (really?) to ease the day ;)
> 
> http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/
> 

Enjoyed.

Really refreshing and seemed expressing me.



-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/Documentation-storm-on-user-s-list-tp5107834p5109462.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Documentation storm on user's list

[Angel Pais]

El 27/05/2010 11:16, Horodyski Marek (PZUZ) escribió:



Viktor,
...  Harbour is beautiful, beautiful, and once again fast :)

Best regards,
Marek Horodyski



Amen 

Some hummor (really?) to ease the day ;)

http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/

Enjoy
Angel

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14618] trunk/harbour

[druzus]

Revision: 14618
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14618&view=rev
Author:   druzus
Date: 2010-05-27 14:27:25 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 16:27 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/xhb/Makefile
  + harbour/contrib/xhb/xhbhasha.c
+ added xHarbour Hash with Associative Array compatibility functions:
 HAAGETKEYAT( ,  ) -> 
 HAAGETVALUEAT( ,  ) -> 
 HAASETVALUEAT( , ,  ) -> NIL
 HAADELAT( ,  ) -> NIL
 HAAGETPOS( ,  ) -> 
 HAAGETREALPOS( ,  ) -> 
 HGETVAAPOS(  ) -> 
 HSETAACOMPATIBILITY( ,  ) -> 
 HGETAACOMPATIBILITY(  ) -> 
  These functions were added only for compatibility with existing
  xHarbour code. Harbour does not emulate associative arrays by
  special index but it uses real natural order for them. It means
  that associative array indexes are equal to regular hash indexes
  so we do not need any translation between them and Harbour users
  can use regular hash array functions for associative array indexes,
  i.e. instead of using HAAGETKEYAT() they can use HB_HKEYAT().

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/xhb/Makefile

Added Paths:
---
trunk/harbour/contrib/xhb/xhbhasha.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] Documentation storm on user's list

[Horodyski Marek (PZUZ)]

> -Original Message-
> From: Viktor Szakáts [mailto:harbour...@syenar.hu]
> Sent: Thursday, May 27, 2010 12:03 PM
> To: Harbour Project Main Developer List.
> Subject: [Harbour] Documentation storm on user's list
> 
> To Pete,
> 
[...]
> 
> Strange and insulting thoughts towards anyone who have
> dedicated huge amount (many years) of (maybe even full
> time) to take this project where it is now. 

Viktor,
do not write like that. You know that Harbour is beautiful, beautiful, and once 
again fast :)

Best regards,
Marek Horodyski
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[14614] trunk/harbour

[Viktor Szakáts]

> FUNCTION SubscribeNow( ... )
>   RETURN {| mtx, nTimeOut, lSubscribed |
>local xSubscribed
>lSubscribed := hb_mutexSubscribeNow( mtx, iif( hb_isNumeric( 
> nTimeOut ), nTimeOut / 1000, ), @xSubscribed )
>return xSubscribed
>  }:eval( ... )
> 
> Why this code is written in such complicated way???

Only because I mechanically converted translations.

Anyhow this version got deleted in the next commit, 
and now the already existing clean version is live 
again.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[14614] trunk/harbour

[Mindaugas Kavaliauskas]

Hi,



   + contrib/xhb/hbcompat.prg
 + Added equivalent function wrappers for all hbcompat.ch
   translations where such was possible (everywhere besides
   "dirty" extensions of original Clipper functions)


FUNCTION SubscribeNow( ... )
   RETURN {| mtx, nTimeOut, lSubscribed |
local xSubscribed
lSubscribed := hb_mutexSubscribeNow( mtx, iif( 
hb_isNumeric( nTimeOut ), nTimeOut / 1000, ), @xSubscribed )

return xSubscribed
  }:eval( ... )

Why this code is written in such complicated way???


Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14617] trunk/harbour

[vszakats]

Revision: 14617
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14617&view=rev
Author:   vszakats
Date: 2010-05-27 13:22:44 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 15:21 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/xhb/xhbfunc.c
+ Added XHB_NETNAME(), XHB_MEMOWRIT()

  * contrib/xhb/hbcompat.ch
! Fixed MEMOWRIT() translation. Someone pls test it with
  real xhb.

  * contrib/xhb/hbcompat.ch
  * contrib/xhb/xhb.ch
! Moved xhb_*() function dependent translations to xhb.ch.
  (since the promise is that hbcompat.ch translations don't
  need xhb lib)

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/xhb/hbcompat.ch
trunk/harbour/contrib/xhb/xhb.ch
trunk/harbour/contrib/xhb/xhbfunc.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] HBMK2 Inquiry

[Viktor Szakáts]

Hi Jerry,

>> No clue from here, maybe a broken mingw installation.
>> To tell more pls post -trace output and hbmk2 cmdline.
> 
> I did some research and found out that
> this is a bug from mingw 4.5. It was fixed
> before but I don't know why it resurface.
> So for now Im dropping 4.5 and wait for
> the official release.

I'm using official mingw 4.5 release without such 
problem, though this may depend on the input (or 
build options) you're trying use.

> BTW can you check if nxcompat is supported 
> for TDM mingw 4.4? Im getting an error compiling

It doesn't, so for all 4.4 mingw versions, 
nxcompat is disabled.

Quote from mingw.mk:
---
# It is also supported by official mingw 4.4.x and mingw64 4.4.x,
# but not supported by mingw tdm 4.4.x, so I only enable it on or
# above 4.5.0.
---

> hbpp.exe with gcc saying nxcompat is not a
> valid option.

You should delete HB_COMPILER=mingw and let 
the build autodetect everything. It will work.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] HBMK2 Inquiry

[Jerry Finuliar]

Hi Viktor,


>No clue from here, maybe a broken mingw installation.
>To tell more pls post -trace output and hbmk2 cmdline.

I did some research and found out that
this is a bug from mingw 4.5. It was fixed
before but I don't know why it resurface.
So for now Im dropping 4.5 and wait for
the official release.

BTW can you check if nxcompat is supported 
for TDM mingw 4.4? Im getting an error compiling
hbpp.exe with gcc saying nxcompat is not a
valid option.

Thanks for the time

Jerry




-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14616] trunk/harbour

[vszakats]

Revision: 14616
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14616&view=rev
Author:   vszakats
Date: 2010-05-27 12:55:18 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 14:54 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/xhb/hbcompat.ch
* Grouped together all translations which cannot be
  replaced using wrapper technique.

  * contrib/xhb/xhbgt.c
  * contrib/xhb/xhbfunc.c
! Deleted two wrappers which cannot be wrappers.
  (dirty extensions)

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/xhb/hbcompat.ch
trunk/harbour/contrib/xhb/xhbfunc.c
trunk/harbour/contrib/xhb/xhbgt.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14615] trunk/harbour

[vszakats]

Revision: 14615
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14615&view=rev
Author:   vszakats
Date: 2010-05-27 12:48:11 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 14:42 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
   * contrib/xhb/Makefile
   - contrib/xhb/hbcompat.prg
   + contrib/xhb/xhbfunp.prg
 * Renamed.

   * contrib/xhb/Makefile
   * contrib/xhb/xhbmt.prg
   + contrib/xhb/xhbmtc.c
   * contrib/xhb/xhbfunp.prg
 % Some .prg wrappers changed to .c ones.
 ! This also fixed some double implementation
   after previous commit.

   * contrib/xhb/xhbarr.c
   * contrib/xhb/xhbfunp.prg
 % Converted RASCAN wrapper to .c and moved to
   existing array wrapper source file.

   * contrib/xhb/Makefile
   * contrib/xhb/xhbfunc.c
   + contrib/xhb/xhbhash.c
 % Moved hash wrappers to separate file.
   (also synced with xhbfunp.prg content)
 - Deleted special macro to disable these wrappers.

   * contrib/xhb/Makefile
   * contrib/xhb/xhbfunc.c
   + contrib/xhb/xhbinet.c
 % Moved inet function wrappers to separate file.
   (also synced with xhbfunp.prg content)
 - Deleted special macro to disable these wrappers.

   * contrib/xhb/Makefile
   * contrib/xhb/xhbfunp.prg
   + contrib/xhb/xhbgt.c
   + contrib/xhb/xhbini.c
   + contrib/xhb/xhbproc.c
   + contrib/xhb/xhbregx.c
   + contrib/xhb/xhbmtc.c
   + contrib/xhb/xhbfs.c
   + contrib/xhb/xhbdate.c
   + contrib/xhb/xhbi18n.c
 % Rewritten wrappers in .c and moved them to
   separate files.

   ; Few other double definitions fixed after previous commit.
 Hopefully now it's optimal and modular, and the best wrappers
 were kept.
   ; Basically hbcompat.ch is now not of too much use, unless
 someone specifically want to avoid linking xhb.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/xhb/Makefile
trunk/harbour/contrib/xhb/xhbarr.c
trunk/harbour/contrib/xhb/xhbfunc.c
trunk/harbour/contrib/xhb/xhbmt.prg

Added Paths:
---
trunk/harbour/contrib/xhb/xhbdate.c
trunk/harbour/contrib/xhb/xhbfs.c
trunk/harbour/contrib/xhb/xhbfunp.prg
trunk/harbour/contrib/xhb/xhbgt.c
trunk/harbour/contrib/xhb/xhbhash.c
trunk/harbour/contrib/xhb/xhbi18n.c
trunk/harbour/contrib/xhb/xhbinet.c
trunk/harbour/contrib/xhb/xhbini.c
trunk/harbour/contrib/xhb/xhbmtc.c
trunk/harbour/contrib/xhb/xhbproc.c
trunk/harbour/contrib/xhb/xhbregx.c

Removed Paths:
-
trunk/harbour/contrib/xhb/hbcompat.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14614] trunk/harbour

[vszakats]

Revision: 14614
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14614&view=rev
Author:   vszakats
Date: 2010-05-27 10:59:44 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 12:58 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/xhb/Makefile
  + contrib/xhb/hbcompat.prg
+ Added equivalent function wrappers for all hbcompat.ch
  translations where such was possible (everywhere besides
  "dirty" extensions of original Clipper functions)
; NOTE: This method, as is now, has some advantages:
- doesn't require modification of app source code.
- doesn't require knowledge about hbcompat.ch.
and disadvantages:
- is slightly slower
- will pull unnecessary code parts into the executable
If this change gets positive feedback, the two
disadvantages can be easily mitigated by splitting
hbcompat.prg into multiple .prg sources and replacing
wrappers with .c code where possible.
; Pls review me.

  * contrib/xhb/hbcompat.ch
! Minor cleanup.

  * contrib/hbcomm/hbcomm.prg
! Fixed return value of OUTCHR(). Thank you Przemek for reviewing.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbcomm/hbcomm.prg
trunk/harbour/contrib/xhb/Makefile
trunk/harbour/contrib/xhb/hbcompat.ch

Added Paths:
---
trunk/harbour/contrib/xhb/hbcompat.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Vouch32 ActiveX Server - Unrestricted Version

[A.Mart�nez]

Pritpal

Thank you for all your efforts in harbour project !

Pritpal Bedi escribió en mensaje
<1274945225082-5107328.p...@n2.nabble.com>...
>
>Hello All
>
>I have just uploaded Vouch32 ActiveX Server with
>all the necessary files; application code with .hbp,
>.chm help and the server without any restrictions.
>
>It is compiled with latest Harbour and Przemek's
>excellent contribution towards this end. You do not
>need to ask for license key. Use it. It has all the
>powerful print engine with preview, graphic and charts
>plus report generator, and is extremly easy to use.
>
>The samples/harbour/V32xDemo.prg demonstrate
>the application specific constructs and is accompanied
>by .hbp. The server behaves best under GTWVG or GTWVT,
>where it executes the dialogs in separate thread. But
>console ( windows ) applications like GTWIN can also
>use it.
>
>Demo code also shows how to register server programatically.
>
>More details and screen-shots can be found at
>http://www.vouch32.com/
>
>
>
>-
> enjoy hbIDEing...
>Pritpal Bedi
>http://hbide.vouch.info/
>--
>View this message in context:
http://harbour-devel.1590103.n2.nabble.com/Vouch32-ActiveX-Server-Unrestrict
ed-Version-tp5107328p5107328.html
>Sent from the harbour-devel mailing list archive at Nabble.com.



___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Documentation storm on user's list

[Viktor Szakáts]

To Pete,

[ Sorry to reply here, but I'm readonly user of users-list. ]

> yeah, sure! "very well" and "very idealistic".. 
> (but please keep in mind that idealism is the container of fanaticism 
> -and of any obnoxious "-ism" in general. we  don't need them any more.) 
> "asking" is not only a right, is the "creative trigger" for everything 
> being made by human race; and please don't confuse "asking" with 
> "demanding" nor "user" with "consumer". Into the subject now, maybe it's 
> difficult to understand and accept it but, "documenting" is more 
> valuable than "coding" itself. IMHO, documentation is (or must be) on 
> upper top, in the scale of open source priorities, since documents, or 
> better the lack of documents, is straightly against to the spirit of 
> open source initiative, because if open source, due to lack of 
> documents, is not easily understandable/self-learn-able, becomes 
> unusable to wider programmer-cycles and degenerates to a cryptic tool in 
> hands of an illuminated elite, less or not at all, different than closed 
> software. And this is a real problem with wider consequences than you 
> can imagine. Of course nobody can demand from developers to write 
> manuals. All that one could ask from them is to be, their coding, more 
> documentation friendly, ensuring this way that their valuable and  very 
> respectable labor and creation won't go in vain.. 

Strange and insulting thoughts towards anyone who have 
dedicated huge amount (many years) of (maybe even full 
time) to take this project where it is now. Maybe 
you could elaborate on what you mean by "documentation 
friendly code"...

If coding means nothing to you, pls delete all the 
Harbour sources and try to use it after...

If documentation is so important, why wasn't there 
even a single person (f.e. you?) who would take the pain 
and write even a small snippet of it? By now if every user 
who benefitted from this free product named Harbour, 
would have done so, we'd probably have a full documentation.
All information is right there in the source, mailing 
list and ChangeLog, open and accessible to everyone, 
and all educated questions (unlike the one that started 
off this thread) used to be answered on our forums, 
and yes it sometimes triggers ideas as you say, but the 
emphasis is on "educated".

Remember you got something for free, so before demanding 
anything, asking for more or complaining like children, 
think about what _you_ can do to change the situation.

Idealism is thinking that you get can everything from 
thin air, without thinking, learning, contributing 
and/or paying for it.

In reality potential users have three choices for _all_ 
open source software:

- don't use it
- accept what's offered
- contribute (that's also the best form to say "thank you")

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Vouch32 ActiveX Server - Unrestricted Version

[Viktor Szakáts]

Thank you Pritpal for this contribution to the 
Harbour community.

I'm going to check VOUCH now.

Viktor

On 2010 May 27, at 09:27, Pritpal Bedi wrote:

> 
> Hello All
> 
> I have just uploaded Vouch32 ActiveX Server with 
> all the necessary files; application code with .hbp, 
> .chm help and the server without any restrictions.
> 
> It is compiled with latest Harbour and Przemek's 
> excellent contribution towards this end. You do not 
> need to ask for license key. Use it. It has all the 
> powerful print engine with preview, graphic and charts
> plus report generator, and is extremly easy to use.
> 
> The samples/harbour/V32xDemo.prg demonstrate 
> the application specific constructs and is accompanied 
> by .hbp. The server behaves best under GTWVG or GTWVT,
> where it executes the dialogs in separate thread. But 
> console ( windows ) applications like GTWIN can also 
> use it.
> 
> Demo code also shows how to register server programatically.
> 
> More details and screen-shots can be found at 
> http://www.vouch32.com/
> 
> 
> 
> -
> enjoy hbIDEing...
>Pritpal Bedi 
> http://hbide.vouch.info/
> -- 
> View this message in context: 
> http://harbour-devel.1590103.n2.nabble.com/Vouch32-ActiveX-Server-Unrestricted-Version-tp5107328p5107328.html
> Sent from the harbour-devel mailing list archive at Nabble.com.
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [SPAM] [Harbour] Re: SF.net SVN: harbour-project:[14593] trunk/harbour

[Massimo Belgrano]

 have tried in a machine with Crystal report XI installed and not show
anythig
on machine without crystal report

What i have miss?

function main()
  local oCrystal
local oReport
local oCrViewer
local adbf,i
 aDbf := {}
 AADD( aDbf, { "FN", "N", 10, 0 } )
 AADD( aDbf, { "FNF", "N", 12, 4 } )
 AADD( aDbf, { "FC", "C", 40, 0 } )
 AADD( aDbf, { "FD", "D", 8, 0 } )
 AADD( aDbf, { "FL", "L", 1, 0 } )
 AADD( aDbf, { "FM", "M", 0, 0 } )
 dbCreate("dbtest",aDbf)
 use dbtest
 for i = 1 to 15
append blank
replace fn with INT(sin(i)*i)
replace fnf with sin(i)*i
replace fc with replicate( CHR(65+INT(ABS(sin(i)*25)) ), 40 )
replace fd with date() + MOD(INT(sin(i)*i),1)
replace fl with IIF( SIN(i) >= 0, .T., .F. )
 next
oCrystal := CreateObject( "CrystalRuntime.Application.11" )
oReport  := oCrystal:OpenReport("dbtest.RPT") // was ( crpt)
oCrViewer:= CreateObject("CrystalReports11.ActiveXReportViewer.1")

oReport:DiscardSavedData()
oReport:ReadRecords()
oCrViewer:reportsource(oReport)
oCrViewer:ViewReport()
//oReport:Printout(.t.)
wait
RETURN NIL

function sin
   PARAMETER X_VALORE
   return (X_vALORE - INT(X_VALORE/6.28)*6.28 - 3.14)/3.14



-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[14609] trunk/harbour

[Viktor Szakáts]

Thanks very much, I'll update the code.

I have two questions/notes:

- I noticed that COM_NUM may not be what 
original CT does, though the NG is a little 
bit easy to misunderstand. It looks COM_NUM() 
now returns next free slot, while in CT it 
returned maximum number of com ports.
- If COM_NUM() returns max number of port slots, 
how to retrieve next free one?

Viktor

On 2010 May 27, at 09:05, Przemysław Czerpak wrote:

> On Wed, 26 May 2010, vszak...@users.sourceforge.net wrote:
> 
> Hi,
> 
>> 2010-05-27 00:15 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>>  * utils/hbmk2/examples/contribf.hbc
>>  * contrib/Makefile
>>  + contrib/hbcomm
>>  + contrib/hbcomm/Makefile
>>  + contrib/hbcomm/hbcomm.hbc
>>  + contrib/hbcomm/hbcomm.prg
>>  + contrib/hbcomm/hbcomm.hbp
>>  + contrib/hbcomm/tests
>>  + contrib/hbcomm/tests/hbmk.hbm
>>  + contrib/hbcomm/tests/test.prg
>>+ Added HBCOMM compatibility library. It's based on hbct
>>  COM functions. Not tested with real port. Also see one
>>  TOFIX and one INCOMPATIBILITY note inside. The latter
>>  belongs to INCHR() function which in original HBCOMM
>>  library will do HVM corruption by overwriting string
>>  content passed as 3rd parameter. In Harbour 3rd
>>  parameter needs to be passed by reference.
>>  Also added fully adapted test code from HARBOUR MINIGUI
>>  project. Interestingly this code was using the return
>>  value of INCHR() to get the returned buffer, which was
>>  in sync with included HBCOMM code. Anyway, hopefully
>>  this can be finalized based on report from real users.
> 
> Thank you for your contribution.
> I do not know HBCOMM library so I cannot help you much but you
> wrote in the code:
> 
>   /* Send out characters. Returns .t. if successful. */
>   FUNCTION OUTCHR( nPort, cString )
>  RETURN com_send( nPort, cString )
> 
> and this function return number of character which were not sent.
> If your comment is correct then it should be changed to:
> 
>   FUNCTION OUTCHR( nPort, cString )
>  RETURN com_send( nPort, cString ) == 0
> 
> otherwise the description should be updated.
> 
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] HBMK2 problem

[Viktor Szakáts]

Hi Przemek,

>> Another thing I noticed is that I cannot build 
>> watcom servers, not clients. For servers it 
>> complains about 'Error! E2030: file clib3s.lib(cstrtwwt): multiple starting 
>> addresses found', 
>> for clients there are unresolved symbol, even 
>> if I comment the special -cflag in .hbp.
> 
> You have to recompile whole Harbour core code with HB_USER_CFLAGS=-6r
> to resolve insufficient dependencies.
> The multiple entry points are probably caused by DllMain() in hbwin.lib
> and WinMain() in hbvm.lib so linker does not know which one should chose.

Yes.

> Maybe it can be resolved by adding some linker command to hbolesrv-watcom.def.
> For sure it can be done by linking hbolesrv.c directly not from library.
> In such case linker gives higher priority to code in .obj files so takes
> DllMain() from hbolesrv.obj before begins to scan libraries.
> If you link OLE server dynamically then it also resolves this problem.
> Alternatively we can move WinMain() to separate library or remove strict
> binding to HVM (hb_forceLinkMainWin()) and add some code to HBMK2 which
> will force linking with WinMain() if necessary (GUI application is created).
> hb_forceLinkMainWin reference was added to HVM code for quite old OpenWatcom
> versions and maybe can be eliminated now or maybe it's enough to add some
> commands to link script by HBMK2. Removing hb_forceLinkMainWin() reference
> from watcom builds should resolve the problem. You only have to check if
> HBMK2 can still create static GUI binaries for using OW.

I'd appreciate if you could find some to make 
some patches, I'll try to follow it with hbmk2.

>> I think watcom should truly be fixed by switching 
>> to default callconv on the Harbour level, though 
>> in this case for win/watcom builds all HB_EXPORT 
>> declarations need have a __cdecl modifier added 
>> between return type and function name. And this is 
>> currently not possible without creating a new scheme 
>> for public C function declaration (at least I could 
>> not find a painless solution).
> 
> The problem is only for users who will want to use harbour.dll
> created by Open Watcom with some other C languages so it's not
> very common. Probably we should ignore it now switch to register
> calling convention and then if possible look for some solutions
> which can force using C calling convention for exported Harbour
> functions.

It also causes that watcom builds cannot utilized 
harbour.dll created with non-watcom compiler, which 
is a problem, because in windows unified build I 
include harbour.dll built with mingw, so in effect 
watcom -shared mode doesn't work by default.

Shipping special watcom .dlls is not a good option 
due to size, so maybe win/watcom libs can just be 
dropped from the distro as a solution, albeit a 
drastic one and rather a workaround.

Do you see any notion or chance to fix the issue 
by using __cdelc for watcom?

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] HBMK2 Inquiry

[Viktor Szakáts]

Hi,

> hbmk2: Compiling...
> hbmk2: Linking... conso.exe
> Info: resolving vtable for __cxxabiv1::__si_class_type_info by linking to 
> __imp_
> __ZTVN10__cxxabiv120__si_class_type_infoE (auto-import)
> Info: resolving vtable for __cxxabiv1::__class_type_info by linking to 
> __imp___Z
> TVN10__cxxabiv117__class_type_infoE (auto-import)
> Info: resolving vtable for __cxxabiv1::__vmi_class_type_info by linking to 
> __imp
> ___ZTVN10__cxxabiv121__vmi_class_type_infoE (auto-import)
> Info: resolving std::cout  by linking to __imp___ZSt4cout (auto-import)
> c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: 
> warning: a
> uto-importing has been activated without --enable-auto-import specified on 
> the c
> ommand line.
> This should work unless it involves constant data structures referencing 
> symbols
> from auto-imported DLLs.
> 
> Can someone explain what this means? 

No clue from here, maybe a broken mingw installation.
To tell more pls post -trace output and hbmk2 cmdline.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: SF.net SVN: harbour-project:[14611] trunk/harbour

[Viktor Szakáts]

>>> + contrib/hbqt/hbqt.h
>>>   + Added: constants hbqt_par_Qsci* 
>>> ; TODO make them local.
>> 
>> This is serious modularization fault, 
>> even for an initial upload. Pls fix it.
>> 
> 
> Yes, sure.
> I need a name of such .h - hbqt_local.h ?

contrib/hbqt/qscintilla/hbqscintilla.h
  which refers to ../hbqt.h

>>>   + Initial upload of wrappers for QScintilla.
>>> To generate the sources auto you need to stay in hbqt/hbqscintilla
>>> and issue ../generator/hbqtgen.
>>> 
>>> HB_WITH_QSCINTILLA and HB_WITH_QT need be properly defined.
>>> I am still finding where to host modified QScintilla, any tips ?
>> 
>> Are you sure you need to modify this 
>> external lib to make it work with HBQT?
>> 
> 
> My experiments say it is must.
> 
> 1. Flagship lexer is not implemented in QScintilla which I did.

Smells like an upstream patch.

> 2. May be it can go, but a lot of warnings while compiling QScintilla as per 
>   Harbour make system.

It can be suppressed, or just simply ignored. 
It's not our code, they are not our warnings, 
if it works, it's good for us.

> 3. I could only build static lib, .a, and do not know how to a shared one,
> .dll.

That's a problem hitting distribution, not 
code hosting. If the code needs to be patched, 
it looks like a definite upstream patch.

> 4. One serious issue which I could not resolve, commenting out a line 
>delete [] words; solved the problem, otherwise GPF. I know it may lead 
>to leaked memory but unless someone with more knowledge look into it,
>I could not fix. "words" is defined as - char * words.

Looks like a serious problem to me. Current 
solution is not a very good hack. Could be 
upstream bug to fix, I don't know.

> 5. It is just the begining, I may need some more tweaking to achieve 
>some more goals, so may be needing to tweak Scintilla sources itself.

That's bad direction, I'd very strongly suggest to 
avoid forking. Take it a black-box and use as is, 
as documented. If there is a problem, report back 
to author or qscintilla forums.

> 6. Author, Phil Thomson, did not reply when I offered Flagship lexer code 
>to him plus few fixes to get rid of the warnings. His only reply was,
> 
> "I don't understand this. By including QScintilla your application must
> becompatible with the GPL. This means that you must make all the source
> codeavailable to your users, and allow them to rebuild the application. So
> whycan't you build it yourself as well? "

Because we do not want to fork. But it's possible 
that your patch wasn't generic or had other problems,
so upstream patch is not always the answer, or it may 
need to be reiterated.

>It was on request that if he can provide a binary distro anyway because
> Harbour
>users do not know enough about Qt and its build system.
>As hbIDE itself is open source, it confirm to GPL license, so no issues.
>The only problem is how to manage it.

My impression is still that it'd be the best to 
move hosting of complete HBIDE and even HBQT to 
a different repository with more lax rules, so 
you could manually maintain a fork if you think 
it's the best solution. While I believe it should 
be technically possible to avoid the fork and 
solve everything without massive (or even any) 
QSCINTILLA patches), I see a very bumpy road ahead 
and lots of wasted energy.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14613] trunk/harbour

[vouchcac]

Revision: 14613
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14613&view=rev
Author:   vouchcac
Date: 2010-05-27 07:51:42 + (Thu, 27 May 2010)

Log Message:
---
2010-05-27 00:45 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/hbqscintilla/qth/HBQsciScintilla.qth
  * contrib/hbqt/hbqscintilla/qth/QsciAbstractAPIs.qth
  * contrib/hbqt/hbqscintilla/qth/QsciAPIs.qth
  * contrib/hbqt/hbqscintilla/qth/QsciCommand.qth
  * contrib/hbqt/hbqscintilla/qth/QsciCommandSet.qth
  * contrib/hbqt/hbqscintilla/qth/QsciDocument.qth
  * contrib/hbqt/hbqscintilla/qth/QsciLexer.qth
  * contrib/hbqt/hbqscintilla/qth/QsciLexerCPP.qth
  * contrib/hbqt/hbqscintilla/qth/QsciLexerFlagship.qth
  * contrib/hbqt/hbqscintilla/qth/QsciScintilla.qth
  * contrib/hbqt/hbqscintilla/qth/QsciStyle.qth
  * contrib/hbqt/hbqscintilla/qth/QsciStyledText.qth

  * contrib/hbqt/hbqscintilla/QSci*.cpp

  + contrib/hbqt/hbqscintilla/hbqt_local.h
+ Localized: hbqt_par_Qsci*()

  * contrib/hbqt/doc/en/class_qchar.txt
  * contrib/hbqt/doc/en/class_qthread.txt
  * contrib/hbqt/qtcore/QChar.cpp
  * contrib/hbqt/qtcore/QThread.cpp
  * contrib/hbqt/qtcore/TQChar.prg
  * contrib/hbqt/qtcore/TQThread.prg
  * contrib/hbqt/qth/QThread.qth
! Regenerated.

  * contrib/hbqt/hbqt.h
- Removed: hbqt_par_Qsci*()

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/doc/en/class_qchar.txt
trunk/harbour/contrib/hbqt/doc/en/class_qthread.txt
trunk/harbour/contrib/hbqt/hbqscintilla/HBQsciScintilla.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciAPIs.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciAbstractAPIs.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciCommand.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciCommandSet.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciDocument.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciLexer.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciLexerCPP.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciLexerFlagship.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciScintilla.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciStyle.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/QsciStyledText.cpp
trunk/harbour/contrib/hbqt/hbqscintilla/qth/HBQsciScintilla.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciAPIs.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciAbstractAPIs.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciCommand.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciCommandSet.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciDocument.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciLexer.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciLexerCPP.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciLexerFlagship.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciScintilla.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciStyle.qth
trunk/harbour/contrib/hbqt/hbqscintilla/qth/QsciStyledText.qth
trunk/harbour/contrib/hbqt/hbqt.h
trunk/harbour/contrib/hbqt/qtcore/QChar.cpp
trunk/harbour/contrib/hbqt/qtcore/QThread.cpp
trunk/harbour/contrib/hbqt/qtcore/TQChar.prg
trunk/harbour/contrib/hbqt/qtcore/TQThread.prg
trunk/harbour/contrib/hbqt/qth/QThread.qth

Added Paths:
---
trunk/harbour/contrib/hbqt/hbqscintilla/hbqt_local.h


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Vouch32 ActiveX Server - Unrestricted Version

[Pritpal Bedi]

Hello All

I have just uploaded Vouch32 ActiveX Server with 
all the necessary files; application code with .hbp, 
.chm help and the server without any restrictions.

It is compiled with latest Harbour and Przemek's 
excellent contribution towards this end. You do not 
need to ask for license key. Use it. It has all the 
powerful print engine with preview, graphic and charts
plus report generator, and is extremly easy to use.

The samples/harbour/V32xDemo.prg demonstrate 
the application specific constructs and is accompanied 
by .hbp. The server behaves best under GTWVG or GTWVT,
where it executes the dialogs in separate thread. But 
console ( windows ) applications like GTWIN can also 
use it.

Demo code also shows how to register server programatically.

More details and screen-shots can be found at 
http://www.vouch32.com/



-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/Vouch32-ActiveX-Server-Unrestricted-Version-tp5107328p5107328.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[14609] trunk/harbour

[Przemysław Czerpak]

On Wed, 26 May 2010, vszak...@users.sourceforge.net wrote:

Hi,

> 2010-05-27 00:15 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>   * utils/hbmk2/examples/contribf.hbc
>   * contrib/Makefile
>   + contrib/hbcomm
>   + contrib/hbcomm/Makefile
>   + contrib/hbcomm/hbcomm.hbc
>   + contrib/hbcomm/hbcomm.prg
>   + contrib/hbcomm/hbcomm.hbp
>   + contrib/hbcomm/tests
>   + contrib/hbcomm/tests/hbmk.hbm
>   + contrib/hbcomm/tests/test.prg
> + Added HBCOMM compatibility library. It's based on hbct
>   COM functions. Not tested with real port. Also see one
>   TOFIX and one INCOMPATIBILITY note inside. The latter
>   belongs to INCHR() function which in original HBCOMM
>   library will do HVM corruption by overwriting string
>   content passed as 3rd parameter. In Harbour 3rd
>   parameter needs to be passed by reference.
>   Also added fully adapted test code from HARBOUR MINIGUI
>   project. Interestingly this code was using the return
>   value of INCHR() to get the returned buffer, which was
>   in sync with included HBCOMM code. Anyway, hopefully
>   this can be finalized based on report from real users.

Thank you for your contribution.
I do not know HBCOMM library so I cannot help you much but you
wrote in the code:

   /* Send out characters. Returns .t. if successful. */
   FUNCTION OUTCHR( nPort, cString )
  RETURN com_send( nPort, cString )

and this function return number of character which were not sent.
If your comment is correct then it should be changed to:

   FUNCTION OUTCHR( nPort, cString )
  RETURN com_send( nPort, cString ) == 0

otherwise the description should be updated.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] HBMK2 problem

[Przemysław Czerpak]

On Wed, 26 May 2010, Szak�ts Viktor wrote:

Hi Viktor,

> Another thing I noticed is that I cannot build 
> watcom servers, not clients. For servers it 
> complains about 'Error! E2030: file clib3s.lib(cstrtwwt): multiple starting 
> addresses found', 
> for clients there are unresolved symbol, even 
> if I comment the special -cflag in .hbp.

You have to recompile whole Harbour core code with HB_USER_CFLAGS=-6r
to resolve insufficient dependencies.
The multiple entry points are probably caused by DllMain() in hbwin.lib
and WinMain() in hbvm.lib so linker does not know which one should chose.
Maybe it can be resolved by adding some linker command to hbolesrv-watcom.def.
For sure it can be done by linking hbolesrv.c directly not from library.
In such case linker gives higher priority to code in .obj files so takes
DllMain() from hbolesrv.obj before begins to scan libraries.
If you link OLE server dynamically then it also resolves this problem.
Alternatively we can move WinMain() to separate library or remove strict
binding to HVM (hb_forceLinkMainWin()) and add some code to HBMK2 which
will force linking with WinMain() if necessary (GUI application is created).
hb_forceLinkMainWin reference was added to HVM code for quite old OpenWatcom
versions and maybe can be eliminated now or maybe it's enough to add some
commands to link script by HBMK2. Removing hb_forceLinkMainWin() reference
from watcom builds should resolve the problem. You only have to check if
HBMK2 can still create static GUI binaries for using OW.

> I think watcom should truly be fixed by switching 
> to default callconv on the Harbour level, though 
> in this case for win/watcom builds all HB_EXPORT 
> declarations need have a __cdecl modifier added 
> between return type and function name. And this is 
> currently not possible without creating a new scheme 
> for public C function declaration (at least I could 
> not find a painless solution).

The problem is only for users who will want to use harbour.dll
created by Open Watcom with some other C languages so it's not
very common. Probably we should ignore it now switch to register
calling convention and then if possible look for some solutions
which can force using C calling convention for exported Harbour
functions.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour