2008-02-12 08:04 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* harbour/contrib/hbwhat32/make_gcc.sh
! Fixed compilation under MingW and Cygwin
* harbour/contrib/make_b32_all.bat
* harbour/contrib/make_vc_all.bat
+ Added hbwhat32 to a list of compiled contribs
* harbour/cont
On Tue, 12 Feb 2008, Ryszard Głąb wrote:
> OK, hb_gcAlloc() can automatically lock the pointer however we
> still have to have hb_gcUnlock() function to unlock it distinctly
> after the assignment to the item stored inside the iternal VM
> storages (local stack, statics, etc). If the item will r
On Tue, 12 Feb 2008, Mindaugas Kavaliauskas wrote:
> I'm not sure we are talking about the same thing, but if memory are
> dumped to fm.log files, I have a little proposition how to extend output
> to help find memory leaks.
It was not the same thing though maybe address information will help
Pr
On Mon, 11 Feb 2008, Randy Portnoff wrote:
> Hi Przemek,
> I just took a look at (what I think is) the latest build on
> SourceForge and I do not see that HB_GCALL takes any parameters - Are
> you sure there is a difference between hb_gcAll(.t.) and hb_gcAll()?
In Harbour there is no difference
Przemyslaw Czerpak <[EMAIL PROTECTED]> napisał(a):
> I think that it will greatly reduce possible mistakes and also your
> first example will work as you wanted. hb_gcLock()/hb_gcUnlock() are
> a little bit too low level for me if possible then they should be
> eliminated from 3-rd party API.
>
>
Definitely.
I'd also vote to separate for full hbrdd/rdd*, otherwise
we will end up having lots of different combinations with
and without RDD, with and without MT, etc, and at the end
we will have the same amount of libs as we have now, just
the size will be be bigger.
To put it shortly: I'd on
Hi,
The same bug exists in Harbour and xHarbour but only Harbour reports it.
But it can be result of any memory corruption, f.e.:
proc main()
BADCFUNC({})
return
#pragma begindump
#include "hbapiitm.h"
HB_FUNC( BADCFUNC )
{
/* damage 1-st param item type */
Hi Przemek,
I just took a look at (what I think is) the latest build on
SourceForge and I do not see that HB_GCALL takes any parameters - Are
you sure there is a difference between hb_gcAll(.t.) and hb_gcAll()?
TIA.
Regards,
Randy.
At 04:30 PM 2/11/2008, you wrote:
On Mon, 11 Feb 2008, Pri
Thanks.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szakáts Viktor
Sent: Monday, February 11, 2008 1:40 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] OLE Implementation - xHarbour Compatibility
Hi Massimo,
This is it. The first p
On Mon, 11 Feb 2008, Pritpal Bedi wrote:
> I have understood in what circumstances destructors operate. But I have
> never used destructors anywhere. I mean I am not assigning self to any class
> variables, public variables, or even I do not use DESTRUCTOR command in any
> of my classes. Because my
Hello Przemek
Przemyslaw Czerpak-2 wrote:
>
> Clipper does not have destructors and xHarbour cannot detect most
> of destructors errors at all what causes memory corruption and later
> GPFs. See tests/destruct.prg as an example of such errors. It also
> illustrates why destructors are not safe
Enrico,
Thank you for sample.
As expected, your code works well here.
Now trying to squeeze a GPF without success.
The only one change made in xharbour\makefile.bc from -a8 to -a4
Best regards,
Saulius
___
Harbour mailing list
Harbour@harbour-project.or
On Mon, 11 Feb 2008, Maurilio Longo wrote:
> I've got a weird problem, this simple code
> function main()
> ? log(0)
> return nil
> compiled with GCC on OS/2 runs ok on some PCs and fails with a SIGFPE on
> others?!?!
On some systems calling math functions with wrong parameters generates
SIG
source of problem ;-)
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
__ Information from ESET Smart Security, version of virus signature
database 2864 (20080211) __
T
Hi Maurilio,
I think I've found what is causing that 'emxbind failed...' error, you're
probably using eCS and you have a emx\bin directory in your boot disk where
there is an old emxbind.exe which gets called before the one inside
gcc\usr\bin because you have an environment variable named 'PATH'
-Messaggio Originale-
Da: "Saulius Zrelskis" <[EMAIL PROTECTED]>
A: "Harbour Project Main Developer List."
Data invio: lunedì 11 febbraio 2008 14.55
Oggetto: Re: R: [Harbour] OLE Implementation - xHarbour Compatibility
Enrico, have you code, which GPFs with -a4 ?
Here it is:
FUNC
Przemek, Viktor,
> For PCRE we have set of macros you can set in C_USR
envvar before building Harbour to reach such effect, f.e. -DHB_POSIX_REGEX
We can use:
HB_POSIX_REGEX - use POSIX regex instead of PCRE, it should work
on all POSIX systems (f.e. in *nixes)
HB_PCRE
2008-02-11 16:23 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/xhb/wintypes.ch
! added missing => in #ytranslate command - thanks to Alex
* harbour/contrib/hbw32/w32_tole.prg
* fixed typo in one comment
* harbour/contrib/hbw32/w32_ole.c
! added cleanup cod
Saulius Zrelskis wrote:
OLE include files have their suitable #pragma option directives with
restoring _all_ initial settings, so different alignment seems as if
provided by compiler...
Hi,
I also have a question similar to Saulius. Do you know what structures
needs some specific alignment?
On Mon, 11 Feb 2008, Alex Strickland wrote:
> Hi all
> I tried to use the xharbour dll functions with Harbour. hbdll.ch from
> Harbour includes wintypes.ch which *is* in Harbour.
> wintypes.ch has the line:
> #ytranslate CTYPE_INT() Int() /* Fixes conflict with INT()
> function */
> in it. This
On Mon, 11 Feb 2008, Ryszard Glab wrote:
> > Yes. This will be nice solution. The only one problem is with
> > temporary test if in our RTL code will not appear calls to new
> > RDD functions which may force linking both modules. But of course
> > it's a minor problem.
> Can we create then two li
Very useful reading, thank you, Przemek.
It needs deeper tests done, I am extremely interested to assist.
Enrico, have you code, which GPFs with -a4 ?
Have to mention, that before building xHarbour binaries I always search
for "-a8" and replacing with "-a4" (there are about ten places in sources)
Hi, Mindaugas
> One small notice, looking at line:
> > pEntry = (ULONG*) hb_xrealloc( pEntry, ulEntryAlloc * sizeof( ULONG )
> );
> >
> > Compiler must launch warning, that variable pEntry is not initialized;
> > may be assigning to that variable drown this fact...
>
>
> I do not agree here. hb
On Mon, 11 Feb 2008, Guillermo Varona Silupú wrote:
> Please,
> Does Anyone checked this?
> >procedure main
> >use D:\harbour\tests\test.dbf
Add here:
? used(), neterr(), alias()
if used()
? "DBF structure:"
dbEval(dbStruct(),{|x,i|qout(i, "{",x[1],x[2],x[3],x[4],"}")})
els
On Sat, 02 Feb 2008, Mindaugas Kavaliauskas wrote:
> >Multiple putting the same pointer in
> >GC pointer item is not safe. If you think that it should be
> >safe then I can add such functionality but in such case IMHO
> >I should also update hb_itemPutCPtr() to be safe for multiple
> >putting the s
Hi all
I tried to use the xharbour dll functions with Harbour. hbdll.ch from
Harbour includes wintypes.ch which *is* in Harbour.
wintypes.ch has the line:
#ytranslate CTYPE_INT() Int() /* Fixes conflict with INT()
function */
in it. This results in:
\harbour8\include\wintypes.ch(111) Er
Hi,
Saulius Zrelskis wrote:
Thanks for sharing info. I am intensively using BCC and all related info
is very important.
I'm also using BCC, but haven't find anything wrong until now. That's
why I've made assumption it could be my bug.
One small notice, looking at line:
pEntry = (ULONG*)
On 11 Feb 2008 at 14:00, Przemyslaw Czerpak wrote:
> Yes. This will be nice solution. The only one problem is with
> temporary test if in our RTL code will not appear calls to new
> RDD functions which may force linking both modules. But of course
> it's a minor problem.
Can we create then two
m ESET Smart Security, version of virus
signature database 2863 (20080211) __
The message was checked by ESET Smart Security.
http://www.eset.com
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
On Mon, 11 Feb 2008, Marek Paliwoda wrote:
> >Are you absolutly sure ? AFAIK there is *always* a reference to RDD
> >code from VM. Otehrwise it would be possible to link an executable
> >without *any* rdd library, which is IMO impossible. So yes,
> > gcc myapp.o -lnulrdd -lhrb
> >will work.
>
Marek,
I think I've found what is causing that 'emxbind failed...' error, you're
probably using eCS and you have a emx\bin directory in your boot disk where
there is an old emxbind.exe which gets called before the one inside
gcc\usr\bin because you have an environment variable named 'PATH' which h
On Mon, 11 Feb 2008, Marek Paliwoda wrote:
> >There are some techincal differences.
> >1. On some system it will be hard (or impossible) to overload some
> > subsystem using only libraries. F.e. nulrdd which should replaces
> > whole RDD tree for applications which do not want to use any
> >
Marek Paliwoda wrote:
There are some techincal differences.
1. On some system it will be hard (or impossible) to overload some
subsystem using only libraries. F.e. nulrdd which should replaces
whole RDD tree for applications which do not want to use any
RDD releated code will not work i
Hi Massimo,
This is it. The first part basically came from MSVC, my
part comes after ':end', nothing special really. This can
be used for both core and contribs.
(I've never compiled xhb, so I have no idea if this works it)
--
@echo off
@SET VSIN
Przemyslaw Czerpak wrote :
On Sun, 10 Feb 2008, Szakáts Viktor wrote:
I disagree. Having them as separate libraries has no advantages.
I just made some tests with GTs under BCC and including them in
link command changes *nothing*, until you *explicitly* REQUEST
a particular GT. So having them a
On Mon, 11 Feb 2008, Saulius Zrelskis wrote:
> I always compiling xHarbour with BCC -a4 alignment; sizeof(HB_ITEM) = 24
> and memory(HB_MEM_STACK) / memory(HB_MEM_STACKITEMS) = 24.
> But never noticed any anomaly in OLE work. Can you help me how to make
> sure with this?? Till now I think, that it
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szakáts Viktor
Sent: Monday, February 11, 2008 12:23 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] OLE Implementation - xHarbour Compatibility
>Hi Massimo,
>Yes, it's a clean compile with MSVC 2008 Express, too.
Hi Massimo,
Yes, it's a clean compile with MSVC 2008 Express, too.
Brgds,
Viktor
On 2008.02.11., at 10:11, Massimo Belgrano wrote:
Can you tried also MSCV 2008 Express ?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] On Behalf Of Szakáts Viktor
Sent: Monday,
Hello, Przemek
I always compiling xHarbour with BCC -a4 alignment; sizeof(HB_ITEM) = 24
and memory(HB_MEM_STACK) / memory(HB_MEM_STACKITEMS) = 24.
But never noticed any anomaly in OLE work. Can you help me how to make
sure with this?? Till now I think, that it is enough for OLE structures
to be co
On Sun, 10 Feb 2008, Szakáts Viktor wrote:
> >I disagree. Having them as separate libraries has no advantages.
> >I just made some tests with GTs under BCC and including them in
> >link command changes *nothing*, until you *explicitly* REQUEST
> >a particular GT. So having them as separate librarie
I like then Przemyslaw Czerpak's word about CUI-GUI-WWW without source
code modification .
This implementation will grow [x]harbour and give new live to a lot of
clipper application but is interesting also for non clipper developer
I Thanks to all (particularry Przemyslaw ) for the work done in las
On Sun, 10 Feb 2008, Pritpal Bedi wrote:
> Hello Everybody
> I receive this error when executing modules with parent/child relations.
> Child records are shown in a TBrowse.
> DO_MENU (149)description Object Destructor Failure
> MAIN (150) genCode 45
>
Can you tried also MSCV 2008 Express ?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szakáts Viktor
Sent: Monday, February 11, 2008 9:29 AM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] OLE Implementation - xHarbour Compatibility
Hi Al
Oh okey, sorry.
Brgds,
Viktor
On 2008.02.11., at 9:44, Alex Strickland wrote:
Szakáts Viktor wrote:
It's a clean compile now (no errors or warnings) with MSVC.
See my ChangeLog entry from around last week.
Tested with MSVC 2005 Express (the free one) + SDK Vista (also free).
Sorry, I shoul
Hi Viktor,
> >> I like it better still, because these are "plugins" in a sense.
> >
> > But this fact, "in a sense", has *zero* impact on a technical
> > problems
>
> In my first mail regarding this, I clearly wrote that
> while I see no TECHNICAL problems here, yet I (IMHO)
> find it better to ha
Hi Marek,
Hi Viktor,
I like it better still, because these are "plugins" in a sense.
But this fact, "in a sense", has *zero* impact on a technical problems
In my first mail regarding this, I clearly wrote that
while I see no TECHNICAL problems here, yet I (IMHO)
find it better to have them
Szakáts Viktor wrote:
It's a clean compile now (no errors or warnings) with MSVC.
See my ChangeLog entry from around last week.
Tested with MSVC 2005 Express (the free one) + SDK Vista (also free).
Sorry, I should be more specific. I meant the ActiveX support in
FreeWin which I think is only
Hi Alex,
It's a clean compile now (no errors or warnings) with MSVC.
See my ChangeLog entry from around last week.
Tested with MSVC 2005 Express (the free one) + SDK Vista (also free).
Brgds,
Viktor
On 2008.02.11., at 8:14, Alex Strickland wrote:
Pritpal Bedi wrote:
Even compiling Harbour,
Hi David,
On 2008.02.11., at 2:07, David Arturo Macias Corona wrote:
>This is true for make_*os2.cmd, bld.cmd, etc. If these
>were updated by the OS/2 users here (David?), I think
>they're okey, once we've agreed on the filenames.
If they need changes, I can do it
>I'd suggest /make_gnu_os2.c
49 matches
Mail list logo
