On Wed, 29 Jul 2009, Przemyslaw Czerpak wrote:
> I'm not very familiar with TIP code but some user messages I've seen
> suggested that some things do not work correctly, i.e. as workaround
> for some problems with FTP TIP client Miguel introduced new functions
> hb_inet[SG]et
On Thu, 30 Jul 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-07-30 06:59 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * source/common/hbdate.c
> ! Refixed for HB_HAS_LOCALTIME_R.
gmtime() just like localtime() is not thread safe in most of systems
so use gmtime_r() when HB_HAS
UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> [E:\harbour907c\harbour]make -r1>make_ow.log
> make[3]: *** [hbrtl.lib] Segmentation fault
> make[2]: *** [descend] Error 2
> make[1]: *** [rtl] Error 2
> make: *** [source] Error 2
Can you locate what exactly
On Thu, 30 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> But using your change:
>for %i in ( *$(OBJ_EXT) ) do @echo -+%i >> __lib__.tmp
> build fine
> I think problem is some kind of limit in make.exe, and/or Watcom
It's not related to Watcom because also gcc.cf needs such trick so I gue
ick test with Harbour code after:
2009-07-29 05:19 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
or better simply take today CVS.
The previous version could give unpredictable results in some cases
due to "accepted" sockets working in unblocking mode on platforms which
inherits BLOC
On Thu, 30 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> >Try to replace:
> > LD_RULE = $(link_exe_file) $(HB_USER_LDFLAGS)
> >with:
> > empty:=
> > space:= $(empty) $(empty)
> > comma:= ,
> > LDFILES = $(subst $(space),$(comma) ,$(^F))
> > LDLIBS = $(subst $(space),$(comma) ,$(s
On Thu, 30 Jul 2009, Francesco Saverio Giudice wrote:
Hi,
> Il 30/07/2009 14.32, Przemyslaw Czerpak ha scritto:
>> Francesco please make quick test with Harbour code after:
>>2009-07-29 05:19 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
>> or better simply ta
On Thu, 30 Jul 2009, Szak�ts Viktor wrote:
>> The above behavior describes problem with nonblocking socket so it's
>> expected for Harbour versions before:
>> 2009-07-29 05:19 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
>> With today CVS it should work wit
On Thu, 30 Jul 2009, Szak�ts Viktor wrote:
> I'd like to add Jose Luis Capel to our developer team.
> Jose is the author of SMS/SIM interface code just recently
> committed by me, and this way he will be able to add further
> updates directly to SVN.
Welcome Jose!
best regards,
Przemek
__
On Thu, 30 Jul 2009, Francesco Saverio Giudice wrote:
Hi,
> it's very strange because I did everytime a clean rebuild and I did also
> this morning before I wrote the mail. Now I did a new one and the result is
> correct (apart from few errors in my prgs I have corrected, paths etc that
> I wi
On Thu, 30 Jul 2009, Przemyslaw Czerpak wrote:
Hi,
> BTW why did you use different stop condtions in current readRequest()
> code instead of exact replication of above socket_*() code, i.e:
>
> cRequest := ""
> nLen := 1
> cBuf := Space
On Fri, 31 Jul 2009, Francesco Saverio Giudice wrote:
Hi,
> on 30/07/2009 20.29 Przemyslaw Czerpak wrote:
>> BTW why did you use different stop condtions in current readRequest()
>> code instead of exact replication of above socket_*() code, i.e:
>> cReques
On Fri, 31 Jul 2009, Francesco Saverio Giudice wrote:
Hi,
>> In above code you do not check for additional CONTENT-LENGTH data.
> [I have already seen your following message)
> The non inet code was the original I didn't use and I forgot to change. But
> I will check better your code and I will
On Fri, 31 Jul 2009, Francesco Saverio Giudice wrote:
Hi,
> ok, thank you.
Yet another advice.
Add to Handler_HrbScript() just after:
CATCH oError
this line:
hb_mutexUnlock( s_hmtxHRB )
otherwise error in one .hrb script blocks all other threads so they
cannot execute any .hrb script.
On Fri, 31 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> >This looks like side effect caused by results of some previous builds.
> >It's possible that if you clean all files left by previous builds then
> >above warnings disappear. If it will not help then I would like to see
> >whole log fil
On Fri, 31 Jul 2009, vszak...@users.sourceforge.net wrote:
Hi,
> Log Message:
> ---
> 2009-07-31 11:09 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * include/hbdefs.h
> * include/hbsetup.h
> * include/hbinit.h
> * source/vm/fm.c
> + config/sunos/sunpro.cf
> + Added first
On Fri, 31 Jul 2009, Szak�ts Viktor wrote:
Hi,
> AFAIK SunPro has SPARC 32/64 and x86/x64 CPU targets. It can be
> solved by simple few lines line long wrapper .cf files, so it won't
> create any maintenance nightmare. For this reason I don't see this
> is a problem at all in this case. It's howe
[pi�tek, 31 lipiec 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> > BTW I'm interesting in Windows results for above code so if possible
> > please I would like to ask desktop windows and WinCE/WinMobile users
> > to send here "total client time" for above test code executed in both
> > modes.
> Afte
On Fri, 31 Jul 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-07-31 12:29 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * source/rtl/hbinet.c
> % Cleaned old error description handling logic. Now the error
> desc is dynamically retrieved instead of being stored along
>
s\1.0\hb-mingw\bin\hbmk.cfg
>
> Harbour 2.0.0beta2 (Rev. 11919)
> Copyright (c) 1999-2009, http://www.harbour-project.org/
> Compiling 'tstrcv.prg'...
> Lines 109, Functions/Procedures 4
> Generating C source output to 'tstrcv.c'... Done.
Ups. MT suppo
On Fri, 31 Jul 2009, Szak�ts Viktor wrote:
> Sry i don't understand the problem. There is 1 to 1 relation between
> error nums and desc and num is still stored per socket. If the other
> is an issue it should be fixed elsewhere too
Ups. You are right - my fault. I haven't look at your modification
On Fri, 31 Jul 2009, Tamas TEVESZ wrote:
Hi,
> sunpro64.cf: cflags = -m64
> include sunpro.cf
> -- and that is all to a sunpro64.cf
> sunpro.cf: cflags ?= -m32 # not really, but essentially that
> -- other stuff in sunpro.cf
Yes it is but these flags are useful only if you want to o
On Fri, 31 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> Current Harbour under OS/2
> * $Id: ChangeLog 11949 2009-07-31 11:21:30Z druzus $
> 2009-07-31 13:21 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> It fail with:
>
> and m
On Fri, 31 Jul 2009, David Arturo Macias Corona wrote:
Hi,
> >If it still generates GPF then you can finally try sth like:
> >define create_library
> >echo $(LIB_DIR)/$@ > __lib__.tmp
> >$(if $(wordlist 1, 10,$(^F)), echo $(wordlist 1, 10,$(addprefix
> >-+,$(^F))) >> __lib__.tmp,)
> >$(if $(
On Fri, 31 Jul 2009, Szak�ts Viktor wrote:
> Citing "personal reason" is totally wrong. Unless messing/having fun
> with harbour counts as such. Please stop using this argument. Or i can
> drop dealing with every component which i dont use, this means about
> 90% of them. Imo we should allow such c
[sobota, 01 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> > Please rebuild Harbour after:
> >2009-07-31 13:21 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> > * harbour/include/hbthread.h
> >! unblocked MT compilation for WinCE
> >
ations.
Please try after:
2009-08-01 20:24 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Hi All,
I'll be offline for a week.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
On Tue, 04 Aug 2009, vszak...@users.sourceforge.net wrote:
Hi Viktor,
> 2009-08-04 03:32 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * source/vm/dynlibhb.c
> ! Fixed to not use dl*() functions on linux/sunpro.
Above modification simply broke working code by disabling all calls to
dl*(
On Sun, 09 Aug 2009, AbeB wrote:
Hi,
> i'm getting closer to the source of this bug.
> the index will start from the current record if the last movement in the
> Area was a Seek.
> it will start from the beginning of the file if the last movement was a
> Skip.
> Remember this only happens on a re
Hi Viktor,
when hbmk2 is used with GCC without support for
-Wl,--start-group/-Wl,--end-group then the order
of linked libraries is not sufficient to resolve
cross references.
Just try to compile this code (for test you can
disable -Wl,--start-group in mingw builds):
proc main()
browse()
On Mon, 10 Aug 2009, Szak�ts Viktor wrote:
Hi,
> Yes, the CRC16 is different indeed, but the CRC32 was the same, in
> fact (reading the old comments) the CRC32 code was taken from a generic
> unicode library, so it's nothing tpathy specific, before deletion
> I've verified the code table and form
On Mon, 10 Aug 2009, David Arturo Macias Corona wrote:
Hi David,
> Przemek:
> - having the sources and possibility to rebuild os2make381, have some
> benefit ?
> - The problem is with os2make381, and/or OS/2 command shell (CMD.exe) ? If
> later, can we use other ?
> - Is any other kind of envir
On Tue, 11 Aug 2009, FRANČEK PRIJATELJ wrote:
Hi Franček,
> This code (simplified version) worked few days ago, with rddntx or rddcdx).
> Today it crashes
> function main()
>use knjizbe new
>index on posel+dtos(dat_va) tag posel_datv to knjizbe
>wait
> return
> Today it crashes wit
On Tue, 11 Aug 2009, Szak�ts Viktor wrote:
Hi,
> I've recently fixed hb_fsCreate*() to honor FO_EXCL flag
> on win platforms (it was ignored before). AFAICS this error
> could be caused by interaction of temp file creation routines
> in fstemp.c and above change.
> I'm investigating, but I'd appr
On Tue, 11 Aug 2009, Szak�ts Viktor wrote:
> Okay, what happens now is that on win platform GetTempFileName()
> will create the file (and release the handle... bloody MS),
> and this causes hb_fsCreate() with FO_EXCL to fail permanently.
> There are a few options, but I'm unsure which is the better
On Tue, 11 Aug 2009, FRANČEK PRIJATELJ wrote:
Hi,
> No, before I ran program , I emptied tmp dir.
> In real application I index 10 dbf files before this one.
> I also tried (very simple) short version and real application
>with backup dbf that worked few days ago.
>Only diff
On Mon, 10 Aug 2009, vszak...@users.sourceforge.net wrote:
Hi Viktor,
> 2009-08-10 22:34 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * contrib/hbtpathy/telepath.prg
> * contrib/hbtpathy/tpcommon.c
> + TP_CRC16() reimplemented in .prg after reading Przemek's e-mail.
Maybe we should a
On Tue, 11 Aug 2009, Szak�ts Viktor wrote:
Hi,
> Here is darwin 'man mkstemp':
[...]
Thank you,
>| The implementation of these functions calls arc4random(3), which is
>| not reentrant. You must provide your own locking around this and other
>| consumers of the arc4random(3) API.
I do not li
On Tue, 11 Aug 2009, Szak�ts Viktor wrote:
>>> | The implementation of these functions calls arc4random(3), which is
>>> | not reentrant. You must provide your own locking around this and other
>>> | consumers of the arc4random(3) API.
>> I do not like it. It means that in MacOSX and probably in B
On Tue, 11 Aug 2009, Szak�ts Viktor wrote:
>> Maybe we should add to RTL set of functions to swap bytes in numbers?
>> I.e. hb_swapI(), hb_swapW(), hb_swapL(), hb_swapU(), hb_swapLL()
>> The suffixes should correspond to BIN2?() functions but maybe you have
>> better proposition for names.
>> With
On Tue, 11 Aug 2009, David Arturo Macias Corona wrote:
Hi David,
> This is an updated report:
> Current Harbour under OS/2
> * $Id: ChangeLog 12055 2009-08-11 07:57:13Z vszakats $
> 2009-08-11 09:55 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> a) gcc (GCC) 3.3.5 (Bird Build 2006-03-18 05:37
On Tue, 11 Aug 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-08-11 17:40 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> - tests/hbpptest/Makefile
> + tests/bldtest/bldtest.hbp
> + Added hbmk2 make files (quite simple ones) for these tests.
This have to be reverted. bldtest.c i
On Tue, 11 Aug 2009, vszak...@users.sourceforge.net wrote:
> 2009-08-12 00:07 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> - tests/bldtest/bldtest.hbp
> + tests/bldtest/Makefile
> ! Restored GNU Make file.
> Maybe we should move this file to somewhere else, perhaps
> inside
On Mon, 10 Aug 2009, Tamas TEVESZ wrote:
Hi,
> > > > * config/linux/sunpro.cf
> > > > ! Fixed to include gpm lib.
> > > > ; TOFIX: linux/sunpro linking dies on:
> > > > ../../../../../lib/linux/sunpro/libhbpcre.a(pcrecomp.o): In
> > > > function `check_auto_possessive':
> > > >
On Mon, 10 Aug 2009, Tamas TEVESZ wrote:
Hi,
> > > > HB_CMP = suncc
> > > > instead of CC and cc. With above version you do not have keep path to
> > > > Sun C compiler at the beginning of PATH envvar so both GCC and Sun C
> > > > builds can be easy used. It should work also in SunOS.
On Wed, 12 Aug 2009, vszak...@users.sourceforge.net wrote:
Hi,
> ; TODO: Streamline macro usage regarding external dependencies.
> There is currently HAS*, HAVE*, HB_HAVE*, HB_WITHOUT*
> plus some other variations.
> We should probably stick to HB_BUILD_WI
On Tue, 11 Aug 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-08-11 13:24 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * Cleaned LDLIBS usage:
One of recent modifications enabled some unnecessary libraries
in linking phase, i.e. now harbour compiler in Linux builds is linked
with
On Wed, 12 Aug 2009, Szak�ts Viktor wrote:
Hi,
> Thank you. It was explicitly invoking the shell command processor
> to launch the shell commands. Probably much better to use $(shell)
> command in case such forced shell invocation is to be used, but
> these weren't such cases.
I only guess but I
On Wed, 12 Aug 2009, Szak�ts Viktor wrote:
>>>; TODO: Streamline macro usage regarding external dependencies.
>>>There is currently HAS*, HAVE*, HB_HAVE*, HB_WITHOUT*
>>>plus some other variations.
>>>We should probably stick to HB_BUILD_WITH_* for user
>>>
On Wed, 12 Aug 2009, vszak...@users.sourceforge.net wrote:
> 2009-08-12 14:59 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * config/wce/mingwarm.cf
> * config/win/mingw.cf
> - Deleted ranlib usage. I've tested with mingw 3.4.2, 4.4.0
> and mingwarm 4.4.1, and the runlib command ma
On Wed, 12 Aug 2009, David Arturo Macias Corona wrote:
Hi,
>> This seems to be problem we had in the past. HBRUN used some code which
>> causes such effect but I do not remember what it was. It's also
>> possible that I'm wrong and it's new problem.
>> Anyhow we will have to locate it.
>> Do othe
On Thu, 13 Aug 2009, Marco Bernardi wrote:
Hi Marco,
> It seems to me that GTSLN do not send properly inkey code like defined in
> inkey.ch for EXT_INKEY
> I means CTRL_Y should be code 537 if xharbour is compiled with #ifdef
> HB_EXT_INKEY, while it should be 25 otherwise. By default xHarbour
On Thu, 13 Aug 2009, toni...@fwi wrote:
Hi,
> > Please test it after:
> Przemek, seems that all is working fine.
Thanks for the information though it probably needs deeper tests
to eliminate possible typos in different translations. I've found
in xHarbour many wrong translations and no one has b
[czwartek, 13 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> I can't execute any WinCE app from harbour app.exe
> f.e. :
> app.prg
>
> link_ := '\Windows\calc.exe'
> hb_run(link_)
>
> do nothing.
> Any idea ?
hb_run() simply executes
[pi�tek, 14 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
> The same :(
> hb_processRun() return -1
Then it means that CreateProcess() is not supported by your OS
or some other errors appeared (wrong path, too much processes,
insufficient permission, etc.)
Try to check HB_OSERROR() code after hb_
[pi�tek, 14 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> PC> Then it means that CreateProcess() is not supported by your OS
> PC> or some other errors appeared (wrong path, too much processes,
> PC> insufficient permission, etc.)
> PC> Try to check HB_OSERROR() code after hb_processRun().
[pi�tek, 14 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> PC> Then it means that CreateProcess() is not supported by your OS
> PC> or some other errors appeared (wrong path, too much processes,
> PC> insufficient permission, etc.)
> I've found similar problem in this thread :
> http://www.t
[pi�tek, 14 sierpie� 2009], Przemyslaw Czerpak napisa�(a):
> I'll hack hbprocess.h to pass NULL in lpProcessInformation in WinCE
> builds and hb_processRun() function. The process result will be hardcoded
> to 0 and of course we will not have anything to wait for process termination.
On Fri, 14 Aug 2009, toni...@fwi wrote:
Hi,
> >If possible please make simple test and add at the end of
> >hb_oleItemToVariantRef() code:
> > if( pVarRef )
> > {
> > pVarRef->n1.n2.vt = VT_VARIANT | VT_BYREF;
> > pVarRef->n1.n2.n3.pvarVal = pVariant;
> > }
> I do it and now all b
[pi�tek, 14 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
> PC>2009-08-14 14:00 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> PC> If you confirm it works then I also update __run() and hb_run() in
> PC> WinCE builds to not use system() command.
> Thanks. I&#x
On Fri, 14 Aug 2009, Szak�ts Viktor wrote:
> Hi Przemek,
> Probably the OS CP conversion should still be retained in this case.
Yes but not here.
See my second commit.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lis
On Fri, 14 Aug 2009, toni...@fwi wrote:
Hi,
> >Please also add at beginning of function hb_oleVariantToItem()
> >
> > if( pVariant->n1.n2.vt == VT_VARIANT | VT_BYREF )
> > pVariant = pVariant->n1.n2.n3.pvarVal;
> >
> >and then test again.
> Hi Przemek, same result: all var is nil and now g
On Fri, 14 Aug 2009, Szak�ts Viktor wrote:
> I think this is a new one:
[...]
> POLINK: error: Unresolved external symbol '_beginthreadex'.
> POLINK: error: Unresolved external symbol '_endthreadex'.
It's possible because MT support for WinCE was disabled.
Look at HB_THREAD_RAWWINAPI in include/hb
On Fri, 14 Aug 2009, Szak�ts Viktor wrote:
> It's not over yet though :( Here's the next new one:
> ---
> pocc.exe -I. -Ze -Go -W1 -Ot -Tarm-coff -D_M_ARM -D_WINCE
> -I../../../../../include-DUNICODE -Foolecore.obj -c
> ../../../olecore.c
> ../../../olecore.c(239): error #2152: Unknown field '
On Fri, 14 Aug 2009, toni...@fwi wrote:
Hi,
> Only to you understand scenario, I have a simple call:
> ---cut---
> local nRet:= 1, cTitular := "", cCnpj := "", cNumeroSerie := "",
> cEmissor := "", cInicioValidade := "", cFimValidade := "", cMensagem
> := ""
> nRet = ::oNFEUtil:PegaDadosCertifica
[piątek, 14 sierpień 2009], Jaroslaw Kadziola napisał(a):
Hi,
> > Thanks. In such case I'll update __run() and hb_run() in a while
> > so you can test also them.
> Unfortunately the same errors -1/87 after download hbproces.c from SVN
> and build all libraries for WinCE.
I hope that you haven't
On Fri, 14 Aug 2009, Szak�ts Viktor wrote:
> ---
> ../../../hbsocket.c:179:1: warning: "socklen_t" redefined
> In file included from /usr/include/sys/socket.h:15,
> from ../../../hbsocket.c:167:
> /usr/include/cygwin/socket.h:24:1: warning: this is the location of
> the previous de
On Sat, 15 Aug 2009, Szak�ts Viktor wrote:
Hi,
> Regardless of this fix, maybe Harbour PP could be modified to
> not throw a warning when the redefinition is identical to the
> original value, just like in C. Przemek, what's your opinion?
Such warning is standard Clipper behavior and I do not th
On Sun, 16 Aug 2009, maurilio longo wrote:
Hi Maurilio,
> without the comspec trick a make install freezes, the shell cannot even be
> killed anymore :(
Which GNU make version are you using?
Have you tried to use 3.81?
best regards,
Przemek
___
Harbo
On Sun, 16 Aug 2009, Tamas TEVESZ wrote:
Hi,
> > I've partially moved some former logic in make_gnu.sh
> > to linux/global.cf with notes left in ChangeLog and the
> > file. Logic should be completed (I didn't have enough
> > information to implement it in the more limited GNU Make
> > syntax
On Mon, 17 Aug 2009, Szak�ts Viktor wrote:
Hi,
> UNIX vs. UNIX_COMPATIBLE: hard to tell, but this may be possible
> to clean to have only one of them (the former ideally).
Now we used to use HB_OS_UNIX to mark UNIX compatible OS-es
so we can eliminate HB_OS_UNIX_COMPATIBLE macro.
best regards,
On Sat, 15 Aug 2009, vszak...@users.sourceforge.net wrote:
> 2009-08-15 11:48 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * utils/hbmk2/hbmk2.prg
> ! Minor fix for darwin and automatic entry function detection using 'nm'.
> nm on Darwin doesn't seem to support '--defined-only -C' o
[pi�tek, 14 sierpie� 2009], Jarosław Kądzioła napisa�(a):
Hi,
> > If current hb_processRun() fails then please try to change in
> > hbproces.c[219]:
> >fError = ! CreateProcess( NULL, /* lpAppName */
> > lpCommand, /* lpCommandLine */
> > to:
> >
On Mon, 17 Aug 2009, Maurilio Longo wrote:
Hi,
> Anyway, I have the full gnufutils installed, so I'll do a test with cp,
> without even moving it inside config since it is in my PATH.
So I guess you also have some *sh.exe files in your path.
Maybe it's the reason of your problems with rules with
[poniedzia�ek, 17 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
> PC>proc main( ... )
> PC> alert( hb_valToExp( { ... } ) )
> PC>return
> PC> Seems that to pass parameters we will have to make some additional
> PC> modifications and I would like to know if application name is stripped
On Mon, 17 Aug 2009, David Arturo Macias Corona wrote:
Hi David,
> First try with gcc 4.x.x and OpenWatcom wlink.exe as linker
[...]
> Downloading wl-hll-r1.zip wl.exe show:
> --
> [E:\wl-hll-r1]wl
> ** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 1.6beta1 Limited
> A
[poniedzia�ek, 17 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> > I would like to ask you about some others yet.
> > Above code does not allow to pass parameters.
> > Can you modifiy it to:
> >fError = ! CreateProcess( lpCommand, /* lpAppName */
> > lpC
[poniedzia�ek, 17 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> > Just simply execute above program (let's call it myprg.exe) from other
> > Harbour application, i.e.:
> >proc main()
> > hb_run( hb_dirBase() + "myprg.exe" )
> >return
> > I'm interesting in parameters passed to
On Mon, 17 Aug 2009, Szak�ts Viktor wrote:
> Output in C++ mode:
> silver:bin vszakats$ nm tstrcv.o -g -n
> U _HB_FUN_AT
> U _HB_FUN_EMPTY
[...]
> U _hb_vmProcessSymbols
> 0050 T _HB_FUN_MAIN
[...]
> ---
> Output in C mode:
> silver:bin vszakats$ nm tstrcv.o -g -n
>
[poniedzia�ek, 17 sierpie� 2009], Przemyslaw Czerpak napisa�(a):
> please try to recompile Harbour for WinCE with small patch I'll
> commit in a while and then try to make test for passing parameters.
I have just committed it:
2009-08-17 19:42 UTC+0200 Przemyslaw Czerpak
On Mon, 17 Aug 2009, Itamar Lins wrote:
Hi,
> $Id: ChangeLog 12153 2009-08-17 18:02:30Z vszakats $
> With MSVC, OS Windows XP SP3.
> Function Main
> ? oemtoansi(cmonth(date())) //I Get GPF.
Harbour does not have OEMTOANSI() function so it's not our problem.
best regards,
Przemek
__
On Mon, 17 Aug 2009, Lautaro Moreira wrote:
> Hi !
> I have the same warnings.
> This is normal ???
Yes it is.
I hope that Viktor reduce warning level before someone starts mechanical
warning cleanup hiding real bugs and introducing very serious problem
for types modification in the future.
best
On Mon, 17 Aug 2009, Itamar Lins wrote:
> Best way hbmk2 inform oemtoansi() not found. Because hbmk2 compile fine now
> show error, is not my function. HB_ prefix resolve the problem.
1-st it's not hbmk2 job but used linker which is called by hbmk2.
HBMK2 cannot have such functionality.
2-nd AFAI
On Mon, 17 Aug 2009, Itamar Lins wrote:
> I found the problem.
> Colision again Hwgui function.
> Piece of code hwgui\source\drawtext.c
> #ifndef __XHARBOUR__
> HB_FUNC( OEMTOANSI )
> {
>char *buffer = hb_parc( 1 );
>OemToChar( buffer, buffer );
>hb_retc( buffer );
> }
> HB_FUNC( ANSITO
Hi Viktor,
We have in xhb.ch:
#xtranslate __Keyboard([]) => xhb__Keyboard()
#xtranslate __CopyFile([]) => xhb_CopyFile()
#xtranslate Subscribe( )=> xhb_mutexSubscribe( )
#xtranslate SubscribeNow( ) => xhb_mutexSubscribeNow( )
#xtranslate
On Tue, 18 Aug 2009, Szak�ts Viktor wrote:
> In line 47 TARGET is set to 'i386-mingw32msvc', but the
> check is made for 'i386-mingw32-gcc' before. This
> is so since very long, but I wonder if 'msvc' ending in
> line 47 is just a (copy-past) typo?
Looks like a typo but don't ask me about correct
[wtorek, 18 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> After recompile Harbour for WinCE and compile 2 programs:
>
>/*** myprg1.prg ***/
>proc main()
> AltD()
> yy=hb_run("\myprg2.exe" )
>return
>
> /*** myprg2.prg ***/
>proc main( ... )
> Alert(hb_val
On Tue, 18 Aug 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-08-17 10:15 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * config/global.mk
> + Implemented win/mingw cross-tool autodetection.
> Based on the logic found in make_gnu_xmingwce.sh. It's not
> exactly the sa
[wtorek, 18 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> Done
>/*** myprg1.prg ***/
>proc main()
> AltD()
> yy=hb_run("\myprg2.exe par1 par2" )
>return
>
> i've got on screen : -
> | {"par1","par2"} |
>
On Tue, 18 Aug 2009, Szak�ts Viktor wrote:
Hi,
> I don't see why they would need to edit any make files.
I do not think that we ever directly address 10% of platforms where
Harbour can be compiled. It's technically impossible so if we
make build process too complicated to easy adopt it for some
[wtorek, 18 sierpie� 2009], Jaroslaw Kadziola napisa�(a):
Hi,
> Of course yy = 0,
> hb_valToExp( { ... } ) = {"\myprog2.exe","par2","par3"}
Thank you for confirmation.
Current SVN code of hb_fsProcessRun() (hb_fsProcessExec()) is working
correctly with parameters for WinCE.
Please only remember
On Tue, 18 Aug 2009, vszak...@users.sourceforge.net wrote:
Hi,
> on linux hosts:
>-> wce/mingwarm
>-> win/mingw
>-> win/watcom
>-> dos/watcom(*)
I'm creating such binaries but they do not work probably due to problem
with Linux 'wlink' port which I hope wi
On Tue, 18 Aug 2009, Szak�ts Viktor wrote:
> I'd still like to address watcom cross-compiler support, but
> regarding this area that's the only remaining item pending in queue.
For me it works quite well. I only have to set:
export HB_ARCHITECTURE=dos
export HB_COMPILER=watcom
export HB_
On Tue, 18 Aug 2009, Szak�ts Viktor wrote:
>> We do not use autoconf so we have to guess what is available
>> on given platform. It creates potential problems in portability,
>> i.e. to older systems. I guess that current Harbour cannot be used
>> with older MacOSX or Linux builds. Now I'm trying t
On Tue, 18 Aug 2009, Szak�ts Viktor wrote:
Hi,
>> I'll look at it but I'll wait for real final versions.
>> It's hard to follow or your modifications.
> 'real final version' :) okay, please consider current state as
> pretty much it. I can't promise I won't have any new idea along
> the way, but
On Tue, 18 Aug 2009, Szak�ts Viktor wrote:
Hi,
> Did 'echo' work alright in your tested environments?
It was but AFAIR I have echo.exe in DJGPP bin dir so I will
have to test it without it. I'll check it later.
> I was thinking to add an $(ECHO) variable to make it
> configurable. [ F.e. on som
On Tue, 18 Aug 2009, Przemyslaw Czerpak wrote:
> > Did 'echo' work alright in your tested environments?
> It was but AFAIR I have echo.exe in DJGPP bin dir so I will
> have to test it without it. I'll check it later.
I've just checked it and it doesn't work wh
On Wed, 19 Aug 2009, elart wrote:
Hi,
> On Ubuntu 9.04 32 bits compiling from latest svn sources when i try make
> install i get this error
> make[3]: `../../../../../lib/linux/gcc/liblibhpdf.a' is up to date.
> ! Installing ../../lib/linux/gcc/liblibhpdf.a on /usr/local/lib/harbour
> ! 'libpng'
On Wed, 19 Aug 2009, David MS wrote:
Hi,
> Hi, I've a problem with outstd(),
> when I do...
> outstd(space(53218))
> nothing is output to the console . Under this limit outstd() works fine.
> I'm using Harbour 2.0.0beta1 (Rev. 11413) under XP
Harbour writes all stdout() output in single WriteF
1 - 100 of 2668 matches
Mail list logo
