On Tue, 16 Jun 2009, Pritpal Bedi wrote:
Hi,
> Here is what I am having in my applactions:
[...]
> // QUESTION: pz1 is initialized in main thread and re-public(d) in another
> thread
> // because macro is compiled in main thread, pz1 referenced is from
> main thread
This is not true.
On Tue, 16 Jun 2009, Pritpal Bedi wrote:
Hi,
> > I just wanted to suggest you something like that.
> > I'll add HB_WALIST()/HB_WAEVAL() functions which should help in
> > writing function to iterate workareas.
> If you are into that:
> Xbase++ functions to this effect:
> Syntax
> WorkSpaceList(
On Wed, 17 Jun 2009, Alexander S.Kresin wrote:
Hi,
> are there objections to make functions from rtl/errorapi.c ( hb_errNew(),
> hb_errPutGenCode(), ... ) HB_EXPORT ?
> This could allow to build as dll third party RDD's, etc.
They should be exported. I'll commit such modification in a while.
On Wed, 17 Jun 2009, Szak�ts Viktor wrote:
> Thanks, typo of mine, will commit the fix ASAP.
Ups, I also found it and already committed fix :-)
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/m
On Wed, 17 Jun 2009, Szak�ts Viktor wrote:
> No problem, but I noticed your clock is in the future by
> about 10 minutes :)
I forgot to sync it after some local test few _week_ ago.
Thanks for the remainder. I'll sync it in a while.
best regards,
Przemek
__
On Wed, 17 Jun 2009, Angel Pais wrote:
Hi,
> >proc main()
> > dbCreate( "_tst", { { "F","C",10,0 } } )
> > use _tst alias "tst1" new shared
> > dbRelease()
> > use _tst alias "tst1" new shared
> > dbRelease()
> > aeval( WorkSpaceList( 2 ), {|s, i| qout( i,
On Wed, 17 Jun 2009, Angel Pais wrote:
> This program:
> proc main()
> > dbCreate( "_tst", { { "F","C",10,0 } } )
> > use _tst alias "" new shared
> > ? select(), used(), "["+alias()+"]"
> > use _tst alias "" new shared
> > ? select(), used(), "["+alias()+"]"
> >
On Wed, 17 Jun 2009, Angel Pais wrote:
> This program:
> proc main()
> > dbCreate( "_tst", { { "F","C",10,0 } } )
> > use _tst alias "" new shared
> > ? select(), used(), "["+alias()+"]"
> > use _tst alias "" new shared
> > ? select(), used(), "["+alias()+"]"
> >
On Wed, 17 Jun 2009, Pritpal Bedi wrote:
Hi
> Przemyslaw Czerpak-2 wrote:
> >proc main()
> > dbCreate( "_tst", { { "F","C",10,0 } } )
> > use _tst alias "tst1" new shared
> > dbRelease()
> >
On Wed, 17 Jun 2009, Angel Pais wrote:
> Program:
> proc main()
> set alternate to test.txt
> set alternate on
> dbCreate( "_tst", { { "F","C",10,0 } } )
> use _tst alias "tst1" new shared
> dbRelease()
> use _tst alias "tst1" new shared
> WorkSpaceEval( {|| doTest() }
On Wed, 17 Jun 2009, Angel Pais wrote:
>>proc main()
>> dbCreate( "_tst", { { "F","C",10,0 } } )
>> use _tst alias "tst1" new shared
>> dbRelease()
>> WorkSpaceEval( {|| dbRelease() }, 2 )
>> wait
>>return
> It aborts with this error:
>
On Wed, 17 Jun 2009, Angel Pais wrote:
> New results:
> Current workarea: 1 alias: TST1 (verify:0) used: Y
> All active workareas in thread workspace:
>workarea: 1 alias: TST1
> ZeroSpaceList: [TST1]
> WorkSpaceList:
>
> Current workarea: 2 alias: TST1 (verify:1) used: Y
> All active workarea
On Wed, 17 Jun 2009, vszak...@users.sourceforge.net wrote:
> ; TODO: Decide about the status of STOD() function, which is
> currently an XPP compatibility function, not in Harbour
> namespace, yet it's widely used with same functionality.
IMO covering it by HB_COMPAT_XP
On Thu, 18 Jun 2009, vszak...@users.sourceforge.net wrote:
> * contrib/hbct/Makefile
> + contrib/hbct/dattime4.c
> * contrib/hbct/datetime.c
> * Moved STOD() into separate file to avoid linking problems
> when HB_COMPAT_XPP is defined.
> ! Removed HB_COMPAT_XPP protection. No lo
On Thu, 18 Jun 2009, Szak�ts Viktor wrote:
Hi,
> Is there any objections in adding new socket API
> developed by Mindaugas to core RTL lib?
> To me it seems a better / cleaner implementation,
> with a more natural Harbour level API. It's also
> friendlier with MT.
Just like hb_inet it's not MT s
On Thu, 18 Jun 2009, J. Lefebvre wrote:
Hi,
> 2009-06-18 21:18 UTC+0200 Jean lefebvre (jfl at mafact dot com)
> * vm/runner.c
> + Added options to HB_HRBLOAD() :
> HB_HRB_DEFAULT 0 // do not overwrite any functions, ignore
> // public HRB fun
On Fri, 19 Jun 2009, J. Lefebvre wrote:
Hi,
> Sorry, a small typo in my last upload.
> Will be corrected in a few minuts !
If possible please wait a while.
I'll commit this and some other fixes.
best regards,
Przemek
___
Harbour mailing list
Harbour@h
On Fri, 19 Jun 2009, Szak�ts Viktor wrote:
Hi,
> Thanks Guy.
> Maybe it's simpler to just add HB_CCPREFIX support
> to that AR macro in gcc.cf:
> AR = ${HB_CCPREFIX}ar
> And set HB_CCPREFIX accordingly:
> export HB_CCPREFIX=mipsel-linux-gnu-
> This envvar should also make hbmk2 work. Can you try?
On Fri, 19 Jun 2009, vszak...@users.sourceforge.net wrote:
> 2009-06-19 14:50 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * config/darwin/gcc.cf
> + Added HB_CCPREFIX support.
> + Added HB_CCPOSTFIX support.
> * config/linux/gcc.cf
> + Added HB_CCPREFIX support.
Thank you.
be
On Fri, 19 Jun 2009, Guy Roussin wrote:
Hi,
> All is fine *except one point* :
> When i run apps dynamic link on mips(el) i get a
> segmentation fault :
>
> g...@cobalt:~$ hbmk2 t
> hbmk: Processing configuration: /usr/local/bin/hbmk.cfg
> Harbour 2.0.0beta1 (Rev. 11424)
> Copyright (c) 1999-
On Fri, 19 Jun 2009, Guy Roussin wrote:
> $ ldd ./t
>libharbour.so => /usr/local/lib/harbour/libharbour.so (0x2aadc000)
>libc.so.6 => /lib/libc.so.6 (0x2af44000)
>libm.so.6 => /lib/libm.so.6 (0x2b0bc000)
>libdl.so.2 => /lib/libdl.so.2 (0x2b154000)
>librt.so.1
On Sat, 20 Jun 2009, vszak...@users.sourceforge.net wrote:
> 2009-06-20 04:22 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * source/rtl/mlcfunc.c
> % Minor optimization to EOL parameter handling.
> Please review.
It broke the code by reverting April fix.
best regards,
Przemek
On Sat, 20 Jun 2009, Szak�ts Viktor wrote:
> I wonder how though.
> hb_parclen() is only > 0 (and also is hb_parc() != NULL only)
> if HB_ISCHAR() is true, so what is the difference?
Not true. They can return non empty value for arrays.
hb_par*() functions accept variable number of parameters whic
On Sat, 20 Jun 2009, Szak�ts Viktor wrote:
> I wanted to suggest that, as current code makes LOTS OF
> otherwise valid code prone to such errors and unexpected
> behaviour.
> Please do.
Fine, I'll commit it in a while.
> As a next step we will have to convert all our codebase to
> use the new API
On Sat, 20 Jun 2009, Pritpal Bedi wrote:
Hi,
I do not know what exactly you are asking for but maybe some
information can help you to find the answer.
> Please look at this code
> CREATE CLASS XbpComboBox INHERIT XbpSLE, XbpListBox
> ENDCLASS
> METHOD XbpComboBox:new( ... )
>::XbpSLE:init( .
On Sun, 21 Jun 2009, Pritpal Bedi wrote:
Hi
> XbpSLE is cast message. It returns special pseudo object
> ^^^
> How I can retrieve this pseudo object?
> I need value of a property in the XbpComboBox():new() itself
> of the instance respresenting XbpSLE().
Such ins
On Sun, 21 Jun 2009, Szak�ts Viktor wrote:
Hi,
> Can this expression be optimized by compiler to NOP:
>Do( NIL )
> I'm trying to make this work in every situation:
> #if defined( __HB_OUTDEBUG__ ) .AND. defined( __PLATFORM__WINDOWS )
>#xtranslate HB_OUTDEBUG( [] ) => WAPI_OUTPUTDEBUGSTRIN
On Sun, 21 Jun 2009, Szak�ts Viktor wrote:
Hi,
> I was proposing extra Harbour compiler warnings for this purpose
> a while ago. For the compiler it's a much easier job to detect these
> cases and show a warning, since the full PP + parser logic is there.
#command IF( , [], [] ) => ;
#s
On Mon, 22 Jun 2009, Xavi wrote:
> Thanks Viktor,
> Override new/delete operator not work when active HB_FM_STATISTICS because
> fm.c is not compiled in mode c++.
> My idea about fm.cpp was to be incorporated the file in the compilation of
> the application user pending further comments, views.
>
On Mon, 22 Jun 2009, Rossine wrote:
> Hello,
> I was using the release 11401 and updated to 11478 and all examples of
> fivewin "c:\fwh\samples" stopped
> work. Now all generate errors of GPF. Seek some errors:
> What can be wrong ?
FWH is not binary compatible with current Harbour builds.
best
Hi,
I've downloaded from internet some xbase++ documentation and I'm
wondering how some things really works. Maybe I'm wrong but IMHO
few things cannot work as described. Also some results from previous
tests had some strange for me anomalies.
I would like to ask xbase++ users to make some tests w
On Mon, 22 Jun 2009, Szak�ts Viktor wrote:
Hi,
> This code:
> --- test.prg
> PROC MAIN()
>? hb_compile( NIL, { "test.prg", "-gc2", "-l", "-l-" } )
>RETURN
> ---
> will create test.c *with* line numbers, while equivalent Harbour
> command line below will properly disable it by second -l- o
On Mon, 22 Jun 2009, Szak�ts Viktor wrote:
Hi,
Thank you for your results.
> t1:I had to kill it.
> This line was repeated about 1900 times:
> wating... 23:00:05
So it behaves like a task switching not OS threads. Without function
call it does not switch execution context so only second thread
On Mon, 22 Jun 2009, Szak�ts Viktor wrote:
> >> t2:
> >> Here it consistently exits after a few seconds.
> >> Displaying the two kind of strings in random order,
> >> sometimes the same two times.
> > It should not exit without user interaction (ESC key).
> > I guess that it's results of some inter
On Tue, 23 Jun 2009, Szak�ts Viktor wrote:
> I did a full rebuild with r11486, but I'm getting this with hbmk2
> (even the simplest session):
> ---
> Error F0036 Invalid filename ''
> ---
> In hbmk2, it's invoked by:
> ---
> HB_COMPILE( "", { } )
> ---
> Maybe the first empty parameter is now unn
On Mon, 22 Jun 2009, Angel Pais wrote:
> First test resut:
> wating... 20:02:31 > first line
> after many thouthand lines ...
> wating... 20:02:31 > last line
> Compiler: Xbase++ 1.90.355 The last one dated may 2009
> Celeron processor Acer notebook Win XP
So it's only task switching not
On Mon, 22 Jun 2009, Angel Pais wrote:
> Second test
> Running about 3 minutes no error.
> Same system same cpu same compiler
> No error.
So sth has been improved in 1.9 or it's hardware dependent.
Anyhow with simple task switching it should work without any
errors in all cases. BTW how many threa
On Mon, 22 Jun 2009, vszak...@users.sourceforge.net wrote:
> 2009-06-23 00:36 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * utils/hbmk2/hbmk2.prg
> ! Deleted first empty string parameter passed to HB_COMPILE()
> function. AFAIR it seems it was needed so far (or was ignored,
>
On Tue, 23 Jun 2009, Szak�ts Viktor wrote:
>> Ups. Sorry for troubles but now if I remove
>> argv[ argc++ ] = ( char * ) "";
>> from hbcmplib.c then hbmk2 stops to work again.
>> If I do not remove it then we should update hbrun to not pass
>> HB_ARGV( 0 ) to hb_compile*() functions.
>> What do y
On Tue, 23 Jun 2009, Szak�ts Viktor wrote:
> There is still some problem. In hbmk2 getFirstFunc() function
> will still extract the original name (when extracting from .c source).
This is correct. The problem is that you use this name without encoding
in C source code as REQUEST.
> I don't know w
On Tue, 23 Jun 2009, Szak�ts Viktor wrote:
Hi,
> Very nice job April.
> I was wondering what would it take to generate a *full*
> equivalent to include/hbextern.ch.
> Few issues which need to be solved to achieve that:
> - Add HB_CODEPAGE_* symbols (from source/codepage/*.c)
> - Add HB_LANG_* sym
On Tue, 23 Jun 2009, Szak�ts Viktor wrote:
> The mingw approach cannot be easily implemented to support
> all compilers, plus it needs to be done after creating
> all libs, creating hbextern but before creating the rest
> of tools (noteably hbrun). So it's tricky.
And it's the reason why it always
On Tue, 23 Jun 2009, Maurilio Longo wrote:
Hi,
> > 1-st I would like to check how looks simultaneous execution in xbase++.
> A single line in _out_.txt, with 'waiting 14.47.32' inside. I had to kill it;
> it was on a Core2Duo E6750 with windows xp sp3 and using xbase++ 1.90.331;
It looks like xb
On Tue, 23 Jun 2009, Pritpal Bedi wrote:
Hi
> Windows XP 5.1 Service Pack 2
> c:\harbour\tests>xpp cpu1.prg /n && alink cpu1
> Xbase++ (R) Compiler 1.90.326 Dec 9 2005
> Copyright (c) Alaska Software. All rights reserved.
> File: cpu1.prg Line: 24
> File cpu1.prg successfully compiled.
> Alask
On Tue, 23 Jun 2009, Maurilio Longo wrote:
> > Interesting. I guess that they are defined as some type of helper
> > function. If possible please also check how many threads are created
> > by program which does not create any new thread and then how many threads
> > are allocated when new thread i
On Tue, 23 Jun 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-06-23 18:15 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * include/hbapi.h
> * include/hbapiitm.h
> * source/vm/itemapi.c
> * source/vm/arrays.c
> * source/vm/extend.c
> ! Fixed hb_parvc() function to return N
On Tue, 23 Jun 2009, Xavi wrote:
> It also makes me do strange casting as (void **) (void*) but don't
> report any warning: I don't know if it is intentional.
It is intentional. Read about strict aliasing optimizations.
best regards,
Przemek
___
Harbour
On Wed, 24 Jun 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-06-24 16:07 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * source/vm/memvars.c
> + Added hb_fsCommit() to __MVSAVE().
> (Change copied from xhb, created by Peter Rees)
Are you sure that it's Clipper compatible?
On Wed, 24 Jun 2009, Xavi wrote:
> Uff, with g++ (TDM-1 mingw32) 4.4.0
> Set HB_USER_CFLAGS=-fno-strict-aliasing
> :)
It may strongly reduce performance in some cases.
It disables important source code optimizations.
Please also note that it does not effect ANSI C code.
Any code which needs -fno-s
On Wed, 24 Jun 2009, Szak�ts Viktor wrote:
> I was holding these back, because it seems better to fix hb_par*() (and
> other involved API) call parameter list to actually use the 'const'
> modifier.
Exactly. We should change returned value from 'char *' to 'const char *'.
I hope it will force code
On Wed, 24 Jun 2009, Szak�ts Viktor wrote:
> No. I've checked and it isn't.
> Can it cause any problems?
On some systems hb_fsCommit() executed even for single file may force
all disk buffer flushing. In some cases it can be performance killer
if application often stores some memvars in files. Lon
On Wed, 24 Jun 2009, Xavi wrote:
Hi,
>> with meory protection we will have GPF so the warnings are perfectly valid.
> Thank you very much Przemek, but this means that many of these codes must be
> rewritten. ;)
Not so much. I cleaned core code long time ago and eliminated all places
where such l
On Wed, 24 Jun 2009, Szak�ts Viktor wrote:
> Przemek, are you working on this now?
I haven't started yet.
> For a start, I'd like to change to these:
> extern HB_EXPORT const char * hb_parc( int iParam );
> extern HB_EXPORT const char * hb_parcx( int iParam );
> extern HB_EXPORT const char * hb_i
On Thu, 25 Jun 2009, Mindaugas Kavaliauskas wrote:
Hi,
> I'm trying to find a way to compile WinCE executable on WinXP. It is not
> very clear for me, what compilers/tools should be installed to do this? I
> prefer MinGW CE, but googling does not give an answer, that mingw CE is.
> Are "mingwc
On Wed, 24 Jun 2009, Davor Siklic wrote:
> Hi all
> Today I see this error (ubuntu 9.04)
> svn update
> At revision 11520.
>
> make[4]: Entering directory `/opt/clipp/harbour/source/rtl/linux/gcc'
> gcc -I. -I../../../../include -Wall -W -O3-c ../../strpeek.c
> -ostrpeek.o
> .
On Thu, 25 Jun 2009, Szak�ts Viktor wrote:
> Przemek, I've just realized I have fixed warnings in these files already:
> contrib/hbmysql/mysql.c
> contrib/hbodbc/odbc.c
> contrib/hbtpathy/tpcommon.c
> contrib/hbsqlit3/hbsqlit3.c
> contrib/hbpgsql/postgres.c
> contrib/hbmisc/
On Thu, 25 Jun 2009, Mindaugas Kavaliauskas wrote:
> Hi,
>> MinGW CE is MinGW for Windows CE and is designed to port windows
>> application to WinCE. CEGCC is GNUC compiler for Windows CE and
>> is designed to port POSIX applications to WinCE.
>> Both comes from the same projects. I ported Harbour
On Thu, 25 Jun 2009, Szak�ts Viktor wrote:
> Thanks, I'll fix this typo in my next commit.
> Until then change line #156 in contrib/hbwin/legacy.prg to:
> IF ! Empty( hOle )
> Or even better to use the new API which is more efficient:
> hb_oleCreateObject("WScript.Shell")
Please wait w
On Fri, 26 Jun 2009, Szak�ts Viktor wrote:
Hi,
> Shouldn't the last (input buffer) parameter of hb_gtRest()
> be also protected with 'const'?
Yes it should. Thank you for the note. I missed it.
Probably we will find also few other functions which should be
converted.
If we remove casting to void
172.EXE
> 2009-06-25
> 2009-06-25
> C:\cawi32\sample\test>hbrun test172.prg
> 2009-06-25
> - -
Should be fixed after:
2009-06-26 11:13 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
HB_CTOT() also. I tested it with:
PROC main()
LOCAL tNow,
On Fri, 26 Jun 2009, Szak�ts Viktor wrote:
> One more:
> Is there any reason to keep GT box frame strings
> as 'BYTE *' instead of 'char *' ?
I want to convert all of them to 'char*' but I would like to also
change USHORT in cords to int.
We need negative value in some of them and now we have to m
On Fri, 26 Jun 2009, Szak�ts Viktor wrote:
> FYI, there are some explicit ( BYTE * ) casts to hb_parc*()
> calls in hsx.c, sxcompr.c, sxcrypt.c and usrrdd.c.
I'll clean them. Thank you.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-proj
Hi All,
I'll be offline for the weekend.
I'll answer for all pending questions to me when I'll be back.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
On Fri, 26 Jun 2009, Szak�ts Viktor wrote:
Hi,
> Found some candidates for 'const' addition in hbhash.h.
Fine, please update it.
BTW changing [const] BYTE* in hb_fsRead*()/hb_fsWrite*() to
[const] void* (just like in ANSIC read()/write()) should help
in eliminating casting from other code.
Prob
r:
2009-06-29 12:02 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Thank you for information.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
On Sat, 27 Jun 2009, vszak...@users.sourceforge.net wrote:
> 2009-06-27 09:47 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * include/hbapifs.h
> * source/rtl/filebuf.c
> * source/rtl/filesys.c
> * Changed file I/O buffer parameters from
> '( [const] BYTE * )' to '( [const] void
On Fri, 26 Jun 2009, vszak...@users.sourceforge.net wrote:
> Revision: 11547
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11547&view=rev
> Author: vszakats
> Date: 2009-06-26 16:42:25 + (Fri, 26 Jun 2009)
> Log Message:
> ---
> 2009-06-25 18:41 UT
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> No idea, sorry, -debug add -g C switch on linux/gcc, strange
> that this can create such effect, so it may also be that it's
> something else.
> As a next step you'd need gdb to get a C trace call, I hope
> someone can help with more info here.
Rebuild
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
___
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
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:
> 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
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:
> 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, 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 regar
On Tue, 30 Jun 2009, Szak�ts Viktor wrote:
> Besides the packaging (.deb/.rpm/.tgz), I also wonder why
> we need to create one for every distro.
> And could we possibly do anything to make Harbour
> "distro-independent".
We cannot due to different binary dependencies in different Linux
distributio
On Tue, 30 Jun 2009, Szak�ts Viktor wrote:
> I like these modifications :)
Anyhow it will force some 3-rd party code modifications.
I've just downloaded LETO and updated it for current Harbour SVN
code.
I'm attaching patch. Alexander please look at it.
I do not know LETO code so I haven't analyze
On Tue, 30 Jun 2009, Alexander S.Kresin wrote:
>> I'm attaching patch. Alexander please look at it.
> Thanks, Przemek, I'll review them.
> I'll need to add some code to provide compatibility with older Harbour
> versions and xHarbour.
Hi Alexander,
This time it may be really hard.
Maybe it wil
hanges. I remember that we had similar
> problem
> with constants in the past, were BCC try to optimize constant string access
> by reading
> a 32bit value. This had a problem for less than 4 bytes strings.
> See my NOTE on source/rtl/console.c
Please test after:
2009-06-30 13:3
On Tue, 30 Jun 2009, Alexander S.Kresin wrote:
Hi,
>> I'm attaching patch. Alexander please look at it.
> Thanks, Przemek, I'll review them.
> I'll need to add some code to provide compatibility with older Harbour
> versions and xHarbour.
I updated the patch so now LETO can be compiled also b
On Tue, 30 Jun 2009, Xavi wrote:
> Some questions reviewing hbapi.h
> Should be hb_pards and hb_parvds const?
buffer returned by hb_par[v]ds() is writable so we can leave it
as is. Anyhow if you think that it will be cleaner to define
this buffer as readonly then we can change it.
> Do you
On Wed, 01 Jul 2009, Horodyski Marek (PZUZ) wrote:
> App hangs when NTXes try created file withs size bigger than 4 Gb.
rddInfo( RDDI_LOCKSCHEME, DB_DBFLOCK_XHB64, "DBFNTX" )
enables 64-bit locking and large file support in DBFNTX.
In some spare time I'll add error when maximal file size is e
On Wed, 01 Jul 2009, Alexander S.Kresin wrote:
Hi,
>> I updated the patch so now LETO can be compiled also by Harbour
>> and probably also by old Harbour though I haven't restored wrong
>> casting for [const] char|BYTE * strings so C++ some compilers
>> may refuse to compile LETO with xHarbour or
On Thu, 02 Jul 2009, Alexander S.Kresin wrote:
Hi,
> Maybe, this issue was discussed already, but ...
> This code gives an error with Harbour, but works with Clipper:
> PROCEDURE main
> PRIVATE arr[10], r
>arr[1] := "OO"
>r = 'arr[1]'
>&r += '*'// Runtime "Syntax error: &" with Ha
On Thu, 02 Jul 2009, Xavi wrote:
> Do you permit a question to my learn? :)
> In Harbour is possible define rule ExprAssign with LeftExpression
> as ExprEqual, ExprPlusEq, etc ... beacuse it does the same for
> all. Not have to do things different if is Variable or MacroVar.
Just simply when I int
On Fri, 03 Jul 2009, marek.horody...@interia.pl wrote:
> How we can use fields type :
> {{ 'DATA', 'D', 3, 0}, ...
Just like above.
> to build orders ?
There is no difference between D3 D4 and D8 when index is created.
> When I use DATA or DtoS( DATA), dbSeek() do not can find records.
> Rdd is
On Mon, 06 Jul 2009, Phil Krylov wrote:
Hi,
> Did you ever experiment with pthread-compatible and non-compatible
> threading libs in DJGPP contribs? There are some, although I haven't
> tried any.
No I haven't. I haven't even know that they exist.
I'll look at it in some spare time.
best regard
On Sat, 04 Jul 2009, vszak...@users.sourceforge.net wrote:
> Revision: 11636
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11636&view=rev
> Author: vszakats
> Date: 2009-07-04 07:17:00 + (Sat, 04 Jul 2009)
> Log Message:
> ---
> 2009-07-04 09:13 UT
On Tue, 07 Jul 2009, Szak�ts Viktor wrote:
Hi,
> To me current large DO CASE statement seems equivalent to
> this single function call:
> ::pPtr := hb_ExecFromArray( @qt_*(), hb_AParam() )
> It will pass through the number of parameters received.
Both method are two complicated. ... can be used
On Tue, 07 Jul 2009, Randy Portnoff wrote:
Hi,
> Can you please tell me if the ADS bug (below) is only an issue with
> compressed fields or does it affect non-compressed fields as well?
It was very old problem exploited by recent modification.
>From the beginning our ADSRDD was ignoring error c
On Tue, 07 Jul 2009, Hannes Ziegler wrote:
Hi,
> I have followed this thread with great interest and would like to add my
> 2cents as the external help author who has written the xHarbour docs:
> 1) Programmers are no help authors
> 2) Software cannot be spread without good documentation
> 3) xH
On Tue, 07 Jul 2009, Szak�ts Viktor wrote:
Hi,
> Is there any way to use some core functions to replace
> HB_EXEC() custom C function implemented in hbtip lib?
> (it's in utils.c)
I added this function as xHarbour compatible HB_EXEC() function.
In HB_TIP() library it's used without additional pa
On Tue, 07 Jul 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-07-08 00:42 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> + HB_EXEC() moved to legacy status and reimplemented in .prg.
> (Thanks Przemek and Petr)
I think that you should move HB_EXEC .c code to XHB library.
Prob
On Wed, 08 Jul 2009, vszak...@users.sourceforge.net wrote:
> 2009-07-08 11:07 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
[...]
thank you,
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mai
way..."
> > hbmk2 q.o
> where q.o is a simple two liner .prg compiled into an obj using MinGW.
> The crash happens after calling hb_processRun() in getFirstFunc(),
> in the AT() call.
Should be fixed by:
2009-07-08 15:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Thu, 02 Jul 2009, Przemyslaw Czerpak wrote:
Hi,
> > Maybe, this issue was discussed already, but ...
> > This code gives an error with Harbour, but works with Clipper:
> > PROCEDURE main
> > PRIVATE arr[10], r
> >arr[1] := "OO"
> >r = &
On Thu, 09 Jul 2009, Xavi wrote:
> Hi All,
> A spanish expression says: "ser más papistas que el Papa" in English "be more
> Catholic than the Pope".
> I'm surprised that we are pass some lines and nobody says anything.
> Maybe not understand the changes or are the holidays but...
> Are we correct
On Thu, 09 Jul 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-07-10 01:01 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * include/hbapigt.h
> * contrib/hbct/screen2.c
> * contrib/hbct/cursor.c
> * contrib/hbct/screen1.c
> * contrib/hbct/setrc.c
> * contrib/hbclipsm/status.c
On Fri, 10 Jul 2009, Szak�ts Viktor wrote:
> Sorry, for me it's still a pending question why at some places a char
> is represented by BYTE, on some others by UCHAR, and on some others
> USHORT.
> There surely is a logic in it, but I can't recognize it.
> Pls wait a little, I'm converting GT USHORT
On Fri, 10 Jul 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-07-10 11:40 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * include/hbgtcore.h
> * include/hbapigt.h
> * source/rtl/gtdos/gtdos.c
> * source/rtl/gtwin/gtwin.c
> * source/rtl/gtxwc/gtxwc.c
> * source/rtl/gtcrs/gtc
701 - 800 of 2668 matches
Mail list logo
