2008-10-01 23:52 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* contrib/hbfbird/firebird.c
! Added ugly hack to make it compile with Firebird 2.1.1
and BCC 5.8.2 (and upper).
This way all Win32/Win64 builds are now supporting
this newer version of Firebird. DOS still nee
That was it - Thanks!
At 02:14 PM 10/1/2008, you wrote:
Hi Randy,
Did you use ANNOUNCE HB_GTSYS in that app?
Brgds,
Viktor
On 2008.10.01., at 20:09, Randy Portnoff wrote:
Hi all,
I can successfully link various apps using gtgui - However, one app
just won't link and I can't see why - I get
Hi Przemek,
Many thanks, I didn't know that. But I've noticed
the refresh problem.
I agree with adding these, but it's probably better
if I leave this for someone familiar with MT and GT.
Personal question: If only the core is compiled with
-gc3, could it cause problems in real life, if I'm not
Hi Randy,
Did you use ANNOUNCE HB_GTSYS in that app?
Brgds,
Viktor
On 2008.10.01., at 20:09, Randy Portnoff wrote:
Hi all,
I can successfully link various apps using gtgui - However, one app
just won't link and I can't see why - I get this link error:
hbrtl.lib(gtsys.obj) : error LNK2019
Hi all,
I can successfully link various apps using gtgui - However, one app
just won't link and I can't see why - I get this link error:
hbrtl.lib(gtsys.obj) : error LNK2019: unresolved external symbol
_HB_FUN_HB_GT_WIN referenced in function _hb_gt_ForceLink_HB_GT_WIN
How can I get around
On Wed, 01 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
> I'd like to ask for opinions on turning on Harbour
> -gc3 switch (native C code generation) for core .prg code.
> The involved code parts are high-level functions in RTL,
> the debugger and some high-level RDD functions.
> To me it seems tha
On Wed, Oct 1, 2008 at 5:41 PM, Lorenzo Fiorini
<[EMAIL PROTECTED]> wrote:
> instead of the #xcommand VAR ... trick, could I have ( in my local
> Harbour ) VAR as synonymous of LOCAL?
Sorry forget this, "local var" works so I'll add:
#xcommand LOCAL VAR => LOCAL
#xcommand STATIC VAR => STATIC
>I'd like to ask for opinions on turning on Harbour
>-gc3 switch (native C code generation) for core .prg code.
Viktor, I´m using -gc3 and I had no problems. I´d compiled full
Harbour, my application and FWH with -gc3.
The results are fastest code and bigger .exe, but I don´t see any
problem with
On Wed, Oct 1, 2008 at 5:00 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> Because ';' is line concatenator in PP. Just look at .ppo file.
> Prepocessor is before compiler and compiler does not know
> ...
> cb:= ( {||
> ? "EXT BLOKCK"
> return NIL
> } )
Ok now I got it., sorry.
GUI/IDE should help to create apps, but not be the only one.
I don't want to force anyone to change anything.
The ":=" vs "=" vs "==" vs "SET EXACT" ambiguity exist today.
What I think would be good for Harbour is to be as clean as possible:
1) I think that "=" should be valid wherever ":=" i
On Wed, 01 Oct 2008, Lorenzo Fiorini wrote:
Hi Lorenzo.
> > This is not compiler but PP issue. You will have to change
> > line concatenation character otherwise PP will make from
> > these 3 lines single lines which will be preprocessed and
> > then passed to compiler.
> > So you are asking to u
2008/10/1 ABIX - Adam Jurkiewicz <[EMAIL PROTECTED]>:
> Just one word, Lorenzo, please consider the sutiation, in which I (as old
> Clipper programer) used to use ":=".
> I think in today world, in wich GUI and IDE and RAD (rapid app. devel.) are
> the most common used by young programmers (who re
Hi Lorenzo,
If the goal is to make Harbour compatible with Eclipse,
IMO one should rather try to contribute the relevant
parts to the Eclipse project itself, instead of changing
the Clipper language to fit into their existing concept.
Maybe it's just a matter of creating a syntax-rule file.
On Wed, Oct 1, 2008 at 3:16 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> This is not compiler but PP issue. You will have to change
> line concatenation character otherwise PP will make from
> these 3 lines single lines which will be preprocessed and
> then passed to compiler.
> So you are
Dnia środa, 1 października 2008, Lorenzo Fiorini napisał:
> But this apart the "=" vs ":=" and the semicolon issues are general
> issue that will only improve the acceptance of the language.
Just one word, Lorenzo, please consider the sutiation, in which I (as old
Clipper programer) used to use "
Hi Mindaugas,
Szakáts Viktor wrote:
I'd like to ask for opinions on turning on Harbour
-gc3 switch (native C code generation) for core .prg code.
To me it seems that enabling this switch gives a
noticeable performance boost (mainly to tget, tbrowse,
and other UI classes). The cost is a slight
Hi Przemek,
Przemyslaw Czerpak ha scritto:
Syntax highlighting in some editors is not a problem. It's enough to update
highlighting rules in used editor. AFAIR in the past Giancarlo created .prg
rules for eclipse or some other popular IDE.
AFAIK only for Kate, that I use under Linux/CentOS/KDE
> If the goal is to make Harbour compatible with Eclipse, IMO one should
> rather try to contribute the relevant parts to the Eclipse project
> itself, instead of changing the Clipper language to fit into their
> existing concept.
>This was my first idea. I've contacted a Java developer but he t
On Wed, Oct 1, 2008 at 1:01 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> If the goal is to make Harbour compatible with Eclipse,
> IMO one should rather try to contribute the relevant
> parts to the Eclipse project itself, instead of changing
> the Clipper language to fit into their existing co
Szakáts Viktor wrote:
I'd like to ask for opinions on turning on Harbour
-gc3 switch (native C code generation) for core .prg code.
To me it seems that enabling this switch gives a
noticeable performance boost (mainly to tget, tbrowse,
and other UI classes). The cost is a slightly larger
final e
On Wed, 01 Oct 2008, Lorenzo Fiorini wrote:
Hi Lorenzo,
> JavaScript is a widely used and known language and I've found that
> with few changes an Harbour source can be "digested" by IDEs like
> Eclipse or NetBeans as a JavaScript source and that these changes can
> also "fix" some "ambiguities"
2008-10-01 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* contrib/hbct/ctmisc.prg
! Fix to CENTER() when 3rd param is logical.
+ Added ALLOFREE().
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbou
On Wed, 01 Oct 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
> The results are:
> ARR_LEN = 16 ST MT MT
> N_LOOPS =100USE_TLS
[...]
> total application time: 64.95 100.00 89.30
> Previous MT overhead
On Wed, Oct 1, 2008 at 11:22 AM, Lorenzo Fiorini
<[EMAIL PROTECTED]> wrote:
> 1) {} to enclose function's body. This valid code:
xcommand { =>
xcommand } =>
Is it correct to say that these will remove "only" curly braces that
are in a line by itself?
best regards,
Lorenzo
__
Hi Lorenzo and all,
1) {} to enclose function's body. This valid code:
2) ";" as statement separator. This is a valid code:
3) "=" vs "==" vs ":="
Comments?
This wouldn't be Clipper anymore.
C-like syntax with Clipper-like high-levelness is
already implemented as C#.
If the goal is to mak
JavaScript is a widely used and known language and I've found that
with few changes an Harbour source can be "digested" by IDEs like
Eclipse or NetBeans as a JavaScript source and that these changes can
also "fix" some "ambiguities" of the actual language.
Moreover I think this "alternative" syntax
Hi folks,
I'd like to ask for opinions on turning on Harbour
-gc3 switch (native C code generation) for core .prg code.
The involved code parts are high-level functions in RTL,
the debugger and some high-level RDD functions.
To me it seems that enabling this switch gives a
noticeable performanc
Przemyslaw Czerpak wrote:
The only reason I see for binding stack preload with "no tls" is that stack
preload also uses inlined Windows like function to access tls. But I see it
as to separate features stack: stack preload and tls access method
(compiler native or system API)?
When compiler n
Also here
http://prdownloads.sourceforge.net/nedmalloc/nedmalloc_v105_svn1078.zip?download
http://prdownloads.sourceforge.net/nedmalloc/nedmalloc_v105_svn1078.zip
I
found dlmalloc V2.8.4
V2.8.4 (not yet released)
* Add mspace_mmap_large_chunks; thanks to Jean Brouwers
* Fix insu
29 matches
Mail list logo
