While it correctly gives .F. under Linux
procedure main()
local cHome := getenv( "HOME" )
? cHome
? file( cHome + "/.notexist/notexist" )
return
Any hint?
best regards,
Lorenzo
___
Harbour mailing list
Harbour@harbour-project.org
http:/
On Wed, 05 Mar 2008, Lorenzo Fiorini wrote:
> While it correctly gives .F. under Linux
> procedure main()
>local cHome := getenv( "HOME" )
>? cHome
>? file( cHome + "/.notexist/notexist" )
>return
> Any hint?
What hardware?
Most of non x86 CPUs needs strict alignment. Have you comp
On Wed, Mar 5, 2008 at 12:47 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> What hardware?
PPC32
> Most of non x86 CPUs needs strict alignment. Have you compiled
> Harbour with HB_STRICT_ALIGNMENT macro?, f.e.:
>export C_USR=-DHB_STRICT_ALIGNMENT
No I'll try.
> If it not help then
On Wed, 05 Mar 2008, Phil Barnett wrote:
> > OK but how many changes we want to introduce before next release
> > and final 1.0 version? I would like to unblock SVN repository as
> > soon as possible.
> Unlock it to what?
For new 1.2/2.0 or any other version were we can commit long waiting
new fea
On Wed, 05 Mar 2008, Lorenzo Fiorini wrote:
> The problem is file() and the dir that don't exist. file( "./notexist"
> ) returns .F.
Can you catch it in GDB to see C call stack?
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
On Wed, Mar 5, 2008 at 1:17 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> Can you catch it in GDB to see C call stack?
I've rebuilt with -O3 -g -DHB_STRICT_ALIGNMENT and I get:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0
On Tuesday 04 March 2008 06:59:56 am Przemyslaw Czerpak wrote:
> On Tue, 04 Mar 2008, Teo Fonrouge wrote:
> > Hello,
> > In a set of inherited classes, the DESTRUCTOR procedure is called more
> > than one time if a parent class, has a DESTRUCTOR.
> > I think that this is incorrect behavior. Accepta
(gdb) bt
#0 0x9442dcec in closedir$UNIX2003 ()
#1 0x0004d4a8 in hb_fsFindFirst (pszFileMask=0x312aa0
"/Users/fiorlo/.notexist/notexist", attrmask=0) at ../../hbffind.c:853
Hi,
looks like missing line in rtl/hbffind.c:hb_fsFindClose():
+if( info->dir )
{
closedir
Lorenzo,
welcome aboard Mac OS X :) You won't regret, I'm almost sure!
Maurilio.
Lorenzo Fiorini wrote:
> On Wed, Mar 5, 2008 at 1:17 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
>
>> Can you catch it in GDB to see C call stack?
>
> I've rebuilt with -O3 -g -DHB_STRICT_ALIGNMENT and I ge
On Wed, 05 Mar 2008, Lorenzo Fiorini wrote:
> > Can you catch it in GDB to see C call stack?
> I've rebuilt with -O3 -g -DHB_STRICT_ALIGNMENT and I get:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x
>
On Wed, Mar 5, 2008 at 5:18 PM, Maurilio Longo <[EMAIL PROTECTED]> wrote:
> welcome aboard Mac OS X :) You won't regret, I'm almost sure!
I'm not new in the Apple world. I've programmed on an Apple II in 1984
:))) and I still have an Apple IIe compatible with two external 51/4"
floppy drives but
On Wed, Mar 5, 2008 at 5:36 PM, Mindaugas Kavaliauskas
<[EMAIL PROTECTED]> wrote:
> looks like missing line in rtl/hbffind.c:hb_fsFindClose():
>
> +if( info->dir )
> {
> closedir( info->dir );
> }
Do you mean where there is /* Intentionally do nothing */
On Wed, Mar 5, 2008 at 5:36 PM, Mindaugas Kavaliauskas
<[EMAIL PROTECTED]> wrote:
> looks like missing line in rtl/hbffind.c:hb_fsFindClose():
>
> +if( info->dir )
> {
> closedir( info->dir );
> }
You're right, now it works.
Many thanks,
Lorenzo
___
ourXdbu has been added to
https://sourceforge.net/projects/ourxdbu/
Best regards,
Miguel Angel marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
2008-03-05 19:10 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbct/screen2.c
! fixed possible vary bad bug (memory buffer overflow) in SCREENSTR()
* harbour/source/rtl/hbffind.c
! fixed possible GPF in some *nixes
* harbour/source/vm/classes.c
! do not
It seems that K_ALT_keys are "aliens" in the OS X world even using
putty and a Linux server.
Has anybody already done sth about it?
( for example our debug uses Alt+D )
best regards,
Lorenzo
___
Harbour mailing list
Harbour@harbour-project.org
http://l
On Wed, 05 Mar 2008, Lorenzo Fiorini wrote:
> It seems that K_ALT_keys are "aliens" in the OS X world even using
> putty and a Linux server.
When you want to test terminal keyboard capabilities then please first
check escape sequences generated for given key combinations. It will
give you an answe
On Thu, Mar 6, 2008 at 12:31 AM, Przemyslaw Czerpak
> When you want to test terminal keyboard capabilities then please first
> [...]
> '"alien" in the OS X world' does not give me any information what's
> the problem. So what exactly happens in your case: 1, 2 or 3 above
> and if then please
18 matches
Mail list logo
