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.or
Hi Pritpal,
Ctrl+Ins (copy) and Shift+Ins (paste) keys don't work.
+1: There is still a lot of functionality which are
only available on the toolbar, but not from the menu.
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour
Hi,
On regular CLI input boxes where you can type stuff, we have found copying
and pasting in Windows to be very slow. When I looked more into it, using
something like MEMOEDIT() to test pasting a bunch of chars, I found the
UPPERCASE chars paste very slowly, and lowercase chars paste instantly.
>> Wich other harbour part need be rewritten from scratch?
>
> I can't think of any other.
I've found three:
- XML handling in xhb lib, but that rather needs a reimplementation
in core.
- .dll support in hbwin. (the x86 part)
- SORT command
( + ACHOICE() and MEMOEDIT() of course)
Brgds,
Vik
> Wich other harbour part need be rewritten from scratch?
I can't think of any other.
> rewriting will allow also a true and native GUI mode?
It has nothing to do with GUI mode. These are
Clipper functions, and if rewriting them, the only
one goal is to implement them as close as possible
to
Wich other harbour part need be rewritten from scratch?
rewriting will allow also a true and native GUI mode?
think how memoedit seem to windows user for select/copy/past operation
2010/2/6 Viktor Szakáts :
>> I am curious about this ACHOICE stuff. It sounds as though Przemek thought
>> it neede
In order to do a lot of the other Clipper implementations, did the Harbour
Project reverse engineer Clipper code, or was some source code donated from
the original Clipper company? In this instance, would you have to just take
an approximate guess as to how ACHOICE functions under any circumstance
> I am curious about this ACHOICE stuff. It sounds as though Przemek thought
> it needed to be rewritten from scratch. Is that a big project to do, or
> likely to be done? I'm starting to think I'd be a lot more useful to the
> Harbour Project if I was a good C programmer.
ACHOICE() (and als
I am curious about this ACHOICE stuff. It sounds as though Przemek thought
it needed to be rewritten from scratch. Is that a big project to do, or
likely to be done? I'm starting to think I'd be a lot more useful to the
Harbour Project if I was a good C programmer.
On Sat, Feb 6, 2010 at 7:30 A
Hi,
I didn't miss them, but what I reported look like new
errors after recent patches.
Just run ac_test.prg, press , then -> RTE.
It was okay in 2.0.0, but it's not okay in current trunk.
Brgds,
Viktor
On 2010 Feb 6, at 16:22, smu johnson wrote:
> Hi Viktor, see:
>
> http://lists.harbour-p
Hi Viktor, see:
http://lists.harbour-project.org/pipermail/harbour/2010-February/031590.html
http://lists.harbour-project.org/pipermail/harbour/2010-February/031661.html
In case you missed them.
On Sat, Feb 6, 2010 at 3:51 AM, Viktor Szakáts wrote:
> Hi All,
>
> In recent SVN, tests/ac_test.p
Hi All,
In recent SVN, tests/ac_test.prg shows some problems
with ACHOICE(). It doesn't initially show to
selecting and RTEs (Bound Error) after moving
around.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-proj
The same with
HPDF_Page_GetMiterLimit
Best regards,
Saulius
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
In harupdf.ch the following line (701)
hb_retnl( ( long ) HPDF_Page_TextWidth( ( HPDF_Page ) hb_parptr( 1
), hb_parc( 2 ) ) );
should be changed in
hb_retnd( ( double ) HPDF_Page_TextWidth( ( HPDF_Page ) hb_parptr(
1 ), hb_parc( 2 ) ) );
since function definition in Haru library is:
HPDF_
Hi,
>> List:tar -tf
>> Extract: tar -xf
>> Create: tar -cf [filenames...]
>> Help:tar --help
>> wc: harbour-2.0.0-darwin.bin.tar.gz: open: No such file or directory
>> cat: harbour-2.0.0-darwin.bin.tar.gz: No such file or directory
>> ---
>
> You have non GNU tar which accepts --v
On Wed, 06 Jan 2010, Szak�ts Viktor wrote:
Hi,
> I got this while trying to create a 2.0.0 tgz for darwin (Snow Leopard):
> ---
> [...]
> ./bin/postinst.sh
> tar: Option --owner=root is not supported
> Usage:
> List:tar -tf
> Extract: tar -xf
> Create: tar -cf [filenames...]
> Hel
I got this while trying to create a 2.0.0 tgz for darwin (Snow Leopard):
---
[...]
./bin/postinst.sh
tar: Option --owner=root is not supported
Usage:
List:tar -tf
Extract: tar -xf
Create: tar -cf [filenames...]
Help:tar --help
wc: harbour-2.0.0-darwin.bin.tar.gz: open: No such
Hi Przemek,
> It means that you had to take above code from xHarbour.
> I've just check that above fix were committed to xHarbour CVS by Paul at:
> 2006-07-01 18:35 UTC-0500 Paul Tucker
Mea Culpa!
I understand that don't know much about history :(
Thank you for correcting me.
Best regards,
Sa
Przemysław Czerpak pisze:
The real problem is the fact that you didn't start new thread
but simply used "replay" option in your mail program so your
both messages still belongs to the same initial thread. The context
of subject is unimportant for mail programs which can follow threads.
Just look
Yes, you are right. Strange that no one reported it for such long time.
Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
...
/* Special case */
if ( usRows < _GetScreenHeight() && usCols > _GetScreenWidth() )
{
HB_GT_FUNC(gt_SetM
On Wed, 23 Dec 2009, Saulius Zrelskis wrote:
Hi,
> > Yes, you are right. Strange that no one reported it for such long time.
> Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
> ...
> /* Special case */
> if ( usRows < _GetScreenHeight() && usCols > _G
> Yes, you are right. Strange that no one reported it for such long time.
Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
...
/* Special case */
if ( usRows < _GetScreenHeight() && usCols > _GetScreenWidth() )
{
HB_GT_FUNC(gt_SetMode( us
On Tue, 22 Dec 2009, Jacek Potempa wrote:
Hi,
> (sorry for my previous post under invalid subject - please ignore)
The subject is not the problem.
The real problem is the fact that you didn't start new thread
but simply used "replay" option in your mail program so your
both messages still belong
Massimo,
The bug is not related to Cytrix or Terminal server.
Just try to execute the following PRG code directly under Windows console:
SetMode(25,80)
? "Initial console size:", maxrow()+1,"X", maxcol()+1
? "Changing to :", maxrow()+1+1, "X", maxcol()+1-1
wait
SetMode(maxrow()+2,maxcol(
Can you post a little sample to show the problem so i can try on
Terminal server & Citrix?
2009/12/22 Jacek Potempa :
> Hi,
>
> (sorry for my previous post under invalid subject - please ignore)
>
> Recently one of our customers reported bug in Terminal software. After
> tracing it down it seems t
Hi,
(sorry for my previous post under invalid subject - please ignore)
Recently one of our customers reported bug in Terminal software. After
tracing it down it seems that the actuall problem lays in
xHarbour/Harbour implementation of the hb_gt_win_SetMode() / gtwin.c
SetConsoleWindow API f
On Mon, 07 Dec 2009, Pritpal Bedi wrote:
Hi
> > It may change in different HVM version so no one should create code
> > which depends on current behavior anyhow if you are interested what
> > happens now then return value is overwritten by last return value in
> > executed code (depending on cont
Hi
Przemysław Czerpak wrote:
>
> It may change in different HVM version so no one should create code
> which depends on current behavior anyhow if you are interested what
> happens now then return value is overwritten by last return value in
> executed code (depending on context it may cause so
On Mon, 07 Dec 2009, Pritpal Bedi wrote:
Hi,
> > I've just checked hbqt_slots.cpp and there are _many_
> > hb_vmRequestReenter() calls without hb_vmRequestRestore()
> > pairs.
> > I don't know the consequences, but it doesn't seem right.
> Matched.
> I also do not know its implications, Przemek
Hi
Viktor Szakáts wrote:
>
> I've just checked hbqt_slots.cpp and there are _many_
> hb_vmRequestReenter() calls without hb_vmRequestRestore()
> pairs.
>
> I don't know the consequences, but it doesn't seem right.
>
Matched.
I also do not know its implications, Przemek ?
Regards
Pritpal B
Hi Pritpal,
I've just checked hbqt_slots.cpp and there are _many_
hb_vmRequestReenter() calls without hb_vmRequestRestore()
pairs.
I don't know the consequences, but it doesn't seem right.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit
> Viktor Szakáts wrote:
>>
>> It's just a sort of hunch, since I don't have
>> test code and detailed theoretical proof for this,
>> but it looks like existing HBQT_QTPTR_FROM_GCPOINTER()
>> is a wrong concept and should not be used at all.
>>
>> It converts GC pointer to a simple one.
>>
>>
Hello Viktor
Viktor Szakáts wrote:
>
> It's just a sort of hunch, since I don't have
> test code and detailed theoretical proof for this,
> but it looks like existing HBQT_QTPTR_FROM_GCPOINTER()
> is a wrong concept and should not be used at all.
>
> It converts GC pointer to a simple one.
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> So, I'm afraid I'm confused. For sure I don't want to
> unblock it just for the sake of having it unlocked. But
> now I can't see why it cannot work as main CP, but can
> work as DB CP. I assume if it can be used in DB, sorting
> must be workin
>> Ok I see. Although this also means that I can't use
>> it as native CP in an application.
>> You seem to have suggested that any app may use UTF-8
>> even now. But maybe I misunderstood something. I understand
>> this needs UTF-8 sorting support (for ASORT(), <, > operators,
>> maybe else, p
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> Ok I see. Although this also means that I can't use
> it as native CP in an application.
> You seem to have suggested that any app may use UTF-8
> even now. But maybe I misunderstood something. I understand
> this needs UTF-8 sorting support (fo
Hi All,
It's just a sort of hunch, since I don't have
test code and detailed theoretical proof for this,
but it looks like existing HBQT_QTPTR_FROM_GCPOINTER()
is a wrong concept and should not be used at all.
It converts GC pointer to a simple one.
In code it's used for some comparisons, but
Hi,
>> 'SET( _SET_CODEPAGE, "UTF8" )' does't work, it leaves CP in previous setting.
>
> 2009-09-11 20:37 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> + added pseduto codepage "UTF8" which can be used in trnaslations only
>
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> 'SET( _SET_CODEPAGE, "UTF8" )' does't work, it leaves CP in previous setting.
2009-09-11 20:37 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
+ added pseduto codepage "UTF8" which can be used in trnaslations only
Hi All,
'SET( _SET_CODEPAGE, "UTF8" )' does't work, it leaves CP in previous setting.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Hi Przemek,
>> Please note I haven't tested this on C5.2e, so it may
>> be Clipper compatible behavior, but anyway I just noticed
>> it today in repository, and felt better to report it:
>> ---
>> #ifdef MACRO
>> ? 1
>> #else
>> ? 0
>> ---
>> Will not report any warning in Harbour. Probably it
On Sat, 28 Nov 2009, Szak�ts Viktor wrote:
Hi,
> Please note I haven't tested this on C5.2e, so it may
> be Clipper compatible behavior, but anyway I just noticed
> it today in repository, and felt better to report it:
> ---
> #ifdef MACRO
> ? 1
> #else
> ? 0
> ---
> Will not report any war
Viktor,
> Please note I haven't tested this on C5.2e, so it may
> be Clipper compatible behavior
Clipper 5.2e behave the same (no warning or error is given).
I think it will be a good practice to report it as an error
(Maybe guard current behavior with HB_CLP_STRICT).
Chen.
___
Hi All,
Please note I haven't tested this on C5.2e, so it may
be Clipper compatible behavior, but anyway I just noticed
it today in repository, and felt better to report it:
---
#ifdef MACRO
? 1
#else
? 0
---
Will not report any warning in Harbour. Probably it'd be
nicer if unclosed #if l
>> Upgrade to latest SVN and PSDK dir is added automatically
>> by the build process.
>
> I'm at the tip
> Harbour 2.0.0beta3 (Rev. 12877)
>
> I only set
> HB_COMPILER=bcc
> (since I have a couple others installed)
That's the reason. If you do this, the build system will
not be able to auto
I know that this list is perhaps not the correct one I hope you
will forgive me :-)
Francesco
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
>> I now added -L"...\psdk" and works
>
> Yes, this is the key.
>
> Upgrade to latest SVN and PSDK dir is added automatically
> by the build process.
I'm at the tip
Harbour 2.0.0beta3 (Rev. 12877)
I only set
HB_COMPILER=bcc
(since I have a couple others installed)
Francesco
_
On Sun, 15 Nov 2009, Przemysław Czerpak wrote:
[...]
And I forgot about the most important thing.
Welcome to the devel team :-)
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour
>> If it doesn't work for you pls post your env and error,
>
> Error:
> bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6
> -O2 -OS -Ov -Oi -Oc -onortl.obj -c ../../../nortl.
> c
> ../../../nortl.c:
> tlib.exe /P128 "..\..\..\..\..\lib\win\bcc\hbnortl.lib" -+nortl.obj
> TLIB 4
On Sun, 15 Nov 2009, francesco perillo wrote:
Hi,
> I'm only a bit puzzled about the fact that removing that libraries it
> compiles, links and works.
Amazing, do you know that I can compile and link my application
without xhb.lib and final binaries works.
Does it means that we should say th
Viktor, you are right as usual
On Sun, Nov 15, 2009 at 1:25 AM, Viktor Szakáts wrote:
>> I had to rem this line in config\win\global.mk to compile succesfully in bcc
>> 5.5
>> # SYSLIBS += kernel32 user32 ws2_32 advapi32 gdi32
>>
>> bcc has no kernel32.lib and the other ones
>
> This is
> I had to rem this line in config\win\global.mk to compile succesfully in bcc
> 5.5
> # SYSLIBS += kernel32 user32 ws2_32 advapi32 gdi32
>
> bcc has no kernel32.lib and the other ones
This is not true. All of them are present in PSDK dir,
which is part of BCC 5.5 kit.
If it doesn't work f
I had to rem this line in config\win\global.mk to compile succesfully in bcc 5.5
# SYSLIBS += kernel32 user32 ws2_32 advapi32 gdi32
bcc has no kernel32.lib and the other ones
I know that I should not use bcc (features and speed) but it's listed
as supported...
Francesco
_
Hi All,
I tried to compile the same .prg (having some warnings)
using HB_COMPILE() (via hbmk2) and harbour directly, and
the redirected std output contains different EOLs in the two
cases. HB_COMPILE() output confuses standard tools like
'sort' and 'grep'.
Here's the little program I used for te
On Wed, 28 Oct 2009, Przemysław Czerpak wrote:
> > > hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
> > > doesn't seem to respect app CP (like now f.e. GTWVT does)
> > > with GTXWC, accented chars don't appear correctly in title
> > > bar.
> > > I tried to fix it by convertin
On Wed, 28 Oct 2009, Tamas TEVESZ wrote:
Hi,
> > hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
> > doesn't seem to respect app CP (like now f.e. GTWVT does)
> > with GTXWC, accented chars don't appear correctly in title
> > bar.
> > I tried to fix it by converting to UTF8 in gtx
On Wed, 28 Oct 2009, Viktor Szakáts wrote:
> hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
>
> doesn't seem to respect app CP (like now f.e. GTWVT does)
> with GTXWC, accented chars don't appear correctly in title
> bar.
>
> I tried to fix it by converting to UTF8 in gtxwc.c,
Hi All,
hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
doesn't seem to respect app CP (like now f.e. GTWVT does)
with GTXWC, accented chars don't appear correctly in title
bar.
I tried to fix it by converting to UTF8 in gtxwc.c, but I
may be missing something as it's still not right
Hi,
VS> Hi All,
VS> Found this in our tracker, converted the example to self-contained one:
VS> ---
VS> PROCEDURE Main()
VS>dbCreate( "test", {{ "ITEM", "N", 10, 2 }} )
VS>USE test
VS>dbAppend() ; FIELD->ITEM := 5.00
VS>dbAppend() ; FIELD->ITEM := -5.12
VS>dbAppend() ; FIELD->I
Hi All,
Found this in our tracker, converted the example to self-contained one:
---
PROCEDURE Main()
dbCreate( "test", {{ "ITEM", "N", 10, 2 }} )
USE test
dbAppend() ; FIELD->ITEM := 5.00
dbAppend() ; FIELD->ITEM := -5.12
dbAppend() ; FIELD->ITEM := 6.00
dbAppend() ; FIELD->ITEM :
yes almost right gywvc problem
! MAKE: E:/harbour_cvs/config/mingw32-make 3.81 sh.exe
! HB_INSTALL_PREFIX: e:\harbour_vcce
! HB_BUILD_DLL: yes
! HB_HOST_ARCH: win HB_SHELL: nt (xp)
! HB_ARCHITECTURE: wce (autodetected)
! HB_COMPILER: msvcarm
cl.exe
-I. -I../../../../../../include -nologo -D_WI
ror 2
rm hbpp.obj
mingw32-make[2]: *** [descend] Error 2
mingw32-make[1]: *** [pp] Error 2
mingw32-make: *** [source] Error 2
Bregards,
Fernando
De: Fernando Athayde
Para: Harbour Project Main Developer List. >
Enviadas: Quinta-feira, 20 de Agosto de 2009 8:24:22
Assunto: Res: Res: [Harb
.
Enviadas: Quinta-feira, 20 de Agosto de 2009 8:24:22
Assunto: Res: Res: [Harbour] bug: msvcarm (MSVC 2008) build error
i redo my bat, now happens this error
my bat:
set INCLUDE=E:\Microsoft Visual Studio 9.0\VC\ce\include;%ProgramFiles%\Windows
Mobile 5.0 SDK R2\PocketPC\Include\Armv4i
set LIB
.
Enviadas: Quinta-feira, 20 de Agosto de 2009 8:07:18
Assunto: Re: Res: [Harbour] bug: msvcarm (MSVC 2008) build error
I guess you env is still wrongly set and non-ARM cl.exe is use.
Please *do* read INSTALL example and retry.
Brgdd,
Viktor
On 2009.08.20., at 1:01, Fernando Athayde wrote:
> cl.
Error 2
mingw32-make: *** [source] Error 2
for before message
process.h there is in E:\Microsoft Visual Studio 9.0\VC\include
se your SET include
Thanks
Fernando
De: Viktor Szakáts
Para: Harbour Project Main Developer List. >
Enviadas: Quinta-feira, 20 de Agosto de 2009 5:00:25
Assunto: [Harb
_
De: Viktor Szakáts
Para: Harbour Project Main Developer List.
Enviadas: Quinta-feira, 20 de Agosto de 2009 5:00:25
Assunto: [Harbour] bug: msvcarm (MSVC 2008) build error
../../../../../include\hbthread.h(70) : fatal error C1083: Cannot open
include file: 'process.h': No such fi
../../../../../include\hbthread.h(70) : fatal error C1083: Cannot open
include file: 'process.h': No such file or directory
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
On 2009.07.20., at 1:22, Przemyslaw Czerpak wrote:
On Mon, 20 Jul 2009, Szak�ts Viktor wrote:
in hbinet.c line 981, buffer is initialized to NULL,
Yes it is.
later in line 1003, buffer is used in recv() line as
'buffer + iReceived'.
Yes it is but iMaxLen is 0 so as long as recv() impleme
On Mon, 20 Jul 2009, Szak�ts Viktor wrote:
> in hbinet.c line 981, buffer is initialized to NULL,
Yes it is.
> later in line 1003, buffer is used in recv() line as
> 'buffer + iReceived'.
Yes it is but iMaxLen is 0 so as long as recv() implementation
is not broken then nothing wrong should happe
in hbinet.c line 981, buffer is initialized to NULL,
later in line 1003, buffer is used in recv() line as
'buffer + iReceived'.
Brgds,
Viktor
On 2009.07.20., at 0:50, Przemyslaw Czerpak wrote:
On Sun, 19 Jul 2009, Szak�ts Viktor wrote:
Hi,
There is a potential GPF bug (recently introduced) i
On Sun, 19 Jul 2009, Szak�ts Viktor wrote:
Hi,
> There is a potential GPF bug (recently introduced) in s_inetRecvInternal().
> If hb_itemGetWriteCL() returns FALSE, buffer will be NULLed, and later
> used as recv() buffer.
I'm sorry but I cannot find it.
And you explain when it can appear.
best
Hi Przemek,
There is a potential GPF bug (recently introduced) in s_inetRecvInternal().
If hb_itemGetWriteCL() returns FALSE, buffer will be NULLed, and later
used as recv() buffer.
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http
Hi Przemek and All,
SetMode() or screen resize in GTWVT / GTWXC don't
retain 'attr' flags of screen buffer, also Scroll()
won't retain it, which means drawing chars are garbled
after such events (like TBRowse() navigation). Basically
every method which uses low level SAVE/REST has this problem.
above functions seem to fail on Harbour extension
cursor code SC_UNDEF, which has value of -1.
I didn't try, just looked at the code.
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/
Hi Chen,
No it's simple IF statement, without brackets.
Brgds,
Viktor
On 2009.07.08., at 7:36, Chen Kedem wrote:
Viktor,
hbformat on contrib/hbtip/thtml.prg gives "Error 3" (in line 837 :
ENDDO)
Try to see if the IF() function is used, as I reported in the past,
hbformat think its the I
hbformat does not handle SWITCH/ENDSWITCH, and use the ENDSWITCH to close the
DO:
DO WHILE .T.
SWITCH x
CASE y
ENDSWITCH
ENDDO
Chen.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbo
Viktor,
> hbformat on contrib/hbtip/thtml.prg gives "Error 3" (in line 837 : ENDDO)
Try to see if the IF() function is used, as I reported in the past,
hbformat think its the IF statement. If so, just change it into IIF()
Chen.
___
Harbour mailing l
Hi Alexander,
hbformat on contrib/hbtip/thtml.prg gives "Error 3" (in line 837 :
ENDDO)
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
I can confirm Clipper returns .F. in first test while Harbour .T.,
with latest revision.
Brgds,
Viktor
On 2009.07.02., at 18:47, Randy Portnoff wrote:
Hi all,
The first output line (below) should return FALSE but returns TRUE
instead. The first line is equivalent to "? .F. .AND. .T. .AND. .
Hi all,
The first output line (below) should return FALSE but returns TRUE
instead. The first line is equivalent to "? .F. .AND. .T. .AND. .T."
which clearly should be FALSE.
This was tested in the stable build v1.0.1. with VS2005 I am unable
to test this in the current build - If this was a
But when I type the ls command in the term
the normal color is back
Bruno
2009/7/2 Bruno Luciani
> I try this example in Kubuntu , konsole terminal ,
> and work ok , but when executes , change the color font
> to gray.
>
> The term is white font over black originally.
>
> Bruno
>
> 2009/7/2 Vik
I try this example in Kubuntu , konsole terminal ,
and work ok , but when executes , change the color font
to gray.
The term is white font over black originally.
Bruno
2009/7/2 Viktor Szakáts
> Hi Przemek and All,
>
> I've seen fixes and I may even have reported this, but something is
> still
Hi Przemek and All,
I've seen fixes and I may even have reported this, but something is
still not 100% here. On Ubuntu 9.04 /tests/hello.prg changes
default black-on-white text to lightgray-on-darkgray when running
./hello in default Terminal app (Applications -> Accessories -> Terminal).
Same th
Hi All,
File source/rdd/usrrdd/rdds/fcomma.prg depends on contrib,
namely HB_F*() file handling functions in hbmisc lib.
In my experience these NFLIB-like HB_F*() funcions have
several bugs and aren't up to Harbour standards (like they
aren't MT compatible and don't handle different EOLs well).
On Darwin the crash is now gone. On Win I've only rebuilt
hbrtl yet and it instantly solved the problem.
Thanks a lot.
Brgds,
Viktor
On Mon, Jun 29, 2009 at 3:59 PM, Przemyslaw Czerpak wrote:
> On Mon, 29 Jun 2009, Przemyslaw Czerpak wrote:
>> Bingo - memory corruption which happens when OS CP c
On Mon, 29 Jun 2009, Przemyslaw Czerpak wrote:
> Bingo - memory corruption which happens when OS CP conversion is enabled.
> Thank you for the log. I'll fix it in a while.
Should be fixed by:
2009-06-29 15:58 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
best regards,
Przemek
__
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> There seem to be some problem around hb_fsNameConv().
> Here is valgrind on Darwin output:
> ==41669== Invalid write of size 1
> ==41669==at 0x297590: hb_strncat (in ./ep)
> ==41669==by 0x293A73: hb_fsFNameMerge (in ./ep)
> ==41669==by 0x36AA
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> Here's one with MinGW 4.4.0 on Windows:
> (this was built with 'set HB_BUILD_DEBUG=yes')
> ---
> Program received signal SIGSEGV, Segmentation fault.
> hb_rddFieldGet (pItem=0x1aa4954, pFieldSymbol=0xa094c0) at ../../wafunc.c:479
> 479 if( (
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> Not much closer I guess after switching to plain -g.
> [ BTW, I'm doing these traces on Darwin x86, so there was no
> -fomit-frame-pointer
> switch here. All what's changed now is missing TRACE calls. ]
> ---
> Program received signal EXC_BAD_ACCESS, Co
There seem to be some problem around hb_fsNameConv().
Here is valgrind on Darwin output:
---
==41669== Memcheck, a memory error detector.
==41669== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et
al.
==41669== Using LibVEX rev 1900M, a library for dynamic binary
translation.
==41
Here's one with MinGW 4.4.0 on Windows:
(this was built with 'set HB_BUILD_DEBUG=yes')
---
Program received signal SIGSEGV, Segmentation fault.
hb_rddFieldGet (pItem=0x1aa4954, pFieldSymbol=0xa094c0) at ../../wafunc.c:479
479 if( ( PHB_DYNS ) pField->sym == pDynSym )
(gdb) bt
#0 hb_r
Not much closer I guess after switching to plain -g.
[ BTW, I'm doing these traces on Darwin x86, so there was no -fomit-
frame-pointer
switch here. All what's changed now is missing TRACE calls. ]
---
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAI
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x
> hb_dynsymName (pDynSym=0xd5ddb4) at dynsym.c:463
> 463 HB_TRACE(HB_TR_DEBUG, ("hb_dynsymName(%p)", pDynSym));
GDB shows line
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> I'm getting this when trying to build Harbour with
> HB_BUILD_DEBUG=yes on darwin:
> In file included from ../../hvmall.c:69:
> ../../arrays.c: In function ‘hb_arraySetTDT’:
> ../../arrays.c:717: warning: format ‘%lf’ expects type ‘double’,
> but argume
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
hb_dynsymName (pDynSym=0xd5ddb4) at dynsym.c:463
463HB_TRACE(HB_TR_DEBUG, ("hb_dynsymName(%p)", pDynSym));
(gdb) bt
#0 hb_dynsymName (pDynSym=0xd5ddb4) at dynsym.c:463
#
I'm getting this when trying to build Harbour with
HB_BUILD_DEBUG=yes on darwin:
In file included from ../../hvmall.c:69:
../../arrays.c: In function ‘hb_arraySetTDT’:
../../arrays.c:717: warning: format ‘%lf’ expects type
‘double’, but argument 4 has type ‘LONG’
../../arrays.c:717: warning: t
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> Thank you. The small test is okay now,
> but my large app still GPFs in dbUseArea().
> (after rebuilding everything with recent
> Harbour)
Use GDB or VALGRIND to catch the GPF and show C call stack.
best regards,
Przemek
___
Thank you. The small test is okay now,
but my large app still GPFs in dbUseArea().
(after rebuilding everything with recent
Harbour)
Brgds,
Viktor
On 2009.06.29., at 12:04, Przemyslaw Czerpak wrote:
On Fri, 26 Jun 2009, Szak�ts Viktor wrote:
I'm still investigating, but with r11543 and MinGW
On Fri, 26 Jun 2009, Szak�ts Viktor wrote:
> I'm still investigating, but with r11543 and MinGW, I'm getting GPF
> in DBUSEAREA() and also in ORDCREATE() in this small example:
> ---
> FUNC MAIN()
> USE TEST
> INDEX ON FIRST TO test
> ---
Should be fixed after:
2009-06-29 12:02 UTC+0200 Przemys
>-Original Message-
>From: Viktor Szakáts [mailto:harbour...@syenar.hu]
>Sent: Friday, June 26, 2009 9:01 PM
>To: Harbour Project Main Developer List.
>Subject: [Harbour] bug: RDD GPF with MinGW + r11543
>
>I'm still investigating, but with r11543 and M
1 - 100 of 219 matches
Mail list logo
